マルチエージェントClaude CodeのCode Reviewとは？AIが変更を確かめる仕組み
この記事の要点
- Code Review は、GitHub の変更依頼（プルリクエスト）を複数のAIが手分けして読み、確かめた問題だけを行ごとにコメントする仕組み
- 10月19日の更新で Quick・Standard・Deep の3段階を選べるようになり、大事な所だけ深く確かめられる
- どのプランでも使える /code-review と、チーム向けの Code Review を、目的で使い分ける
AIに仕事を任せるほど、「AIが作ったものを、だれが確かめるのか」という問題が大きくなります。プログラムの変更なら、なおさらです。1件ずつ人が読んでいると、AIで速くなったはずの作業が、確認待ちで止まってしまいます。
Claude Code には、この確認の部分をAIに手伝わせる Code Review（コードレビュー） という仕組みがあります。2026年10月19日の更新（2.1.304）では、確かめる深さを3段階から選べるようになりました。この記事では、公式ドキュメント（2026年10月20日確認）にもとづいて、仕組み・段階の選び方・費用・使い分けを順番に整理します。
結論：確かめる係を「AIのチーム」にして、最後の判断は人が持つ
Code Review の考え方はシンプルです。見つける係・確かめる係・並べる係をAIに分け、合格か不合格かの判断は人に残す。公式ドキュメントでも、レビューが変更依頼を承認したり止めたりすることはなく、取り込むかどうかはチームが決める、と書かれています。
つまり、人の仕事がなくなるわけではありません。人は「全部を読む」のをやめて、「AIが確かめて残した指摘を読んで決める」側に回ります。
Code Review の仕組み（4つの段階）
公式ドキュメントでは、1回のレビューが次の4段階で進むと説明されています。
- 見つける：複数のエージェントが、変更された部分とその周りのコードを同時に読む
- 確かめる：見つかった候補を、もう一度コードと照らして、思い違い（誤検知）を落とす
- 並べる：残った指摘の重複をまとめ、深刻な順に並べる
- 知らせる：該当する行にコメントを付け、まとめと確認結果を変更依頼に残す
ポイントは2つ目の「確かめる」です。AIに確認させると、細かすぎる指摘や勘違いが大量に出がちです。Code Review は、指摘をそのまま出さず、いったん検証してから残すので、人が読む量を減らせます。初期設定では、見た目の好みではなく、本番で壊れるような不具合（正しさ）に絞って 確かめます。
また、レビューの中ではリポジトリを読むだけで、変更を書き込んだりはしません。コードを動かさず、読むことで確かめる仕組みです。
Quick・Standard・Deep の選び方
10月19日の更新で、レビューの深さを選べるようになりました。深いほど時間と費用がかかります。
| 段階 | 中身 | 向いている場所 |
|---|---|---|
| Quick | 軽く確かめる。いちばん速く、費用も最小 | 社内向けの小さな道具、毎日の細かい修正 |
| Standard | 深さ・速さ・費用のバランス型（初期設定） | ふつうの業務システム |
| Deep | いちばん丁寧。時間も費用も最大 | お金や個人情報を扱う所、止まると困る所 |
組織の管理者（Owner）が会社全体の段階を1つ決め、リポジトリごとに別の段階を付けることもできます。たとえば「ふだんの道具は Quick、決済まわりは Deep」という分け方です。全部を Deep にするのではなく、壊れたときの痛さで段階を分ける のが、費用を抑えるコツです。
費用はどう決まる？
公式ドキュメントによると、Code Review には「1回いくら」という決まった値段はありません。使った量（トークン）に応じて、プランに含まれる利用分とは別に、組織あてに請求されます。費用を左右するのは次の2つです。
- 1回あたりの重さ：選んだ段階、変更の大きさ、周りのコードの複雑さ、確かめる候補の数
- 回数：リポジトリごとの「いつレビューするか」の設定
「いつレビューするか」は、変更依頼を作ったときに1回・変更を足すたびに毎回・頼んだときだけ、から選べます。管理画面から追加したリポジトリは「毎回」から始まるので、そのままだと回数がいちばん多くなります。
公式ドキュメントは、いきなり全部で使わず、次の順で試すように勧めています。
- 月の上限額を決める
- 代表的なリポジトリをいくつか選び、「作ったときに1回」か「頼んだときだけ」で始める
- 何回か回ったら、管理画面で1回あたりの平均費用を見る
- 平均×月の変更依頼の数で、月の費用を見積もる
上限額に届くと、レビューは止まり、変更依頼にその理由が書かれます。知らないうちに費用が膨らむ形にはなっていない ので、まず小さく試すのが安全です。
/code-review との使い分け
Code Review はチーム向けの仕組みで、使えるのは Team・Enterprise プランの組織で、GitHub を使っている場合です。それ以外でも、AIに確かめさせる方法はあります。
| 方法 | 始め方 | 向いている人 |
|---|---|---|
/code-review | Claude Code の作業中にコマンドを打つ | どのプランでも。まず1人で試したいとき |
| Code Review | 変更依頼が来たら自動で（設定しだい） | GitHub で複数人が開発しているチーム |
| 自分で作る確かめ役 | サブエージェントやスキルとして用意する | 社内独自の観点で確かめたいとき |
/code-review は、今いるブランチの変更を、裏で動くサブエージェントに確かめさせます。会話を埋め尽くさず、終わると結果が届きます。--fix を付けると、見つけた問題の修正まで頼めます。ただし修正は、いま選んでいる権限モードのルールに従って行われます。
確かめ役を自分で作る方法は、Claude Codeのマルチエージェント入門で解説しています。確かめ役だけ深く考えさせたい場合は、サブエージェントのeffortとモデルの使い分けも参考になります。
任せる前のチェックリスト
- 何を確かめさせるか を書いておく（リポジトリに置く
REVIEW.mdなどの指示ファイル。公式ドキュメントでは、変更依頼の側ではなく元のブランチの指示だけを読むとされています） - 段階 を、壊れたときの痛さで分ける
- 回数 は「作ったときに1回」から始める
- 月の上限額 を先に決める
- 最後に取り込むかどうかは人が決める、と決まりにしておく
指摘が0件でも「安全」とは限りません。公式ドキュメントにも、見逃しはありうると明記されています。AIのレビューは、人の確認をなくすものではなく、人が見るべき所を絞るための道具 と考えるのが現実的です。確認の手間を減らす仕組みとしては、Claude CodeのオートモードやClaude Codeのフックとも組み合わせられます。
そのまま使える指示文の例
まず1人で試すなら、作業の終わりにこう頼みます。
/code-review確かめる観点を足したいときは、指示ファイルに次のように書いておきます。
確かめるときは、次の3つを優先して。
・お金の計算が変わる所（端数の扱い・税の計算）
・お客さまの情報を外に出す所
・元に戻せない操作（削除・上書き）
見た目や書き方の好みは指摘しなくてよい。よくある質問
プログラマーでなくても関係ありますか？
あります。外注先や社内の開発担当に作ってもらう場合でも、「変更をAIに確かめさせているか」「どの段階で確かめているか」を聞けるだけで、品質の会話がしやすくなります。
レビューに使うAIのモデルは選べますか？
選べません。公式ドキュメントでは、Code Review が使うモデルは仕組みの側で決められ、管理画面にモデルの選択肢はないとされています。丁寧さを変えたいときは、段階（Quick・Standard・Deep）を変えます。
下書きの変更依頼もレビューされますか？
自動のレビューは、下書きと、外部から分岐したリポジトリからの変更依頼を飛ばします。必要なときは、書き込み権限のある人が変更依頼に @claude review とコメントすると、その1回だけレビューが始まります。
出典
- Claude Code 公式ドキュメント「Code Review」
- Claude Code 公式ドキュメント「Code Review costs and usage」
- Claude Code 公式ドキュメント「Review locally with /code-review」
- Claude Code 変更履歴（2.1.304・2026年10月19日）
この記事はAIを使って下書きし、著者が事実確認・加筆しています。ツールの機能や料金は変わることがあるため、最新の情報は各社の公式ページでご確認ください。
