広告

AIが生成したプルリクエストをレビューする方法(ステップごとのチェックリスト)

Dev.to / 2026/3/31

💬 オピニオンTools & Practical Usage

要点

  • この記事では、AIが生成したコードには、もっともらしいが誤ったロジック、幻覚(ハルシネーション)したAPI、過剰な設計、意図しないリファクタリング、エラーハンドリングの欠落といった固有のレビュー失敗パターンがあると主張し、それに応じてレビュアー側の対応を調整することを推奨しています。
  • AI PRの変更が依頼された内容に限定されていることを高速に確認するスコープチェックから始める、ステップごとのPRレビュー用チェックリストを提案しています。
  • AI特有のリスクとして最上位にAPIの検証を挙げ、レビュアーは、すべてのインポート、モジュール、メソッド呼び出しが、プロジェクトの現在のライブラリとバージョンに実際に存在することを確認すべきだと強調しています。
  • 「ハッピーパス」をすり抜けがちな問題を見つけるために、エッジケース監査(空/null/Unicode など)による的を絞ったテストのための思考と、エラーパスのトレース(ネットワーク/データベース/ファイルの失敗)を行うことを助言しています。

AIが生成したコードが、あらゆるところでプルリクエストに登場しています。Copilotであれ、Claudeであれ、あるいはChatGPTを使ったチームメイトのものだとしても——AIコードにありがちな特定の失敗パターンを見つけ出すためのレビュー戦略が必要です。

ここでは、私が使っているチェックリストを紹介します。これは、人が書いたコードをレビューするときのやり方とは異なります。

デフォルトレビューの問題点

人間が書いたコードには、人間特有の失敗パターンがあります。命名が一貫していない、見落としたエッジケース、コピペミスです。あなたは、同じミスをしたことがあるからこそ、何を見ればいいかを知っています。

AIコードには、別の失敗パターンがあります:

  • もっともらしいが間違ったロジック——一見正しく見えるのに、エッジケースを逆に処理する
  • 幻覚化したAPI——あなたのライブラリのバージョンには存在しないメソッドへの関数呼び出し
  • 過剰な設計(オーバーエンジニアリング)——誰も求めていない抽象化レイヤーを追加する
  • サイレントな挙動変更——タスクに含まれていない隣接コードをリファクタしてしまう
  • エラーハンドリングの欠落——ハッピーパスは完璧に動くが、それ以外は全部クラッシュする

あなたのレビュー手順は、これらを具体的に狙い撃ちする必要があります。

チェックリスト

1. スコープ確認(30秒)

質問: このプルリクは、依頼された変更だけを加えていますか?

AIは、触ってほしくない部分を「改善」したがります。最初にファイル一覧を確認してください。たとえば、プルリクが「サインアップフォームに入力バリデーションを追加する」だったのに、認証ミドルウェアもリファクタしている——それはレッドフラグです。

アクション: 余計なファイルが変更されているなら、理由を尋ねるか、それらを別のプルリクとして差し戻す(分離する)よう依頼してください。

2. API検証(2分)

質問: すべてのインポートされたモジュール、関数、メソッドは、実際に存在しますか?

これはAI固有の失敗パターンとして#1です。このコードは、ライブラリ側でエクスポートされているのがparseだけなのに、parseAsync\をインポートします。そして存在しないオプションを伴ってresponse.json({ strict: true })のように呼び出します。

アクション: 見覚えのないインポートやメソッド呼び出しがあれば、ドキュメントを確認してください。コードが自信ありげに見えるからといって、その存在を信じてはいけません。

3. エッジケース監査(3分)

質問: 空の入力ではどうなりますか? Nullは? 要素が1つのリストは? ユニコードを含む文字列は?

AIが生成したコードは、ほぼ必ずハッピーパスを正しく処理します。バグは端の部分(エッジ)に潜んでいます。

アクション: このコードで最も起こりそうなエッジケースを3つ選び、頭の中で順にトレースしてください。コードがそれらを扱っていないなら、フラグを立てます。

4. エラーパストレース(2分)

質問: ネットワーク呼び出しが失敗したらどうなりますか? ファイルが存在しない場合は? データベースがダウンしているときは?

try/catchブロックを探してください。I/O操作の周りにtry/catchがないなら、それはバグです。ある場合は、catchの中で何が起きるかを確認します。エラーを無言で握りつぶすのは、AIにありがちなパターンです。

アクション: すべてのI/O呼び出しには、明示的なエラーハンドリングが必要です。「ログを出して再スローする」でも構いません。黙って何もしないのはダメです。

5. テストカバレッジ確認(1分)

質問: テストはありますか? 成功ケースだけでなく失敗ケースもテストしていますか?

AIが生成したテストは、「完璧な入力を渡したときに正しいものを返すこと」を確認しがちです。これは、最も価値の低いテストです。次をカバーするテストを探してください:悪い入力、データの欠落、ネットワーク失敗、同時アクセス。

アクション: PRにテストがなければ、要求してください。ハッピーパスのテストしかないなら、エッジケースのテストを要求してください。

6. 依存関係チェック(30秒)

質問: このプルリクは新しい依存関係を追加しましたか?

AIは、ときどき「3行の関数で済む問題」を解くためにライブラリをインポートします。package.json\ / requirements.txt\ / などに新しいパッケージが追加されていないか確認してください。

アクション: 新しい依存関係が追加されているなら、次を確認します。保守されているか? 必要か? それなしでできないか?

7. 「後ろから読む」パス(2分)

質問: 各関数は、単体で見て意味が通りますか?

ファイルの一番下から読み始めて、各関数をそれぞれ独立に確認してください。AIが生成したコードは、上から下へ読んだときの物語としては筋が通っているかもしれませんが、個々の関数が成立していないことがあります。

アクション: 周辺のコードを読まないと、その関数のロジックが成り立たない/意味が分からないなら、やりすぎているか、抽象化が間違っている可能性があります。

所要時間

完全なチェックリストは、典型的なプルリクに対して約10分です。内訳は次の通りです:

ステップ 時間
スコープ確認 0:30
API検証 2:00
エッジケース監査 3:00
エラーパストレース 2:00
テストカバレッジ 1:00
依存関係チェック 0:30
後ろからの確認 2:00
合計 約11分

これを、運用環境で幻覚化したAPI呼び出しをデバッグするためにあなたが費やす45分と比べてみてください。

どんなときに特に慎重にするべきか

  • プルリクが大きい。 AIが生成したプルリクは、必要以上に大きくなりがちです。300行を超えるなら、分割できないか確認してください。
  • プルリクが認証・決済・データ削除を変更している。 追加の精査を。コードをローカルで実行してください。
  • コミットメッセージが汎用的。 「機能を実装」や「改善を追加」といった文言は、全体が1回で生成され、試行錯誤(イテレーション)がなかったことを示唆します。

メタルール

AIが生成したコードは、「正しく見える」ことに最適化されています。レビューアとしてのあなたの仕事は、それが実際に正しいかを検証することです。「正しそうに見える」と「実際に正しい」のギャップこそが、バグが潜む場所です。

AIコードのレビューは、自信ありげなジュニア開発者を信頼するのと同じくらいに信頼してください。たぶん大丈夫ですが、大事な部分は確認する必要があります。

あなたのAIコードレビューのプロセスはどんなものですか? 他の人が何を確認しているのか、ぜひ聞いてみたいです。

広告