ステージ4 — 検証 (Verification)
作られた速度ではなく、信じられるようになった速度が全体のリードタイムを決める。
このステージの目的
ステージ3から出た成果物はまだ信頼の対象ではない。このステージの目的は「作られた」と「信じられる」の間の隙間を狭めることだ。生成速度はもはやボトルネックではないので、検証に投資することがそのまま全体のリードタイムに投資することと同じだ。すべての成果物に同じ強度の検証をかけるとリソースが無駄になるので、失敗コストに比例して検証強度を調整する。
実行順序
- 第一の防衛線 — 自動テストと静的解析を回す。 ユニットテスト、リント、型チェックのように人手なしで即座に実行可能な検証をまず通過させる。ここで漏れると以降のステージ全体が無駄になる。
- リスク等級をつける。 この成果物が失敗したときのコストがどれだけ大きいかを判断する。決済・認証・個人情報のように失敗コストが大きい領域か、内部ツール・プロトタイプのように軽い領域かを分類する。基準はリスクマトリクスに従う。
- 第二の防衛線 — 別のエージェントが交差レビューする。 リスク等級に比例して、実装したエージェントと異なるセッション・異なるエージェントがコードを読み直し、意図との整合性、抜けたケースを点検する。
- 最終の関門 — 人間がレビューする。 リスク等級が高いほど人間レビューの比重を増やす。リスクが低い領域は自動検証の通過だけで次のステージへ移れる。検証の対象には承認者の理解も含まれる。リスクが高い変更は「承認者がこのコードを説明できるか」を通過基準に入れる — 自分が理解したことをエージェントに説明して確認してもらう説明の問い返し、エージェントとともに変更点を辿るコードウォークスルーが有効な道具だ。
- 見つかった問題の根源を追跡する。 コードを直すことで終わらせない。同じ問題が繰り返される余地があるなら、意図文書やコンテキスト資産の欠陥まで遡ってともに直す。
成果物
- リスク等級が付与された検証計画 — リスクマトリクス
- レビュー記録 — レビューチェックリスト
検証通過の記録は、ステージ5(デプロイと観察)へ移る根拠として残す。
完了基準チェックリスト
- [ ] 成果物ごとにリスク等級が付与されている
- [ ] 第一の防衛線(自動テスト・静的解析)が人の介入なしに自動で回る
- [ ] リスクが高い領域は別のエージェントの交差レビューを経ている
- [ ] リスクが高い領域は人間レビューの記録が残っている
- [ ] リスクが高い変更は承認者がその内容を説明できるか確認した
- [ ] 見つかった問題がコード修正にとどまらず、必要な場合は意図文書・コンテキスト資産まで更新された
よくある誤り
- すべての成果物に同じ強度の検証をかける。 プロトタイプまで決済システム水準でレビューすると検証がボトルネックになり、逆に認証ロジックをプロトタイプのように軽く流すと事故につながる。
- 自動検証だけを信じて人間レビューを省く。 テストを通過したというのは定義されたケースを満たしたという意味にすぎず、意図と整合するかは別の問いだ。
- 症状だけ直して根源を放置する。 同じ種類の誤りが次サイクルで繰り返されるなら、その誤りを防ぐルールがまだコンテキスト資産へ移されていないという信号だ。
Claude Codeなら
TIP
コードレビューを別のサブエージェントやレビュー専用コマンドに分離すれば、実装したセッションと異なる視点から第二の防衛線の役割をさせられる。同じセッションが自分の結果をそのまま承認する構造を避けるのが核心だ。
フック(hook)でコミット前のテスト実行を強制すれば、第一の防衛線を人が忘れても飛ばせなくできる。検証で繰り返し捕まる誤りのパターンはレビューチェックリストに項目として追加し、次サイクルからは同じ誤りが自動で引っかかるようにする。