devils-advocate

Devil's Advocate Protocol

早期の選択肢固定を防ぎ、見落としを明らかにするための、事前コミットメント型の敵対的推論です。

適用するタイミング

次の場合にこのプロトコルを有効にします。

• アーキテクチャのアプローチを選択するとき
• ライブラリ、フレームワーク、ツールを選ぶとき
• 実装戦略を計画するとき
• 複数の選択肢から一つのアプローチを推奨するとき
• ユーザーが「〜すべきですか？」「〜する最善の方法は？」「どのアプローチがよいですか？」と尋ねたとき
• architect、Plan、blueprint のワークフロー中
• 答えが明白でないトレードオフの判断を行うとき

適用しないタイミング

次の場合は適用しないでください。

• すでに決定済みの実装を実行するとき
• 明白な方法が一つしかないとき（実質的な代替案がない場合）
• ユーザーがアプローチを明示的に選択しているとき（「YをするためにXを使ってください」）
• タスクが意思決定を伴わない機械的または手順的なもののとき
• 影響がごくわずかな些細な選択のとき

プロトコル

ステップ1：決定事項を特定する

アプローチを推奨する前に、次の点を明示します。

• どのような決定を行うのか
• どのアプローチに傾いているのか
• なぜそのアプローチに惹かれているのか

ステップ2：反対意見を最も強い形で提示する

自分の傾向に真っ向から反対する最も強力な論拠を示します。

• 何がうまくいかない可能性があるか？
• 誤っているかもしれない、どのような前提を置いているか？
• 批判的な視点を持つ人なら何を指摘するか？
• 機会費用は何か？
• どのような条件で失敗するか？

要件：

• 表面的な反論ではなく、真に敵対的な観点から検討する
• 自分の主張の最も強い形を批判する
• 少なくとも一つ、直感では気づきにくい失敗モードを含める

ステップ3：擁護するか、方針を転換する

敵対的な検討の後に、次のことを行います。

• 反論があっても、そのアプローチが依然として正しい可能性がある理由を説明する
• どのような条件でそれが適切な選択となるかを示す
• 代替案が優位になるには、何が真である必要があるかを示す
• または、反論によって推奨が変わったことを認める

ステップ4：確信度を適切に示して提示する

最終的な推奨には、次の内容を含めます。

• 理由を添えた明確な推奨
• 成立しなければならない主要な前提
• この選択が無効になる条件
• 注視すべき兆候

出力形式

## Decision: [What's being decided]

### Initial Inclination
[Approach] because [reasons]

### Adversarial Challenge
**Against this approach:**
- [Strong objection 1]
- [Strong objection 2]
- [Non-obvious failure mode]

**What I might be wrong about:**
- [Assumption that could be false]

### Resolution
[Why it's still correct OR why I'm changing recommendation]

### Recommendation: [Final choice]
- **Key assumptions:** [What must be true]
- **Watch for:** [Signals this was wrong]

他のツールとの関係

• reasoning-verifier：完了した推論を事後検証します。重大または大きな問題がなくなるまで再実行する反復ゲート（最大3回）を含みます。
• devils-advocate：推論が固まる前に、事前コミットメントに異議を唱えます。
• 両方を使用する場合：計画中に devils-advocate を使い、実行後に reasoning-verifier を使います。
• 確信度を段階的に高めるには、devils-advocate を1回実行し、その出力を reasoning-verifier に渡して、問題を解消する反復を行います。

基本原則

LLMは早い段階で答えを決め、その後に遡って正当化します。このプロトコルは、解決策が確定する前に選択肢を検討させることで、そのパターンを中断します。