Claude Code First PR Review Rubric: スタイル指摘の前に本当のリスクを拾う

Claude Code にいきなり「このPRをレビューして」と頼むと、重大な回帰と軽い命名指摘が同じ重さで並ぶことがあります。レビューの価値は指摘数ではなく、見逃すと困るリスクを先に拾えるかで決まります。

このガイドでは、最初のPRレビュー用 rubric を作ります。P0からP3の重大度、証拠、コメント形式、失敗時の戻り方を決めてから Claude Code に差分を読ませます。

あわせて読む: claude-code-code-review-checklist, claude-code-prompt-library-maintenance, claude-code-pull-request-quality. 公式ドキュメントの基準: Anthropic Claude Code docs.

なぜ最初に決めるのか

スタイルより先に回帰、権限、データ損失、テスト不足を拾うこと

大事なのは、最初の依頼を大きくしすぎないことです。読む範囲、触らない範囲、最初の一手、確認方法を先に置くと、Claude Code は余計な作業を広げにくくなります。

Claude Code でコードレビューを始めたが、指摘が散らばって困っている開発者

実務で使う手順

1. 差分の目的と変更範囲を貼る
2. P0からP3の重大度を先に定義する
3. 証拠がない推測コメントを禁止する
4. テスト、build、再現手順をコメントに含める
5. P3のスタイル指摘は最後にまとめる

場面	Claude Code に任せること	人間が確認する証拠
認証PR	token保存や権限境界をP0として最初に確認する	build, diff, URL
UI修正	クリック不能やモバイル崩れをP1として見る	build, diff, URL
リファクタ	挙動不変の証拠とテスト不足をP2に分ける	build, diff, URL

この証拠が残ると、Claude Code の返答を雰囲気ではなく実際の作業結果で判断できます。

コピーして使えるプロンプトとコード

このPR差分をP0/P1/P2/P3でレビューしてください。P0はセキュリティ、データ損失、支払い、認証、本番停止です。各指摘には該当行、失敗シナリオ、必要な証拠、修正案を含めてください。スタイル指摘は最後にまとめてください。

const reviewRubric = {
  P0: "security, data loss, payment, auth, production outage",
  P1: "user-visible regression or broken release path",
  P2: "test gap, unclear edge case, maintainability risk",
  P3: "style, naming, or optional cleanup"
};

function classifyReviewFinding(finding) {
  const text = finding.toLowerCase();
  if (/auth|token|payment|delete|secret|production/.test(text)) return "P0";
  if (/regression|broken|crash|deploy/.test(text)) return "P1";
  if (/missing test|edge case|unclear/.test(text)) return "P2";
  return "P3";
}

console.log(classifyReviewFinding("missing test for failed payment retry"));

実例と失敗例

場面	Claude Code に任せること	人間が確認する証拠
認証PR	token保存や権限境界をP0として最初に確認する	build, diff, URL
UI修正	クリック不能やモバイル崩れをP1として見る	build, diff, URL
リファクタ	挙動不変の証拠とテスト不足をP2に分ける	build, diff, URL

• 最初から命名とフォーマットを見せると、Claude Code は低リスクの指摘でレビューを埋めます。
• 重大度を定義しないと、支払いバグと句読点が同じリストに混ざります。
• 証拠を要求しないと、もっともらしい推測コメントが増えます。

大事なのは、最初の依頼を大きくしすぎないことです。読む範囲、触らない範囲、最初の一手、確認方法を先に置くと、Claude Code は余計な作業を広げにくくなります。

証拠パックとして残すこと

スタイルより先に回帰、権限、データ損失、テスト不足を拾うこと は、1回の作業だけで終わらせるよりも、次のセッションで再利用できる証拠パックにして残すと価値が出ます。具体的には、最初の依頼文、Claude Code が読んだ範囲、触らなかった範囲、実行した確認コマンド、公開URLやスクリーンショット、判断に迷った点を短く残します。これがあると、別の日に同じ問題を見直しても、なぜその判断をしたのかを追えます。

Claude Code でコードレビューを始めたが、指摘が散らばって困っている開発者 は、最初から完璧な運用規程を作る必要はありません。まずは1つの PR、1つのメモ、1つの deploy だけで試し、失敗した場所を checklist に戻します。Claude Code に任せる作業を増やすのは、build、diff、URL、CTA、rollback の証拠がそろってからで十分です。証拠が薄い段階で権限だけ広げると、速度は上がっても確認コストが後から膨らみます。

収益導線も同じです。読者がまだ基本操作で止まっているなら無料PDF、同じ prompt を何度も書いているなら Gumroad、チームや本番運用で判断が割れるなら導入相談へ進めます。この記事の役割は、読者を急いで買わせることではなく、今の詰まりに合う次の一手を見せることです。PRレビューの型と再利用できるプロンプト が該当する読者だけを教材へ送り、まだ早い読者には無料PDFや関連記事を返します。

追加で残したいのは、判断の分岐です。Claude Code が提案した案をそのまま採用したのか、範囲を狭めたのか、別の確認を先に挟んだのかを一行で書きます。PRレビューなら「P0はなし、P1はモバイル崩れ、P2はテスト不足」のように残します。Obsidian から issue を作るなら「メモ全文ではなくCTA改善だけを採用」と書きます。deploy dry run なら「preview URL は正しいが rollback owner 未設定なので本番はまだ」と書きます。

この一行があると、次に同じ読者や同じチームが来たときのCTAも選びやすくなります。基本操作で迷っている人には無料PDFを案内し、同じ作業を繰り返す人には Gumroad の実用教材を案内し、責任分界や本番権限で止まっている人には導入相談を案内します。PRレビューの型と再利用できるプロンプト は、その分岐の中で「今すぐ型を持って帰れば自走できる」読者に向けたルートです。

最後に、確認ログは記事本文と同じくらい大事です。公開前にどのURLを開いたか、h1 と canonical が合っていたか、heroImage が見えていたか、CTA が無料PDF、Gumroad、導入相談へ正しく分かれていたかを残します。ここまで記録すると、次回の改善は「なんとなくCTAを強くする」ではなく、どの段階で読者が止まったかを見る作業になります。PRレビューの型と再利用できるプロンプト を案内する判断も、証拠があるほど自然になります。小さな記録が次の改善を速くします。

無料PDF、Gumroad、導入相談につなげる

まだ基本コマンドが曖昧なら 無料チートシート で日々の型を固めてください。PRレビューの型と再利用できるプロンプト をすぐ深めたい場合は Gumroad 教材 が次の一手です。チーム導入、レビュー設計、収益導線まで一緒に整理したい場合は 導入相談 に進み、教材比較は products で確認できます。

CTA は記事末尾だけに置くものではありません。導入では無料PDF、実例の後では Gumroad 教材、チーム導入や本番リスクの話では導入相談を自然に出すと、読者の迷いが減ります。

公開後に見る数字

公開後は、レビュー記事から Prompt Templates、Code Review System の将来商品、導入相談へのクリックを見ます。

PV だけで判断せず、本文冒頭の読了、内部リンク、無料PDF登録、Gumroadクリック、導入相談ページへの移動を分けて見ます。HTTP 200、h1、canonical、heroImage、CTA が同じ slug を指していることも確認します。