コードレビュー：AI作成者の上にAIレビュワーを重ねても不十分

AIコーディングツールの普及に伴い、エンジニアリングチームが直面しているのは単なる生産性向上ではなく、リスクの性質の変化です。AIが生成したコードは、適切にフォーマットされ、文書化され、変更内容の説得力のある説明を伴って届くことが多いですが、これらの表面的な品質は潜在的なセキュリティ上の欠陥を隠すことがあります。一見本番準備が整ったように見えるコードでも、ユーザー入力をエスケープせずにDOMに書き込むレンダリングパスや、既知の脆弱性を持つ新しい依存関係が潜んでいる可能性があります。

最近の独立したベンチマークでは、最新のLLMは機能的に正しいコードを生成できるものの、安全なコード生成ははるかに困難な問題であることが一貫して示されています。機能的正当性を向上させる手法は、セキュリティ結果を確実に改善するわけではありません。つまり、コードがテストに合格し、本番対応に見えても、マージする前に決定論的なセキュリティチェックが必要です。

Faros AIのテレメトリー調査（22,000人の開発者、4,000以上のチームを対象）では、組織のAI採用率が低から高に移行するにつれて、インシデントとプルリクエストの比率が242.7％増加したことが判明しました。同時に、レビューなし（人間またはAI）でマージされたプルリクエストは31.3％増加しており、レビューの実践がコードスループットの増加に追いついていないことを示しています。

具体的な例を考えてみましょう。開発者がAIアシスタントにユーザーのプロフィール編集エンドポイントの追加を依頼したとします。アシスタントは新しいルート、データベースマイグレーション、Reactコンポーネント、合格するユニットテストを返します。しかし、その変更には次のようなリスクが潜んでいる可能性があります：ユーザー入力をエスケープせずにレンダリングするXSSの脆弱性、既知のセキュリティ勧告を持つ新しいMarkdownパースライブラリ、テストフィクスチャ内の実際のクレデンシャル（プレースホルダーに見えるが実際にはそうではない）、そして楽観パスのみを検証し、他のユーザーのプロフィールを更新できるかどうかをチェックしないテスト。これらの問題は、従来のざっと読むだけのレビューでは見逃されがちです。

では、AI作成者の上にAIレビュワーを重ねれば問題は解決するのでしょうか？研究によれば、これでは不十分です。GitHub上のコードレビューの5分の1以上にAIエージェントが関与していますが、Faros AIのデータによると、完全に自律的に開かれたプルリクエストは1％未満であり、リスクの大部分は依然として人間が名目上責任を持つコードを通過しています。より深い問題は認識ギャップです。METRの無作為化比較試験では、AIツールを使用する経験豊富な開発者は実際のタスクを完了するのに測定可能なほど長い時間がかかるにもかかわらず、自分たちはより速く進んだと信じており、知覚と実際の生産性の間に大きな乖離がありました。この自信は検証に基づくものではなく、コードレビューにおいて、開発者やレビュワーがAIのおかげで変更が簡単で安全だと感じると、詳細に精査する可能性が低くなります。

AIレビューの価値は、生産性向上のためのアシスタントとしてです。大きな差分の平易な要約を生成したり、開発者が思いつかなかったテストケース（特に認可やエラーハンドリングに関するもの）を提案したり、ジュニアエンジニアに安全なパターンを説明するコーチングツールとして機能します。しかし、AIレビューは決してマージの決定権を持つべきではありません。セキュリティに関連するゲートは、独立した品質ゲートと説明責任のあるレビュワーに依存し、コードを書いたモデル自身に委ねてはなりません。

実践的なワークフローを構築するには、以下の原則に従います。AI支援のプルリクエストを識別する（ラベル、コミット規約、開発者の宣言）。すべてのPRに例外なくベースラインゲートを適用する（シークレットスキャン、依存関係スキャン、静的解析、テストカバレッジ）。高リスクの変更（認証、認可、支払いフロー、顧客データ、インフラストラクチャ）には、人間のレビューとより厳格な閾値を必須とする。AIレビューは助言的に保ち、マージ権限は必須チェックと指名レビュワーに与える。必須チェックを上書きできる権限を制限し、すべての例外を記録する。

AIコーディングツールは確かにスループットを向上させますが、スループットはエンジニアリングリスクの形を変えるものであり、排除するものではありません。最も価値を得ている組織は、AI支援開発を変更の時点で一貫して実施される強制メカニズムと結び付けています。