直接回答
コーディングエージェントは自動承認者ではなく、一次レビュー担当として使います。base と head のコミット、リポジトリ規約、リスク順位、読み取り専用の検証コマンドを固定し、各指摘にコード位置、発生条件、観測できる影響、再現手順を求めてから、人間が採否と重要度を決めます。
重要な結論
- base と head のコミットを固定し、レビュー中の対象変更を防ぎます。
- スタイルより先に正しさ、セキュリティ、データ損失、テスト不足を確認します。
- 具体的な挙動と検証経路を示せない指摘は欠陥として扱いません。
- マージ承認と高リスク修正は責任を持つ保守担当者が判断します。
重要な事実
このガイドで解決できること
不要な書き込み権限を与えず、実行可能な指摘を得られる AI 支援レビューを設計する。
検証範囲と制約
- 証拠の種類
- 公式ドキュメントローカル検証
- 検証範囲
- 変更範囲、リスク別確認、指摘の証拠、読み取り専用検証、保守担当者の選別、修正後レビューを対象とします。
- 制約と失効条件
- - エージェントは欠陥が存在しないことを証明できず、専門的なセキュリティ・コンプライアンスレビューを代替しません。
- - 利用可能なコマンドと権限制御は、クライアントのバージョンとリポジトリ環境に依存します。
レビュー対象と受け入れ境界を固定する
変化し続ける作業ツリーではなく、明示した base と head のコミットを使用します。要件、対象サービス、リポジトリ規約、通常の検証コマンドを渡し、生成ファイルや無関係なリファクタリングは必要に応じて除外します。
エージェントは最初に変更ファイルと想定リスクを要約します。途中で diff が変わった場合は、新しいコミット範囲でレビューをやり直します。
スタイルより先にリスク別の確認を行う
挙動の回帰、認可、データ変更、並行処理、エラー処理、互換性、テスト不足を別々に確認します。広すぎる一つの質問では、重要な問題と好みの指摘が混在します。
- 変更された入力から副作用と外部出力までを追跡します。
- 失敗経路、再試行、後始末、部分書き込みを確認します。
- 追加された分岐と境界条件をテストに対応付けます。
- 可読性や危険性に影響しない書式・命名は後回しにします。
指摘ごとに証拠の形式を決める
各指摘には、対象ファイルまたはシンボル、発生条件、観測される結果、重要度の根拠、検証方法が必要です。「失敗する可能性がある」だけでは、どの状態が失敗分岐に到達するか示すまで実行可能ではありません。
確認済みの欠陥、質問、残存リスクを分離させます。これにより、不確実な項目を直ちにブロッカーにせず調査できます。
制約された環境で重要な指摘を検証する
問題を確認できる最小のテスト、型チェック、静的クエリ、lint を実行します。修正は別タスクとして承認されるまで読み取り専用を維持し、ローカル経路の再現のために本番認証情報や無制限ネットワークを渡しません。
全テストが高コストなら、実行した範囲と未検証部分を記録します。隠れた不足がある緑色の結果より、正直な範囲説明の方が有用です。
保守担当者のゲートで指摘を選別する
保守担当者は、指摘が意図した挙動に該当するかを再現し、種類と重要度を決め、マージ可否と修正担当を判断します。重複や無効な指摘も、今後のレビュー指示を改善する材料になります。
- 01確認固定したリビジョンで挙動を再現します。
- 02分類欠陥、設計上の質問、テスト不足、好みを分けます。
- 03判断チーム規約に従って重要度とマージ影響を決めます。
- 04再確認修正を新しい diff として確認し、関連テストを再実行します。
実際のレビュー結果から手順を改善する
採用、却下、見落としの例を少数だけ匿名化して保存し、リスク質問とリポジトリ指示を改善します。普遍的な検出率の主張には使わず、ビルドや権限が変わったら手順を再検証します。
公式情報と検証範囲
本ガイドは公開されている公式ドキュメントを根拠にしています。コマンドや設定はクライアントのバージョンにより変わるため、実行前に参照元も確認してください。
技術検証方法を見る