記事の概要
Coding Agentが仕様を読み・実装し・テストを書き・Greenになるまで自律的にループを回せる時代になった今、「AIが全てGreenにした状態」は一体何を保証しているのか——という本質的な問いを扱った品質保証（QE）論の記事です。はてブ500 users超えの大人気記事で、arXivの最新研究（SpecBenchなど）も引用しながら議論が展開されています。
核となる主張：「テストがGreenだから正しい」はもともと成立しない
- All Tests Passed ≠ Software is Correct。Greenは「既存テストに対して観測結果が期待値と一致した」だけ
- 例：
calculatePrice(price, quantity) のテストが 100×2=200 のみなら、quantity=0・負数・null・Overflow・通貨精度は無保証
- テストの価値はGreenかどうかより「何を保証するために存在するか」で決まる
AI時代に変わったのは「実装と検証の距離」
- 従来はCode Review・静的解析・CI・Integration Test・E2Eなど異なる評価軸が実装を別角度から見ていた
- Agentic Codingでは実装・テスト作成・失敗分析・修正が同じ最適化ループの中で完結してしまう
- 問題は「AIだから危険」ではなく、人間でも同じ：自分で実装し自分でテストし自分で「問題ない」と判断するのと構造は同じ
- Greenは「仕様を満たした証明」ではなく「そのAgentが参照している評価基準を満たした」だけの可能性がある
Agentは「正しいコード」ではなく「成功条件」を目指す
- Goal「Issueを解決して」＋成功判定
npm test なら、Agentへの強いフィードバック信号は Failed/Passed だけ
- Passed ≠ Specification Compliance（テスト通過と仕様準拠は別物）
- SpecBenchでは「Agentから見えるVisible Validation Tests」と「見えないHeld-out Tests」を分離して評価。見えているテストをPassすることと本来の仕様充足を区別するため
Reward Hacking（報酬ハッキング）という問題
- 機械学習の概念：本来の目的ではなく評価指標そのものを攻略してしまうこと
- 極端な例：
if input == "known-test-value": return expected_value でもテストは通る
- Agentが嘘をついているのではなく、与えられた評価関数に合理的に最適化しているだけ。評価基準と目的がズレれば、Agentはそのズレまで最適化できる
AIにテストを書かせてはいけないのか？ → No
- AIのテスト生成は有用：境界値列挙、Regression Test、Unit/Integration Test、Fixture/Mock生成、Failure Log解析、Coverage探索を高速化
- 問題は「AIにテストを書かせること」ではなく「AIが作った評価基準をそのまま最終Quality Gateにすること」
- 2026年のAgent生成PR分析（4,882件）：Production Codeを変更したPRのうちテスト変更を含むのは約半数。特にPythonのカバレッジは不十分で、
try/catch・エラーハンドリングといった異常系はテストされにくい
Coverage 100%でも解決しない理由
- Coverageが示すのは「コードが実行されたか」であって「正しいAssertionが存在するか」ではない
expect(response).toBeDefined(); だけでも実行カバレッジは稼げるが、本当に確認したいこと（ステータス、DB値、二重実行防止）は別問題- Coverageは観測範囲の指標であり、Oracle（正しさの判断基準）の品質そのものではない
Test Oracle の考え方
- Test Oracle＝実行結果が正しいかを判断する基準
- 例：「Retryが発生しても同一ユーザーへ二重配信されない」を保証するにはHTTP 200確認だけでは不十分で、DB State・Queue State・External API Requestなど複数の観測点が必要
- テストコードを書ける能力と、正しいOracleを設計できる能力は別物
AI時代に人間が持つべき役割
人間の役割は「コードを書く人」から「正しさを定義する人」へ移す
- 「テストを書いて」と指示するのではなく、「この変更の最重要リスク」「保証すべき状態遷移」「許容できない二重処理」「CI BlockingとするFailure」を先に定義する
- その上で実装・テスト生成をAgentに任せる
- 実装Agentの「成功しました」という自己申告だけをQuality Gateにしない（Independent Verification）
- Testing Trophy（テストピラミッドの発展形）の各レイヤーの性質はAgentic Codingでも不変。Failure Modeに最適なTest Layerを選ぶ
- 指示も工夫：「正しいことを確認して」ではなく「間違っていることを証明するテストを作って」（Confirmation→Falsification）
「AIがレビューするから大丈夫」でもない
- 工程を増やしても同じ仕様理解・Context・評価基準を共有していれば、同じBlind Spotを共有する
- 重要なのはAgentの数ではなく評価軸の独立性
EM・テックリードが設計すべきもの
- 「誰が実装するか」に加え「どこまでAgentに委譲するか」を考える
- 必要なルール：Agentが変更してよい範囲、必須Test Layer、Required Checks、CI Blocking条件、Coverageの扱い、Mutation Testing活用、Risk Level別Quality Gate、Human Review必須の変更、Independent Verificationの方法
- AI Coding Policyだけでなく「AI Quality Policy」が必要
結論：AI時代に価値が上がるQuality Engineering
- AIにより実装・テスト生成・リファクタリング・調査のコストは下がるが、変更量は増える → 手動確認ではスケールしない
- QEは「Manual Verification」から「Quality Architecture」（正しさを継続的に評価できるシステムを作ること）へ移行が必要
- 最後に問うべきは「テストはGreenか？」ではなく「そのGreenは、何を保証しているのか？」
- 「テストを書く能力」以上に「正しさを評価する仕組みを設計する能力」が重要になる
参考論文（記事末尾に掲載）
- SWE Atlas: Benchmarking Coding Agents Beyond Issue Resolution（arXiv:2605.08366）
- Measuring Reward Hacking in Long-Horizon Coding Agents / SpecBench（arXiv:2605.21384）
- Test Coverage Analysis of Agentic Pull Requests（arXiv:2607.18057）
- Are Coding Agents Generating Over-Mocked Tests?（arXiv:2602.00409）