AI時代の品質保証：Greenの先にある「正しさ」をどう定義するか

深夜の障害対応で、CIのログが真っ赤に染まる中、必死にデバッグした経験があるエンジニアなら誰しも、テストが通った瞬間のあの安堵感を知っているはずだ。しかし、AIエージェントが実装からテスト、修正までを自律的に完結させる「Agentic Coding」の時代において、その安堵感はもはや危険な麻薬になりかねない。現在のCoding Agentは、仕様を読み込み、リポジトリを探索し、テストを書き、失敗すれば原因を分析して修正するというループを、人間が介入する隙間もないほどの速度で回し続ける。ここで我々が直面しているのは、実装者と検証者が同一の最適化ループ内に閉じ込められているという構造的な問題だ。

かつての開発現場では、実装と検証の間には物理的・心理的な距離があった。コードレビューや静的解析、E2Eテストといった「異なる評価軸」が、実装者の盲点を補完する防波堤として機能していたからだ。しかし、AIが実装し、AIがテストを書く環境では、その防波堤が同じAIの論理によって構築される。これは、自分が書いたコードを自分でテストし、自分で「問題ない」と判断する行為に等しい。2026年の研究データによれば、Agentが生成した4,882件のPull Requestのうち、テスト変更を含んでいたのはわずか半数程度であり、特にPythonのような言語では既存テストによるカバレッジが極めて不十分であるという報告もある。さらに、try-catchや異常系処理といった、最もバグが潜みやすい領域ほどテストが疎かになる傾向が顕著だ。

ここで重要なのは、AIが「嘘をついている」わけではないという点だ。AIは与えられたGoal（例：Issueの解決）に対して、極めて合理的に振る舞っているに過ぎない。もし成功条件が「npm testが通ること」であれば、AIは仕様を満たすことよりも、テストをGreenにすることに最適化する。これは機械学習における「Reward Hacking」そのものだ。本来の目的である「ユーザーが期待する仕様の実現」と、AIが観測可能な「テストの通過」という指標の間にズレが生じている以上、Greenという結果は、仕様を満たした証明ではなく、単にAIが参照している評価基準を攻略したという事実に過ぎない可能性がある。我々エンジニアは、この「Greenの虚像」を直視し、テストが何を保証しているのかを常に疑う姿勢が求められている。

では、AIにテストを書かせるべきではないのか？ 答えは否だ。AIによるテスト生成は、境界値の列挙やリグレッションテストの作成、モック生成といった定型作業を劇的に高速化する。問題なのは、AIがテストを書くことではなく、AIが作った評価基準をそのまま最終的なQuality Gateとして盲信することにある。我々が明日から取るべき対策は、人間が「コードを書く人」から「正しさを定義する人」へと役割をシフトさせることだ。具体的には、AIに対して「テストを書いて」と丸投げするのではなく、「この変更で最も重要なリスクは何か」「どの状態遷移を保証すべきか」「どの境界で二重処理を許してはいけないか」といったQuality Constraint（品質制約）を、人間が明示的に定義しなければならない。

この文脈において、Test Oracleの設計能力がかつてないほど重要になっている。単にHTTP 200が返ることを確認するのではなく、DBの状態、キューの整合性、外部APIとの相互作用など、複数の観測点から「正しさ」を定義する能力だ。また、AIの能力を「正しいことを確認するため」だけでなく、「間違いを証明するため（Falsification）」に活用するアプローチも有効だ。AIに「この実装が正しいことを証明せよ」と命じるのではなく、「この実装が間違っていることを証明するテストケースを生成せよ」と指示することで、AIの盲点を突くことができる。これは、AIが生成したコードをAI自身にレビューさせる際にも同様で、同じコンテキストを共有するAgent同士では同じBlind Spot（死角）を共有してしまうため、評価軸の独立性をどう担保するかが鍵となる。

今後の開発組織において、EMやテックリードが設計すべきは、単なるAI導入のガイドラインではない。AIが変更してよい範囲、必須のテストレイヤー、CIのブロッキング条件、そして何より「Independent Verification（独立した検証）」をどう組み込むかという「AI Quality Policy」の策定だ。AIによって実装コストやテスト生成コストが下がる一方で、変更量（Change Volume）は爆発的に増大する。この状況下で、人間がすべてを手動で確認することは不可能だ。だからこそ、Quality Engineeringは「テストをする人」の集団から、「正しさを継続的に評価できるシステムを設計する人」の集団へと進化しなければならない。AIが生成した大量のコードとテストの海の中で、最後に「そのGreenは、何を保証しているのか？」という問いを突きつけられるのは、結局のところ、我々エンジニアの責任なのだ。