Code Review：テストがカバーできない意図の漂流を補完する
テストが検証するのは振る舞いです。spec が述べた機能を、コードは実現しているか。しかしコードにはもう一つの問題類型があります。振る舞いのレベルでは完全に正しく、テストはすべてグリーンであるにもかかわらず、意図が静かに逸脱しているケースです。code review の仕事は、テストのこの死角を捕捉することです。
テストに見えないもの
spec は設定ファイルでデータベース接続文字列を管理するよう要求していますが、Agent は接続文字列をコードに直接書き込みました。機能は完全に正常で、テストはすべて通りますが、別の環境にデプロイすると失敗します。
spec はユーザー登録機能の実装を要求していますが、Agent は登録を実装するついでにログインモジュールのエラーハンドリングロジックをリファクタリングしました。登録機能のテストは通りますが、ログインモジュールの振る舞いに審査されていない変更が生じています。
spec で定義されたエンティティは Order ですが、Agent はコード中でそれを Transaction と命名しました。機能には何の問題もありませんが、次の Agent がこのモジュールを引き継ぐとき、spec を持って Order の実装を探すと、見つかるのは Transaction というクラスであり、両者の間に明示的な関連付けがありません。
これらの問題の共通特徴は、いかなる振る舞いのアサーションにも違反しないため、テストがそれらを捕捉しないことです。ハードコーディング、スコープ外の変更、アーキテクチャの逸脱、過剰実装、用語の漂流はすべてこのカテゴリに属します。これらはバグではありませんが、コードが spec の定義したフレームワークから徐々に逸脱しているシグナルです。発見されなければ、これらの逸脱は後続のイテレーションで蓄積し、コードと spec の間のマッピング関係を徐々に曖昧にし、最終的に spec が single source of truth としての役割を失います。
Review の基準は仕様
従来の code review のチェックリストは、変数命名は規範的か、潜在的なパフォーマンス問題はないか、例外処理は網羅的か、というものです。これらの問題の参照系はコード自体と汎用的なエンジニアリングのベストプラクティスです。
Agent 開発における code review が問うのは3つだけです。このコードは spec が述べたことと同じか。このコードは spec が要求していないことをしていないか。コード中の概念と spec 中の用語は対応しているか。
参照系がコードから spec に変わります。Review agent の中核的な入力は変更されたコードと spec であり、Agent のコーディングプロセスを見る必要も、その実装の考え方を理解する必要もありません。仕事は spec を持ってコードの変更を逐条で照合し、一致、逸脱、欠落を標注することです。
これは、review の成果物が漠然とした「改善提案」のリストではなく、spec 一致性レポートであることを意味します。どの acceptance criteria が満たされたか、どこに逸脱があるか、何が完全に欠落しているか。このレポートは spec の構造に直接対応しており、人間がレビューする際は逸脱と欠落の項目に集中でき、コードを一行ずつ読む必要がありません。
コーディングとレビューの Agent は独立でなければならない
同じ Agent にコードを書かせてから自身の成果物を審査させると、コーディングプロセスで蓄積されたコンテキストが判断に影響します。コーディング時に Order を Transaction と命名する決定をし、その決定と理由がすべて context に残っています。審査時に Transaction を見ると、context 内の推論プロセスがその命名は合理的だと告げるため、spec と照合して再評価することはありません。バックエンドで検証を一つ漏らしても、フロントエンドで対応済みだと記憶しており、context にその記憶があるため、バックエンドにも必要かどうかを問い直しません。審査がコーディングプロセスで既に行った推論の確認に変わり、spec に対する独立した検証ではなくなります。
したがって、コードを書く Agent と review する Agent は独立した session で実行されなければなりません。Review agent はコーディングプロセスのいかなるコンテキストも持ちません。コードがなぜこう書かれたかを知らず、spec が何を要求しているか、コードが何をしているか、両者が一致しているかだけを判断します。
異なるモデルで交差審査を行うことで、共有される死角のリスクをさらに低減できます。異なるモデルファミリは異なる訓練データと推論の偏りを持っており、コーディング Agent がシステム的に見落とす問題に、別のモデルが敏感である可能性があります。これは spec の章で述べた交差検証と同じ原則です。独立した視点だけが漂流を発見できます。
Anthropic は Claude Code のベストプラクティスドキュメントにおいて、writer/reviewer の分離を最も優先度の高い推奨事項の一つに挙げ、fresh context が review の品質を顕著に向上させることを明示しています。彼らの社内 code review システムは、ほぼすべての PR で複数の agent を並行して審査に投入し、各 agent が異なる問題カテゴリ（ロジックエラー、境界条件、API の誤用、権限の脆弱性、プロジェクト規約）を担当しています。導入後、実質的な発見が得られた PR の割合は16%から54%に上昇しました。1000行以上の大規模 PR では84%で発見があり、PR あたり平均7.5件の問題が標注されました。エンジニアが審査の結論に同意しなかった割合は1%未満でした。
OpenAI の実践は別の規模の参照を提供しています。自動化された code review システムは1日あたり10万件以上の PR を処理し、肯定的なフィードバック率は80%を超えています。
これらのデータが示す実践的な結論は、独立した明確な基準に基づく審査はスケーラブルな開発において実現可能であり、人間の審査よりも一貫性が高いということです。Agent の成果物の速度が人間の審査能力をはるかに超えるとき、独立した Agent による spec 一致性審査は、成果物の速度に追いつくことができる唯一の手段です。
Harness Engineering Playbook · AgentsZone Community