Claude Codeコードレビュー チェックリスト: チームで使うリスク別PR監査

最初の3行で決める: AIレビューは「全部見て」では弱い

Claude Codeに「このPRをレビューして」とだけ頼むと、見た目の指摘は増えますが、チームの事故は防ぎにくいです。

本当に守るべきなのは、個人情報、課金、権限、Migration、アクセシビリティ、テスト、そしてAIが生成した差分の混入です。

この記事では、チームでそのまま使えるコードレビュー チェックリスト、Claude Code向けレビューPrompt、GitHub PRテンプレート、GitHub Actionsで落とすCIガードをまとめます。

前提として、Claude Codeはレビュー担当者の代わりではありません。Claude Codeは「見落としを減らす補助輪」です。最終判断は、PRの責任者とレビュー担当者が行います。公式情報としては、Claude Codeのcode review setupとClaude Code GitHub Actions docs、GitHubのPRテンプレート、protected branches、Actions workflowsを確認しておくと安全です。セキュリティ観点はOWASP Secure Code Review Cheat Sheetを基準にします。

リスク別レビューという考え方

リスク別レビューとは、すべてのPRを同じ重さで見るのではなく、壊れたときの影響でレビューの深さを変える方法です。たとえばCSSの余白修正と、決済Webhookの署名検証変更を同じチェックリストで見ると、前者は重すぎ、後者は軽すぎます。

チームでおすすめの分類は3段階です。

リスク	例	必須レビュー
Low	文言修正、軽いスタイル修正、ログ文言、ドキュメント	1人レビュー、スクリーンショットまたは差分説明
Medium	UI状態、APIレスポンス、フォーム、検索、権限に触れないDB読み取り	1人レビュー、テスト証跡、Claude Codeレビュー
High	認証、認可、課金、個人情報、Migration、削除処理、外部Webhook	2人レビュー、rollback plan、CI必須、セキュリティ観点

ここでいう「Migration」は、データベースの表や列を変更する作業です。コードは戻せても、削除した列や上書きしたデータは簡単に戻せません。だからMigrationは、実装のきれいさよりも「失敗時に戻せるか」を先に見ます。

Claude Codeには、このリスク分類を明示してからレビューさせます。リスクを言わずにレビューさせると、AIは一般論の指摘に寄りがちです。逆に「High risk: billing webhook and customer email changed」と伝えると、署名検証、冪等性、ログ、個人情報の扱い、テストの不足を見つけやすくなります。

Masaがチーム運用で失敗しやすいと感じたのは、レビュー観点を「品質」「可読性」「セキュリティ」のように抽象語で置いてしまうことです。抽象語だけだと、レビュー担当者が忙しい日に必ず抜けます。PRテンプレートとClaude Promptには、必ず「どのファイル」「どのデータ」「どの失敗時挙動」を書かせます。

そのまま使えるレビュー チェックリスト

以下は.github/review-checklist.mdやチームWikiに置けるMarkdownです。Claude Codeに渡す前提で、質問が具体的になるようにしています。

# Code Review Checklist

## 0. PR scope
- [ ] This PR has one clear purpose.
- [ ] Changed files match the stated purpose.
- [ ] Generated or AI-written files are marked in the PR description.
- [ ] No unrelated formatting, dependency, or config changes are mixed in.

## 1. Risk level
- [ ] Risk level is marked as low, medium, or high.
- [ ] High-risk PRs have two human reviewers.
- [ ] High-risk PRs include rollback or recovery steps.

## 2. Security and privacy
- [ ] User input is validated on the server side.
- [ ] Authorization is checked near the data access point.
- [ ] Secrets are not printed, committed, or sent to Claude prompts.
- [ ] Logs do not include email, tokens, addresses, payment IDs, or private content.
- [ ] OWASP-relevant risks such as injection, XSS, broken access control, and SSRF were considered.

## 3. Tests
- [ ] Unit or integration tests cover the changed behavior.
- [ ] Regression tests cover the bug that motivated the PR.
- [ ] Manual verification steps are written with actual result, not "works locally".
- [ ] Snapshot changes are explained.

## 4. Performance
- [ ] New loops, queries, and network calls are bounded.
- [ ] N+1 queries were checked.
- [ ] Large lists, images, and bundles have a budget.
- [ ] Metrics or before/after evidence are attached for performance-sensitive changes.

## 5. Accessibility
- [ ] Keyboard operation works for interactive UI.
- [ ] Focus order and visible focus state are preserved.
- [ ] Form fields have labels and errors that screen readers can understand.
- [ ] Color contrast and reduced-motion behavior are checked where relevant.

## 6. Migration and data risk
- [ ] Migration is backward compatible during rollout.
- [ ] Destructive changes have backup or recovery steps.
- [ ] Old and new app versions can run during deployment.
- [ ] Data cleanup jobs are idempotent.

## 7. AI-generated diff hygiene
- [ ] AI-generated code was read by a human before approval.
- [ ] The diff does not remove tests, monitoring, analytics, or CTA links by accident.
- [ ] New dependencies are justified.
- [ ] Comments do not claim verification that was not actually done.

ポイントは、チェック項目を「気をつける」ではなく、確認できる事実にすることです。「セキュリティを確認した」では弱く、「ログにemail/token/paymentIdが出ていない」は確認できます。「アクセシビリティを考慮した」では弱く、「Tabキーで操作でき、focus stateが見える」は確認できます。

Claude Codeに貼るレビューPrompt

Claude Codeには、レビューの目的、リスク、差分、禁止事項を渡します。特に禁止事項が重要です。レビュー中に勝手に大きな修正を始めると、レビューと実装が混ざり、PRの責任範囲が曖昧になります。

You are reviewing a pull request for a production team.

Goal:
- Find concrete risks before merge.
- Prioritize correctness, security/privacy, tests, performance, accessibility, migration/data risk, and AI-generated diff hygiene.
- Do not rewrite code yet. Produce review findings first.

Context:
- Risk level: <low | medium | high>
- Business area: <auth | billing | content | search | admin | analytics | other>
- Sensitive data touched: <none | email | payment | address | health | private content | other>
- Rollout plan: <flag | migration | immediate deploy | other>

Review method:
1. Read the PR summary and changed files.
2. List the top risks by severity.
3. For each finding, include file, line or function, why it matters, and a minimal fix.
4. Separate "must fix before merge" from "follow-up".
5. Check whether tests prove the changed behavior.
6. Check whether any AI-generated code, dependency, config, or formatting change is unrelated to the PR goal.

Output format:
- Findings first, ordered by severity.
- Then missing evidence.
- Then questions for the author.
- Then a short merge recommendation: block, approve with fixes, or approve.

このPromptは、コードベース把握やテスト戦略と相性がよいです。レビューの前にClaude Codeへ「このPRが触るドメインを3分で説明して」と頼むと、レビューが表面的な命名指摘だけで終わりにくくなります。

GitHub PRテンプレート

GitHubでは.github/pull_request_template.mdを置くと、PR作成画面にテンプレートが自動で入ります。チームレビューでは、本文に「レビュー材料」を集めるのが目的です。長文の作文を強制するのではなく、Claude Codeと人間が同じ前提で読める情報を入れます。

## Summary
- TODO

## Risk
Risk level: low | medium | high

Risk reasons:
- Data touched:
- Users affected:
- Rollout:

## Review focus
- [ ] Correctness
- [ ] Security/privacy
- [ ] Tests
- [ ] Performance
- [ ] Accessibility
- [ ] Migration/data risk
- [ ] AI-generated diff hygiene

## Test evidence
- Automated:
- Manual:
- Not tested because:

## Security and privacy notes
- Secrets changed: no | yes
- Personal data in logs: no | yes
- Authorization boundary changed: no | yes

## Migration / rollback
- Migration included: no | yes
- Backward compatible: no | yes | not applicable
- Rollback plan:

## Claude Code review prompt
Paste this into Claude Code after the PR is ready:

Review this PR as risk level "<low|medium|high>".
Focus on correctness, security/privacy, tests, performance, accessibility, migration/data risk, and AI-generated diff hygiene.
Return findings first with file/function references and minimal fixes.

PRテンプレートで避けたい失敗は、チェックボックスだけを増やすことです。チェックボックスが多すぎると、全員が機械的にチェックして終わります。上のテンプレートでは、Risk reasons、Test evidence、Rollback planのように、証拠を書かないと埋まらない欄を入れています。

GitHubのprotected branchesを使うなら、このPRテンプレートだけでなく、必須ステータスチェックも組み合わせます。たとえばHigh riskなのにrollback planが空ならCIで落とす、Migrationがあるのにbackward compatibleが未記入なら落とす、という運用にします。

GitHub ActionsでCIガードを入れる

次の例は、PR本文と差分ファイルを見て最低限のレビュー材料をチェックするNode.jsスクリプトです。DangerJSを入れてもよいですが、最初は依存を増やさないNode scriptで十分です。

.github/workflows/pr-review-guard.yml:

name: PR review guard

on:
  pull_request:
    types: [opened, edited, synchronize, reopened, ready_for_review]

permissions:
  contents: read
  pull-requests: read

jobs:
  review-guard:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Check PR review evidence
        run: node scripts/pr-review-guard.mjs
        env:
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}

scripts/pr-review-guard.mjs:

import { execSync } from "node:child_process";
import { readFileSync } from "node:fs";

const eventPath = process.env.GITHUB_EVENT_PATH;
if (!eventPath) {
  throw new Error("GITHUB_EVENT_PATH is missing. Run this in GitHub Actions.");
}

const event = JSON.parse(readFileSync(eventPath, "utf8"));
const pr = event.pull_request;
const body = pr?.body ?? "";
const base = process.env.BASE_SHA ?? pr?.base?.sha;
const head = process.env.HEAD_SHA ?? pr?.head?.sha;

function safeRef(value, name) {
  if (!value || !/^[a-f0-9]{40}$/i.test(value)) {
    throw new Error(`${name} must be a full git SHA.`);
  }
  return value;
}

const baseSha = safeRef(base, "BASE_SHA");
const headSha = safeRef(head, "HEAD_SHA");
const changedFiles = execSync(`git diff --name-only ${baseSha} ${headSha}`, {
  encoding: "utf8",
})
  .split(/\r?\n/)
  .filter(Boolean);

function includesFile(pattern) {
  return changedFiles.some((file) => pattern.test(file));
}

const failures = [];
const hasRisk = /Risk level:\s*(low|medium|high)/i.test(body);
const hasTests = /## Test evidence[\s\S]*Automated:\s*\S/i.test(body) ||
  /## Test evidence[\s\S]*Manual:\s*\S/i.test(body);
const hasRollback = /Rollback plan:\s*\S/i.test(body);
const highRisk = /Risk level:\s*high/i.test(body);
const migrationChanged = includesFile(/migrations?|schema|prisma|drizzle/i);
const authOrBillingChanged = includesFile(/auth|session|permission|billing|payment|webhook/i);

if (!hasRisk) {
  failures.push("Add `Risk level: low | medium | high` to the PR body.");
}

if (!hasTests) {
  failures.push("Add automated or manual test evidence.");
}

if ((highRisk || migrationChanged) && !hasRollback) {
  failures.push("High-risk or migration PRs need a rollback plan.");
}

if (authOrBillingChanged && !/Security and privacy notes[\s\S]*(Authorization|Personal data|Secrets)/i.test(body)) {
  failures.push("Auth, billing, or webhook changes need security/privacy notes.");
}

if (changedFiles.length > 40 && !/AI-generated diff hygiene/i.test(body)) {
  failures.push("Large diffs need an AI-generated diff hygiene note.");
}

if (failures.length > 0) {
  console.error("PR review guard failed:");
  for (const failure of failures) console.error(`- ${failure}`);
  process.exit(1);
}

console.log("PR review guard passed.");

このCIガードは「レビューの質」を完全には保証しません。ただし、レビュー材料の欠落はかなり減らせます。protected branchesでこのworkflowを必須にすると、PR本文が空のままマージされる事故を防げます。GitHub Actionsは便利ですが、過剰に厳しくすると小さな修正まで止まります。最初はHigh riskとMigrationだけを厳格にし、Low riskは軽く通す運用が現実的です。

セキュリティ、プライバシー、アクセシビリティの見方

セキュリティレビューでは、OWASPの観点を丸暗記するより「入力、権限、出力、ログ、外部通信」に分けると見落としにくいです。入力はサーバー側で検証されているか。権限は画面ではなくデータ取得の近くで確認されているか。出力はXSSにつながらないか。ログに個人情報やtokenが出ていないか。外部通信はSSRFや署名検証漏れにつながらないか。この順番でClaude Codeに見せると、指摘の粒度が安定します。

プライバシーは「秘密情報」だけではありません。メールアドレス、住所、購入履歴、問い合わせ本文、社内メモ、分析用IDも扱い方を間違えると信用を失います。Claude CodeにPRを見せる前にも注意が必要です。Promptに本物のAPI key、顧客メール、決済ID、非公開契約情報を貼らないでください。必要なら値をマスクし、構造だけを渡します。

アクセシビリティは、最後に思い出すと直しにくい領域です。特にClaude Codeが生成したUIは、見た目が整っていても、キーボード操作、focus、label、エラー文、ARIA属性が抜けることがあります。レビューPromptには「mouseなしで操作できるか」「フォームエラーが読み上げられるか」「モーダルでfocusが外へ逃げないか」を入れます。

3つ以上の実務ユースケース

1つ目は、認証と管理画面のPRです。管理者だけが見られるユーザー一覧、権限変更、監査ログは、UIのif文だけで守ると危険です。レビューでは、API側のauthorization、ログの個人情報、権限変更の監査証跡、テストデータの分離を確認します。

2つ目は、課金やWebhookのPRです。StripeなどのWebhookでは、署名検証、冪等性、二重処理、失敗時再試行、返金やキャンセル状態の扱いが重要です。Claude Codeには「同じeventが2回来ても課金状態が壊れないか」を重点的に見てもらいます。

3つ目は、DB Migrationを含むPRです。列追加だけなら軽く見えますが、not null制約、default、index、削除、renameは本番データで失敗しやすいです。古いアプリと新しいアプリが同時に動く時間を考え、expand and contract方式で段階的に変更します。

4つ目は、AIが大量生成したUI差分です。Claude Codeに一覧画面、フォーム、モーダルをまとめて作らせると、差分が大きくなりがちです。レビューでは、意図しないCTA削除、分析イベント名の変更、既存CSSの破壊、アクセシビリティ漏れ、snapshot更新の意味を確認します。

5つ目は、コンテンツサイトや収益導線です。記事、無料PDF、Gumroad、問い合わせフォームを持つサイトでは、コードレビューでCTAリンクや計測イベントも見るべきです。表示は崩れていなくても、商品一覧や研修・相談へのリンクが消えると売上に直結します。

具体的な落とし穴

落とし穴1は、Claude Codeの指摘をそのまま信じることです。AIはもっともらしい指摘を作ることがあります。必ず差分、テスト、公式ドキュメント、実行結果と照合してください。

落とし穴2は、レビューと修正を同時に進めることです。レビュー中にClaude Codeへ「直して」と言い始めると、PRの差分がさらに膨らみます。まずFindingsを出し、must fixだけを別コミットで直します。

落とし穴3は、AI生成差分の「ついで修正」です。フォーマット、依存更新、古いコメント削除、別機能の軽微修正が混ざると、レビュー担当者は本当に危険な変更を見落とします。Claude Codeには「unrelated changeを列挙して」と明示します。

落とし穴4は、Migrationのrollbackをコードのrevertと同じだと思うことです。DB変更は、revertしてもデータが戻らない場合があります。backup、復旧SQL、feature flag、二段階MigrationをPR本文に書きます。

落とし穴5は、CIガードを厳しくしすぎることです。すべてのPRに長い証跡を求めると、チームはテンプレートを形だけ埋めます。High riskだけを強く、Low riskは軽く、Mediumは証跡重視にします。

収益化CTAとチーム導入

コードレビューは品質活動ですが、収益にも直結します。課金導線、商品ページ、問い合わせフォーム、無料PDF登録、メール配信、分析イベントが壊れると、バグは静かに売上を削ります。Claude Codeでレビューするなら、技術観点だけでなく「このPRで収益導線が壊れていないか」もチェックしてください。

個人で型を固めるなら、まず無料チートシートでClaude Codeの基本確認手順を固定します。チームでPRテンプレート、Claude Prompt、CLAUDE.md、CIガードまでまとめて整えるなら教材・テンプレート一覧が使えます。実リポジトリを前提に、認証、課金、Migration、レビュー運用まで一緒に設計したい場合はClaude Code研修・導入相談が自然です。

この記事で紹介した内容を実際に小さなNext.js想定PR、DB Migration想定PR、AI生成UI差分想定PRに当てて確認した結果、もっとも効果があったのは「Risk level」と「Rollback plan」をPR本文に強制することでした。Claude Codeのレビュー精度も、抽象的な「レビューして」より、リスクとデータ種別を渡したほうが明確に上がります。逆に、チェック項目を増やすだけでは品質は上がりません。PRの目的、リスク、証跡、CIの4点を短く固定するのが、チーム運用では一番続きます。

まとめ

Claude Codeを使ったコードレビュー チェックリストは、単なる便利Promptではありません。チームのリスク判断、PR本文、テスト証跡、CI、protected branchをつなぐ運用設計です。

まずはこの記事のPRテンプレートとCIガードを小さく導入してください。次にClaude CodeペアプログラミングやCLAUDE.md best practicesと組み合わせ、レビュー観点をリポジトリに固定します。レビューは速くするだけでは足りません。危険な差分を、マージ前に確実に止める仕組みにしてください。