Claude Code Reviewとは|プルリクエストを自動でレビューするサービス
Claude Code Review とは、プルリクエスト(PR。コードの変更をチームに確認してもらうための依頼)を Claude が読み、バグの候補を確かめたうえで行単位のコメントとして返すサービスです。
レビューは Anthropic の基盤で動くため、リポジトリにワークフローの設定ファイルを置く必要はありません。組織の管理者が一度有効にすると、対象リポジトリで新しく開かれたプルリクエストに自動でレビューが付きます。
関連記事:Claude Codeとは?できること・料金・使い方と社内導入の判断軸
2026年10月にリサーチプレビューから一般提供へ
Anthropic は2026年10月15日(米国時間)、Code Review のリサーチプレビューを終え、Claude の Team と Enterprise で一般提供を始めたと公式発表で明らかにしました。プレビュー期間の利用者からは「静かで、変更の大きさに見合っていて、速いレビュー」を求める声が多く、一般提供ではこの 3 点が改められています。
- 速さ:多くのレビューが約20分から6〜10分で終わるようになり、約3倍速くなりました
- 指摘の質:直すべきバグをより多く拾い、問題・起きる条件・直し方を数文で伝える形になりました
- 深さの調整:管理者がリポジトリごとに Quick・Standard・Deep のレビューレベルを選べるようになりました
日常的なコードは軽く、止まると困るコードは深く見る、という使い分けができるようになったのが一般提供での大きな変化です。
レビューが返すもの、返さないもの
1 回のレビューでプルリクエストに残るのは、該当行へのインラインコメント、レビュー全体のサマリー、そして「Claude Code Review」という名前の check run(GitHub 上でテストなどの結果を表示する欄)の 3 つです。問題が見つからなかったときは、check run の題名が「Code review found no issues」になり、同じ短い報告がプルリクエストにも投稿されます。
一方で、レビューがプルリクエストを承認したり、マージを止めたりすることはありません。check run も失敗にはならず、マージするかどうかの判断は常にチームに残ります。Claude はあくまで指摘を出す役で、合否を決める役ではないと捉えておくと運用を設計しやすくなります。
使えるプランと対象外になる組織
Code Review を使えるのは Team と Enterprise のプランで、Pro や Max の個人プランは対象外です。コードの置き場所は GitHub に限られ、自社で運用する GitHub Enterprise Server やデータ所在地を指定した GitHub Enterprise Cloud にも対応しています。
ただし、データを保持しない設定(Zero Data Retention)を有効にしている組織、HIPAA 向けの構成を適用している組織、顧客管理の暗号鍵(CMEK)を使う組織では、現時点で利用できません。開発者が Amazon Bedrock や Google Cloud 経由で Claude Code を使っている場合でも、Code Review には Team か Enterprise の Claude 組織が別に必要です。
レビュー工程にAIを使う人はまだ少ない
GiftX のビジネス職生成AI活用実態調査(2026年版)では、AI を使うエンジニアの用途として「コード生成」を挙げた人が30%だった一方、「コードレビュー」は18%で、11 の用途の中で最も少ない結果でした(複数回答)。書く工程には AI が広がっているのに、確かめる工程はまだ人の手に残っている状況がうかがえます。Code Review は、この確かめる側の負担を減らすための選択肢です。
詳細な調査データは「ビジネス職生成AI活用実態調査(2026年版)」にてご覧ください。
Claude Code Reviewの仕組み|レビューの流れと指摘の重要度
Code Review は、1 つのモデルが差分を上から読むのではなく、複数のエージェント(指示を受けて自律的に作業を進める AI)が役割を分けて進めます。既定では本番環境を壊すバグなど正しさに関わる問題に絞って調べ、書き方の好みやテストの不足は対象にしません。
見つける・確かめる・並べる・投稿するの流れ
公式ドキュメントでは、1 回のレビューを次の 4 段階で説明しています。
| 段階 | やること | 読者にとっての意味 |
|---|---|---|
| 見つける | 複数のエージェントが差分と周辺のコードを並行して調べる | 変更行だけでなく、呼び出し元などの文脈も見る |
| 確かめる | 検証ステップで、候補の指摘をコードと照らし合わせて誤検出を除く | 思い込みの指摘が届きにくくなる |
| 並べる | 残った指摘の重複を除き、深刻な順に並べる | 優先して直す箇所が先頭に来る |
| 投稿する | インラインコメント、サマリー、check run をプルリクエストに残す | GitHub の画面だけで結果を確認できる |
AI のレビューで現場が困りやすいのは、的外れな指摘が多くて読むのが面倒になることです。Code Review は、指摘を出す前に検証ステップを挟むことで、この負担を抑える設計になっています。どのモデルを使うかは Code Review 側が決め、管理画面でモデルを選ぶことはできません。
指摘に付く3段階の重要度
各指摘には、次の 3 つのうちいずれかの印が付きます。
| 印 | 重要度 | 意味 |
|---|---|---|
| 🔴 | Important | マージ前に直すべきバグ |
| 🟡 | Nit | 直したほうがよいが、マージを止めるほどではない小さな問題 |
| 🟣 | Pre-existing | この変更で生まれたものではなく、もともとコードにあったバグ |
Pre-existing が別に表示されるので、今回の変更で直すべきものと、既存コードに残る課題を切り分けて扱えます。指摘には「Why this was flagged」という折りたたみ欄が付くことがあり、開くとなぜ指摘したのか、どう確かめたのかを読めます。
コードは読むだけで、実行はしない
レビューはリポジトリを読み取り専用で扱い、コミットを押し込むこともありません。コードをビルドしたり実行したりもせず、差分と周辺コードを読むことだけで判断します。そのため、動かしてみないと分からない不具合や性能の問題は、従来のテストや CI(コードを変更するたびに自動でテストを回す仕組み)で拾う必要があります。
公式ドキュメントも、指摘が無いことはコードに誤りや脆弱性が無いことを意味しないと明記しています。Code Review は人のレビューとテストに重ねる 1 層として扱うのが前提です。
Claude Code Reviewの料金|定額はなく利用量に応じた従量課金
Code Review には 1 回いくらという定額の料金がありません。レビューで使ったトークン量に応じて、プランに含まれる利用枠とは別の利用クレジットから組織に課金されます。費用はプルリクエストを開いた開発者ではなく組織に付き、Amazon Bedrock などを使っている組織でも Anthropic の請求に計上されます(2026年10月時点、出典: claude.com)。
AIエージェントを「どう作り、どう育てるか」を、GiftX記事制作エージェントの実物で解説。
1回あたりの費用を左右する要素
- レビューレベル:Quick が最も安く、Deep が最も高くなります
- 変更の大きさ:差分が大きいほど読む量が増えます
- 周辺コードの複雑さ:呼び出し関係が込み入っているほど調べる範囲が広がります
- 検証が要る候補の数:確かめる指摘候補が多いほど費用がかさみます
月の総額は、この 1 回あたりの費用にレビュー回数を掛けたものです。回数はリポジトリごとの実行タイミングの設定で決まり、push のたびにレビューする設定では push の回数だけ費用が増えます。
月額の見積もり方と上限の掛け方
公式ドキュメントは、全社に広げる前に少数のリポジトリで試して費用をつかむ手順を勧めています。
- 試験運用の間の月額上限を設定する
- 代表的なリポジトリを数本選び、実行タイミングを「PR 作成時に 1 回」か「手動」にして有効にする
- 何回かレビューが走ったら、管理画面の Repositories 表にある Average cost 列で 1 回あたりの平均費用を見る
- 平均費用に月のプルリクエスト数を掛ける。push ごとの設定なら、さらに 1 件あたりの平均 push 回数を掛ける
月額上限は claude.ai の利用設定画面で、組織全体に対して Code Review 用に設定できます。上限や利用クレジットの残高が尽きると、レビューは走らずにスキップされ、プルリクエストには理由を伝えるコメントが付きます。
Claude Code Reviewの導入方法|管理画面での設定から試験運用まで
Code Review を有効にするのは、Claude 組織の Owner(組織の最上位の管理権限を持つ人)です。開発者側で設定ファイルを用意する必要はなく、作業はほぼ claude.ai の管理画面と GitHub の画面で完結します。
始める前にそろえておく権限
| 必要な権限 | 何に使うか |
|---|---|
| Claude 組織の Owner | 管理画面でのすべての操作 |
| GitHub 組織のオーナー | Claude GitHub App のインストールと Claude 組織へのひも付け |
| 対象リポジトリへの書き込み権限 | レビュー対象としてリポジトリを追加する |
3 つを 1 人で持っていない場合は、GitHub 側のオーナーに先に Claude GitHub App を入れてもらうと、当日の作業が止まりません。App が求める権限は、Code Review が実際に使う範囲より広く、GitHub Actions など他の Claude 機能と共通の権限一式になっている点も事前に共有しておくと安心です。
有効化の手順
- 管理画面の Admin settings > Claude Code にある Code review 欄で、Allow code review をオンにする
- Connect GitHub の画面が出たら GitHub アカウントを接続する
- 対象リポジトリが一覧に出ない場合は、Install GitHub App から Claude GitHub App を入れ、対象リポジトリを選ぶ
- レビューしたいリポジトリを選んで Continue を押す
- 「Code review is set up」の画面で Finish を押す
- 下書きではないテスト用のプルリクエストを開き、数分以内に「Claude Code Review」の check run が出るか確かめる
手順 5 で Finish 以外の方法で画面を閉じると、リポジトリは追加されたまま Allow code review がオフに残ります。テストで check run が出ないときは、この状態になっていないかを先に確認します。
レビューレベルと実行タイミングを決める
レビューレベルは組織全体の既定値を 1 つ決め、必要なリポジトリだけ個別に変えられます。
| レベル | 特徴 | 向いているリポジトリ |
|---|---|---|
| Quick | 軽い確認。最も速く、費用も最も低い | 変更が定型的なリポジトリ |
| Standard | 深さ・速さ・費用のバランス型。既定値 | 多くの一般的なリポジトリ |
| Deep | 最も丁寧な確認。時間と費用が最もかかる | 決済や認証など、止まると影響が大きいコード |
実行タイミング(Review runs)は、「Once after PR creation(PR 作成時に 1 回)」「After every push(push のたび)」「Manual(コメントで依頼したときだけ)」の 3 つから選びます。新しく追加したリポジトリは After every push から始まるため、費用を抑えたい場合は追加したあとに設定を変えておきます。
REVIEW.mdで指摘の基準を調整する
何を指摘してほしいかは、リポジトリに置く 2 つのファイルで調整します。CLAUDE.md はプロジェクト全体のルールで、違反した変更が指摘されます。REVIEW.md はレビュー専用の指示で、Important と見なす範囲、Nit の上限数、指摘しないパス、毎回確かめてほしい項目などを書けます。
REVIEW.md はプルリクエストの変更からではなく、ベースブランチか既定ブランチから読まれます。Nit 扱いに下げる、パスを除外する、Nit の数を絞るといった指示を確実に効かせるには、既定ブランチを保護したうえで REVIEW.md をマージしておく必要があります。
関連記事:CLAUDE.mdとは?4つの置き場所と読み込み順、守られる書き方と分割の判断基準
Claude Code Reviewの使い方|@claude reviewと指摘への対応
設定が済めば、開発者は普段どおりプルリクエストを開くだけでレビューを受け取れます。追加でレビューを頼みたいときは、プルリクエストにコメントを書きます。
コメントでレビューを依頼する
| コメント | 動き |
|---|---|
| `@claude review` | その場で 1 回だけレビューする |
| `@claude review always` | レビューしたうえで、以後の push のたびにもレビューする |
| `@claude review once` | `@claude review` と同じく 1 回だけレビューする |
コメントは行へのコメントではなく、プルリクエスト全体への新しいコメントとして、行頭に書きます。依頼できるのはリポジトリへの書き込み権限を持つ人だけで、ボットのコメントではレビューは始まりません。下書きのプルリクエストとフォーク(他人のリポジトリを複製したもの)からのプルリクエストは自動レビューの対象外なので、必要な場合はこのコメントで依頼します。
指摘への対応とマージの判断
指摘に対応しないままでもマージはできますが、ブランチ保護で会話の解決を必須にしている場合は、各指摘のスレッドを解決してからマージします。直す場合はコードを修正して push すれば、次のレビューが修正済みと判断したスレッドを自動で解決します。
指摘に同意できないときは、コメントで理由を返しておくと、次のレビューがその返信を読んでスレッドを閉じるか、追加の返信をします。同じ種類の誤った指摘が繰り返される場合は、REVIEW.md にルールを足すほうが早く収まります。push 後のレビューは前回からの変更点に絞って小さな指摘を減らすため、プルリクエスト全体を改めて見てほしいときは @claude review で依頼し直します。
全国8,000人調査で、AIの活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
Claude Code Reviewと/code-review・GitHub Actionsの比較
Claude にコードを見てもらう方法は Code Review だけではありません。公式ドキュメントでは、次の選択肢を並べて比べています。
| 方法 | 始まるきっかけ | 動く場所 | 使える人 |
|---|---|---|---|
| Code Review | プルリクエストの作成・push、または `@claude review` | Anthropic の基盤 | Team・Enterprise で GitHub を使う組織 |
| `/code-review` コマンド | 自分のブランチで実行する | 自分の Claude Code セッション | 全プランの利用者 |
| Ultrareview | Claude Code から起動する | クラウドのサンドボックス | claude.ai アカウントでログインした利用者 |
| GitHub Actions・GitLab CI/CD | パイプラインのイベント | 自社の CI 実行環境 | API キーかクラウドの認証情報を持つ人 |
選び分けの目安は、組織の全員のプルリクエストに同じ基準のレビューをかけたいか、手元で自分の変更だけ確かめたいかです。前者なら Code Review、後者なら /code-review が合います。GitLab のリポジトリや、レビューの手順を自分で細かく組みたい場合は、自社の CI で Claude を動かす方法が候補になります。
なお、/code-review が読むのは CLAUDE.md だけで、REVIEW.md は Code Review だけが読みます。両方に効かせたい基準は CLAUDE.md に書くのが無難です。
関連記事:Claude CodeとGitHubの連携とは?4つの経路と選び方
自社事例|AIコーディングで開発が速くなった後に残るレビュー工程
GiftX では、自社サービスのフロントエンドとバックエンドの開発に Claude Code を導入し、コードの生成やリファクタ、テストの作成を AI と分担しています。その結果、機能追加 1 件あたりの平均工数は約2日から約半日になり、およそ75%削減できました。
実装が速くなると、同じ人数でもプルリクエストの本数が増え、次はレビューの待ち時間が開発の速さを決めるようになります。書く工程を AI に任せたチームほど、確かめる工程をどう回すかが次の課題になりやすいということです。
Code Review は、この確かめる工程の一部を AI に任せる手段です。ただし最終判断はチームに残るため、すべてを置き換えるのではなく、人が見る前に明らかなバグを拾っておく下ごしらえとして組み込むと、レビュー全体の時間を短くしやすくなります。
Claude Code Reviewの導入で陥りがちな3つの落とし穴
Code Review は管理画面から数分で有効にできる分、試しに広く入れてみたくなるサービスです。ただ、始め方を誤ると、費用が読めない、通知が多すぎて読まれない、といった理由で定着せずに止まってしまいます。
落とし穴1|全リポジトリをpushごとの設定のまま一度に有効にする
新しく追加したリポジトリは push のたびにレビューする設定から始まります。全リポジトリを一度に入れると、push の回数だけ費用が積み上がり、どのリポジトリにいくらかかっているのかを見極める前に請求が膨らみます。
落とし穴2|指摘の基準を決めずに始めて、Nitの通知に埋もれる
REVIEW.md で Important の範囲や Nit の上限を決めないまま始めると、チームが気にしない種類の指摘まで並びます。通知が多すぎると開発者は読まなくなり、本当に直すべき指摘も見落とされます。
落とし穴3|AIの指摘を人のレビューの代わりにしてしまう
Code Review は承認もブロックもせず、指摘が無いことは安全の証明になりません。AI のレビューが付いたことを理由に人の確認を省くと、実行しないと分からない不具合や設計上の問題がそのまま本番に出ます。
スモールスタートで1業務をAIエージェントに任せる
3 つに共通するのは、最初から全部を任せようとしている点です。まずはプルリクエストの一次レビューという 1 業務に絞り、代表的なリポジトリ数本で、PR 作成時に 1 回の設定から始めます。Average cost で費用をつかみ、REVIEW.md で指摘の基準を整えてから対象を広げるほうが、チームに定着させやすくなります。
GiftX では、こうしたスモールスタート前提のAIエージェント構築を 1 業務単位から伴走支援しています。詳細は AIエージェント構築支援サービス をご覧ください。
Claude Code Reviewに関するよくある質問
ProやMaxのプランでも使えますか
Code Review は Team と Enterprise のプラン向けで、Pro や Max では使えません。どのプランでも、Claude Code のセッションで /code-review を実行すれば、自分のブランチをレビューできます。
GitLabのリポジトリでも使えますか
Code Review の対象は GitHub のリポジトリだけです。GitLab を使っている場合は、GitLab CI/CD のパイプラインで Claude を動かす方法を検討します。
レビュー結果でマージを止められますか
check run は失敗にならないため、そのままではマージを止めません。止めたい場合は、check run の詳細に含まれる Important などの件数を自社の CI で読み取り、Important の件数が 1 以上なら失敗させる、といった仕組みを別に用意します。
Enterpriseの無料クレジットはどう申請しますか
対象の Enterprise 組織は、有効な Claude Code の席数に応じて1万〜5万ドル分の Code Review 用クレジットを受け取れます。申請の期限は2027年1月16日8時59分で、組織の Owner が管理画面の Code Review 欄から 1 回だけ申請でき、申請から30日間有効です(2026年10月時点、出典: claude.com)。申請した瞬間に30日が始まるため、先にリポジトリの設定を済ませておきます。
まとめ
Claude Code Review は、GitHub のプルリクエストを複数のエージェントが調べ、検証を経た指摘だけを 3 段階の印付きで返すサービスです。2026年10月に Team と Enterprise で一般提供が始まり、多くのレビューが6〜10分ほどで返るようになりました。
料金は定額ではなく利用量に応じた従量課金のため、少数のリポジトリで試して Average cost から月額を見積もり、上限を掛けてから広げる進め方が向いています。まずはプルリクエストの一次レビューという 1 業務から AI に任せ、REVIEW.md で基準を整えながら対象を広げていくことが、無理なく定着させる近道です。
AI活用の伴走支援をご検討の方へ
本記事で紹介したAIエージェントの活用に向けて、自社の業務でも具体的に進めたい・相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。
GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、PoC、本番運用、社内ナレッジ化まで伴走します。
AI活用にご関心のある方は、ぜひ一度ご相談ください。
▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら