AIエージェントの自己評価はどこまで信用できる？MarketBenchで見る成功確率とtoken見積もりのズレ
MarketBenchをもとに、AIエージェントの成功確率、token usage、完了見込みの自己申告をログ・テスト・差分で補正する運用を整理します。
公開 2026.06.27 / 更新 2026.08.21
この記事のポイント
- MarketBench v1は、自己申告の成功確率・token使用量と実測、auction、scaffoldを分けて評価する
- Calibration表は93タスク、方法説明のPhase Iは693タスク・558 model-task rows、共通scaffoldは50タスクとして読む
- CodexやClaude Codeの自己評価は完了証拠ではなく、diff・test・実使用量・時間・reviewで校正する
結論：AIエージェントの自己評価は、実測ログと校正で補正する
MarketBenchは、AIエージェントが自分の成功確率とtoken使用量を事前に見積もれるかを、SWE-bench Liteのソフトウェア工学タスクで調べた研究です。CodexやClaude Codeの「できます」「この量で終わります」という申告は、計画の材料にはなりますが、完了の証拠ではありません。実務では、実行結果、テスト、差分、時間、token、レビューで補正します。
MarketBenchが実際に評価するもの
MarketBenchは、通常のベンチマークのように最終pass率だけを見るのではなく、タスクを割り当てる前のp_successとestimated_tokens_totalを、実際のpass/failとrealized tokensに照合します。その申告を入札・reserve-price auctionへ機械的に変換し、完全な情報を持つoracleとの差も見ます。
| 論文内の範囲 | 対象 | 見るもの |
|---|---|---|
| Phase Iの方法説明 | SWE-bench Lite 693タスク、6モデル、558 model-task rows | 自己評価を収集する全体の方法範囲 |
| Calibration表1 | 93タスク | mean p_success、realized pass rate、Brier skill、推定・実測token |
| Reserve-price auction | Calibrationと同じ93タスク | 自己申告から作ったbidとoracleのprofit・allocation差 |
| 共通scaffold | 6モデルが試した50タスク | market、solo、external scaffold、Codex diagnosticの実行環境差 |
主な結果：成功率よりも、自己申告の幅とtoken予測を見る
| 観察 | 論文の数値 | 実務での読み方 |
|---|---|---|
| 実現pass rate | 6モデルで75.3%〜80.6% | 平均的な成功率の幅だけではtaskごとの判断力を示さない |
| 平均の自己申告p_success | 61.4%〜92.9% | 同じような実現率でも自信の出し方が大きく異なる |
| token見積もり | 例：Gemini 3 Pro Previewは推定1,801、実測55,969 tokens | 事前見積もりを課金上限や時間上限の根拠にしない |
| 履歴情報の追加 | mean Brier 0.1835→0.1693、ECE 0.1065→0.0616 | 過去実績を見せると改善するが、完全な情報との差は残る |
| 同一scaffoldの比較 | market 29/50、solo GPT-5.2 24/50 | worker poolとretry条件が違うため、単純なモデル順位にしない |
MarketBenchの表では、Claude Opus 4.5とClaude Sonnet 4.5だけがnaive base-rateに対してpositive Brier skillでした。また、50タスクのexternal scaffoldではGPT-5.2が37/50、oracleが42/50でしたが、live scaffoldのGPT-5.2 soloは24/50です。shell、test feedback、multi-turn revision、structured editingの有無で結果が変わるため、モデル名だけを取り出してCodexやClaude Codeの現行性能へ一般化しません。
Codex・Claude Codeへ読み替える観測項目
| エージェントの申告 | 照合する実測 | レビューで残す判断 |
|---|---|---|
| 成功確率が高い | 同じtask群でのpass、再実行、失敗条件 | 本番やpushを自信の数値だけで許可しない |
| tokenは少ない | input・outputを含む実使用量、task時間、retry | 上限、停止条件、予算を保守的に置く |
| 完了した | 生成物、全diff、test、静的HTML、未確認事項 | 完了報告と成果物を同一視しない |
| このagentへ任せる | modelだけでなくscaffold、tool、permission、context | 環境とtaskを固定して比較する |
自己評価を運用へ入れる5段階
- 事前に成功条件、失敗条件、想定時間、token上限を申告させる
- 同じ種類の小さなtaskを複数回実行し、申告と実測を並べる
- 成功率だけでなく、差分サイズ、retry、review修正、時間、実使用量を記録する
- task種別・repo・tool・permissionごとに校正を分け、全作業へ平均値を流用しない
- 過去実績が悪い場合は、model変更だけでなくcontext、scaffold、test feedback、停止条件を見直す
この論文から言えること・言えないこと
- 言えること：このv1の実験では、6モデルの成功確率・token使用量の自己評価が実測とズレ、market allocationがfull-information oracleから離れた
- 言えること：過去実績をpromptへ与える介入はcalibrationを改善したが、差を完全には埋めなかった
- 言えないこと：現行の全AIエージェント、全repo、全model、全scaffoldで同じ数値になるという保証
- 言えないこと：MarketBenchの数値だけでCodexやClaude Codeの本番可否・安全性・料金を決めること
- 注意点：tokenは論文内のmodel-specific blended pricingと実験設定に基づくため、手元の請求額へそのまま換算しない
MarketBenchの2026年8月FAQ
MarketBenchの93タスクと693タスクはどちらが正しいですか？
どちらも論文内の別の範囲を指します。方法説明ではPhase Iを693 SWE-bench Lite tasks・558 model-task rowsとして説明し、Calibrationの表1とauctionは93タスクを対象にしています。数字を一つへ混ぜません。
MarketBenchは現在のCodexの性能を測った論文ですか？
そのままではありません。v1の研究は特定時点の6モデル、SWE-bench Lite、外部・live scaffoldを使った評価です。Codexに使う場合は、自己申告を実測で補正する運用原則へ読み替えます。
AIが成功確率を出す意味はありますか？
ありますが、完了保証ではありません。過去の同種taskで校正し、成功条件・失敗条件・実測pass・retry・reviewを一緒に見ます。
token見積もりは料金計算に使えますか？
参考値にはできますが、論文のmodel-specific blended pricingと手元のplan・API料金は別です。実使用量、retry、task時間、上限で管理します。
scaffoldが違うと何が変わりますか？
shell、test feedback、multi-turn revision、structured editing、時間上限、retry方法が変わります。同じmodel名でも実行環境が違えば結果を直接比較できません。
個人開発で最初に何を記録すべきですか？
task種別、使用model、context、permission、開始時の見積もり、実時間、実使用量、差分、test、失敗と再実行、未確認事項を残します。
関連記事
- Dialogue SWE-Benchとは？対話型コーディングエージェント評価が重要な理由
実際のAIコーディング支援は、完全自律ではなく対話で進みます。Dialogue SWE-Benchから、聞き返しと確認を評価する見方を整理します。
- Codexの完了報告はどこを見る？build・check・diff・本番確認URLの読み方
Codexが「完了」と言ったあと、何を見るべきか。build/checkの成功、未確認事項、diff、upload、commit hash、本番確認URLを順番に読みます。
- Codexのフルアクセスは危険？許可していい作業・止めるべき作業
Codexのフルアクセスは、何でも任せてよい設定ではありません。許可してよい作業、止めるべき作業、.envやAPIキーの扱いを先に分けておくための安全ガイドです。