AI生成コードのレビュー方法｜仕様・テスト・保守性を確認する実践手順
AIがコードを書いてくれるようになり、機能の試作や修正案の作成に取り組みやすくなりました。一方で、「実行できたので、そのまま使ってよいのか」「AIのレビューで問題なしと言われたら十分なのか」と迷う場面もあります。
AI生成コードを採用するときは、仕様に合っているか、既存の機能に影響しないか、運用後も変更しやすいかを確認します。この記事では、レビューの進め方と、AIに確認を依頼する際の具体例を整理します。
目次
１．AI生成コードのレビューでは何を確認する？
コードレビューは、変更したコードを読み、目的に合った実装かを確認する作業です。実行して結果を調べるテストと組み合わせることで、処理の意図と実際の動作の両方を確かめます。
AIが書いたコードにも、人が書いたコードと同じく、条件の取り違えや実装ミスが入り得ます。さらに、AIに渡していない業務ルールや既存の設計方針が、適切に反映されているとは限りません。
| 確認する観点 | 具体的な問い |
|---|---|
| 仕様との一致 | 依頼した条件を満たし、不要な機能を追加していないか |
| 既存機能への影響 | 呼び出し元や保存データとの整合性が保たれているか |
| 入力と権限 | 不正な入力や、権限のない操作を適切に扱えるか |
| テストの妥当性 | 期待する結果が正しく、重要な条件を確認できているか |
| 保守性 | 処理の役割や変更理由を、次の担当者が理解できるか |
AIにレビューを依頼することもできますが、その指摘にも見落としや誤りはあります。「問題なし」という回答だけを採用の根拠にせず、仕様、公式資料、実行結果などで確かめましょう。
２．生成前に、期待する動作と変更範囲を整理する
レビューしやすいコードにするには、生成前の依頼を具体的にします。入力、出力、条件、変更してよい範囲を伝え、不明点をAIが推測だけで埋めないようにしましょう。
例えば、学習アプリの得点判定なら、「合否を表示する」だけでは基準が不足しています。何点から合格か、得点の範囲はどこまでか、不正な入力をどう扱うかを決めておく必要があります。
| 整理する項目 | 学習用の架空の仕様例 |
|---|---|
| 目的 | 得点から合格・不合格を判定する |
| 入力 | ０〜100の整数。文字列や真偽値は受け付けない |
| 判定基準 | 60点以上なら合格、それ未満なら不合格 |
| 不正な入力 | 判定せず、入力エラーとして扱う |
| 変更範囲 | 判定処理と関連テスト。画面や保存形式は変更しない |
既存のプロジェクトでは、使用中の言語・ライブラリのバージョンや、参考にする実装も伝えます。変更範囲を絞ると、何のために追加・削除されたコードなのかを追いやすくなります。
条件が複雑で依頼内容をまとめにくいときは、処理の順序と分岐を整理してみましょう。フローチャートを使った確認方法を紹介しています。
フローチャート設計入門：動きと流れを可視化し、条件分岐を整理する方法 記事を読む →３．AI生成コードをレビューする５つの手順
手順１：変更された箇所と、その理由を確認する
最初に、変更前後の差分を確認します。依頼した修正に必要なファイルが変わっているか、無関係な設定変更や削除が混ざっていないかを見てください。
特に、入力チェック、権限確認、例外処理、既存テストが削られている場合は、その理由を調べます。エラー表示が消えたことと、原因が解消したことは同じではありません。
手順２：仕様から期待する結果を決める
先ほどの得点判定では、60点が合格になることが重要です。実装が「60点を超えたら合格」になっていれば、60点の扱いが仕様と食い違います。
生成されたコードを見てから期待値を合わせるのではなく、仕様を基に確認用の入力と結果を用意しましょう。次の表は、架空の得点判定に対する確認例です。
| 入力 | 期待する結果 | 確認すること |
|---|---|---|
| 59 | 不合格 | 合格基準の直前 |
| 60 | 合格 | 合格基準と一致 |
| 61 | 合格 | 合格基準の直後 |
| ０、100 | それぞれ不合格、合格 | 入力範囲の両端 |
| －１、101 | 入力エラー | 範囲外の値 |
| 文字列、小数、真偽値 | 入力エラー | 受け付けないデータ型 |
この例では文字列を受け付けない仕様ですが、画面からの入力を別の層で数値へ変換する設計もあります。どの部分で何を保証するかを決め、同じ前提で実装とテストを確認してください。
手順３：使っているAPI・パッケージを確かめる
AIが提案した関数やパッケージが実在するか、使用中のバージョンで利用できるかを公式資料で確認します。名前がもっともらしいという理由だけで、インストールや置き換えを進めないようにしましょう。
また、最新版への更新が、そのまま今回の修正に必要とは限りません。既存コードとの互換性、サポート状況、既知の問題、導入による影響を踏まえて判断します。
手順４：外部への影響と失敗時の動作を確認する
データの保存・削除、メール送信、外部APIの呼び出しを含む場合は、何が実行されるかを読んでから検証します。本番データを使う前に、テスト用データや検証環境で結果を確認してください。
通信に失敗した場合、途中まで保存された場合、同じ依頼が再送された場合なども検討します。単に例外を捕まえて処理を続けると、失敗が利用者に伝わらず、結果を取り違える場合があります。
手順５：読みやすさと、変更後の動作を確認する
最後に、命名、処理の分け方、コメント、関連ドキュメントを見直します。コードを整理した後も、期待する動作が保たれているかを確認しましょう。
一度に機能変更と大規模な書き換えを行うと、どの変更が不具合の原因か追いにくくなります。レビューしやすい単位に分け、変更の目的を説明できる状態にしておきます。
４．AIが作ったテストも、そのまま正解と考えない
AIにテストを生成させると、確認項目の候補を増やせます。ただし、実装の誤りを前提にした期待値や、重要な条件を確認していないテストが作られる場合もあります。
得点判定で実装が誤って「60点は不合格」となっていた場合、テストも同じ結果を期待していれば通過します。テストが成功したという事実だけでは、仕様に合っているとは判断できません。
- 期待値の根拠：仕様や独立した計算から決められているか。
- 確認内容：エラーが出ないことだけでなく、必要な結果を比較しているか。
- 条件の不足：境界値や対象外の入力など、重要な場合を確認しているか。
- 既存テストの変更：失敗を消すためだけに、削除・スキップ・期待値変更をしていないか。
実行記録も確認しましょう。「テストを追加した」「一部を実行した」「対象のテストがすべて成功した」は、それぞれ異なる状態です。未実行の項目や、環境の都合で確認できなかった範囲を残してください。
５．コードの「整理」は、短くすることだけではない
整理の目的は、処理の役割と変更理由を読み取りやすくすることです。例えば、得点を判定する関数なら、単なる「process」よりも、何を判定するか分かる名前の方が用途を伝えやすくなります。
関数の分割も、行数だけで決める必要はありません。入力確認、判定、保存などを分けると役割が明確になる一方、細かく分けすぎると、全体の流れを追いにくくなることもあります。
コメントには、コードを読めば分かる操作の説明だけでなく、条件の背景や、その実装を選んだ理由を残します。例えば「得点を比較する」より、「このコースでは60点以上を合格とする」と書く方が、判断の前提を確認できます。
性能は、実際の処理量を確認して判断する
例えば、一覧を１回の問い合わせで取得した後、各項目の関連データを１件ずつ取得する実装を考えます。100件の一覧に対して100回の追加問い合わせが発生すれば、合計101回になります。これは仕組みを説明する仮定の例です。
このような取得方法は、N+1問題として検討されます。ただし、問い合わせ回数だけで障害が起きるとは断定できません。データ量、実行時間、データベースの負荷を測り、必要な箇所を改善してください。
Djangoの公式資料も、最適化の前後で計測することや、関連データの取得方法を見直すことを説明しています。AIの「高速になりました」という説明についても、変更前後の測定結果で確かめましょう。
AIでコードの生成時間が短くなっても、確認や修正に時間がかかる場合があります。業務全体で効果を測る考え方を紹介しています。
AI導入で生産性は上がる？効果が出ない原因と業務改善の進め方 記事を読む →６．AIにコードレビューを依頼するプロンプト例
AIにレビューを依頼するときは、「問題がないか見て」だけでなく、仕様と確認したい範囲を渡します。指摘の理由や再現条件も求めると、実際の修正が必要かを検討しやすくなります。
以下は、レビュー依頼のひな形です。共有してよいコードと資料を用意し、目的や条件を自分のプロジェクトに合わせて置き換えてください。
次の仕様と変更差分を基に、コードをレビューしてください。
【目的】
今回の変更で実現したいこと：
［ここに記入］
【仕様】
入力、出力、判定条件、不正な入力の扱い：
［ここに記入］
【環境と変更範囲】
使用する言語・ライブラリのバージョン：
［ここに記入］
変更してよい範囲：
［ここに記入］
【確認してほしいこと】
・仕様と異なる動作
・境界値や異常時の処理
・呼び出し元と既存機能への影響
・テストの期待値と確認範囲
【回答形式】
各指摘について、次の情報を示してください。
1. 該当箇所
2. 問題が起きる条件
3. 期待する動作と、コードから読み取れる動作
4. 指摘の根拠
5. 修正案と確認方法
情報不足による推測は、その旨を明記してください。
実行していないテストを、成功したと記載しないでください。
まず指摘を提示し、コードの修正は行わないでください。回答を受け取ったら、指摘された条件で問題が再現するかを確かめます。再現できない場合は、呼び出し元や設定などの前提を確認し、根拠が不十分なまま変更を重ねないようにしましょう。
７．採用前に、確認できたことと未確認のことを残す
レビューの最後には、何を確認したかを短く記録します。すべての項目に形式的なチェックを付けるよりも、今回の変更に関係する範囲と、未確認の部分が分かることが大切です。
| 記録する項目 | 記入例 |
|---|---|
| 変更目的 | 60点を合格とする判定条件に修正 |
| 確認した動作 | 59・60・61点と入力範囲の両端を確認 |
| 実行したテスト | 得点判定のテストを実行し、すべて成功 |
| 未確認の範囲 | 画面から入力した場合の表示は未確認 |
| 残る対応 | 検証環境で画面表示を確認してから公開する |
継続して開発する場合は、重要なテストや静的解析を自動実行する仕組みも役立ちます。ただし、自動チェックで確認できる範囲は設定した内容に限られるため、業務上の判断や画面の使いやすさなども別途確認してください。
自動処理を運用する際は、コードの正しさに加えて認証情報や再実行の扱いも確認します。GitHub ActionsによるSNS自動投稿の例で整理しています。
GitHub ActionsでSNS自動投稿する方法｜定期実行・Secrets・重複投稿対策 記事を読む →８．AI生成コードのレビューに関するよくある質問
別のAIにも確認させれば、十分ですか？
別のAIから異なる指摘を得られる場合はありますが、複数のAIが同じ誤りを見落とす可能性もあります。回答の一致だけで判断せず、仕様との照合や再現テストを行ってください。
初心者でコードを十分に読めない場合はどうすればよいですか？
一度に作る機能を小さくし、入力、条件分岐、出力を順に確認しましょう。AIに説明させた後、自分で結果を予想して実行し、説明と一致するかを確かめる練習ができます。
認証やデータ削除など、判断を誤ると影響が大きい処理は、説明を読んだだけで公開せず、詳しい人のレビューも受けてください。理解できていない部分を明確にすることも、確認作業の一つです。
レビューに時間がかかるなら、AIを使う意味はありますか？
効果は、作業内容や経験、既存コードの複雑さによって変わります。生成時間だけでなく、依頼の準備、確認、修正、手戻りを含めた時間と成果物の品質で判断しましょう。
AIの指摘は、すべて修正するべきですか？
すべてを採用する必要はありません。仕様に関わる不具合、保守上の提案、単なる好みの違いを分け、根拠と影響を確認して判断します。採用しない場合も、意図した動作である理由を残すと、後の確認に役立ちます。
９．小さな変更を、根拠を持って採用する
AI生成コードのレビューでは、仕様から期待する動作を決め、変更差分を読み、必要なテストを実行します。AIによる説明や指摘も活用しながら、実際の根拠を確認することが大切です。
まずは一つの機能について、通常の入力、条件の境目、不正な入力を整理してみましょう。何を確認できたかを記録する習慣が、次の修正やチームへの引き継ぎにもつながります。
参考資料
- GitHub Docs：Review AI-generated code
- GitHub Docs：Application card: GitHub Copilot Agents
- GitHub Docs：Best practices for using GitHub Copilot
- Google Engineering Practices：What to look for in a code review
- Django公式ドキュメント：Database access optimization
Learning Tools
記事を検索したい方はここから！
記事を検索
関連記事や、今の内容に近いテーマをすぐに検索できます。
例: AI / 情報Ⅰ / Python / 統計 / 資格 / 学習法