異なる専門性を持つロールが議論し、トレードオフを検討して最適解を導出するコマンド。
Facilitates multi-role debates to explore trade-offs and derive optimal solutions.
/plugin marketplace add wasabeef/claude-code-cookbook/plugin install cook@claude-code-cookbook異なる専門性を持つロールが議論し、トレードオフを検討して最適解を導出するコマンド。
/role-debate <ロール 1>,<ロール 2> [議題]
/role-debate <ロール 1>,<ロール 2>,<ロール 3> [議題]
# セキュリティ vs パフォーマンスのトレードオフ
/role-debate security,performance
「JWT トークンの有効期限設定について」
# ユーザビリティ vs セキュリティのバランス
/role-debate frontend,security
「2 段階認証の UX 最適化について」
# 技術選定の議論
/role-debate architect,mobile
「クロスプラットフォーム vs ネイティブ開発の選択について」
# 3 者議論
/role-debate architect,security,performance
「マイクロサービス化の是非について」
各ロールが専門視点から独立して意見表明
ロール間でのクロス議論
実装可能な解決策の模索
最終的な推奨事項の決定
ロール議論: Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
議題: JWT トークンの有効期限設定
Security ロールの主張:
「15 分の短期有効期限を推奨します」
根拠:
- OWASP JWT Security Cheat Sheet 準拠
- トークン漏洩時の被害時間窓を最小化
- 攻撃者の利用可能時間を制限
懸念事項:
- 長期有効期限は攻撃リスクが指数関数的に増大
- コンプライアンス要件 (金融系) では短期が必須
成功指標:
- セキュリティインシデント発生率 < 0.1%
- 平均攻撃検出時間 < 5 分
Performance ロールの反論:
「2 時間の有効期限を推奨します」
根拠:
- Google OAuth 2.0 Best Practices 参考
- 頻繁な再認証によるサーバー負荷増大を回避
- ユーザー体験 (作業中断) の最小化
懸念事項:
- 15 分間隔の再認証は API 負荷 8 倍増
- モバイル環境での接続断が頻発
成功指標:
- API レスポンス時間 < 200ms 維持
- サーバー CPU 使用率 < 60%
相互議論:
Security → Performance:
「サーバー負荷よりもセキュリティ侵害のビジネス損失の方が甚大。
例: Equifax 事件では 7 億ドルの損失」
Performance → Security:
「リフレッシュトークン機構で両立可能。
バックグラウンド更新により UX を損なわずセキュリティ確保」
Security → Performance:
「リフレッシュトークンも攻撃対象。適切な実装が前提」
Performance → Security:
「段階的アプローチを提案。通常操作 30 分、機密操作 15 分」
妥協点探索:
共通理解:
- ユーザー体験とセキュリティの両立が必要
- リスクレベルに応じた柔軟な対応
- 実装・運用コストの現実的考慮
Win-Win 要素:
- リフレッシュトークン機構の活用
- リスクベース認証の段階的導入
- 自動ログアウト機能による補完
統合結論:
「30 分有効期限 + リフレッシュトークン + リスクベース認証」
実装詳細:
1. アクセストークン: 30 分有効期限
2. リフレッシュトークン: 7 日有効期限
3. 高リスク操作: 15 分で強制再認証
4. 無操作 30 分で自動ログアウト
段階的実装:
週 1-2: 基本的な 30 分トークン実装
週 3-4: リフレッシュトークン機構追加
月 2: リスクベース認証の導入
成功指標:
- セキュリティ: インシデント発生率 < 0.1%
- パフォーマンス: API 負荷増加率 < 20%
- UX: ユーザー満足度 > 85%
将来の見直し:
- 3 ヶ月後: 実際の攻撃パターン・負荷状況を評価
- 6 ヶ月後: より洗練されたリスクベース認証への移行検討
ロール議論: Architect vs Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
議題: マイクロサービス化の是非
Architect ロールの主張:
「段階的マイクロサービス化を推奨」
根拠: ドメイン境界の明確化、独立したデプロイ、技術選択の自由度
Security ロールの懸念:
「サービス間通信のセキュリティ複雑化」
根拠: API Gateway、mTLS、分散認証の管理コスト
Performance ロールの懸念:
「ネットワーク通信によるレイテンシ増加」
根拠: 内部 API 呼び出しによる N+1 問題、分散トランザクション
3 者議論:
Architect → Security: 「API Gateway で集中管理により統制可能」
Security → Architect: 「単一障害点となるリスク」
Performance → Architect: 「サービス分割の粒度が重要」
...(議論継続)
統合結論:
「ドメイン駆動設計による段階的分割 + セキュリティファースト設計」
/role-debate architect,performance
「データベース選択: PostgreSQL vs MongoDB」
/role-debate frontend,mobile
「UI フレームワーク: React vs Vue」
/role-debate security,architect
「認証方式: JWT vs Session Cookie」
/role-debate security,frontend
「ユーザー認証の UX 設計」
/role-debate performance,mobile
「データ同期戦略の最適化」
/role-debate architect,qa
「テスト戦略とアーキテクチャ設計」
/role-debate security,performance
「暗号化レベル vs 処理速度」
/role-debate frontend,performance
「リッチ UI vs ページ読み込み速度」
/role-debate mobile,security
「利便性 vs データ保護レベル」
議論スタンス:
- 保守的アプローチ (リスク最小化)
- 規則準拠重視 (標準からの逸脱に慎重)
- 最悪ケース想定 (攻撃者視点)
- 長期的影響重視 (技術的負債としてのセキュリティ)
典型的論点:
- "セキュリティ vs 利便性" のトレードオフ
- "コンプライアンス要件の必達"
- "攻撃コスト vs 防御コストの比較"
- "プライバシー保護の徹底"
論拠ソース:
- OWASP ガイドライン
- NIST フレームワーク
- 業界標準 (ISO 27001, SOC 2)
- 実際の攻撃事例・統計
議論での強み:
- リスク評価の精度
- 規制要件の知識
- 攻撃手法への理解
注意すべき偏見:
- 過度な保守性 (イノベーション阻害)
- UX への配慮不足
- 実装コストの軽視
議論スタンス:
- データ駆動判断 (測定ベース)
- 効率性重視 (コスト対効果の最適化)
- ユーザー体験優先 (体感速度重視)
- 継続的改善 (段階的最適化)
典型的論点:
- "パフォーマンス vs セキュリティ"
- "最適化コスト vs 効果の投資対効果"
- "現在 vs 将来のスケーラビリティ"
- "ユーザー体験 vs システム効率"
論拠ソース:
- Core Web Vitals メトリクス
- ベンチマーク結果・統計
- ユーザー行動への影響データ
- 業界パフォーマンス標準
議論での強み:
- 定量的評価能力
- ボトルネック特定
- 最適化手法の知識
注意すべき偏見:
- セキュリティの軽視
- 保守性への配慮不足
- プレマチュアオプティマイゼーション
議論スタンス:
- 長期視点重視 (システム進化への配慮)
- バランス追求 (全体最適)
- 段階的変更 (リスク管理)
- 標準準拠 (実証済みパターン優先)
典型的論点:
- "短期効率 vs 長期保守性"
- "技術的負債 vs 開発速度"
- "マイクロサービス vs モノリス"
- "新技術採用 vs 安定性"
論拠ソース:
- アーキテクチャパターン集
- 設計原則 (SOLID, DDD)
- 大規模システム事例
- 技術進化のトレンド
議論での強み:
- 全体俯瞰能力
- 設計パターンの知識
- 長期影響の予測
注意すべき偏見:
- 過度な一般化
- 新技術への保守性
- 実装詳細への理解不足
議論スタンス:
- ユーザー中心設計 (UX 最優先)
- 包摂的アプローチ (多様性配慮)
- 直感性重視 (学習コスト最小化)
- アクセシビリティ標準 (WCAG 準拠)
典型的論点:
- "ユーザビリティ vs セキュリティ"
- "デザイン統一 vs プラットフォーム最適化"
- "機能性 vs シンプルさ"
- "パフォーマンス vs リッチな体験"
論拠ソース:
- UX 研究・ユーザビリティテスト結果
- アクセシビリティガイドライン
- デザインシステム標準
- ユーザー行動データ
議論での強み:
- ユーザー視点の代弁
- デザイン原則の知識
- アクセシビリティ要件
注意すべき偏見:
- 技術制約への理解不足
- セキュリティ要件の軽視
- パフォーマンス影響の過小評価
議論スタンス:
- プラットフォーム特化 (iOS/Android 差異考慮)
- コンテキスト適応 (移動中・片手操作)
- リソース制約 (バッテリー・メモリ・通信)
- ストア準拠 (審査ガイドライン)
典型的論点:
- "ネイティブ vs クロスプラットフォーム"
- "オフライン対応 vs リアルタイム同期"
- "バッテリー効率 vs 機能性"
- "プラットフォーム統一 vs 最適化"
論拠ソース:
- iOS HIG / Android Material Design
- App Store / Google Play ガイドライン
- モバイル UX 研究
- デバイス性能統計
議論での強み:
- モバイル特有制約の理解
- プラットフォーム差異の知識
- タッチインターフェース設計
注意すべき偏見:
- Web プラットフォームへの理解不足
- サーバーサイド制約の軽視
- デスクトップ環境への配慮不足
議論スタンス:
- 証拠重視 (データファースト)
- 仮説検証 (科学的アプローチ)
- 構造的思考 (システム思考)
- バイアス除去 (客観性追求)
典型的論点:
- "相関関係 vs 因果関係"
- "症状対症療法 vs 根本解決"
- "仮説 vs 事実の区別"
- "短期症状 vs 構造的問題"
論拠ソース:
- 実測データ・ログ分析
- 統計的手法・分析結果
- システム思考理論
- 認知バイアス研究
議論での強み:
- 論理的分析能力
- 証拠評価の客観性
- 構造的問題の発見
注意すべき偏見:
- 分析麻痺 (行動力不足)
- 完璧主義 (実用性軽視)
- データ万能主義
【ロール名】の推奨案:
「[具体的な提案]」
根拠:
- [公式文書・標準への言及]
- [実証事例・データ]
- [専門分野の原則]
想定効果:
- [短期的効果]
- [中長期的効果]
懸念・リスク:
- [実装リスク]
- [運用リスク]
- [他分野への影響]
成功指標:
- [測定可能な指標 1]
- [測定可能な指標 2]
[対象ロール] への反論:
「[対象提案への具体的反論]」
反論根拠:
- [見落とされた視点]
- [対立する証拠・事例]
- [専門分野からの懸念]
代替案:
「[改良された提案]」
妥協可能ポイント:
- [受け入れ可能な条件]
- [段階的実装の可能性]
統合解決案:
「[各ロールの懸念を考慮した最終提案]」
各ロールへの配慮:
- [Security]: [セキュリティ要件の満足方法]
- [Performance]: [パフォーマンス要件の満足方法]
- [その他]: [その他要件の満足方法]
実装ロードマップ:
- フェーズ 1 (即座): [緊急対応事項]
- フェーズ 2 (短期): [基本実装]
- フェーズ 3 (中期): [完全実装]
成功指標・測定方法:
- [統合的な成功指標]
- [測定方法・頻度]
- [見直しタイミング]
# 設計文書を元にした議論
cat system-design.md
/role-debate architect,security
「この設計のセキュリティ面での課題を議論して」
# 問題を元にした解決策議論
cat performance-issues.md
/role-debate performance,architect
「パフォーマンス問題の根本的解決策を議論して」
# 要件を元にした技術選定議論
/role-debate mobile,frontend
「iOS ・Android ・Web の統一 UI 戦略について議論して」