AI生成コードのコードレビューは、別物です。プルリクエストは文法的に完璧に見え、ローカルのすべてのテストに通っているのに、それでも気づきにくい形で間違っていることがあります。
他人が書いたコードを何年も読み続けることで培ってきた、私たちのレビュー習慣は、その状況に備えていません。私たちは論理エラーやスタイルの問題を探すのに慣れています。変わるのは、AIが一見すると正しく見えるのに、誤った前提にもとづいて作られた何百行ものコードを生成できるようになったことです。
これにより、ソフトウェア開発におけるボトルネックの位置が変わります。コードを書くことはもはや最も遅い工程ではありません。生成物を検証することがそうなります。
開発者が大量のコードを生成できるようになると、レビュアーの仕事はミスを直すことから、意図を検証することへと移ります。表面的なレビューのコストも同様に変わります。それは小さなバグで終わるとは限らず、アーキテクチャ上の欠陥、セキュリティ上のリスク、あるいは本番で初めて現れるパフォーマンス問題になる可能性があります。
AI生成コードを信じるコスト
AIによる即時の生産性向上は明らかです。その後に来るものが、いつもそうとは限りません。最初は正しそうに見えるのに、システムに対する脆い、あるいは誤った理解にもとづいて作られたコードで、新しい種類の問題が増えてきていることが分かってきました。
AIの出力における失敗を無視する
AI生成コードは、多くの場合「完成している」ように見えます。ドキュメント文字列（docstring）付きの関数を生成し、基本的なエラーハンドリングを追加し、コードベース全体の一般的な構文に従います。最初はすべてが正しく見えるのですが、重要な詳細が欠けているかもしれません。
そのコードは通常、私たちの特定の運用上の文脈ではなく、一般的な課題向けに書かれています。また、より経験のあるエンジニアなら経験をもとに通常追加するはずの追加チェックが欠けていることもあります。たとえば、下流のサービスが不正なオブジェクトを返す場合や、負荷がかかるとタイムアウトする場合を考慮していないかもしれません。そうした失敗は、学習データではなく、私たちのシステムに固有のものだからです。生成されたコードには、ネットワーク障害向けの `try/catch` ブロックが含まれていることすらあるかもしれませんが、成功したように見えるものの破損しているレスポンスのペイロードを検証しないでしょう。
もう1つよくある問題は、難解、または標準でないライブラリの導入です。AIモデルは、学習データの中で見かけたニッチなパッケージを使って課題を解決するかもしれません。開発者が気づかないうちに、新しい保守負担と新しいセキュリティ面を増やしてしまいます。コードは動くのに、チームは自分たちで選ばなかった依存関係を抱えることになります。
なぜ現在のコードレビュー手順は失敗するのか
私たちのコードレビューの実践は、1つの前提に基づいて構築されてきました。それは、推論を問いただせる人間の作成者がいるということです。私たちは論理と保守性を見ながらコードをレビューし、作成者がシステムの頭の中のモデルを持っていることを信頼します。AI生成コードは、その前提を壊します。
正しさの錯覚
最大の課題は、AIのコードが正しく見えることです。多くの場合、ジュニア開発者が書いたコードよりも、スタイル面でより整理され一貫しています。その見た目の良さが、レビュアーに誤った安心感を与えてしまうことがあります。私たちは明白なバグを探しますが、戦略的なバグを見逃します。
AIは、完全に機能するデータ変換スクリプトを生成できます。レビュアーはサンプルデータで動くことを確認します。見過ごされるのは、そのスクリプトがデータセット全体をメモリに読み込むことです。100件のレコードを含むテストファイルでは動作しますが、レコード数1,000万の本番データベースに対して実行するとサーバーがクラッシュします。コードは技術的にはバグがないかもしれませんが、運用上は成立しません。
コード内に繰り返しの多いセクションがある場合、これはさらに悪化します。AIは、チームのRESTパターンに従っているように見える200行のコントローラを生成できます。そのコードのどこかに、サービス層とその検証ロジックを迂回して直接データベースをクエリしている部分が潜んでいるかもしれません。
人間のレビュアーは、見慣れたパターンを見ればコードを素早く読み進めて、アーキテクチャ上の逸脱に気づかない可能性があります。問いただすべき「作成者としての意図」は存在せず、検証すべき「出力」があるだけです。機械の「推論」を追跡することはできません。存在しないからです。
セキュリティとパフォーマンスの退行を無視する
AIモデルは公開コードで学習されています。既知の脆弱性や非効率なパターンの例も含まれています。そのため、それらの解決策を評価せずに、導入してしまうことがあります。
2021年のスタンフォード研究では、AIアシスタントを使う開発者は、使わない開発者よりも不安全なコードを書きやすいことが示されました。
AIは、古い学習データに出てきたという理由で、廃止予定の暗号化アルゴリズムを提案するかもしれません。また、公のフォーラムからコピーした複雑な正規表現パターンを提案することで、正規表現デノサービス攻撃（ReDoS）に対して脆弱なコードを生成する可能性があります。これらは単純なミスではありません。リンタや基本的なテストでは見つかりにくい、継承された脆弱性です。
パフォーマンスの退行もよく起こり、特定するのが難しいです。AIは、システム全体へのパフォーマンス影響を考慮せずに、目先の課題を解決する傾向があります。リスト内のアイテムをネストしたループで処理するような解決策を生成し、その結果 O(n²) の計算量になるかもしれません。10個のアイテムでのユニットテストは通りますが、10,000個ではほぼアプリケーションが止まってしまいます。
システムの規模に関する文脈を持つ人間の開発者なら、おそらくこのようなことは避けるでしょう。AIにはその文脈がありません。
エラーハンドリングでも同様のことが起こります。ある関数では、AIが学習例に基づく例外を使うかもしれません。別の関数では null やエラーコードを返し、不整合な挙動とより壊れやすいシステムにつながります。
AI時代に合わせたコードレビュー
これらの新しいリスクに対処するには、コードレビューの焦点をコード修正からコード検証へと移す必要があります。問うべきは、「このコードは、私たちのシステムの制約の中で、正しいことを、正しい理由で行っているか？」です。AI生成コードのあらゆるブロックは、あなたのプロジェクトがどう動いているかを知らない新しい開発者から来たかのように扱うべきです。
構文よりも意図を優先する
レビュー手順は、コードを見る前に始める必要があります。変更を作成した人に対してレビュアーが最初に投げるべき質問は、「あなたは正確にどのプロンプトを使いましたか？」と「どんな課題を解決しようとしていましたか？」です。これにより、レビューの焦点を「コードが何をするはずなのか」に再設定できます。
まず、生成されたコードが意図した課題を実際に解いているかどうかを確認します。AIが、よく似ているが微妙に異なる課題を解いてしまうことはよくあります。解決策はプロンプトに対して正しくても、ビジネス要件には合っていないかもしれません。
次に、AIの実装がシステムのアーキテクチャに適合しているかを確認します。タスクが単純な検証ルールを追加することであった場合、既存のサービスを正しく変更できたのでしょうか。それとも、新しいクラスを生成してロジックを分断したのでしょうか。
最後に、データフローを頭の中で追跡します。重要でない関数でない限り、入力から出力までデータを追ってください。入力が null の場合はどうなりますか？文字列が空だったり、珍しい文字を含んでいる場合は？ネットワーク呼び出しが失敗した場合は？この意図的な追跡により、単なる読み通しよりも深い分析が強制されます。
AI生成コードをレビューするためのチェックリスト
これを体系化するには、生成されたコードが大量に含まれるあらゆるプルリクエストに対して、チームは検証に重点を置いたチェックリストを採用すべきです。これにより、レビューを主観的な判断から切り離し、構造化されたプロセスへと移行できます。
- ビジネス領域を理解していますか？ AIにはドメインの文脈がなく、一般的な前提で不足部分を埋めてしまいます。たとえば、当社のシステムでは複数のメールアドレスを許可しているのに、ユーザーがメールアドレスを1つだけ持っていると仮定していませんか？
- テストは本当に良いですか？ AIがテストを生成した場合、幸せの道筋（happy path）だけをカバーしていますか？ AIが生成したテストは出発点にはなりますが、多くの場合、システムに固有のエッジケースや失敗モードまではカバーしません。AI生成コードにおけるテストカバレッジへの期待は、低くするのではなく高くあるべきです。
- 安全ですか？ コードは信頼できない入力として扱ってください。新しい依存関係を導入しており、その依存関係が評価されましたか？ ユーザー入力を安全に取り扱えていますか？ 承認済みの暗号ライブラリを使用していますか？
- 効率的ですか？ 生成された関数のアルゴリズム上の計算量はどれくらいですか？ ループの中でデータにアクセスしていますか？ メモリ効率は良いですか？ レビュー担当者は、生成器が無視したパフォーマンス分析に対しても今では責任を負うことになります。
- 人間が保守できますか？ コードは理解しやすいですか？ 必要以上に複雑なアルゴリズムをAIが選んでいませんか？ コードは、何をするのかだけでなく、このように動く理由を説明するためにドキュメント化されていますか？ プロンプトを使った人は、出力を説明できる必要があります。説明できないなら、マージしないでください。
- プロジェクトの基準に従っていますか？ AIは あなたの特定のアーキテクチャ基準、好まれるライブラリ、またはエラーハンドリング戦略を 知りません。レビュー担当者は、生成されたコードが一貫性のないロジックを持ち込むのではなく、システムの残りの部分と適切に統合できているかを確認することで、これらの基準が尊重されていることを確実にする必要があります。
このアプローチは、レビュー担当者により多くを要求します。レビュー担当者の役割は、単にスタイルや構文を確認することではなくなります。コードが本当にシステムの中で意味をなしているかを理解する必要があります。
そうでなければ、コードベースには、後になって本番環境で初めて表面化するような、微妙な誤りや問題が蓄積され始めます。
AIによるコード生成の速さは大きな利点ですが、それが機能するのは強力なコードレビューのプロセスがある場合に限ります。
