エージェント・ルーム

メタ — 確率的マルチエージェント・ディスカッション。複数の専門家視点を通じた議論またはアンケートにより問題を多角的に検討します。

中心的な質問： 「複数の視点が収束するのはどこか——そして本当に対立している部分はどこか？」

これは中央集約型の マルチパースペクティブ分析 機能です。スキルが議論、合意形成、または意思決定に関する複数の視点を必要とする場合、エージェント・ルームを実行します。（task-breakdown など）構造化された分解作業では、ドメイン固有の専門エージェントを保持できます。

---

2つのエントリーポイント

1. スタンドアロン（ユーザーが直接実行）

ユーザーが /agent-room "モノレポとポリレポのどちらを使うべきか？" を実行します——スキルは完全な議論またはアンケート・セッションを実行します。

2. サブルーチン（別のスキルが実行中に実行）

discover スキルが会話中に複雑な意思決定に直面します。特定の意思決定を明確に設定してエージェント・ルームを実行し、結果を待ってから会話を続けます。

サブルーチン・プロトコル（スキル実行時）：

1. 特定の意思決定を明確な問題ステートメントとして定義する
2. これまでに収集した関連コンテキストを含める
3. モード（議論/アンケート）とエージェント数を指定してエージェント・ルームを実行する
4. レポートを受け取る：合意、不一致、推奨事項
5. 推奨事項を進行中の会話に統合する
6. エージェント・ルーム・レポートは一時的——コンテキストに保存され、ディスクに必ずしも保存されない

サブルーチンとして実行する場合、ユーザーが要求しない限りレポートをディスクに書き込まないでください。価値は洞察であり、成果物ではありません。

---

重要なゲート

1. 正しいモードを選択する — トレードオフ決定には議論、幻覚をフィルター化して合意を見つけるにはアンケートを使用します。デフォルトは議論です（少ないエージェント数でより豊かな出力）。
2. 問題は具体的である必要があります — 曖昧なプロンプトに対するN個のエージェントはトークンを浪費します。曖昧な場合は、エージェントを生成する前にユーザーに改善を求めてください。
3. エージェントは構造化された出力を生成する必要があります — 自由形式の散文は集計できません。
4. コストはエージェント数に応じてスケールします — 3つの議論エージェント × 3ラウンド ~ $0.30-0.50。10個のアンケート・エージェント ~ $0.30-0.50。ユーザーがOpusをリクエストしない限り、デフォルトはSonnetです。

---

モード・ルーティング

キーワード	モード
「議論」「主張」「ディスカッション」「チャットルーム」「トレードオフ」	議論
「合意」「アンケート」「投票」「エージェントはどう考えるか」「複数の意見」	アンケート
曖昧	デフォルトは 議論

---

モードA：議論

N個のエージェント（デフォルト3個）を共有会話に投入します。各エージェントは応答する前に完全なチャット履歴を読み、前の貢献に基づいて、異議を唱えたり、洗練したりします。

機能する理由： 順序付きハンドオフはコンテキストを失います。共有会話は推論チェーンを保持し、本物の議論を実現します。エージェントAが「これはキューが必要」と言い、エージェントBが「単純なループで問題ない」と言う場合、その不一致は各エージェントの単独の回答より価値があります。

A1. リクエストを解析する

以下を抽出します：

• 議論する問題/質問
• エージェント数N — デフォルト3（オーバーライド：「5つのエージェントに議論させて」）
• ラウンド数R — デフォルト3（オーバーライド：「5ラウンド議論して」）
• エージェント・ロール — ユーザーが指定できます。指定されない場合は、多様なデフォルトを割り当てます。

A2. エージェント・ロールを割り当てる

各エージェントは生産的な意見の相違を最大化するための異なった視点を得ます。

ソフトウェア・エンジニアリング：

1. アーキテクト — システム、インターフェース、スケーラビリティ、長期的な保守性
2. プラグマティスト — 迅速なデリバリー、最小限の複雑さ、「十分な」ソリューション
3. クリティック — エッジケース、障害モード、セキュリティ穴、明示されていない仮定

プロダクト/デザイン：

1. ユーザー・アドボケート — UX、シンプルさ、デライト
2. ビジネス・ストラテジスト — 収益、成長、競争上の優位性
3. エンジニア — 技術的実現可能性とコスト

戦略/意思決定：

1. 楽観主義者 — 機会、アップサイド、行動する理由
2. 懐疑主義者 — リスク、ダウンサイド、待つ理由
3. シンセサイザー — 中道、両方の視点を統合

N > 3の場合、既存の視点と生産的な緊張を作成するロールを追加します。

発散のための制約割り当て — 議論がデザインまたはアーキテクチャに関する場合（戦略ではなく）、各エージェントに（または加えて）構造的制約を視点の代わりに割り当てます。これは異なるソリューションを機械的に強制し、それらを期待するのではなく：

• エージェント1：「表面積を最小化——可能な限り最少のメソッド/エンドポイントを目指す」
• エージェント2：「柔軟性を最大化——最も幅広いユースケースをサポート」
• エージェント3：「最も一般的なケースに最適化——80%のパスを自明に単純にする」
• エージェント4（N > 3の場合）：「[ユーザーが知っている特定のパラダイム/ライブラリ]からインスピレーションを取得」

制約割り当てされたエージェントは本当に異なるデザインを生成します。視点割り当てされたエージェントは異なる正当性を持つ同様のデザインに収束する傾向があります。

A3. 議論ラウンドを実行する

ラウンド1 — オープニング・ポジション。 エージェント・プロンプト：

You are {role}: {role_description}

PROBLEM:
{problem}

CONTEXT:
{context}

This is Round 1 of a multi-agent debate. State your initial position.
Be specific — propose actual solutions, not vague principles. Take a clear stance.
Other agents will challenge you in subsequent rounds.

Communication discipline:
- No performative agreement: never open with "Great point" or "I appreciate X's perspective"
- State disagreements directly: "That approach fails because [X]" not "While that has merit..."
- No hedging: "This will break under load" not "This might potentially have scaling concerns"

Respond in this format:
POSITION: [One-sentence stance]
REASONING: [3-5 key points]
PROPOSAL: [Concrete recommendation]
CONCERNS: [What could go wrong with your approach]

Write your response directly — do not write to any files.

ラウンド2以降 — 議論。 エージェント・プロンプト：

You are {role}: {role_description}

PROBLEM:
{problem}

PREVIOUS DISCUSSION:
{all previous round entries}

This is Round {N}. Read the previous discussion carefully.

1. Respond to the strongest counterargument against your position
2. Identify where you AGREE with other agents (concede good points)
3. Identify where you still DISAGREE and why
4. Refine your proposal based on the discussion

Do NOT repeat your previous position. Engage with what others said.
Change your mind if they made a better argument.
Do NOT soften disagreements with praise. "I appreciate Agent A's point, but..." is sycophancy disguised as discourse. State the disagreement directly.

Respond in this format:
AGREEMENTS: [What other agents got right]
DISAGREEMENTS: [Where you still differ and why]
REFINED PROPOSAL: [Updated recommendation]
CONFIDENCE: [1-10]

Write your response directly — do not write to any files.

各ラウンド後：

1. すべてのエージェント応答を収集する
2. 収束を確認する：すべてのエージェントが同意している場合（確信度8以上、提案がアライン）、早期に停止する
3. それ以外の場合は次のラウンドに続行する

A4. 統合する

最後のラウンド後、あなた（オーケストレーター）が完全な議論を読んで統合します：

• エージェントが収束した部分は何か？ — 高い確信度の結論
• どこで分かれたままか？ — ユーザーが決定する必要がある本物のトレードオフ
• 提起されたが解決されなかった懸念は何か？ — 監視すべきリスク
• いずれかのエージェントが意見を変えたか？ — 意見の変更は強いシグナル

---

モードB：アンケート

N個のエージェント（デフォルト10個）を同じコンテキストと異なるフレーミングで投入します。各エージェントは独立して分析し、構造化された出力を生成します。合意、発散、外れ値で集計します。

機能する理由： 確率的変動を活用します。10人の専門家に別々にアンケートを取るようなものです。幻覚と個々のバイアスをフィルター化します。発散は本当の判断の呼び出しを明らかにします。

B1. 構造化出力スキーマを設計する

各エージェントは機械的に比較できる構造化出力を返す必要があります：

出力タイプ	いつ	スキーマ
ランキング	定義済みオプション	「これら5つのオプションを1-5にランク付け」
推奨事項	オープンエンド	「信頼度1-10で上位3つの推奨事項」
バイナリ	はい/いいえ決定	「YESまたはNO、上位3つの理由」
スコアリング	マルチ基準	「[基準]の各オプションを1-10でスコア付け」

B2. フレーミング・バリエーションを生成する

わずかに異なるN個のプロンプト。コア問題+スキーマは同じ——フレーミングだけ異なります：

1. ニュートラル・ベースライン
2. リスク回避的アナリスト
3. 成長志向型ストラテジスト
4. コントラリアン（従来の知恵に異議を唱える）
5. ファーストプリンシプル推論家
6. ユーザー・エンパシー・フォーカス
7. リソース制約最適化者
8. 長期（5年）最適化者
9. データドリブン（測定可能なもののみ）
10. システム思考者（2次/3次効果）

N < 10の場合は最初のNを使用します。N > 10の場合はサイクルします。

B3. すべてのNエージェントを並列に生成する

ワンパス——収束検出なし。独立サンプルは反復的な洗練より優れた統計的信号を提供します。

B4. 結果を集計する

ランキング： ボルダ・カウント（1位 = Nポイント、2位 = N-1など） 推奨事項： 同様のものをグループ化、発生回数をカウント。合意（70%以上）、発散（40-69%）、外れ値（40%未満）。 スコアリング： 平均、中央値、標準偏差。高分散オプションにフラグを立てます。 バイナリ： YES/NOをカウント、各側から最強の引数を要約します。

---

レポート

スタンドアロン（または明示的にリクエストされた場合）の場合、.agents/meta/agent-room-report.md に書き込みます：

---
skill: agent-room
version: 1
date: {YYYY-MM-DD}
status: final
---

# エージェント・ルーム・レポート

**問題**: {problem}
**モード**: {議論 | アンケート}
**エージェント**: {N} | **ラウンド**: {R、議論のみ}

議論セクション： 参加者、合意、主要な不一致、推奨アクション、未解決リスク、議論のハイライト。

アンケート・セクション： 合意（X+/N同意）、発散（X/Y分割）、外れ値（Z/N）、生ランキング/スコア。

サブルーチンとして実行する場合：統合をインライン返し、ディスク書き込みをスキップしてください。

---

設定

パラメーター	デフォルト	オーバーライド
mode	debate	「これをアンケート」 / 「これを議論」
N	3（議論）/ 10（アンケート）	「5つのエージェント」 / 「15のエージェント」
R	3	「5ラウンド議論」（議論のみ）
model	sonnet	「opusを使用」
roles	auto	「DBA、フロントエンド開発者、DevOpsエンジニアに議論させて」

---

エッジケース

• 曖昧な問題: エージェントを生成する前にユーザーに改善を要求してください。曖昧さについてトークンを浪費しないでください。
• N < 2（議論）またはN < 3（アンケート）: ユーザーに警告——議論は2以上が必要、アンケートは3以上が必要です。
• ラウンド1で満場一致: 早期に停止。合意をレポート。有効で安価。
• Rラウンド後のデッドロック: 正直にレポート。その発見は支配的な回答が存在しないことです。
• 投票が均等に分かれている: その分割をレポート。強制的なタイブレーカーはなし。
• エージェントが話題から外れる: 統合から除外、有効なNを注記します。
• 既存レポート: 上書き——これらはエフェメラル分析成果物です。

---

コスト考慮事項

• 3つのSonnetエージェント × 3ラウンド（議論）：約$0.30-0.50
• 10個のSonnetエージェント（アンケート）：約$0.30-0.50
• Opusは約10倍にスケール——明示的にリクエストされた場合のみ使用
• 早期収束はコストを節約
• バイナリ決定では、通常5つのアンケート・エージェントで十分です

チェーン位置

スタンドアロン・スキル——マルチパースペクティブ意思決定のためにサブルーチンとして他のスキルで実行できます。典型的な呼び出し元：solution-design、system-architecture、discover。