deliberation-debate-red-teaming

熟慮、ディベート、レッドチーム演習

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Deliberation & Red Teaming Progress:
- [ ] Step 1: Define the proposal and stakes
- [ ] Step 2: Assign adversarial roles
- [ ] Step 3: Generate critiques and challenges
- [ ] Step 4: Synthesize findings and prioritize risks
- [ ] Step 5: Recommend mitigations and revisions

ステップ 1：提案と重要性を定義する

評価する計画／決定（曖昧なアイデアではなく、具体的な提案）、重要性（失敗した場合に何が起きるか）、現在の確信度（どの程度確信しているか）、期限（いつまでに決定する必要があるか）をユーザーに尋ねます。重要性を理解することで、批判の強さを調整できます。範囲を定めるための質問を参照してください。

ステップ 2：敵対的な役割を割り当てる

盲点を明らかにできる、批判的な視点を特定します。提案の種類に応じて、3～5 個の役割（セキュリティ、法務、運用、顧客、競合他社など）を選びます。それぞれの役割には、異なる動機や懸念があります。敵対的な役割の種類と、役割の割り当て方について説明したresources/template.mdを参照してください。

ステップ 3：批判と課題を生成する

各役割の観点から、具体的な批判を生成します。何が問題になる可能性があるか？疑わしい前提は何か？どのようなエッジケースで破綻するか？敵対的でありながらも現実的な批判にしてください（藁人形論法ではなく、最も強力な反論を組み立てます）。高度な批判手法については、レッドチームの攻撃パターンを解説したresources/methodology.mdを参照してください。

ステップ 4：調査結果を統合し、リスクに優先順位を付ける

すべての批判を集め、テーマ（セキュリティ上の不備、運用リスク、顧客への影響など）を特定し、各リスクの重大度と発生可能性を評価します。致命的な問題（必ず修正する必要があるもの）と、許容可能なリスク（監視／軽減するもの）を区別します。リスクの優先順位付けを参照してください。

ステップ 5：軽減策と修正を提案する

重大なリスクごとに、具体的な軽減策を提案します（計画を変更する、安全策を追加する、データをさらに収集する、または監視しながらリスクを受け入れる）。修正を反映した改訂版の提案を提示します。一般的なアプローチについては、軽減策のパターンを参照してください。

範囲を定めるための質問

提案を定義するには：

• 何を評価するのですか？（具体的に：「日付 Z にコホート Y へ機能 X を公開する」）
• 目標は何ですか？（なぜこれを実施するのですか？）
• この提案をしたのは誰ですか？（偏りを理解するのに役立ちます）

重要性を理解するには：

• 成功した場合、何が起きますか？（上振れ）
• 失敗した場合、何が起きますか？（下振れ、最悪のケース）
• これは元に戻せますか？（誤っていた場合、ロールバックできますか？）
• 遅延によるコストはどれくらいですか？（待つことによる機会費用）

批判の強さを調整するには：

• チームはどの程度確信していますか？（0～100％）
• すでにどのような分析が行われていますか？
• 内部ではどのような懸念が挙がっていますか？
• いつまでに決定する必要がありますか？（時間的なプレッシャーは、検証の厳密さに影響します）

敵対的な役割の種類

この特定の提案の盲点を明らかにする可能性が最も高い役割を、3～5 個選びます。

外部の敵対者の役割

競合他社：

• 「競合他社はこの決定をどう利用するでしょうか？」
• 「市場で相手に付け入る隙を与えるのは何でしょうか？」
• 有用な場面：戦略、製品の公開、価格決定

悪意ある行為者（セキュリティ）：

• 「攻撃者はこれをどう侵害するでしょうか？」
• 「一連の流れの中で最も弱い部分は何でしょうか？」
• 有用な場面：セキュリティアーキテクチャ、データの取り扱い、アクセス制御

規制当局／監査人：

• 「これによって、法律、規制、コンプライアンス要件に違反することはありませんか？」
• 「監査証跡に必要な文書のうち、不足しているものは何でしょうか？」
• 有用な場面：プライバシー、金融、医療、法務に関する事項

調査報道記者：

• 「これが公になった場合、何が問題に見えるでしょうか？」
• 「何を隠している、または開示していないのでしょうか？」
• 有用な場面：広報上慎重さが求められる決定、倫理、透明性

内部ステークホルダーの役割

運用／SRE：

• 「本番環境に影響しますか？ 維持できますか？」
• 「午前2時に障害が発生した場合の運用手順書はありますか？」
• 役立つ場面：技術的な変更、デプロイ、インフラストラクチャ

顧客／ユーザー：

• 「これは実際に問題を解決しますか？ それとも新たな不便を生みますか？」
• 「行動を変えるよう求められていますか？ その必要があるのはなぜですか？」
• 役立つ場面：製品機能、UX の変更、価格設定

財務／予算：

• 「隠れたコストは何ですか？ 3年間の TCO はいくらですか？」
• 「ROI は現実的ですか？ それとも楽観的な前提に基づいていますか？」
• 役立つ場面：投資、ベンダーの選定、リソース配分

法務／コンプライアンス：

• 「これによってどのような法的責任が生じますか？」
• 「契約や利用規約は明確ですか？ どのような紛争が起こり得ますか？」
• 役立つ場面：パートナーシップ、ライセンス、データ利用

エンジニアリング／技術：

• 「技術的に実現可能ですか？ 技術的負債はどの程度ですか？」
• 「複雑さを過小評価している点はありませんか？」
• 役立つ場面：アーキテクチャの決定、技術の選択、スケジュール

あえて反論する役割

悲観論者：

• 「最悪のシナリオは何ですか？」
• 「マーフィーの法則：起こり得ることは必ず起こります」
• 役立つ場面：リスク評価、緊急時対応計画

反対論者：

• 「逆が正しいとしたらどうでしょうか？」
• 「すべての前提に異議を唱える：市場調査が間違っていたとしたらどうでしょうか？」
• 役立つ場面：前提の検証、合意の妥当性確認

長期的視点を持つ人：

• 「1～3年後にどのような二次的影響が生じますか？」
• 「今日の問題を解決して、明日の危機を生み出していませんか？」
• 役立つ場面：戦略的な意思決定、アーキテクチャの選択

リスクの優先順位付け

批判を洗い出した後、深刻度と発生可能性に基づいて優先順位を付けます。

深刻度の尺度

重大（5）： 壊滅的な障害（データ侵害、規制当局からの罰金、事業停止） 高（4）： 大きな損害（大幅な収益減、顧客の大量離脱、評判の低下） 中（3）： 中程度の影響（遅延、予算超過、顧客からの苦情） 低（2）： 軽微な不便（まれな不具合、小さな非効率） ごく軽微（1）： 無視できる程度（見た目の問題、わずかな UX 上の不便）

発生可能性の尺度

非常に高い（5）： 実行した場合の発生確率が 80％超 高い（4）： 発生確率が 50～80％ あり得る（3）： 発生確率が 20～50％ 低い（2）： 発生確率が 5～20％ まれ（1）： 発生確率が 5％未満

リスクスコア = 深刻度 × 発生可能性

重大な阻害要因（スコア ≥ 15）： 先に進む前に必ず対処する必要があります 優先度高（スコア 10～14）： 対処するか、強力な緩和策を用意する必要があります 監視対象（スコア 5～9）： リスクを許容しつつ、緊急時対応策を用意します 許容（スコア < 5）： 認識したうえで先に進みます

リスクマトリクス

深刻度 ↓ / 発生可能性 →	まれ（1）	低い（2）	あり得る（3）	高い（4）	非常に高い（5）
重大（5）	5（監視対象）	10（優先度高）	15（重大な阻害要因）	20（重大な阻害要因）	25（重大な阻害要因）
高（4）	4（許容）	8（監視対象）	12（優先度高）	16（重大な阻害要因）	20（重大な阻害要因）
中（3）	3（許容）	6（監視対象）	9（監視対象）	12（優先度高）	15（重大な阻害要因）
低（2）	2（許容）	4（許容）	6（監視対象）	8（監視対象）	10（優先度高）
ごく軽微（1）	1（許容）	2（許容）	3（許容）	4（許容）	5（監視対象）

リスク軽減のパターン

特定したリスクごとに、軽減策を選択します。

1. 提案を見直す（計画を変更する）

• 設計やアプローチの欠陥を修正します
• 例：セキュリティリスク → リリース前に認証レイヤーを追加する

2. 安全策を追加する（発生可能性を下げる）

• リスクを防ぐための制御を実装します
• 例：運用リスク → 自動ロールバックと機能フラグを追加する

3. 影響範囲を縮小する（深刻度を下げる）

• 障害が発生した場合の範囲や影響を限定します
• 例：顧客リスク → まずユーザーの5％に段階的に展開する

4. 不測の事態に備える（障害に備える）

• 代替案を用意します
• 例：ベンダーリスク → 事前に代替サプライヤーを特定する

5. さらにデータを集める（不確実性を下げる）

• 決定を下す前に調査、プロトタイプ作成、テストを行います
• 例：仮定に関するリスク → 仮説を検証するために A/B テストを実施する

6. 受け入れて監視する（情報に基づくリスク）

• リスクを認識し、顕在化した場合に検知できるようアラートやメトリクスを設定します
• 例：発生確率の低い例外的なケース → エラー率を監視し、修正をすぐに適用できるよう準備する

7. 延期・中止する（リスクを完全に回避する）

• リスクが大きすぎて軽減できない場合は、先に進みません
• 例：法務上の重大なリスク → 法務レビューが完了するまで延期する

このスキルを使用しない場合

次の場合は、レッドチーミングを省略してください。

• 判断が些細でリスクが低い（かける労力に見合わない）
• 緊急性の高い事態（検討する時間がなく、ただちに行動する必要がある）
• すでに十分に検証されている（事前に徹底したレビューが済んでおり、レッドチームは重複になる）
• 合理的な代替案がない（実行可能な道筋が1つしかなく、レッドチームを行っても結果を変えられない）
• 純粋な調査・探索（何かを決定するわけではなく、失敗しても損失が小さい）

代わりに次のようにします。

• 些細な判断 → そのまま決定し、先に進みます
• 緊急事態 → ただちに行動し、後から振り返ります
• すでに検証済み → 監視しながら進めます
• 代替案がない → 実行計画に注力します

クイックリファレンス

プロセス：

1. 提案とリスクの大きさを定義する → 範囲を設定する
2. 敵対的な役割を割り当てる → 重要な視点を3～5つ選ぶ
3. 批判点を挙げる → 各役割の視点から何が問題になり得るかを考える
4. リスクに優先順位を付ける → 深刻度 × 発生可能性のマトリクスを使う
5. 軽減策を提案する → 見直し、安全策、不測の事態への備え、受け入れ、または中止

敵対的な役割の例：

• 競合他社、悪意のある行為者、規制当局、運用担当者、顧客、財務担当者、法務担当者、エンジニア、悲観論者、反対論者、長期的な視点を持つ人

リスクの優先順位付け：

• 重大な障害要因（≥15）：必ず修正する
• 優先度が高い（10-14）：対処すべき
• 監視対象（5-9）：不測の事態への備えを用意して受け入れる
• 受け入れ（<5）：認識する

リソース：

• resources/template.md - 役割テンプレートを含む、体系的なレッドチームプロセス
• resources/methodology.md - 高度な手法（アタックツリー、プレモーテム、ウォーゲーム）
• resources/evaluators/rubric_deliberation_debate_red_teaming.json - 品質チェックリスト

成果物： 批判点、リスク評価、軽減策の提案をまとめた deliberation-debate-red-teaming.md