Review Levelで決めること
先に答えると、迷った場合はStandardを基準にし、変更の影響が小さく時間を優先する場合だけQuick、認証・決済・個人情報など影響が大きい場合にDeepを候補にします。Levelはmergeの承認ではなく、レビューの深さを選ぶ設定です。
Claude Code公式changelogの2.1.304（2026年10月19日）は、Code ReviewにQuick、Standard、Deepのreview levelsを追加し、Ownerが組織の既定値と個別リポジトリのレベルを設定できると説明しています。公式のCode Reviewガイドも、Quickは最短・低コスト、Standardは深さ・速度・費用のバランス、Deepは最も詳細で時間と費用が大きいと整理しています。
これは「Deepなら必ずバグを見つける」という保証ではありません。公式ガイドは、レビューがAIによる確認であり、問題がない結果でも安全や無欠陥を意味しないと注意しています。既存のCode Reviewとローカルdiffの比較が経路選択を扱うのに対し、本稿は同じCode Reviewをどの深さで運用するかに限定します。
3段階の比較
| Level | 向く場面 | 注意点 |
|---|---|---|
| Quick | 小さな修正、短納期、反復的なPR | 重大変更の最終確認を代替しない |
| Standard | 通常の機能変更、既定運用 | リスクに応じてDeepへ上げる |
| Deep | 認証、決済、データ境界など重要変更 | 時間・費用が増える |
判断軸は変更行数だけではありません。認証・権限・個人情報・外部API・削除処理・DB migrationのように、失敗時の影響が大きい変更はDeep候補です。逆に文言、テストfixture、局所的なリファクタリングはQuick候補ですが、影響範囲が広いなら例外にします。
導入条件と制限を先に確認する
公式ガイドによると、Code ReviewはClaudeのTeamとEnterpriseプラン、GitHub上のリポジトリが対象です。Zero Data Retention、HIPAA構成、CMEKを使う組織では利用できず、self-hosted environmentsでレビューが動くわけでもありません。開発者がBedrock、Vertex、Foundryを使っていても、Code Review側には対象プランのClaude組織が必要です。
また、レビューはAnthropicのmanaged environmentで動き、リポジトリ内をread-onlyで読み、commitをpushしません。pull requestにはinline comment、summary、Claude Code Reviewのcheck runを投稿しますが、PRを承認・ブロックしません。こうした制限を確認せず、Deepを「自社CIの最終承認」と説明するのは誤りです。
8手順で組織の既定値を決める
- 対象プラン、GitHub host、ZDR・HIPAA・CMEKの適用有無を確認する。
- レビュー対象のリポジトリを、通常業務・重要業務・対象外に分類する。
- 過去の変更を、認証、個人情報、外部公開、データ変更、軽微変更に分類する。
- 各分類について、許容できるレビュー時間と予算の上限を決める。
- 通常のリポジトリにStandardを仮設定し、一定期間の結果を記録する。
- 高影響リポジトリだけDeep、反復的な小変更だけQuickへ例外設定する。
- 結果のseverity、見逃し、誤検知、再レビュー時間を人間が確認する。
- 月次でLevel、対象repo、費用、運用上の事故を見直す。
公式セットアップガイドの要件に従い、OwnerがGitHub App、対象repository、レビュー開始条件、Review Levelを設定します。設定を変えた人、理由、適用日、戻す方法を記録すると、個人の好みが組織標準へ無断で広がるのを防げます。
自動実行と手動依頼を分ける
Code Reviewは、リポジトリの設定によりPRのopen時、push後、または依頼時に起動できます。自動実行をQuickにして開発中のフィードバックを得て、release候補だけDeepにする設計も可能です。ただし自動レビューが走ることと、mergeを許可することは別です。誰がseverityを確認し、テストと実機検証をどう組み合わせるかを別のchecklistにします。
費用はLevelだけでなく、レビューの頻度や変更量などでも変わります。公式の費用と使用量ガイドを参照し、未確認の単価を記事や社内資料へ固定しないでください。利用量、Level、repo別の回数を記録して、予算上限と一緒に判断します。
Level変更を監査できる形にする
Review Levelの設定変更は、Ownerが選んだ値だけでなく、対象repository、変更理由、適用日、変更前の値、次回見直し日を記録します。Deepを選んだPRで何が見つかり、Quickへ戻した変更でどの確認を別の手段に移したかを残すと、単なる印象ではなく実績で見直せます。
レビューの結果が空でも、テスト、担当者の目視、脅威モデル、リリース承認を省略しません。AIのfind・verify・rank・postという流れと、組織のmerge責任を別の工程として表にし、失敗時に誰が再レビューを依頼するかまで決めておくと、深さの選択が形だけになりません。
運用チェックリスト
- TeamまたはEnterpriseとGitHub要件を確認した
- ZDR・HIPAA・CMEKの利用可否を確認した
- Quick・Standard・Deepの判断軸を文書化した
- 組織の既定値とrepo別例外のOwnerを決めた
- レビュー開始条件と再レビュー条件を決めた
- 費用・頻度・変更量・severityを記録する
- コメントがあっても人間がmerge判断する
- Level変更を月次で見直し、rollbackを確認する
よくある質問
Standardが常に最適ですか？
いいえ。公式ドキュメント上の既定値ですが、日常的な変更はQuick、重要な変更はDeepなど、リスクと時間・費用で選びます。
Review Levelでモデルを選べますか？
Code Reviewの管理設定にはモデル選択はなく、深さはReview Levelで調整します。
Code Reviewはマージを止めますか？
いいえ。レビューはコメントとcheck runを投稿しますが、pull requestを承認・ブロックせず、merge判断はチームに残ります。
無料診断で選定表を作れますか？
対象リポジトリ、変更リスク、頻度、予算、確認者を整理し、運用表へ落とし込めます。無料診断（60秒）をご利用ください。
まとめ
Review Levelは、Quick・Standard・Deepを変更リスクとレビュー期限に割り当てるための設定です。既定値はStandardでも、重要なrepoはDeep、反復的な小変更はQuickと分けられます。利用条件、read-only範囲、merge判断の責任、費用記録を確認し、AIレビューを人間の承認やテストの代替にしないでください。Miraigentでは、リポジトリ別のAIレビュー基準と承認フローを無料で診断します。無料診断（60秒）をご利用ください。