AIレビューの指摘が多すぎて読まれないとき、どこで絞り、どこから読むか

自分で作っているAIレビューのRiver Reviewを個人の開発で使っていて、困ったことがあります。指摘が細かく、対応するかしないかを1件ずつ判断すること自体が負担になりました。AIが実装し、AIがレビューし、自分はその間で判断を中継しているだけのように感じたのです。

指摘の多さは、それ自体が問題になります。どれを読めばよいか分からない指摘は、読まれません。読まれない指摘は、0件と同じ結果になります。

量を測るなら、直近20件ほどのプルリクエストで、1件あたりのAI指摘数（重複を除く）と採用率を数えます。採用率は、重複を除いた指摘のうち、修正された、または明示的に受け入れられたものの割合です。保留や却下は採用に数えません。

この記事では、出す前に落とす、読む順番を決める、後で見る指摘を分ける、抑制を検証する、の順に線引きを整理します。例として引くRiver Reviewの実装は2026年9月24日時点のもので、将来の互換性は保証されません。

1. 指摘を減らす前に、指摘を「出す前」に落とす

件数を減らす第一段は、人が読む前に「形式として成り立たない指摘」を機械で落とすことです。ただし、機械で確かめられるのは形式と根拠の有無までです。「今回のプルリクエストで止めるべきか」という意味の判断は、機械では決まりません。この2つを分けて設計します。

River Reviewの現在の実装では、AIが出した指摘を、LLMを使わないルールで検査しています。主な項目は次のとおりで、いずれも書式の検査です。

根拠（Evidence）が書かれているか
根拠でファイル名を挙げたなら、そのファイルが差分に含まれているか
ある程度の長さの修正提案があるか
重要度が、その観点で宣言した上限を超えていないか
指摘の工程（設計・実装・テスト）が、ファイルの種類や観点の宣言と噛み合っているか

検査に通らなかった指摘は、出力から外れます。

ここで区別したいのが、「根拠の置き場所」と「問題の所在」です。根拠の置き場所は、指摘の裏付けとして示す差分の箇所です。問題の所在は、指摘している問題があるコードです。根拠で差分の外のファイルを名指しした指摘は落とします。一方、問題の所在が既存コードにあることは、それだけでは落とす理由にしません。範囲の情報として残し、扱いは次章の並び順で決めます。

意味の判断を担う層は、River Reviewでも設計課題として残っています。レビュー方針では、意図がコメントで説明されていれば軽微な指摘は取り下げてよい一方、セキュリティ・データ喪失・正しさのリスクは取り下げないと決めています。減らしすぎへの歯止めです。

既製ツールを使う場合は、ツールのレビュー指示に「根拠として、差分に含まれるファイルと箇所を示す」「意図が説明されている軽微な点は指摘しない」と書くのが代わりの手段になります。

持ち帰る問い: 自分たちのAIレビューは、人に見せる前に何を落としているか。意味の判断まで機械に任せていないか。Noなら、まずレビュー指示に「根拠として差分の箇所を示す」ことを必須として書きます。

2. 読む順番を決める：先頭で「直すべきものがあるか」だけ分かるようにする

全件を同じ重さで並べると、読まれません。レビュー結果を開いたとき、最初の数行で「マージ前に直すものがあるか」が分かる必要があります。

River Reviewのレビュー方針では、提示順を次のように決めています。

判定と重要度別の件数を、本文の最初の1行にまとめる
Critical と Major は展開し、Minor と Info は折りたたむ
折りたたみの見出しには件数を書き、開かなくても規模が分かるようにする
折りたたみは省略ではない。折りたたんだ節にも指摘の全文を残す

折りたたみは削除とは違います。第1章で残した「問題の所在が差分の外にある指摘」も、消さずに後ろへ回します。

並び順にも考え方があります。現在の実装では、複数のレビュアーの合意度、重要度、差分の内か外か、の順に並べます。差分の内か外かを先頭の基準にしないのは、「この差分の外にある」ことは「重要でない」ことではないからです。複数の観点が一致した既存コードの重大な指摘が、1つの観点だけが挙げた軽微な指摘より後ろに回ってはいけません。差分の内外は、同じ重さの指摘どうしの並びを決めるときだけに使います。

既製ツールを使う場合は、重要度の高い指摘だけをプルリクエストの要約欄やチャット通知に流す方法があります。要約欄には重要度別の件数を出させ、軽微な指摘は消さずに後ろへ回します。

持ち帰る問い: レビュー結果を開いて、最初の数行で「直すべきものがあるか」が分かるか。Noなら、まず重要度の高い指摘の件数だけを先頭の要約に出すようにします。

3. 後で見る指摘を分ける：「通すが、後で人が見る」

絞っても、軽微な指摘は残ります。その全件をマージ前に読ませると、第2章で決めた順番も埋もれます。そこで、今すぐ読む指摘と、後でまとめて見る指摘を分けます。

River Reviewは、判定の信号として次の4つを返します。実際に進めるか止めるかは、呼び出し側が決めます。

信号	意味
GO	通す
GO_WITH_OBSERVATION	通すが、後で人が見る
NO_GO	止めて直させる
ESCALATE	人に判断を渡す

指摘の量を減らすうえで効くのは、GO_WITH_OBSERVATIONです。現在の実装では、たとえば止めるべき指摘がなく、人の確認を勧める程度の指摘だけが残ったときにこの信号になります。マージは止めず、見る予定も消さない出口です。

ただし、後で見る指摘は、いつ誰が見るかを決めないと読まれずに溜まります。週に一度やリリース前など、まとめて確認する時期と担当を決めます。

既製ツールを使う場合は、軽微な指摘を専用のラベルや一覧に集め、プルリクエストの画面から外す方法が代わりの手段になります。

持ち帰る問い: 今すぐ読む指摘と、後で見る指摘を分けているか。後で見る指摘を、いつ誰が見るか決めているか。Noなら、まず軽微な指摘の置き場所と見る日を決めます。

4. 指摘を黙らせる仕組みにも検証が要る

黙らせた指摘の一覧を、いつ、誰が見直していますか。抑制、resolve、学習させたルールなど、形はツールによって違います。

毎回同じ指摘が出るとノイズになるので、抑制（suppression）は必要です。ただし抑制は「黙らせる」操作です。期限、取り消し、レビュー基準を変えたときの扱いを設計しないと、効かない抑制や、効きすぎる抑制が生まれます。

自分でも踏みました。River Reviewの抑制に「レビュー基準が変わったら止める」失効条件を追加し、本番のレビュー経路で効くか確かめたところ、抑制を登録する機能で作った抑制が、そもそも1件もレビューに届いていませんでした。登録は成功し、一覧にも残るので、効いているように見えていました。実際には、それまでずっと効いていなかったのです。直すと今度は、取り消し済みの抑制まで効くようになりました。

これはExperimentalな機能で観測した一例です。現在の実装では、抑制の期限と取り消しを見ており、基準を変えたときに抑制を止める判定も任意で有効にできます。ただ、この経緯から分かるのは、ノイズを減らす仕組みも、それ自体を検証しないと信用できないということです。

既製ツールを使う場合は、resolveした指摘、無視させた指摘、レビュー指示で除外した観点を一覧にしておき、決めた時期に見直すのが代わりの手段になります。

持ち帰る問い: 抑制を作ったあと、それが実際に効いているか、効きすぎていないかを確かめる手段を持っているか。Noなら、まず黙らせた指摘の一覧を見直す日を決めます。四半期ごとや、レビュー基準を変えたときが目安です。

まとめ：どこで絞り、どこから読むか

AIレビューの指摘を読まれるものにするために、次の4つを決めます。

出す前に機械で落とす条件と、機械に任せない意味判断の線引き
先頭に何を置くか、読む順番と折りたたむ範囲
今すぐ読む指摘と後で見る指摘の分け方と、後で見る時期と担当
抑制の期限と取り消し、抑制が効いているかの確かめ方

着手は手間の小さい順がおすすめです。まず直近のプルリクエストで指摘数と採用率を測り、基準にします。次に、出させたくない指摘をレビュー指示に書き、重要度別の件数を先頭に出します。最後に、後で見る指摘と黙らせた指摘を見直す日を決めます。

冒頭に書いた「判断を中継しているだけ」という感覚は、この線引きがないまま全件を1件ずつ受け取ることから来ていたと考えています。線引きを先に決めておけば、マージ前に読むのは先頭に並んだ重い指摘だけになり、残りは決めた日にまとめて見られます。