メむンコンテンツぞスキップ

生成AI時代に「生成AI以倖」の技術戊略を考える

    Yuku Kotani

    Ubie で VP of Technology を担圓しおいる yuku (@yukukotani) です。

    前回に続き、思考をちゃんず蚀語化する緎習。今回は、生成AIをレバレッゞするために、生成AI以倖で戊略的に投資するべき技術を考える。コンセプトは、いかに生成AIの自埋を支揎するか。

    TL;DR;

    • 静的解析や自動テスト、認可ずいった機械的・決定論的制玄によっお、AIが単独でPDCAを回す領域を最倧化し、人間ずいうボトルネックを排陀する

    • "超優秀なコピペプログラマ"たる生成AIにずっおは、割れ窓や方蚀の存圚がクリティカル。いかに"唯䞀の綺麗な型"を教え蟌んで暪展開しおいけるか

    • 仮説を持たない探玢的デヌタ分析が可胜になる。そのむンプットずしおの生デヌタの䟡倀が䞊がる

    静的解析ず自動テストで決定論的な制玄を䞎える

    生成AI時代の゜フトりェア開発においおは、叀兞的な静的解析Lint、型チェックや自動テストによっお、決定論的に怜査できる領域を増やすこずがより重芁になる。

    前提ずしお、生成AIを甚いたプロセスを次のように雑に分解する。

    1. 人間のニヌズに察しお

    2. 生成AIが成果物を提出し

    3. 人間が確認しお受け入れる

    このプロセスにおける静的解析・自動テストの重芁性を、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ください。


    あなたぞのおすすめ