Claude Code Code Reviewは、GitHubのプルリクエスト（PR）ごとに複数のAIエージェントが変更と周りのコードを読み、見つけた問題を検証してから該当する行にコメントする機能で、2026年10月18日時点ではTeamとEnterpriseのプランの組織が使えます。Anthropicが2026年10月15日に研究プレビューを終えて正式提供にしました（Anthropicの正式提供の告知）。料金は1回あたりの定額ではなく、使ったトークン量に応じて、プランに含まれる利用枠とは別のusage credits（利用クレジット）から組織に請求されます（料金と使用量のドキュメント）。
結論：Code Reviewは人の代わりにPRを承認する機能ではなく、人が見る前に不具合を拾っておく機能です。費用は使った分だけ組織に請求されるので、1つのリポジトリで平均費用を測ってから広げるのが安全です。
- 要点1：10月15日に正式提供。多くのレビューは研究プレビューの頃の約20分から6〜10分で終わるようになり、リポジトリごとにQuick・Standard（既定）・Deepの段階を選べます。
- 要点2：Zero Data Retention（ZDR）を有効にした組織、HIPAA構成の組織、顧客管理の暗号鍵（CMEK）を使う組織は使えません。有効にできるのはClaudeの組織のOwnerです。
- 要点3：「Add a repository」で1つずつ追加したリポジトリは「After every push」（pushのたびにレビュー）で始まります（GitHubの組織ごと対象にした時は組織の設定を引き継ぎます）。試験導入は「Once after PR creation」か「Manual」で始め、月の上限を先に決めます。
- 要点4：同じ日にClaude Codeの開発チームがレビューの進め方を公開しました。6〜9月にマージしたPRは2倍超に増え、差し戻し（revert）の割合は40%超減ったとしていますが、同社の社内の実測です。
対象読者：Claude CodeをTeam・Enterpriseで使っている会社の開発責任者と、情報システム部門の担当者。
読了後にできること：自社で使えるかを判定し、試験導入の設定（対象のリポジトリ・段階・いつ走るか・月の上限）を決められます。
最終更新：2026年10月17日。Anthropicの告知、Claude Codeの公式ドキュメント、Claudeヘルプセンター、開発チームのブログに書かれた範囲で整理しています。Anthropicの社内の数字は同社が公表した値で、他社で同じ結果になることを示すものではありません。
AIがコードを書く量は増えたのに、レビューの人手は増えない。Anthropic自身も告知で、コーディングエージェントによってコードを書く速さは上がり続けているのに、レビューの詰まりは解消していないと書いています。Code Reviewはこの詰まりに向けた機能で、PRが開かれると人が見る前にAIが一通り調べ、問題がありそうな行にコメントを残します。
ただ、使える組織には条件があり、費用は使った分だけかかります。しかもリポジトリを1つずつ追加すると、最初はpushのたびにレビューが走る設定なんです。この記事では、仕組みから導入前に決めることまでを、一次情報に書かれた範囲で整理します。
Claude Code Code Reviewとは｜仕組みと/code-reviewなどとの違い
Code Reviewをひと言でいうと、「複数の下読み役が手分けして読み、別の確認役が裏を取ってから付箋を貼る。ただし承認のハンコは押さない」仕組みです。公式ドキュメントによると、複数のエージェントが変更（差分）と周りのコードを並行して読み、論理の誤り・セキュリティの脆弱性・境界条件の不具合などを探します。候補は検証の段階でコードと突き合わせて誤検知を落とし、残った指摘だけが重要度の順に該当する行へコメントされます（Code Reviewのドキュメント）。
レビューの流れと、PRに残るもの
流れは「PRを開く→複数のエージェントが読む→指摘を検証→重要度で並べる→行にコメント」で、承認も差し止めもしない、という形です。PRには行ごとのコメント、レビュー本文の要約、「Claude Code Review」という名前のチェックラン（GitHubのChecksに出る実行結果）が残ります。何も見つからなければ、チェックランの題名は「Code review found no issues」になります。既定で見るのは正しさ、つまり本番を壊すバグで、書式の好みやテストの不足は対象外です。使うClaudeのモデルはCode Reviewが選び、管理設定にモデルの選択肢はありません。
| 印 | 重要度 | 意味 |
|---|---|---|
| 🔴 | Important | マージの前に直すべきバグ |
| 🟡 | Nit | 小さな問題。直す価値はあるが、止めるほどではない |
| 🟣 | Pre-existing | このPRが持ち込んだのではなく、もとからコードにあるバグ |
（出典：PRでのレビューの読み方のドキュメント）
承認も差し止めもしない
いちばん大事なのは、Code ReviewがPRを承認も差し止めもしないことです。マージの判断はチームに残り、チェックランも失敗では終わりません。ドキュメントには「AIのレビューはバグや脆弱性を見逃すことがあり、指摘が無いことは誤りが無い・安全であることを意味しない」という注意もあります。レビュー中のリポジトリへのアクセスは読み取りだけで、コミットをpushせず、コードをビルド・実行もしません。動かして確かめる役は、これまでどおりCIとテストが受け持つということなんです。
手元の/code-review・Ultrareview・自社のCIとの違い
Claudeにコードを見てもらう方法はほかにもあります。ドキュメントの比較表から主な4つを日本語にすると次のとおりです。
| 方法 | 何で始まるか | どこで動くか | 使える人 |
|---|---|---|---|
| Code Review | PRの動き（リポジトリごとの設定）か「@claude review」のコメント | Anthropicの基盤 | TeamかEnterpriseでGitHubのリポジトリを持つ組織（Ownerが有効にした後） |
| /code-review | 自分のブランチで実行する | 自分のClaude Codeのセッション | どのプランでも |
| Ultrareview（/code-review ultra） | Claude Codeから始める | クラウドのサンドボックス | claude.aiのアカウントでサインインした人（使えない環境あり） |
| 自社のCI（GitHub Actions・GitLab CI/CD） | パイプラインのイベント | 自社のCIのランナー | ClaudeのAPIキーかクラウド事業者の認証情報を持つ人 |
手元の/code-reviewはセッションの中で動くので、プランの利用枠かAPIの請求に含まれます（/code-reviewのドキュメント）。Ultrareviewは研究プレビューの機能で、ProとMaxには1アカウント1回限りの無料の3回があり、その後はおおむね1回5〜25ドルのusage creditsがかかります（Ultrareviewのドキュメント）。
Code Reviewは、Ownerが有効にすれば各リポジトリの設定どおりに自動で走り、費用は組織にまとめて請求されます。リポジトリにワークフローのファイルを足す必要もありません。3月の告知では、既存のClaude Code GitHub Actionより丁寧で、そのぶん費用も高い選択肢と説明されていました（研究プレビューの告知）。GitHub Actionsで組み込む方法はClaudeのGitHub連携の方法とできること、PRやworktreeの扱いはClaude CodeとGitの使い方にまとめています。なお、同じリポジトリでClaude Code GitHub Actionを既定の「@claude」の呼びかけで動かしていると、「@claude review」のコメントでActionも一緒に動くため、ドキュメントはActionの呼びかけの語（trigger_phrase）を別の語に変えるよう案内しています（PRでの使い方のドキュメント）。
10月15日の正式提供で何が変わったか｜発表の要点
AnthropicはCode Reviewを2026年3月9日にTeamとEnterprise向けの研究プレビューとして出し、2026年10月15日に正式提供にしました。正式提供の告知の要点は次のとおりです（正式提供の告知）。
| 項目 | 告知の内容 |
|---|---|
| 提供の状態 | 研究プレビューを終え、ClaudeのTeamとEnterpriseの組織で使える |
| 速さ | 多くのレビューが研究プレビューの頃より約3倍速くなり、約20分から6〜10分に |
| 指摘の質 | 本当に問題になるバグをより多く見つけ、問題・起きる条件・直し方を数文で示す |
| 段階 | 管理者がリポジトリごとにQuick・Standard（既定）・Deepを選ぶ |
| Enterprise向けのクレジット | 対象のEnterpriseの組織は、2027年1月15日までに申請すると1万ドル以上のCode Reviewのクレジットを受け取れる。申請から30日後に失効。条件あり |
| 開発者の操作 | 有効にした後は開発者側の設定なしで、新しいPRに自動でレビューが走る（ただしリポジトリの設定が「Manual」の時と、下書き・フォークからのPRは自動では走らない） |
告知によると、研究プレビューを使ったチームからは、もっと静かで、変更の大きさに合わせた、速いレビューを求める声があったそうです。3月の告知では、社内で実質的なレビューのコメントが付くPRの割合が16%から54%に上がったと書かれていました（研究プレビューの告知）。
使える条件｜Team・Enterpriseの組織とGitHubのリポジトリ
設定を始める前に、自社の組織が条件を満たすかを確かめます。ドキュメントの使える条件（Availability）と設定に要る権限をまとめると次のとおりです（Code Reviewのドキュメント・設定のドキュメント）。
| 条件 | 内容 |
|---|---|
| プラン | Team・Enterprise（どちらかのプランのClaudeの組織） |
| コードの置き場 | GitHub。自社で運用するGitHub Enterprise Serverと、データの保存先を指定したGitHub Enterprise Cloudも含む |
| 使えない組織 | ZDRの組織は不可。Zero Data Retentionを有効にした組織とHIPAA構成を適用した組織は使えず、AnthropicのBAA（Business Associate Agreement）の対象にもならない。顧客管理の暗号鍵（CMEK）を使う組織も、まだ使えない |
| 有効化 | Ownerが有効化。管理画面の手順には、すべてClaudeの組織のOwnerの権限が要る |
| GitHub側の権限 | Claude GitHub Appのインストールと連携にはGitHubの組織のOwner、追加する各リポジトリには書き込み権限が要る |
| クラウド事業者経由の利用 | Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry経由でClaude Codeを使っていても、TeamかEnterpriseのClaudeの組織が必要。費用はAnthropicの請求書に載る |
レビューはAnthropicの基盤の上で動き、自社で用意した実行環境（self-hosted environments）では動きません。GitLabなどGitHub以外に置いたリポジトリは対象外なので、比較表にある/code-reviewや自社のCIを使うことになります。Teamプランの席や料金の考え方は、Claude Code Teamプランの料金と最低人数で整理しています。
料金の仕組み｜1回の定額はなく、usage creditsで組織に請求
Code Reviewには1回あたりの定額の料金がありません。使ったトークン量に応じてusage creditsから支払い、プランに含まれる利用枠とは別に数えます。請求先は組織で、PRを開いた開発者やレビューを頼んだ人ではありません（料金と使用量のドキュメント）。
月の費用は「1回の費用」と「レビューの回数」で決まります。1回の費用を左右するのは、段階・変更の大きさ・周りのコードの複雑さ・検証する候補の数の4つ。レビューの回数は、リポジトリごとの「いつ走るか」の設定で決まります。usage creditsは標準のAPI料金で計算され、Teamプランでは組織のOwnerが前もって購入し、席ごとに契約するEnterpriseプランでは月末に実際の利用分が請求されます（ヘルプセンターのusage creditsの記事）。Claude Code全体の使用量の見方はClaude Codeの費用の見方を参照してください。
いつ走るかで回数が変わる（3つの設定）
| 設定（Review runs） | レビューが走るとき | 費用への影響 |
|---|---|---|
| Once after PR creation（PR作成時に1回） | PRを開いた・開き直した・下書きを「Ready for review」にしたとき | そのたびに1回 |
| After every push（pushのたびに） | PRのブランチにpushするたび | pushの回数だけ増える。「Add a repository」で追加した直後のリポジトリはこの設定（組織ごと対象なら組織の設定） |
| Manual（@claude review） | 書き込み権限のある人が、開いているPRに新しいコメントの先頭で「@claude review」と書いたときだけ（ボットのコメントでは走らない） | 頼んだ分だけ |
「@claude review」は1回だけのレビューです。「@claude review always」は、そのPRを以後のpushごとのレビューの対象にするので、その後はpushのたびに費用がかかります。下書きのPRとフォークからのPRは、自動のレビューの対象外です（PRでのレビューのドキュメント）。
試験導入で平均費用を測る4つの手順
ドキュメントは、広く展開する前に小さな試験導入で月の費用を見積もるよう勧めています。
- 試験導入用に月の上限を設定する
- 代表的な数個のリポジトリで、Review runsをOnce after PR creationかManualにして有効にする
- 何回か走ったら、管理設定のRepositoriesの表の「Average cost」（平均費用）列で1回あたりの平均を読む
- 平均に月のPR数を掛ける。After every pushなら、さらにPRあたりのpush回数を掛ける
平均はPRの大きさと段階で動くので、段階を変えたら測り直します。
月の上限と、足りないときにレビューを飛ばす仕組み
Code Review専用の月の上限は、claude.aiの使用量の設定（admin-settings/usage）で「Claude Code Review」のサービスに設定し、組織全体にかかります。この上限、組織全体のusage creditsの月の上限、usage creditsの残高のどれかが尽きるか、残りが1回分の見込み費用を下回ると、レビューを飛ばします。ただし、Enterpriseの特典クレジットが残っている間は、組織が上限に達していても、上限を0ドルにしていても、前払いの残高が尽きていても、レビューが走ることがあり、特典の残りを超えては請求されません（特典クレジットの案内）。飛ばしたPRには「⚠️ Code review skipped」で始まるコメントが付きます（トラブル対応のドキュメント）。分析画面の費用は請求書の金額とずれることがある（リポジトリ別の内訳は定価での見積もり）ので、正確な金額は請求書で確かめます。
3月の告知にあった平均額は研究プレビューの時点の目安
3月9日の告知には、レビューの費用は一般に平均15〜25ドルで、PRの大きさと複雑さで増減すると書かれていました（研究プレビューの告知）。これは研究プレビューの時点の目安です。正式提供後の料金のドキュメント（2026年10月17日に確認）では1回あたりの平均額を確認できず、段階も選べるようになったので、今の費用は上の手順で測るのが確かです。
Enterpriseの組織向けのクレジット（2027年1月15日までに申請）
対象のEnterpriseの組織が受け取れるクレジットの条件は、ヘルプセンターの記事に書かれています（Enterprise向けの無料クレジットの記事）。
| 項目 | 内容 |
|---|---|
| 金額 | 1万〜5万ドル。申請した時点のClaude Codeの有効な席の数で決まる |
| 申請の期間 | 2026年10月15日から2027年1月15日23時59分（UTC）まで。日本時間では1月16日8時59分まで |
| 申請のしかた | OwnerかPrimary OwnerがCode Reviewの設定画面で「Claim」を押す。組織で1回だけで、取り消せない |
| 使える期間 | 申請した時点から30日が過ぎるか、使い切るまで。レビューが走っていなくても日数は進む |
| 対象 | github.comのリポジトリのPRのレビュー。/code-review、Ultrareview、GitHub Actionで自社で動かすレビュー、GitHub Enterprise Serverでのレビューには使えない |
| 対象外の組織 | Team・Pro・Max・Freeのプラン、リセラー経由で請求される組織、試用中や、契約が解約・未払い・停止中の組織、GitHub Enterprise Serverか.ghe.comのGitHub Enterprise Cloudをつないだ組織、以前の無料提供を受けた組織、ZDRなどでCode Reviewを使えない組織 |
ヘルプセンターは、申請する前にリポジトリのCode Reviewを設定しておくよう書いています。対象のリポジトリと段階を決めてから申請するのが、無駄のない順番です。
始め方｜Ownerが有効にしてGitHub Appを入れるまで
操作はclaude.aiの「Admin settings > Claude Code」（管理設定のClaude Code）にある「Code review」欄で行います（設定のドキュメント）。
- 有効化のスイッチを押す：「Allow code review」（コードレビューを許可）のスイッチを押す
- GitHubをつなぐ：「Connect GitHub」（GitHubと接続）で「Connect」を押し、GitHubでClaudeを許可する。GitHub Enterprise Serverなら先にインスタンスを選ぶ
- GitHub Appを入れる：「Add a repository」（リポジトリの追加）に目的のリポジトリが無ければ、「Install GitHub App」からClaude GitHub Appを入れる。権限はレビューで使う分より広く、ほかのClaudeの機能と共有される
- リポジトリを選ぶ：選んで「Continue」（続ける）、次に「Finish」（完了）を押す。ほかの閉じ方をするとAllow code reviewはオフのまま
- 段階といつ走るかを決める：組織の既定の段階（Review level）と、リポジトリごとの段階とReview runsを決める
- テスト用のPRで確かめる：下書きでないPRを開き、数分のうちに「Claude Code Review」のチェックランが出るかを見る。Manualなら「@claude review」とコメントする
段階（Quick・Standard・Deep）の選び方
| 段階 | 中身 |
|---|---|
| Quick | 軽めの確認。最も速く、費用も最も低い |
| Standard | 深さ・速さ・費用のバランスを取る。既定の段階 |
| Deep | 最も丁寧な確認。時間も費用も最もかかる |
Ownerは組織の既定を1つ決め、リポジトリごとに別の段階を付けられます。開発チームのブログは、見逃した1つのバグの代償がレビューの追加の時間より大きい所ではDeepに価値があると書いています（開発チームのブログ）。
GitHubの組織をまるごと対象にする前に
GitHubの組織の行にReview runsを設定すると、Claude GitHub Appがアクセスできるリポジトリが後から増える分も含めて対象になり、ドキュメントは費用が大きく増えることがあると注意しています。条件は、つないだGitHubアカウントがその組織のOwnerであること、組織がgithub.comにあること、月の上限を設定していることの3つです。開発者が「@claude review」で頼んだレビューも、組織に請求されます。
この記事の内容を社内で使うなら
要点と手順をまとめた資料を無料で受け取れます。研修6,000名以上・支援100社以上の実績をもとに、自社の業務に当てはめる相談も30分から受け付けています。
何を指摘させるか｜REVIEW.mdとCLAUDE.mdの使い分け
指摘の中身は、リポジトリに置く2つのファイルで調整します（カスタマイズのドキュメント）。
| ファイル | 役割 | 読まれる範囲 |
|---|---|---|
| CLAUDE.md | Claude Codeがすべての作業で読むプロジェクトの指示。レビューでも読み、ルールに反する変更を指摘にする | リポジトリ直下と、変更したファイルの親のディレクトリにあるもの |
| REVIEW.md | レビューだけの指示。何を指摘し、どの重要度にし、何を飛ばすか | リポジトリ直下。サブディレクトリに置くと、その配下の変更に確認を足せる |
REVIEW.mdの雛形（ドキュメントの例を日本語にしたもの）
公式ドキュメントの例と、開発チームのブログの助言（失敗とは何かを書く・Nitに上限・飛ばすパス・根拠にファイルと行・件数から始まる要約）をもとに日本語にした雛形です。REVIEW.mdは自由形式のMarkdownなので、自社に合わせて書き換えてください。日本語で書いた指示の効き方は、試験導入のリポジトリで確かめてから広げるのが安全です。
# レビューの指示
## このリポジトリで Important とするもの
動作を壊すもの、データを漏らすもの、切り戻しを妨げるものだけを Important にする。
例：誤ったロジック、テナントで絞り込んでいないデータベースのクエリ、
ログやエラーメッセージに含まれる個人情報、後方互換のないマイグレーション。
書式・命名・リファクタリングの提案は、多くても Nit とする。
## Nit の上限
1回のレビューで報告する Nit は最大5件まで。
## 報告しないもの
- CI がすでに確かめているもの（リント、書式、型エラー）
- src/gen/ 配下の生成ファイルと *.lock ファイル
- 意図して本番のルールから外しているテスト専用のコード
## 必ず確かめるもの
- 新しい API のルートに結合テストがある
- ログにメールアドレス、ユーザー ID、リクエストの本文を出していない
- データベースのクエリが呼び出し元のテナントで絞り込まれている
## 根拠
挙動についての指摘には、名前からの推測ではなく、ソースの file:line を示す。
## 要約
要約は指摘の件数から始め、直すものが無いときはそう明記する。REVIEW.mdはどのブランチから読まれるか
REVIEW.mdはPRのbaseのブランチか既定のブランチから読まれ、PR自体の変更からは読まれません。書き換えたら先にマージします。重要度を下げる・パスを除外する・Nitに上限を付けるという指示を守らせるには、既定のブランチを保護（ブランチ保護ルールかルールセット）してそこに置きます。保護の設定を確かめられないと、REVIEW.mdは読まれません。また手元の/code-reviewはCLAUDE.mdを読みますが、REVIEW.mdは読みません。両方で効かせたい指示はCLAUDE.mdに書きます。CLAUDE.mdの書き方はClaude Code Best Practices完全ガイドにまとめています。
Claude Code開発チームのレビューの進め方｜公開された数字と7つの層
正式提供と同じ2026年10月15日、Claude Codeの開発チームはブログ「How the Claude Code team does code review」で、自分たちのレビューの進め方を公開しました（開発チームのブログ）。Claude Codeのコードの約9割をClaudeが書いている中で、レビューをなくしたのではなく、読む作業の多くを機械に移し、人の時間と注意を危険度の高い判断に回したと書いています。
ブログに出てくる数字
| 数字 | 中身 |
|---|---|
| 2倍超・40%超の減少 | 6月から9月に、Claude Codeのコードベースにマージされたプルリクエストは2倍超に増え、差し戻し（revert）が必要になった割合は40%超減った |
| 約2,500→30,000超 | Anthropicのモノレポに1日に入る変更は、5月の約2,500から9月の30,000超に増えた（Claude Codeはモノレポとは別のリポジトリ） |
| 16%→54% | 研究プレビューを始めたとき、実質的なレビューのコメントが付く社内のPRの割合が上がった |
| 65%→78% | レビューと修正の1往復で通る社内のPRの割合（収束の工夫の前と後） |
| 8.9%→1.5% | 5往復以上かかったPRの割合（同） |
| 2.08→1.32 | 通るまでの平均のレビュー回数（同） |
どれもAnthropicの社内の実測です。他社で同じ数字になるとは書かれていないので、自社での効き目は、差し戻しの率とレビュー待ちの時間を自社で測って確かめます。
変更が通る7つの層
- PRの前に確かめる：テストやビルドなど、Claudeが実行して確かめられるものを渡し、結果を示させる。新しい文脈のサブエージェントにも差分を読ませる
- 必須のCI：リント・型チェック・テスト・ビルド。PRのテンプレートで「どうテストしたか」「どう戻すか」を聞く
- AIがレビュー：すべてのPRに、人が見る前にClaudeのレビューが入る。指摘は別のエージェントたちが本物かを票決してから載せる
- セキュリティレビュー：自動のセキュリティレビューも入る。社内のリポジトリでは、指摘が未解決の間はマージできない
- 危険度で人が承認：変更の危険度で、人の承認の数を変える（下の表）
- マージキューとフラグ：マージキューで全チェックをやり直し、新しい挙動はまず社員向けにフラグの裏で出して、段階的にリリースする
- すぐ戻せる：フラグはデプロイなしで切れ、障害の振り返りでは「どの層で捕まえるべきだったか」を問う
4つ目の「マージできない」は社内のリポジトリの運用です。製品のCode Review自体は差し止めをしないので、同じことをするにはブランチ保護で会話の解決を必須にするなど、リポジトリ側で設定します（PRでのレビューのドキュメント）。
危険度で人の承認を変える
| 危険度 | 例 | 人の承認 |
|---|---|---|
| 低 | ドキュメント、文言、社内だけの機能、フラグの裏の追加だけの変更 | 信頼済みリストの作者なら、自動のレビューとセキュリティのチェックが通れば不要（リスト外の作者は人の承認が必要） |
| 中 | 通常のプロダクトの変更、キャッシュ・自動アップデーター・システムプロンプトなどの変更 | 1人 |
| 高 | 最も危険度の高いコードと、常に2人が要る一部のパス | 2人 |
危険度は書いた人ではなく変更の中身で決め、エージェントの承認は人の承認に数えません。エージェントに書かせたPRでは、指示した人が必須のレビュー担当の1人になります。承認は特定のコミットにだけ有効で、エージェントのpushなど確かめきれない新しいコミットが入れば承認し直します。
レビューを「収束」させる工夫
エージェントが書いてエージェントがレビューすると、終わらなくなることがあります。ブログには、CLIのPRがひと晩で50往復以上のレビューと修正を繰り返した例が出てきます。そこでチームは、3往復の後は書き手にやり方の見直しを求める上限、数回目からは新しい差分だけの再レビュー、同じ種類のバグをまとめて指摘、同じ指摘を繰り返さない、の4つを入れました。上の表の65%→78%などは、この前と後の数字です。
自社で使う前に決めること｜7項目のチェック表
ドキュメントと、ブログの「How you can adopt this process」（自社でまねる方法）をもとに、有効にする前に決めておきたいことを7つに絞りました。
| 決めること | 決め方の目安 |
|---|---|
| 1. 対象のリポジトリ | まず1つか、代表的な数個。REVIEW.mdを数週間整えてから広げる（ブログ・料金のドキュメント） |
| 2. 段階 | 既定はStandard。日常的なコードはQuick、見逃しの代償が大きい所はDeepを検討（告知・ブログ） |
| 3. いつ走るか | 試験導入はOnce after PR creationかManual。After every pushはpushの回数を見てから（料金のドキュメント） |
| 4. 月の上限 | Claude Code Reviewの月の上限と、組織全体のusage creditsの上限を先に設定（料金のドキュメント） |
| 5. REVIEW.mdの担当 | コードのオーナーが書き、繰り返し出る指摘を移す。既定のブランチを保護する（ブログ・カスタマイズのドキュメント） |
| 6. 人が必ず見る変更の線引き | CODEOWNERSとブランチ保護で、認証・課金・CIとリリースのワークフロー・インストーラーは必ず人が見る。ボットの承認を必須の人の承認の代わりにしない（ブログ） |
| 7. ZDRなどを使っていないか | ZDR・HIPAA構成・CMEKの組織は使えない。情報システム部門で契約と設定を確かめる（Code Reviewのドキュメント） |
ブログの一覧にはほかにも、PRのテンプレートに「Testing」「Risk」「How to revert」を足す、などが並んでいます。全社への広げ方の段取りはClaude Code企業導入5ステップも参考になります。
【要注意】Code Reviewのよくある読み違い4つ
読み違い1：AIが承認するので、人のレビューは要らなくなる
❌ Code Reviewを入れれば、PRの承認をAIに任せられる
⭕ Code Reviewは承認も差し止めもせず、マージの判断はチームに残ります。開発チームのブログも、ボットの承認を必須の人の承認の代わりにしないと書いています。人がレビューに使う時間を減らす道具であって、人の判断をなくす道具ではありません。
読み違い2：1回いくらの定額で使える
❌ 3月の告知の平均額が、今の1回の料金だ
⭕ 1回あたりの定額はありません。3月の告知の平均額は研究プレビューの時点の目安です。今は段階も選べるので、試験導入で自社の平均費用を測ります。
読み違い3：既定のままならPRごとに1回だけ走る
❌ リポジトリを追加すれば、PRごとに1回だけレビューが走る
⭕ 「Add a repository」で追加した直後のリポジトリはAfter every push（組織ごと対象にした時は組織の設定）で、pushのたびにレビューが走り、その回数だけ費用が増えます。1回で十分ならOnce after PR creationに変えます。
読み違い4：指摘ゼロならバグも脆弱性もない
❌ 「Code review found no issues」と出たので安全
⭕ ドキュメントは、指摘が無いことは誤りが無い・安全であることを意味しないと書いています。コードを動かして確かめるわけでもないので、CI・テスト・セキュリティのチェックは残します。
Uravationならこう判断する｜まず1リポジトリで平均費用を測る
判断1：1つのリポジトリ・Once after PR creation・Standardで始める
PRの量が中くらいのリポジトリを1つ選び、Review runsをOnce after PR creation、段階をStandardにします。月の上限を先に設定してから有効にし、数週間たったらAverage cost列の平均に月のPR数を掛けて、全社に広げたときの見込みを出します。After every pushにするかは、その後で決めれば十分です。
判断2：REVIEW.mdは短く始め、繰り返す指摘だけを足す
最初から長いルールを書くより、出てきた指摘のうち「毎回同じ」「うちでは問題にならない」ものを移していくほうが、Nitの多さに疲れずに済みます。ブログも、よいREVIEW.mdは短いと書いています。担当はそのコードのオーナーにします。
判断3：認証・課金・リリースは必ず人が見る形を先に作る
Code Reviewの指摘は、人が判断するための材料です。壊れると影響が大きい所はCODEOWNERSとブランチ保護で必ず人が承認する形にしてから、AIの指摘を使います。Enterpriseでクレジットの対象になる組織は、この設定とリポジトリの選定を終えてから「Claim」を押すと、30日を無駄にしません。
よくある質問
Claude Code Code Reviewは無料で使えますか？
いいえ。TeamとEnterpriseの組織の機能で、使った分がusage creditsから組織に請求されます。プランに含まれる利用枠とは別です。対象のEnterpriseの組織には、2027年1月15日まで申請できる1万ドル以上のクレジットがあります（条件あり）。
ProやMaxのプランでも使えますか？
Code Reviewは使えません。ProとMaxでは、手元の/code-reviewと、研究プレビューのUltrareview（1アカウント1回限りの無料の3回、その後はusage credits）を使えます。
GitLabのリポジトリでも使えますか？
Code Reviewの対象はGitHubのリポジトリです。GitLabでは、/code-reviewに–commentを付けてマージリクエストに指摘を書き込む方法（glabというCLIが必要）か、GitLab CI/CDにClaudeを組み込む方法がドキュメントに載っています。
指摘が残っているPRのマージを止められますか？
Code Review自体は止めません。止めたい場合は、GitHubのブランチ保護で会話の解決を必須にする方法があります。自社のCIでチェックランの詳細にある重要度ごとの件数を読み、Importantが1件以上なら失敗にする手順もドキュメントにあります。
レビュー中にコードを書き換えたり実行したりしませんか？
しません。リポジトリへのアクセスは読み取りだけで、コミットをpushせず、コードをビルド・実行もしません。ただしClaude GitHub Appの権限はレビューで使う範囲より広いので、導入前に権限の一覧を確かめてください。
Enterpriseのクレジットはいつまでに申請すればよいですか？
2027年1月15日23時59分（UTC）、日本時間では1月16日8時59分までに、OwnerかPrimary Ownerが「Claim」を押します。申請した時点から30日が過ぎるか使い切ると、通常の請求に戻ります。Teamのプランは対象外です。
まとめ
Claude Code Code Reviewは2026年10月15日に正式提供され、TeamとEnterpriseの組織がGitHubのリポジトリで使えるようになりました。PRごとに複数のエージェントが読み、検証した指摘だけを行にコメントしますが、承認も差し止めもしません。費用は1回の定額ではなくusage creditsで組織に請求され、1つずつ追加したリポジトリは最初pushのたびに走ります。まずは1つのリポジトリで月の上限を決めて平均費用を測り、REVIEW.mdと、人が必ず見る変更の線引きを整えてから広げてください。
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・書籍シリーズ累計66,000部）、『AI推進担当になったら読む本』（大和書房）。
SBクリエイティブ「ビジネス＋IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。
今日から始める3つのアクション
- 今日やること：自社のClaudeの組織がTeamかEnterpriseか、ZDR・HIPAA構成・CMEKを使っていないか、コードがGitHubにあるかを確かめる
- 今週中：試験導入のリポジトリを1つ選び、Claude Code Reviewの月の上限を設定してから、Once after PR creationとStandardで有効にする
- 今月中：Average cost列の平均から月の費用を試算し、REVIEW.mdの担当と、CODEOWNERSとブランチ保護で人が必ず見る変更を決める
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
参考・出典
- Code Review is now generally available — Anthropic（claude.com）、2026年10月15日（参照日：2026-10-17）
- How the Claude Code team does code review — claude.dev ブログ（Addy Osmani、Morgan Westlee Lunt、Qing Wang）、2026年10月15日（参照日：2026-10-17）
- Bringing Code Review to Claude Code — Anthropic（claude.com）、2026年3月9日（参照日：2026-10-17）
- Code Review — Claude Code Docs（参照日：2026-10-17）
- Set up Code Review — Claude Code Docs（参照日：2026-10-17）
- Code Review costs and usage — Claude Code Docs（参照日：2026-10-17）
- Customize Code Review — Claude Code Docs（参照日：2026-10-17）
- Read and request reviews on a pull request — Claude Code Docs（参照日：2026-10-17）
- Troubleshoot Code Review — Claude Code Docs（参照日：2026-10-17）
- Review locally with /code-review — Claude Code Docs（参照日：2026-10-17）
- Find bugs with ultrareview — Claude Code Docs（参照日：2026-10-17）
- Free Code Review promotional credits for Claude Enterprise — Claudeヘルプセンター（参照日：2026-10-17）
- Manage usage credits for Team and seat-based Enterprise plans — Claudeヘルプセンター（参照日：2026-10-17）
この記事の内容を社内展開する方へ: Claude Code × ビジネス活用 実践ガイド（無料・PDF 30ページ＋Excel） をダウンロードできます。
