🤖 AI

BUILD-AND-FIND: An Effort-Aware Protocol for Evaluating Agent-Managed Codebases

本論文では、エージェントが生成したコードベースの品質を評価する、ビルドと発見を考慮した評価プロトコル「BUILD-AND-FIND」を導入するものであり、これは単に行動の正しさを測定するだけでなく、下流のエージェントが元の設計意図や仕様を回復するために必要な正確性と検査労力を測定するものである。

原著者： Jhen-Ke Lin

公開日 2026-05-08

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Jhen-Ke Lin

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

以下は、論文「BUILD-AND-FIND」を平易な言葉と日常的な比喩を用いて解説したものです。

大きなアイデア：答えだけでなく、その「痕跡」が重要

秘密のレシピを渡されたシェフ（AI エージェント）に、複雑な料理を作らせると想像してください。

従来の方法： 料理を味見する。味が良ければ、シェフは合格となる。
新たな問題： もしシェフが美味しい料理を作ったとしても、秘密の材料を施錠された箱に隠したり、レシピを不可視インクで書いたり、台所を散らかったままにしたりしたらどうなるか？後から別のシェフ（別の AI）が来て、その料理を味見し、どのように作られたかを突き止めて、焦げた部分を修正したり塩を加えたりする必要がある。最初のシェフが明確な手がかりを残さなかった場合、料理が美味しくても、2 人目のシェフは失敗するかもしれない。

この論文は、AI プログラマーをテストする新しい方法「BUILD-AND-FIND」を紹介する。コードが「動くか（味がするか）」だけをチェックするのではなく、次にそのコードを扱う人（または AI）にとって読みやすく理解しやすいかをチェックする。

2 つの役割：ビルダーとファインダー

研究者は、2 つの明確な役割を持つゲームを設定した。

ビルダー（シェフ）：
- 隠された「仕様（秘密のレシピ）」を与えられる。
- その指示に基づき、完全なソフトウェアプロジェクト（台所と料理）を構築する。
- すぐに誰かが自分の作業を見るわけではないと知っており、単に動くようにすればよい。
ファインダー（検査員）：
- 完成したコードのみ（台所と料理）を与えられる。元の秘密のレシピを見ることは許されない。
- 設計選択に関する多肢選択問題のリストを与えられる（例：「シェフはこの特定のオーブンを選んだのはなぜか？」または「塩はどこに保管されているか？」）。
- コードを調べ、証拠を見つけ、問題を正しく解答する。

スコアカード：精度と労力

この論文は主に 2 つのことを測定する。

正解できたか？（精度）
- ファインダーはコードを見るだけで正解を導き出せるか？
- 比喩： 検査員は隠されたスパイスの瓶をうまく見つけられたか？
どれほど探さなければならなかったか？（検査労力）
- これがこの論文の大きな革新点である。2 人のビルダーがどちらもファインダーに正解させるコードを作った場合、どちらの方が推測しやすかったか？
- 研究者は「労力」を、ファインダーが読み、または検索しなければならなかったコードのバイト数で測定する。
- 比喩： シェフ A が塩の瓶をカウンターの上に置き、シェフ B がそれを複雑なコードで開ける必要がある施錠された金庫の中に隠したとしよう。両方のシェフが食べられる料理を作った。しかし、シェフ A の方が次の人にとって働きやすいようにした。この論文は、塩をカウンターの上に置いておくシェフを評価する。

なぜこれが重要なのか

この論文は、将来 AI エージェントがチームで働くようになるだろうと主張する。ある AI がプログラムを書き、別の AI が後からそれを修正または更新する必要がある。

もし最初の AI が「正しい」が乱雑で混乱を招くコードを書けば、2 人目の AI は苦労する。
BUILD-AND-FINDは、コードが実際に動くかどうかとは別に、AI のコードがどれほど「読みやすい」か「伝達性があるか」を測定できることを証明する。

結果（彼らが発見したもの）

研究者は、ミニデータベースの構築と小さな Web サーバーの構築という 2 種類のタスクにおいて、GPT-5 や Claude Opus など複数の強力な AI モデルでこれをテストした。

「高事前確率」の問題： 彼らが問うた質問は、経験豊富なエンジニアが通常、暗記しているようなものだった（例：「データベースは通常、書き込む前にログを保存する」）。AI は賢いので、コードを読まなくても一般的な知識を使って正解を推測できた。
解決策： 全員が正解してしまったため、研究者は単に「正解数」を数えることはできなかった。代わりに、AI がどれほど読まなければならなかったかに注目した。
- 一部の AI モデルは、答えが明白で簡単に見つかるコードを書いた（低労力）。
- 他のモデルは、答えがファイルの奥深くに埋もれており、ファインダーがそれを見つけるために多くのコードを読まなければならなかった（高労力）。
勝者： 答えを見つけるために最も少ない読書量で済ませたコードを生成したモデルが、設計選択を「伝達する」能力が最も優れていると見なされた。

セーフティネット（統制）

AI が単に不正をしたり、推測したりしないことを確認するため、研究者は安全チェックを追加した。

質問のみのテスト： コードを見せずにファインダーに質問を投げかけた。ここで AI が正解した場合、それは一般的な知識に基づいた推測に過ぎなかった。
仕様のみのテスト： ファインダーに秘密のレシピを見せ、コードは見せなかった。これでレシピが明確であることを証明した。
「ゲート」： 研究者は、ファインダーが実際に正解した場合にのみ「労力」スコアをカウントした。ファインダーが答えを全く見つけられなかった場合、どれだけ読む必要が少なかろうと、そのコードは失敗とみなされた。

まとめ

BUILD-AND-FINDは、AI プログラマーに対する新しいテストである。それはこう問う：「もしあなたがこのコードを書いたなら、別の AI はあなたがなぜその選択をしたのかを簡単に理解できるだろうか？」

「コードは動くか？」という問いから、「コードは未来への優れた伝達手段か？」という問いへと移行する。最高の AI とは、単に正しいものを作るものではなく、次の人が引き継いで働き続けることを容易にする方法で物を作るものである。

技術的サマリー：BUILD-AND-FIND

問題定義

現在のコーディングエージェントベンチマークは、主に行動の正しさ（例えば、単体テストの通過）を評価しています。しかし、エージェントが関数合成からリポジトリレベルのエンジニアリングへと移行するにつれ、生成されたコードベースは中間成果物としてますます重要な役割を果たすようになっています。つまり、あるエージェントがリポジトリを作成し、後続のエージェントがそれを調査、監査、または拡張する必要があります。この文脈において、リポジトリは単なるタスクへの回答ではなく、コミュニケーションの成果物です。

本論文は、あるギャップを特定しています。リポジトリは可視的な行動テストをパスする一方で、その行動の背後にある設計意図や選択を明確に露呈することに失敗する可能性があります。生成されたリポジトリが意図を隠蔽する場合、コードが正しく機能していたとしても、下流のエージェントに追加の調査負担を課すことになります。既存のベンチマークは、変更が試みられる前に、意図された決定がその成果物自体から回復可能かどうかを測定していません。

手法：BUILD-AND-FIND プロトコル

著者は、成果物証拠に基づく回復を評価するために設計されたプロトコル、BUILD-AND-FINDを提案します。このアプローチは、コードを構築する能力と、そのコードから意図を回復する能力を分離します。

主要な役割

ビルダー（Builder）: 隠された仕様（意図された行動と設計選択を定義）を受け取り、自己完結型のコードベースを生成します。
ファインダー（Finder）: 生成されたコードベースと、仕様を追跡した多肢選択問題バンクのみを受け取ります。隠された仕様はアクセス不可です。ファインダーはファイルを検査し、ツール呼び出しを行い、成果物のみに基づいて質問に回答しなければなりません。

評価レイヤー

このプロトコルは、3 つの明確な評価レイヤーを定義します。

行動の正しさ: コードはテストをパスするか？（標準的なベンチマークの焦点）。
成果物側の意図回復可能性: 下流のエージェントは、成果物のみから意図された行動と設計選択を回復できるか？（BUILD-AND-FIND の焦点）。
下流の変更成功: 後続のエージェントはリポジトリを安全に変更できるか？（将来の課題）。

指標と統制

このプロトコルは、厳格な解釈の階層を持つ 4 つの主要指標を報告します。

回復精度: 問題バンクにおける完全一致精度。
安定性/再現性: 反復試行における回答の一貫性。
実装カバレッジ: 成果物に実際に実装された仕様の主張の割合（未実装のゴールド主張に対してファインダーが罰せられないよう監査されます）。
調査労力: 新規エージェント調査バイト数（システムプロンプトや転送オーバーヘッドを除く、ツール呼び出しを通じて取得された新しいバイト数）で測定されます。

重要な制約: 調査労力は、回復精度と安定性のゲートを通過した後にのみ、成果物の可読性の代理指標として解釈されます。回復が失敗した場合、労力は無意味です。

統制:

質問のみ: ファインダーは質問のみを目にします（一般的なエンジニアリングの事前知識を測定）。
仕様のみ: ファインダーは仕様を目にします（回答可能性の上限を測定）。
コンパイル失敗: コンパイルに失敗した成果物は、ストレス診断のために保持されます。
証拠監査: 事後チェックにより、正しい回答が事前知識に依存するのではなく、特定の成果物証拠（ソースファイル、設定など）を引用しているかを確認します。

主要な貢献

評価対象: 行動の正しさと下流の変更の間に、成果物証拠に基づく回復という独自のレイヤーを定義します。
ビルダー - ファインダープロトコル: ビルダーが隠された仕様をコードにエンコードし、ファインダーが仕様を見ずにそれをデコードしようとする、役割分担型のフレームワーク。
測定契約: 精度（妥当性）と労力（可読性）を分離する厳格な報告基準。回復が信頼できる場合にのみ労力を分析することを保証します。
較正と公開: ハarness、タスク（scratch_minidb、scratch_nanoweb）、生成された成果物、標準テーブル、および証拠監査を含む包括的な公開。ビルダーとファインダーの親和性および低事前知識感度に関する診断を含みます。

実証結果

本研究は、2 つのタスクファミリーにわたって 12 のエージェント構成（GPT-5.5、Opus 4.7、Sonnet 4.6、MiMo 変種を含む）を評価しました。

高回復領域: 公開された高事前知識タスクパックにおいて、回復精度は飽和に近い値を示しています（例えば、成果物条件付き実行では約 98.9%、質問のみの場合 94.5%）。精度が高いため、これは主にゲートとして機能し、識別信号としては主に機能しません。
識別子としての調査労力: 回復ゲートを通過した後、条件付き調査労力が成果物の可読性を比較するための主要指標となります。
- GPT-5.5は、高労力パネルで相対労力スコア（ $R_b$ ）が 1.033 であり、最も低い調査労力（高い可読性）を示しました。
- MiMo変種は、一般的に高い調査労力を必要としました。
- Claude Sonnet 4.6およびOpus 4.7は、推論労力の設定（高 vs 低）に基づいてある程度のばらつきを示しつつ、中間的な労力レベルを示しました。
親和性: 本研究は、可読性が読者依存性を持つ可能性があることを発見しました。同じファミリーのビルダー - ファインダーペア（例：OpenAI ビルダー + OpenAI ファインダー）は、クロスファミリーのペアよりも意図を回復しやすいことを示唆する、正の親和性残差を示しました。
証拠監査: 72 の正解のサンプルにおいて、65 は引用された成果物証拠（主にソースファイル）によって「支持」されており、この設定では高い精度が一般的に成果物に基づく推論と相関していることを確認しました。

意義と主張

本論文は、BUILD-AND-FIND がエージェント管理型コードベースのための必要な評価契約を確立すると主張しています。その意義は以下の点にあります。

焦点の転換: 「機能するか？」から「別のエージェントにとって理解可能か？」へと焦点を移すこと。
可読性の代理指標: 回復が安定していることを前提に、調査労力を設計意図をどの程度よく成果物が伝達するかという測定可能な代理指標として扱うこと。
関心の分離: 実装能力と意図回復能力を明示的に分離し、エージェントのパフォーマンスのよりニュアンスのある分析を可能にすること。
監査可能なフレームワーク: 一般的な事前知識を成果物条件付き回復から分離する、再現可能で監査準備が整ったインフラを提供し、ベンチマークが暗記や一般的なエンジニアリング知識だけで解決されることを防ぐこと。

著者は、現在の主張が公開されたパネルとタスクファミリーに限定されていることを謙虚に指摘しています。彼らは、このベンチマークがランタイムの正しさ、セキュリティ、または人間の保守性を測定するものではなく、生成されたリポジトリを外部メモリおよびコミュニケーション媒体として使用するエージェントの特定の能力を測定するものであることを強調しています。