こんにちは、みねです。
「AIを使ったら生産性が上がった気がする」——この"気がする"を、どうやって測定可能な改善に変えるか。これが今回のテーマです。
この記事でできるようになること
- SWE-bench Verifiedが「何を測っているか」を理解し、自社の文脈に翻訳できる
- 自社リポジトリで「mini SWE-bench」を構築し、AIワーカーの評価を回せる
- Lead time / CI pass rate / Rework count の3指標で改善を追跡できる
対象読者
- AIコーディングツール（Copilot、Cursor、Claude Code、Gemini CLI等）を業務で試している
- 「速くなった」以外の指標で成果を語りたい
- チームへのAI導入を検討中で、説得材料が欲しい
この記事でやらないこと
- 特定ツールのセットアップ手順（ツール比較はシリーズ5本目で扱います）
- 学術的なベンチマーク設計の詳細
1. SWE-bench Verifiedは何を測っているのか
SWE-benchは、GitHubの実際のIssue/PRから抽出した「バグ修正タスク」でLLMの能力を評価するベンチマークです。
1.1 測っている能力
Epoch AIの分析によると、SWE-bench Verifiedは以下を測定しています：
| 能力 | 具体的な内容 |
|---|---|
| コード理解 | 既存コードベースの構造を把握する |
| 問題特定 | Issueの記述から修正すべき箇所を特定する |
| コード生成 | 修正パッチを正確に生成する |
| テスト通過 | 既存テストを壊さず、回帰テストを通す |
1.2 現実とのズレ
ただし、SWE-benchには現実の開発とズレもあります：
[!WARNING] SWE-benchが測らないこと
- 仕様の曖昧さへの対処（Issueが完璧に書かれている前提）
- 設計判断（「どう直すか」の選択肢が複数ある場合）
- チームとのコミュニケーション（レビュー対応、質問）
このズレを理解した上で、「使える部分」を自社に持ち込みます。
2. 自社の「mini SWE-bench」を作る
完璧なベンチマークを目指さない。最小限の観測ができる仕組みを作ります。
2.1 タスクの選び方
text
┌─────────────────────────────────────────────────────┐
│ AIワーカーに向くタスク │
├─────────────────────────────────────────────────────┤
│ ✅ バグ修正 + 回帰テスト追加 │
│ ✅ 依存ライブラリの minor/patch 更新 │
│ ✅ リファクタリング（関数抽出、命名変更） │
│ ✅ ドキュメント更新（コードとの整合性チェック付き） │
├─────────────────────────────────────────────────────┤
│ AIワーカーに向かないタスク │
├─────────────────────────────────────────────────────┤
│ ❌ 新規アーキテクチャ設計 │
│ ❌ セキュリティ要件が絡む変更 │
│ ❌ データベーススキーマ変更 │
│ ❌ 複数リポジトリにまたがる変更 │
└─────────────────────────────────────────────────────┘
2.2 実験プロトコル
bash
# ディレクトリ構成
ai/
├── plan.md # タスク計画（AIが生成、人間がレビュー）
├── handoff/ # AIからAI or AI/人間への引き継ぎ
│ └── 001.md # 各タスクの引き継ぎログ
└── metrics.md # KPI記録
metrics.md の例:
markdown
# Metrics Log
| タスクID | タイプ | 開始 | 終了 | CI初回 | Rework | レビュー指摘 |
| :------- | :--------- | :---- | :---- | :----- | :----- | :----------- |
| #123 | bugfix | 10:00 | 11:30 | PASS | 1 | 2 |
| #124 | dep-update | 14:00 | 14:45 | FAIL | 2 | 1 |
2.3 禁止領域の設定
[!CAUTION] AIワーカーが触ってはいけない領域を明示する
markdown
# ai/rules.md
## 禁止領域（AIは編集禁止）
- `secrets/`, `.env*`
- `database/migrations/`（本番スキーマ）
- `*.lock` ファイル
## 変更上限
- 最大5ファイル / 300行まで
- 超える場合は分割を提案してタスクを中断
3. スコアの読み方
速度だけを見ると「汚い成功」を見逃します。
3.1 KPIの優先順位
text
1. CI pass rate（品質ゲート）
└─ 初回でCIが通らないなら、速さに意味がない
2. Rework count（手戻り）
└─ 1回で終わるか、何度もやり直すか
3. Lead time（速度）
└─ 上2つが合格なら、ここで差がつく
4. Review burden（レビュー負荷）
└─ 人間の時間をどれだけ奪うか
3.2 目標値の例
| KPI | 初期目標 | 3ヶ月後目標 |
|---|---|---|
| CI pass rate | 60% | 80% |
| Rework count | 3回以下 | 2回以下 |
| Lead time | 現状比 -10% | 現状比 -20% |
| Review burden | 5件以下 | 3件以下 |
4. 最小テンプレ（Root Planner → Worker）
text
┌─────────────────┐
│ Root Planner │ ← 人間 or 上位AI
│ (計画・分解) │
└───────┬─────────┘
│ handoff.md
▼
┌─────────────────┐
│ Worker │ ← AIワーカー
│ (実装・テスト) │
└───────┬─────────┘
│ metrics.md
▼
┌─────────────────┐
│ CI / Review │ ← 自動 + 人間
└─────────────────┘
handoff.md のテンプレート
markdown
# Task Handoff: #123 Fix login timeout
## Context
- Issue: ログインが60秒でタイムアウトする
- 原因の仮説: API側のkeep-alive設定が短い
## Scope
- 変更対象: `src/api/auth.ts`
- テスト追加: `tests/auth.test.ts`
- 禁止: データベース変更、環境変数変更
## Success Criteria
- [ ] タイムアウトが300秒に延長される
- [ ] 既存テストが全パス
- [ ] 新規テストでタイムアウト動作を確認
## Constraints
- 最大ファイル数: 3
- 最大行数: 100
5. よくある落とし穴
5.1 汚い成功：テスト逃げ
AIがテストをスキップして「動いた」と報告するケース
対策: CIで必須テストカバレッジを設定、新規コードには最低限のテスト追加をルール化
5.2 仕様誤解
Issueの曖昧な部分を勝手に解釈して実装するケース
対策: handoff.mdに「確認済み仕様」と「未確認・仮定」を明記させる
5.3 局所最適
目の前のタスクだけ解決し、全体の整合性を壊すケース
対策: 「影響範囲」をhandoffに含め、レビューで確認
今日から一歩
まずは今日、ai/ ディレクトリを作ってください。
bash
mkdir -p ai/handoff
touch ai/plan.md ai/metrics.md ai/rules.md
そして、1つだけタスクを選んでください。「バグ修正 + テスト追加」か「依存更新（minor）」がおすすめです。
1週間後、metrics.mdを見返してください。数字が見えるだけで、議論の質が変わります。
シリーズ記事
- AI自動運転を"ベンチマーク思考"で検証する（本記事）
- MCPで"運転席と作業者"を分離して事故率を下げる
- LLM/AI開発のObservabilityを"eBPF × OTel"で最小実装する
- WASM Component Modelで"安全な拡張"を作る
- 2026年の「AIコーディング自動運転」最前線
