フェーズ 6: レビュー

目的

実装されたコードが要件を満たし、品質基準をクリアしていることを確認する。自動レビューエージェントと人間のレビューを組み合わせ、バグ・セキュリティ問題・設計欠陥を実装段階で摘出する。

検証は「期待する振る舞いを実行証拠で示せるか」、レビューは「差分が安全で保守可能か」を別々に判定する。先に検証証拠を揃え、レビューでコードが変わった場合は検証へ戻って最新差分の証拠を作り直す。

開始条件

• 差分、要件書、実装計画、docs/workflow/test-evidence.md が同じ変更版を指す
• 検証の必須ゲートが成功し、既知の例外が明示されている

入力成果物

• レビュー対象の差分
• docs/workflow/requirements.md
• docs/workflow/implementation-plan.md
• docs/workflow/test-evidence.md

実行手順

1. 要件と計画に対する差分の過不足を確認する
2. 正しさ、保守性、セキュリティ、規約の観点で指摘する
3. 指摘ごとに対応、反証、または承認済み例外を残す
4. コード変更後は検証へ戻し、更新証拠を確認して承認する

期待成果物

• docs/workflow/review-report.md
• 指摘、重要度、根拠、対応結果、承認者

終了条件

• ブロッキング指摘が解消され、変更後の検証証拠が更新されている
• 判断と対応履歴が記録され、リリース承認がある

失敗時の戻り先

• コード指摘は実装へ戻し、検証後に再レビューする
• 設計欠陥は計画へ、必要に応じて調査・要件理解まで戻る
• 検証証拠が古い、または不足している場合は検証へ戻る

Before / After

Before: 従来のやり方

• コードを書き終えたら自己申告で「完了」
• レビューなしでコミット・マージ
• バグや設計問題が本番環境で発覚
• セキュリティ脆弱性の見逃し

After: ツール活用後

• 専用レビューエージェントがコードを体系的に評価
• Critical / Important / Suggestion の重大度別に問題を分類
• セキュリティレビューとコード品質レビューが独立して実行
• 要件との合致が仕様レベルで検証

レベル別アプローチ

Beginner

Level 1 プレイブック

入力例

差分: 現在の git diff
要件: docs/workflow/requirements.md
検証: docs/workflow/test-evidence.md

コマンド / プロンプト

claude

実装者の説明を前提にせず差分をレビューしてください。要件との一致、
正しさ、保守性、セキュリティ、規約を確認し、根拠・影響・対応を
docs/workflow/review-report.md に保存してください。

生成物例

# レビュー報告
## ブロッキング指摘
なし。
## 検証証拠
docs/workflow/test-evidence.md を確認。
## 判断
リリース可能。

検証

test -s docs/workflow/review-report.md
rg -n 'ブロッキング指摘|検証証拠|判断' docs/workflow/review-report.md
git diff --check

出口判定

• ブロッキング指摘がなく、変更後の検証証拠が最新である
• 判断と根拠が記録され、リリース承認がある

Claude Code の /review コマンドと基本的なプロンプトでレビュー。

# Claude Code 組み込みのレビュー
Claude Code > /review

# 基本的なレビュープロンプト
Claude Code > 以下の観点でコードをレビューして:
              1. バグの有無
              2. セキュリティ問題
              3. パフォーマンス
              4. 可読性

# PR コメントの確認
Claude Code > /pr_comments

手順:

1. /review でコードレビューを要求
2. 指摘事項を確認し、Critical から順に対応
3. /pr_comments で PR のコメントを確認
4. 対応結果をコミット

Intermediate

Superpowers の requesting/receiving-code-review と OMC の code-reviewer エージェントを活用。

# Superpowers: requesting-code-review
# code-reviewer サブエージェントをディスパッチ
# セッション履歴ではなく、精密に作成されたコンテキストを提供
# Critical → 即時修正, Important → 進行前修正, Minor → 後で

# Superpowers: receiving-code-review
# 6ステップ応答パターン: READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
# 禁止: 「おっしゃる通り！」「素晴らしいポイント！」などの表面的同意
# YAGNI チェック: 「プロフェッショナル」な機能提案に反論

# OMC: code-reviewer エージェント
> この PR をレビューして
# opus で品質・セキュリティ・保守性を包括的にレビュー

# OMC: security-reviewer エージェント
> セキュリティの観点でレビューして
# 信頼境界と脆弱性の分析

手順:

1. Superpowers requesting-code-review でレビューを要求
2. レビュー結果を受信し、Superpowers receiving-code-review の6ステップで対応
3. OMC security-reviewer でセキュリティ特化レビューを実施
4. Critical / Important の指摘を即座に修正

Advanced

OMC ccg（クロスモデルレビュー）と ECC の品質ゲートで多角的にレビュー。

# OMC: ccg（トリモデルアドバイザー）
/ccg この PR をレビューして
# Codex → アーキテクチャレビュー
# Gemini → UI/デザインレビュー
# Claude → 統合シンセシス

# ECC: quality-gate
/quality-gate
# 品質ゲートチェックをリポジトリ全体または特定パスに実行

# ECC: code-review コマンド
/code-review
# 品質とセキュリティの包括的レビュー

# ECC: security-scan
/security-scan
# AgentShield セキュリティ監査（1282テスト、102静的分析ルール）

# OMC: visual-verdict
/oh-my-claudecode:visual-verdict
# UI変更の構造化された視覚的 QA 評決

手順:

1. OMC ccg で Codex/Gemini/Claude の3モデルでクロスレビュー
2. ECC quality-gate で自動品質ゲートを通過
3. ECC security-scan で設定ファイルのセキュリティ監査
4. OMC visual-verdict で UI 変更の視覚的検証
5. 全レビュー結果を統合して最終判定

ベストプラクティス

1. 実装とレビューを分離 -- 同じコンテキストで実装とレビューを行うと盲点が生じる。Superpowers はサブエージェントに新鮮なコンテキストを与えてレビューさせる
2. 表面的同意を禁止 -- 「おっしゃる通り！」で済ませず、技術的に検証してから対応する。Superpowers receiving-code-review は6ステップの構造化対応を強制
3. 重大度別に対応 -- Critical は即時、Important は次ステップへ進む前、Minor は後で。Superpowers の分類基準に従う
4. セキュリティレビューは独立して -- コード品質レビューとは別に、セキュリティ特化のレビューを行う。OMC security-reviewer や ECC security-scan を活用
5. YAGNI チェック -- レビューでの「プロフェッショナル」な機能提案に注意。本当に必要か確認し、不要なら反論する
6. 証拠ベースで確認 -- 完了宣言の前に必ず検証コマンドを実行して結果を確認。Superpowers verification-before-completion の IDENTIFY → RUN → READ → VERIFY → THEN claim フロー

よくある罠

自己承認（Same-Context Review）

実装した自分と同じコンテキストでレビューすると、実装時の前提をそのまま受け入れてしまう。必ず別コンテキスト（サブエージェント等）でレビューする。

レビュー指摘の表面的な対応

指摘されたコードを機械的に修正するだけでなく、なぜ指摘されたかを理解する。Superpowers receiving-code-review の VERIFY → EVALUATE ステップで技術的に評価する。

Critical 指摘の後回し

「動いているから後で直す」は危険。Critical 指摘は即座に対応し、Important は次に進む前に対応する。

セキュリティレビューの省略

「小さな変更だから大丈夫」とセキュリティレビューを省略すると、認証 bypass やインジェクション脆弱性を見逃す。ECC の AgentShield は設定ファイルレベルで自動検出する。

レビュー結果の記録不足

レビューで指摘された問題と対応結果を記録しないと、同じ問題が再発する。OMC project memory や CLAUDE.md に記録する。