3行まとめ
開始コミット、制約、テスト、採点表をそろえる。
Bugfix、Feature Add、Test Repairを分けて見る。
修正品質、テスト証跡、差分の小ささ、承認回数を残す。
見るべきものは総合順位ではなく、自社タスクで安定して任せられる範囲です。
- AIコーディングエージェントを比べる前に、Bugfix、Feature Add、Test Repairを同じ開始コミット、同じ制約、同じテスト、同じ採点表で回せる小さなBenchmark Kitを作ります。
- 見るべきものは「どのAgentが最強か」ではなく、自社の典型タスクで、修正品質、テスト証跡、差分の小ささ、承認回数、再実行しやすさが安定するかです。
- 本記事では、公式Docsで確認した権限・評価・レポート設計と、Next.js + Playwrightの小さなローカル検証ログを使い、導入前に再現できる測り方へ落とします。
Xでは、Claude CodeやCodexの長時間実行、複数Agent運用、agent harnessという言葉を含む投稿が直近でも目立っていました。ただし、この記事ではXを市場関心のシグナルとしてだけ扱います。仕様、権限、レポート、評価の説明は、OpenAI、Anthropic、GitHub、SWE-bench、Playwrightの一次情報と、手元で確認できたログに寄せます。
この記事でわかること
- 1タスクを分ける
Bugfix、Feature Add、Test Repairで失敗の出方を分ける。
- 2条件を固定する
入力、権限、開始プロンプト、実行ログをそろえる。
- 3Scorecardに残す
Pass、Partial、Failだけでなく判定理由を残す。
- 4導入範囲を決める
どの作業を任せ、どこで人間が止めるかに変換する。
測れるタスクを先に作ると、導入判断の会話が具体的になります。
- AIコーディングツール比較を、感想ではなく再実行できるベンチマークに変える考え方
- Bugfix、Feature Add、Test Repairを分けてタスク定義する理由
- 同じ条件で走らせるためのディレクトリ構成、開始プロンプト、権限チェック
- Pass、Partial、Failだけで終わらせないスコアカードの作り方
- PlaywrightやCIのログを、レビュー可能な証跡として残す方法
- チーム導入前に見たい失敗条件、セキュリティ、コスト注意
比較そのものの判断軸を先に整理したい場合は、公開済みの<a href="https://ai-dev.blog.mo-gmo.com/ai-coding-loop-engineering-plan-implement-test-review/">AI Coding Loop Engineering入門</a>も近いテーマです。この記事では、その前段として「測れるタスク」を作るところに絞ります。
前提知識
SWE-benchなどは参考にしつつ、導入前の答えは自社タスクで確かめます。
ここでいうBenchmark Kitは、巨大な公開ベンチマークではありません。自分たちのリポジトリに近い小さなタスクを用意し、複数のAIコーディングエージェントで同じ条件に近づけて実行し、判断材料を残すための作業セットです。
Agent harnessは「モデル以外の実行環境」まで含めて見る
AIコーディングの結果は、モデル名だけでは決まりません。リポジトリの読み方、指示ファイル、コマンド実行、sandbox、承認、テスト、ログ、レビュー画面まで含めた実行環境で大きく変わります。
OpenAI Codexの公式Docsでは、sandbox modeとapproval policyを分けて説明しています。Codexがどこへ書けるか、ネットワークへ出られるか、いつ承認を求めるかは、プロンプトではなく実行設定の問題です。Claude Codeのmemory docsでも、CLAUDE.mdやauto memoryは文脈であって強制設定ではなく、操作を確実に止めるにはhookなどの仕組みが必要だと説明されています。
つまり、比較でそろえるべきものは「同じモデルを使ったか」だけではありません。何を読ませ、どこまで触らせ、どのコマンドを許し、失敗したときに何を残したかまで含めて、ようやく結果を読めます。
SWE-benchは参考になるが、自社導入前の答えをそのまま出してはくれない
SWE-benchは、GitHub上の実世界のissueをもとに、コードベースとissueから問題を解決するpatchを生成できるかを評価するベンチマークです。これはAIコーディング評価の考え方を学ぶうえで重要な一次情報ですが、自社のReact管理画面、社内API、Playwrightの癖、レビュー文化まで直接測ってくれるわけではありません。
この記事では、SWE-benchのように「タスク、コード、評価」を分ける考え方だけ借ります。実務導入前には、自社の作業に近いBugfix、Feature Add、Test Repairを小さく作り、同じ形式で回す方が判断しやすくなります。
結果：小さくても同じ条件は作れる
Bugfix、Feature Add、Test Repairを1件ずつ用意する。
Agentごとの差が出ても、最初の依頼文は同じ形式にする。
結果、理由、残ったリスク、再実行時の確認点をそろえる。
テスト結果、差分、承認、失敗理由をあとで見返せるようにする。
小さなキットでも、同じ条件で比べる意識が入るだけで会話は具体的になります。
今回の結論はシンプルです。最初から大規模なランキング基盤を作る必要はありません。3タスク、1つの開始プロンプト形式、1つのscorecard、1つのログ保存ルールがあれば、導入前の会話はかなり具体的になります。
最初のキットは3タスクで足りる
最小構成は次の3つです。
| タスク | 見たい能力 | 合格条件の例 |
|---|---|---|
| Bugfix | 再現ログから原因を切り分け、最小差分で直す力 | 再現手順が通り、回帰テストが追加される |
| Feature Add | 受け入れ条件を読み、余計な変更を増やさず機能を足す力 | 指定された機能だけが入り、既存テストが壊れない |
| Test Repair | 壊れたテストを弱めず、実装と期待値のズレを直す力 | skipやassertion弱体化なしでテストが通る |
3つに分ける理由は、同じ「コードを書く」でも評価すべき失敗が違うからです。Bugfixでは原因調査が浅いと危険です。Feature Addでは要件外の変更が増えやすくなります。Test Repairでは、テストを通すためにテストそのものを弱める失敗が起きます。
手元のミニ検証ではPlaywright 1件を再実行した
ローカルでは、.verification/cursor-playwright-nextjs-test-repair にあるNext.js + Playwrightの小さなフィクスチャを使いました。対象は、ボタンのaccessible nameがテスト期待値とずれていたケースです。
失敗ログの要点は次の形でした。
Running 1 test using 1 worker
✘ tests/request-form.spec.ts:3:1 › 申請フォームから確認へ進める
Test timeout of 30000ms exceeded.
Error: locator.click: Test timeout of 30000ms exceeded.修正差分は、ボタンの表示名とaria-labelをテストが探す名前にそろえるだけです。
- <button type="submit" aria-label="申請内容を確認する">
- 送信
+ <button type="submit" aria-label="送信する">
+ 送信する2026年6月16日、macOS 26.5、Darwin 25.5.0 arm64、Node.js v25.9.0、npm 11.12.1で、rtk npm run test:e2eを実行し、実体のplaywright testは1件成功しました。
Running 1 test using 1 worker
✓ tests/request-form.spec.ts:3:1 › 申請フォームから確認へ進める
1 passed (4.2s)この結果は、どのAgentが優れているかを示すものではありません。記事内で使う「失敗ログ、修正差分、再実行ログを同じ単位で残す」サンプルです。
なぜAIコーディング比較をキット化するのか
- 1条件差を見つける
タスク定義、権限、ヒント量、テスト条件の差を見えるようにする。
- 2作業タイプで分ける
Bugfixが得意でも、Feature AddやTest Repairで同じ結果とは限らない。
- 3再実行できる形にする
同じ開始条件で回せるように、入力と記録形式を残す。
- 4チーム判断に使う
総合順位ではなく、任せる範囲とレビューの置き方を決める。
キット化の目的は、感想を減らすことではなく、判断の再現性を上げることです。
AIコーディングエージェントの導入判断で一番危ないのは、たまたま成功した1回の作業を、チーム全体の導入根拠にしてしまうことです。逆もあります。初回で失敗しただけで、タスク定義や権限設定が悪かった可能性を見ずに、ツール全体を見送ってしまうことです。
体感比較は条件がそろいにくい
人間が試すと、どうしても条件がずれます。片方のAgentには詳しい補足を入れ、もう片方には短い指示だけ渡す。片方ではネットワークを許可し、もう片方では拒否する。片方では失敗後に追加ヒントを出し、もう片方ではそこで打ち切る。
この状態で「Aの方が強い」と言っても、実際にはAgentの能力差ではなく、入力差、権限差、再試行差、レビュー差を見ている可能性があります。
導入判断に必要なのは作業タイプ別の傾向
実務で知りたいのは、総合ランキングよりも次のような判断です。
- 既存バグの原因調査を任せても、差分が大きくなりすぎないか
- UI追加で、受け入れ条件以外のデザイン変更やリファクタを増やさないか
- テスト修復で、テストを削ったり、assertionを弱めたりしないか
- 失敗したとき、ログと説明がレビューできる形で残るか
- 外部API、秘密情報、非公開コードに触る場面で止められるか
この粒度で見ると、評価対象は「Agent名」ではなく「自社タスクと運用ルールの組み合わせ」になります。
AI Coding Benchmark Kitの全体像
最初はWeb UIより、読めるタスク定義と見返せる証跡を優先します。
最小キットは、次のようなディレクトリで十分です。最初からWeb UIや自動採点基盤を作る必要はありません。
ai-coding-benchmark-kit/
README.md
tasks/
bugfix-accessible-name.yml
feature-add-filter.yml
test-repair-playwright.yml
prompts/
run-template.md
runs/
2026-06-16-codex-bugfix-accessible-name/
prompt.md
commands.log
test.log
diff.patch
scorecard.md
reports/
summary-2026-06.md
.github/
workflows/
benchmark.ymltasksには入力条件を置く
タスク定義には、少なくとも次の項目を置きます。
id: bugfix-accessible-name
type: bugfix
start_commit: "abc1234"
allowed_paths:
- "app/**"
- "tests/**"
blocked_paths:
- ".env*"
- "package-lock.json"
goal: "Playwrightのrole locatorが探すボタン名と実装のaccessible nameをそろえる"
success_commands:
- "npm run test:e2e"
must_not:
- "テストをskipしない"
- "assertionを弱めない"
- "関係ないUIを変更しない"
evidence:
- "失敗ログ"
- "修正差分"
- "再実行ログ"
- "未実行なら理由"ここで大事なのは、Agentに「頑張って直して」と渡さないことです。何を達成すればよいか、どこまで触ってよいか、何をしてはいけないかを、評価者があとで読める形にします。
runsにはAgentごとの記録を置く
同じタスクを複数Agentで回す場合、結果だけを表にしないで、実行単位ごとに記録を残します。
runs/
2026-06-16-codex-bugfix-accessible-name/
2026-06-16-claude-code-bugfix-accessible-name/
2026-06-16-copilot-bugfix-accessible-name/各runには、開始プロンプト、承認の有無、実行コマンド、失敗ログ、最終差分、scorecardを置きます。これがない比較表は、あとから見返したときに「なぜその判定になったか」が追えません。
reportsには人間向けの要約を置く
レポートはランキング表ではなく、判断材料として書きます。
| 観点 | 書くこと |
|---|---|
| タスク別の傾向 | Bugfixでは安定、Feature Addでは差分が大きいなど |
| レビュー負荷 | 人間が確認すべきファイル、説明不足、危険な変更 |
| 再実行条件 | モデル変更、料金プラン変更、権限変更、CI変更 |
| 見送り条件 | 外部API依存、秘密情報、破壊的操作、長時間実行の失敗 |
この形式にしておくと、月次で同じタスクを再実行したときに、ツール更新やモデル更新の影響も見やすくなります。
Bugfix・Feature Add・Test Repairのタスク定義
同じ成功に見えても、タスクごとに評価すべき失敗パターンは違います。
3種類のタスクは、同じように見えて失敗の出方が違います。最初から分けて作る方が、結果の読み違いを減らせます。
Bugfixは再現手順と回帰テストで縛る
Bugfixタスクでは、バグ説明だけでは足りません。再現手順、期待結果、現在の失敗ログ、修正後に通すコマンドを書きます。
良いBugfixタスクの条件は、次の4つです。
- 失敗が手元で再現できる
- 直すべきふるまいが一文で説明できる
- 修正後に通すテストコマンドがある
- 関係ないリファクタを禁止している
「一覧が壊れているので直して」では弱すぎます。「検索条件を空にしたとき、既存の全件表示へ戻らない。npm run test:e2e -- request-filterで再現する。APIレスポンス形式は変えない」のように書くと、Agentの余計な探索を減らせます。
Feature Addは受け入れ条件と非要件を分ける
Feature Addでは、やってほしいことより、やらないでほしいことが重要です。AIエージェントは、親切に見える変更を足すことがあります。UI文言を変える、型を広く直す、コンポーネント構造を入れ替える。実務では、それがレビュー負荷になります。
タスク定義には、受け入れ条件と非要件を分けます。
acceptance:
- "一覧をステータスで絞り込める"
- "既存の検索条件と併用できる"
- "フィルタ解除で全件に戻る"
out_of_scope:
- "一覧UIのデザイン変更"
- "APIレスポンス形式の変更"
- "状態管理ライブラリの追加"この非要件リストは、採点にも使います。機能が動いても、禁止した変更が入っていたらPartialまたはFailにします。
Test Repairはテスト弱体化を防ぐ
Test Repairは、AIコーディング比較で特に危険です。テストを通すだけなら、skipする、timeoutを伸ばす、assertionを曖昧にする、locatorを広くする、といった逃げ道があります。
そのため、Test Repairでは最初に原因の候補を書きます。
- 実装が壊れている可能性が高い
- テストの期待値が古い可能性が高い
- テスト環境の待機条件が不安定
- 外部APIや時刻依存で揺れている
さらに、禁止事項を明示します。
must_not:
- "test.skipを追加しない"
- "expectを削除しない"
- "locatorをbody全体へ広げない"
- "timeoutだけを伸ばして解決扱いにしない"テスト修復は、テストを通すゲームではありません。プロダクトの期待動作とテストの表現をそろえる作業です。
同じ条件で実行するためのランナー設計
- 1開始コミット
同じ状態から作業を始め、差分の比較をしやすくする。
- 2開始プロンプト
タスク、制約、禁止事項、指定コマンドを同じ形式で渡す。
- 3権限と承認
読み取り、書き込み、ネットワーク、承認回数を記録する。
- 4モデルとプラン
利用したモデルやプランを、あとから更新できる形で残す。
- 5証跡
ログ、テスト結果、差分、失敗理由をrun単位で保存する。
完全に同じ操作体験ではなく、比較で固定する項目を決めることが大切です。
Agentごとの自然な使い方は違います。Codex、Claude Code、Cursor、Copilot cloud agentを完全に同じ操作体験にすることはできません。だからこそ、比較で固定する項目を決めます。
開始プロンプトを固定する
開始プロンプトは、次の形にします。
あなたはAI Coding Benchmark Kitのタスクを実行しています。
Task ID: bugfix-accessible-name
Goal: Playwrightのrole locatorが探すボタン名と実装のaccessible nameをそろえる。
制約:
- allowed_paths以外を変更しない。
- テストをskipしない。
- assertionを弱めない。
- 関係ないリファクタをしない。
実行してほしい確認:
- 失敗ログを読む。
- 最小差分で修正する。
- npm run test:e2eを実行する。
- 実行できない場合は理由をscorecardに書く。
最後に残すもの:
- 変更したファイル
- 実行したコマンド
- テスト結果
- 未検証項目
- 人間レビューで見てほしいリスクこのプロンプトは、Agentに同じ文章を押し付けるためではなく、評価者が同じ観点で結果を読めるようにするためのものです。
権限と承認を記録する
権限は結果に影響します。OpenAI Codexでは、sandbox modeとapproval policyが実行可能範囲を左右します。GitHub Copilot cloud agentでは、GitHub上でリポジトリ調査、plan、branch上の変更、pull request作成までの流れが説明されています。Claude Codeでは、memoryは文脈として効く一方、command hooksはユーザー権限で動くため、設定内容をレビューする必要があります。
run記録には、最低限これを入れます。
| 記録項目 | 理由 |
|---|---|
| sandbox / permission | どこまで自動で触れたかを読むため |
| network access | 外部情報を使ったかを分けるため |
| write範囲 | 変更が許可範囲内かを見るため |
| approval回数 | 自走度とレビュー負荷を見るため |
| secrets利用 | 秘密情報を触らせていないか確認するため |
チームで指示ファイルをそろえる場合は、<a href="https://ai-dev.blog.mo-gmo.com/agents-md-standardization-team-ai-coding-instructions/">AGENTS.md標準化の実務影響</a>も合わせて読むと、プロンプトとリポジトリ内ルールの分担を整理しやすくなります。
モデルとプランは本文末で更新できる形にする
モデル名、料金プラン、トークン上限、AI credits、実行時間制限は変わりやすい情報です。記事や社内レポートの冒頭に大きな前提表を置くより、run単位と更新履歴に短く残す方が運用しやすくなります。
run_metadata:
date: "2026-06-16"
agent: "codex"
model: "記録できる場合だけ書く"
plan: "記録できる場合だけ書く"
network: "disabled"
sandbox: "workspace-write"
commands:
- "npm run test:e2e"未確認の値は書かない。これが地味に大切です。特に料金や制限は、古い情報が残ると導入判断を間違えます。
スコアリングは点数より判定理由を残す
受け入れ条件を満たし、指定コマンドが通ったかを見る。
どのテストを実行し、どのログで確認できるかを残す。
必要な差分に収まり、余計なリファクタが増えていないかを見る。
Partial判定の理由、残った懸念、壊れた既存テストを残す。
再実行、追加検証、人間レビューのどれにつなげるかを書く。
70点と75点の差より、なぜPartialなのかが実務判断では効きます。
100点満点の表は見栄えがよい一方で、実務判断には向かないことがあります。70点と75点の差より、なぜPartialなのか、どのリスクが残ったのか、再実行したら何を見るのかの方が重要です。
Correctnessだけで終わらせない
最小scorecardは、次の6項目にします。
| 項目 | Pass | Partial | Fail |
|---|---|---|---|
| Correctness | 受け入れ条件を満たす | 一部条件のみ満たす | 主要条件を満たさない |
| Minimality | 差分が目的に閉じている | 余計な変更が少しある | 大きな無関係変更がある |
| Test Evidence | 指定テストと必要な追加テストがある | 一部のみ実行 | 未実行または根拠なし |
| Instruction Following | 禁止事項を守る | 軽微な逸脱がある | 禁止変更をした |
| Safety | 秘密情報や外部操作を避ける | 確認不足がある | 危険な操作がある |
| Reproducibility | ログと差分で再現できる | 一部情報が不足 | 追跡できない |
合計点を出すなら、最後に補助として扱います。本文や社内報告では、Pass/Partial/Failと理由を主役にします。
Partial判定を先に決める
採点で揉めやすいのは、完全失敗ではないケースです。
- 機能は動いたが、関係ないファイルも大きく変更した
- テストは通ったが、追加すべき回帰テストがない
- 修正は正しいが、なぜその修正にしたのか説明がない
- 指定コマンドは通ったが、別の既存テストを壊している
- 失敗ログを読まずに推測だけで直している
これらは事前にPartialとして定義しておきます。Agentの評価だけでなく、人間レビューのばらつきも減ります。
評価基準を変える条件
評価基準は、途中で変えないのが原則です。ただし、タスク定義の不備が明らかになった場合は、runを無理に採点せず、タスクを修正して再実行します。採点表をあとから都合よく変えると、Agentの差ではなく評価者の後出し条件を測ってしまいます。
既存ベンチマークから考え方だけ借りる
SWE-benchは、実世界のGitHub issueに対してpatchを作る評価として参考になります。OpenAIのagent evals docsでは、trace、grader、dataset、eval runを使ってagent workflowを評価する考え方が説明されています。
自社キットでも、同じように「入力」「実行」「証跡」「採点」を分けます。ただし、最初から大きな評価基盤にしないこと。3タスクを手で回して、レビュー会で読めるscorecardを残すところから始める方が、導入判断には近道です。
CIとレポート保存をキットに含める
- 1テスト実行
指定コマンドと追加で回した確認コマンドを分けて残す。
- 2Reporter
Playwrightなどのレポートを、runごとに見返せる形にする。
- 3Artifact
ログやレポートを保存し、あとで判断を確認できるようにする。
- 4Run summary
人間が読む短い要約に、結果と判定理由をまとめる。
- 5保存期間
必要以上に長く残さず、運用に合った期限を決める。
ログが残っていない比較は、翌週にはほとんど判断できなくなります。
AIエージェント比較の失敗は、ログを保存していないことから起きます。成功したかどうかだけをチャットに残しても、翌週には判断できません。
Playwrightはreporterを使って証跡を分ける
Playwrightの公式Docsでは、list、line、dot、json、HTML、JUnit、GitHub Actions annotationsなど複数のreporterが説明されています。小さな導入前キットなら、ローカルではlist、CIではdotやgithub reporter、保存用にはjsonやHTMLを使う設計が扱いやすいです。
例として、ローカルの見やすさと保存用JSONを分けるなら、次のようにします。
import { defineConfig } from "@playwright/test";
export default defineConfig({
reporter: [
["list"],
["json", { outputFile: "reports/playwright-results.json" }]
],
});レポートを残す目的は、失敗時に人間が読み返せるようにすることです。長いstdoutをそのまま貼るより、機械用のJSONと人間用のscorecardを分けます。
GitHub Actionsのartifactは保存期間を短く決める
GitHub Actionsでは、workflow artifactとしてファイルを保存できます。GitHub Docsでは、actions/upload-artifactにretention-daysを指定して個別artifactの保存期間を設定できることが説明されています。組織やリポジトリの上限もあるため、社内ルールと合わせて決めます。
- name: Upload benchmark evidence
uses: actions/upload-artifact@v4
with:
name: benchmark-${{ github.run_id }}
path: |
runs/**
reports/**
retention-days: 14保存期間を長くすれば安心、という話ではありません。AIエージェントのログには、ファイル名、エラー内容、社内仕様、場合によっては個人情報や秘密情報に近いものが入りえます。保存対象と除外対象を先に決めます。
保存しない情報を先に決める
artifactに入れる前に、保存しない情報を決めます。APIキー、個人情報、本番データ、社内URL、private repository固有の長いコード断片は、ベンチマーク証跡として残す対象から外します。必要な場合は、ダミー値と短い抜粋へ置き換えます。
人が読むrun summaryを別に作る
CIログとartifactだけでは、導入会議で読みづらくなります。runごとに、短いsummaryを置きます。
# run summary
- Task: bugfix-accessible-name
- Agent: codex
- Result: Partial
- Commands: npm run test:e2e
- Test result: 1 passed
- Changed files: app/page.tsx
- Review risk: accessible nameの方針をデザイン側と確認
- Not verified: 他ブラウザでのE2Eこの1枚があると、比較表から詳細ログへ降りる導線ができます。
サンプルリポジトリとして配布できる最小構成
勝者を決めるためではなく、判断材料を作るためのキットだと明記する。
入力、制約、禁止事項、指定コマンドを人間が読める形式にする。
PRレビューに貼れる長さで、判定理由を書けるようにする。
秘密情報や本番データを含まない小さな再現例を置く。
公開できる小型サンプルで型を作ると、社内導入時のリスクを下げられます。
Benchmark Kitは、社内リポジトリに直接入れる前に、公開可能な小型サンプルで型を作ると安全です。社内コードやAPIキーを含めず、タスク定義、ログ形式、採点表だけを再利用します。
READMEには「勝者を決めない」と書く
READMEの最初に、目的を明記します。
# AI Coding Benchmark Kit
このリポジトリは、AIコーディングエージェントの順位を決めるためではなく、
自社タスクに近いBugfix、Feature Add、Test Repairを同じ条件で測るための
最小テンプレートです。この一文がないと、あとで「どれが最強だったか」という話に吸い寄せられます。
タスクメタデータは人間が読める形式にする
最初はYAMLかMarkdownで十分です。データベース化やダッシュボード化は、3タスクを数回回してからで構いません。
tasks/
bugfix-accessible-name.yml
feature-add-status-filter.yml
test-repair-flaky-form.yml各ファイルには、目的、許可範囲、成功条件、禁止事項、実行コマンド、採点観点を書きます。
ScorecardはPRレビューに貼れる長さにする
scorecardは、長すぎると読まれません。1タスク1ページを目安にします。
Scorecard
| Item | Result | Evidence |
| --- | --- | --- |
| Correctness | Pass | npm run test:e2e passed |
| Minimality | Pass | app/page.tsxのみ |
| Test Evidence | Partial | 既存E2Eのみ、回帰テスト追加なし |
| Safety | Pass | secrets未使用 |
| Reproducibility | Pass | prompt、diff、test.logあり |この程度なら、PR本文にも社内レビュー資料にも転用できます。
結果を導入判断に変換する
コストと速度は、修正品質や安全性とセットで読まないと誤解しやすくなります。
Benchmark Kitの目的は、比較表を作って終わることではありません。どの作業をAIに任せるか、どこで人間が止めるか、どの権限を開けるかを決めることです。
採用、追加検証、見送りに分ける
結果は、次の3つに分けます。
| 判定 | 条件の例 | 次の動き |
|---|---|---|
| 採用候補 | 3タスクでPassが多く、差分が小さく、ログも読める | 小さな本番タスクでpilot |
| 追加検証 | Correctnessは高いが、差分や権限に不安がある | タスクを増やして再実行 |
| 見送り | テスト弱体化、危険な操作、説明不足が繰り返される | 権限設計やタスク定義を見直す |
この判定は、ツール全体の永久評価ではありません。2026年6月16日時点のタスク、設定、モデル、プラン、リポジトリに対する判断です。
作業タイプごとに任せ方を変える
たとえば、BugfixではPassが多いがFeature Addでは余計な差分が増えるAgentがあるかもしれません。その場合、Bugfixの一次調査や候補差分には使い、Feature Addではplanだけ任せる、という選択ができます。
逆に、Test Repairでテストを弱めがちなAgentは、テスト修復を自動実行させず、失敗原因の説明だけに使う方がよい場合があります。
コストと速度は安全性と一緒に読む
速いことは重要です。ただし、速さだけで導入すると、レビュー負荷や承認漏れで後から詰まります。GitHub Copilot cloud agentのDocsでは、利用にGitHub Actions minutesやAI creditsが関係することも説明されています。料金や上限は変わりやすいため、運用前に必ず自分のプランで確認します。
料金観点を深く見る場合は、<a href="https://ai-dev.blog.mo-gmo.com/github-copilot-ai-credits-agent-mode-code-review-budget/">GitHub CopilotのAI Credits移行を読む</a>も参考になります。
失敗点とハマりどころ
片方だけ詳しい補足を足すと、結果の比較が崩れる。
Test Repairでassertionを弱めると、成功に見えて品質が落ちる。
外部APIキーや本番データがログに混ざらないようにする。
成功か失敗かだけでは、あとから原因と再現性を確認できない。
キットは作るだけでは公平にならないため、条件差と保存内容を先に決めます。
Benchmark Kitは、作れば自動的に公平になるわけではありません。むしろ、作り方を間違えると、間違った自信を強めます。
片方だけヒントを足してしまう
よくある失敗は、片方のAgentが迷ったときだけ、人間が追加ヒントを出すことです。実務では自然なやり取りですが、比較としては条件が崩れます。
追加ヒントを出すなら、その時点で再試行回数として記録します。可能なら、同じ補足を全Agentに渡して再実行します。
Test Repairでテストを弱めてしまう
テストが通ったことだけを見ると、テスト削除やassertion弱体化を見落とします。Test Repairのscorecardには、必ず次を入れます。
- skipが増えていないか
- expectが削られていないか
- locatorが不自然に広くなっていないか
- timeout変更だけで解決扱いにしていないか
- 失敗原因の説明がログと合っているか
この確認をしないTest Repair比較は、むしろ危険です。
外部APIや秘密情報がログに混ざる
Agentが調査中に環境変数、APIレスポンス、顧客名、社内URLをログへ出すことがあります。Benchmark Kitでは、そもそも秘密情報が必要なタスクを最初の対象にしない方が安全です。
必要な場合も、ダミー値、モックAPI、read-only token、短いartifact保存期間を使います。ログ保存の設計は、セキュリティ設計です。
実務で使うなら
- 1日目
既存の失敗ログから、代表的な3タスクを選ぶ。
- 2日目
タスク定義、受け入れ条件、禁止事項を書く。
- 3〜5日目
複数Agentで同じrun形式を回し、証跡を残す。
- 6日目
人間レビューでscorecardの判定理由を確定する。
- 7日目
採用、追加検証、見送りと、任せる範囲を決める。
1週間で見るのは総合順位ではなく、どの作業をどこまで任せられるかです。
最初の1週間でやるなら、次の順番が扱いやすいです。
1日目：既存の失敗ログから3タスクを選ぶ
新しく課題を作るより、過去に実際に起きた小さなバグ、軽い機能追加、テスト失敗を使います。ただし、社外へ出せない情報は削り、再現用の小型fixtureに移します。
2日目：タスク定義と禁止事項を書く
各タスクに、allowed paths、blocked paths、success commands、must notを入れます。ここを曖昧にすると、Agentの比較ではなく、タスク作成者の説明力を測ることになります。
3日目から5日目：複数Agentで同じrun形式を回す
Codex、Claude Code、Cursor、Copilotなど、候補のAgentを同じrun形式で回します。Agentごとの自然な使い方は残しつつ、開始プロンプト、ログ、scorecardをそろえます。
CodexとClaude Codeの併用や役割分担を検討している場合は、<a href="https://ai-dev.blog.mo-gmo.com/claude-code-codex-team-dual-use-roles-mcp-memory-budget/">Claude CodeとCodexを併用する前に</a>の記事も合わせて確認すると、read-onlyレビューと編集担当を分ける発想が使えます。
6日目：人間レビューでscorecardを確定する
AIに自己採点させるだけでは足りません。人間が差分、ログ、テスト、禁止事項を見て、Pass、Partial、Failを確定します。
7日目：導入範囲を決める
最後に、採用候補、追加検証、見送りを決めます。ここでいきなり全リポジトリへ広げず、小さな本番タスクでpilotします。権限設定を広げる場合は、<a href="https://ai-dev.blog.mo-gmo.com/codex-config-toml-permissions-rules-agents-md-mcp/">Codex設定を増やす前に決めること</a>のような設定整理も必要です。
セキュリティ・コスト注意
最初は読み取り中心にして、書き込みや外部接続を段階的に開ける。
hooksや自動実行は便利だが、何が動くかを確認してから使う。
コストは1回の料金だけでなく、失敗後の再実行で上振れする。
secret、本番データ、申請内容などをログに残さない。
ベンチマークの仕組み自体がリスクにならないよう、権限と保存内容を制限します。
AIコーディングのベンチマークは、コードを書かせるだけの話ではありません。権限、ログ、料金、承認の扱いを間違えると、検証のために作った仕組みがそのままリスクになります。
権限はread-onlyから始める
最初のrunでは、できるだけread-only調査、plan、diff提案までに閉じます。いきなり外部API、データベース、本番認証、書き込み権限を渡さない方が安全です。
書き込みを許す場合でも、allowed pathsを限定します。package manager、migration、外部API呼び出し、delete操作、credential操作は、別の承認対象にします。
Claude Code hooksは便利だが強い権限で動く
Claude Codeのhooks docsでは、command hooksがシステムユーザーの権限でshell commandを実行し、ユーザーがアクセスできるファイルへアクセス、変更、削除できることが明記されています。Benchmark Kitにhookを使う場合は、hookも評価条件の一部です。
「hookが賢く補助した結果」と「Agent本体ができた結果」を混ぜると、比較が読めません。使うなら、run metadataにhook名と目的を残します。
コストは再試行回数で上振れする
Agent比較は、同じタスクを複数回回したくなります。モデル、プラン、AI credits、Actions minutes、外部API料金が絡む場合、再試行回数でコストが上振れします。
runごとに、開始時刻、終了時刻、再試行回数、実行コマンド、使用プランを残します。金額が確定できない場合は、無理に試算せず、どの利用枠に影響するかまでを記録します。
ログには保存しないものを決める
保存対象外リストを作ります。
- APIキー、token、cookie
- 顧客名、メールアドレス、個人情報
- 非公開URL、社内ホスト名
- 本番DBの実データ
- private repositoryの固有コード断片
- 契約や請求に関わる内部情報
このリストがない状態でartifactを残すと、あとで削除作業が発生します。
FAQ
総合順位より、自社タスクでの任せ方を決める方が実務では使いやすい。
公開ベンチは参考にしつつ、社内の権限やタスク条件は別に確かめる。
秘密情報を含まない小さな再現リポジトリで型を作る。
回数だけでなく、失敗の種類と再実行時に見る点を残す。
補助には使えても、最終判定はログと人間レビューで確認する。
FAQの答えも、勝者探しではなく運用判断に戻して読むとぶれにくくなります。
どのAgentが一番強いかを出さないと意味がないのでは？
導入前に必要なのは、総合順位よりも自社タスクでの任せ方です。Bugfixは任せられるがFeature Addはplanまで、Test Repairは人間レビュー必須、という結論の方が実務では使えます。
SWE-benchをそのまま見ればよいのでは？
SWE-benchは重要な参照点です。ただし、自社リポジトリの権限、テスト、レビュー、CI、秘密情報の扱いまでは測れません。公開ベンチマークは市場全体の参考にし、自社導入前の判断は小さなBenchmark Kitで補います。
社内コードを使えない場合はどうする？
公開可能な小型fixtureを作り、タスク形式だけ社内でも使います。社外へ出すサンプルには、ダミーデータ、モックAPI、短いログだけを入れます。社内runのログは保存場所と閲覧権限を分けます。
何回実行すれば判断できる？
最初は3タスクを1回ずつで構いません。ただし、その結果で全社導入を決めるのは早すぎます。候補を絞ったあと、同じタスクの再実行や、自社コードに近い追加タスクで傾向を見ます。
Agentに自己採点させてもよい？
下書きとしては使えます。ただし、最終判定は人間が差分、ログ、テスト結果、禁止事項を確認して決めます。AI生成の採点は、レビュー対象であって監査結果ではありません。
次に読むなら
参照した主な情報源
- OpenAI Codex Agent approvals & security: https://developers.openai.com/codex/agent-approvals-security
- OpenAI Codex Sandboxing: https://developers.openai.com/codex/concepts/sandboxing
- OpenAI Codex AGENTS.md: https://developers.openai.com/codex/guides/agents-md
- OpenAI Evaluate agent workflows: https://developers.openai.com/api/docs/guides/agent-evals
- Claude Code memory docs: https://code.claude.com/docs/en/memory
- Claude Code hooks docs: https://code.claude.com/docs/en/hooks
- GitHub Copilot cloud agent docs: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent
- GitHub Copilot task kickoff docs: https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/kick-off-a-task
- SWE-bench GitHub: https://github.com/swe-bench/SWE-bench
- SWE-bench overview: https://www.swebench.com/SWE-bench/
- Playwright reporters docs: https://playwright.dev/docs/test-reporters
- GitHub Actions workflow artifacts: https://docs.github.com/en/actions/tutorials/store-and-share-data
更新履歴
- 2026-06-16
初版として、需要シグナルと一次情報の扱いを分けた。
- 一次情報
OpenAI、Anthropic、GitHub、SWE-bench、Playwrightの情報を確認した。
- ローカル確認
実行環境、Node.js、npm、Next.js、React、Playwrightなどの条件を記録した。
更新履歴は、読者が記事の前提と検証範囲を後から確認するための記録です。
- 2026-06-16: 初版。Xの需要シグナルは市場関心としてのみ使用。仕様確認はOpenAI、Anthropic、GitHub、SWE-bench、Playwrightの一次情報で実施。ローカルではmacOS 26.5、Darwin 25.5.0 arm64、Node.js v25.9.0、npm 11.12.1、Next.js 16.2.7、React 19.2.7、Playwright 1.60.0、TypeScript 5.9.3の小型fixtureで
rtk npm run test:e2eを実行し、Playwright 1件の成功ログを確認。モデル名、料金プラン、実在Agent間の勝敗はこの記事では検証対象外。