What Context Does a Coding Agent Actually Need to Act?
本論文は、コードを編集するコーディングエージェントにとって、不可欠なコンテキストは修正対象の特定のファイルに厳密に限定されており、自然言語による要約や周囲のファイル内容は、ソースコード自体と比較して問題解決への寄与が無視できるほど小さいこと、そしてまた、非決定的なAPI推論によってベンチマーク結果に生じる重大なノイズフロアが存在することを明らかにしている。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
巨大な100階建ての超高層ビルで、蛇口の水漏れを修理しようとしている場面を想像してみてください。あなたは、レンチを見つけるためにビルの設計図全体や、食堂のメニュー、あるいはセキュリティログを読み解く必要はありません。ただ、どのパイプが滴っているのかを正確に特定し、その周辺の状況さえ分かればいいのです。
これは、「コーディングエージェント（ソフトウェアを記述・修正するAIボット）」に関する新しい研究が示した、驚くべき教訓です。長い間、テック業界では、これらのボットが仕事を遂行するためには、プロジェクトの（時には数百万行に及ぶ）コードベース全体をその「脳」に飲み込ませる必要があると考えられてきました。「コンテキスト（文脈）は多ければ多いほど良い」という考え方です。
しかし、この論文はこう告げています。**「脳に詰め込みすぎるのはやめなさい」**と。実際、コードを修正するという行為においては、AIは修正しようとしている特定の行以外、ほとんど何も必要としないことが判明したのです。
「探索」と「実行」
研究者たちは、この問題を2つのパートに分けました。
- 探索 (The Find): 壊れたコードの場所を特定すること。
- 実行 (The Act): 場所が見つかった後、実際に修正すること。
これをテストするために、彼らは「魔法の地図（オラクル）」を使用して、AIに壊れたコードがどこにあるかを正確に伝えました。これにより、AIはどこを探すべきか迷う必要がなくなり、単に「どうやって直すか」に集中できるようになりました。そして、AIにそのコードの異なる「視点（ビュー）」を与え、何が最も効果的であるかを検証しました。
大きな失望：要約は機能しない
一つの有力なアイデアがありました。「コードの自然言語による要約（本の紹介文のようなもの）をAIに与えればいいのではないか」というものです。
- テスト: 彼らは、AIに対し、ソースコード全文を用いる場合と、非常に優秀なAI（フロンティアモデル）によって書かれた要約を用いる場合で、コードの挙動に関する難解な質問に答えさせました。
- 結果: ソースコード全文を用いた場合は、45問中27問に正解しました。一方、要約を用いた場合は、わずか4問しか正解できませんでした。
- ひねり: 要約を書いたのが世界最高峰のAIであっても、極めて小さな基本モデルであっても、結果は変わりませんでした。どちらも等しく失敗したのです。問題は書き手の能力ではなく、「フォーマット」にありました。要約には、バグを修正するために必要な具体的な「挙動」の詳細を載せることができないのです。それは、車のエンジンを直そうとしているのに、車の旅行ガイドを読んでいるようなものです。ガイドブックは素晴らしいものですが、どのボルトが緩んでいるかまでは教えてくれません。
「骨格」か「全身」か
次に、AIに肉付けされた完全なコードが必要なのか、それとも「骨格」（関数名やシグネチャなどの構造）だけで十分なのかをテストしました。
- セットアップ: 70件の実世界のコーディング問題を取り上げました。あるケースではAIにファイル全文を与え、別のケースでは「骨格」（UML図やシグネチャ）のみ、あるいは「保持/破棄（keep/drop）」バージョン（不可欠な部分だけを残して残りを削除したもの）を与えました。
- 結果: 「骨格」バージョンと「保持/破棄」バージョンは、ファイル全文を与えた場合と同等の数の問題を解決しました。実際、「保持/破棄」メソッドは、ファイル全文を用いた場合（70件中19件）よりも、わずかに多い（25件）を解決しましたが、その差は偶然の範囲内と言えるほど僅かなものでした。
- コスト: ここが重要なポイントです。問題解決にフルファイルを用いた場合、AIは94,000トークン（テキストの単位）を消費しました。しかし、圧縮された「保持/破棄」メソッドを用いた場合、コストはわずか19,000トークンでした。これは、パフォーマンスを損なうことなく、3倍から3.7倍も安価に済んだことを意味します。
「ノイズ」への警告
研究者たちはまた、奇妙で重要な発見もしました。全く同じ設定で全く同じテストを実行したにもかかわらず、AIが異なる回答を出すことがあったのです。約**9%**の確率で、実行ごとに結果が逆転していました。これは、もし2つの手法の間にわずかな差（例えば2%の向上）が見られたとしても、それが真のブレイクスルーではなく、単なるランダムなノイズである可能性があることを意味しています。
結論
この論文の結論は、コードを修正するという特定のタスクにおいて、**「少ないことは、より良いことである（Less is more）」**ということです。
- 効果的な方法: 編集が必要な正確なコードの行を与え、本質的な部分だけに削ぎ落とすこと。
- 効果的でない方法: コードの要約、ファイル全体の履歴、あるいは複雑な構造図をAIに浴びせること。
- 判定: 「信号（シグナル）」はコードそのものの中に存在するのであり、コードについて語られる物語の中にあるのではありません。無駄を削ぎ落とすことで、図書館全体を読み返すことなく、たった一枚の正しいページを見つけるだけで、わずかなコストでバグを修正できるのです。
著者たちは、これは「シングルショット（AIが一度きりで試行し、再読や助けを求めることができない状況）」の修正に適用されるものであると慎重に断っています。しかし、編集という具体的かつ重要な瞬間においては、データは明白です。図書館全体は必要ありません。ただ、正しいページさえあればよいのです。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。