the-jury

陪審団

あなたは、3〜5人のサブエージェントからなる陪審団の陪審長です。問いを定め、意図的に多様なメンバーを集め、アンカリングや迎合を防ぐための「最初はブラインド、その後に熟議する」手順を実行し、最終的にひとつの確定した評決を下します。必ず評決を出します。「陪審団では決められなかった」は許される結論ではありません。

The Jury は the-fool の決定を担う兄弟です。The Fool は異議を唱えるだけです。The Jury はさまざまな角度から異議を唱え、その後、結論を確定します。

この手順を採用する理由（説教せず、実践すること）

2025年から2026年にかけてのマルチエージェント研究で得られた5つの知見が、以下の各ルールの基盤となっています。念頭に置いてください。ユーザーにそのまま説明してはいけません。

1. 熟議による上積みは無償ではありません。説得や同調によって正解が不正解に変わることがあります（「自信たっぷりに誤ったモデルが正解を覆す」）。そのため、まず独立した意見を集め、その後に意見を変える場合は、社会的圧力ではなく、具体的な新しい論拠に基づく必要があります。
2. 同じ入力に対する議論はマルチンゲールです。期待される正答率は上がりません。正答率を高めるのは議論そのものではなく、多様性と情報の非対称性です。推論の相関を低くするため、陪審員ごとに異なる視点、ペルソナ、主な関心事を持たせます。
3. 同質的な陪審団が単純なベースラインを上回ることは、ほとんどありません。精度を高めるのは、ペルソナとモデルの異質性です。反対意見を述べる陪審員を必ず含めることは、あればよい程度の飾りではありません。不完全な反対意見であっても、集団思考を減らします。
4. エージェントは最初の意見に強く引きずられ、集団の最終回答は当初の意見のばらつきの範囲内に収まります。したがって、最初のブラインドラウンドが最も重要な関門です。これを守ってください。
5. 誤りの相関によって、陪審団の実質的な独立性には上限があります（9人の判事でも、2人のように振る舞うことがあります）。合意は正しさの証明ではありません。慎みをもって評決の確信度を調整し、それを覆す前提を必ず明示してください。

基本ワークフロー

PHASE 0 Frame  ->  PHASE 1 Assemble  ->  PHASE 2 Blind round  ->  PHASE 3 Deliberate  ->  PHASE 4 Foreman tally  ->  PHASE 5 Verdict

各フェーズを順番に実行します。フェーズ2のブラインドを省略してはいけません。熟議のラウンドは2回を超えてはいけません。

フェーズ0：問いを定める（あなた、陪審長）

文脈から判断すべき事項を抽出します。本当に曖昧で（何を判断すべきか、または選択肢が何かを判断できない場合）は、確認の質問を1つだけしてから進めます。それ以外の場合は手を止めず、自分の解釈を1行で示して先に進みます。

エージェントを起動する前に、次の3点を用意し、ユーザーに提示します。

• 判断の枠組み：問いを、最も明確で判断可能な形にします。選択肢がある場合は、具体的な選択肢（A、B、C）を列挙します。主張や計画の場合は、何を受け入れるか、または退けるかを正確に示します。
• 評価基準：この問いに対する良い回答を定義する基準を2〜4個挙げます（例：正確性、可逆性、コスト、価値実現までの時間、影響範囲、保守性）。陪審団はこの基準に照らして採点するため、明確に示す必要があります。
• 共有する証拠：すべての陪審員に渡す事実、制約、文脈です。コード、設定、ドキュメントに異議を唱える場合は、今それらを読み、関連箇所を含めます。

フェーズ 1：陪審員を編成する（あなたは陪審長です）

references/juror-archetypes.mdを今読んで、パネルを選んでください。ルール：

• 人数：ほとんどの判断では標準の3人を使用します。重大な影響がある、多面的である、または意見が対立している質問には5人を使用します。同票を避けるため、奇数を優先してください。上限は5人です（陪審員を増やしても、独立した意見ではなく、相関したノイズとコストが増えることがほとんどです）。
• 必須の役割：すべてのパネルに、最有力の選択肢を支持する最も強い主張を述べるPROPONENT（支持者）、それに反対する、または最善の代替案を支持する最も強い主張を述べるSKEPTIC / DEVIL'S ADVOCATE（懐疑論者／悪魔の代弁者）、基準を管理し、双方を比較衡量し、時期尚早な合意を避けるINTEGRATOR（統合者）を1人ずつ含めます。5人のパネルでは、アーキタイプのファイルからその分野に関するペルソナを2人追加します。
• 直交性：盲点が異なるペルソナを選んでください。同じ視点の変形を5人集めてはいけません。多様性によって、誤りの相関を低減できます。
• レンズの割り当て：各陪審員に、references/deliberation-craft.mdにある重要な手法を1つ割り当てます（steelman、pre-mortem、red-team、evidence-audit、assumption-surfacing、second-order consequences）。これにより、The Foolの厳密さが議論の場に加わります。漠然とした意見ではなく、各陪審員が1つの鋭い手法を使います。
• 同一入力を崩す：すべての陪審員が同じ証拠を共有していても、それぞれに異なる主な関心事を割り当て、プロンプトが同一にならないようにします。質問に切り分け可能なサブクエスチョンや証拠の流れがある場合は、陪審員ごとに異なる流れを重視させてもかまいません。

フェーズ 2：独立した意見をブラインドで集める（サブエージェントを並列で実行）

ランタイムの並列サブエージェント機能（たとえば、Claude CodeのTaskツールや並列ツール呼び出し）を使って、すべての陪審員を同時に起動します。各陪審員には、判断の枠組み、評価基準、共有する証拠、および自身の役割、ペルソナ、レンズを渡します。陪審員は、他の陪審員の出力を見てはいけません。references/deliberation-craft.mdにあるRound 1のプロンプトテンプレートを使用してください。

サブエージェントを利用できないランタイムの場合：同じコンテキスト内で、役割を演じるパスを順番にシミュレートします。ただし、いずれかの陪審員に意見を見せる前に、Round 1のすべての立場を必ず生成してください。ブラインド状態は譲れない条件です。これはアンカリングを防ぐためのゲートです。

各陪審員は、簡潔な構造化ブロックで以下を返します。

• 立場：選ぶ選択肢、または主張に対する立場です。必ず明確に決めてください。「場合による」は立場ではありません。
• 主な論拠：自身のレンズを使った、具体的で根拠に基づくポイントを2～4点。漠然とした「もしこうだったら」は避けてください。
• 証拠の評価：A（強い：直接的なデータ、証明、再現可能）、B（中程度：確かな推論または間接的なデータ）、C（弱い：もっともらしいが根拠が薄い）、D（逸話的、または仮定に基づく）。立場の根拠となる証拠を評価してください。
• 前提：この立場が成り立つために、何が真である必要があるか。
• 確信度：0～100。

Round 1の立場と確信度をすべて記録してください。これらが独立した投票となり、フェーズ4でもう一度必要になります。

フェーズ 3：匿名での審議（サブエージェント）

Round 1を匿名化します。すべてのペルソナ名と識別ラベルを削除し、各立場に「Position 1」「Position 2」…のような中立的なラベルを付けてください。識別情報が漏れると、同じ基盤モデルへのえこひいきや迎合が生じるため、陪審員は誰が何を述べたかを知ってはいけません。匿名化した立場をまとめ、Round 2のプロンプトテンプレートを使って各陪審員に送り返します。

Round 2では、各陪審員は次のことを行う必要があります。

1. 反論する前に、自分の立場に反対する最も強い意見をsteelmanします。
2. 何があれば自分の考えが変わるのかを明示します。
3. 立場を維持するか、変更します。立場を変更する（翻意する）場合は、変更の原因となった具体的な新しい論拠または証拠を必ず挙げてください。理由を挙げない翻意、または見かけ上の多数派に近づくだけの翻意は無効とし、フェーズ4で同調行動として扱います。

適応的な停止：Round 2の終了後、立場が安定していて（実質的な変更をした陪審員がいない場合）、審議を停止してフェーズ4に進みます。追加ラウンドを1回だけ行うのは、大きな変化が実際にあり、かつパネル内で意見がなお分かれている場合に限ります。いずれの場合も、審議ラウンドは2回を超えてはいけません。

最終的な立場、最終的な確信度、および各翻意の理由として挙げられた内容を記録してください。

フェーズ 4：フォアマンによる集計と統合（あなた、フォアマン）

判定を決定論的に算出します。コードを実行できる場合は、集計スクリプトを実行します。

python scripts/tally.py --input jury.json

ここで jury.json には、各審査員の initial_choice、initial_confidence、final_choice、final_confidence、flip_reason、evidence_grade と、パネル全体の diversity に関するメモが記録されています。スクリプトは、信頼度で重み付けしたスコア、意見変更とバンドワゴンのフラグ、同質性に関する注意事項、推奨判定を返します。正確な JSON の形式については、scripts/tally.py のヘッダーを参照してください。

コードを実行できない場合は、同じ手順を手作業で適用します。

1. 信頼度で重み付けしたスコア：最終投票に基づき、選択肢ごとに、支持する審査員の信頼度を合計します。
2. 意見変更の監査：初期の選択から最終的な選択へ変更した審査員全員について、新たに挙げられた理由があるか確認します。意見変更の半数を超えるものに正当な理由がない場合、またはすべての変更が最初に示された多数派の意見に近づく方向である場合、審議を「疑わしい」と判定します。
3. 「疑わしい」場合：代わりに、独立した第 1 ラウンドの投票を使ってスコアを再計算し、その勝者を採用して信頼度を「低」に制限します。審議にバンドワゴンの兆候があったため、独立した集計に切り替えたことを明確に述べます。（独立した集計は、質の低下した審議を上回ることがよくあります。）
4. それ以外の場合：最終的な信頼度加重スコアの勝者を判定とします。
5. 同点または僅差（上位の選択肢の差が約 10％以内）：コイントスで決めたり、棄権したりしてはいけません。根拠を比較し、ルーブリックに照らして、悪魔の代弁者による最も強い反論に最もよく耐えた、根拠の評価がより高い選択肢を選びます。
6. 同質性による上限：パネルの実質的な多様性が低い場合（同じモデル、ありきたりなペルソナ、最初からほぼ全員一致）、信頼度を 1 段階下げ、実質的な独立性が低く、合意は弱い根拠であることを明記します。

判定は必須です。どんな場合でも、「判定なし」とせず、少なくともましな選択肢とテストを示し、信頼度を「低」または「方向転換」としてください。

フェーズ 5：判定を提示する

次のセクションにある判定ブロックのみを、ユーザーの言語で出力します。前置き、審議の記録、締めの挨拶は不要です。ユーザーから後で理由を求められた場合は、審査員ごとの見解と集計を共有します。

判定形式（必須の形式）

判定は、ADHD に配慮した形式に従います。結論を最初に示し、理由に番号を付け、余計な文言を避け、具体的な次の行動を 1 つ示します。簡潔にまとめてください。

VERDICT: <the decision, one actionable line>
Confidence: HIGH | MEDIUM | LOW | PIVOT

Why:
1. <reason, grounded in the rubric and evidence>
2. ...
(max 5, ranked; cut the rest)

Dissent: <the strongest minority position, preserved in one line; "none" only if genuinely unanimous>
Riskiest assumption: <the single thing that, if false, breaks the verdict>
Test: <one concrete experiment or check to validate that assumption>
Next: <one action the user can take now, under a few minutes to start>

信頼度の基準：

• 高：悪魔の代弁者による反論に耐えた真の合意があり、根拠の大半が A または B 評価で、パネルに実質的な多様性があります。
• 中：明確な差をつけた信頼度加重多数決、または異論が一部未解決ながら、B または C 評価の根拠に基づく合意です。
• 低：僅差、または重み付けした票が分かれている、根拠の大半が C または D 評価、あるいはバンドワゴンを受けて独立した集計に切り替えています。
• 方向転換：パネルが、問いそのものの立て方に問題があると判断した場合です。ただし、必ず現在の枠組みで最もましな対応策を示し、問いの立て直し方も述べます。判定を避けるために「方向転換」を使ってはいけません。

制約

必ず行うこと

• 必ず判定を出してください。決して棄権してはいけません。
• 他の審査員の意見を見せる前に、ブラインド方式で第 1 ラウンドを実施してください。
• 必須の悪魔の代弁者を含め、多様なパネルを編成してください。
• 審議中は、意見が誰のものか分からないようにしてください。
• 意見を変更する場合は、具体的な新しい理由を必ず示させてください。正当な理由のない変更や、多数派に追随する変更はバンドワゴンとして扱い、独立した集計に切り替えてください。
• 同点は票数だけで決めず、ルーブリックに照らして論拠の質を比較して判断してください。
• パネルの実質的な多様性と根拠の評価に合わせて信頼度を調整してください。独立性が低い場合は、その注意事項を明記してください。
• ADHD に配慮した形式で判定をまとめてください。結論を最初に示し、理由は最大 5 つを重要度順に並べ、異論を残し、次の行動を 1 つだけ示してください。

MUST NOT

• いずれかの立場を藁人形論法で歪めないでください。
• それ自体を目的として意見の不一致を作り出さないでください（実際に異論を唱える人が必要です。無理に芝居がかった演出をする必要はありません）。
• 説得や迎合が疑われる場合、議論の質より票数を優先しないでください。
• 審議中に陪審員の身元を明かさないでください。
• 審議は2ラウンドを超えないでください。
• 同質なパネルの合意を、確実な結論として過大に示さないでください。
• フレームワークについて講釈したり、研究を引き合いに出したりしないでください。適用しても、それを表に出さないでください。
• 前置き、要約、「何かあればお知らせください」といった締めくくりで評決を水増ししないでください。

例

例1：エンジニアリング上のトレードオフ

ユーザーの発言：「コンパクションが書き込みパスを圧迫しています。陪審を招集してください。LSM ストアを維持して調整するか、今四半期中にホットテーブルを新しいエンジンに移行するか？」

アクション：

1. 選択肢A（現行エンジンを調整）対B（ホットテーブルを移行）として整理します。評価基準：書き込みレイテンシ、移行リスク、可逆性、エンジニアリングコスト。共有する根拠：現在のp99、コンパクションのメトリクス、チームの規模、期限。
2. 5人を招集します：推進役（移行）、悪魔の代弁者（調整）、統合役に加え、信頼性担当のペルソナ（プレモーテムの視点）とコスト担当のペルソナ（根拠監査の視点）。
3. ブラインド形式のラウンド1：信頼性担当の陪審員は「移行リスクは低い」という主張をDと評価し、80の確率でAを選択します。推進役は70の確率でBを選択します。ほかも同様です。
4. 審議：推進役は、二重書き込みの検証計画がないことを認め、その理由を明示したうえでAに転じます。統合役はAを維持します。
5. 集計：加重多数決でAとなり、便乗はありません（意見の転換には根拠が示されています）。根拠の評価はBです。確信度はMEDIUMです。

評決：

VERDICT: Tune the current engine this quarter; do not migrate yet.
Confidence: MEDIUM

Why:
1. Migration risk graded weak (D): no dual-write or shadow-read validation plan exists, and the deadline leaves no rollback window.
2. Compaction thrash is addressable now: leveled-to-tiered switch plus a larger memtable targets the exact p99 spike.
3. Tuning is reversible in hours; the migration is a one-way door this quarter.
4. Team of 4 cannot own two write paths during the freeze.

Dissent: Migration gives the larger long-term ceiling; tuning may only defer the problem one quarter.
Riskiest assumption: that tuning actually moves p99 below target rather than just smoothing it.
Test: run the tiered-compaction config on one replica for 72h and compare p99 against target before committing the quarter.
Next: clone the config to a canary replica and enable tiered compaction.

例2：一般的な意思決定（構築か購入か）

ユーザーの発言：「パネルで判断してください。請求処理用コネクタを自作するか、SaaS Xを購入するか？」

アクション：

1. 選択肢を構築か購入かとして整理します。評価基準：3年間の総コスト、ロードマップに対する主導権、価値実現までの期間、切り替えコスト。共有する根拠：価格、現在の利用量、社内の対応能力。
2. 3人を招集します：推進役（購入）、悪魔の代弁者（構築）、統合役。
3. ブラインド形式のラウンド1の後、匿名で審議し、ラウンド2後に適応的に終了します（立場が安定）。
4. 集計：2対1に分かれましたが、構築案は評価Cの対応能力に関する仮定に基づいています。議長が内容に基づいて判断します。

評決（ユーザーの言語であるポルトガル語で出力）：

VEREDITO: Comprar o SaaS X agora; reavaliar build em 12 meses.
Confianca: MEDIUM

Por que:
1. Time-to-value: comprar entrega em semanas; build estimado em 2 trimestres com capacidade ja comprometida.
2. O caso de build depende de premissa fraca (grade C) de que sobra banda de engenharia.
3. Custo de troca do SaaS X e baixo (export documentado), entao a decisao nao e uma porta de mao unica.

Voto dissidente: no volume atual, o custo do SaaS X ultrapassa o build em ~18 meses; controle de roadmap fica limitado.
Premissa mais arriscada: que o volume nao cresca 5x e dispare o custo por transacao do SaaS.
Teste: modelar o custo do SaaS X em 3 cenarios de volume (1x, 3x, 5x) antes de assinar contrato anual.
Proximo passo: pedir ao fornecedor a tabela de preco por faixa de volume e rodar o modelo.

参考ファイル（条件に応じて読む）

• references/juror-archetypes.md：ドメイン別に整理されたペルソナと役割のライブラリ、直交性に関するガイダンス、パネル規模のガイダンス。フェーズ1で毎回読みます。
• references/deliberation-craft.md：6つの重要な視点（愚者の厳密さ）、迎合とアンカリングを防ぐための詳細、ラウンド1とラウンド2のサブエージェント用プロンプトテンプレート、簡潔な認知バイアスのチェックリスト、根拠資料。フェーズ1の前に読み（視点を割り当てるため）、フェーズ3の間は開いたままにします（プロンプトテンプレートを参照するため）。
• scripts/tally.py：確信度で重み付けした決定論的な集計と、意見の転換、便乗、同質性のチェック。コードを実行できる場合はフェーズ4で実行します。できない場合は、フェーズ4の手作業による段階的な手順に従います。

トラブルシューティング

ラウンド1からパネルの意見が一致している

原因：多様性が低いか、簡単な質問です。パネルを確認してください。同じ視点が繰り返されていませんか？その場合、合意は弱い根拠です（同質性の上限が適用されます）。多様性が実際にあり、悪魔の代弁者が本気で立場を崩そうとしたものの失敗した場合は、確信度をHIGHにするのが妥当です。いずれの場合も、評決は出してください。人為的な意見の不一致を作り出さないでください。

陪審員が毎ラウンド意見を変える

原因：迎合、またはアンカリングへの対処の失敗です。意見を変える場合は理由を示すというルールを徹底し、2ラウンドの上限で終了してください。意見の転換に正当な理由がない場合はSUSPECTとマークし、独立したラウンド1の集計に戻して、確信度をLOWとします。

票が真っ二つに割れている

原因：選択肢のバランスが実際に取れています。棄権もコイントスも行わないでください。評価基準に沿って内容で判断します。根拠の評価が高く、悪魔の代弁者の反論によりよく耐えた選択肢を採用します。拮抗していたことは異論として記録し、確信度を下げてください。

陪審員が判断を下さない（「場合によります」）

原因：役割への忠実さが損なわれています。その陪審員に再度プロンプトを送り、現在の証拠に基づいて最善の選択肢を1つ選び、注意事項は立場の欄ではなく前提条件の欄に記載するよう指示してください。陪審員が提示するのは立場であり、論文ではありません。