ディシジョン・カウンシル（Decision Council）
このスキルが解決する問題
エージェントに「これはなぜ良いアイデアなのか？」と尋ねると、説得力のある賛成論が返ってきます。「これはなぜ悪いアイデアなのか？」と尋ねると、同様に説得力のある反対論が返ってきます。どちらも流暢ですが、どちらも判断ではありません。単一のエージェントは、正しい答えではなく、一貫性のある答えを最適化するため、 Advisor として不十分です。
このスキルは、複数の独立した視点を実行し、それらを互いに誰が書いたかわからないエージェントにレビューさせ、最終的に1つの判断を生成します。
実行すべきタイミング
実際にトレードオフが存在し、コストがかかる分岐点：構築 vs 購入、出荷 vs 保留、価格変更、機能が時期尚早かどうか、次に何に取り組むか。既に答えが分かっている質問には使用しません。
手順
1. 決定事項を正確に述べる
実際の選択肢が含まれた1文で記述します。そのように述べられない場合、その決定はまだレビューするほど明確ではありません。まずそれを修正してください。
実際に分かっていることを収集します：制約、既に試したこと、取り戻しが効くかどうか、取り戻せないかどうか。
2. カウンシルを立ち上げる — 並行して、独立して
5人のエージェント。それぞれが真に異なる視点を持ちます。互いの回答を見てはいけません。
| ペルソナ | 役割 |
|---|---|
| 批判者 | これが失敗すると仮定する。何がそれを潰したのか？ |
| 楽観主義者 | これが成功すると仮定する。過小評価されているどのような可能性を引き出したのか？ |
| 運用担当者 | 誰が作業を行うのか、何が壊れるのか、ユーザーの時間における本当のコストは何か？ |
| 顧客 | 実際に支払う人は気にするのか？気づくだろうか？ |
| 会計担当 | これにはどれだけコストがかかるか、何がリターンか、機会費用は何か？ |
各ペルソナは以下を返します：推奨事項、その根拠、そして考えを変えるであろう1つの事実。
決定内容に応じてペルソナを入れ替えます——コンプライアンスの分岐点には規制の視点を、アーキテクチャの分岐点にはセキュリティの視点を。レンズは真に異なるものを維持してください。
3. ピアレビュー、ブラインドで
属性情報を削除し、シャッフルします。匿名化されたセットを新たなレビュー担当者に渡します。各担当者に尋ねます：どの議論が最も強力か、どの議論が最も弱いか、そして全員が見逃したものは何か？
ブラインド化は重要です——これにより、レビューが最も権威のあるペルソナに追随するのを防ぎます。
4. 議長
最後の1人のエージェントが、視点とレビューを読み、以下を返します：
## 決定: <質問>
**評決:** <判断、1文で>
**確信度:** <高 | 中 | 低> — <理由>
**決定を支えた論拠:** <2〜3文>
**最も強い反対論:** <公平に述べること — 藁人形論法にしない>
**これを変えるもの:** <答えを覆す特定の事実またはイベント>
**進める場合:** <最初の具体的なステップ>
5. 正直に報告する
カウンシルが分裂した場合、分裂したと述べること。 強制された合意は、生の意見の不一致よりも悪いものです。ほとんどの人は、本当の緊張関係を見て、自分で判断を下すことを望みます。
決断力があるように見せるために、合意をでっち上げてはいけません。
規模の調整
5人のペルソナがデフォルトです。小さな決定には3人、高コストまたは元に戻すのが難しい決定には7人。より多くのペルソナは、レンズが真に異なる場合にのみ役立ちます——5つの異なる角度が、9つの重複する角度より優れています。
クレジット
複数ペルソナ＋ブラインドレビュー＋議長のパターンは、Remy Gaskell の Open Residency におけるエージェントオペレーティングシステムに関するエピソードを経由して、Ollie Leman によるものです。