今回やること
AIへコードレビューを頼む時の情報と、指摘を安全に検証する手順を学びます。
- 変更目的と対象差分を整理する
- レビュー観点と優先度を指定する
- 根拠を含む出力形式を決める
- 人が指摘を検証する
AIは見落とし候補を増やす補助者です。最終判断と実行確認は人が担当します。
なぜ聞き方が重要なのか
コードだけでは、AIは変更理由や守るべき仕様を確定できません。「レビューして」だけでは、命名の好みを詳しく述べる一方、認可漏れや互換性の問題を見逃すことがあります。
良い依頼は正解を保証しませんが、確認範囲を狭め、指摘を検証しやすくします。重要なのは指摘の数ではなく、根拠を確かめられる指摘の数です。変更の背景を共有すると、仕様変更と単なる不具合を区別する助けにもなります。
秘密情報、個人情報、未公開の認証情報は入力しません。組織で許可されたAIサービスとデータ範囲も先に確認します。 許可範囲が分からない時は、送信前に担当者へ確認します。
レビュー依頼の流れ
1. 目的と非目的を書く
利用者から見た変更を1〜2文で書きます。
目的: ログアウト時にサーバー側セッションを無効化する
非目的: 認証方式と画面デザインは変更しない
2. 差分と前提を渡す
対象ファイル、関連する型やテスト、成功時と失敗時の仕様を示します。巨大なリポジトリ全体より、差分と直接の呼び出し元を選びます。
Gitでは次のコマンドで差分を保存できます。
git diff --staged > review.diff
内容を確認し、秘密情報や無関係な変更がない場合だけAIへ渡します。
3. 観点と優先度を指定する
今回の変更で壊れやすい場所を先に伝えます。
- 認証・認可
- 入力検証
- エラー処理
- 既存利用者との互換性
- 同時実行や二重送信
- テスト不足
すべてを同じ重さで求めず、重要な観点を2〜4個へ絞ります。
4. 出力形式を決める
各指摘に、優先度、場所、問題になる条件、根拠、確認方法を求めます。
優先度: 高 / 中 / 低
場所: ファイル名と行
問題: 何が起きるか
条件: どの入力や状態で起きるか
根拠: 仕様またはコード上の理由
確認: 再現手順や追加テスト
5. 人が検証する
指摘をそのまま修正へ変えません。該当コード、仕様、実行結果を確認し、正しい指摘だけを採用します。
そのまま使えるテンプレート
次の差分をレビューしてください。
変更目的:
- [利用者から見た目的]
変更しないこと:
- [対象外]
前提:
- [守る仕様や権限]
重点観点:
1. [最重要の観点]
2. [次の観点]
3. [必要なら追加]
各指摘は、優先度、ファイルと行、問題になる条件、
根拠、確認方法の順で示してください。
根拠を確認できない場合は推測と明記してください。
書式だけの好みは、動作や保守性へ影響する場合だけ指摘してください。
例：認可漏れを探す
プロフィール更新APIの差分を確認するとします。
悪い依頼:
このコードをレビューして。
改善した依頼:
本人だけが自分のプロフィールを更新できるAPIです。
管理者機能は今回の対象外です。
認証済みでも、URLのuserIdを書き換えて他人を更新できないか、
入力検証とエラー時の情報露出に絞って確認してください。
指摘には、問題になるRequest例と追加すべきテストを付けてください。
後者なら「ログインしているか」だけでなく「対象データを操作する権限があるか」を確認しやすくなります。
指摘を検証する
次の順番で1件ずつ確認します。
- 指摘された行と呼び出し元を読む
- 問題になる入力や状態を作る
- 既存テストを実行する
- 必要なら失敗を再現するテストを追加する
- 最小の修正後に同じ手順を再実行する
AIが存在しないAPIや古い仕様を前提にすることもあります。公式資料とプロジェクト内のversionを照合してください。
指摘を採用しない判断も記録します。たとえば「既存middlewareで認可済み」「この入力はschemaで拒否済み」のように根拠を残すと、同じ誤検知を繰り返し確認せずに済みます。反対に、再現できないだけで安全と決めず、権限条件や実行環境が揃っているかを見直します。
修正案を求める場合も、最初から大きな書き換えを依頼しません。問題を再現するtest、最小の変更、変更後の確認commandを順に求めると、AIの提案と検証結果を対応付けられます。
成功を確認する
AIへ依頼した後、次を確認します。
- 目的、非目的、前提を渡した
- 指摘にfile、発生条件、根拠、確認方法がある
- 少なくとも1件を再現するか、根拠を示して反証した
- secret、個人情報、未公開の認証情報を送っていない
指摘数が多いことではなく、採否を説明できることが成功です。
よくあるつまずき
差分だけを貼って目的を書かない
正しい動作を判断できません。目的、非目的、守る契約を短く添えます。
観点を増やしすぎる
回答が浅くなります。変更の危険度に合わせて優先順位を付けます。
指摘をまとめて自動修正する
誤った指摘も混ざります。1件ずつ再現し、テストで確認します。
秘密情報を貼る
token、Cookie、顧客データを入力しません。差分を送る前に内容を確認します。
練習
「問い合わせフォームへ文字数制限を追加した」という差分を想定し、テンプレートを埋めてください。
確認基準は次のとおりです。
- 目的に上限値と利用者への結果がある
- 空文字、上限ちょうど、上限超過を観点に含める
- frontendだけでなくserver側検証も確認する
- 指摘へ再現入力とテストを求める
- 個人情報をAIへ渡さないと明記する
まとめ
- 変更目的、非目的、前提を先に渡す
- 差分と関連範囲だけを選ぶ
- 観点へ優先順位を付ける
- 指摘には根拠と確認方法を求める
- AIの回答は人がコードとテストで検証する
次のステップ
次はコードレビューで意図とリスクを確認するチェックリストを使い、人間のレビュー観点も整理しましょう。
