仕様が曖昧なまま作らせると、最強のコーディングAIでも38.2%。ICAE-Benchが暴いた本当の弱点
「いい感じのタスク管理アプリを作って。通知も欲しい」
人間なら、ここで少し嫌な予感がします。誰に通知するのか。期限を過ぎたら毎日送るのか。削除したタスクの通知はどうするのか。ところが現在のコーディングAIは、曖昧な依頼でも勢いよく実装を始められます。勢いはあります。正解があるとは言っていません。
2026年7月23日に公開された論文ICAE-Bench: Evaluating Coding Agents as Interactive Project Buildersは、この問題を480件のリポジトリ構築タスクで測りました。12のプログラミング言語、6つのモデル、Claude CodeとOpenHandsの2基盤を使った結果、全タスクで最も高いOverall pass rateは38.2%でした。
この研究が面白いのは、「AIは質問が下手だ」で終わらないことです。質問を増やして制約を多く回収しても、成功率は単純には上がりません。一方、同じ情報を実行可能なテストとして渡すと、ある条件では37.4%から61.8%へ伸びました。
問題は、情報の不足だけではありません。回収した情報を、長い実装の途中で失わず、検証可能な形へ変える能力です。
古い評価は、完成した仕様から始まっていた
多くのコーディングベンチマークは、課題がかなり整理された状態から始まります。
- 直すべきバグが書かれている
- 対象リポジトリがある
- 期待する振る舞いがテストで決まっている
- 完了条件が比較的明確
これはパッチ生成能力を測るには適しています。しかし、実際の開発の上流はもっと湿っています。「検索を速くして」「管理画面を使いやすくして」「前と同じ感じで」という依頼から、隠れた期待を掘り起こさなければなりません。
ICAE-Benchは、完成した仕様をそのまま渡さず、短く曖昧な製品要求へ変えます。エージェントは質問し、要件を回収し、空の作業環境からリポジトリを組み立てます。
従来の「正しい仕様を正しく実装できるか」に、「正しい仕様へ近づけるか」が加わったわけです。
仕組み：正解を隠すが、採点可能性は残す
曖昧さを評価する時の難問は、正解まで曖昧になりやすいことです。自由な依頼を人間が採点すると、「この実装もありでは」という議論が始まり、ベンチマークが居酒屋になります。
ICAE-Benchは、動作する実在のオープンソースリポジトリから各タスクを作ります。
- 元リポジトリとテストがDocker内で動くことを確認する
- 完全な要求文書であるGroundPRDを作る
- 元の振る舞いを標準化したブラックボックステストへ変換する
- GroundPRDからAPI、境界条件、設計制約の一部を隠し、曖昧なFuzzy PRDを作る
- 隠した情報をUser Agent Dataへ保存する
- エージェントが質問した時だけ、該当する情報を返す
User Agentは自由に要件を発明しません。隠された正解データへ質問を対応付け、根拠のある回答を返します。これにより、「曖昧な依頼から始める現実味」と「同じ正解で採点できる再現性」を両立させています。
評価もテスト通過率だけではありません。
- Public：見えている例に対応する振る舞い
- Native：元リポジトリの隠れたテスト
- Enhanced：境界条件を追加したテスト
- Semantic、API、Design：意味、外部API、設計品質
- Structure：ファイル数、コード量、クラス、メソッドの類似
- Interaction：制約回収率、空振り回答率、質問予算の使用
「見える例だけ再現したのか」「隠れた条件まで守ったのか」「質問はできたのか」を分けて見られます。
実験：全480タスクで最高38.2%
全480タスクをClaude Code基盤で評価したTable VIでは、Overall pass rateは次の通りでした。
| モデル | Overall | Public | Native | Enhanced | |—|—:|—:|—:|—:| | Claude Opus 4.8 | 38.2% | 48.5% | 41.4% | 35.5% | | GPT-5.5 | 37.2% | 50.3% | 42.0% | 32.8% | | Gemini 3.1 Pro | 27.0% | 37.0% | 30.7% | 23.5% | | GLM-5.1 | 26.6% | 36.8% | 30.0% | 23.7% | | Claude Sonnet 4.6 | 21.8% | 29.0% | 24.1% | 19.4% | | MiniMax M2.5 | 0.8% | 1.5% | 1.2% | 0.6% |
論文の主張として重要なのは、どのモデルが一位かではありません。PublicからEnhancedへ一貫して落ちることです。
見えている例に合うコードは作れても、明示されなかった境界条件や長い統合では壊れます。また、GPT-5.5はClaude Opus 4.8より多くの制約を回収しましたが、Overallは1ポイント低い結果でした。回収した情報の量は、正しさの代理指標になりません。
モデルのランキング表として読むより、要求から検証までの配管テストとして読む方が価値があります。
質問を増やしても、成功率は単調に上がらない
「では、もっと質問させればよい」と考えたくなります。論文はGLM-5.1 think-8kで、質問予算だけを8回、16回、24回へ変えました。
- 8回：Overall 22.9%
- 16回：Overall 37.4%
- 24回：Overall 34.4%
一方、制約回収率は57.9%から71.4%へ上がりました。
つまり、24回条件は多くの制約を見つけたのに、16回条件より最終実装が悪化しました。余分な情報がノイズになった可能性、実装中に保持できなかった可能性、矛盾なく統合できなかった可能性があります。論文が直接確定した原因ではありませんが、少なくとも「質問数を増やせば解決する」という単純な処方は崩れます。
必要なのは質問力だけではなく、回答を一つの実装可能な仕様へまとめる力です。
一番効いたのは、情報量ではなく実行可能性
この論文で実務に最も効く結果はTable IXです。
GLM-5.1 think-8kに対し、Public caseの意味内容は変えず、次の2条件を比べました。
- 既定条件：質問を通してcase内容へアクセスする
- case filesあり：同じ内容を入力、期待出力、呼び出し形式を持つ実行可能ファイルとして作業空間へ置く
結果は、Overall 37.4%から61.8%でした。24.4ポイントの改善です。しかも制約回収率は63.8%から61.2%へ少し下がっています。
情報が増えたのではありません。自然言語の断片が、実行して確かめられる構造へ変わりました。
ここから、「優れたプロンプトを書けばよい」より一段具体的な教訓が得られます。
> エージェントに理解させたい要件は、説明文だけでなく、失敗できる形へ変える。
入力例、期待出力、境界条件、受け入れテストがあれば、エージェントは実装と検証を同じループへ入れられます。要求文を美しくすることより、要求を壊せるテストへ変えることが効く場面があります。
AICompanyの小さな追試案
ここからは論文の直接主張ではなく、AICompanyの実務案です。
同程度の小規模機能を20件用意し、同じコーディングエージェントへ2条件で依頼します。
条件A：質問だけ
- 曖昧な依頼を渡す
- ユーザー役へ最大16回質問できる
- 回答は会話履歴にだけ残す
条件B：質問と受け入れテスト
- 条件Aと同じ依頼、同じ回答を使う
- 回収した要件を、機械実行できる受け入れテストへ変換する
- 実装前後にテストを実行できる
測るのは、最終テスト通過率、質問数、回収制約数、手戻り回数、トークン数、実行時間です。
AICompanyの仮説は、制約回収数より受け入れテストの有無が成功率を強く分ける、です。論文のTable IXと同じ方向を予想しますが、この追試結果が出るまでは推測として扱うべきです。
運用へ入れるなら、次の順番が安全です。
- エージェントに不明点を列挙させる
- 人間または根拠付きユーザー役が回答する
- 回答を一つのRequirements Ledgerへ統合する
- 各要件へ受け入れテストを対応付ける
- 実装、テスト、差分確認を繰り返す
質問ログを増やすだけでは、会話が長くなる割に賢くならないことがあります。議事録だけ立派な会議と同じです。耳が痛い。
限界：顧客は正解データを持っていない
この研究には、はっきりした限界があります。
第一に、User Agentは人間の顧客ではありません。隠された正解データを持ち、質問を該当レコードへ結び付けます。実際の顧客は自分の欲しいものを完全には知らず、回答が矛盾し、途中で方針も変わります。
第二に、タスクは実在リポジトリから作られますが、GroundPRDの構築、曖昧化、批評評価の一部にLLMが使われています。ベンチマークの品質は、これらの生成と検証手順にも依存します。
第三に、主要な全量結果はClaude Code基盤です。OpenHandsも評価されていますが、すべての基盤、権限設定、モデル更新へ一般化できるとは限りません。
第四に、Overall pass rateはベンチマーク内の機能評価です。「このモデルは実務案件の38.2%しか作れない」と読み替えてはいけません。
第五に、公開実装はありますが、480タスクの完全再現にはDocker環境、複数のモデルAPI、ユーザー役と批評役が必要です。READMEも、50タスク実行だけで多数のモデル呼び出しが発生すると注意しています。無料の週末工作ではありません。
結論：質問できるAIより、要件を検証へ変えられるAI
ICAE-Benchは、コーディングAIの弱点を「仕様が曖昧だから」で片付けませんでした。
全480タスクで最良のOverall pass rateは38.2%。質問予算を増やし、制約回収率を上げても、成功率は単調に上がりませんでした。一方、同じ意味内容を実行可能なcase filesへ変えると、37.4%から61.8%へ伸びました。
本当に必要なのは、質問、記憶、実装、検証を一つの流れにすることです。
- 不明点を見つける
- 根拠のある回答を得る
- 回答を一貫した仕様へ統合する
- 仕様を実行可能なテストへ変える
- 実装結果を読み返し、失敗から直す
コーディングAIに渡すべきものは、長いプロンプトだけではありません。壊れた時に、どこが違うか分かる仕組みです。
一次資料
【送料無料】マクロキーパッド、ストリームコントローラーデッキゲームストリーミングショートカットキーボード、18個のプログラム可能