🧭 本記事は 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のように最新・バージョン固有のドキュメントを参照できる仕組みも効きます。

Context7 MCP

全体構成

今回の構成です。

役割はこうです。

コマンド	役割
`/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・開発・レビュー・統括エージェント設計 ― 同じ発想で開発全体を組織化
🗺 シリーズ全記事の地図(親記事)