AIが生成したコードをレビューするための開発者ガイド

コードレビューは常に、バグが本番環境に到達する前にそれを捕捉することにあった。しかし、コードが人間の同僚ではなくAIアシスタントによって書かれた場合、レビューの力学は根本的に変わる。AIが犯すミスは人間が犯すミスとは異なり、チェックすべき項目もピアレビューと同じではない。

本ガイドは、経験豊富なチームがAI生成コードのレビューについて学んできたことをまとめたものだ。AIモデルが一貫して生み出す問題のカテゴリ別に整理されているため、人間が書いたコード向けに培われた直感に頼るのではなく、体系的なチェックリストに沿ってレビューを進められる。

なぜAI生成コードには異なるレビュー基準が必要なのか

人間の開発者が犯すミスは、疲労、注意散漫、知識のギャップに集中する——疲れた開発者はエッジケースを見逃し、注意散漫な開発者はエラー処理を忘れ、ジュニア開発者は知識不足ゆえにアンチパターンを使う。AIモデルが犯すミスは、まったく異なる軸に集中する——幻覚(hallucination)、コンテキスト盲、スタイルの不整合だ。

null入力を処理しない関数を書いた人間は、おそらく本来はそれを知っていて単に忘れただけだ。同じ関数を書いたAIは、あなたのコードベースでnullが可能かどうかを、明示的に伝えない限り、本当に知らない。この違いは重要だ。なぜなら修正方法が異なるからだ——人間にはリマインダーが必要だが、AIにはプロンプトにエンコードされるか、レビューで捕捉される制約が必要なのである。

この違いを理解することが、効果的なAIコードレビューの基盤である。あなたがチェックしているのは、開発者が注意深かったかどうかではない。AIが正しいコードを生成するのに十分なコンテキストを持っていたかどうか、そしてその出力が、AIには見えなかったコードベースの暗黙の規約と一致しているかどうかである。

チェック項目1: 幻覚のAPIとインポート

AI生成コードにおける最も一般的な問題は、存在しないライブラリ、関数、APIの使用である。AIモデルはもっともらしいコードを生成するように訓練されており、存在しないパッケージのインポートや、存在したことのないメソッドの呼び出しを自信満々に生成する。これは悪意ではなく、学習中に見た実際のパッケージの間を補間し、もっともらしい橋を作り出しているだけだ。

// もっともらしく見えるが、存在しない関数をインポートしているAI生成コード
import { renderAsync } from 'react-dom'; // renderAsync は存在しない
import { optimize } from 'lodash/fp/string'; // このパスは lodash に存在しない

// 実際に必要なもの
import { renderToString } from 'react-dom/server';

修正はシンプルだが重要だ。すべてのインポートとAPI呼び出しを実際のドキュメントと照合して検証すること。コードがコンパイルを通るからといってAPIが正しいと仮定してはいけない——幻覚の関数の中には、TypeScriptのチェックは通るが実行時に失敗する、もっともらしいシグネチャを持つものもある。レビューには、見覚えのないインポートに対する簡単な正気チェックを含めるべきだ。

チェック項目2: 欠落したエラーハンドリング

AIモデルはハッピーパスを生成する傾向がある。関数のメインロジック——ループ、変換、戻り値——を書くのは驚くほど得意だが、問題が起きたときの処理を書くのは驚くほど苦手だ。ネットワークリクエストにキャッチブロックがない。ファイル操作にエラー処理がない。非同期関数に拒否ハンドラがない。

これはAIがエラーハンドリングを書けないからではない。明示的に要求すれば、AIは徹底的なtry-catchロジックを生成する。問題は、モデルのデフォルトの振る舞いが最もシンプルな動作バージョンを書くことであり、エラーハンドリングはそのデフォルトに含まれていないということだ。AI生成コードのレビューには、エラーパスのみに注目するパスを必ず含めるべきである。

• すべての非同期関数にはcatchまたは拒否ハンドラが必要。
• すべての外部API呼び出しは、ネットワークエラー、タイムアウト、予期しないレスポンス形式を処理すべき。
• すべてのデータ変換は、null、undefined、予期しない型を処理すべき。
• すべてのファイルまたはデータベース操作は、パーミッションエラーとリソース欠如を処理すべき。

便利なテクニックとして、AI生成コードからtry-catchブロックを取り除き、残ったロジックがまだ意味をなすかを確認するという簡単なテストがある。もし意味をなすなら、AIはおそらくエラーハンドリングについて深く考えていない。もしロジックがエラーハンドリングに依存して機能するなら、AIはそれを適切に統合している。

チェック項目3: スタイルと規約の不一致

どのコードベースにも、書かれていないスタイルの規約がある。チームは早期リターンを使い、ネストされたifは使わない。エラーメッセージは特定のフォーマットに従う。変数名は特定のパターンを用いる。何百万もの公開リポジトリで学習されたAIモデルは、それらすべてのリポジトリの統計的平均を反映したコードを生成する——あなたのコードベースに固有の規約ではない。

結果は、動作するが違和感のあるコードだ。異なる命名規則、異なるモジュール構造、異なるエラーハンドリングパターンが使われる。この種の不整合は急速に蓄積する——5つの異なる暗黙のスタイルで書かれた5つのAI生成関数が、一貫性のない、保守が困難なコードベースを作り出す。

最善の対策は、プロンプトにスタイル例を含めることだ。同じモジュールから代表的な関数を貼り付け、「このスタイルを使ってください」と指示する。これにより、AIの学習デフォルトを上書きする具体的な参照が与えられる。レビュー中は、生成されたコードが周辺のモジュールを書いた同じ人物によって書かれたと言えるかを確認する。

チェック項目4: 過剰エンジニアリングと不要な抽象化

AIモデルは抽象化に強く偏っている。単純な問題を与えると、1つの関数で済むところを、クラス階層、インターフェース、ファクトリ、3つのユーティリティ関数を生成することがよくある。この傾向は、シンプルなスクリプトや1回限りの関数が過小評価される一方で、適切に設計されたオープンソースライブラリが過大評価されている学習データに起因する。

AIモデルはデフォルトで過剰エンジニアリングをする。あなたのレビューはデフォルトでシンプルさを志向すべきだ。AIが導入したすべての抽象化は、よりシンプルな代替案に対してその存在意義を正当化する必要がある。

レビュー中に自問してほしい。このコードにクラスが必要か、それとも関数で十分か？ このインターフェースは複数の実装で使われているか？ このユーティリティを抽出することで、間接性を正当化するのに十分な繰り返しが削減されるか？ これらのいずれかの答えがノーなら、AIはおそらく過剰エンジニアリングしており、よりシンプルなバージョンのほうが良い。

チェック項目5: セキュリティ脆弱性

AIモデルはセキュリティ脆弱性を含むコードで学習されている。彼らはそのコードからパターンを学習するが、脆弱なパターンも含まれる。最近のモデルはSQLインジェクションのような明白な問題を避けるのが上手くなったが、レビューアが捕捉すべき微妙なセキュリティ問題をまだ生み出す。

• 生成コード内のハードコードされたシークレット、APIキー、認証情報を確認する。
• ユーザー入力が使用前に検証されサニタイズされていることを確認する。
• 保護された操作に認証・認可チェックが存在することを確認する。
• 生成されたSQLクエリが、文字列連結ではなくパラメータ化ステートメントを使用していることを確認する。
• ファイルパスが、サニタイズなしに信頼できない入力から構築されていないことを確認する。

機密データやユーザー入力を扱うAI生成コードには、セキュリティに特化したレビューパスが必須である。AIは、あなたが伝えない限り、システムのどの部分がセキュリティクリティカルかを知らない。迷ったときは、マージ前に生成コードに対して静的解析ツールを実行する。

チェック項目6: 既存アーキテクチャとの一貫性

AIモデルは各リクエストを独立して見る。チームが先四半期にすべてのデータフェッチにReact Queryを使うことで合意したこと、APIが常にキャメルケースのキーを返すこと、プロジェクトが特定の状態管理パターンを使っていることを、AIは知らない。生成されるコードは内部的には一貫しているが、現在のファイルからは見えないアーキテクチャ上の決定に違反する可能性がある。

ここで人間のレビューアが最も価値を発揮する。あなたはADRに文書化された決定、チームの議論から生まれたパターン、どの単一ファイルにも捉えられていない設計上の制約を知っている。AI生成コードを、正しさやスタイルだけでなく、これらの目に見えない制約に対してレビューする。

持続可能なレビュープロセスの構築

AIがコードベースのより多くの部分を生成するにつれ、レビュープロセスもスケールする必要がある。4人チームがAI生成の各行を手動でレビューしていては疲弊する。持続可能なアプローチは、自動チェックと人間による集中レビューを組み合わせることだ。

自動チェックは、人間がコードを見る前に、幻覚のインポート、スタイル違反、欠落したエラーハンドリング、一般的なセキュリティ問題を捕捉する。これにより、AI固有のレビューは、アーキテクチャの一貫性、設計上の決定、リンターでは検出できない微妙な問題という、より小さな範囲に絞られる。

目標は、AI生成コードの人間レビューを排除することではない。ツールが自動的に捕捉できる問題をフィルタリングし、人間だけが下せる判断に人間の注意力を温存することで、レビューを可能な限り効率的にすることだ。適切なプロセスがあれば、AI生成コードのレビューは人間が書いたコードのレビューよりも高速で信頼性が高くなる——AIのミスのほうがより予測可能だからだ。