Claude CodeのCode Reviewの使い方｜PRレビューの設定と確認

Claude CodeのCode Reviewは、GitHubのプルリクエスト（PR）をClaudeが自動でレビューするサービスで、Claudeの組織のOwnerが管理画面の「Allow code review」をオンにし、GitHubアプリを入れてリポジトリを選ぶと使えます。対象はTeamプランとEnterpriseプランで、レビューはPRを開いた時、pushした時、または「@claude review」とコメントした時に動きます（公式のCode Reviewのページ）。

この記事は、Code Reviewの機能に絞って、使える条件、有効化の手順、レビューを出す方法、指摘の読み方、調整の仕方、費用の考え方、できないことを公式の記載の範囲で整理します。GitHub Actionsに自分でClaude Codeを組み込む設定はClaude Code GitHub Action セキュリティの記事で扱っているため、ここでは違いを示すにとどめます。

確認日は2026年10月16日です。Anthropicの公式記事は2026年10月15日付で、Code Reviewがリサーチプレビューを終えて提供される旨を伝えています（公式のCode Review一般提供の記事）。画面の名称や設定項目は更新されることがあるため、実際の操作では公式の最新のページも見てください。

Code Reviewとは｜PRに何を残すサービスか

Code Reviewは、Anthropicのインフラ上で動くマネージドなレビューサービスです。複数のエージェントが変更箇所と周辺のコードを読み、見つけた問題を検証してから、PRに指摘を投稿します。

公式のページによると、レビューは4段階で進みます。複数のエージェントが差分と周辺のコードを並行して調べ、次に検証の段階で候補の指摘をコードと照らして誤検知を除き、残った指摘を重複排除して重要度順に並べ、最後にPRへ投稿します（公式のCode Reviewのページ）。

PRに残るものは3種類です。変更行へのインラインコメントとレビュー本文の要約、「Claude Code Review」という名前のチェック実行（check run）、そして指摘がない場合は「Code review found no issues」というタイトルのチェック実行と短い通知です。標準では、本番で壊れるバグのような正しさの問題を見るもので、書式の好みやテスト不足の指摘は中心ではないと公式は説明しています（公式のCode Reviewのページ）。

使えるプランと条件｜先に確かめておくこと

Code Reviewは、TeamプランまたはEnterpriseプランのClaude組織で、リポジトリがGitHubにある場合に使えます。公式が対象として挙げるのはこの2つなので、先に組織の契約を確かめます。

公式のCode Reviewのページが挙げる条件を表にまとめます。各行の出典は同じページです（公式のCode Reviewのページ（Availability））。

確認する点	公式の記載
プラン	TeamとEnterprise
コードのホスト	GitHubのリポジトリ。GitHub Enterprise Serverと、データレジデンシー付きのGitHub Enterprise Cloudを含む
データ保持	Zero Data Retentionを有効にした組織や、HIPAA構成を適用した組織では使えず、BAAの対象にもならない
暗号鍵	顧客管理の暗号鍵（CMEK）を使う組織ではまだ使えない
クラウドプロバイダー	開発者がAmazon Bedrock、Google Cloud、Microsoft FoundryでClaude Codeを使っていても、上記プランのClaude組織が必要

2026年10月15日付の公式の一般提供の記事も、Code ReviewがTeamとEnterpriseの組織で使えると書いています（公式のCode Review一般提供の記事）。GitLabなどGitHub以外のホストについては、上のページで対象として挙げられていません。

有効化の手順｜Ownerが管理画面でオンにする

有効化は、Claude組織のOwnerがclaude.aiの「Admin settings > Claude Code」にある「Code review」の項目で行います。レビューはAnthropicのインフラで動くため、リポジトリにワークフローのファイルを足す作業はありません。

始める前に、公式のセットアップのページが求める権限を揃えます。Claude組織のOwnerロール、GitHub組織のOwner（GitHubアプリのインストールとClaude組織への連携に必要）、追加するリポジトリへの書き込み権限（接続するGitHubアカウントで）の3つです（公式のCode Reviewのセットアップのページ）。手順は次のとおりです。

1. 「Admin settings > Claude Code」の「Code review」で「Allow code review」のスイッチをクリックします。
2. 「Connect GitHub」のダイアログが出たら「Connect」を押し、GitHubでClaudeを承認します。
3. 対象のリポジトリが一覧にない場合は「Install GitHub App」からGitHubアプリを入れ、アクセスさせるリポジトリを選んで権限を承認します。
4. レビューしたいリポジトリを選んで「Continue」を押します。
5. 「Code review is set up」のダイアログで「Finish」を押してオンにします。
6. ドラフトでないテスト用のPRを開き、「Claude Code Review」という名前のチェック実行が出ることを確かめます。

手順3のGitHubアプリが求める権限は、レビューが使う範囲より広く、GitHub Actionsなど他のClaudeの機能と共有されると公式は書いています（公式のCode Reviewのセットアップのページ）。インストール時の承認画面で権限の内容を読んでから進めてください。2026年10月15日付の一般提供の記事も、管理者がClaude Codeの設定で有効にしてGitHubアプリを入れ、対象リポジトリを選ぶと、新しいPRでレビューが自動で動くと説明しています（公式のCode Review一般提供の記事）。

手順4でリポジトリを追加した直後の初期値は「After every push」で、レビューが最も多く動く設定です。費用を抑えたい場合は、次のセクションの設定を先に見直します。

レビューが動くタイミングを決める｜Review runsの3つの設定

Review runsは、リポジトリごとに、どのタイミングでPRをレビューするかを決める設定です。選択肢は「Once after PR creation」「After every push」「Manual (@claude review)」の3つです。

各設定の動きは、公式のセットアップのページの記載を整理すると次の表になります（公式のCode Reviewのセットアップのページ（Set when reviews run））。

設定	レビューが動く場面	向いている使い方
Once after PR creation	PRを開いた時、再オープンした時、Ready for reviewにした時	PRごとにレビューを1回にしたいとき
After every push	PRのブランチへのpushのたび。修正を直すと、指摘のスレッドが自動で解決されることもある	PRが育つ間も新しい問題を拾いたいとき
Manual (@claude review)	開いた時やpushでは動かず、コメントで依頼した時だけ	PR数の多いリポジトリで、必要なPRだけレビューしたいとき

Manualの設定でも、「@claude review always」とコメントしたPRは、以後のpushでもレビューされます。また、どの設定でも、自動のレビューはドラフトのPRとフォークからのPRを飛ばします。これらは次のセクションのコメントコマンドで依頼します（公式のPRでのレビューのページ）。

レビューの深さを選ぶ｜Quick・Standard・Deep

レビューレベルは、1回のレビューをどれだけ深く行うかを決める設定で、深いほど費用が増えます。Quick、Standard、Deepの3段階で、初期値はStandardです。

レベル	公式の説明
Quick	軽めの確認。最も速く、費用は最も低い
Standard	深さ、速さ、費用のバランス型。初期値
Deep	最も徹底した確認。時間が最もかかり、費用も最も高い

Ownerは組織の既定のレベルを1つ決め、リポジトリごとに上書きできます。たとえば定型的なコードベースはQuick、重要なコードベースはDeepにします。レビューに使うモデルは管理画面では選べず、Code Reviewが選ぶ仕組みだと公式は書いています。深さを変えたいときは、モデルではなくレビューレベルを変えます。新しいレベルは、変更後に始まるレビューから適用されます（公式のCode Reviewのセットアップのページ（レビューレベル））。

速さについて、公式の一般提供の記事は、多くのレビューがリサーチプレビューの頃の約20分から6〜10分に縮み、約3倍速くなったと書いています（公式のCode Review一般提供の記事）。実際の所要時間はPRの大きさとレベルで変わるため、手元のPRで測ってください。

PRでレビューを出す方法｜コメントコマンドと条件

PRにコメントで「@claude review」と書くと、Claudeにレビューを依頼できます。書き込み権限があれば、Ownerでなくても、ドラフトやフォークからのPRにも使えます。

使えるコマンドは3つです（公式のPRでのレビューのページ（Comment commands））。

コマンド	動き
@claude review	1回だけレビューする。以後のpushは購読しない
@claude review always	レビューし、以後のpushごとのレビューにも購読する
@claude review once	@claude reviewと同じ

コマンドが効くには、次の条件がすべて必要です。PRへの新しいトップレベルのコメントとして投稿すること（差分行へのインラインコメントやレビュー本文、前のコメントの編集は対象外）、コメントの先頭にコマンドを書き、「always」を同じ行に置くこと、リポジトリへのwrite、maintain、admin のいずれかの権限があること、PRがオープンであることです。ボットのコメントではレビューは始まりません。受け付けられると、「Code review queued…」というタイトルのチェック実行が出て、始まると「Code review in progress…」に変わります（公式のPRでのレビューのページ（Comment commands））。

コメントにClaudeが付ける目のリアクションは、レビューが始まらない場合にも付くことがあると公式は書いています。始まったかどうかは、リアクションではなくチェック実行で判断します。同じ最新コミットに対してレビューがすでに動いている間は、2つ目のレビューは始まりません。

2026年7月の更新より前は、「@claude review」がpushごとのレビューへの購読も兼ねていたと公式は注記しています。以前の挙動に頼っていた場合は、「@claude review always」に書き換えます。

指摘の読み方と返し方｜重要度とチェック実行

Code Reviewの指摘は、Important、Nit、Pre-existingの3つの重要度で印が付き、インラインコメントとチェック実行の詳細の両方で読めます。レビューがPRを承認したりブロックしたりすることはありません。

重要度	意味（公式の説明）
Important（赤の印）	マージ前に直すべきバグ
Nit（黄の印）	直す価値はあるが、マージを止めるほどではない軽微な問題
Pre-existing（紫の印）	コードベースにすでにあり、このPRで入ったものではないバグ

印の色と意味は公式のPRでのレビューのページに沿っています（公式のPRでのレビューのページ（Severity levels））。指摘に「Why this was flagged」の折りたたみがある場合は、開くと、なぜ指摘したかと、どう検証したかが読めます。

チェック実行の「Details」には、指摘が重要度順の1つの表にまとまります。インラインコメントとして受け付けられなかった指摘もここに載り、行のある指摘は「Files changed」タブの注釈にも出ます。チェック実行の結論は中立（neutral）かスキップで、失敗にはなりません。そのため、必須チェックに設定しても、レビューが終わっただけでマージが止まることはありません。自分のCIで結果を使いたい場合は、Detailsの最後の行にある機械可読のコメントから、重要度ごとの件数を読めると公式は説明しています（公式のPRでのレビューのページ（Check run output））。

指摘への対応は3通りです。コードを直してpushすると、次のレビューが直ったと判断した時点で元のスレッドを解決します。直さずに閉じたいときは、GitHubでスレッドを自分で解決します。返信だけでは指摘は消えません。意見がある場合は返信を書くと、次のレビューが返信を読み、スレッドの解決か追加の返信を1回行うことがあります。返信そのものはレビューを始めません（公式のPRでのレビューのページ（Respond to findings））。

pushを契機に自動で走る2回目以降のレビューは、前回から変わった部分に集中し、軽微な指摘や既存バグの指摘を少なめにします。PR全体をもう一度見せたいときは「@claude review」とコメントします。

REVIEW.mdとCLAUDE.mdで指摘を調整する

REVIEW.mdは、Code Reviewだけに効かせる指示を書くリポジトリのファイルです。CLAUDE.mdはClaude Code全般の指示で、Code Reviewもプロジェクトの背景として読みます。

公式のカスタマイズのページでは、REVIEW.mdをリポジトリのルートに置き、重要度の基準の見直し、軽微な指摘の上限、生成ファイルやCIがすでに見ているものの除外、チームの規則の追加、根拠の要求などを書けるとしています。サブディレクトリにもREVIEW.mdを置くと、そのパス以下の変更への確認を足せます（公式のCode Reviewのカスタマイズのページ）。

CLAUDE.mdの書き方はClaude CodeのCLAUDE.md書き方の記事にまとめています。手元の/code-reviewコマンドはCLAUDE.mdを読みますがREVIEW.mdは読まない、と公式は書いています。両方に効かせたい指示はCLAUDE.mdに置き、PRレビュー専用の規則だけREVIEW.mdに置くと整理しやすくなります。

見落としやすいのは、REVIEW.mdを読む場所です。公式によると、レビューはPRのベースブランチかデフォルトブランチのREVIEW.mdを読み、PR自身の変更の中のREVIEW.mdは読みません。重要度を下げる、パスを除外する、軽微な指摘に上限を付けるといった指示を効かせるには、REVIEW.mdをマージしたうえでデフォルトブランチを保護します。保護を確認できない場合、レビューはREVIEW.mdを読まないとされています（公式のCode Reviewのカスタマイズのページ（読み込む枝））。

料金と支出の上限｜1回いくらではなく使用量で決まる

Code Reviewには、レビュー1回あたりの定額の料金はありません。トークン使用量に応じて、プランの含まれる使用量とは別に、使用量クレジット（usage credits）から請求されます。

公式の費用のページによると、1回のレビューの費用は、レビューレベル、変更の大きさ、周辺コードの複雑さ、検証が必要な候補の数で変わります。請求は、PRを開いた開発者ではなく組織に付きます（公式のCode Reviewの費用のページ）。一般提供の記事には基本料金の記載がなく、プロモーションとして、対象のEnterprise組織が2027年1月15日までに少なくとも1万ドル分のCode Reviewクレジットを受け取れる旨と、クレジットは受け取りから30日で失効する旨が書かれています（公式のCode Review一般提供の記事）。自社が対象かどうかは、公式の記載と契約の内容で確かめてください。

月の費用の見積りは、公式が示す手順をそのまま式にすると考えやすくなります。まず少数のリポジトリで試し、管理画面の「Repositories」表にある「Average cost」列から、レビュー1回の平均の費用を読みます。それに月のPR数を掛け、「After every push」なら、さらにPRあたりのpush回数を掛けます（公式のCode Reviewの費用のページ（Estimate your spend））。設定ごとの式を並べると次のとおりです。

Review runsの設定	月の費用の見積り式
Once after PR creation	平均の費用 × 月のPR数
After every push	平均の費用 × 月のPR数 × PRあたりのpush回数
Manual (@claude review)	平均の費用 × コメントで依頼したレビューの回数

上の式は、公式の説明を基にこの記事で整理したものです。公式は、コメントによる単発の依頼はpush数を増やさないこと、「@claude review always」を付けたPRはpushごとに費用が増えること、ドラフトとフォークからのPRは自動のレビューに加わらないことも書いています。

支出の上限は、claude.ai/admin-settings/usageで、Claude Code Reviewのサービスに月額の上限として設定できます。上限、組織全体の支出上限、使用量クレジットの残高のいずれかが尽きる、または残りが1回のレビューの見込み費用を下回ると、レビューはスキップされます。スキップされたPRには、原因と設定画面へのリンクが付いたコメントが付きます。GitHub組織全体を一括でカバーする設定には、月額の上限があらかじめ必要です（公式のCode Reviewの費用のページ（Limit your spend））。

利用状況は、claude.ai/analytics/code-reviewで確かめられます。レビューしたPR数、当月のCode Reviewの費用、自動で解決された指摘の数、リポジトリごとの内訳が出ます。分析画面の金額は定価に基づく見積りで、請求額と一致しないことがあるため、請求の正確な金額はAnthropicの請求書で見ると公式は書いています。

できないことと注意点｜レビューの範囲を知っておく

Code Reviewは、PRを承認もブロックもせず、コードをビルドも実行もしません。AIによるレビューで、見逃しがありうると公式が明記しています。

公式のページから、できないことと制約を拾うと次のとおりです（公式のCode Reviewのページ）。

• PRの承認やブロックはしません。マージの判断はチームに残ります。チェック実行も失敗とはなりません。
• レビューは差分と周辺のコードを読んで行い、コードのビルドや実行はしません。
• リポジトリへのアクセスは読み取り専用で、レビューがコミットをpushすることはありません。
• Anthropicのインフラで動き、自前でホストした環境（self-hosted environments）では動きません。
• 指摘がないレビューは、コードに誤りがない、あるいは安全だという意味ではないと公式は注意しています。
• Zero Data Retention、HIPAA構成、CMEKの組織は対象外で、GitHub以外のホストも対象に挙がっていません。

レビューの結果は、あくまでも人のレビューを助ける材料です。マージ前の確認の最後の砦にしない前提で、チームの運用に組み込んでください。

ほかのレビュー手段との使い分け

Claudeにコードをレビューさせる手段は、Code Reviewのほかに複数あります。誰が使えるか、何が起点か、どこで動くかが違うため、組織の状況に合わせて選びます。

公式のCode Reviewのページにある比較を、要点だけ表にします（公式のCode Reviewのページ（比較））。

手段	起点	動く場所	使える人
Code Review	PRの動き、または「@claude review」のコメント	Anthropicのインフラ	TeamかEnterpriseで、GitHubのリポジトリがあり、Ownerがオンにした組織
/code-review	自分でコマンドを実行	手元のClaude Codeのセッション	どのプランでも
Ultrareview	Claude Codeから開始	クラウドのサンドボックス	claude.aiアカウントでのサインインが必要
自分のCIでClaudeを動かす（GitHub ActionsやGitLab CI/CD）	パイプラインのイベント	自分のCIランナー	APIキーかクラウドの認証情報がある人
自作のレビュー用サブエージェントやスキル	自分かClaudeが呼ぶ	Claude Codeを動かす場所	書ける人なら誰でも

プランがTeamやEnterpriseでない場合は、手元で/code-reviewを使うのが近道です。自前のCIで細かく制御したい場合はGitHub Actionsを選びますが、権限とトークンの設計が必要になります。その設計はClaude Code GitHub Action セキュリティの記事で扱っています。サブエージェントで自作するならClaude Codeのサブエージェント使い方の記事が入口になります。

すでにGitHub ActionsでClaude Codeを「@claude」で動かしている場合は、注意点があります。「@claude review」のコメントが、Code Reviewだけでなく、そのActionも起動することがあります。両者を分けたいときは、Actionのtrigger_phraseに別のフレーズを設定します（公式のPRでのレビューのページ（Actionとの併用））。

手元のセッションでの許可やフックは、Code Reviewの管理画面の設定とは別の話です。必要に応じてClaude Codeの権限設定の記事とClaude Codeのフックの記事も参照してください。

うまく動かないときの見方｜チェック実行のタイトルから探る

レビューが期待どおりに動かないときは、まずPRの「Claude Code Review」チェック実行のタイトルを見ます。タイトルが、レビューがどこまで進んだかを示します。

チェック実行のタイトル	意味	公式が示す対処
Code review queued… / in progress…	まだ終わっていない	タイトルが変わるのを待つ
Code review found no issues	終わり、指摘なし	対処は不要
Code review skipped — no new changes	最新のpushで自動レビューが動かなかった	必要なら「@claude review」とコメントする
Code review failed / timed out	レビューが完了しなかった	「@claude review」のコメント、またはチェックの「Re-run」で再実行する
Code review declined	レビューが動かなかった	要約を読み、予算や支出上限の記載があれば管理者が復旧する
チェック実行が出ない	レビューが始まっていない	「@claude review」とコメントする

上の表は公式のトラブルシューティングのページに基づきます（公式のCode Reviewのトラブルシューティングのページ）。チェック実行が出ないときは、Allow code reviewがオンか、対象のリポジトリが一覧にあるか、GitHubアプリがそのリポジトリにアクセスできるかを順に調べます。ドラフトのPRは自動のレビューの対象外で、Manualのリポジトリは最初の1回をコメントで依頼する必要があります。

予算の問題でスキップされた場合、PRには「Code review skipped」で始まるコメントが付きます。予算を回復した後は、「@claude review」とコメントすると、スキップされたレビューを受けられます。ただしコメントを書く人にはwrite権限が必要です。インラインコメントが見当たらない場合は、チェック実行の「Details」、「Files changed」の注釈、レビュー本文の「Additional findings」の順に探します。

よくある質問（FAQ）

Q1. Proプランの個人でもCode Reviewは使えますか。

公式のページが対象として挙げているのはTeamとEnterpriseです。個人のProやMaxを対象とする記載は、この記事で確認した公式のページにはありませんでした。手元でClaudeにレビューさせたい場合は、どのプランでも使える/code-reviewが案内されています（公式のCode Reviewのページ）。

Q2. 誰がCode Reviewを有効にできますか。

Claude組織のOwnerが、claude.aiの「Admin settings > Claude Code」で有効にします。GitHubアプリの導入にはGitHub組織のOwnerの権限も必要です。一般の開発者は、PRへのコメントでレビューを依頼したり、REVIEW.mdやCLAUDE.mdをリポジトリに追加したりできますが、レビューレベルや実行タイミングは変えられません（公式のCode Reviewのセットアップのページ）。

Q3. レビューは自動で動きますか。

リポジトリのReview runsの設定次第です。追加直後はpushのたびに動く設定で、PR作成時の1回やManualにも変えられます。ドラフトとフォークからのPRは、どの設定でも自動では動きません（公式のCode Reviewのセットアップのページ）。

Q4. 指摘が多すぎるときはどうすればよいですか。

リポジトリのREVIEW.mdに、軽微な指摘の上限や、生成ファイルなど対象から外すものを書きます。REVIEW.mdはデフォルトブランチなどからだけ読まれるため、先にマージします。レビューの深さそのものは、Ownerがレビューレベルで変えます（公式のCode Reviewのカスタマイズのページ）。

Q5. レビューがPRのマージを止めることはありますか。

Code Review自体は、PRを承認も拒否もせず、チェック実行も失敗になりません。ただし、リポジトリのブランチ保護で「会話の解決」を必須にしている場合は、指摘のスレッドを解決してからマージします（公式のPRでのレビューのページ）。

Q6. 費用はどこで確かめますか。

リポジトリごとの平均の費用は管理画面の「Repositories」表、当月の費用と利用状況はclaude.ai/analytics/code-reviewで見られます。請求額の正確な金額はAnthropicの請求書を見ます。月額の上限はclaude.ai/admin-settings/usageで設定します（公式のCode Reviewの費用のページ）。

Q7. 日本語でレビューしてもらえますか。

レビューの言語については、この記事で確認した公式のページに記載を見つけられませんでした。REVIEW.mdに書く指示で調整できるかどうかも、公式では確認できていないため、実際のPRで試して確かめてください。

Code Reviewを始めるときの流れ

最初に、組織がTeamかEnterpriseで、リポジトリがGitHubにあり、ZDRやHIPAA構成、CMEKの対象でないことを確かめます。次に、Ownerが「Admin settings > Claude Code」で「Allow code review」をオンにし、GitHubアプリを入れて、少数のリポジトリから始めます。費用が読めるまでは、Review runsを「Once after PR creation」か「Manual (@claude review)」にし、月額の上限を置くと進めやすくなります。テスト用のPRで「Claude Code Review」のチェック実行が出ることを確かめたら、「Average cost」を見て対象を広げます。指摘の質は、REVIEW.mdで重要度や除外を調整して整えます。マージの判断は引き続き人が行います。