AIが書いたコードのレビュー手順｜確認する順番と観点をチームでそろえる

AIコーディングツールを使うと、短い時間でまとまった量のコードが手に入ります。変数名が整い、コメントも付いているため、一見すると問題がないように見えるかもしれません。ところが、依頼の意図とずれていたり、必要のないファイルまで変わっていたりすることがあります。

AIが書いたコードのレビューも、基本は人が書いたコードのレビューと同じです。違うのは、変更を出した本人が中身をすべて把握しているとは限らない点です。そのため、レビューする側と変更を出す側の両方で、確認の順番をそろえておくと進めやすくなります。

この記事で取り上げるのは、AIが書いたコードをレビューするときの手順です。確認する順番に沿って見ていきましょう。

レビューの前に、変更を出す側が確認すること

レビューを依頼する前に、変更を出す本人が一度目を通します。プルリクエストとは、変更を取り込む前にレビューを受けるための依頼のことです。AIの出力をそのままプルリクエストにすると、レビューする側が最初の読み手になってしまいます。本人が差分を読み、目的に合わない部分を直してから依頼しましょう。

依頼の説明欄には、AIに何を頼んだか、どこを自分で確認したかを書いておきます。AIへの指示文をそのまま貼る必要はありません。「この関数のテストをAIで作成し、境界値のケースを自分で追加した」のように、要点が伝われば十分です。

動作確認の結果も添えてください。テストを実行したか、画面で操作して確かめたか、確認していない部分はどこか。これらが書かれていると、レビューする側が重点を決めやすくなります。

手順1 依頼内容と変更内容を照らし合わせる

レビューの最初は、細かいコードを読む前に全体を見ます。課題やチケットに書かれた要件と、変更の内容が一致しているかを確認しましょう。AIは指示の一部だけを実装したり、頼んでいない機能を足したりすることがあります。

照合のときは、変更されたファイルの一覧を先に見ると分かりやすいでしょう。依頼と関係のないファイルが含まれていれば、その理由を変更者に尋ねます。理由を説明できない変更は、いったん取り除いてもらうのが安全です。

要件そのものがあいまいな場合は、変更を読む前に依頼の内容を確かめ直します。AIは足りない情報を推測で補って実装することがあり、その推測がチームの意図と合っているとは限りません。気になる点があれば、変更者と要件を書いた人の両方に確認するとよいでしょう。

手順2 変更の範囲と影響を確かめる

次に、変更がほかの機能に影響しないかを見ます。共通で使われる関数や設定ファイルが変わっている場合は、特に注意が必要です。AIは目の前の課題を解決するために、既存の処理を書き換えることがあります。

依存ライブラリ（外部から取り込んで使うプログラム部品）の追加や更新にも気を配ります。新しいライブラリが本当に必要か、保守が続いているものか、ライセンスに問題がないかを確認してください。存在しないライブラリ名や、古い書き方が含まれていることもあります。名前と使い方は、公式の文書で確かめると確実です。

変更の量が多すぎる場合は、分けて出し直してもらうことも検討してください。AIを使うと一度に大きな変更を作りやすくなる一方で、差分が大きいほどレビューでの見落としも出やすくなります。一つのプルリクエストには一つの目的、という基本を守ると、確認の負担を抑えられます。

手順3 動作とテストを確認する

コードを読むだけでは、動くかどうかは分かりません。テストが通っているかを確認し、必要であれば手元で動かします。AIが作ったテストが、AIが作ったコードに合わせて書かれているだけの場合もあります。テストが何を確かめているのかを読み、要件を確認できる内容になっているかを見ましょう。

エラー処理も見落としやすい部分です。入力が空のとき、通信に失敗したとき、想定外の値が来たときにどう動くかを確認します。正常な流れだけを実装したコードは、見た目が整っていても運用で問題が出ることがあります。テストの作り方については、テストコードの作成にAIを使うときの注意点も参考にしてください。

手順4 セキュリティと秘密情報を確認する

最後に、セキュリティの観点で見直します。利用者の入力をそのまま使っている箇所、権限の確認が抜けている箇所、ログに個人情報を出している箇所などが代表的な確認点です。

秘密情報がコードに含まれていないかも確認します。APIキー（外部サービスを使うための鍵となる文字列）やパスワードが、例として書かれたまま残っていることがあるからです。秘密情報らしい文字列を自動で検出するツールを併用すると、目視での見落としを減らせるはずです。

レビューで見つかったことをチームに戻す

同じ指摘が何度も出る場合は、チームの運用に戻して直します。たとえば、エラー処理の抜けが続くなら、AIへの指示や変更を出す前の確認項目に加えます。指摘を個人の問題で終わらせず、手順やルールに反映すると、次のレビューの手間を減らせるでしょう。

レビューの観点をチェックリストにしておくのも一つの方法です。ただし、項目が多すぎると形だけの確認になりやすくなります。よく見つかる問題に絞って始め、必要に応じて足していくと続けやすいはずです。

チェックリストやレビューの観点は、チームの運用ルールと一緒に管理すると探しやすくなります。運用ルール全体の決め方は、AIコーディングツールをチームで使うための運用ルールで整理しました。

注文取消し機能の変更をレビューする例

架空の社内受注アプリで、「担当者が未出荷の注文を取り消せるようにする」という課題を考えます。AIがボタン、API、テストをまとめて作ったとしても、ボタンを押せることだけでは要件を満たしたと判断できません。

まず、誰が取り消せるか、出荷済みの注文をどう扱うか、同じ操作が二度届いたらどうするかを課題と照合します。決まっていない条件は、AIが選んだ動作をそのまま採用せず、業務担当者へ確認します。以下は確認表の例であり、特定のシステムの実装仕様ではありません。

この表を用意したうえで差分を読むと、どの処理を重点的に調べるかが決まります。画面の制御、サーバーでの権限確認、保存先の更新、結果の表示を順にたどり、期待する動作と対応する箇所を結び付けます。

AIが作ったテストで確かめられる範囲を見る

上の例で「ボタンを押すとAPIが呼ばれる」というテストしかなければ、権限のない要求を拒否できる証拠にはなりません。レビュー担当者は、どの層の動作をテストしているかを確認します。画面のテスト、APIのテスト、実際の保存結果を見るテストには、それぞれ確認できる範囲があります。

テスト内で外部処理を置き換えている場合は、その置き換えによって失敗の条件まで消していないかを見ます。たとえば保存処理が必ず成功する設定だけなら、保存失敗時の表示は未確認です。必要なケースを追加し、どこまで実環境と同じ条件で確かめたかを説明欄へ残します。

既存のテストが削除されていた場合も、理由を尋ねます。新しい仕様で不要になったのか、失敗を避けるために外したのかで評価は変わります。テストを通すために要件を弱めていないことを確認してから取り込んでください。

差し戻しは場所・条件・期待結果を具体化する

「権限をもっと安全にしてください」というコメントでは、修正の範囲が定まりません。「取消しAPIで利用者の権限を確認できていません。権限がない利用者から直接要求した場合に拒否し、注文状態が変わらないことを確認してください」と書けば、変更者が修正と検証を進められます。

指摘には、対応が必要な不具合と、別の機会でもよい提案を区別して付けます。処理の誤りと変数名の好みが同じ扱いになると、変更者が優先順位を判断しにくくなります。依頼と無関係な整理を追加する場合は、別の変更として扱うと差分を追いやすくなります。

再レビューでは、コメントへの返事だけで完了にしません。修正箇所と新しいテストを読み、問題が起きる条件を試した結果を確認します。共通処理を直したなら、その処理を利用する既存機能にも影響がないかを確かめます。

説明できない変更が多いときの戻し方

AIが広範囲を書き換え、変更者が理由を説明できない場合は、疑問のある差分を一つずつ承認し続けるより、作業単位を小さくし直します。先に取消しの条件を整理し、次にAPI、最後に画面というように、確認できる順番で変更を作ります。

使わない差分を戻す前には、他の人の変更や必要な修正が混ざっていないかを確認します。AIに「全部元に戻して」と依頼するだけでは、残したい変更まで消すおそれがあります。対象の差分を特定してから戻し、やり直す範囲をチームで共有してください。

まとめ

AIが書いたコードのレビューは、依頼との照合・範囲と影響・動作とテスト・セキュリティの順に進めると整理しやすくなります。変更を出す側も、本人が差分を読み、確認した内容を説明欄に書いてから依頼しましょう。変更した本人が説明できない変更は取り込まないと決めておくと、チームの品質を保ちやすくなります。

e-Grantsでは、Codex・Claude Code・GitHub Copilotの導入とあわせて、レビューの流れや運用ルールの整備を支援しています。詳しくはAI開発環境の導入・整備をご覧ください。