エージェントによるコード生成は、作業の単位そのものを変えます。人間が小規模なPRを一つ作成してレビューする代わりに、エージェントは多数の実装候補やサービス横断の雛形、自動マイグレーションを次々と生成できます。その結果、コードの量と種類が増え、レビュー対象の範囲も広がります。チームには、機能を継続的にリリースする「スループット」と、退行やサプライチェーン上の問題を防ぐ「安全性」という二つの課題が生じます。このセクションでは、自動化によって対象範囲が広がる仕組み、レビュアーがボトルネックになる理由、そしてリリースエンジニア、セキュリティチーム、重要なライブラリのメンテナーなど、特に影響を受ける役割について説明します。

テストは、選択したシナリオで期待どおりに動作するかを確認し、テストケースに該当する退行の防止に力を発揮します。静的解析やリンターは、実行前に型エラーやメモリの問題、多くのAPIの誤用を見つけます。AIによるコードレビューは、可読性や論理的な不具合の可能性、スタイルの退行を大規模にトリアージできますが、微妙な意味上の誤りや、幻覚によるロジックを見逃すことがあります。これに対し、形式検証は、厳密な仕様が与えられれば、あらゆる入力について性質を証明します。実務では、動作範囲の確認にテスト、構造的な問題の検出に静的解析ツール、トリアージにAIレビューを使い、テストでは統計的に網羅できない不変条件、並行処理、暗号の保証には証明を活用します。

形式手法は強力ですが、万能ではありません。厳密な仕様が必要で、その設計自体が簡単ではありません。また、証明しやすいコードのサブセットを使ったり、契約を注釈として記述したりする必要があることも多くあります。UIのレイアウトやパフォーマンス調整、現実の曖昧な入力に左右される動作要件には、あまり向いていません。証明を広く適用しすぎると、変化の速い大規模なコードベースを形式検証しようとして、チームのボトルネックになるおそれがあります。このセクションでは、仕様の乖離、証明の保守コスト、CIとの統合の難しさ、前提が誤っているのに証明があることで過信してしまうリスクなど、よくある落とし穴を解説します。

複数の層からなるパイプラインを導入します。1) 仕様を先に定めて生成する——エージェントに実装を依頼する前に、厳密なAPI契約、型、プロパティベーステストを用意する。2) サンドボックス内で合成する——計測とファジングを行うCIランナー上で、エージェントを隔離して実行する。3) 自動チェックを設ける——人間のレビュー前に、ユニットテスト、統合テスト、プロパティテストとGitHub AI Scanによるセキュリティチェックを必須にする。4) 対象を絞って形式的証明を行う——コンセンサス、暗号、認可などの重要な不変条件や、影響範囲の大きいモジュールに適用する。5) 人間が検証する——一行ずつの正しさを確認するのではなく、設計、仕様への準拠、敵対的な視点にレビュアーの注意を集中させる。各段階が作業を妨げず、PRダッシュボードから状況を確認できるよう、ツールを統合しましょう。

まずは小さく始めましょう。重要なサービス一つで証明の試行導入を行い、欠陥が発生してから検出されるまでの期間やレビュー時間を測る指標を整え、SREやセキュリティエンジニアに仕様や証明用ハーネスの作成方法を習得してもらいます。製品要件を機械で検証可能な契約に落とし込む、証明エンジニアや検証推進担当といった新たな役割やローテーションも設けましょう。長期的には、コードの大半は高速な確率的ツールと人間のレビュアーが検証し、価値の高い一部のモジュールは形式的証明で強固にする、という二層化が進むと考えられます。この組み合わせなら、開発速度を保ちながら、特に重要な領域のシステミックリスクを大幅に下げられます。