AIにコードレビューさせるとき、「重要な指摘だけしてください」と書くのは逆効果です。最近のモデルはその指示に忠実に従うため、バグを見つけたうえで「重要度が低い」と判断して報告を落とします。まず全部報告させ、絞り込みは別工程でやる——これだけで拾える問題の数が変わります。
AIレビューを導入したのに大した指摘が出てこない。それはモデルの能力ではなく、こちらの指示が原因かもしれません。この記事では実務で効く使い方と、ツールの役割分担を整理します。
なぜ「重要な指摘だけ」が逆効果なのか
レビュープロンプトに「高重要度の問題だけ報告して」「保守的に」「細かい指摘は不要」と書くと、モデルは調査自体は同じ深さで行ったうえで、自分が設定された基準に満たないと判断した発見を報告しません。
結果として精度（報告のうち本物の割合）は上がりますが、拾えたはずの問題が黙って捨てられます。これは能力の問題ではなく、指示に忠実であることの副作用です。
代わりにこう書く
「見つけた問題は、確信が持てないものや軽微だと思うものも含めて全て報告してください。この段階では重要度で絞り込まないでください——絞り込みは別の工程で行います。各指摘には確信度と推定される重大度を添えてください。」
実際に別工程を用意しなくても効果があります。「絞るのはあなたの仕事ではない」と伝えることが本質です。
「重要な」という曖昧語を使わない
どうしても1回で絞りたいなら、基準を具体的に書いてください。「重要なものだけ」ではなく「誤動作・テスト失敗・誤った結果につながりうるバグは全て報告し、命名や書式の好みだけは除外する」のように書きます。曖昧な形容詞はモデルごとに解釈が変わります。
ツールの役割分担
| GitHub Copilot | Claude Code | |
|---|---|---|
| 設計思想 | IDE統合のマルチモデルプラットフォーム型 | リポジトリ全体を理解するエージェント型 |
| 得意 | 手元の速度 | 大きな仕事 |
| レビュー | PRを送ると自動で指摘（Copilot Code Review） | 文脈を踏まえた深い読み |
| コスト感 | 月額枠で日常作業を広く回す | 重い作業に使用量を集中させる |
Copilot Code Review はプルリクエストを送るだけで指摘が返る手軽さが強みで、累計6,000万件以上のレビューを処理した実績があります。日常の一次フィルタとして優秀です。
実務で効く「AI相互レビュー」
単一ツールで書いて同じツールでレビューすると、同じ思い込みを見逃します。実装と review で別のツールを使うのが実践的です。
補完とチャットで手を速く動かします。
リポジトリ全体の文脈を踏まえた読みが入ります。ここで前述の「全部報告させる」プロンプトを使います。
AIの指摘を鵜呑みにしないこと。特に「動くが非効率」系の指摘は、そのコードベースの事情を知らないと的外れになります。
ツールの詳しい比較は自律agent型AIコーディングツール比較にまとめました。レビューを独立したコンテキストで走らせたい場合はSubagentsの使い方が効きます。
AIレビューが苦手なこと
期待しすぎると失望するので、線引きを持っておくと良いです。
- そのプロジェクト固有の事情——「ここは意図的にこう書いている」を知らないので、正しい実装を指摘してくることがあります。
- 設計レベルの是非——コードとして正しくても設計として間違っている、という判断は文脈依存です。
- 性能の実測——「遅そう」は言えても、実際に遅いかは測らないと分かりません。
逆に得意なのは、見落としやすい具体的な欠陥——境界値、null/undefined、エラーハンドリング漏れ、非同期処理の競合など。人間が疲れて見落とす領域です。この住み分けを理解して使うと、期待値のズレが減ります。
まとめ
AIレビューの精度を上げる一番効く操作は、モデルを変えることではなく「絞り込むな」と伝えることでした。全部報告させて、確信度と重大度を添えさせ、絞るのは自分がやる。
そのうえで、実装とレビューでツールを分けると見落としが減ります。最後に人間が判断する工程だけは省かないでください。プロジェクト固有の事情を知っているのは自分だけです。
コメント