🧭 本記事は Claude Code実務運用シリーズ の STEP 5「レビュー自動化する」です。
前回作った6体チームと通常レビューを、差分リスクで自動的に使い分けます。
シリーズ全体の地図と読む順は 親記事 にまとめています。
2026-07-02 追記: 実運用からの改良を反映しました。①ブランチ指定時の比較基点を main 固定から自動判定（main / release 系ブランチ）＋ --base オプションに変更、②チームレビューのレビューワー・検証役をSubagentとして独立実行する方式を明記、③修正後のセルフチェックを追加。本文と各テンプレートを更新しています。
はじめに
前回の記事で、Claude Codeで1体のAIに全部レビューさせるのをやめて、複数の専門レビューワーに分けるカスタムコマンドを作りました。
1体AIレビューを6体チームに分割：Claude Codeで作る責務分割型コードレビュー【テンプレ全公開】
前回作ったのは、重要な差分を複数レビューワーで確認する /review-team-and-fix です。
/review-team-and-fix feature/123456
強力なんですが、実務で毎回使うには少し重い。
たとえば、以下のような差分にまで6体のAIレビューワーを起動するのは過剰です。
- 文言修正
- コメント修正
- 軽微なリネーム
- 小さなUI調整
- テストデータの修正
一方で、以下のような差分は通常レビューだけだと不安が残ります。
- SDK更新
- Package更新
- 認証まわり
- 課金まわり
- Push通知
- DRM
- 起動処理
- 非同期処理
- 広範囲に影響がある変更
そこで今回は、AIコードレビューを3つに分けて運用する構成にしました。
/review-and-fix
通常レビュー用
/review-team-and-fix
重要差分・高リスク差分用
/review-smart
通常レビューとチームレビューを自動で使い分ける入口
この3層をまとめると、1つのコードレビュー・オーケストレーターになります。入口の /review-smart が指揮者として差分のリスクを見極め、単独レビューで済ませるか、6体のレビューワーチームを編成するかを決める——本記事で作るのはこの仕組みです。
この記事では、この3つのカスタムコマンドで、Claude CodeのAIコードレビューを実務運用に載せる方法を紹介します。
この記事のゴール
便利なカスタムコマンドを紹介すること自体がゴールではありません。
ゴールは、AIコードレビューをこう運用できる状態にすることです。
軽微な差分
→ 通常レビュー
重要な差分
→ 複数レビューワーによる重点レビュー
迷う差分
→ 入口コマンドが判定
AIレビューは強力ですが、毎回最大構成で使えばいいわけではありません。差分のリスクに応じてレビュー方式を選べることが大事です。
前提
Claude Codeのカスタムコマンド（Slash Command）として作ります。/ で呼び出す定型作業をコマンド化する仕組みです。
Slash Commands - Claude Code Docs
複数の専門レビューワーに分ける考え方は、Claude CodeのSubagentとも相性がよいです。
Create custom subagents - Claude Code Docs
外部ライブラリやSDK更新を含む差分では、Context7のように最新・バージョン固有のドキュメントを参照できる仕組みも効きます。
全体構成
今回の構成です。
役割はこうです。
| コマンド | 役割 |
|---|---|
/review-and-fix |
通常レビュー、修正、ビルド確認、テスト項目作成、受け入れ基準作成 |
/review-team-and-fix |
複数レビューワーによる重点レビュー、統合、検証、高リスク修正 |
/review-smart |
差分を見て、通常レビューかチームレビューかを判定する入口 |
普段は /review-smart だけ使います。
/review-smart feature/123456
明らかに軽微な差分なら、通常レビューを強制できます。
/review-smart feature/123456 --normal
明らかに重要な差分なら、チームレビューを強制できます。
/review-smart feature/123456 --team
判定だけ見たいときは --dry-run です。
/review-smart feature/123456 --dry-run
1. /review-and-fix：通常レビュー用
日常的なコードレビューに使うコマンドです。対象は次のような差分です。
- 小規模な機能修正
- 軽微なUI調整
- 文言修正
- コメント修正
- 既存ロジックを大きく変えない修正
- テストデータ修正
- 小さなリファクタリング
/review-and-fix の流れです。
1. 入力の正規化
2. Issue / Ticket 情報の確認
3. Context7 利用要否判定
4. コードレビュー
5. 高リスク問題のみ修正
6. ビルド確認
7. テスト項目作成
8. 受け入れ基準作成
9. レポート作成
10. 必要に応じて通知・添付
ポイントは、AIに全部直させないことです。修正対象は原則として以下に絞ります。
🔴 重大
🟠 高
🟡 中 や 🟢 低 は、原則としてレポートに残すだけにします。
AIに「全部直して」と任せると、不要な変更が混ざりがちです。AIが修正してよい範囲を制限しておくのが実務では効きます。
中・低リスクをAIに直させないのは、品質を下げるためではなく、差分を読める状態に保つためです。直すかどうかは人間が判断する余地を残しておきます。
review-and-fix.md の公開用テンプレート例を開く
あなたは熟練したコードレビュー担当です。
$ARGUMENTS には、コミット範囲またはブランチ名が渡されます。
以下の手順でレビューしてください。
## Step 1: 入力の正規化
$ARGUMENTS を確認し、レビュー対象をコミット範囲に正規化してください。
### ルール
- `..` を含む場合は、コミット範囲として扱う
- `..` を含まず、既存ブランチ名として解決できる場合は、ブランチ指定として扱う
- ブランチ指定の場合は、比較基点とのマージベースを使って差分範囲を作る
- `--base <branch>` が指定されていれば、それを基点にする
- 指定がなければ、`main` と release 系ブランチのうち**対象ブランチとのマージベースが最も新しいもの**を基点として自動判定する（release から切られたブランチは release 側が選ばれる）
- 採用した基点をレポートに明記する
- 特定できない場合は、レビュー対象を特定できない旨を報告して中断する
例:
```bash
git merge-base <基点ブランチ> <branch>
```
## Step 2: Issue / Ticket 情報の確認
引数、ブランチ名、コミットメッセージからIssue番号またはTicket番号を抽出してください。
取得できる場合は、Issue / Ticketの以下を確認してください。
- タイトル
- 目的
- 背景
- 受け入れ条件
- 関連Issue
取得できない場合は、コード差分のみでレビューしてください。
不明な情報は「未確認」と明記してください。
## Step 3: Context7 利用要否判定
差分に以下が含まれる場合は、Context7などを使って公式ドキュメントを確認してください。
- 外部ライブラリ変更
- SDK更新
- Package更新
- import変更
- 初期化処理変更
- API変更
- 非推奨APIの可能性
- 設定ファイル変更
以下のみの場合は、原則としてContext7は不要です。
- 文言修正
- コメント修正
- 軽微なリネーム
- 既存ロジックを変えない整形
- 小さなUI調整
- テストデータ修正
出力形式:
```markdown
## Context7利用判定
- 判定: 要利用 / 不要
- 理由:
```
## Step 4: コードレビュー
以下の観点を必ず確認してください。
1. Issue / Ticket 要件との整合性
2. クラッシュリスク
3. メモリリスク
4. 対象バージョン互換性
5. 既存コードへの影響
6. テスタビリティ
7. 命名・可読性
8. エラーハンドリング
9. 非同期処理
10. アクセシビリティ
11. 外部ライブラリ準拠
各観点について、該当なしの場合も「該当なし」と明記してください。
## Step 5: リスク分類
指摘事項を以下で分類してください。
- 🔴 重大: 起動不能、重大クラッシュ、データ破壊、重大なセキュリティリスク
- 🟠 高: 広範囲回帰、依存関係の破壊的変更、主要導線の障害
- 🟡 中: 局所的回帰、保守性低下、異常系の懸念
- 🟢 低: 影響範囲が限定的な改善
## Step 6: コード修正
🔴重大 または 🟠高 の問題のみ修正してください。
修正時のルール:
- 最小限の変更にする
- 元のコード意図を尊重する
- 推測で大きな設計変更をしない
- 中・低リスクは原則としてレポートに残すだけにする
- 修正後、修正差分そのものを Step 4 の観点で再点検し、新たな問題を生んでいないことを確認する
## Step 7: ビルド確認
可能であればビルドを実行してください。
ビルドに失敗した場合は、最大3回まで修正を試みてください。
3回失敗した場合は、以下を報告してください。
- 最後のエラーメッセージ
- 試した修正内容
- 推測される原因
- 人間による確認が必要な箇所
## Step 8: テスト項目作成
以下の形式でテスト項目を作成してください。
| # | 分類 | テスト項目 | 操作手順 | 期待結果 | 優先度 |
| - | -- | ----- | ---- | ---- | --- |
分類:
- 正常系
- 異常系
- 回帰テスト
- 外部依存テスト
優先度:
- 🔴 P0
- 🟡 P1
- 🟢 P2
## Step 9: 受け入れ基準作成
Issue / Ticket 情報と差分に基づいて、受け入れ基準を作成してください。
```markdown
# 受け入れ基準
- xxxできること
- yyyの場合にzzzとなること
- 既存機能に回帰がないこと
```
## Step 10: 最終レポート
以下の構成で最終レポートを出力してください。
```markdown
# 最終レポート
## 対象
- Issue / Ticket:
- コミット範囲:
- ブランチ:
- 比較基点:
## Context7利用判定
- 判定:
- 理由:
## レビュー結果
| # | リスク | 観点 | ファイル:行 | 問題内容 | 推奨対応 | 修正実施 |
|---|---|---|---|---|---|---|
## 実施した修正
## ビルド結果
## テスト項目
## 受け入れ基準
## 残課題
```
## Step 11: 成果物保存
可能であれば、以下のMarkdownファイルを保存してください。
- レビュー結果
- テスト項目
- 受け入れ基準
保存先はプロジェクトに合わせてください。
例:
```text
./review-artifacts/{ticket_id}/
```
## Step 12: 任意連携
Slack、Teams、Redmine、GitHub Issue、Jiraなどへの通知・添付が必要な場合は、プロジェクトの環境に合わせて実施してください。
社内URL、チャンネルID、認証情報はカスタムコマンドに直書きしないでください。
2. /review-team-and-fix：重要差分・高リスク差分用
前回記事で作った、レビューワーチーム型のコマンドです。使う対象はこういう差分です。
- 影響範囲が広い
- 複数画面に影響する
- SDKやPackage更新を含む
- 認証・課金・通知・DRMなど重要領域を触る
- 非同期処理を変更する
- 起動処理や状態管理を変更する
- クラッシュやデータ破壊のリスクがある
- リリース前に重点レビューしたい
/review-team-and-fix では、レビュー担当を分けます。
| レビュー担当 | 観点 |
|---|---|
| 要件レビュー | 要件・受け入れ条件 |
| 安全性レビュー | クラッシュ・メモリ・非同期 |
| UIレビュー | UI・互換性・アクセシビリティ |
| 依存レビュー | 外部依存・Context7 |
| 設計レビュー | 既存影響・設計・テスタビリティ |
| 運用レビュー | エラーハンドリング・ビルド・運用 |
ここで大事なのは、レビューワーには修正させないことです。各レビューワーは指摘だけを返します。修正は、AggregatorとSelf-Critiqueを通過した後にやります。
これで以下を防ぎます。
- 根拠の弱い指摘をそのまま修正する
- レビューワーごとに別々の修正方針が混ざる
- AIが直さなくてよい箇所まで変更する
- 重要でない指摘で差分が膨らむ
また、この「分離」はプロンプトの注意書きではなく実行形態で担保します。各レビューワーと検証役はSubagentとして分離起動し、互いの出力や検討の経緯を見せません。同一コンテキストで順番に演じさせると、後のレビューワーが前の出力に引っ張られて独立性が建前になるからです（詳細は前回記事を参照）。
review-team-and-fix.md の公開用テンプレート例を開く
あなたはコードレビューを行うレビューワーチームのオーケストレーターです。
$ARGUMENTS には、コミット範囲またはブランチ名が渡されます。
このコマンドは、重要差分・高リスク差分向けです。
以下の手順でレビューしてください。
## Step 1: 入力の正規化
$ARGUMENTS をコミット範囲に正規化してください。
- `..` を含む場合はコミット範囲として扱う
- ブランチ名の場合は、比較基点とのマージベースから差分範囲を作る
- `--base <branch>` が指定されていれば、それを基点にする
- 指定がなければ、`main` と release 系ブランチのうち**対象ブランチとのマージベースが最も新しいもの**を基点として自動判定する
- 採用した基点をレポートに明記する
- 特定できない場合は中断する
## Step 2: Issue / Ticket 情報の確認
Issue / Ticket番号を抽出できる場合は、以下を確認してください。
- タイトル
- 目的
- 背景
- 受け入れ条件
- 関連Issue
取得できない場合は、コード差分のみでレビューしてください。
不明点は「未確認」と明記してください。
## Step 3: Context7 利用要否判定
外部ライブラリ、SDK、Package、ツールチェーン、設定ファイルに関わる変更がある場合は、Context7などで公式ドキュメントを確認してください。
出力:
```markdown
## Context7利用判定
- 判定: 要利用 / 不要
- 理由:
- 確認対象:
```
## Step 4: レビューワーチームによる並列レビュー
以下の6つの観点でレビューしてください。
- 各レビューワーは Subagent（サブエージェント）として起動し、**1つのメッセージで並列に呼び出してください**
- Subagent が使えない環境では順次のロールプレイで代替し、レビューワー間の独立性が低下している旨を最終レポートに明記してください
- 各レビューワーには他のレビューワーの出力を渡さないでください
- 各レビューワーは、対象コミット範囲に対して自ら `git diff` / `git log` を実行し、差分の実物を確認して構いません
- 各レビューワーは、修正を実施せず、指摘のみ返してください
### Reviewer A: 要件・受け入れ条件
確認観点:
- Issue / Ticket の目的を満たしているか
- 受け入れ条件と実装が一致しているか
- 仕様外の変更が混ざっていないか
- 実装範囲が広すぎないか
- 実装範囲が狭すぎないか
### Reviewer B: クラッシュ・メモリ・非同期
確認観点:
- null / nil 参照
- force unwrap
- 配列範囲外アクセス
- 型変換失敗
- メインスレッド違反
- retain cycle
- リソース解放漏れ
- async / await の扱い
- Taskキャンセル漏れ
### Reviewer C: UI・互換性・アクセシビリティ
確認観点:
- 対象サポート環境で動作するか
- OSバージョン互換性
- 画面状態別の影響
- Dynamic Type
- VoiceOver
- レスポンシブ対応
- 画面遷移
- フォーカス制御
- バックグラウンド復帰時の挙動
### Reviewer D: 外部依存・Context7
確認観点:
- 外部ライブラリの使い方
- SDK更新
- Package更新
- import変更
- 初期化処理
- 非推奨API
- 権限設定
- 環境変数
- 署名・Capabilities
- 配布・審査・運用上のリスク
Context7確認結果がある場合は、それを根拠にしてください。
### Reviewer E: 既存影響・設計・テスタビリティ
確認観点:
- 呼び出し元への影響
- 呼び出し先への影響
- 既存機能への回帰
- 命名
- 責務分離
- 保守性
- 単体テストしやすいか
- 結合テストしやすいか
### Reviewer F: エラーハンドリング・ビルド・運用
確認観点:
- 例外処理
- エラー戻り値の扱い
- ログ出力
- ビルド設定
- CI影響
- 障害発生時の切り分けやすさ
- 運用時の確認ポイント
## Step 5: Aggregatorによる統合
各レビューワーの指摘を統合してください。
統合ルール:
- 重複指摘をまとめる
- 矛盾する指摘を整理する
- 複数レビューワーが同じ箇所を指摘した場合は優先度を上げる
- 1人だけの指摘は、根拠が弱ければリスクを上げない
- 修正対象は重大・高リスクに絞る
- ファイル名、行番号、根拠コードを明記する
リスク分類:
- 🔴 重大: 起動不能、重大クラッシュ、データ破壊、重大なセキュリティリスク
- 🟠 高: 広範囲回帰、依存関係の破壊的変更、主要導線の障害
- 🟡 中: 局所的回帰、保守性低下、異常系の懸念
- 🟢 低: 影響範囲が限定的な改善
## Step 6: Self-Critiqueによる検証
Aggregatorの結果を、**独立した Subagent** で再検証してください。
- 渡す情報は「Aggregator統合結果・対象コミット範囲・Issue / Ticket 情報の要約」のみとし、各レビューワーの生の出力や統合の経緯は渡さないでください
- Subagent は `git diff` で差分を自ら確認し、各指摘が実際の差分に基づいているかを検証してください
- Subagent が使えない場合は同一コンテキストで実施し、その旨を最終レポートに明記してください
検証観点:
- 指摘が差分に基づいているか
- ファイル・行・コード断片の根拠があるか
- Issue / Ticket情報と矛盾していないか
- 推測を断定していないか
- 過剰な重大判定になっていないか
- 公式確認が必要な項目を未確認のまま断定していないか
根拠が弱い指摘は削除または「未確認」にしてください。
## Step 7: コード修正
Self-Critiqueを通過した 🔴重大 または 🟠高 の問題のみ修正してください。
修正ルール:
- 最小限の変更にする
- 既存の設計意図を尊重する
- 中・低リスクの指摘は原則として修正しない
- 修正理由を明記する
- Before / After をレポートする
## Step 8: ビルド確認
可能であればビルドを実行してください。
最大3回まで修正を試みてください。
3回失敗した場合は、以下を報告してください。
- 最後のエラーメッセージ
- 試した修正内容
- 推測される原因
- 人間による確認が必要な箇所
## Step 9: テスト項目作成
以下の形式でテスト項目を作成してください。
| # | 分類 | テスト項目 | 操作手順 | 期待結果 | 優先度 |
| - | -- | ----- | ---- | ---- | --- |
分類:
- 正常系
- 異常系
- 回帰テスト
- 外部依存テスト
## Step 10: 受け入れ基準作成
Issue / Ticket 情報と差分から、受け入れ基準を作成してください。
```markdown
# 受け入れ基準
- xxxできること
- yyyの場合にzzzとなること
- 既存機能に回帰がないこと
```
## Step 11: 最終レポート作成
以下の構成で出力してください。
```markdown
# 最終レポート
## 対象
- Issue / Ticket:
- コミット範囲:
- ブランチ:
- 比較基点:
## Context7利用判定
## レビューワー別レビュー結果
## Aggregator統合結果
## Self-Critique結果
## 修正対象
## 実施した修正
## ビルド結果
## テスト項目
## 受け入れ基準
## 残課題
```
## Step 12: 成果物保存
可能であれば、以下をMarkdownファイルとして保存してください。
- 最終レポート
- テスト項目
- 受け入れ基準
保存先例:
```text
./review-artifacts/{ticket_id}/
```
## Step 13: 任意連携
必要に応じて、Slack、Teams、Redmine、GitHub Issue、Jiraなどへ通知・添付してください。
社内URL、チャンネルID、認証情報はカスタムコマンドに直書きしないでください。
3. /review-smart：自動振り分け用
今回の主役です。
/review-smart はレビュー本体ではありません。役割は、差分を軽く見て、どちらのレビュー方式を使うべきか判断することです。位置づけとしては、この3層構成＝コードレビュー・オーケストレーターの「指揮者」にあたります。
軽微・通常差分
→ /review-and-fix
重要・高リスク差分
→ /review-team-and-fix
普段はこれだけ覚えておけばよいです。
/review-smart feature/123456
コミット範囲でも使えます。
/review-smart abc1234..def5678
直近3コミットをレビューしたいとき。
/review-smart HEAD~3..HEAD
1コミットだけレビューしたいとき。
/review-smart abc1234^..abc1234
判定だけ確認したいとき。
/review-smart feature/123456 --dry-run
通常レビューを強制したいとき。
/review-smart feature/123456 --normal
チームレビューを強制したいとき。
/review-smart feature/123456 --team
ブランチの切り出し元は main とは限らない
当初、ブランチ指定時の比較基点は main 固定にしていました。ところが実務では、release ブランチから feature ブランチを切る運用がまれにあります。この場合、main とのマージベースで差分を作ると、release 側に積まれた他チケットのコミットがレビュー範囲に混入します。
実際に手元で計測したところ、release から切ったブランチを main 基点でレビューすると、本来 19 コミットの差分が 145 コミット分に膨らんでいました。差分が膨らむだけでなく、コミットメッセージからの Ticket 番号抽出も誤りやすくなります。
そこで、比較基点は自動判定に変更しました。
- 基点候補（
mainと release 系ブランチ）それぞれと対象ブランチのマージベースを取り、最も新しいマージベースを持つ候補を基点に採用する（release から切られたブランチは release 側が、main から切られたブランチは main が選ばれる） - 明示したい場合は
--base <branch>で上書きできる
/review-smart feature/123456 --base release/v1.2.0
/review-smart の判定ルール
通常レビューに回す条件です。
/review-and-fix に回す
- 文言修正
- コメント修正
- 軽微なリネーム
- 小さなUI調整
- テストデータ修正
- 既存ロジックを大きく変えない修正
- 変更ファイル数が少ない
- 変更行数が少ない
- 外部依存に触れていない
チームレビューに回す条件です。
/review-team-and-fix に回す
- SDK更新
- Package更新
- 外部ライブラリ変更
- 認証
- 課金
- Push通知
- DRM
- 起動処理
- 非同期処理
- 状態管理
- DB / 永続化
- 権限設定
- 署名・Capabilities
- CI / ビルド設定
- 複数画面への影響
- 変更ファイル数が多い
- 変更行数が多い
- クラッシュリスクがある
review-smart.md の公開用テンプレート例を開く
あなたはコードレビュー方式を選択し、実行を統括するコードレビュー・オーケストレーターです。
このコマンドは、通常レビューとチームレビューの入口を一本化するルーターとして働きます。
$ARGUMENTS には、コミット範囲、ブランチ名、またはオプションが渡されます。
このコマンドの目的は、差分のリスクに応じて以下を使い分けることです。
- 通常レビュー: /review-and-fix
- 重要レビュー: /review-team-and-fix
## 対応オプション
以下のオプションに対応してください。
- `--dry-run`: 判定だけ行い、レビュー本体は実行しない
- `--normal`: 通常レビューを強制する
- `--team`: チームレビューを強制する
- `--base <branch>`: ブランチ指定時の比較基点を明示する（自動判定を上書き）
## Step 1: 入力の正規化
$ARGUMENTS から、レビュー対象とオプションを分離してください。
### コミット範囲指定
`..` を含む場合は、コミット範囲として扱ってください。
例:
```bash
abc1234..def5678
HEAD~3..HEAD
abc1234^..abc1234
```
### ブランチ指定
`..` を含まず、既存ブランチ名として解決できる場合は、ブランチ指定として扱ってください。
比較基点（baseブランチ）は次の手順で決めてください。
- `--base <branch>` が指定されていれば、それを基点にする
- 指定がなければ、自動判定する
1. 基点候補を列挙する: `main` と release 系ブランチ（例: `git branch -r --list 'origin/release/*'`）
2. 候補ごとに `git merge-base <候補> <branch>` を求める
3. **マージベースが最も新しい候補**（他候補のマージベースを祖先に含む方。`git merge-base --is-ancestor` で判定）を基点に採用する
4. すべて同一なら `main` を採用する
```bash
base=$(git merge-base <採用した基点> <branch>)
range="${base}..<branch>"
```
採用した基点と判定根拠を、判定結果に含めてください。
### 特定できない場合
レビュー対象を特定できない場合は、以下を報告して中断してください。
```text
レビュー対象を特定できませんでした。
コミット範囲またはブランチ名を指定してください。
```
## Step 2: 差分サマリの取得
以下を確認してください。
```bash
git diff --name-only <range>
git diff --shortstat <range>
git diff --stat <range>
git log --oneline <range>
```
必要に応じて、差分の中身も確認してください。
```bash
git diff <range>
```
ただし、この段階ではレビュー本体を行わず、レビュー方式の判定に必要な範囲だけ確認してください。
## Step 3: 強制オプションの処理
### `--normal` が指定された場合
通常レビューを選択してください。
```text
選択: /review-and-fix
理由: --normal が指定されたため
```
### `--team` が指定された場合
チームレビューを選択してください。
```text
選択: /review-team-and-fix
理由: --team が指定されたため
```
### `--dry-run` が指定された場合
判定結果だけ出力し、レビュー本体は実行しないでください。
## Step 4: 自動判定
以下の条件に該当する場合は、`/review-team-and-fix` を選択してください。
### チームレビュー条件
- SDK更新
- Package更新
- 外部ライブラリ変更
- 認証まわりの変更
- 課金まわりの変更
- Push通知まわりの変更
- DRMまわりの変更
- 起動処理の変更
- 非同期処理の変更
- 状態管理の変更
- DB / 永続化の変更
- 権限設定の変更
- 署名・Capabilitiesの変更
- CI / ビルド設定の変更
- 複数画面に影響する変更
- 変更ファイル数が多い
- 変更行数が多い
- クラッシュリスクがある
- データ破壊リスクがある
- セキュリティリスクがある
以下のみの場合は、`/review-and-fix` を選択してください。
### 通常レビュー条件
- 文言修正
- コメント修正
- 軽微なリネーム
- 小さなUI調整
- テストデータ修正
- 既存ロジックを大きく変えない修正
- 変更ファイル数が少ない
- 変更行数が少ない
- 外部依存に触れていない
- 重要導線に影響しない
## Step 5: 判定結果の出力
以下の形式で出力してください。
```markdown
# レビュー方式判定
## 入力
- 指定:
- 正規化後のコミット範囲:
- 比較基点: （自動判定 / --base 指定）
- オプション:
## 差分サマリ
- 変更ファイル数:
- 変更行数:
- 主な変更ファイル:
- 主な変更領域:
## 判定
- 選択: /review-and-fix または /review-team-and-fix
- 理由:
## リスク要因
- xxx
- yyy
## 実行予定
- 実行するコマンド:
```
## Step 6: dry-run の場合
`--dry-run` が指定されている場合は、ここで終了してください。
```text
--dry-run のため、レビュー本体は実行しません。
```
## Step 7: 選択したレビュー方式の実行
選択結果に応じて、対応するレビュー手順を実行してください。
### 通常レビューの場合
`/review-and-fix` 相当の手順を実行してください。
### チームレビューの場合
`/review-team-and-fix` 相当の手順を実行してください。
## 注意
このコマンドは、レビュー方式を選ぶ入口です。
レビュー品質を上げるために、判定理由を必ず明記してください。
判断に迷う場合は、軽い通常レビューではなく、チームレビューを選択してください。
配置方法
プロジェクト単位で使う場合は、以下に配置します。
.claude/commands/
構成例です。
.claude/
commands/
review-and-fix.md
review-team-and-fix.md
review-smart.md
作成コマンドです。
mkdir -p .claude/commands
touch .claude/commands/review-and-fix.md
touch .claude/commands/review-team-and-fix.md
touch .claude/commands/review-smart.md
各ファイルに、上記のテンプレートを貼り付けます。
全プロジェクト共通で使いたい場合は、ホームディレクトリ配下に置きます。
mkdir -p ~/.claude/commands
touch ~/.claude/commands/review-and-fix.md
touch ~/.claude/commands/review-team-and-fix.md
touch ~/.claude/commands/review-smart.md
ただし、最初はプロジェクト配下の .claude/commands/ に置くほうが安全です。プロジェクトごとにレビュー観点、ビルドコマンド、Issue Tracker、通知先が違うからです。
実行例
普段のレビュー。
/review-smart feature/123456
コミット範囲指定。
/review-smart abc1234..def5678
直近3コミット。
/review-smart HEAD~3..HEAD
1コミットだけ。
/review-smart abc1234^..abc1234
判定だけ確認。
/review-smart feature/123456 --dry-run
通常レビューを強制。
/review-smart feature/123456 --normal
チームレビューを強制。
/review-smart feature/123456 --team
release ブランチから切ったブランチで、基点を明示。
/review-smart feature/123456 --base release/v1.2.0
実務での使い分け
基本運用はこれでいいです。
迷ったら:
/review-smart
軽微と分かっている:
/review-smart --normal
重要と分かっている:
/review-smart --team
判定だけ見たい:
/review-smart --dry-run
もう少し実務寄りにすると、こうなります。
| 差分 | 推奨 |
|---|---|
| 文言修正 | /review-smart --normal |
| コメント修正 | /review-smart --normal |
| 軽微なUI調整 | /review-smart |
| 小さなリファクタリング | /review-smart |
| SDK更新 | /review-smart --team |
| Package更新 | /review-smart --team |
| 認証まわり | /review-smart --team |
| 課金まわり | /review-smart --team |
| Push通知 | /review-smart --team |
| DRM | /review-smart --team |
| 起動処理 | /review-smart --team |
| 非同期処理 | /review-smart --team |
| リリース前の重点確認 | /review-smart --team |
なぜ3つに分けるのか
最初は、1つの巨大なレビューコマンドに全部入れればいいと思うかもしれません。でも実務では分けたほうが回しやすい。理由は3つあります。
理由1: 軽微な差分にチームレビューは重すぎる
複数レビューワー構成は観点が広い分、時間もトークンも使います。文言修正やコメント修正にまで毎回使うのは過剰です。
理由2: 重要差分には通常レビューだけだと不安
一方で、重要な差分では通常レビューだけだと足りないことがあります。特に以下は見落としのコストが高い。
- クラッシュ
- データ破壊
- 認証不備
- 課金不備
- 通知不備
- SDKの使い方間違い
- 外部ライブラリの仕様変更
- ビルド設定ミス
こういう差分では、要件・安全性・UI・依存・設計・運用を分けて確認する価値があります。
理由3: 人間が毎回判断するのは面倒
人間が毎回、
これは通常レビューでよいか？
チームレビューに回すべきか？
と考えるのは地味に面倒です。
そこで /review-smart を入口にします。差分を見て、変更ファイル・変更量・変更領域からレビュー方式を判定させる。これで運用ルールが単純になります。
普段は /review-smart
これだけです。
注意点
1. 社内情報を直書きしない
カスタムコマンドに以下を直書きするのは避けます。
- 社内URL
- SlackチャンネルID
- APIキー
- 認証情報
- 個人名
- 社内固有のプロジェクト名
公開用テンプレートでは、こう抽象化します。
{ISSUE_TRACKER_URL}
{SLACK_CHANNEL_ID}
{PROJECT_NAME}
{TICKET_ID}
2. 自動修正範囲を制限する
AIに自動修正させる場合、修正対象は絞ります。おすすめは以下です。
🔴 重大
🟠 高
中・低リスクは、レポートに残して人間が判断するほうが安全です。
3. review-smart は判定理由を必ず出す
review-smart で重要なのは、どちらを選んだかだけではありません。なぜ選んだかが重要です。
出力例です。
# レビュー方式判定
## 判定
- 選択: /review-team-and-fix
## 理由
- Package更新を含む
- 起動時初期化処理に変更がある
- 変更ファイル数が多い
- 外部ライブラリ仕様の確認が必要
判定理由が残ると、レビュー方式の妥当性を後から検証できます。
4. 最初は --dry-run を使う
導入直後は、いきなりレビュー本体を走らせず、--dry-run で判定だけ見るのがおすすめです。
/review-smart feature/123456 --dry-run
判定が妥当なら、通常実行に切り替えます。
/review-smart feature/123456
まとめ
今回作ったのは、Claude CodeのAIコードレビューを実務運用するための3層構成——いわば「コードレビュー・オーケストレーター」です。
/review-and-fix
通常レビュー
/review-team-and-fix
重要差分・高リスク差分レビュー
/review-smart
レビュー方式の自動振り分け
前回は、AIレビューを6体のレビューワーチームに分けました。今回は、そのチームレビューを毎回使うのではなく、差分のリスクに応じて使い分ける入口を作りました。
AIコードレビューで重要なのは、レビュー能力を上げることだけではありません。レビュー方式を選べるようにすることです。
軽微な差分には軽いレビュー
重要な差分には重いレビュー
迷ったら自動判定
この形にしておくと、Claude Codeのレビュー運用がかなり現実的になります。
このシリーズの歩き方
Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。
- ◀ 前の記事: 1体AIレビューを6体チームに分割：Claude Codeで作る責務分割型コードレビュー【テンプレ全公開】
- ▶ 次の記事: ビジネス担当の企画に、6人の専門家AI+検証役が意見書を返す ― Claude Codeスキル公開
- 🔍 あわせて読む: ループエンジニアリングでClaude Codeを実務に：Redmineチケット駆動開発のQA・開発・レビュー・統括エージェント設計 ― 同じ発想で開発全体を組織化
- 🗺 シリーズ全記事の地図(親記事)