AI Coding Benchmark Kitの作り方：Bugfix・Feature Add・Test Repairを同一条件で測る

3行まとめ

入力

同じrepo状態、Issue、失敗ログ、制約を渡します。

検証

typecheck、unit test、E2E、CIを同じ条件で走らせます。

記録

prompt、diff、実行時間、未検証項目、コストメモを残します。

勝敗より先に、比較条件を揺らさないことが出発点です。

• AIコーディングツールを公平に比べるには、ツール名より先に、同じrepo状態、同じIssue、同じ失敗ログ、同じ検証コマンドを固定します。
• 最初のBenchmark Kitは、Bugfix、Feature Add、Test Repairの3タスクで十分です。速度の印象より、テスト通過、差分の読みやすさ、未検証項目、権限の扱いを残します。
• この記事はランキング記事ではありません。2026年5月31日時点の公式情報とローカル確認をもとに、日本語チームが自分たちのrepoで再現できる評価台を作るための記事です。

本文の事実確認には、公式ドキュメント、公式ヘルプ、関連する仕様・SDKドキュメントを使っています。実リポジトリでの性能ベンチマークや更新代行は、本文で明記した場合を除き実施していません。

この記事でわかること

タスク定義

Bugfix、Feature Add、Test Repairを同じ形式で用意できます。

ログ形式

prompt、commands、diff、test result、review memoを保存できます。

採点表

速度だけでなく、レビュー容易性、安全性、コストも見られます。

運用ルール

read-only開始、人間承認、秘密情報除外の線引きを決められます。

比較記事ではなく、自分たちで比較できる状態を作るための記事です。

• AIコーディングツール比較用の最小ディレクトリ構成
• Bugfix、Feature Add、Test Repairを同じ条件で測るタスク定義
• Playwright、Vitest、TypeScript、GitHub Actionsのログを保存する考え方
• 評価表に入れるべき項目と、点数だけでは見落とす項目
• エージェントに渡す権限、秘密情報、外部通信、コストの注意点
• 実務チームで1週間だけ試すときの運用手順

前提知識

1. 1Issue粒度

   一方だけ詳細だと結果が有利になります。

2. 2権限差

   テスト実行や外部通信の可否で成果が変わります。

3. 3ログ差

   失敗原因を残さないと後で比較できません。

4. 4レビュー差

   人間の確認基準が違うと採用判断が揺れます。

Benchmark Kitは、評価対象外の差を減らすための実験装置です。

AIツール比較は入力条件で簡単に歪む

AIコーディングツールの比較は、思った以上に入力条件で結果が変わります。あるツールには詳細なIssue、失敗ログ、関連ファイル、期待する修正方針を渡し、別のツールには「テストを直して」とだけ渡せば、結果は比較になりません。

同じツールでも、初回実行か、会話履歴があるか、repo全体を読めたか、ネットワークを使えたか、テストを実行できたかで成果が変わります。モデル名や月額だけではなく、作業環境そのものが評価対象です。

そろえるべき条件

最低限、次の条件はそろえます。

条件	そろえる内容
repo状態	同じcommit、同じlockfile、同じfixture、同じ環境変数
入力	Issue本文、制約、失敗ログ、対象外の範囲
権限	read-only、ファイル編集、コマンド実行、外部通信、PR作成
検証	lint、typecheck、unit test、E2E、coverage
記録	prompt、実行時間、コマンド、stdout、stderr、diff、未検証項目

ここが崩れると、比較は「その日の相性」に寄ってしまいます。Benchmark Kitの役割は、AIツールの性能を一発で決めることではなく、比較条件を揺らさないことです。

Benchmark Kitはランキング表ではなく実験装置

この記事で作るBenchmark Kitは、公開ベンチマークの代替ではありません。小さなチームが、候補ツールを実務導入する前に、自分たちの開発スタイルに近いタスクで試すための実験装置です。

ランキング表だけを作ると、点数の高いツールを選んだ気分にはなれます。しかし実務では、失敗したときに何が起きるかのほうが大事です。テストが落ちたときにログを読んで戻れるか。大きすぎる差分を出したときにレビューできるか。秘密情報に近い操作を避けられるか。CIで再実行できるか。ここまで見ないと、導入判断には使いにくいです。

Benchmark Kitの全体像

項目	内容	見方
Bugfix	失敗テストを通す	原因特定、最小差分、回帰防止を見ます。
Feature Add	小さな仕様追加	既存設計の理解、新規テスト、互換性を見ます。
Test Repair	壊れたE2E修正	仕様を変えずにテストを安定化できるかを見ます。

得意不得意はタスクごとに出るため、1種類だけで決めないようにします。

最小構成は、次の3タスクです。

タスク	目的	主な評価
Bugfix	既存の失敗テストを通す	原因特定、最小差分、回帰防止
Feature Add	小さな仕様追加を実装する	既存設計の理解、新規テスト、互換性
Test Repair	壊れたE2Eテストを直す	UI仕様の理解、テストの安定性、誤修正の回避

この3つに分ける理由は、AIツールの得意不得意が違うからです。Bugfixが得意でも、既存設計に沿ったFeature Addが雑なことがあります。逆に、機能実装は速いのに、E2Eの失敗ログから本当の原因を切り分けるのが苦手なこともあります。

1タスク1ブランチ1ログにする

タスクごとに、次の単位で記録します。

benchmark-kit/
  tasks/
    bugfix-date-format/
    feature-filter-panel/
    test-repair-login-flow/
  runs/
    2026-05-31-codex-bugfix-date-format/
    2026-05-31-claude-code-bugfix-date-format/
  reports/
    scorecard-2026-05-31.md

tasks/には入力条件を置き、runs/には実行結果を置きます。タスク定義と実行ログを混ぜないのが大事です。あとで別のAIツールを試すとき、同じtasks/を使い回せます。

評価しないもの

このKitでは、次のものは評価対象から外します。

• モデル全般の能力を代表する総合順位
• 企業ごとのセキュリティ体制の完全比較
• 非公開コードでの結果を一般化した断定
• 料金プランの恒久的な優劣
• 開発者のレビュー能力まで含む完全自動化

言い換えると、「自分たちのrepoで、この作業を任せてもよいか」を見るための小さな実験です。

ディレクトリ構成とメタデータ

1. 1tasks

   task.md、constraints.md、expected.md、seed.patch、verify.shを置きます。

2. 2runs

   ツール別のprompt、transcript、commands、diff、reviewを保存します。

3. 3reports

   scorecardや比較表をまとめます。

タスク定義と実行ログを混ぜないと、別ツールで再試行しやすくなります。

まず、タスク定義をファイルとして固定します。

tasks/bugfix-date-format/
  task.md
  constraints.md
  expected.md
  seed.patch
  verify.sh
  fixtures/
    input.json

task.mdには、AIツールへ渡すIssue本文を書きます。constraints.mdには、変更してよい範囲、禁止操作、使ってよいコマンドを書きます。expected.mdには、人間レビュー用の期待結果を書きます。AIツールへ最初から答えを渡す必要はありませんが、評価者が迷わないようにします。

seed.patchは、失敗状態を作るための差分です。毎回同じcommitへ当ててから実行すると、比較条件を戻しやすくなります。verify.shは、そのタスクの合格条件です。

#!/usr/bin/env bash
set -euo pipefail

npm ci
npm run typecheck
npm test -- --reporter=json --outputFile=reports/vitest.json
npx playwright test --reporter=json --output=reports/playwright

実際のrepoでは、npm test -- --reporter=json --outputFile=...のようなオプションがそのまま通らない場合があります。Vitestのreporterやoutput設定、Playwrightのreporterやoutput設定は、公式Docsに沿ってプロジェクトの設定へ合わせます。

runs配下にツール別ログを残す

AIツールを実行したら、runs/配下に結果を保存します。

runs/2026-05-31-codex-bugfix-date-format/
  meta.json
  prompt.md
  transcript.md
  commands.log
  test-before.log
  test-after.log
  diff.patch
  review.md

meta.jsonには、後で比較したい前提を入れます。

{
  "run_date": "2026-05-31",
  "task": "bugfix-date-format",
  "tool": "Codex CLI",
  "tool_version": "0.135.0",
  "model": "gpt-5.5",
  "plan": "契約プラン名または不明",
  "repository_commit": "abc1234",
  "network": "disabled",
  "permission": "workspace-write-with-approval",
  "started_at": "2026-05-31T13:20:00+09:00",
  "ended_at": "2026-05-31T13:42:00+09:00",
  "cost_note": "API課金なし、または管理画面の使用量で別途確認"
}

料金はツールごとに単位が違います。token、request、credit、subscription、agent compute、Actions minutesのように揺れます。最初から完全な円換算を狙うより、「どの画面やログから使用量を確認したか」を残すほうが続きます。

タスク1 Bugfix

原因特定

失敗ログから対象関数へたどり着けるか。

最小差分

無関係な整形や外部依存追加を避けられるか。

回帰防止

既存テストを壊さず、必要なテストを追加できるか。

Bugfixは速さより、原因と差分の説明がレビューしやすいかを重視します。

Bugfixタスクは、AIコーディングツールの基本性能を見る入口です。おすすめは、壊れた単体テストを1つ用意し、原因が1ファイルか2ファイルに閉じる程度の不具合にすることです。

例として、日付フォーマットの仕様を考えます。

# task.md

注文一覧の表示で、`createdAt` がUTCのまま `2026-05-31T04:00:00.000Z` と表示されている。
日本語UIでは `2026/05/31 13:00` の形式で表示したい。

制約:

- `src/lib/formatDate.ts` と関連テストだけを変更してよい。
- 外部ライブラリを追加しない。
- 既存の英語向けフォーマット関数は壊さない。
- `npm run typecheck` と `npm test` を通す。

このタスクで見るのは、正解に近いコードを書けるかだけではありません。既存関数を壊さずに直したか、タイムゾーンを雑に扱っていないか、テストを追加したか、差分が小さいかを見ます。

評価基準

評価項目	見ること
原因特定	失敗ログから対象関数へたどり着いたか
差分	変更が必要範囲に収まったか
テスト	既存テストを通し、回帰テストを追加したか
説明	変更理由と未検証範囲を報告したか
安全性	外部ライブラリ追加や無関係な整形を避けたか

タスク2 Feature Add

1. 1仕様

   既存機能と併用する条件を明確にします。

2. 2実装

   既存の状態管理、型、命名規則に合わせます。

3. 3テスト

   happy pathだけでなく既存機能との併用を確認します。

4. 4レビュー

   変更理由と未検証範囲を残します。

機能が動くだけでなく、チームが保守できる差分かを見ます。

Feature Addは、既存設計の理解を見ます。新機能といっても、最初は小さくします。たとえば、一覧画面へ「statusで絞り込む」機能を追加する程度です。

# task.md

注文一覧にstatusフィルタを追加する。
`all`、`paid`、`pending`、`failed`を切り替えられるようにし、既存の検索条件と併用できるようにする。

合格条件:

- 既存の検索機能が壊れない。
- statusが未指定のときは全件を表示する。
- `paid`を選ぶと支払い済みだけが表示される。
- unit testを追加する。
- UI文言は既存の日本語表記に合わせる。

Feature Addでありがちな失敗は、動くコードは出るが設計に合わないことです。状態管理の置き場所がずれる、既存コンポーネントの責務を崩す、URL queryに載せるべき状態をローカルstateだけにする、テストがhappy pathだけになる、といった問題が起きます。

既存設計に沿っているかを見る

レビューでは、次の観点を入れます。

• 既存の命名規則に沿っているか
• フィルタ条件の型が明確か
• API、UI、テストの責務が分かれているか
• 既存テストの意図を壊していないか
• 失敗時にユーザーへ不自然な状態を見せないか

AIツールは、局所的な実装を早く出す一方で、既存設計の小さな癖を見落とすことがあります。Feature Addでは、速度よりも「レビューしたくなる差分か」を重く見ます。

タスク3 Test Repair

1. 1失敗ログ

   test title、error、trace、関連差分を渡します。

2. 2仕様確認

   UIや認証フローが変わってよい範囲を決めます。

3. 3修正

   壊れやすいselectorだけでなく、テスト設計を見直します。

4. 4再実行

   同じPlaywrightコマンドで確認します。

Test Repairでは、アプリ本体の誤修正を避けることが重要です。

Test Repairは、実務でかなり重要です。AIツールにE2E失敗ログを渡し、アプリ仕様を変えずにテストを直せるかを見ます。

Playwrightの公式CLIでは、npx playwright test、--project、--workers、--reporter、--traceなどのオプションが整理されています。Benchmark Kitでは、E2Eの再現性を上げるため、必要に応じてworker数、project、trace保存を固定します。

npx playwright test tests/login.spec.ts \
  --project=chromium \
  --workers=1 \
  --reporter=json \
  --trace=retain-on-failure

Test Repairで避けたいのは、テストを通すためにアプリ本体の仕様を変えることです。ボタンの文言が変わっただけならlocatorを直せばよいかもしれません。しかし、認証フローが変わったなら、テストだけではなく仕様変更の確認が必要です。

失敗ログに入れる情報

• 実行コマンド
• 失敗したtest title
• エラーメッセージ
• traceやreportの保存場所
• 直前の関連差分
• アプリ仕様として変わってよい範囲

Playwrightのbest practicesでは、ユーザーに見える振る舞いに近いlocatorや独立したテスト設計が重視されています。Benchmark Kitでも、壊れやすいselectorをAIに直させるだけでなく、テストそのものが安定した設計になっているかをレビューします。

実行コマンドとログ保存

項目	内容	見方
test-before.log	修正前	初期失敗を再現できたか。
test-after.log	修正後	同じ条件で検証したか。
diff.patch	差分	レビュー対象を固定します。
review.md	判断	未検証項目と人間判断を残します。

ログが残っていない成功は、次の比較やレビューに使いにくくなります。

ローカル実行の基本は、タスクごとのverify.shに寄せます。

git checkout main
git checkout -b bench/codex-bugfix-date-format
git apply tasks/bugfix-date-format/seed.patch

./tasks/bugfix-date-format/verify.sh | tee runs/current/test-before.log

この時点では失敗してよいです。失敗ログをAIツールへ渡し、修正後に同じコマンドを再実行します。

./tasks/bugfix-date-format/verify.sh | tee runs/current/test-after.log
git diff -- . ':!runs' > runs/current/diff.patch

runs/をrepoに含めるかどうかはチーム次第です。公開repoなら、ログに秘密情報や内部URLが入らないように注意します。社内repoでは、artifact保管先、保持期間、アクセス権を決めておきます。

GitHub Actionsで同じゲートを再実行する

ローカルで通っても、CIで落ちることはあります。GitHub Actionsを使う場合、workflowのpermissionsを必要最小限にし、テストログをartifactとして保存します。

name: ai-coding-benchmark

on:
  workflow_dispatch:
    inputs:
      task:
        description: "Benchmark task name"
        required: true
        type: string

permissions:
  contents: read

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run typecheck
      - run: npm test -- --reporter=json --outputFile=reports/vitest.json
      - run: npx playwright test --reporter=json --trace=retain-on-failure
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: benchmark-reports
          path: reports/

GitHub Actionsのworkflow syntaxは更新されるため、実際に使うときは公式Docsでpermissions、jobs、steps、usesの現在の書き方を確認してください。

評価表

項目	内容	見方
完了	pass / partial / fail	すべての検証コマンドが通ったか。
差分量	files / lines	レビュー負荷を見ます。
レビュー容易性	1から5	変更理由と未検証範囲が明確か。
安全性	1から5	秘密情報や危険操作を避けたか。
コスト	使用量メモ	確認方法も残します。

点数は入口です。採用判断には失敗条件のコメントが必要です。

評価は、点数だけで終わらせないほうが役に立ちます。おすすめは、定量と定性を混ぜた表です。

評価軸	記録する値	コメント例
完了	pass / partial / fail	すべての検証コマンドが通ったか
初速	分単位	最初の有効差分までの時間
テスト	pass数、fail数	unit、typecheck、E2Eを分ける
差分量	files changed、lines changed	大きいほど悪いとは限らないがレビュー負荷を見る
コード理解	1から5	既存設計に沿ったか
テスト修正	1から5	テストを弱めずに直したか
レビュー容易性	1から5	変更理由、未検証範囲、ログが明確か
安全性	1から5	秘密情報、外部通信、危険操作を避けたか
コスト	金額または使用量メモ	planや使用量画面の確認方法も残す

採点例は次のように残します。

Review memo:

- Result: partial
- Passed: typecheck, unit test
- Failed: Playwright login flow
- Diff: 4 files, +82/-21
- Good: 既存のformatterを再利用し、テストを追加した
- Concern: E2E失敗を未解決のまま完了扱いにした
- Security: 外部通信なし、秘密情報参照なし
- Cost: 管理画面で使用量未確認。次回からrun後に記録する
- Human decision: このままmergeしない。E2E原因を追加調査する

このmemoが残っていると、チーム内で「速かったけど危なかった」「遅かったがレビューしやすかった」を話しやすくなります。

失敗点とハマりどころ

テスト不足

通ったように見えても壊れた箇所を見逃します。

曖昧なIssue

実装力ではなく質問力の比較になりがちです。

不安定なE2E

外部API、時刻、並列実行で結果がぶれます。

広すぎる権限

成功しても説明責任が重くなります。

AIツールを走らせる前に、合格条件そのものを安定させます。

テストが薄いとAIツールの評価にならない

テストが少ないrepoでは、AIツールが通したように見えても、壊れている可能性を見逃します。Benchmark Kitの最初の整備は、AIツールを走らせることではなく、合格条件を作ることです。

Issueが曖昧だと会話力の比較になる

曖昧なIssueで試すと、ツールの実装力より、質問力や補完力の比較になります。それ自体も評価対象にできますが、最初のKitでは入力を固定したほうがよいです。

E2Eが不安定だと結果がぶれる

E2Eテストは、外部API、時刻、ネットワーク、並列実行、認証状態の影響を受けます。Playwrightではworkers、project、trace、reporterを固定し、必要ならmockやtest dataを整えます。AIツール比較の前に、テストが単独で再現するかを確認します。

権限が広いと成功しても採用しにくい

AIツールに外部通信、任意コマンド、push、PR作成まで許すと、作業は進みやすくなります。一方で、何をしたかの説明責任が重くなります。最初のBenchmark Kitでは、read-only調査、workspace内の編集、指定コマンド実行までに抑え、人間が差分を確認してからCIへ進める形が扱いやすいです。

モデル更新で再現性が崩れる

AIツールはモデルや内部プロンプトが更新されます。1か月後に同じ結果が出る保証はありません。だからこそ、run date、tool version、model、plan、入力prompt、diff、test logを残します。再現性は「同じ結果を永遠に出す」ではなく、「何を比較したかを後から説明できる」ことだと考えます。

実務で使うなら

1. 1

   小さなサンプルブランチを作ります。

2. 2

   秘密情報を除いたfixtureへ置き換えます。

3. 3

   3タスクとverify.shを用意します。

4. 4

   1つのAIツールで試し、ログ形式を整えます。

5. 5

   別ツールで同じ条件を再実行します。

いきなり全社導入せず、採用できない失敗条件を先に決めます。

最初の1週間は、次の順番がおすすめです。

1. 既存repoから小さなサンプルブランチを作る
2. 秘密情報、顧客データ、社内固有ログを除いたfixtureへ置き換える
3. Bugfix、Feature Add、Test Repairを1件ずつ作る
4. verify.shを作り、人間だけで実行して失敗と成功を確認する
5. 1つのAIツールで試し、ログ形式を整える
6. 別のAIツールで同じタスクを試す
7. 点数より、採用できない失敗条件をチームで決める

この流れは、AIコーディングエージェント導入そのものの前段です。権限や禁止操作を文書化する場合は、公開済み記事のClaude Codeに依存更新を任せる前に：権限とテストゲートの置き方や、MCP更新時の確認観点を扱ったMCP更新で壊さないための確認手順も参考になります。

Benchmark Kitを運用に入れるなら、AGENTS.mdやツール別ルールに次のような短い指示を書きます。

# AI Benchmark Rules

- 指定されたtask.md、constraints.md、verify.shだけを前提に作業する。
- 秘密情報、外部サービス、本番環境へアクセスしない。
- 変更前後で同じverify.shを実行する。
- 実行したコマンド、結果、未検証項目、差分の理由をreview.mdに残す。
- テストを弱める変更、skip、only、snapshot無断更新は人間承認へ戻す。

AI Coding Benchmark Kitをテンプレート化しておくと、次回から比較記事、社内選定、ツール更新時の再検証に使い回せます。更新通知や検証テンプレートの改善を追いたい場合は、ニュースレターで新しい検証記事を確認してください。

セキュリティ・コスト注意

項目	内容	見方
APIキー	含めない	.envやsecretを入力やログに入れません。
外部通信	無効または承認制	初回比較では範囲を限定します。
Git操作	local branchまで	pushやforce操作は人間承認にします。
料金	runごとに記録	plan、実行時間、使用量の確認方法を残します。

よく直った成功例だけでなく、止め方と説明責任まで設計します。

Benchmark Kitは、AIツールに実務repoへ触れさせる前の練習台です。だからこそ、最初から安全側に倒します。

論点	方針
APIキー	.envやsecretをAI入力、ログ、artifactに含めない
非公開コード	公開記事や外部共有には、再現用サンプルへ置き換える
外部通信	初回比較では無効または承認制にする
Git操作	git diffとlocal branchまで。pushやforce操作は人間承認にする
テストログ	個人情報、社内URL、tokenが混ざらないか確認する
料金	plan名、使用量画面、実行時間、再試行回数をrunごとに残す
データ保持	各ツールの利用規約、データ利用、保持、学習利用を導入前に確認する

特に、AIツール比較では「よく直してくれた」成功体験に寄りがちです。実務導入では、失敗時の止め方、ログの消し方、秘密情報が出たときの対応、利用量が上振れしたときの予算管理まで決めておきます。

FAQ

小規模repo

最初は小さいほうが原因を切り分けやすくなります。

E2Eなし

BugfixとFeature Addから始め、必要に応じて追加します。

点数化

点数だけでなく失敗条件とレビュー負荷を残します。

公開repo

社内情報を除いたサンプルだけを公開対象にします。

Benchmark Kitは小さく始め、比較条件を育てていくほうが続きます。

小さなrepoでもBenchmark Kitを作る意味はありますか

あります。むしろ最初は小さいほうがよいです。大きなrepoでいきなり比較すると、AIツールの差なのか、repoの複雑さなのか、テスト不足なのかが分かりにくくなります。

E2Eテストがない場合はどうしますか

まずはBugfixとFeature Addだけで始めて構いません。ただし、UIや業務フローを任せたいなら、最低1本はE2Eまたは統合テストを用意したほうが判断しやすくなります。

点数化して1位を決めてもよいですか

社内判断の便宜として点数化するのはありです。ただし、点数だけで採用を決めるのは危険です。失敗条件、レビュー負荷、権限設計、コスト上振れをコメントで残してください。

クラウド型エージェントはどう比べますか

同じIssue、同じbranch、同じCIゲートで比べます。ただし、ローカルCLIとクラウド型では実行場所、権限、ログ取得方法が違います。meta.jsonに実行場所と権限を必ず残します。

Benchmark Kitを公開repoに置いてもよいですか

公開用に作ったサンプルなら問題ありません。社内repoから切り出す場合は、顧客名、内部URL、API仕様、ログ、認証情報、ビジネスロジックの漏えいがないか確認します。迷う場合は、公開しない前提で運用してください。

次に読むなら

参照した主な情報源

• Playwright Command line: https://playwright.dev/docs/test-cli
• Playwright Best Practices: https://playwright.dev/docs/best-practices
• Vitest Reporters: https://main.vitest.dev/guide/reporters
• Vitest Coverage config: https://main.vitest.dev/config/coverage
• GitHub Actions Workflow syntax: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
• OpenAI Codex AGENTS.md docs: https://github.com/openai/codex/blob/main/docs/agents_md.md

更新履歴

1. 2026年5月31日

   初版作成。公式情報とローカルバージョン確認を反映しました。

ツール仕様やnpmバージョンは変わるため、導入時は最新情報を確認してください。

日付	内容
2026年5月31日	初版作成。Playwright、Vitest、GitHub Actions、Codex AGENTS.mdの公式情報とローカルバージョン確認を反映。