AIレビューの指摘を取捨選択する判断軸｜直す・保留・落とす
「レビューして」とAIに頼んだら、指摘が20個も返ってきた。 ざっと見ると、確かに直したほうがよさそうなものもある。でも「それは好みでは？」というものや、「今回の変更と関係ある？」というものも混じっている。全部直すには時間が足りないし、全部無視するのも気持ちが悪い。——そこで手が止まってしまう。
この「指摘は出た。で、どれをやるの？」という所で詰まるのは、あなたの判断力の問題ではありません。 AIは指摘を出すのは得意でも、「あなたのチームにとってどれが重要か」までは知らないからです。だから、返ってきた指摘をそのまま作業リストにしない。一度、自分の手元で仕分ける。この記事では、その仕分けの判断軸を、コピーして使える問いかけ付きで整理します。
結論：AIレビューの指摘は「全部直す」でも「全部無視」でもなく、直す／保留／落とすの3つに仕分けます。判断の軸は2つだけ——①それは事実か、好みか（バグ・規約違反のような客観的な指摘か、スタイルの提案か）、②今回の変更の範囲内か（この差分の責任範囲か、別の話か）。①が事実で②が範囲内なら「直す」。事実だが範囲外、または良い提案だが今やる必要がないなら「保留」。好みの押し付け・仕様の誤読・すでに意図してそうしている所なら「落とす」。迷ったら「この指摘を採らなかったら、後で困るのは誰か」を考えると、たいてい仕分けられます。
指摘が多いのは、AIが優秀だからでも、あなたのコードが悪いからでもありません。 AIは「気づいたことを全部言う」ように振る舞うので、重要度がフラットに並びます。人間のレビュアーなら「まあこれはいいか」と飲み込む所まで、律儀に指摘として出す。だから多い＝全部やるべき、ではない。今日は、その山を落ち着いて仕分ける方法を、一緒に見ていきましょう。
なぜ「全部直す」でも「全部無視」でもうまくいかないのか
AIの指摘を「全部直す」と決めると、一見まじめですが、実は危うい進め方です。 好みレベルの提案まで取り込んでいくと、もともと意図してそう書いていた所まで書き換わり、設計が少しずつぶれていきます。しかも「AIが言ったから直した」という理由でコードが変わっていくと、後から「なぜこうなってる？」と聞かれても答えられない。時間もかかるわりに、品質が上がった実感が持ちにくい進め方です。
逆に「全部無視」だと、今度は本当に直すべきバグや抜けまで見送ってしまう。AIの指摘の中には、確かに拾っておいてよかったものが必ず混じっています。玉石混交だからと丸ごと捨てると、せっかくの一次フィルタが働きません。
だから、二択ではなく仕分けです。 指摘を一つずつ見て、「これは直す」「これは今回はやらない（保留）」「これは採らない（落とす）」と、自分の判断で振り分ける。採る・採らないを決めるのはAIではなく自分という形さえ保てれば、指摘が何個返ってきても、振り回されずに済みます。
ポイントは、仕分けそのものは難しくないということ。次の2つの軸で見れば、たいていの指摘はどこかの箱に落ち着きます。
判断軸①：それは「事実」か「好み」か
まず一つ目の軸は、その指摘が客観的な事実の指摘なのか、書き方の好みの提案なのかです。
- 事実の指摘：バグがある、null の考慮が漏れている、規約に違反している、テストが無い、タイポがある——正しい／間違っているがはっきり言えるもの。
- 好みの指摘：この書き方のほうが読みやすい、この関数は分割したほうがいい、命名はこうしては——どちらもあり得る、程度問題のもの。
事実の指摘は、基本的に採る方向で考えます。バグや抜けは、好き嫌いの問題ではないからです。 一方、好みの指摘は、採ってもいいし採らなくてもいい。あなたのチームの慣習や、そのコードの事情に照らして決めます。AIが「分割すべき」と言っても、今の粒度に理由があるなら、そのままでも構いません。
ここで大事なのは、AIは両方を同じ断定口調で書くということです。 「ここはバグです」も「ここは分割すべきです」も、同じくらい自信ありげに並びます。だから口調に引っ張られず、「これは事実の話か、好みの話か」を自分で見分ける。事実なら重く、好みなら軽く扱う。この一段だけで、指摘の山がかなり整理されます。
見分けが難しいときは、「この指摘は、別の優秀なエンジニアなら全員そう言うか」と考えてみてください。全員が同意しそうなら事実寄り、意見が割れそうなら好み寄りです。
判断軸②：今回の「変更の範囲内」か
二つ目の軸は、その指摘が今回の差分の責任範囲に入っているかです。
AIにレビューを頼むと、変更した行のすぐ隣にある前からあった問題まで指摘してくることがあります。「ついでにここも直したら」という提案です。 それ自体は親切なのですが、今回のPRで全部背負う必要はありません。今回の変更と関係ない改善まで混ぜると、差分が膨らんで、レビューする人も「結局この変更は何をしたの？」と分かりにくくなります。
だから、範囲の軸で見ます。
- 範囲内：今回自分が変更した所に関する指摘 → 今回のスコープで対応を検討。
- 範囲外だが正しい：今回と関係ないが、確かに直したほうがいい所 → 保留（別チケット・別PRに回す）。「無視」ではなく「今はやらない」として記録に残す。
- 範囲外で今やる意味が薄い：昔からある些細な所 → 落とすか、気になれば保留メモだけ。
「良い指摘だけど、今回じゃない」を保留という箱で受け止められると、心理的にも楽になります。 捨てるのは惜しいけれど、今のPRに入れると散らかる。そういう指摘を、罪悪感なく後ろに送れる。保留は「見なかったことにする」ではなく、「タイミングを分ける」という前向きな判断です。
2つの軸を組み合わせた早見表
2つの軸を掛け合わせると、指摘の行き先がだいたい決まります。迷ったときの目安にしてください。
| 指摘の性質 | 今回の変更の範囲内 | 範囲外 |
|---|---|---|
| 事実（バグ・抜け・規約違反） | 直す | 保留（別PRで直す） |
| 好み（読みやすさ・分割の提案） | 保留 or 直す（余力しだい） | 落とす（or 気になれば保留メモ） |
| 仕様の誤読・的外れ | 落とす（なぜ違うか一言残す） | 落とす |
| すでに意図してそうしている所 | 落とす（意図をコメントに残すと吉） | 落とす |
太字が、その組み合わせでいちばん多い行き先です。 表のいちばん大事な行は一番上——事実で、範囲内なら、直す。ここが仕分けの背骨です。あとは「範囲外なら後ろに送る」「好みは余力しだい」「的外れ・意図済みは落とす」と流していけば、20個の指摘も数分で振り分けられます。
なお「落とす」を選んだとき、なぜ落としたかを一言だけ残すと後で効きます。特に仕様の誤読を落とすときは、「これは仕様上こうしている」とコードのコメントやPRの返信に書いておくと、次に同じ指摘が来ても迷いません。的外れな指摘を「なぜ的外れか」説明できると、自分の理解も一段深まります。
迷ったときの最後の問い
軸で分けても、どっちの箱か迷う指摘は必ず残ります。 そんなときは、一つの問いに戻ってください。
この指摘を採らなかったら、後で困るのは誰か。
- 採らないとユーザーや本番が困る（バグ・データ・セキュリティ）→ 迷わず直す。範囲外でも保留で必ず拾う。
- 採らないと将来の自分やチームが少し困る（読みにくさ・保守性）→ 保留。余力があれば直す。
- 採らなくても誰も困らない（好みの押し付け・些細な体裁）→ 落としてよい。
困る相手が「本番・ユーザー」なら重く、「将来のチーム」なら中くらい、「誰も」なら軽く。 この問いは、実は判断軸①②を一つにまとめたものです。困る相手の大きさ＝事実性の高さと影響の大きさ、だからです。迷ったらこの一問に立ち返れば、たいていの指摘は落ち着く先が見えます。
そして忘れてはいけないのが、AIが何も言わなかった所。 指摘の仕分けに集中していると、「指摘リストを全部さばいた＝レビュー完了」という気になりがちです。でも、AIの沈黙は「問題なし」の意味ではありません。設計の妥当性やセキュリティは、AIが触れていなくても人が見る所です。仕分けは「出てきた指摘の処理」であって、レビューそのものの代わりではない——ここだけは押さえておきましょう。この線引きはAIにコードレビューの一次チェックを任せる｜範囲と注意点にも整理しています。
AIに頼むときに、仕分けやすくしておく
そもそも、指摘をもらう段階でひと工夫すると、仕分けがぐっと楽になります。 「レビューして」だけだと重要度がフラットに並びますが、出力の形を指定すると、最初から仕分けの助けになる形で返ってきます。
聞き方の例：
この差分をレビューして、気づいた点を指摘してください。
指摘ごとに、次を添えてください。
- 場所（ファイル/関数のあたり）
- 種別：【バグ・抜け】か【規約違反】か【読みやすさの提案】か【その他】か
- なぜ気になるか
- 直し方の案（断定でなく提案として）
- 確信度：高い / 要確認
今回の変更と直接関係ない「ついでの改善」は、その旨を明記してください。
マージ可否の判断はしなくて大丈夫です。指摘の洗い出しだけお願いします。ポイントは、種別（事実か好みか）と、今回の範囲内かどうかを、AI自身に添えさせること。 判断軸①②に対応する情報を最初からもらっておけば、あなたは「その仕分けが妥当か」を確認するだけで済みます。もちろんAIの自己申告は完璧ではないので、種別が怪しい所は自分で見直しますが、ゼロから仕分けるより、たたき台があるほうがずっと速いです。「確信度：要確認」が付いた指摘は、特に自分の目で確かめる、という使い分けもできます。
ありがちな落とし穴と、その回避
指摘の取捨選択で、つまずきやすい所を先に潰しておきます。
- 多さに気圧されて全部やろうとする：件数は重要度ではありません。まず事実／好みで分け、好みは後回しにしていい。
- AIの断定口調を重要度と勘違いする：「〜すべきです」の強さは確信度ではない。種別と確信度を添えさせ、自分で重みを決める。
- 良い指摘を「今回じゃない」と全部捨てる：捨てるのではなく保留（別PR）に送る。惜しい指摘を記録に残すと、あとで効いてくる。
- 意図してそう書いた所を、指摘されるまま直す：AIは背景を知りません。理由があるなら落としてよい。ついでに意図をコメントに残すと親切。
- 指摘を全部さばいて満足する：AIが触れなかった設計・セキュリティは、沈黙していても人が見る。仕分けはレビューの代わりではない。
- 仕分けの基準を毎回ゼロから考える：軸は「事実か好みか」「範囲内か」の2つだけ。この2軸を固定すると、判断がぶれずに速くなる。
落とし穴のほとんどは、「指摘の数」に飲まれた瞬間に生まれます。 数ではなく、一つずつを2軸で見る。この構えさえ持てれば、返ってきた指摘が多くても、落ち着いてさばけます。
明日からやること（小さく始める3つ）
いきなり仕組みにしようとせず、まずこの3つから。
- 次のAIレビューで、指摘を「直す／保留／落とす」の3つに手で分けてみる：紙でもメモでも十分。まず仕分ける癖をつけます。
- プロンプトに「種別」と「今回の変更と関係あるか」を添えさせる1文を入れる：たたき台が仕分け向きの形で返ってきます。
- 落とした指摘に、なぜ落としたかを一言だけ残す：特に「意図してこうしている」「仕様上こう」は、後の自分とチームを助けます。
この3つだけでも、「指摘が多くて手が止まる」瞬間が、少し軽くなります。
コピーして使う「指摘の仕分けシート」
AIレビューの指摘を受け取ったら、上から順に振り分けてください。一度に全部でなく、気になる指摘だけでも十分です。
# AIレビュー指摘の仕分け
## 指摘ごとにチェック
- 指摘の内容：
- ① 事実か好みか（バグ/規約=事実、読みやすさ/分割=好み）：
- ② 今回の変更の範囲内か（範囲内 / 範囲外）：
- 迷ったら：採らないと後で困るのは誰か（本番・ユーザー / 将来のチーム / 誰も）：
- → 行き先：直す / 保留（別PR・別チケット） / 落とす
- （落とすなら）理由の一言：
## さばき終えたら、最後に必ず
- AIが触れなかった所（設計・仕様・セキュリティ）を、自分で見たか：
- 「指摘を処理した」で終わらず「レビューとして通していいか」を自分で判断したか：仕分けの前後チェックリスト
指摘を受け取ったときと、対応を終えたときに、さっと確認します。全部に○が要るわけではなく、関係する所だけで十分です。
指摘を受け取ったとき
- 指摘を「直す／保留／落とす」に仕分けたか
- 「事実か好みか」でいったん重みづけしたか
- 「今回の範囲内か」で保留に回すものを分けたか
- 断定口調に引っ張られず、確信度を自分で見たか
対応を終えたとき
- 良い指摘を「今回じゃない」と捨てず、保留として記録したか
- 落とした指摘に、理由を一言残したか（特に仕様・意図）
- AIが触れなかった所（設計・セキュリティ・仕様）を、自分で見たか
- 「AIが言ったから」ではなく「自分が採ると決めたから直した」と言えるか
最後に
指摘が山ほど返ってきて、どれから手をつけるか分からず手が止まる。 その状況を「自分の判断が遅いせいだ」と感じてしまうこと、ありますよね。でも、フラットに並んだ指摘を前にすれば、誰だって一瞬ひるみます。多いのは、あなたの問題ではなく、AIの出し方の特性です。
全部を直さなくて大丈夫です。今日ひとつ、返ってきた指摘を「直す・保留・落とす」に分けてみる。それだけで、AIレビューとの付き合い方が、少し軽くなります。 指摘を出す前段の頼み方はAIにコードレビューの一次チェックを任せる｜範囲と注意点に、AIが書いたコードを受け取る側の型はAI生成コードのレビュー・検証チェックリストに整理しています。採るか採らないかを、自分で決める。その一点さえ手放さなければ、指摘がどれだけ増えても、あなたが振り回されることはありません。