Claude Code Reviewの指摘は解消しないと再カウントされる

Claude CodeのCode Reviewは、同じPRへの2回目以降のレビュー(フォローアップレビュー)で、前回までの指摘のうちまだ開いたままのものを一覧にして出します。Claude Code v2.1.268では、その一覧の下に注記が1行加わりました。指摘スレッドへ返信しただけでは解消扱いにならず、スレッドを解消しない限り、後続のレビューでも開いたままとして数えられるという内容です。

フォローアップレビューの「開いたまま」とは何か

Code Reviewは、PRが開いてから2回目以降にレビューが走ると、前のレビューで見つかった指摘のうち解消されていないものをまとめて示します。ここでいう「解消(resolve)」は、コードの直し方ではなく、GitHubのレビュースレッドが持つ解決状態を指します。

v2.1.268のchangelogには次の記述があります。

[Code Review] Added a note under the still-open findings list in follow-up reviews: resolving a finding's thread, not just replying to it, stops later reviews from counting it as open

指摘はPRのインラインコメントとして投稿され、返信を重ねると1本の会話(スレッド)になります。スレッドにはGitHub標準の解決操作(Resolve conversation)があり、実行すると会話全体が解決済みになります。この解決状態が、フォローアップレビューが「開いたまま」と数えるかどうかの分かれ目です。

フォローアップレビューが走る条件は、リポジトリごとのレビュー動作(Review Behavior)で変わります。

どのモードでも、フォークからのPRは@claude reviewを投稿したときだけレビューされます。トリガーモードの全体像はClaude CodeでGitHub PR自動レビューを設定・運用するにまとめています。

返信やリアクションでは指摘は消えない

インラインコメントへの返信に、Claudeは応答もPRの更新もしません。各コメントには👍👎があらかじめ付いていますが、集計されるのはPRのマージ後で、Anthropicがレビュアーの調整に使います。リアクションは再レビューもPRの状態変更も起こしません。

返信も👍/👎も、スレッドを解決済みにする操作ではありません。何をするとスレッドが閉じ、何をしても開いたままなのかは、操作ごとに分かれます。

コードを直さずに指摘を却下したいとき

誤検知だったときや、意図的に直さないと決めたときは、コードを変える必要がありません。取る操作は1つで、そのスレッドをResolve conversationで解決済みにすることです。返信で理由を書き残しても却下にはならないので、理由を残したいなら返信を書いたうえで、続けて解消まで行います。

push購読は「After every push」モードのほか、@claude review alwaysでも成立します。管理画面の分析には、開発者が対処したことで自動解消されたコメントの件数が「Feedback」として載ります。

2.1.268以降にCode Reviewに入った修正

解消状態まわりでは、v2.1.268のあとにも関連する修正が続いています。

指摘が消えないときの切り分け

次のレビューでも同じ指摘が残るときは、上から順に確かめます。

pushせずに再レビューだけを走らせる

スレッドを解消したあと、pushせずに一覧が更新されるかを見たいときは、@claude reviewをPRのトップレベルコメントとして投稿します。購読設定を変えない単発のレビューが走ります。フォーク以外のPRなら、「Claude Code Review」チェックのRe-runでも、購読せずに新しいレビューを始められます。

gh pr comment 123 --body "@claude review"

alwaysを付けない限り、以後のpushは購読されません。onceを付けた@claude review onceも同じ単発の動作です。2026年7月の更新より前は、@claude reviewだけでpush購読になっていました。そのころの動きを前提にしている運用は、@claude review alwaysに書き換えます。

コマンドが効く条件は4つあります。

• トップレベルのPRコメントで、コマンドがコメントの冒頭にある
• リポジトリへのwrite・maintain・admin権限がある
• PRがopenである
• 組織のメンバーシップが非公開(GitHubの既定)のときは、リポジトリのコラボレーターとして直接追加されている

最後の条件に当たると、Claudeは👀のリアクションを付けても、レビューを始めません。組織のメンバーシップを公開にすれば解消します。下書きPRでも、手動のコマンドなら動きます。自動のトリガーは下書きPRを対象にしないため、下書きのまま再レビューを走らせたいときは手動コマンドで走らせます。すでにレビューが走っているPRでは、新しいリクエストは実行中のレビューが終わるまで待たされます。レビューの所要時間は平均20分で、進み具合はPRのチェック実行で見られます。

チェック実行の結果とスレッドの解消は別物

PRの「Claude Code Review」チェック実行の「Details」には、そのレビューで見つかった指摘の重大度別の一覧が出ます。重大度は🔴 Important・🟡 Nit・🟣 Pre-existingの3段階です。

チェック実行の結論は常にneutralで、ブランチ保護でマージを止めることはありません。ただし、ブランチ保護で会話の解決(Require conversation resolution before merging)を必須にしていると、未解決のスレッドがマージを止めます。

マージを止めたいなら、Detailsの末尾にある機械可読のコメントをCI側で読んで判定します。チェック実行のIDは、コミットのチェック実行一覧から探します。

gh api repos/OWNER/REPO/commits/<commit-sha>/check-runs \
  --jq '.check_runs[] | {id, name}'
gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
  --jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'

返るのは{"normal": 2, "nit": 1, "pre_existing": 0}のようなJSONです。normalが🔴 Importantの件数で、0より大きければ、マージ前に直す価値のあるバグが1件以上あります。🟡 Nitは直す価値はあっても止める必要はない指摘、🟣 Pre-existingはこのPRより前からあるバグです。

各指摘には折りたたみの「Why this was flagged」が付き、なぜ指摘したか、どう検証したかを読めます。開いたままの指摘が誤検知に見えたら、ここを読んでからスレッドを解消するか、直すかを決められます。

REVIEW.mdの収束ルールとは別の仕組み

REVIEW.mdには、すでにレビュー済みのPRでのClaudeの振る舞いを決める「再レビュー時の収束ルール」を書けます。たとえば「最初のレビュー以降は新規のNitを出さず、Importantだけを投稿する」といった書き方です。1行の修正が、スタイルだけで7回目のレビューに達するのを防げます。Nitの件数に上限を置く書き方もあります。「1回のレビューで最大5件まで。超えた分は件数だけを要約に書く」といった例が、公式のREVIEW.mdの記述例にあります。

これは今後投稿される指摘の量を絞る設定で、投稿済みの指摘が開いたままか閉じたかには作用しません。新しいNitの増加を止めたいならREVIEW.md、すでに出た指摘を片付けたいならGitHub上での解消と、手を入れる場所が分かれます。REVIEW.mdの調整項目はREVIEW.mdカスタマイズでClaude Codeの自動レビュー基準を変えるで扱っています。

この注記は、changelog上はCode Reviewのフォローアップレビューの項目です。実行経路の使い分けはClaude Codeコードレビュー — 4つの実行経路の使い分けにあります。ローカルの/code-reviewやultrareviewもそこで比べています。

まとめ

「Once after PR creation」や「Manual」のリポジトリでは、pushしても自動解消は起きません。修正後も指摘が残りやすいのはこの設定なので、スレッドの解消を手で行う前提で運用すると食い違いが出ません。