🧭 本記事は Claude Code実務運用シリーズ の STEP 5「レビュー自動化する」です。
シリーズ中核です。1体のAIレビューを6体の専門家チームに分割します。
シリーズ全体の地図と読む順は親記事にまとめています。

2026-07-02 追記: レビューの独立性を「プロンプトの建前」ではなく実行形態で担保する改良を反映しました — ①6人のレビューワーをSubagentとして1メッセージで並列起動、②検証役（Self-Critique）を独立Subagent化、③各レビューワーが差分の実物を自ら確認。「全体アーキテクチャ」「検証役」「公開用カスタムコマンド」「まとめ」を更新しています。

はじめに

Claude Codeにコードレビューをさせると、かなり便利です。

ただ、実務で使い続けていると、こんな問題が出てきます。

観点を増やすほど、1つ1つの確認が浅くなる
クラッシュ、仕様、外部依存、UI、テスト観点が混ざり、重要な指摘が埋もれる
「それっぽいが根拠の弱い指摘」が出ることがある
自動修正まで任せると、直さなくてよい箇所まで変更してしまう

そこで、1人のAIに全部レビューさせるのをやめて、複数の専門レビューワーに分けてレビューさせるカスタムコマンドを作りました。

作ったもの

作ったのは、こんなカスタムコマンドです。

/review-team-and-fix <commit-range | branch-name>

コミット範囲を渡す例です。

/review-team-and-fix main..feature/123456

ブランチ名だけ渡すこともできます。

/review-team-and-fix feature/123456

このコマンドは、次の流れでレビューします。

Claude Codeのカスタムコマンドとして作る理由

Claude Codeでは、/ で呼び出せるSlash Commandで定型作業をコマンド化できます。

公式ドキュメントでは、Slash CommandはClaude Codeセッションを制御するためのコマンドで、カスタムコマンドの呼び出しにも使えると説明されています。

また、Subagentは特定タスクを分離して処理する仕組みです。メイン会話に大量の検索結果・ログ・ファイル内容を流し込まず、専門タスクだけを担当させる用途に向いています。

「複数のレビューワーで別々の観点を確認する」という今回の用途には、この考え方がかなり相性よくハマります。

なぜ既存のレビューコマンドとは別にするのか

普段のレビューなら、1つのレビューコマンドで十分なケースも多いです。

たとえば、こういう差分です。

文言修正
コメント修正
軽微なリネーム
小さなUI調整
テストデータの修正

こうした軽微な差分に対して、毎回レビューワーチームを起動するのは重すぎます。

なので、通常レビュー用のコマンドとは別に、重要な変更だけに使うコマンドとして分けておくのがおすすめです。

通常レビュー:
/review-and-fix

重要レビュー:
/review-team-and-fix

全体アーキテクチャ

今回の構成は、こうなっています。

役割	担当
要件レビューワー	要件・受け入れ条件
安全性レビューワー	実行時安全性
UIレビューワー	UI・互換性・アクセシビリティ
依存レビューワー	外部依存・設定
設計レビューワー	既存影響・設計・テスタビリティ
運用レビューワー	エラーハンドリング・ビルド・運用
統合役	各レビューワーの指摘を統合
検証役	指摘の根拠を再検証
修正役	高リスク問題のみ修正
レポート生成役	レポート・テスト項目・受け入れ基準を作成

図にすると、6人のレビューワーが並列でレビューし、その結果が統合役に集約され、検証・修正・レポート作成へと一本化されていく流れになります。

ポイントは、レビューワーには修正させないことです。

各レビューワーは指摘だけを返します。そのあと統合役で統合し、検証役で妥当性を検証してから、修正対象を決めます。

レビューと修正を分離するのが、このコマンドの肝です。指摘する役と直す役を分けることで、レビューワーが自分の指摘を正当化するために修正を盛りすぎる、という事態を避けられます。

もう1つの肝は、この「分離」を実行形態で担保することです。

6人のレビューワーは、同一コンテキストで順番に演じさせるのではなく、Subagentとして1つのメッセージで並列起動します。同一コンテキストで順番に演じさせると、後のレビューワーが前のレビューワーの出力を見えてしまい、「他レビューワーの出力を渡さない」というルールが建前になります。独立性はプロンプトに書くだけでは守られません。実行の仕組みで守ります。

要件レビューワー: 要件・受け入れ条件

要件レビューワーは、仕様面を見ます。

確認する観点です。

Issueの目的を満たしているか
受け入れ条件と実装が一致しているか
Issue外の仕様変更が混ざっていないか
実装範囲が広すぎないか
実装範囲が狭すぎないか

コードとして正しくても、Issueの目的から外れている変更は実務では問題になります。だから技術レビューとは別に、要件レビュー担当を分けています。

安全性レビューワー: 実行時安全性

安全性レビューワーは、クラッシュや実行時エラーを見ます。

確認する観点です。

null / nil 参照
配列範囲外アクセス
型変換失敗
スレッド違反
リソース解放漏れ
非同期処理のキャンセル漏れ

実務で最優先なのは、クラッシュやデータ破壊につながる問題です。この観点は設計レビューや可読性レビューと混ぜず、独立させたほうが見落としにくくなります。

UIレビューワー: UI・互換性・アクセシビリティ

UIレビューワーは、ユーザーが直接触る部分を見ます。

確認する観点です。

対象サポート環境で動作するか
UI状態別の影響
アクセシビリティ
レスポンシブ対応
画面遷移
フォーカス制御
バックグラウンド復帰や再読み込み時の挙動

UI変更は、コード差分だけ見ると小さく見えることがあります。でも実際にはアクセシビリティや既存導線に影響することがある。なのでUI系のレビューワーを分けています。

依存レビューワー: 外部依存・設定

依存レビューワーは、外部ライブラリや設定変更を見ます。

確認する観点です。

外部ライブラリの使い方
SDKやパッケージの更新
importや初期化処理
非推奨API
権限設定
環境変数
署名やCapabilities
配布・審査・運用上のリスク

外部ライブラリやSDKの変更を、モデルの学習時点の知識だけで判断するのは危険です。そのため、必要に応じてContext7などで公式ドキュメントを確認する工程を入れています。

Context7は、最新かつバージョン固有のドキュメントやコード例をプロンプトに入れるためのMCPとして説明されています。

設計レビューワー: 既存影響・設計・テスタビリティ

設計レビューワーは、保守性とテストしやすさを見ます。

確認する観点です。

呼び出し元・呼び出し先への影響
既存機能への回帰
命名
責務分離
保守性
単体テストしやすい構造か
結合テストで確認できる構造か

AIレビューは、クラッシュのような目立つ問題は拾いやすい一方で、責務の肥大化やテストしにくさは見落としがちです。なので設計・テスト観点を独立させています。

運用レビューワー: エラーハンドリング・ビルド・運用

運用レビューワーは、異常系と運用面を見ます。

確認する観点です。

例外処理
Resultやエラー戻り値の扱い
ログ出力
ビルド設定
CI影響
障害発生時の切り分けやすさ

正常系だけ動くコードは、実務では不十分です。失敗時に原因を追えるか、CIやビルドで壊れないかまで確認します。

統合役で重複・矛盾を整理する

複数レビューワーを使うと、同じ問題が複数の観点から指摘されることがあります。レビューワー同士で判断が矛盾することもあります。

そこで統合役を入れます。

統合役の役割です。

重複指摘を統合する
矛盾する指摘を整理する
複数レビューワーが同じ箇所を指摘した場合は優先度を上げる
1人だけの指摘は、根拠が弱ければリスクを上げない
修正対象を重大・高リスクに絞る

ここで大事なのは、指摘数が多いことと、指摘が正しいことは別という点です。統合役には、指摘の数ではなく根拠の強さで判断させます。

検証役でハルシネーションを落とす

統合役のあとに、検証役を入れます。

検証役の役割です。

指摘が本当に差分に基づいているか確認する
ファイル・行・コード断片の根拠がない指摘を落とす
Issue情報と矛盾する指摘を落とす
公式確認が必要なのに未確認の指摘は「未確認」にする
過剰な重大判定を抑える

AIレビューで一番危ないのは、もっともらしいのに差分に根拠がない指摘です。だからレビュー結果をそのまま採用せず、検証する工程を挟んでいます。

さらに、検証役は統合役と同一コンテキストでは実行しません。独立したSubagentとして起動し、渡すのは「統合結果・対象コミット範囲・Issue情報の要約」だけにします。各レビューワーの生の出力や、統合に至った経緯は渡しません。

理由は、レビューワーに修正させないのと同じです。自分が統合した結果を自分で採点すると、どうしても甘くなります。 統合の経緯を知らない検証役が、git diff で差分の実物を自分で確認しながら指摘を突き合わせることで、初めて「別視点の検証」として機能します。

自動修正は重大・高リスクだけに限定する

このコマンドでは、リスクを4段階に分類しています。

リスク	内容
🔴 重大	起動不能、重大クラッシュ、データ破壊、重大なセキュリティリスク
🟠 高	広範囲回帰、依存関係の破壊的変更、主要導線の障害
🟡 中	局所的回帰、保守性低下、異常系の懸念
🟢 低	影響範囲が限定的な改善

自動修正するのは、🔴重大 / 🟠高だけです。🟡中 / 🟢低は、原則としてレポートに残すだけにします。

理由は、AIに「気になったところを全部直して」と任せると、レビュー対象外の変更まで混ざる可能性があるからです。

実務では、正しそうな改善よりも、意図しない差分を増やさないことのほうが重要になる場面が多いです。レビューPRに余計な差分が混ざると、それ自体がレビューコストを押し上げます。

成果物も作る

レビューだけで終わらせず、こちらも作成します。

レビューワーチームレポート
テスト項目
受け入れ基準

レビュー結果を人間が確認しやすくするためです。特にチケット駆動で開発している場合、レビュー結果からテスト項目と受け入れ基準まで作れると、実務にかなり載せやすくなります。

公開用カスタムコマンド

社内固有のIssue Tracker、SlackチャンネルID、URLなどを除いた公開用テンプレートです。

.claude/commands/review-team-and-fix.md として配置します。

mkdir -p .claude/commands

cp review-team-and-fix.md .claude/commands/review-team-and-fix.md

実行例です。

/review-team-and-fix main..feature/123456

review-team-and-fix.md を開く

---
description: 複数の専門レビューワーで差分をレビューし、統合・検証後に高リスク問題のみ最小修正して、レポート・テスト項目・受け入れ基準を作成する
argument-hint: "<commit-range | branch-name>"
---

あなたは熟練したコードレビュー責任者です。
対象プロジェクトの言語・フレームワーク・ビルドシステム・依存関係・配布方式を理解したうえで対応してください。

このコマンドは「レビューワーチーム型」のレビューコマンドです。
単独レビューではなく、複数の専門レビューワーで差分を確認し、Aggregator で統合し、Self-Critique で妥当性を検証してから、重大・高リスク問題のみ修正してください。

重要ルール:
- 入力に存在しない事実を前提にしない
- 不明な項目は「未確認」と明記する
- 推測は必ず「(推測です)」と明記する
- 指摘には、差分・Issue情報・公式ドキュメント・ビルド結果のいずれかの根拠を持たせる
- 自動修正は 🔴 重大 / 🟠 高 の問題に限定する
- 🟡 中 / 🟢 低 は原則としてレポートに記載するだけにし、勝手に修正しない
- 既存のコード意図を尊重し、修正は最小差分にする
- Issue Tracker / チャット通知 / Context7 / ブラウザ操作などの外部連携は、利用可能な場合のみ使う。使えない場合は理由を明記して処理を継続する

---

# Step 1: 入力の正規化・Issue番号の特定・Issue内容の確認

## Step 1-0: 入力（コミット範囲 / ブランチ名）の正規化

`$ARGUMENTS` にはコミット範囲またはブランチ名のいずれかが含まれる。
以下のルールでコミット範囲に正規化する。

- `..` を含む要素があれば、それをコミット範囲として扱う
- `..` を含む要素がなく、引数のいずれかが既存のブランチ名（`git rev-parse --verify <arg>` が成功）の場合は、ブランチ指定とみなす
  - 比較基点（base）は `main` 固定とする
  - `base=$(git merge-base main <branch>)` でマージベースを求める
  - `${base}..<branch>` を以後の「コミット範囲」として使用する
  - これにより `git log` / `git diff` の両方で、そのブランチが `main` に追加した差分だけを対象にする
  - ブランチ名に `feature/<番号>`、`fix/<番号>`、`bugfix/<番号>` 等の番号が含まれる場合は、それを Step 1-1 の Issue番号として優先採用する
- コミット範囲もブランチ名も特定できない場合は「レビュー対象（コミット範囲またはブランチ）を特定できませんでした」と報告し、処理を中断する

## Step 1-1: Issue番号の特定

- Issue番号が引数（コミット範囲またはブランチ名）に含まれていればそれを使用する
- Issue番号が含まれていない場合は、Step 1-0 で正規化したコミット範囲の `git log` から番号を抽出する
  - レンジの開始コミットは基点のため対象外
  - レビュー対象のコミットメッセージのみから抽出する
- Issue番号が複数ある場合は、最初に見つかったものを使用する
- Issue番号が見つからない場合は「Issue情報は未確認」とし、Step 2 以降はコード差分のみで判断する

## Step 1-2: Issue内容の確認（任意連携）

Issue Tracker 連携が利用できる場合のみ、特定した Issue番号から以下を取得する。

- タイトル・概要
- 改修の目的・背景
- 受け入れ条件（記載がある場合）
- 関連Issue（記載がある場合）

取得できた場合は日本語で要約する。
取得できない場合は「Issue情報の取得に失敗しました」と報告し、以降はコード差分のみで判断する。

---

# Step 2: 差分の事前整理

Step 1-0 で正規化したコミット範囲について、以下を取得する。

- `git log --oneline <コミット範囲>`
- `git diff --name-status <コミット範囲>`
- `git diff --stat <コミット範囲>`
- `git diff <コミット範囲>`

以下を日本語で簡潔にまとめる。

## 差分概要

- 対象ブランチ
- コミット範囲
- 変更ファイル一覧
- 主な変更内容
- 影響が大きそうな領域
- レビュー上の注意点

---

# Step 3: 公式ドキュメント確認の要否判定

差分レビューを開始する前に、公式ドキュメント確認が必要かを判定する。
Context7 MCP が利用可能な場合は Context7 を優先して使う。
利用できない場合は、利用できない理由を明記し、必要に応じてローカルの README・公式ドキュメント・型定義・ソースコードを確認する。

## 判定ルール

以下のいずれかに該当する場合は、公式ドキュメント確認を行う。

- 外部ライブラリ、SDK、パッケージ、ツールチェーンに関わる変更が含まれる
- ライブラリの import、初期化、設定、依存関係に変更がある
- API変更、非推奨化、削除の可能性がある
- ビルドエラーや警告の原因がライブラリ仕様変更の可能性がある
- 実装方法の正しさを公式ドキュメントで確認しないと危険な変更である
- package lock、設定ファイル、ビルド設定、CI設定に変更が含まれる

以下のみで構成される差分は、原則として公式ドキュメント確認を行わなくてよい。

- 文言修正
- コメント修正
- ローカル変数名や関数名の単純なリネーム
- 既存ロジックを変えない軽微な整形
- プロジェクト内ロジックのみの修正
- 画面文言、定数値、表示順などの軽微な変更
- テストデータやモックの軽微な修正
- 外部ライブラリやSDKに影響しないUI調整

## 出力形式

### 公式ドキュメント確認判定
- 判定: 要確認 / 不要
- 理由: 1〜3行

### 公式ドキュメント確認結果
※ 要確認の場合のみ記載

- 確認対象
- 確認内容
- 修正根拠

---

# Step 4: レビューワーチームによる並列レビュー

ここがこのコマンドの中核である。
単独レビューではなく、以下の専門レビューワーを可能な限り並列に起動してレビューする。

## 並列実行ルール

- 各レビューワーは Subagent（サブエージェント）として起動し、**1つのメッセージで並列に呼び出す**
- Subagent が使えない環境では順次のロールプレイで代替してよい。その場合、レビューワー間の独立性が低下している旨を最終レポートに明記する
- 各レビューワーには、以下の共通情報のみを渡す
  - Issue情報
  - 差分概要
  - 対象コミット範囲
  - 変更ファイル一覧
  - 必要に応じた公式ドキュメント確認結果
- 各レビューワーは、渡された対象コミット範囲に対して自ら `git diff` / `git log` を実行し、差分の実物を確認してよい
- 各レビューワーには他レビューワーの出力を渡さない
- 各レビューワーは自分の専門領域だけを深く見る
- 各レビューワーはコードを修正しない。レビュー結果のみ返す
- 各レビューワーは、指摘ごとに根拠となるファイル・行・差分内容を明記する
- ファイル・行が特定できない場合は「ファイル:行 = 未確認」とする

## Reviewer A: 要件・受け入れ条件レビューワー

観点:
1. Issue要件との整合性
2. 受け入れ条件との整合性
3. 仕様の抜け漏れ
4. 関連Issue・既存仕様との矛盾
5. 実装範囲が広すぎる、または狭すぎる可能性

特に確認すること:
- Issueの目的を満たしているか
- 実装がIssue外の仕様変更を含んでいないか
- 受け入れ条件に対して確認可能な実装になっているか

## Reviewer B: 実行時安全性レビューワー

観点:
1. クラッシュリスク
2. nil / null 参照
3. 配列範囲外アクセス
4. 型変換失敗
5. スレッド違反
6. リソース解放漏れ
7. 非同期処理のキャンセル漏れ

特に確認すること:
- 実行時クラッシュにつながる箇所がないか
- 非同期処理が不要に残り続けないか
- UI更新や共有状態の更新が安全に行われているか

## Reviewer C: UI・互換性・アクセシビリティレビューワー

観点:
1. OS / ランタイム / ブラウザ / フレームワークの互換性
2. UI状態別の影響
3. アクセシビリティ
4. レスポンシブ対応
5. 画面遷移・フォーカス・入力導線
6. バックグラウンド / 復帰 / 再読み込み時の挙動

特に確認すること:
- 対象サポート環境で動作するか
- UI変更がアクセシビリティや既存導線を壊していないか
- 状態変化時に表示や内部状態が破綻しないか

## Reviewer D: 外部依存・設定レビューワー

観点:
1. 外部ライブラリ準拠
2. SDK / package manager / ビルド設定
3. import、初期化、設定変更
4. 非推奨 API
5. 権限、環境変数、署名、Capabilities
6. 配布・審査・運用上のリスク

特に確認すること:
- 公式ドキュメント確認が要確認の場合、公式仕様に反していないか
- 依存関係更新による破壊的変更がないか
- 配布・署名・権限・審査に影響しないか

## Reviewer E: 既存影響・設計・テスタビリティレビューワー

観点:
1. 既存コードへの影響
2. 呼び出し元・呼び出し先への影響範囲
3. 命名・可読性
4. 責務分離
5. 保守性
6. テスタビリティ
7. 単体テスト・結合テストで確認可能な構造か

特に確認すること:
- 変更が既存機能に回帰を起こさないか
- 過剰な責務集中がないか
- テスト観点が抽出できる構造か

## Reviewer F: エラーハンドリング・ビルド・運用レビューワー

観点:
1. エラーハンドリング
2. 例外処理 / Result / エラー戻り値の扱い
3. ログ出力
4. ビルド設定
5. CI / ローカルビルド影響
6. 運用・調査時の問題切り分けやすさ

特に確認すること:
- 異常系が握りつぶされていないか
- 失敗時にユーザーまたは運用者が原因を追えるか
- ビルドやCIで壊れる可能性がないか

## 各レビューワーの出力形式

各レビューワーは以下の形式で返す。

```markdown
## Reviewer X: {レビューワー名}

### 確認範囲
- 対象ファイル:
- 対象観点:

### 指摘一覧
| # | リスク | 観点カテゴリ | ファイル:行 | 問題内容 | 根拠 | 推奨対応 | 確信度 |
|---|--------|------------|-----------|---------|------|---------|--------|

### 該当なしの観点
-

### 未確認の観点
-
```

リスク評価基準:
- 🔴 重大: 起動不能、重大クラッシュ、データ破壊、署名や権限の重大不整合、重大なセキュリティリスク
- 🟠 高: 広範囲回帰、依存関係の破壊的変更、権限設定不備、主要導線の障害
- 🟡 中: 局所的回帰、保守性低下、異常系の懸念、運用リスク
- 🟢 低: 影響範囲が限定的で、入力上は重大な懸念が確認できない

確信度:
- 高: 差分・Issue情報・公式仕様・ビルド結果に直接根拠がある
- 中: 差分から合理的に懸念できるが、実行確認が必要
- 低: 可能性の指摘に留まる。必ず「(推測です)」を付ける

---

# Step 5: Aggregator による統合レビュー

6人のレビューワー結果を統合する。

## 統合ルール

- 重複指摘を統合する
- 矛盾する指摘を整理する
- 複数レビューワーが同じ箇所を指摘している場合は「複数指摘あり」と明記する
- 1人だけの指摘は、根拠が弱ければリスクを上げない
- 指摘ごとに、最終リスクを再判定する
- 修正対象は 🔴 重大 / 🟠 高 のみとする
- 🟡 中 / 🟢 低 は原則として修正候補ではなく、残課題または推奨改善として扱う

## Aggregator 出力形式

```markdown
## Aggregator統合結果

| # | 最終リスク | 観点カテゴリ | ファイル:行 | 問題内容 | 指摘元 | 根拠 | 推奨対応 | 修正対象 |
|---|------------|------------|-----------|---------|--------|------|---------|---------|
```

---

# Step 6: Self-Critique による検証

Aggregator の統合結果を、**独立した Subagent** で検証する。

- 渡す情報は「Aggregator統合結果・対象コミット範囲・Issue情報の要約」のみとし、各レビューワーの生の出力や統合の経緯は渡さない
- Subagent は `git diff` で差分を自ら確認し、各指摘が実際の差分に基づいているかを検証する
- Subagent が使えない場合は同一コンテキストで実施し、その旨を最終レポートに明記する

## 検証ルール

- 各指摘が本当に差分に基づいているか確認する
- ファイル・行・コード断片の根拠がない指摘は削除または「未確認」に格下げする
- Issue情報と矛盾する指摘がないか確認する
- 公式ドキュメント確認が必要な指摘で、確認結果がない場合は「未確認」とする
- 過剰な 🔴 / 🟠 判定を抑制する
- ただし、クラッシュ・起動不能・データ破壊・署名・権限・広範囲回帰は過小評価しない

## Self-Critique 出力形式

```markdown
## Self-Critique結果

| # | 判定 | 対象指摘 | 理由 | 最終扱い |
|---|------|---------|------|---------|
```

判定:
- 採用
- 修正して採用
- リスク格下げ
- 未確認
- 削除

---

# Step 7: コード修正

Self-Critique 通過後、最終的に 🔴 重大 または 🟠 高 と判定された問題のみ修正する。

## 修正ルール

- 元のコード意図を尊重する
- 最小限の変更にする
- 中リスク・低リスクの改善は勝手に含めない
- 公式ドキュメント確認結果がある場合は、その内容に準拠した修正を行う
- 修正前後の差分を記録する
- 修正した理由を日本語で報告する

---

# Step 8: ビルド確認

プロジェクトに応じたビルドまたは検証コマンドを実行する。

優先順:
1. リポジトリの README / CONTRIBUTING / Makefile / package scripts / CI 設定に記載された公式手順
2. 既存のローカルビルドコマンド
3. 言語・フレームワーク標準の検証コマンド

例:
- iOS / macOS: `xcodebuild`、またはプロジェクトで定義されたビルドスクリプト
- Node.js: `npm test` / `npm run build` / `pnpm test` / `pnpm build`
- Ruby: `bundle exec rspec`
- Python: `pytest`
- Go: `go test ./...`

ビルドエラーがあれば修正を試み、再度ビルドする。

- ビルド試行は最大3回まで
- 3回失敗した場合は以下を報告して次のStepに進む
  - 最後のエラーメッセージ全文
  - 試した修正内容の履歴
  - 推測される原因（「(推測です)」と明記）
  - 人間によるデバッグが必要である旨
- 最終的なビルド結果を報告する

---

# Step 9: テスト項目作成

改修内容、Issue情報、レビュー結果に基づき、以下の観点でテストケースを作成する。

## 正常系
- 改修で追加・変更された機能が期待通り動作するケース
- Issueの受け入れ条件を満たすケース

## 異常系
- 不正な入力、通信エラー、未認証状態、権限不足など異常条件でのケース

## 回帰テスト
- 改修の影響範囲にある既存機能が壊れていないことを確認するケース

## 外部依存テスト
※ Step 3 で「要確認」の場合のみ追加する。

- 外部ライブラリ・SDKのバージョン更新に伴う互換性確認ケース
- API仕様変更による影響範囲のケース

## 出力形式

| # | 分類 | テスト項目 | 操作手順 | 期待結果 | 優先度 |
|---|------|-----------|---------|---------|-------|

優先度:
- 🔴 P0（必須）
- 🟡 P1（重要）
- 🟢 P2（推奨）

改修差分から読み取れる範囲のみ記載し、推測は「(推測です)」と明記する。

---

# Step 10: 受け入れ基準の作成

Issue情報、コード差分、レビュー結果に基づき、この変更の受け入れ基準を作成する。

## 作成ルール

- Issueに既存の受け入れ基準がある場合は、それをベースに不足分を補完する
- 既存の受け入れ基準がない場合は、新規に作成する
- 実装内容から確認すべき動作条件を箇条書きで列挙する
- 技術的な補足が必要な項目には「Note:」を付記する
- 確認方法が未確定の項目には「[TBD]」を付記する
- Markdown 形式で出力する

## 観点

- 改修で追加・変更された機能が正しく動作すること
- アプリ・サービスの状態別の動作
- 既存ユーザーへの影響
- 異常系での動作
- 既存機能への回帰影響

---

# Step 11: 最終レポート作成

以下の構成で最終結果を Markdown としてまとめる。

# 最終レポート

## Issue情報
- Issue番号:
- タイトル:
- コミット範囲:

## 差分概要
- 対象ブランチ:
- 変更ファイル:
- 主な変更内容:

## 公式ドキュメント確認判定
- 判定:
- 理由:
- 確認結果:

## レビューワーチーム構成
| Reviewer | 役割 | 実施結果 |
|----------|------|----------|

## Aggregator統合結果
| # | 最終リスク | 観点カテゴリ | ファイル:行 | 問題内容 | 指摘元 | 根拠 | 推奨対応 | 修正対象 |
|---|------------|------------|-----------|---------|--------|------|---------|---------|

## Self-Critique結果
| # | 判定 | 対象指摘 | 理由 | 最終扱い |
|---|------|---------|------|---------|

## レビュー結果
| # | リスク | 観点カテゴリ | ファイル:行 | 問題内容 | 推奨対応 | 修正実施 |
|---|--------|------------|-----------|---------|---------|---------|

問題が1件もない場合は、表の代わりに「該当なし」と明記する。

## 実施した修正
- 修正内容の一覧
- Before / After のコード差分

## ビルド結果
- ✅ 成功 / ❌ 失敗
- 失敗の場合は最後のエラーメッセージを併記する

## テスト項目
Step 9 で作成したテストケースを記載する。

## 受け入れ基準
Step 10 で作成した受け入れ基準を記載する。

## 残課題
- あれば記載
- なければ「なし」と明記する

---

# Step 12: 成果物をファイルに保存

Step 9〜11 の成果物を Markdown ファイルとして保存する。

- Issue番号がある場合の保存先: `./review-artifacts/{Issue番号}/`
- Issue番号がない場合の保存先: `./review-artifacts/review-YYYYMMDD-HHmmss/`
- 保存先ディレクトリが存在しない場合は `mkdir -p` で作成する

保存ファイル:
- `{Issue番号}_test_cases.md`
- `{Issue番号}_review_team_report.md`
- `{Issue番号}_acceptance_criteria.md`

Issue番号がない場合:
- `test_cases.md`
- `review_team_report.md`
- `acceptance_criteria.md`

同名ファイルが既に存在する場合は、ファイル名末尾に `-YYYYMMDD-HHmmss` を付ける。
保存完了後、ファイルの絶対パスを報告する。

---

# Step 13: 任意の外部連携

以下は利用可能な場合のみ実施する。
利用できない場合はスキップし、手動対応方法を案内する。

## 13-1: チャット通知

Slack / Teams / Discord などの通知連携が利用可能な場合は、以下の内容で完了通知を送る。

```text
{IssueリンクまたはIssue番号} のレビューワーチームレビューが完了しました。

成果物:
- test_cases.md（テスト項目）
- review_team_report.md（最終レポート）
- acceptance_criteria.md（受け入れ基準）

レビュー方式:
- 複数専門レビューワーによる並列レビュー
- Aggregator による統合
- Self-Critique による妥当性検証
```

## 13-2: Issue Tracker へのコメント・添付

Issue Tracker 連携またはブラウザ操作が利用可能な場合は、以下を実施する。

- 対象Issueを開く
- レビュー完了コメントを追加する
- 成果物3ファイルを添付またはリンクする
- 送信後、コメント・添付・リンクが反映されたことを確認する

自動連携できない場合は、以下の手動コメント案を提示する。

```text
レビューが完了しました。

対象ブランチ: {ブランチ名}
コミット範囲: {コミット範囲}
レビュー対象コミット: {レビュー対象コミット}

以下の資料を作成しました。

- レビューワーチームレポート
- テスト項目
- 受け入れ基準

内容をご確認ください。
```

---

# Step 14: 最終報告

最後に、以下を日本語で報告する。

- 対象コミット範囲
- Issue情報の取得結果
- レビューワーチームレビューの結果
- 修正有無
- ビルド結果
- 保存した成果物のパス
- 任意外部連携の実施結果
- 手動対応が必要な項目

向いているケース

このコマンドが向いているのは、こんな変更です。

影響範囲が広い変更
SDKや外部ライブラリの更新
認証、課金、配信、通知など重要導線の変更
クラッシュリスクがある変更
リリース前の重点レビュー
受け入れ基準やテスト項目まで整理したいチケット

向いていないケース

逆に、こちらには向いていません。

文言修正
コメント修正
軽微なリネーム
小さなUI調整
テストデータの軽微な修正

レビューワーチーム型は通常レビューより重いです。すべての差分に使うのではなく、重要な差分に絞って使うのが現実的です。Subagentを7体（レビューワー6＋検証役）起動するぶんトークンコストも増えるので、なおさら「重要な差分だけ」に絞る価値があります。

まとめ

AIコードレビューの精度を上げるポイントは、プロンプトを長くすることではなく、レビュー責務を分割することだと思います。

今回の構成では、こう分けました。

専門レビューワーが指摘する
  ↓
統合役が統合する
  ↓
検証役が検証する
  ↓
高リスクだけ修正する

この形にすると、AIレビューを単なる「便利な補助」から、実務のレビュー工程に組み込みやすいものに変えられます。

特に効いているのは、次の3点です。

レビューワーには修正させない
自動修正は重大・高リスクだけに限定する
レビューワーと検証役の「独立」は、プロンプトの建前ではなくSubagentという実行形態で担保する

AIに任せる範囲を広げるほど、制御設計が重要になります。

「全部AIに任せる」のではなく、AIに任せる工程と、人間が確認する工程を分ける。この考え方が、実務でClaude Codeを安全に使ううえで効いてくると感じています。

このシリーズの歩き方

Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。

◀ 前の記事: Claude Code標準SkillをiOSアプリ開発でどう使うか：公式ドキュメントを根拠に整理する
▶ 次の記事: 差分リスクでレビュー方式を自動振り分け：Claude Codeで作る3層コードレビュー・オーケストレーター【6体AI＋テンプレ全公開】
🔍 あわせて読む: プロンプトを磨くのをやめて、就業規則を書き始めた ── Claude Codeで定型業務を「組織化」する話 ― 分割の背後にある組織化の思想
🗺 シリーズ全記事の地図(親記事)