検証：コードが仕様に忠実であることを保証する
前章のOKR事例では、specが2回の反復修正を経て、13件のacceptance criteriaと5件のbusiness rulesがすべて明確に定義されました。Agentはこのspecに基づいて12個のバックエンドファイルと4個のフロントエンドファイルを生成しました。コンプライアンスチェックの結果は26/28 PASSでした。
漏れた2件は偶然ではありません。BR-002は「各目標に最大5つのKR」を要求していましたが、AgentはフロントエンドでElement UIの提示を実装したものの、バックエンドにServiceExceptionのバリデーションを追加していませんでした。フロントエンドを迂回してAPIを直接呼び出せば、制限を突破できてしまいます。BR-004は「新規作成ページを開いた際に現在の四半期をデフォルト選択する」ことを要求していましたが、Agentはこのデフォルト値のロジックを実装していませんでした。
この2つの問題には共通の特徴があります。コード自体はよく書かれており、インターフェース設計は合理的で、命名規則も正しく、テストも通ります。コード品質の問題ではなく、意図の欠落です。Specに記述があるのに、コードが実装していないのです。
仕様が解決するのは「Agentに何をすべきか伝える」こと。検証が解決するのは「Agentが本当にそれを実行したか」ということです。
意図の逸脱：既存ツールの死角
この問題を発見したのは私たちだけではありません。Anthropicはharness設計に関する一連の記事で、生成と評価を分離することが品質管理における最も効果的なレバーであると明確に指摘しています。業界のコンセンサスはすでに形成されています。検証はharness engineeringにおける最も重要な要素の一つです。
各フレームワークはこの方向で多くの試みを行ってきました。BMADは3層の情報非対称なcode reviewを設計し、異なるreviewerが異なる範囲の情報を見ることで確認バイアスを軽減しています。Spec Kitはconstitution統治と10種類の曖昧性検出を用いて、spec段階で品質問題を捕捉します。OpenAIとAnthropicはいずれも、複数Agentによる並列code reviewシステムとevalフレームワークを公開しています。コミュニティでもTDD、Trophy Testing、対抗的reviewの議論が絶えません。
実際のプロジェクトでこれらの検証ツールを大規模に使用した経験があれば、あることに気づくはずです。コードはすべてのlint、すべてのユニットテスト、すべての対抗的reviewを通過できますが、実装された機能はspecが述べていることとは別物であり得るのです。
null checkの欠如、命名の不規則、セキュリティ脆弱性といったコード品質の問題はAI自身が発見し修正できます。本当に検出が困難なのは意図の乖離です。Specが求めるAを、コードがBとして実装してしまう。上述のBR-002がまさにこの種の問題です。コードはよく書かれていますが、specにある1つのbusiness ruleが欠落しています。specを参照しないreviewでは発見できません。
2026年3月に発表されたTDAD論文は定量的な証拠を提供しています。研究者は、Agentに「TDDのフローに従ってください」という抽象的なプロセス指示を与えると、回帰率が6.08%から9.94%に上昇することを発見しました。一方、ツールでspecを分析し、具体的にどのテストをチェックすべきかをAgentに伝えると、回帰率は1.82%に低下しました。プロセス指示は答えではなく、specのコンテキストこそが鍵です。
これらのツールが機能しない理由は同じです。参照基準がspec ではなくコード自体であるということです。「このコードにバグがあるか」には答えられますが、「このコードはspecが要求したものか」には答えられません。BR-002のバックエンドバリデーション欠如は、コードベースの検査では発見できません。コード自体にバグはなく、specが要求する機能が欠けているだけだからです。
検証のアンカーは仕様である
「コードがspecの要求通りか」に答えるには、コード以外の参照基準が必要です。その参照基準が仕様です。検証のsingle source of truthは仕様であり、コードではありません。
すべての検証行為は1つの問いに答えています。このコードとドキュメントが述べていることは一致しているか。テストは「specが述べた振る舞いをコードが実装しているか」を検証するものであり、「コードが正しいか」を検証するものではありません。Code reviewは「コードとspecは一致しているか」を問うものであり、「コードの品質は良いか」を問うものではありません。Specから離れてreviewを行うと、「コード構造は明確です。例外処理の追加をお勧めします」のような正確ではあるが無意味なフィードバックしか得られません。コードが仕様に忠実かという問いに答えていないからです。
これが、仕様の章が検証の章の前にある理由でもあります。良いspecがなければ、検証にはアンカーがありません。
検証は前倒し、プロセス中、モジュール化でなければならない
検証基盤はコーディングの前に整備され、実行プロセス中に継続的に稼働し、モジュール単位で分割される必要があります。この結論はAgentの2つの構造的特性から導かれます。
Agentは実行中にドリフトします。仕様の章ですでにこの概念を確立しました。Agentの出力はcontextの蓄積とともに偏移し、小さなずれが後続のステップで累積します。コード実装段階では、10番目のステップのコードが1番目のステップで参照したspecからすでに乖離している可能性があります。すべてが完了してから検証すると、数十の失敗したテストに直面し、それぞれが異なる問題を指し示すため、修正コストはプロセス中の修正よりはるかに高くなります。したがって検証はプロセス中に行うべきであり、事後に行うものではありません。
Agentのcontext window容量には限りがあります。この制約はコーディングだけでなく検証にも適用されます。Agentに一度に2000行のコードを書かせ、別のAgentにreviewさせると、review側のAgentはspecの内容と2000行のコード実装を同時に理解し、両者が一致しているか判断する必要があります。これは有効な処理範囲を超えています。結果として検出漏れが起きるか、「命名の最適化をお勧めします」のような一般的なフィードバックが返されます。したがって検証の粒度は実行の粒度と一致させる必要があります。実行を小さなブロックに分割し、検証もそれに合わせて小さなブロックに分割します。
この2つの制約は共に、まずspecを実行可能なテストフレームワークに変換し、Agentが最初のステップからfeedback loopを持てるようにすべきことを示しています。DORA 2025レポートは大規模データでこの点を裏付けています。AIは既存のエンジニアリングプラクティスの増幅器です。検証基盤のあるチームでは、Agentの速度がアウトプットを増幅します。検証基盤のないチームでは、Agentの速度が混乱を増幅します。
では、前倒しの検証基盤とは具体的に何を含むのでしょうか。
テストとcode reviewは両方不可欠である
specとの一致性を検証するには、1つではなく2つのメカニズムが必要です。コミュニティでは繰り返し見られるパターンがあります。チームが片方だけを採用し、結果が悪く、「AIプログラミングは信頼できない」と結論づけるケースです。
code reviewだけでテストを行わないチームは、reviewがコードとspecの乖離を発見できる一方、ランタイムの正確性は検証できないことに気づきます。Reviewが「このロジックは正しそうに見える」と言っても、コードが実際に正しく動作することとは等しくありません。
テストだけでcode reviewを行わないチームは、別の問題に遭遇します。テストは振る舞いを検証できますが、カバレッジがspecの全意図に到達するのは困難です。Agentはハードコードでテストを回避する可能性があります。例えば期待値を直接returnしてテストを通過させることがあります。テストはすべてグリーンですが、特定の条件下でのみ顕在化する問題がコードに埋め込まれています。
2つのメカニズムの目標は同じです。specを実行可能な制約に変えること。しかし、カバーする次元が異なります。テストは振る舞いの正確性を検証します。specが述べた機能をコードが実現しているか。Code reviewは意味的な完全性を検証します。コードがspecのフレームワークから逸脱していないか、specに記述のないことを行っていないか。
コスト構造も異なります。テストはコストが低く、実行速度が速く、フィードバックが即時で、プロセス中の継続的な検証の主力です。Code reviewはコストが高く、フェーズの区切りで行うのに適しています。両者はコストとカバレッジにおいて相互補完の関係にあります。
本章ではこの2つのメカニズムをそれぞれ展開します。次のセクションではテスト基盤について説明します。最初のビジネスコードを書く前に、specを実行可能なテストフレームワークに変換し、Agentが実行の各ステップでフィードバックを得られるようにする方法です。その後、code reviewについて説明します。独立したAgentを使ってコードとspecの一致性を審査し、テストがカバーできない意図のドリフトを補完する方法です。最後に、AILock-Stepフレームワークの実践を通じて、この2つのメカニズムの完全なフローを示します。
Harness Engineering Playbook · AgentsZone Community