AIコード生成のコストは、「行動に意味を持たせる」設計の工夫で30倍変わる

AIにコードを書かせる開発は、すでに普通の営みになってきました。次に問われているのは、どれだけ任せられるかではなく、任せた作業をあとから読める形で残せるかです。

今回紹介する設計アプローチは、コードを単なる関数やファイルではなく、「意味のある行動」の単位で組み直します。

実験では、仕事の切り方だけで30倍以上の差が生まれる結果になりました。以下で詳しく見ていきます。

AIに任せるほど作業の意味が見えにくくなる

AIエージェントは、人間が画面を見ていない間にもファイルを編集し、コードを実行し、実験環境を操作します。便利である一方、そこで何が起きたのかを知る手がかりは、ほとんどの場合、エージェント自身が残したログに限られます。通常のソフトウェアなら、画面上の操作や状態変化を人間が直接追えます。しかし自律的に動くエージェントでは、ログが実質的な観察窓になります。

問題は、記録の量ではありません。ツール呼び出し、モデルの応答、長い散文の説明が残っていても、ある変更が事前の見立てに沿ったものなのか、あとから都合よく説明されたものなのかは判別しにくいからです。詳しい記録があるのに、肝心の意味が読めない。ここに、AIエージェント時代の開発管理の難しさがあります。

コード側にも同じ断絶があります。画面上では単純な操作に見えても、実装を追うと非同期処理、ルーティング、イベント、間接参照が絡み合い、どの部分がどの振る舞いを担っているのか見えなくなることがあります。重要なのは、コードが細かく分かれていることではありません。そのまとまりが、人間にもAIにも「何のための単位か」と読めることです。

小さく分けるだけではAIに伝わらない

従来の開発では、関数、クラス、型、サービスといった技術的な構造を先につくり、そこに意味を載せていくことが多くあります。しかしAIにコードを書かせるとき、この順番は不利に働きます。モデルは長い文脈を読めますが、文脈が広がるほど、どこを変えるべきか、何を守るべきか、どの変更が本質なのかを見失いやすくなります。

そこで重要になるのが、先に意味を決め、その意味に構造を割り当てる発想です。たとえば「仮説を立てる」「実験を実行する」「結果を測定する」「変更をコミットする」といった行動を、それぞれ独立した単位として扱います。ここでいう意味の単位とは、単なる小さなファイルや関数ではなく、ひとつの関心事だけを担い、それだけで目的が説明できるまとまりです。

この設計では、各モジュールが互いを直接参照し合わないようにします。連携は、外側に置かれたルールが担います。モジュール同士が密につながっていなければ、AIはひとつの単位を実装するときに、リポジトリ全体を読む必要がありません。必要なのは、その単位の仕様と、全体で共有される前提だけです。

意味の単位で組むとAI生成は安く安定する

意味の単位で分ける価値は、設計思想として美しいことではありません。AIに渡す仕事の形が変わり、生成コスト、並列化、保守性、権限管理に実利が出ることにあります。特に重要なのは、次の四つです。

文脈が小さくなり生成コストが下がる

LLMによるコード生成では、文脈は燃料のようなものです。多く読ませれば柔軟に見えますが、そのぶん費用が増え、誤った関連づけも起きやすくなります。実験では、文脈を適切に管理して意味の単位をひとつ実装した場合、生成コストは0.09ドル未満でした。一方で、同じような作業をリポジトリ全体にアクセスできる商用エージェントへ任せた場合、3ドルを超えるケースがありました。単純に比べると、30倍以上の開きです。

モジュールが独立し並列生成しやすくなる

意味の単位が互いに独立していれば、AIによる実装は同時並行で進められます。あるモジュールを生成するために別のモジュールの内部を読む必要がないため、複数の生成タスクを分けて走らせられるからです。連携部分をつくるときも、必要なのは各モジュールの宣言や入出力の取り決めであり、内部実装の詳細ではありません。

変更の波及範囲を狭くできる

独立した単位であれば、ひとつの変更が予想外の場所へ波及しにくくなります。開発者にとってはレビューの範囲が狭まり、AIにとっては余計な文脈を読まなくて済みます。結果として、人間は変更の意味を追いやすくなり、AIは与えられた範囲で安定して出力しやすくなります。ある大学の演習では、この方式で80を超える個人課題と20のチーム課題が一学期のうちに仕上がっています。

丸投げによるエージェント負債を避けやすくなる

リポジトリ全体を自由に動ける商用エージェントへ任せると、短期的には便利に見えます。しかし観察された例では、使用量の上限にすぐ達して作業が止まったり、本来触るべきではない基盤コードを書き換えたりする挙動がありました。こうした書き換えは正当な修正ではなく、本来はモジュール側で素直に直せる問題でした。判断を外に預けるほど、人間側の理解、戦略、意思決定の力が失われる。この複利的なコストが、エージェント負債です。

エージェントの行動は名前つきで管理する

意味の単位は、コード生成だけでなく、自律エージェントの説明責任にも効きます。エージェントが行ってよい活動と、それを許可する条件を、短い文書として書き下します。ここでは、それを行動規範と呼びます。行動規範があると、エージェントは名前のついた行動を通してだけ動きます。

行動規範はログを証拠に変える

行動規範があると、「仮説を立てる」「変更を適用する」「実験を実行する」「結果を記録する」「コミットする」といった行動が、同じ語彙でログに残ります。あとから「何が起きたか」と「何があれば正当だったか」を並べて読めるため、ログは散文の説明ではなく、検証可能な証拠に近づきます。

仮説つきコミットは後付けの説明を防ぐ

実験的なコーディングエージェントでは、変更をコミットしてよいのは、その変更が事前に立てた仮説に紐づいている場合だけにする、という制約が使えます。エージェントは作業コピーに変更を加えたり、実験を走らせたりできます。しかし、コミットという影響の大きい行動へ進むには、その変更がどの仮説を検証するためのものかを示さなければなりません。

型付きログは検索できる記憶になる

長時間動くエージェントは、以前に試した設定をもう一度試し、すでに得た結果を忘れ、似たような失敗を繰り返すことがあります。この問題は文脈容量の不足として扱われがちですが、散文のログが意図で検索しにくいことも大きな原因です。行動と事実が型付きで記録されていれば、過去に試した仮説、失敗した実験、測定結果と合わなかった説明を、作業の構造に沿って取り出せます。

トレース再生で現場の判断を評価できる

型付きの行動ログがあれば、過去の実行の途中までを取り出し、そこで別のモデルなら次に何をするかを比較できます。通常の評価では、あらかじめ用意されたベンチマークで正解にどれだけ近づけるかを測ります。しかし実務で知りたいのは、複雑な途中経過の中で、どの判断を選ぶかです。評価対象は、代理課題から実際の仕事の分岐点へ近づきます。

複数エージェントでも共通語彙で協調できる

エージェントが複数になると、メッセージのやり取りだけでは、どの判断がどの条件で行われたのかが埋もれがちです。共通の行動規範があれば、あるエージェントが仮説を立て、別のエージェントが検証し、さらに別のエージェントが結果を統合する場合でも、その受け渡しは名前のついた行動の連鎖として残ります。協調は会話の積み重ねではなく、構造化された作業の記録になります。

小規模実験は成果と限界の両方を示した

この行動規範の考え方は、三つの自律研究ループで試されています。言語モデルの訓練スクリプトを編集して検証ロスを下げる作業、数値シミュレーションの実行時間短縮を狙う作業、半導体デバイスを試作前にシミュレーションで設計するTCADの並列作業です。TCADは、半導体デバイスの設計や試作前検証に使われるシミュレーション技術を指します。

注目したいのは、説明責任を持たせても成果が犠牲にならなかった点です。むしろ、型付きのトレースは、本物の成果と失敗した説明を切り分けました。数値シミュレーションでは、実測では速くなっているのに、その理由として示された説明が測定結果と合わない場面が記録から見えました。言語モデル訓練では、同じような設定を繰り返す「記憶なき探索」も明らかになりました。

ただし、結論は慎重に扱う必要があります。実証の規模は大きくなく、行動規範の内容もそれぞれの領域に合わせて設計されています。あらゆる開発チームや自律エージェントにそのまま適用できる万能策ではありません。見えているのは、振る舞いを名前のついた行動として記録するという一点が、複数の異なる作業に共通して使えそうだという見通しです。

AIに渡す仕事をどの意味の単位に分けるか

この考え方を採り入れるために、最初から大規模な仕組みをつくる必要はありません。目安になるのは、次の四つです。

• ひとつの単位が、ひとつの関心事だけを担当している
• その単位の仕様だけを読めば、AIが実装に着手できる
• 他の単位の内部実装を読まなくても、入出力と連携条件がわかる
• ログに残す行動名と、コード上の振る舞いの名前が一致している

次に、エージェントが行ってよい行動を短く定義します。「調査する」「仮説を立てる」「変更を適用する」「実験する」「結果を記録する」「コミットする」といった単位です。そして、各行動に進む条件を決めます。特にコミットや本番反映のように影響が大きい行動には、事前の仮説や測定結果との紐づけを求めるべきです。

ここでの目的は、AIを縛って使いにくくすることではありません。むしろ、AIが自由に動ける範囲を明確にし、任せられる仕事を増やすことです。意味の単位と行動規範があれば、人間はすべての操作を監視しなくても、重要な判断点をあとから検証できます。AI活用の焦点は、作業量を減らすことから、任せた作業を信頼できる形にすることへ移ります。

まとめ

AIにコードを書かせる時代に重要なのは、どれだけ多くの作業を任せられるかだけではありません。任せた作業を、あとから意味のある形で読めるかどうかです。

コードを意味の単位に分ければ、AIが読む文脈は小さくなり、生成コストは下がり、並列化もしやすくなります。エージェントに行動規範を与えれば、ログは散文の説明ではなく、検証可能な行動の記録になります。事前の仮説とコミットを結びつければ、あとから取り繕う正当化も減らせます。

開発者の価値は、コードを一行ずつ書く力だけでは測れなくなります。AIに渡す仕事をどの意味の単位に分け、どの行動を許し、どの記録を残させるか。コード生成の安さと正確さは、モデル選びだけで決まりません。AIが迷わず働けるように、仕事の意味を先に設計できるかどうかで決まります。

本記事の関連研究