wasabeef 複数ロールの議論でトレードオフを検討
異なる専門性を持つロールが議論し、トレードオフを検討して最適解を導出するコマンド。
使い方
/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
「マイクロサービス化の是非について」
議論の基本原則
建設的議論の心得
- 相互尊重: 他ロールの専門性と視点を尊重する
- 事実ベース: 感情的反論ではなく、データ・根拠に基づく議論
- 解決志向: 批判のための批判ではなく、より良い解決策を目指す
- 実装重視: 理想論ではなく実現可能性を考慮した提案
論拠の質的要件
- 公式文書: 標準・ガイドライン・公式ドキュメントへの言及
- 実証事例: 成功事例・失敗事例の具体的引用
- 定量評価: 可能な限り数値・指標での比較
- 時系列考慮: 短期・中期・長期での影響評価
議論倫理
- 誠実性: 自身の専門分野の限界も認める
- 開放性: 新しい情報・視点に対する柔軟性
- 透明性: 判断根拠・前提条件の明示
- 責任性: 提案の実装リスクも含めて言及
議論プロセス
Phase 1: 初期立場表明
各ロールが専門視点から独立して意見表明
- 推奨案の提示
- 根拠となる標準・文書の明示
- 想定されるリスク・課題の説明
- 成功指標の定義
Phase 2: 相互議論・反駁
ロール間でのクロス議論
- 他ロール提案への建設的反論
- 見落とされた視点の指摘
- トレードオフの明確化
- 代替案の提示
Phase 3: 妥協点探索
実装可能な解決策の模索
- 各視点の重要度評価
- Win-Win 解決策の検討
- 段階的実装アプローチ
- リスク軽減策の検討
Phase 4: 統合結論
最終的な推奨事項の決定
- 合意された解決策
- 実装ロードマップ
- 成功指標・測定方法
- 将来の見直しポイント
出力フォーマット例
2 ロール議論の場合
ロール議論: 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 ヶ月後: より洗練されたリスクベース認証への移行検討
3 ロール議論の場合
ロール議論: 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 データ保護レベル」
ロール別議論特性
🔒 Security ロール
議論スタンス:
- 保守的アプローチ (リスク最小化)
- 規則準拠重視 (標準からの逸脱に慎重)
- 最悪ケース想定 (攻撃者視点)
- 長期的影響重視 (技術的負債としてのセキュリティ)
典型的論点:
- "セキュリティ vs 利便性" のトレードオフ
- "コンプライアンス要件の必達"
- "攻撃コスト vs 防御コストの比較"
- "プライバシー保護の徹底"
論拠ソース:
- OWASP ガイドライン
- NIST フレームワーク
- 業界標準 (ISO 27001, SOC 2)
- 実際の攻撃事例・統計
議論での強み:
- リスク評価の精度
- 規制要件の知識
- 攻撃手法への理解
注意すべき偏見:
- 過度な保守性 (イノベーション阻害)
- UX への配慮不足
- 実装コストの軽視
⚡ Performance ロール
議論スタンス:
- データ駆動判断 (測定ベース)
- 効率性重視 (コスト対効果の最適化)
- ユーザー体験優先 (体感速度重視)
- 継続的改善 (段階的最適化)
典型的論点:
- "パフォーマンス vs セキュリティ"
- "最適化コスト vs 効果の投資対効果"
- "現在 vs 将来のスケーラビリティ"
- "ユーザー体験 vs システム効率"
論拠ソース:
- Core Web Vitals メトリクス
- ベンチマーク結果・統計
- ユーザー行動への影響データ
- 業界パフォーマンス標準
議論での強み:
- 定量的評価能力
- ボトルネック特定
- 最適化手法の知識
注意すべき偏見:
- セキュリティの軽視
- 保守性への配慮不足
- プレマチュアオプティマイゼーション
🏗️ Architect ロール
議論スタンス:
- 長期視点重視 (システム進化への配慮)
- バランス追求 (全体最適)
- 段階的変更 (リスク管理)
- 標準準拠 (実証済みパターン優先)
典型的論点:
- "短期効率 vs 長期保守性"
- "技術的負債 vs 開発速度"
- "マイクロサービス vs モノリス"
- "新技術採用 vs 安定性"
論拠ソース:
- アーキテクチャパターン集
- 設計原則 (SOLID, DDD)
- 大規模システム事例
- 技術進化のトレンド
議論での強み:
- 全体俯瞰能力
- 設計パターンの知識
- 長期影響の予測
注意すべき偏見:
- 過度な一般化
- 新技術への保守性
- 実装詳細への理解不足
🎨 Frontend ロール
議論スタンス:
- ユーザー中心設計 (UX 最優先)
- 包摂的アプローチ (多様性配慮)
- 直感性重視 (学習コスト最小化)
- アクセシビリティ標準 (WCAG 準拠)
典型的論点:
- "ユーザビリティ vs セキュリティ"
- "デザイン統一 vs プラットフォーム最適化"
- "機能性 vs シンプルさ"
- "パフォーマンス vs リッチな体験"
論拠ソース:
- UX 研究・ユーザビリティテスト結果
- アクセシビリティガイドライン
- デザインシステム標準
- ユーザー行動データ
議論での強み:
- ユーザー視点の代弁
- デザイン原則の知識
- アクセシビリティ要件
注意すべき偏見:
- 技術制約への理解不足
- セキュリティ要件の軽視
- パフォーマンス影響の過小評価
📱 Mobile ロール
議論スタンス:
- プラットフォーム特化 (iOS/Android 差異考慮)
- コンテキスト適応 (移動中・片手操作)
- リソース制約 (バッテリー・メモリ・通信)
- ストア準拠 (審査ガイドライン)
典型的論点:
- "ネイティブ vs クロスプラットフォーム"
- "オフライン対応 vs リアルタイム同期"
- "バッテリー効率 vs 機能性"
- "プラットフォーム統一 vs 最適化"
論拠ソース:
- iOS HIG / Android Material Design
- App Store / Google Play ガイドライン
- モバイル UX 研究
- デバイス性能統計
議論での強み:
- モバイル特有制約の理解
- プラットフォーム差異の知識
- タッチインターフェース設計
注意すべき偏見:
- Web プラットフォームへの理解不足
- サーバーサイド制約の軽視
- デスクトップ環境への配慮不足
🔍 Analyzer ロール
議論スタンス:
- 証拠重視 (データファースト)
- 仮説検証 (科学的アプローチ)
- 構造的思考 (システム思考)
- バイアス除去 (客観性追求)
典型的論点:
- "相関関係 vs 因果関係"
- "症状対症療法 vs 根本解決"
- "仮説 vs 事実の区別"
- "短期症状 vs 構造的問題"
論拠ソース:
- 実測データ・ログ分析
- 統計的手法・分析結果
- システム思考理論
- 認知バイアス研究
議論での強み:
- 論理的分析能力
- 証拠評価の客観性
- 構造的問題の発見
注意すべき偏見:
- 分析麻痺 (行動力不足)
- 完璧主義 (実用性軽視)
- データ万能主義
議論進行テンプレート
Phase 1: 立場表明テンプレート
【ロール名】の推奨案:
「[具体的な提案]」
根拠:
- [公式文書・標準への言及]
- [実証事例・データ]
- [専門分野の原則]
想定効果:
- [短期的効果]
- [中長期的効果]
懸念・リスク:
- [実装リスク]
- [運用リスク]
- [他分野への影響]
成功指標:
- [測定可能な指標 1]
- [測定可能な指標 2]
Phase 2: 反駁テンプレート
[対象ロール] への反論:
「[対象提案への具体的反論]」
反論根拠:
- [見落とされた視点]
- [対立する証拠・事例]
- [専門分野からの懸念]
代替案:
「[改良された提案]」
妥協可能ポイント:
- [受け入れ可能な条件]
- [段階的実装の可能性]
Phase 3: 統合解決テンプレート
統合解決案:
「[各ロールの懸念を考慮した最終提案]」
各ロールへの配慮:
- [Security]: [セキュリティ要件の満足方法]
- [Performance]: [パフォーマンス要件の満足方法]
- [その他]: [その他要件の満足方法]
実装ロードマップ:
- フェーズ 1 (即座): [緊急対応事項]
- フェーズ 2 (短期): [基本実装]
- フェーズ 3 (中期): [完全実装]
成功指標・測定方法:
- [統合的な成功指標]
- [測定方法・頻度]
- [見直しタイミング]
議論品質チェックリスト
論拠の質
- 公式文書・標準への言及がある
- 具体的な事例・データが提示されている
- 推測と事実が明確に区別されている
- 情報源が明示されている
議論の建設性
- 相手の提案を正確に理解している
- 感情的でなく論理的な反論
- 代替案も提示している
- Win-Win の可能性を探っている
実装可能性
- 技術的実現可能性を考慮
- 実装コスト・期間を見積もり
- 段階的実装の可能性を検討
- リスク軽減策を提示
統合性
- 他分野への影響を考慮
- 全体最適を追求
- 長期的視点を含む
- 測定可能な成功指標を設定
Claude との連携
# 設計文書を元にした議論
cat system-design.md
/role-debate architect,security
「この設計のセキュリティ面での課題を議論して」
# 問題を元にした解決策議論
cat performance-issues.md
/role-debate performance,architect
「パフォーマンス問題の根本的解決策を議論して」
# 要件を元にした技術選定議論
/role-debate mobile,frontend
「iOS ・Android ・Web の統一 UI 戦略について議論して」
注意事項
- 議論は時間がかかる場合があります (複雑なトピックほど長時間)
- 3 つ以上のロールでは議論が発散する可能性があります
- 最終判断は議論結果を参考にユーザーが行ってください
- 緊急性の高い問題では single role や multi-role を先に検討してください