背景
Claude Codeのレビュー系コマンド（/code-review・/simplify・/security-review・/verify）を実践するハンズオンで、それぞれのコマンドが担う役割が明確に分業されている点が印象的でした。特に/code-reviewの努力レベル指定と、/simplifyが内部で4エージェント並列動作する仕組みを整理します。
1. /code-reviewは努力レベルでレビューの深さを調整できる
/code-review --effort low # 高確度な指摘のみ・少数
/code-review --effort medium # バランス型（デフォルト）
/code-review --effort high # 広範囲の指摘
/code-review --effort max # 最大範囲（時間がかかる）
/code-review --effort ultra # クラウドで深い多エージェントレビュー
日常的なコミット前チェックはmedium（デフォルト）で十分ですが、ultraはクラウド上の複数エージェントが協力してレビューするため最も深い分析ができる一方、$5〜$25程度のコストがかかります。重要なコアロジックや大型リリース前など、使う場面を絞るのが実務上のコツです。
2. /simplifyは4つの専門エージェントが並列で同時にチェックする
再利用チェック → コードベース内の既存ヘルパー・重複コードの見落とし
簡潔化 → 不要な複雑さ・より単純に書ける箇所
効率性 → パフォーマンス最適化の機会
抽象化レベル → 変更が適切なレイヤーに存在しているか
/simplifyはバグを探すことを目的とせず、「動いているコードをより良いコードに」磨き上げることに特化しています。4つの観点を同時に処理するため、単一のレビューでは見落としがちな問題も検出しやすく、チェック後はそのまま修正が自動適用されます。
3. /code-reviewと/simplifyの実行順序は厳格に「バグ検出が先」
❌ /simplify を先に実行 → バグが潜んだままきれいなコードになる
✅ /code-review → /simplify の順
/simplifyはバグを探さない設計のため、バグが残ったコードに適用しても問題は解決しません。必ず/code-reviewでバグを検出・修正してから/simplifyで磨き上げる、という順序を守る必要があります。
4. /security-reviewは自動修正を行わない設計
/code-review: --fix オプションで自動修正可能
/security-review: レポートのみ、コードの自動修正はしない
セキュリティ上の修正は必ず人間が内容を理解した上で行うべき、という設計思想のもと、/security-reviewはSQLインジェクション・XSS・機密情報漏洩などを検出して報告するだけに留まります。検出内容は一つずつ確認してから手動で修正します。
5. /verifyは静的解析ではなく実際にアプリを起動して確認する
テストは通過している
→ が、環境変数の問題・複数コンポーネント統合時のエラー・UIの見た目は
静的解析では検出できない
→ /verify が実際にアプリを起動して確認する
/verifyは他の3コマンドと性質が異なり、コードを静的に分析するのではなく実際にアプリケーションを動かして動作確認します。テストが全件パスしていても実際に動かすと問題が発覚するケースに対応する、最後の砦としての役割です。
まとめ
努力レベルによる/code-reviewのコスト・精度トレードオフと、/simplifyの4エージェント並列動作、そして「バグ検出が必ず先」という実行順序の原則が、このレビュー自動化フローの核心でした。/security-reviewが自動修正しない設計思想も含め、それぞれのコマンドの役割分担を理解すると使い分けに迷わなくなります。