AIがコードを書く速度は上がっても、変更内容を確かめる人の時間は増えません。小さな開発チームでは、実装よりレビュー待ちが長くなることもあります。Anthropicは2026年10月15日付で、GitHubのプルリクエストを調べる Code Reviewの正式提供を発表しました。公式発表
プルリクエスト（PR）は、コードの変更案を確認してから本流へ取り込むための単位です。今回のCode Reviewは、その変更と周辺のコードをAIが読み、不具合の候補をGitHub上へコメントするサービス。この記事では、レビューを頼む相手が足りないチームに向け、料金・設定・小さく試す手順を整理します。
個人向けのClaude Codeで使う /code-review コマンドとは別の仕組みです。Code Reviewはプランの通常利用枠とは別に、組織のusage creditsから従量課金されます。レビュー結果はコードの安全性を保証しません。本記事は2026年10月16日時点の公式仕様の解説で、実サービスの速度・検出率・請求額は未実測です。
今回の更新：正式提供と、リポジトリごとのレビューの深さ
公式発表では、研究プレビューを終え、TeamとEnterpriseへ一般提供すると説明しています。発表日と一般提供日は10月15日と確認できましたが、正確な時刻とタイムゾーンは不明です。すべての利用者に無料で開放された、という意味ではありません。
新たな案内の中心は、レビューの高速化と、Quick・Standard・Deepという深さの選択です。所要時間が約20分から6〜10分になり、多くのレビューが約3倍速くなったという数字は提供元の報告です。自分のPRで同じ時間になるとは限らず、本記事では比較実測していません。正式提供の説明
| 項目 | 確認できた仕様 | 導入時の判断 |
|---|---|---|
| Quick | 軽い確認。3段階で最速・低コスト | 変更の影響が限定的なリポジトリから検討 |
| Standard | 深さ・速さ・費用のバランス。既定値 | 最初の比較の基準にする |
| Deep | 最も詳しく調べ、時間と費用も最も大きい | 重要な業務ロジックを扱うリポジトリで検討 |
表の導入判断は編集部の提案です。「Deepなら必ず見つかる」とは言えません。組織のOwnerが既定の深さを決め、リポジトリごとに上書きできます。モデル自体はサービス側が選び、管理画面でモデル名を指定する機能はありません。レビューの深さ
できることと、人が引き続き担当すること
複数のエージェントが差分と周辺コードを調べ、候補を検証し、重複をまとめて重要度を付けます。指摘は該当行へのコメント、要約、GitHubのチェックとして届きます。基本の対象は動作を壊す問題であり、書き方の好みやテストの不足を網羅するサービスではありません。処理の流れ
例えば、返金処理で同じ要求を二度受けたときの扱い、顧客ごとのデータ取得範囲、空欄や境界値での分岐などは、確認してほしい観点になります。これは業務上の利用例であり、今回サービスが実際に発見した結果ではありません。
| 役割 | Code Review | 開発チーム |
|---|---|---|
| コードを読む | 差分と周辺から問題を探す | 業務の前提と期待する動作を示す |
| 動作を確かめる | コードをビルド・実行する検証は行わない | テスト、型検査、必要な画面確認を行う |
| 指摘を扱う | 候補をコメントする | 再現条件を確かめ、修正するか判断する |
| マージする | PRを承認・ブロックしない | 承認者と必須チェックで可否を決める |
「Code review found no issues」は、不具合がない証明ではありません。また、Claude Code Reviewのチェックは失敗という結論にならないため、緑色の表示だけを承認条件にしないことが重要です。既存のテストや人の承認を残して併用します。公式の制限とチェックの説明
利用条件：Mac専用ではなく、GitHubにつなぐクラウドの仕組み
レビューはAnthropicの管理環境で実行されます。手元のMacに大きなモデルを載せる必要はありません。導入操作はブラウザーで行い、リポジトリへワークフローのファイルを追加する手順も不要です。自社のローカル環境だけでコードを処理する製品ではありません。セットアップ
対象はTeam・Enterpriseの組織とGitHubのリポジトリです。GitHub Enterprise Serverなどにも対応があります。一方、Zero Data Retention、HIPAA構成、顧客管理の暗号鍵（CMEK）を使う組織では利用できないと案内されています。既存のClaude契約だけで対応可否を判断せず、組織の条件を確認してください。利用条件
Claude組織のOwner、GitHub組織のOwnerによるアプリの導入・連携、対象リポジトリへの書き込み権限が必要です。レビュー処理自体はコードを読み取るだけでコミットを追加しませんが、GitHub Appが求める権限には他のClaude機能と共通の、より広い権限が含まれます。対象を選択してから接続します。必要な権限
日本語のコードコメントや業務条件を使う場合も、指摘の意味と根拠を人が確かめます。確認した資料からは日本語レビュー品質の保証や言語別の精度は判断できません。日本語で指示を書けば検出率が保たれる、と本記事では断定しません。
料金で先に見るのは、単価より「何回走るか」
現行の料金資料は、一律の1回料金を定めていません。消費トークンに基づいて組織へ請求され、レビューの深さ、変更量、周辺コードの複雑さ、確認する問題候補によって費用が変わります。過去の記事にある平均金額を、正式提供後の固定料金として予算へ入れないようにします。
| Review runsの設定 | 動くタイミング | 試行時の考え方 |
|---|---|---|
| Once after PR creation | PRの作成・再オープン・レビュー可能状態への変更 | 通常は初回を中心に確認。再開などでも増える |
| After every push | PRブランチを更新するたび | 修正後も追えるが、更新回数に応じて費用が増える |
| Manual (@claude review) | 権限のある人がコメントで依頼 | 対象を選んだ小規模な試行に使いやすい |
管理画面から個別に追加したリポジトリは、更新のたびにレビューする設定で始まります。初回の検証前にReview runsを確認します。組織全体を対象にしている場合は組織側の設定を引き継ぐ例外があります。
月額は「実測した平均レビュー費用 × 月間レビュー回数」で見積もります。例えば平均が仮に8米ドル、月50PRで各1回なら400米ドル。各PRを平均4回レビューすれば1,600米ドルです。8米ドルは計算方法を示す架空の値で、公式単価でも実測でもありません。 再レビューや対象外になったPRも記録して、実際の回数を使います。
管理画面のUsageでCode Reviewの月間支出上限を設定できます。サービス上限・組織全体の上限・クレジット残高によりレビューがスキップされ、残り予算が1回の見込み費用より小さい場合も実行されません。指摘が来ないときは「問題なし」ではなく「実行されていない」可能性を確認します。支出上限
最初の導入は、1リポジトリ・手動・少数のPRで測る
- 1Ownerが対象プラン、データの扱い、GitHub Appの権限を確認し、試すリポジトリを一つ選ぶ。
- 2Admin settings > Claude CodeのCode reviewを開く。GitHubを接続し、必要なアプリ導入と対象の選択を行い、Finishで有効化する。
- 3Review runsをManualにし、深さはStandardを比較の出発点にする。Usageで承認済みの試行予算に支出上限を設定する。
- 4権限のある担当者がテスト用PRに @claude review とコメントし、Claude Code Reviewのチェックが現れ、完了したことを確認する。
- 5指摘を既存テストや手作業で再現し、採用・誤指摘・判断保留を記録する。指摘がなかったPRも人が確認する。
- 6数件を終えたら費用、待ち時間、人が読む時間、修正につながった件数を比較し、自動実行に広げるか決める。
この手順は導入案です。本記事の作成では新しい契約、アプリへの権限追加、有料レビューの実行は行っていません。自動レビューはドラフトとフォークから作成されたPRをスキップします。コメントでの依頼にはリポジトリへの書き込み権限が必要です。実行条件とコメント
一度だけ依頼するなら @claude review を使います。@claude review always は、対象PRを以後の更新でもレビューする設定にできる別の依頼です。試すだけのつもりで継続実行を始めないよう区別してください。
試行の記録表CSVをダウンロードできます。空欄の表であり、製品の実測データは含みません。費用は管理画面のAverage costや分析画面を確認し、請求額の確定には請求書を使います。分析画面の推定額には割引・クレジットなどが反映されない場合があります。
REVIEW.mdに、実際に困る不具合を短く書く
プロジェクト全体のルールはCLAUDE.md、PRレビュー専用のルールはREVIEW.mdに書けます。以下は架空の業務アプリ向けの日本語指示例です。実際のフォルダーや業務条件に合わせて変更し、指示が期待どおり反映されたかを試行で確認します。カスタマイズの公式資料
# レビューで確認する業務条件
- 顧客別のデータ取得が、呼び出した利用者の所属顧客に限定されているか。- 同じ返金要求を再送したときに、二重処理にならないか。- 金額がゼロ、数量が空欄の場合の動作が既存仕様と一致するか。- 指摘には、該当ファイルと行、発生条件、起こる問題を添える。- 前提を確認できない場合は、断定せず不足する情報を示す。重要なのは置く場所と反映の順序です。サービスはPR自身が変更したREVIEW.mdを使わず、条件に応じてベースブランチまたはデフォルトブランチのものを読みます。指示の変更を先にマージし、デフォルトブランチを保護します。重要度を下げる、対象を除外する、細かな指摘の件数を制限するといった指示には追加条件があるため、ブランチ保護と読み取り元の表も確認します。
手元のClaude Codeセッションで使う /code-review は、CLAUDE.mdを読みますがREVIEW.mdは読みません。同じ名前のレビュー機能でも、PRサービス用に書いた指示がローカルのコマンドにも効くとは限りません。両方で必要な前提はCLAUDE.mdへ置き、PRだけの観点を分けると管理しやすくなります。
導入の価値は、コメント数ではなく判断が進むかで測る
見るべきなのは「何件指摘したか」だけではありません。少ないコメントでも重大な見落としを一つ減らせれば価値があります。一方、根拠を確かめる時間が増えるだけなら設定を見直す必要があります。最初は手動で費用と有用性を測り、重要度の基準を整え、その後に自動化の範囲を広げる。この順序なら、小さな開発チームでも効果を判断しやすくなります。
人の確認との役割分担はClaude任せと人間のレビューの境界、静的な検査で拾えることと限界はDeslopのローカル検証も参考になります。