生成AI時代に「生成AI以外」の技術戦略を考える
Ubie で VP of Technology を担当している yuku (@yukukotani) です。
前回に続き、思考をちゃんと言語化する練習。今回は、生成AIをレバレッジするために、生成AI以外で戦略的に投資するべき技術を考える。コンセプトは、いかに生成AIの自律を支援するか。
TL;DR;
静的解析や自動テスト、認可といった機械的・決定論的制約によって、AIが単独でPDCAを回す領域を最大化し、人間というボトルネックを排除する
"超優秀なコピペプログラマ"たる生成AIにとっては、割れ窓や方言の存在がクリティカル。いかに"唯一の綺麗な型"を教え込んで横展開していけるか
仮説を持たない探索的データ分析が可能になる。そのインプットとしての生データの価値が上がる
静的解析と自動テストで決定論的な制約を与える
生成AI時代のソフトウェア開発においては、古典的な静的解析（Lint、型チェック）や自動テストによって、決定論的に検査できる領域を増やすことがより重要になる。
前提として、生成AIを用いたプロセスを次のように雑に分解する。
人間のニーズに対して
生成AIが成果物を提出し
人間が確認して受け入れる
このプロセスにおける静的解析・自動テストの重要性を、2つの観点から考える。
AIエージェントによるPDCA
生成AIを用いたソフトウェア開発の走りといえばGitHub Copilotだろう。そして最近ではDevinやCursor Composer、ClineのようなAIエージェントが登場している。
では、Copilotとエージェントの違いはなんだろうか。それは、(1)~(3)のサイクルの大きさ。つまり、Copilotはスニペットの単位で人間が確認してTabで承認する一方で、エージェントはPull Requestになるような、より大きい作業単位で人間が確認する。
言い換えると、粒度の細かい(1), (3)が自動化され、人間が指示・確認せずともAIが独立してPDCAを回すということ。自動化のためにはAIの成果物を機械的に検査してフィードバックする仕組みが必要で、静的解析や自動テストがその役割を担う。
静的解析・自動テストの実行速度もより重要になるだろう。AIエージェントは時間の流れ方が人間とは全く違う。あるコードを書くのに30分かかる人間が1分間の静的解析を回すのと、30秒で書けてしまうAIエージェントのそれとでは、ボトルネックさが段違いである。
受け入れ確認の効率化
(1) のニーズ把握については、現時点ではまだ具体的な指示を出すシーンが多く人間がボトルネックだが、非構造データを解釈できる生成AIの性質からして、多くの部分を生成AIに委譲していけそうと感じている。
実際Devinでは、「このリポジトリのリファクタリングすべきポイントを直して」というような抽象的な指示でも、改善点を提案して動いてくれる。より多くのコンテキストをうまく与えられるようになれば、この指示すら不要になるだろう。
一方で、(3) の受け入れ確認については、非決定的な生成AIには任せにくい。人間よりも性能が良いという話もあるが、責任の所在みたいな論点もあり、完全な委譲は難易度が高いと感じる。そうなると人間がボトルネックであり続けるため、効率化が重要になる。
ここで、静的解析や自動テストによって機械的に担保されている領域が大きければ、人間が確認することが減り、ボトルネックを小さくできる。
別にこれは真新しい話ではなく、怠惰を美徳とする我々は今までもそうやってコードレビューを自動化してきたわけだけど、生成AIが今までと比べ物にならない量のコードレビューを要求してくる時代においては、より頑張らなきゃというシンプルな話。
以上より、生成AIを最大限活用するためには静的解析と自動テストが重要である。技術選択においては、例えば動的型付け言語やLinterエコシステムが弱い言語は不利になるだろう。
また、ここではソフトウェア開発について考えたが、文書生成における textlint などでも同様のことが言える。むしろソフトウェア開発だけ異常に静的解析が発達しているので、その他のフィールドではこれからの投資で差がつきそう。
コンテキストをシンプルに標準化する
社内で様々なコンテキストを標準化することも生成AI活用の鍵となる。ソフトウェア開発の文脈で平たく言うと、プログラミング言語やアーキテクチャ、コーディング規約といった技術選択は全社で統一されていたほうが良いということだ。
またしてもDevinの例だけど、Knowledgeという機能があり、フィードバックした内容を自動で記憶してくれる。Cursor や Cline も自動とはいかないが、 .cursorrules や .clinerules ファイルを用いてコンテキストを与えることができる。AIエージェントを育てるという世界観。
育成する上で、このリポジトリではこういうコードで、あっちのリポジトリではここが違って、、、と別々にやっていては大変。全社で最強のエージェントを育てたい。人間と違ってAIエージェントは無限に複製可能なので、その適用可能範囲は広ければ広いほどよい。
そのためには、あらゆるものを標準化して、コンテキストの分断を回避する必要がある。多少冗長でも、AIが解釈しやすいシンプルなものになっているとよいだろう。
また、単に標準が決まっているだけでなく、既存資産のコードベースが高いレベルでそれに準拠している必要もありそう。生成AIは「超優秀なコピペプログラマー」のような感じで、既存コードが標準に準拠していなかったり、品質が低かったりすると、割れ窓的に生成AIの出力もそうなる。どこもレガシーを抱えているはずで、その負債は生成AI時代にはより大きくなる。割れ窓塞ぎをどこまでやり切れるかで差がつくだろう。
標準化の副次的な効果として、上述した静的解析への投資も集中させられるだろう。自動テストの作成も一定任せられそう。
ただし、標準化は一般にはイノベーションとトレードオフの関係にある。特に変化の激しい生成AI周辺において、標準を陳腐化させずにアップデートし続けるのはチャレンジングだと思う。標準化しないところはそれはそれで見極め、代わりに情報を明文化して蓄積する必要があるだろう。
エージェントのアクションを認可・検証・監査する
色々なところで言われているように、これからはどんどんAIエージェントがアクションを代行するようになる。開発系エージェントだと既に各種コマンドの実行を代行しているし、それ以外だと飲食店の予約などが考えられる。AIエージェントが様々なAPIを叩くようになるだろう。
ここで、他人名義で予約されたら困る。「絶対にコタニユウク名義で予約してください」とプロンプトに入れれば良いだろうか。もちろんそんなのは容易にハックされるのでNGで、APIに対して厳格に認可を設定することが極めて重要になる。
今はぶっちゃけ、「原理的にはできちゃうけど呼び出し側の実装で気をつけている」ところもあるんじゃないかな。生成AIは原理的にできることはやっちゃうので、それは通用しなくなる。
さらに言うと、ランタイムで認可が効いていれば最低限は良いが、エージェントがAPIを呼んでみて、弾かれて、再度プランニング、というのは効率が悪い。できれば、事前にできることをできないことをエージェントに伝えたい。そのためには、API側が認可について宣言的に公開するプロトコルが必要そう。あるいはPDP的なものがその役割を担うか。この辺りは生煮えなのでもっと考えたい。
また、DLP(Data Loss Prevention)的な検証の仕組みも重要である。極端な例を挙げると、個人情報APIとツイートAPIを呼べるAIエージェントがいたときに、個人情報を勝手にツイートしないことをAIエージェントは保証できない。代わりに人間が承認するか、何らかの手段で機械的に検知しなければならない。なるべく人間の手から離れてほしいので機械的にやりたいところではあるが、既存のDLP技術で対応できるかはまだ考えきれていない。どうだろう。
このようにブラックボックスな生成AIにアクションを任せるからには監査ログも必要。サービス運用のための監査もあるけど、ユーザーにもどういうアクションが実行されたか伝える必要がある。
普通のソフトウェアの監査ログは、ソースコードを紐づけてログの発生理由を記録することが多いけど、生成AI時代にその"why"の部分をどのように扱うべきかは難しいなと思う。
探索的な分析のために生データを持つ
生成AI時代においては、データ分析のあり方も大きく変わると考えている。
今までは、何らかの仮説を立てて、それをデータで確認していた。「クリック率は年代で変わるだろう」という仮説のもと、年代別で集計して確認するような具合だ。
生成AIでは、生データを渡して「クリック率が高いのはどういう属性の人？」と聞けば「広告から流入してXXを閲覧したことのある男性が高い傾向にあります」と返ってくる。仮説を伴わない探索的なデータ分析ができるということ。もちろん信頼性は低いので、古典的なデータ分析によるバリデーションは必要だけど。
この探索的分析では、我々が想像もつかないような因果を生成AIが導き出してくれる。例えば、実はクリック率はユーザー属性ではなくシステムメトリクスと相関していた、みたいなこともあり得る。そのため、取捨選択せずにできるだけ多くの情報を生成AIに与えることが重要だろう。
できるだけ多くの情報とはつまり、生データということ。今までは利用しているSaaSの裏に生データが隠れていても、我々の仮説を検証するのに十分なインタフェースをSaaSが提供していればよかった。しかしこれからは、100%の情報量を生成AIに与えるため、生データが欲しい。AIエージェントがSaaSのAPIを叩くのでも良いけど、どうしても情報量は落ちそう。
SaaS事業者は囲っているデータをMOATとしてエージェントやAPIを売り始めるだろうから、諸々を内製化する価値は上がると思う。
おわりに
色々考えているけどまだまだ全部生煮えで、ぜひみなさんの考えも聞かせてほしい。僕も考え続けていきたい。
そして、こういうことを一緒にウンウンと考えて喧喧諤諤と議論しながら生成AI時代のプラットフォームを作るプラットフォームエンジニアを募集していますのでよろしくお願いします。DMください。