GitHubでチーム開発していて、PRのレビューをClaudeに任せられるか知りたい人向け
GitHubでチーム開発していて、PRのレビューが特定の人に集中して詰まっている時や、外部から来たPRを本流に取り込む前に自動でふるいにかけたい時に使う。adminが組織にClaudeのGitHub Appを入れて対象プロジェクトを選んでおき、PRに @claude review とコメントするか、開いた時に自動で走るよう設定して動かす。
Code Review は、GitHub上のPR（Pull Request＝コードの変更案を出す申請）をClaudeが読み、問題を見つけた行に直接コメントを付けてくれる仕組みです。チーム開発で「このPR、レビューする人が手一杯で止まってる」みたいな詰まりを、人間レビュアーの前にもう一枚はさんで減らすのが狙いです。
動かす場所がターミナルではなくGitHub側という点が、ほかのレビュー機能と決定的に違います。一度adminが組織に入れてしまえば、対象に選んだプロジェクトのPRに対して勝手に走ってくれます。
名前が紛らわしいので先に言っておくと、ターミナルのClaude Codeセッションで打つ /code-review コマンドや、セキュリティ特化の /security-review とは別物です。この記事で扱うのはGitHubで自動的に動くサービスのほう。混同しやすいので、最後の落とし穴で3つをきっちり切り分けます。
噛み砕くと
新しく開いたお店に、専門の違う検査員が何人もまとめて入ってくる様子を想像すると近いです。論理のミス担当、セキュリティの穴担当、見落とされがちな例外パターン担当、というふうに役割を分けた検査員たちが、変更されたコードを同時に見ていきます。
ひとりの担当が「ここ怪しい」と言っても、すぐコメントにはなりません。別の確認役が「本当にその挙動になるか」を実際のコードで突き合わせて、勘違い（誤検知）をふるい落とします。残ったものだけが、問題のあった行にメモとして貼られる。
この検査員たちはAnthropic側のサーバーで動きます。自分のパソコンが重くなることはありません。
大事な前提：使えるのはTeam / Enterprise契約だけ
ここが一番つまずきます。Code Review は research preview（試験提供中）の機能で、使えるのは Team プランと Enterprise プランの契約だけです。個人向けの Pro や Max では、そもそもメニューに出てきません。
もうひとつ条件があって、Zero Data Retention を有効にしている組織では使えません。これはデータを一切残さない設定で、略してZDRと呼ばれます。ここに当てはまると、いくらadminが設定しようとしても入れられない。
「ローカルで試したいだけ」なら、後述するターミナルの /code-review コマンドが契約に関係なく使えます。そこは安心していい。
「料理ブログのレシピ検索機能」を例に、実際の手順を見る
料理ブログのプロジェクトがGitHubにあって、組織はTeam契約、adminがすでにClaudeのGitHub Appを入れてこのプロジェクトをCode Review対象にしてある、という状態から始めます。ここに「レシピを検索できる機能」を足すPRを出してみます。
ステップ1: 検索機能用のbranchを作る
まず作業用のbranch（枝分かれした作業場所）を切って、そこにレシピ検索のコードを書きます。本流のコードを直接触らず、別レーンで作業するイメージです。
$ git switch -c add-recipe-searchステップ2: 変更をpushしてPRを開く
書いたコードをGitHubに上げ（push）、ブラウザでPRを開きます。「レシピ検索機能を追加」みたいなタイトルを付けて、変更内容を申請する画面を作る。
$ git push origin add-recipe-searchここで初心者がやりがちな勘違いをひとつ。PRを開いた瞬間に必ずレビューが走るわけではありません。走るタイミングは組織側の設定（後述の3択）で決まっていて、Manual設定なら自分でコメントして呼ぶまで動きません。
ステップ3: PRに @claude review とコメントする
Manual設定の場合、PRの一番上のコメント欄に @claude review と書いて投稿します。これがレビュー開始の合図です。
@claude review注意点として、これはdiffの行に付けるコメント（inlineコメント）ではなく、PR全体への一番上のコメントとして書きます。あと、そのプロジェクトに owner / member / collaborator のどれかの権限が要ります。PRが閉じていると動きません。
ステップ4: 解析を待つ
コメントすると、Anthropic側で複数の検査員（agent）が変更内容を同時に読み始めます。料理ブログ程度の小さいPRなら数分、大きいPRでも平均20分ほどで終わります。
かかる時間と費用はPRの大きさに比例します。小さく出すほど速く安く済む。
費用の出どころにも注意がいります。Code Reviewの料金は usage credits（追加で買い足せる利用枠）から別立てで引かれ、TeamやEnterpriseプランにもとから付いている月の利用枠とは別勘定になっています。1回あたり平均$15〜25なので、走らせた回数ぶんがプラン料金とは別に積み上がります。
ステップ5: 該当行にコメントが付く
解析が終わると、問題のあった行に重要度マーク付きのコメントが貼られます。たとえばレシピ検索のコードで、利用者が入力した検索ワードをそのままデータベースへの命令文に埋め込んでいたとします。これは外部から悪意ある文字列を流し込まれる穴になるので、🔴 Important として該当行にコメントが付く、といった具合です。
全体のまとめはレビュー本文に書かれ、Checkタブの「Claude Code Review」のDetailsから、見つかった指摘の一覧をまとめて確認できます。
ステップ6: コードを直してpushする
指摘を直したいときは、コメントに返信するのではなく、コードを修正してもう一度pushします。「After every push」設定なら、直した箇所に対応するコメントのやり取りが自動で解決済みになります。
$ git push origin add-recipe-searchつまり Code Review は何をしてくれるのか
- やってくれる: 変更コードを全体のコードと突き合わせて、論理ミス・セキュリティの穴・壊れる例外パターン・見落としがちな劣化を探し、該当行に重要度マーク付きでコメントを貼る
- やってくれる: 重要度を🔴/🟡/🟣の3段階で仕分けて、まとめをレビュー本文に書く
- やってくれない: PRを承認したりマージを止めたりはしない。結果は「neutral（どちらでもない）」扱いで、既存のレビューの流れを壊さない
- やってくれない: inlineコメントに返信しても反応しない。直すならコードを修正してpushする
- 意味が薄い場面: 個人プラン（Pro / Max）や、データを一切残さない設定の組織。そもそも使えない
使いどころ3シナリオ（具体題材で再現）
シナリオ1: レビュアーが1人しかいない小さなチームのとき
料理ブログを3人で開発していて、コードを読めるベテランが1人だけ、という状況はよくあります。その1人にPRが全部集まると、レビュー待ちで前に進まない。ここでCode Reviewを「Once after PR creation（PRを開いたら1回走る）」にしておくと、人間が見る前に明らかなミスや穴がコメントで出そろいます。ベテランは残った設計判断だけに集中できる。私はこの「下読みを機械に任せる」使い方が一番効くと思っています。
シナリオ2: 外部の人からPRが来るオープンソースのとき
料理ブログのプロジェクトを公開していて、見知らぬ人が「レシピのお気に入り機能を作りました」とPRを送ってきた。どこの誰が書いたか分からないコードを、いきなり本流に取り込むのは怖いですよね。Code Reviewを通せば、利用者入力の扱いやセキュリティの穴を自動で洗ってくれるので、人間が中身を読む前のふるいになります。これは正直ありがたい。
シナリオ3: 大きな書き換えで「壊した気がする」とき
レシピ検索を作るついでに、検索結果の並び替え部分も大きく書き換えた。こういう「ついで改修」は、前から動いていた別の機能を静かに壊しがちです。Code Reviewは変更を全体のコードと突き合わせて、既存の劣化（regression）や、このPRで作ったわけじゃないけど見つかった既存のバグ（🟣 Pre-existing）も拾います。自分の目だけでは追いきれない範囲を補ってくれる。
重要度マークとレビュー開始タイミングの一覧
コメントに付く重要度は3段階です。色で深刻さがひと目で分かるようになっています。
- 🔴 Important: マージ前に直すべきバグ
- 🟡 Nit: 直す価値はあるけれど、止めるほどではない小さな指摘
- 🟣 Pre-existing: このPRで持ち込んだわけではないが、コード内にもとからあったバグ
レビューが走るタイミングも、組織側で3択から選びます。
- Once after PR creation: PRを開いた、またはレビュー可能にした時に1回だけ走る
- After every push: push のたびに走る。PRが育つたびに新しい問題を拾い、直した指摘は自動で解決済みになる
- Manual: 誰かが
@claude reviewか@claude review onceとコメントした時だけ走る
初心者が踏みやすい落とし穴
- 3つの似た名前を混同する。この記事のCode Reviewは、GitHubで自動的に動くサービスでTeam / Enterprise限定。ターミナルで打つ
/code-reviewコマンドは、GitHub Appを入れずに手元の変更を1回見てもらう別物です。このコマンドはv2.1.147より前は/simplifyという名前でした。/security-reviewはセキュリティの穴に特化した、さらに別のコマンド。3つは完全に別物。 - Pro / Max では使えない。Team / Enterprise契約だけ。個人プランではメニューに出てこない。データを一切残さない設定の組織も対象外。
- PRをブロックも承認もしない。Checkの結果は常に「neutral」で完了するので、ブランチ保護ルール（マージ前に通すべき条件）でマージを止める用途には使えない。止めたいなら自前のCI（自動チェックの仕組み）でCode Reviewの結果を読み取って判定する。
- inlineコメントに返信してもClaudeは反応しない。指摘に対処したいなら、返信ではなくコードを直してpushする。これが唯一の正しい動かし方。
- GitHubのCheckタブのRe-runボタンでは再実行されない。あのボタンを押してもCode Reviewは走り直さない。もう一度走らせたいなら
@claude review onceとコメントするか、新しくpushする。 - @claude review は「pushごと」に購読されて費用が積む。
@claude reviewは今後のpushにも自動で反応するよう登録される。1回だけ見てほしいなら@claude review onceを使う。1回のレビューで平均$15〜25かかるので、ここの差は地味に効く。 - CLAUDE.md と REVIEW.md の役割を取り違える。CLAUDE.md はプロジェクト全体の指示で、Code Reviewはそれを文脈として読み、新しく違反した箇所を🟡 Nitとして指摘する。REVIEW.md はレビュー専用の指示で、各検査員に最優先で渡される。「何を・どの重要度で指摘するか」を変えたいなら REVIEW.md のほう。
書き方
@claude review
@claude review onceやってみるとこうなる
入力
（PRの一番上のコメント欄に投稿）
@claude review once出力例
Anthropic側の検査員が変更を解析し、問題のあった行に重要度マーク付きのコメントが付く。例: 検索ワードを命令文にそのまま埋め込んでいる行に「🔴 Important: 利用者入力をエスケープしていない」。Checkタブの「Claude Code Review」Detailsに指摘一覧、レビュー本文に全体のまとめが出る。PRの承認やマージのブロックはしない（neutralで完了）。1回平均$15〜25、平均20分。このページに出てきた言葉
- PR（Pull Request）
- GitHubで「このコードの変更を取り込んでください」と出す申請。変更一覧とレビューがここに集まる
- research preview
- 正式版の前の試験提供段階。仕様や使える範囲が今後変わる場合がある
- Team / Enterprise
- Claudeの組織向け契約。Code Review はこの2つだけで使える（個人向けのPro / Maxでは使えない）
- ZDR（Zero Data Retention）
- 入力データをAnthropic側に一切残さない契約設定。これを有効にした組織はCode Reviewを使えない
- 重要度3段階
- 🔴 Important（マージ前に直すべきバグ）/ 🟡 Nit（直す価値はあるが止めるほどでない小さい指摘）/ 🟣 Pre-existing（このPRで持ち込んだのではない既存のバグ）
- @claude review / @claude review once
- PRの一番上のコメントに書く合図。review は今後のpushにも自動で反応するよう登録され、once は1回だけ走らせて登録しない
- neutral check run
- Code Reviewの結果は常に「どちらでもない」で完了する。だからマージを止めも承認もせず、既存のレビュー運用を壊さない
- CLAUDE.md と REVIEW.md
- CLAUDE.mdはプロジェクト全体の指示でレビューは文脈として読む。REVIEW.mdはレビュー専用の指示で各検査員に最優先で渡される