AI活用の社会的ムーブメント
こんにちは、ゼロトピックです。 今日は、TenXの中で、LLMの活用について
どういうふうに考えて、経営として取り組んでいるか、 みたいなところをご紹介できればと思っています。
背景としては、昨今、LLMというか AIを活用したツールって、本当に
大挙に挑まないというか、UGOのタケノコのように 毎日何か出ては、かつそれを使って
こんなことをできましたっていう、 プラクティスについての発信っていうのを
個人も企業も我先にとしていて、 それによって自社のAI活用みたいなものを
率先して取り組んでいこう、やっていこうっていう、 なんかそういう社会的なムーブメントが
起きているなっていうふうに、 個人的には思っています。
このムーブメントを見てというか、 そもそもLLM、AIみたいなものを
自分たちの会社にどう取り入れていようかって、 考えない経営者はいないと思うんですよね。
それは自分も同じで、自分自身も いろんな活用の仕方をしてはいる
っていうところがあります。 でも一方で、ここまでの間、会社としては
こうしていきますっていうのは、 結構発信自体はしていなかった。
それは社内的にも正式な指針だったり、 ルールみたいなものを定めずに来ていて、
それはまだ定めるには時期が早いなっていうふうに 思っていたり、
またどういったことを決めていかないといけないのか っていうことに対する解像度が
なんとなく手触り感が足りなかったんですよね。 なんですけど、やっぱりちょっと
ゴーニアしてと言いますか、 社内で検討のようなものを
急速に始めようっていう機運を感じまして、 自分が一応旗振りをして、
例えばCTOの石川さんとか、 あとはデータサイエンティストの方、
セキュリティエンジニアの方を ぐっと指揮者として集めて、
このLLMをどう活用していくかってところの、 検討会みたいなのも立ち上げて、
社内の指針まで落とし込むってことを この2週間ぐらいでやりました。
そこの背景とか、あと決まったものも 合わせてご紹介できればなっていうふうに
思っています。 まず初めに、その検討会の前に、
自分がどう考えているのかっていうのを 先に出す必要があるなと思って、
社内的なメモを作ったんですよね。 それを簡単にお話しさせていただきますと、
このAI技術だったり、特に大規模言語モデル、 LLMの進化っていうのは、
やっぱり企業活動においては、破壊的に根本から 何かを変える可能性があるものだと思っている。
し、その検討を始めた時点では、うちの中だと、 特にDevynを活用した開発生産性の向上みたいなものが
明確に確認されていたっていう状況なんですけども、 もう少し単純な技術導入を超えた、
体系的なアプローチみたいなものを しなきゃいけないなっていう危機感、
そもそも持っているという状態でした。 もっと前提としては、企業活動に浸透していくことは、
短期中期の目でも避けられない不可避の流れだと思っているし、 積極的に使っていきたいという経営者としての
個人的な前提がそもそもあるという前提があります。 その上で、いくつかの前提とする要件みたいなものを
固めてクリアしていかないと、逆に言うと怖い モロ派の剣になってしまうなと思っていて、
その点を少し言及しています。 例えば、守りの要件として、リスク管理とかガバナンスみたいなものっていうのは、
より重要になるだろうなというふうに思いました。
AAを特に積極的に活用しようと思ったとき、 ツールを導入するとか課金するとかってことは、
ぶっちゃけクリック2つで終わるので、 何のハードルもないんですよ。
要は誰でも使える。予算さえあれば誰でも使える。そんなことよりも、
適切なガードレールが設置されているっていう、 企業の内部の構造のほうがずっとアクセルを踏むためには
重要な要件になっている。そういうふうに思いました。
例えばなんですけど、どういうものかというと、 データセキュリティやったりプライバシー保護。
要はAAを活用して、自社の重要なデータが漏れるっていう、 そういったインシデントを起こさないためには、
どういったふうに守られているかでしたり、 またはコンプラとか法的リスクの管理。
例えば、我々は対企業に対して契約をしているわけで、 その契約の責任範囲だったり、
あるいはそこに対するAAの関与みたいなものを、 どうやって整理、区切るかといったところですね。
あとはハルシネーション、誤情報が生成されるという問題を、 どうやって検知して扱うのか。
あとはインシデントが起こってしまった場合、 特にAAが関与したインシデントが起こってしまった場合は、
どうやってリカバーし、どうやって説明責任を果たすのか。 こういったものをどうやって運用するのかといった、
言いつつ、こういったものをしっかりガードレールとして 整備しておかないと、いざ何か起きたときには、
もう遅いというふうにリスクとして感じていました。
こういうリスクが解消できていない中だと、 やっぱり心の負担もあったんだろうなと思っていて、
踏み切るみたいなものをバッと宣言すること自体が難しいなって、 言語化していなかったですけど、感じていたんだろうなと思っています。
攻めの要件のところでは、3つぐらいあって、 結局AAを活用することが、事業にどんだけインパクトするのというのが一番大事で、
Where to playというか、どこでそのAIを活用するのというのが 一番重要なことだと思っています。
要は、事業に何のインパクトもないのに、 AIでこれできましたみたいなのは本当に意味がないと思っています。
AIに限らずどんなツールでもそうですね。
また、それを活用するための技術的な要件の検証だったり、
またAIと人が共同していくための基盤とかワークフローみたいなものも 整備する必要があると。
この中でも特に自分が一番重要視したのは、 一番目のビジネス上のインパクトだと思っていて、
やっぱり全ての会社が同じビジネスをしているわけではないので、 自分たちのビジネスには一体どういうレバー構造があって、
その構造の中でAIというのは何にどのぐらい効くのか。
そういった見積もりとか仮説とか、 あるいはその検証がないまま、
ただただ導入だけ進めても、実際はただのコストなので、
本当の意味でいうと成果が出ないだろうというふうに思っていました。
というので、この辺を掲げた上で、 自分としてはそれでも積極的に使うべきだから、
いろんなものを要件として書きましたけども、
固めていきつつ、そのAIの検証をしていこうぜっていうのを 旗振りをさせてもらったわけですね。
具体的なAIツールの活用方法
特に自分も結構いろんなニュースとかが出たりすると、
このアプリケーションを触ってみたり試したいけど、 会社の環境だとできないなとか、
そういったこともあって、自分自身も振り回されてるな というふうに思ったりしたんですよね。
なんですけど、やっぱり会社の中で正式に導入したツールも、
2ヶ月ぐらいでそのツールを解雇したりということもよくあって、
来年同じものを使っている可能性は低いなと。
であれば、アプリケーションを 人が分散的にバラバラ検証していくみたいなものって、
やっぱり本質的には価値がなくて、
本当に重要なアプリケーションを 自分たちの重要なオペレーションに載せられるだけの
固い基盤というか、それを会社とかプロダクトとか オペレーションの領域でしっかり作って、
さっきのデータとかセキュリティとかコンプラ、 ハルシネーション、
ああいった問題を解決できます。なので、どんどん試せますよ。
なのか、しっかり選んだものを使っていけますよ って状況を作る必要があると。
そういった形で、まずは自分の考えを発信した というのがスタートになります。
これ出してから本当に3日後ぐらいには、 さっき話したようなメンバーを集めて、
実際に会議をして、その場で指針の骨格を作って、
同じ州の中でその指針自体を開示する っていうことをさせてもらいました。
ここではその指針自体もぜひお伝えできればな っていうふうに思っています。
前置きですね。前置きとして、さっき話したような、
AI、あるいはAIを使ったツールみたいなものが 企業活動に浸透していくっていうのは、
やっぱり不可否の流れですっていうことは、 会社の中でも宣言させてもらっていますし、
それは積極的に使うべきだっていう話をしています。
その上で指針は6ですね。6つの項目からできていて、
その1つ1つをちょっと読み上げていきます。
1つ目、AIツールの活用。
これの成果およびゴールっていうのは、 開発生産性の増加とする。
ここで開発生産性の増加とするって言ってるのは、
ある種、今出ているいろんなAIツールの中で、
もっとも我々が恩恵を受けられるのは、
この開発、ソフトウェアが開発するっていう、 この領域だっていうふうに、
ほぼほぼ固定したんですね。
その上で、この領域についてまずしっかり ガードレールを引いていくのが大事。
指針を示すのが大事っていう形で、 ここにスコープを当てています。
この開発生産性っていうものも定義が大事だと思っていて、
基本生産性っていうのは、 生み出される負荷価値を、
それにかかるコストで割ったものなんですけど、
開発って、すぐに例えば荒りにつながるとか、
売上につながるってものってないと思ってるんですよね。
基本的には、こう、事項してそういう効果が出てくる。
ビジネスインパクトが出てくるので、 やっぱりその手前で測る必要があって、
我々でいうと、全ての開発チームが、
プロダクト本部っていう本部機能と、 2週に1回チェックインをして、
そこで成果の確認だったり、 フィードバックを受けるみたいな、
モニタリングの機構を持ってるんですよね。
なので、僕らの会社として認識する、 開発の成果、物みたいなものは、
そこでチェックされるので、 これが分子側、成果であると。
一方で、分母側は、そのLLMだったり、 ツールを活用するにかかる、
実質的なコストとか、 認知的なコスト、みたいなコスト。
この2つで、生産性を評価していこうとしています。
2つ目、開発向けのAIツールっていうのを、 4類型で整理します。
特に大きな権限をツールに委ねるエージェント型は、
期待リターンもリスクも大きいと考えられる、 というふうに書いてるんですけども、
この4類型っていうのは何かっていうと、 開発環境がローカルかリモートか、
あとはツールの性質が、 アシスタント型かエージェント型の4つで、
ざっくりとこのデベロップメントツール みたいなものを分類しています。
例えば、ローカルのアシスタント型は、 コパイロットチャットとか、
クラインのローカルLLM、 カーソルのローカルLLM、
ジェミナイのコードアシスタント、 こういったものを分類しています。
逆にローカルのエージェント型っていうのは、 コパイロットエージェント、
クライン、カーソル、クラウドコードとかですね。
リモートのエージェント型は、 ちょっと今のところ分かってなくてないです。
リモートのエージェント型は、 Debian AIだったり、
コパイロットワークスペースみたいなもので、
ちょっと今、我々が触れるものっていうのを、 こんな形で分類をしています。
このアシスタントとエージェントの違いは、 アシスタントは実行権限を持たずに、
あくまで支援とかサジェストだけをするもの。
基本的に単一のファイル情報だけを利用するもの。
AI活用のリスク管理
エージェントは場合によっては承認なしに、 ターミナルでコマンド実行まで可能なものを指す。
基本的にワークスペース全体の情報を活用できるもの、 っていうものを類型として分けています。
指針の三つ目ですね。
AIツールの活用には、事業継続を脅かすリスクを 最小化する必要がある。
継続的なリスク評価とリスク抑制の取り組みを行う。
これは自分が借り出しのドキュメントで 書いたようなものですね。
事業継続を脅かすリスクを回避するための 明確なルールを定義するっていうことをしたいんだけど、
現時点では技術があまりに不確立すぎて難しいと。
なので、TENXでは検証するっていうリスクは取りながら、 知見を溜め込んで、
守りの要件をもっとクリアな解像度で固めていく っていう方針を取ることにしました。
このため、現時点では全てのガードルを カチッと引くってことはできないんですけど、
三つ取り組んで、その三つの取り組みを継続する中で、 都度リスクを評価しようとしています。
公式ツールとMCPサーバー
一つ目はツールを制限しますと。
さっき4類あったんですけど、 会社として公式に利用するツールっていうのは、
公認のものを絞り込んで集約しますと。
集約することで、作っている会社に 僕らはリスクを意向するような形になると思うんですけど、
リスクの意向先っていうのを限定できるので、 何でもかんでも、
例えばオープンソースも含めて、 何でも誰でも使っていいという環境ではなくて、
うちの会社では会社として公認したものだけ 使えますという環境になっています。
二つ目が権限管理で、これは当たり前なんですけど、 過剰な権限を個人、
それは使う個人ですね、持ちすぎないということが、
ある種エージェント型AIに同様に権限を 渡しすぎないという状態につながっていくので、
安心して渡せる状態を目指す。
過剰とは何かというと、その権限が行使されると、 本番データが破壊されたり、
本番コードが破壊されたりするなどの 破壊的なリスクが起き得るものということを
過剰と指しています。
三つ目はモニタリング体制を整備しようという形で、 不審なログ検知、
例えば大量に変な時間にプールリックが 大量に飛んでくるとか、
そういった不審ログを検知する環境だったり、 あるいはローカル環境を監視するように
EDRの導入というものを進めていきます。
始めの段階でこの今挙げたような三つが 全部揃っている状態ではないんですけども、
この辺を順次揃えていきながら ツールの検証を進めていこうというふうに言っています。
指針の四つ目は、会社としては公式に利用する ツールはドキュメントにまとめますよと。
これ今何を公認としているかなんですけど、 結構いっぱいあって、GitHub Copilot、
Devian AI、Klein、Gemini、ここまでは既に 社内申請も承認済みで使えますという形になっています。
ディープシークは逆で禁止となっています。
今、社内申請を倫義中のものがカーソル、 クロードコード、チャットGPTという形になっています。
この他、MCPサーバーも今三つ。
Notion MCP、Figma MCP、GitHub MCP、この三つについて、
社内の倫義をこれから回して公認ツールに していけないかというのを検討していく段階になります。
五つ目は、ここまでコーディングアシスタントとか コーディングエージェントについて触れているんですけど、
そこにちゃんと情報を渡すためのMCPサーバーについても その有用性の検討自体を行おうというふうに話しています。
このMCPサーバーが持つリスク要素自体は エージェント型のツールと近しいと思っているので、
同じような環境が整備していければ、
MCPサーバーについても自信を持って 安心して使えるんじゃないかなと思っています。
これについては、守り側はそこで守れるとして、
そもそも本当に有用なんだっけという検証の方が うちの会社の場合は足りていないので、
そこはどんどん検証していこうと。
かつ、有用性があって継続的に使うようなものっていうのは、
内製化自体も検討できるよねと思っているので、そこに触れています。
AI活用の未来と会社方針
最後予算は、基礎にこういった検証予算を立てているので、
その中で管理しましょうと。
それを大幅に超過したい場合みたいなものは、
基本的にはやっぱり成果とセットですよと、 説明責任を果たしてくださいという形式にして、
こういった形でAIを活用していくための、
会社の中の要件みたいなものを言語化して、 指針として開示しています。
というところですね。
冒頭でも触れたんですけど、そもそも積極的に使いたいし、
生産性すごい上がると思っている。
自分自身も、例えばGemini 2.5 Proの ディープリサーチとかはめちゃ使っていて、
特に今、新規プロダクトの営業とかをかけていく時の 事前調査として、あんな優秀なものないなと。
ああいうのがあると、やっぱり一人で営業できる先は どんどん増えていくなと思っているので、
めちゃくちゃ積極的に使いたいし、 使える領域ももっと広げたいと思っている。
一方で、やっぱり壊してはいけないものも たくさんあると思っていますし、
他の場合は、ビジネスの相手が非常に大企業で、 扱っているデータもセンシティブデータが多いという、
そんな事業ですので、 もしかしたら一般的なSaaS企業とか、
C向けのプロダクトをやっている企業よりも、 少し冷静にAIみたいなものと付き合えるように、
まずはしっかり社内を整備して、その整備したものに 安心して乗せて使っていけるような環境を作ろうと、
そういった考えでやっています。
実はこれプロダクトでの適用も、 ほとんど同じ考えになっていて、
これは自分というよりはCTOの石川さんが 積極的に進めてくれているんですけど、
ソースコードをいかにテスタブルにしたり、 責任を分割していくかというのが、
まさにこういったAIにコードを書かせたり、 エージェントに丸っと書かせたりする上では、
非常に重要な環境だと思っているんですよね。
どうしてもやっぱりHuman in the loopで、 最後は人間の目でプルリクエストをレビューしたり、
チェックしていったりするんですけど、 どうしても抜け落ちるものがあるので、
やっぱりそこをしっかりテスト、 自動テストでガッチリ守っていくですとか、
責任の範囲をクリアにしておくことで、
AIがどこに何の影響を及ぼしたのかというのが、 一目で分かるような環境を作っていくと、
やっぱりAIと一緒にソフトウェアを構築していくというのは、
もっと安心しながらできるだろうという、 そういったビジョンの下、
石川さんが儚い技術面でそこを引っ張って、
既存のステーラーネットスーパーのソースコードを 利用してくれている、そんな状況なんですね。
会社として取り組んでいることも、 技術的に取り組んでいることも、
うちは今土台がためになっているし、
それこそが本当この数ヶ月じゃなくて、 数年かけた時には大きな差を生むと思っているので、
そういった考えで、AIを自分たちの会社、 開発に取り組んでいこうと思っています。
ざっと以上になりますかね。
弊社ではソフトウェアエンジニアも、 今大募集しているんですが、
こういった考え自体も、 実は会社を選ぶ上で重要なんじゃないかなと思って、
今回自分の口から発信させていただきました。
ということで、今回もお聞きいただきありがとうございました。
