同僚にレビューを頼むのを諦めた日 ─ Claude に PR を任せる 3 つの公式ルート

「同僚にレビューを頼んだのに 2 日返ってこない」「自分の PR が 3 本積まれていて開発が止まる」「人手が足りないからレビュー基準が緩くなる」。 PR レビューの順番待ちはチーム開発の慢性ボトルネックです。本記事ではここを Claude に肩代わりさせる Anthropic 公式の 3 ルート、Code Review と code-review plugin と GitHub Actions を整理し、自分のプランと運用に合うのはどれかと、最小コストの第一歩を扱います。

シリーズ #11 「先に lint かけて」と毎回書かない ─ Claude Code Hooks 入門 で扱った PreToolUse hook は、ローカル品質ゲート（手元の Claude Code が git commit を実行する直前に lint やテストを走らせて、エラーがあれば commit 自体を止める仕組み）でした。本記事はその次の段、CI（Continuous Integration、push 後にリポジトリ側で自動でテスト・ビルド・レビューなどを走らせる仕組み）側で PR が積まれる問題を解きます。

TL;DR

• PR レビューを Claude に任せる Anthropic 公式は 3 ルート：(A) code-review plugin（Pro/Max でも使える、手元の Claude Code で /code-review slash command 起動、push 前ローカルレビュー）／ (B) GitHub Actions（Pro/Max でもチームでも、自前 CI で anthropics/claude-code-action@v1、ANTHROPIC_API_KEY 持参）／ (C) Managed Code Review（Team/Enterprise 専用、Anthropic 側で自動レビュー、$15-25/PR）
• まず分岐：個人 Pro/Max → (A) が最短／チームで CI 自動化したい → (B)／Team/Enterprise で push 後自動レビュー → (C) が最少手番
• (A) は /code-review、(B) は @claude mention または yml の prompt、(C) は @claude review、と起動方法がそれぞれ違う
• (C) のカスタマイズは REVIEW.md（レビュー専用、最高優先で system prompt に注入）と CLAUDE.md（プロジェクト全体、nit 扱い）の二段構え
• 今週やる 1 つ：(A) なら /plugin install code-review@claude-plugins-official 1 行／(B) なら pull_request: opened 限定の最小 workflow yml／(C) なら PR テンプレに @claude review once を 1 行

「PR が 2 日返ってこない」が常態化していませんか

• 同僚にレビュー依頼を投げて 2 日経つが「忙しくて見れていない」と返ってくる
• 自分の PR が 3 本積み上がっており、最初の PR の差分とコンテキストが頭から消える
• 「人手が足りないから基準を緩めよう」が常態化し、Important （重要）なバグが本番直前で見つかる
• 「コメント 1 行で済む typo」を指摘するためだけにレビュアーの時間を取るのが心理的に重い

これらは個別のスキル問題ではなく、「レビューを誰がやるか」の選択肢が人間の同僚しかないことが原因です。Claude Code の登場で、ここに公式の選択肢が 3 つ足されました。

問題の立て方が間違っている

「レビューを Claude にやらせるべきか、それとも人間が責任を持つべきか」という議論は、二者択一ではありません。Claude のレビューは 「人間レビュアーの一次フィルタ」 として置くと噛み合います。Importantなバグ・セキュリティ脆弱性・regression（既存機能の壊れ）は Claude が拾い、Nit（細かい好み）以下は人間が判断する分業です。

Anthropic 公式の Code Review docs ではこの分業を次のように表現しています。

Findings are tagged by severity and don’t approve or block your PR, so existing review workflows stay intact.

検出された問題は重大度ごとにタグ付けされ、PR の承認やマージブロックは行いません。既存のレビューワークフローはそのまま維持されます。

つまり Claude のレビューは 既存の人間レビューを置き換えるのではなく、その上流にフィルタを 1 段挟むという発想です。

公式の 3 ルート ─ Plugin / GitHub Actions / Managed

PR レビューを Claude に任せる公式ルートは 3 つあります。

(C) Managed Code Review は Anthropic infra でマルチエージェント分析を走らせる仕組みで、サーバ側でのデータ保存が前提になるため ZDR と両立できず、ZDR 有効組織では自動で無効化されます（公式 docs に「Code Review … is not available for organizations with Zero Data Retention enabled」と明記）。一方 (A) Plugin は手元の Claude Code で、(B) GitHub Actions は自前 runner で動くので、ZDR 配下でも問題なく使えます。

ZDR（Zero Data Retention）は Claude for Enterprise 契約のオプションで、Claude Code のプロンプトと応答を Anthropic 側がリアルタイムで処理した後、保存しないようにする設定です（公式 docs）。ソースコードを社外サーバに滞留させたくない金融・医療・政府系などの組織で有効化されます。

選び方

• 個人開発 / Pro・Max ユーザー: (A) code-review plugin が最短。/plugin install code-review@claude-plugins-official を 1 回打って、PR branch で /code-review を叩くだけ。push 前に手元で見たいケースに向く
• CI に組み込みたい / 個人 Pro・Max でも自前リポで自動レビューしたい: (B) GitHub Actions。Pro / Max / Team / Enterprise のどのプランでも、Anthropic Console で ANTHROPIC_API_KEY を発行すれば動きます。workflow yml を書く手間はかかりますが、自由度は最大です
• チームで PR 開いたら自動レビューしたい / Team・Enterprise plan: (C) Managed が最少手番。GitHub App を一発入れて、@claude review か自動 trigger に任せる

flowchart TD Start["PR レビューを<br/>Claude に任せたい"] --> Q1{push 前にローカル or<br/>push 後に CI で自動} Q1 -->|push 前にローカル| P["(A) code-review plugin<br/>手元の Claude Code で<br/>/code-review を叩く"] Q1 -->|push 後に CI で自動| Q2{Team/Enterprise plan で<br/>Managed を有効化できる？} Q2 -->|Yes| Q3{ZDR 有効？} Q3 -->|No| M["(C) Managed Code Review<br/>admin が Code Review を ON<br/>@claude review でトリガー"] Q3 -->|Yes| GA["(B) GitHub Actions<br/>self-host"] Q2 -->|No / 個人 Pro/Max でも OK| GA GA --> H["GitHub App install +<br/>workflow yml +<br/>ANTHROPIC_API_KEY"] P --> P2["push 前にローカルレビュー<br/>気になる点を直してから push"]

(A) code-review plugin ─ Pro/Max でも使える、手元 Claude Code のレビュー

(C) Managed Code Review は Team / Enterprise 専用ですが、Pro / Max プランの個人開発者が「push 前に手元で Claude にレビューさせたい」場合は、公式 plugin marketplace の code-review plugin が最短です。Claude Code が動くプランなら使えるので、Pro / Max / Team / Enterprise いずれでも install 可能です。

動作モデル

(C) Managed と同じく、専門分化したエージェント群が並列で diff を分析し、信頼度スコア（0-100）でフィルタするマルチエージェント設計です。違いは 走る場所が Anthropicのインフラ上ではなく、手元の Claude Code 内である点。検出結果は手元のターミナルに出力され、PR には自動投稿されません。push する前にローカルで気付いて直す、という運用に向きます。

公式 plugin 一覧の discover-plugins docs では code-review は次のように紹介されています。

Plugins: browse the plugin marketplace, including a code-review plugin for running on-demand reviews locally before pushing

プラグイン: プッシュする前にローカルでオンデマンドレビューを実行するための「code-review」プラグインを含む、プラグイン マーケットプレイスを参照します。

install ─ 1 行

公式 Anthropic marketplace (claude-plugins-official) は Claude Code 起動時から自動で読み込まれるので、マーケット追加の手順は不要です。

/plugin install code-review@claude-plugins-official

install 後に /reload-plugins で反映します。/plugin メニューの Installed タブで code-review が緑色で表示されていれば OK です。

起動 ─ PR branch に checkout して /code-review

レビュー対象の PR branch に git checkout してから、Claude Code 内で /code-review slash command を叩きます。引数なしで現在の branch を main（または base branch）と diff してレビューします。

git checkout feat/user-auth # レビューしたい PR branch
claude # Claude Code 起動
> /code-review # マルチエージェント分析が走る

実行中は (C) Managed と同様に並列エージェントが diff を分析し、信頼度スコア 80 以上の検出だけが表示されます（公式 plugin ページの仕様より）。レビュー結果はそのターミナル内で読めるので、気になる Important を直して git commit --amend か追加 commit してから push、という流れです。

(B) GitHub Actions ルート ─ Pro/Max でもチームでも、自前 runner で動かす

動作モデル

Claude Code GitHub Actions は anthropics/claude-code-action@v1 という公式 GitHub Action（GitHub Actions docs と公式リポジトリ）を .github/workflows/ 配下の yml に置く形で動きます。Managed 側と違い 自前の GitHub Actions runner 上で Claude が走り、API 課金は ANTHROPIC_API_KEY 経由で発生します。

このルートは プラン制限がありません。Anthropic Console で ANTHROPIC_API_KEY を発行できれば、Pro / Max / Team / Enterprise のどのプランでも、あるいは API のみ契約でも使えます。Pro / Max ユーザーが自前リポジトリで CI レビューを自動化したいケース、Team / Enterprise plan は契約しているが (C) Managed Code Review の課金体系（$15-25/PR の extra usage）ではなく ANTHROPIC_API_KEY の通常 API 課金で運用したいケースなど、選択理由は色々あります。

公式 Action は 2 つのモードを 設定から自動判定します（公式 docs Before and After Example より）。

• Interactive mode — @claude mention（issue / PR コメント）で起動。prompt を指定しなければこちらに倒れる
• Automation mode — yml の prompt フィールドに指示を書く。cron や pull_request: opened などのイベントで即時実行

「PR レビューに使う」場合は automation mode で pull_request: opened イベントを契機に走らせるのが定番です。

Setup の最短経路

公式 docs Quick setup から引用します。

The easiest way to set up this action is through Claude Code in the terminal. Just open claude and run /install-github-app.

このアクションをセットアップする最も簡単な方法は、ターミナル上の Claude Code 経由です。claude を開いて /install-github-app を実行するだけです。

/install-github-app（Claude Code のターミナル内 slash コマンド）が GitHub App のインストールと ANTHROPIC_API_KEY の secret 登録を順番にガイドしてくれます。前提は repo の admin 権限です。

Manual setup（手動）の場合は次の 3 ステップです（同 docs より）。

1. Claude GitHub App を repo にインストール（github.com/apps/claude）。Contents / Issues / Pull requests の read & write 権限を要求される
2. ANTHROPIC_API_KEY を repo の Secrets に追加（GitHub Actions の Secrets は 公式 docs）
3. examples/claude.yml を .github/workflows/ にコピー（公式リポジトリ examples）

PR レビュー目的なら code-review plugin を載せる

公式 docs の Code Review workflow 例から原文どおり引用します。yml の中身そのままです。

name: Code Review
on: pull_request: types: [opened, synchronize]
jobs: review: runs-on: ubuntu-latest steps: - uses: anthropics/claude-code-action@v1 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} plugin_marketplaces: "https://github.com/anthropics/claude-code.git" plugins: "code-review@claude-code-plugins" prompt: "/code-review:code-review ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"

plugin_marketplaces は plugin の取得元 marketplace（再利用可能な機能パッケージの配布元）、plugins は使う plugin の指定です。公式の code-review plugin が Managed Code Review と同等のマルチエージェント分析を提供します。prompt フィールドで slash command 形式（/code-review:code-review <PR 参照>）を呼んでいるのが特徴で、PR 番号は GitHub Actions の ${{ github.event.pull_request.number }} 変数から取得します。

types: [opened, synchronize] は「PR を開いた瞬間」と「PR に push されたタイミング」の両方で走るという指定です。Managed Code Review の After every push 相当ですが、こちらは API 課金 + GitHub Actions の分単位課金になります。

v1.0 の破壊的変更

Claude Code GitHub Actions は 2025 年に v1.0 へ GA（一般提供）し、beta から公式 docs Breaking Changes Reference の通り破壊的変更が入りました。主な対応表です。

ネット上の古い記事を真似して @beta や mode: "tag" を書くと warning が出ます。必ず @v1 を指定し、CLI 引数は claude_args に集約します。

(C) Managed Code Review ─ Anthropic 側で動く multi-agent 分析

動作モデル

Code Review は公式 docs の How reviews work セクションで次のように説明されています。

When a review runs, multiple agents analyze the diff and surrounding code in parallel on Anthropic infrastructure. Each agent looks for a different class of issue, then a verification step checks candidates against actual code behavior to filter out false positives.

レビューが実行されると、複数のエージェントが Anthropic インフラ上で diff と周辺コードを並列に分析します。それぞれのエージェントは異なる種類の問題を探し、その後 verification（検証）ステップが候補を実際のコード挙動と照合して、false positive（誤検出）をふるい落とします。

ここがポイントです。単一エージェントが diff だけを見るのではなく、専門分化したエージェント群が並列に走り、別の検証工程が実際のコード挙動と突き合わせて誤検出を排除する設計です。シリーズ #05 専門タスクは専門家へ ─ Claude Code Subagents 入門 で扱った subagent パターンを、Anthropic 側で大規模に組んだものと考えてよいです。

平均所要は 20 分（公式 docs 記載）。PR サイズと codebase の複雑さで上下します。

Severity 3 段階

検出結果は重大度ごとにタグが付きます（公式 docs Severity levels より）。

検出結果は inline comment（diff の該当行に紐付くコメント）として GitHub に投稿され、check run（GitHub Checks タブに表示される実行結果サマリ）には全件の severity tally が出ます。マージブロックはしません。ブロックしたければ check run の出力を自前 CI で読んで判定するという設計で、これは公式 docs の Check run output セクションに具体的な gh api + jq の例が載っています。

3 つの trigger と manual command

Review Behavior の選択肢は 3 つです（公式 docs Step 5）。

• Once after PR creation — PR を開いた / ready for review にした瞬間に 1 回だけ
• After every push — push のたびに走る。新しい issue を捕まえやすいが課金が比例
• Manual — @claude review でだけ走る。high-traffic repo や「PR が ready になってから走らせたい」用途

@claude review と @claude review once の使い分けは、push 毎レビューに subscribe するかどうかです。前者は subscribe（次の push で再レビュー）、後者は 1 回限り。長期 PR でフィードバックは欲しいが push 毎に課金したくないときは once です。

REVIEW.md と CLAUDE.md の二段カスタマイズ

Review behavior を変える場所は 2 か所あります。

• CLAUDE.md：Claude Code がレビューだけでなくすべてのタスクで使う、プロジェクト共通の指示。Code Review はこれをプロジェクト context として読み、新たに導入された違反を nit として検出します。
• REVIEW.md：レビュー専用の指示で、レビュー pipeline の全エージェントに最高優先度で直接注入されます。何を検出するか、どの severity にするか、どう報告するかを変える用途。

CLAUDE.md の扱いはシリーズ #08 CLAUDE.md を書いたのに無視される で扱った通り、プロジェクト全体に効く一般的な指示書です。REVIEW.md はここに乗せると重くなるレビュー専用ルールを別ファイルに切り出すためのものです。

REVIEW.md を書くと役立つパターンは公式 docs に列挙されており、特に効くのは次の 4 つです。

• Severity の再定義：自分の repo で 🔴 Important が何を意味するかを書く。デフォルトは production code 向けに調整されているので、docs repo や config repo では狭め直す
• Nit の上限：「Nit は 1 レビューで 5 件まで、それ以上は summary に件数だけ書く」のような上限ルール
• Skip rules：生成コード・lockfile・vendored 依存・CI が既に enforce している lint / format などをスキップ
• Repo 固有のチェック：「新しい API route は integration test 必須」のような repo 単位の必須項目

公式 docs には英文の最小例が載っています。REVIEW.md は Claude が読むテキストファイルなので、日本語で書いても同じように動きます。日本語でそのまま使える形に書き換えると次のようになります。

# レビュー指示
## ここでの Important（重要）の定義
動作を壊す・データを漏らす・ロールバックを阻むものだけを Important
として扱う。具体的には、論理ミス、マルチテナント境界の未チェック
DB クエリ、ログやエラーメッセージへの個人情報の混入、後方互換性のない
マイグレーション。スタイル・命名・リファクタリングの提案は Nit
止まり。
## Nit の上限
1 レビューで Nit は最大 5 件。それ以上見つけたら、inline で投稿せず
summary に「他に類似 N 件」とだけ書く。検出が Nit だけだったら、
summary の冒頭に「ブロッキング問題なし」と置く。
## 検出しないでよいもの
- CI が既に強制している項目: lint、フォーマット、型エラー
- src/gen/ 配下の生成コード、*.lock ファイル
- 本番コードのルールを意図的に破っているテスト専用コード
## 必ずチェックする項目
- 新規 API ルートに integration test がある
- ログ行にメールアドレス・ユーザー ID・リクエストボディが含まれない
- DB クエリが呼び出し元のテナントに絞られている

英文の原文例を見たい場合は公式 docs Example セクション を参照してください。

短さが効きます。公式 docs の Keep it focused セクションを引用します。

Length has a cost: a long REVIEW.md dilutes the rules that matter most. Keep it to instructions that change review behavior, and leave general project context in CLAUDE.md.

長さにはコストがかかります。「REVIEW.md」が長いと、最も重要なルールが薄れてしまいます。レビュー動作を変更する指示にとどめ、プロジェクトの一般的なコンテキストは「CLAUDE.md」に残します。

価格感

1 PR あたり $15-25（公式 docs Pricing）。高額です。

PR サイズと検出件数で上下します。月次の上限は claude.ai/admin-settings/usage で設定できます。After every push を選ぶと push 回数だけ課金が膨らむので、最初は Once after PR creation か Manual から始めるのが現実的です。

(A) Plugin と何が違うか

要するに、(C) は push 後の自動レビュー、(A) は push 前の手元レビュー。同じマルチエージェント分析の置き場所が違うだけなので、両方を併用しても矛盾はありません。Pro/Max ユーザーは (A) 単独でも十分です。

踏みやすい罠 4 つ

罠 1: 3 ルートを「同じもの」と思い込む

Claude が PR をレビューしてくれるという結果は同じでも、(A) Plugin / (B) GitHub Actions / (C) Managed は内部が別物です。最初の分岐は 「個人で push 前に手元で見たい？／チームで push 後に自動で見せたい？」 です。

• 個人開発・Pro / Max ユーザーが手元で見たい → (A) Plugin
• CI に組み込みたい・Pro/Max でも自前リポで自動化したい → (B) GitHub Actions
• Team / Enterprise plan でチームに自動で見せたい → (C) Managed（ZDR 有効組織は (B) GitHub Actions に倒す）

「Pro / Max では PR レビュー機能が使えない」は誤りで、(A) Plugin も (B) GitHub Actions も Pro / Max で使えます。Team/Enterprise 専用なのは (C) Managed Code Review だけです。この区別を取り違えないことが、本記事で一番伝えたいところです。

罠 2: REVIEW.md を CLAUDE.md の真似で書いて長くする

REVIEW.md は レビュー pipeline の全エージェントに system prompt として最高優先で注入されます。長く書くほど他のルールが薄まります。プロジェクト全体の context は CLAUDE.md に残し、REVIEW.md は「Severity の再定義」「Nit の上限」「Skip rules」「Repo 固有のチェック」の 4 用途に絞ります。

罠 3: GitHub Actions の v1.0 破壊的変更を見逃す

「ネットで見つけた 1 年前の workflow yml を貼ったら deprecated 警告」。@beta / mode: "tag" / direct_prompt / custom_instructions は全部 v1.0 で変わっています。古い記事を信じる前に公式 docs Breaking Changes Reference を見るのが最短です。

罠 4: ANTHROPIC_API_KEY を workflow yml に直書きしてしまう

public repo なら即漏洩、private でもログに残ります。公式 docs Security considerations から原文どおり引用します。

Always use GitHub Secrets (for example, ${{ secrets.ANTHROPIC_API_KEY }}) rather than hardcoding API keys directly in your workflow files.

ワークフローファイルに API キーを直書きするのではなく、必ず GitHub Secrets（例：${{ secrets.ANTHROPIC_API_KEY }}）を使用してください。

シリーズ #10 API を curl で叩く生活から卒業する ─ Claude Code MCP 入門 で扱った「API キー直書き禁止」と同じ話で、CI 側でも同様の規律が必要です。

まとめ

• ローカル commit ゲートはシリーズ #11 の Hooks、CI 側または push 前の PR レビューは本記事の 3 ルート（Plugin / GitHub Actions / Managed）
• 公式ルートは 3 つ：(A) code-review plugin（Pro/Max でも OK、手元の Claude Code で /code-review、push 前ローカル）／(B) GitHub Actions（Pro/Max でもチームでも、ANTHROPIC_API_KEY 持参、CI 自動化）／(C) Managed Code Review（Team/Enterprise 専用、$15-25/PR、push 後自動）
• カスタマイズは CLAUDE.md（プロジェクト全体、nit 扱い）と REVIEW.md（レビュー専用、最高優先注入）の二段（主に Managed 向け）
• 個人 Pro/Max ユーザーの最短は (A)、CI 自動化したいなら (B)、Team/Enterprise の最短は (C)
• 最小手は (A) なら /plugin install code-review@claude-plugins-official 1 行／(B) なら pull_request: opened 限定の 10 行 workflow yml／(C) なら PR テンプレに @claude review once を 1 行

「同僚にレビューを頼むのを諦めた日」から、「Claude が最初の 1 段を見て、人間は本質的な判断だけ」に分業するのが、現状の Anthropic 公式が推奨する PR 運用です。シリーズ次回は #13：チーム運用に広げる ─ subagent と skill の共有戦略 を予定しています。