Claude Code Reviewがスキップ・失敗するときの切り分け — check runタイトル別
Claude Code Reviewのcheck runのタイトルから、skipped・declined・failed・timed outの意味と対処、予算切れコメントの3文言、check runが出ないときの確認先を切り分けます。
Claude Code ReviewがPRで動かないときは、PRに付くClaude Code Reviewというcheck runのタイトルを読みます。タイトルが、レビューがどこまで進んだかをそのまま示しています。タイトルごとに、やることはほぼ決まっています。
先に注意点が1つあります。このcheck runは、失敗(failure)で終わることがありません。レビューが終わったときはneutral、pushでファイルが変わらず自動レビューが走らなかったときはskippedになります。Checksが緑や灰色でも「レビューされた」とは限りません。
タイトルから原因を引く早見表
| check runのタイトル | 意味 | やること |
|---|---|---|
| Code review queued... / in progress... | 意味まだ終わっていない | やることタイトルが変わるまで待つ |
| Code review found no issues | 意味終了し、指摘なし | やることなし |
| 指摘ありを示すタイトル | 意味終了し、指摘あり | やることdiffに見えなければ後述の場所を探す |
| Code review skipped — no new changes | 意味最新のpushでは自動レビューが走らなかった | やること必要なら@claude reviewとコメント |
| Code review failed / timed out | 意味最後まで終わらなかった | やることコメントかRe-runでやり直す |
| Code review declined | 意味レビューが走らなかった | やることサマリーを読み、予算・上限の話なら管理者へ |
| check runが無い | 意味レビューが始まっていない | やること@claude reviewを試し、それでも出なければ設定を疑う |
このうち、原因が1つに決まらず迷いやすいのは「check runが無い」「declined」「skipped」の3つです。以降は症状ごとに順に見ます。
skipped — no new changesは「変更が無かった」というだけ
タイトルが「Code review skipped — no new changes」なら、直近のpushでレビュー対象のファイル変更が無く、自動レビューが走らなかった状態です。壊れているわけではありません。ファイルを変えないpushでは自動レビューが走らない、という仕様どおりの挙動です。
それでも最新の状態をレビューしてほしいときは、PRに新しいトップレベルのコメントとして@claude reviewと書きます。このコマンドは、PR全体をもう一度レビューします。
check runが出ないときの確認順
check runが1つも出ないときは、次の順で確認すると早く絞れます。
- draftのPRか、フォークからのPRか: 自動レビューはどちらも対象外です。
@claude reviewをコメントして始めます - Review runsがManual (@claude review)か: PRを開いてもpushしてもレビューは始まりません。
@claude reviewを一度コメントします - Allow code reviewがオンで、リポジトリがRepositoriesに載っているか: 載っていなければ、Ownerが管理画面のAddから追加します
- ClaudeのGitHub Appがそのリポジトリにアクセスできるか: 次節の「Add a repositoryに出ない」を見てください
設定の側がそろっているのにcheck runが出ない場合は、コマンドの打ち方に原因があることが多いです。
@claude reviewが空振りする4つの原因
コメントに👀のリアクションが付いても、レビューが始まるとは限りません。確認すべきなのは、Code review queued...またはin progress...というcheck runが出たかどうかです。出ないときは次を確認します。
- リポジトリでCode Reviewがオンになっていない: コメントもcheck runも付きません。Ownerにリポジトリを追加してもらいます
- コメントが条件に合っていない: インラインコメントやレビュー本文は無効です。コマンドはコメントの先頭に置きます。既存コメントの編集も数えられず、PRがopenであることも必要です
- write権限が無い: write、maintain、adminのいずれかが必要です。フォークPRで見られるのはベースリポジトリ側の権限です。組織のtipsがオンなら、「No review was started: manual reviews can only be requested by someone with write access to this repository.」と返ります
- 予算が尽きている: 「⚠️ Code review skipped」で始まるコメントが付きます
この条件は、手順としてはClaude CodeのGitHub PR自動レビューの設定記事にも書かれています。ここでは、上のどれに当たるかを症状から引く使い方に絞ります。
予算切れのコメントは文言で原因が分かれる
組織の予算でレビュー費用をまかなえないとき、Code ReviewはレビューをスキップしてPRに「⚠️ Code review skipped」で始まるコメントを残します。一部のケースでは、Code review declinedというcheck runも出ます。コメントにはclaude.ai/admin-settings/usageへのリンクがあり、管理者がそこで予算を戻します。
コメントの文言が、どの上限に当たったかを示します。
| コメントの文言 | 当たった上限 | 管理者がやること |
|---|---|---|
| has reached its monthly code review spending cap | 当たった上限Code Review専用の月次支出上限 | 管理者がやること上限を上げる。次の請求期間の開始でも再開する |
| has no extra usage available to pay for this review | 当たった上限追加使用量(usage credits)の残高ゼロ、または組織全体の月次支出上限 | 管理者がやることクレジットを追加するか、組織の上限を上げる |
| is too low to start another review | 当たった上限残りがレビュー1回の想定費用を下回る | 管理者がやること上限を上げるか、クレジットを追加する |
費用の側から見ると、スキップが起きる条件は3つあります。Code Reviewの月次上限、組織全体の月次上限、usage creditsの残高のどれかが尽きたときです。さらに、残りが1回分の想定費用を割った時点でも止まります。Code Reviewには1回あたりの固定料金がなく、レビューレベル・変更の大きさ・検証すべき候補の数で費用が変わります。
予算を戻したあとは、スキップされたPRに@claude reviewをコメントすると、飛ばされたレビューが走ります。コメントしたのが書き込み権限のある人であることが条件です。
failedとtimed outはどちらも再実行で済む
タイトルが「Code review failed」または「Code review timed out」のときは、まずcheck runのサマリーを読みます。「The review session was interrupted before it could finish. A new review of this commit has been queued automatically.」とあれば、何もしなくて構いません。そのレビューは自動で1回だけやり直されます。
それ以外なら、次のどちらかで再実行します。
@claude reviewをトップレベルコメントで投稿: 新しいレビューが始まります。PRはpush購読になりません- ChecksタブでRe-run: フォークのPRではないときに使えます。現在のhead commitが対象で、こちらも購読にはなりません
フォークPRではRe-runが効かず、コメントだけが有効です。
「指摘あり」なのにdiffに何も無いとき
タイトルが指摘ありを示しているのに、インラインコメントが見えないことがあります。指摘は、次の3か所のどこかにあります。
- check runのDetails: ChecksタブでClaude Code ReviewのDetailsを開くと、ファイル・行・要約の表があります。インラインコメントがGitHubに受け付けられなかった指摘も含まれます
- Files changedタブの注釈: 行がある指摘で、インラインコメントにならなかったものは、該当行にアノテーションとして出ます
- レビュー本文のAdditional findings: 位置を持たない指摘や、今回のdiffの外の指摘です
指摘の重大度の見方と、閉じ方はResolve conversationの記事にまとめています。
スクリプトで読むときは「行が無い」を指摘ゼロと扱わない
CIからcheck runを読む場合は、まずコミットのcheck runの一覧からIDを探します。
gh api repos/OWNER/REPO/commits/<commit-sha>/check-runs \
--jq '.check_runs[] | {id, name}'IDが分かれば、Detailsの末尾にある機械可読の行を取り出せます。
gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
--jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'出力は{"nit": 1, "normal": 2, "pre_existing": 0}のような形です。normalがImportant(🔴)の件数です。判定で注意するのは、この行が無い場合です。failed・timed out・キャンセル・新しいレビューに置き換えられた場合は、この行がありません。完了したレビューでも無いことがあります。「行が無い」は指摘ゼロではなく判定なしとして扱わないと、レビューされていないPRを通すゲートになります。
check runにREVIEW.mdの文が出ているとき
check runにREVIEW.mdの話が出ることがあります。ブランチ保護に関する文言が2種類あります。
- 「This review applied the repository's review instructions (REVIEW.md) from its default branch, which is not protected against direct pushes.」: 保護されていないデフォルトブランチのルートの
REVIEW.mdだけが読まれました - 「were not applied to this review: branch protection could not be confirmed」:
REVIEW.mdはまったく読まれませんでした
REVIEW.mdは、PR自身の変更ではなく、ベースブランチまたはデフォルトブランチから読まれます。基準を変えたいなら、先にREVIEW.mdの変更をマージします。保護済みのデフォルトブランチを読んだレビューでは、重大度を下げる指示、パスやクラスの除外、nitの上限が効きます。書き方はREVIEW.mdカスタマイズの記事で扱っています。
セットアップ時につまずく2つ
Ownerが最初に設定するときの問題も、同じトラブルシュートに入っています。
Add a repositoryにリポジトリが出ない。ダイアログに出るのは、Claude GitHub Appがアクセスできるリポジトリだけです。長い一覧は読み込みきれないため、名前で検索してください。それでも出なければInstall GitHub Appを押して、そのリポジトリへのアクセスを与えます。一覧が空のときはダイアログ内のボタン、そうでなければ組織フィルタのメニューの下にあります。
テスト用PRにcheck runが出ない。 Allow code reviewがオンか、Repositoriesに載っているか、Appのアクセスがあるかを確認します。自動レビューはdraft PRを飛ばし、Manual (@claude review)のリポジトリでは、最初の1回に@claude reviewが要ります。
実際にハマりやすいのは「待たずに押し直す」こと
queuedやin progressの間にコメントを重ねても、同じコミットのレビューは2つ目が始まりません。タイトルが変わるまで待つのが正解です。
もう1つは、Manualのリポジトリで「pushしたのにレビューが来ない」と探してしまうケースです。Manualでは最初から来ない設定です。@claude review alwaysを使うとそのPRだけpushごとにレビューされますが、課金もpushごとに増えます。
どの経路でレビューを受けるかという選び方は、4つの実行経路を比べた記事で整理しています。
まとめ
check runのタイトルが分かれば、原因の半分は絞れます。skippedは「変更が無かった」、declinedは予算の話、failedとtimed outは再実行、check runなしは設定かコマンドの条件です。迷ったら、まずサマリーの文を読みます。書き込み権限のある人が@claude reviewをトップレベルコメントで投稿すれば、ほとんどのケースは次の状態に進みます。