エージェントチャットルーム
N体のエージェント（デフォルト3体）をシミュレートされた共有会話に起動します。各エージェントは完全なチャット履歴を読んでから応答し、以前の貢献を基に構築、挑戦、または洗練させます。あなた（進行役）はプロジェクトマネージャーとして、ラウンドを調整し、議論を読み、最終的な出力を抽出します。
なぜこれが有効か: 逐次的な情報伝達ではコンテキストが失われます。2番目のモデルは、最初のモデルがなぜその決定を下したのかを知りません。共有会話は推論の連鎖を保持し、真の議論を可能にします。エージェントAが「キューが必要」と言い、エージェントBが「単純なループで十分」と言った場合、その不一致は、どちらかのエージェントが自信満々に出した単独の答えよりも価値があります。エージェントは仮定に挑戦し、エラーを発見し、多様な推論経路を統合します。
実行
1. リクエストを解析
ユーザーのメッセージから以下を抽出します:
- 議論する問題/質問
- エージェント数 N — デフォルトは3。ユーザーは上書き可能（「5体のエージェントで議論して」）
- ラウンド数 R — デフォルトは3。ユーザーは上書き可能（「5ラウンド議論して」）
- エージェントの役割 (オプション) — ユーザーが役割を指定可能（「アーキテクト、セキュリティエンジニア、フロントエンド開発者で議論して」）。指定がない場合は、多様なデフォルト役割を割り当てます。
問題があいまいな場合は、起動前に明確にするようユーザーに依頼してください。
2. エージェントの役割を割り当て
各エージェントは、生産的な不一致を最大化するために異なる視点を持ちます。ユーザーが役割を指定しなかった場合、問題ドメインに基づいてこれらのデフォルトから選択します:
ソフトウェアエンジニアリング:
- アーキテクト — システム、インターフェース、スケーラビリティ、長期的な保守性を考慮
- 実用主義者 — 迅速なリリース、最小限の複雑さ、「十分良い」ソリューションを最適化
- 批評家 — エッジケース、障害モード、セキュリティホール、暗黙の前提を発見
プロダクト/デザイン:
- ユーザー擁護者 — UX、シンプルさ、ユーザーの満足度を最適化
- ビジネス戦略家 — 収益、成長、競争優位性を最適化
- エンジニア — 技術的実現可能性とコストに基づいて議論を行う
戦略/意思決定:
- 楽観主義者 — 機会、上昇の可能性、行動する理由を見る
- 懐疑論者 — リスク、下落の可能性、待つ理由を見る
- 統合者 — 中間の道を見つけ、両方の視点を統合
N > 3の場合、既存の役割と生産的な緊張を生み出す役割を追加します。
3. チャットファイルを初期化
active/chatroom/chat.json を以下の初期構造で作成します:
{
"problem": "{問題の説明}",
"context": "{関連するコンテキスト、コード、制約}",
"agents": [
{"name": "エージェントA", "role": "{役割}", "framing": "{役割の説明}"},
{"name": "エージェントB", "role": "{役割}", "framing": "{役割の説明}"},
{"name": "エージェントC", "role": "{役割}", "framing": "{役割の説明}"}
],
"rounds": [],
"final_output": null
}
4. 議論ラウンドを実行
各ラウンド（1からR）について、すべてのNエージェントを並行して起動します。各エージェントは完全なチャット履歴を読み、貢献します。
エージェント起動設定:
subagent_type: "general-purpose"model: "sonnet"(デフォルト — ユーザーはopusに上書きしてより深い推論を要求可能)mode: "bypassPermissions"
ラウンド手順:
ラウンド1 — 初期見解: 各エージェントが問題に対する最初の見解を述べます。
エージェントプロンプト:
あなたは {役割}: {役割の説明}
問題:
{problem}
コンテキスト:
{context}
これはマルチエージェント議論のラウンド1です。この問題に対するあなたの初期見解を述べてください。具体的かつ具体的に — 漠然とした原則ではなく、実際の解決策を提案してください。明確な立場を取ってください。
他のエージェントは以降のラウンドであなたの立場に挑戦します。そのため、あなたの推論を明確にしてください。
以下の形式で応答してください:
見解: [一文であなたの立場]
推論: [詳細な議論 — 3〜5のポイント]
提案: [具体的な推奨事項]
懸念点: [あなたのアプローチで何がうまくいかない可能性があるか]
直接応答を書いてください — いかなるファイルにも書き込まないでください。
ラウンド2以上 — 議論: 各エージェントはすべての以前の応答を読み、応答します。
エージェントプロンプト:
あなたは {役割}: {役割の説明}
問題:
{problem}
以前の議論:
{すべての以前のラウンドエントリ。「エージェントX (役割): 応答」という形式}
これはマルチエージェント議論のラウンド{N}です。以前の議論を注意深く読んでください。
あなたの仕事:
1. あなたの立場に対する最も強力な反論に応答する
2. 他のエージェントと**同意**する点を特定する（良い点を認める）
3. まだ**同意しない**点とその理由を特定する
4. これまでの議論に基づいて提案を洗練する
以前の立場を単に繰り返さないでください。他の人の発言に積極的に関わってください。他の人がより良い議論をした場合には、考えを変えてください。
以下の形式で応答してください:
同意点: [他のエージェントが正しかった点]
不同意点: [まだ異なる点とその理由]
洗練された提案: [更新された推奨事項]
確信度: [1-10 で洗練された立場に対する確信度]
直接応答を書いてください — いかなるファイルにも書き込まないでください。
各ラウンド後:
- すべてのエージェントの応答を収集
chat.jsonのrounds配列に追加:
{
"round": 1,
"entries": [
{"agent": "エージェントA", "role": "アーキテクト", "response": "..."},
{"agent": "エージェントB", "role": "実用主義者", "response": "..."},
{"agent": "エージェントC", "role": "批評家", "response": "..."}
]
}
- 収束を確認: すべてのエージェントが同意している場合（確信度8以上、提案が一致）、早期に停止 — これ以上ラウンドは不要。
5. 最終出力を統合
最終ラウンド後、あなた（進行役）が議論全体を読み、統合を生成します。このために別のエージェントを起動しないでください — あなた自身が行います。
分析:
- エージェントはどこで収束したか？ — これらは確信度の高い結論です
- どこで意見が分かれたままか？ — これらはユーザーが決定すべき真のトレードオフです
- 提起されたが未解決の懸念点は？ — これらは監視すべきリスクです
- 考えを変えたエージェントはいたか？ — 考えの変更は強力なシグナルです
6. 最終レポートを作成
active/chatroom/chat.json の final_output を更新し、人間が読みやすい要約を active/chatroom/chatroom_report.md に書き込みます:
# エージェントチャットルームレポート
**問題**: {problem}
**エージェント数**: {N} | **ラウンド数**: {R}
**日付**: {date}
## 参加者
| エージェント | 役割 | 最終確信度 |
|-------|------|-----------------|
| エージェントA | {役割} | {確信度}/10 |
| エージェントB | {役割} | {確信度}/10 |
| エージェントC | {役割} | {確信度}/10 |
## 合意点
{最終ラウンドまでにすべてのエージェントが同意した内容}
## 主な不一致
{意見が分かれたままの点 — 両方の立場を公平に提示}
## 推奨アクション
{進行役としての統合 — すべての視点を考慮した最善の前進方法}
## 未解決のリスク
{議論中に提起されたが完全には対処されなかった懸念点}
## 議論のハイライト
{最も興味深い交換 — 考えが変わった箇所や強力な反論が現れた箇所}
## 完全なトランスクリプト
{chat.jsonへのリンクまたは主要な交換をインラインで}
7. 結果を提示
ユーザーに提示:
- 議論結果の一段落要約
- 推奨アクション（議論に基づいた進行役としてのあなたの判断）
- 最も鋭い不一致（ユーザーの判断が必要な箇所）
- レポートとchat.jsonへのファイルパス
設定
| パラメータ | デフォルト | 説明 |
|---|---|---|
| N | 3 | チャットルームのエージェント数 |
| R | 3 | 議論のラウンド数 |
| model | sonnet | 各エージェントのモデル |
| roles | auto | エージェントの役割（自動割り当てまたはユーザー指定） |
ユーザーは上書き可能: 「5体のopusエージェントで4ラウンド議論して」または「アーキテクトとジュニア開発者で議論して」
コストに関する考慮事項
- 3 sonnetエージェント x 3ラウンド = 9エージェント呼び出し (~$0.30-0.50)
- 3 opusエージェント x 3ラウンド = 9エージェント呼び出し (~$3-5)
- 5エージェント x 5ラウンド = 25呼び出し — opusだと高価になる
- デフォルトはsonnet。ユーザーが明示的に要求するか、問題が深い技術的推論を必要とする場合のみopusを使用。
- 早期収束でコスト削減 — すべてのラウンドが完了する前にエージェントが同意したら停止。
エッジケース
- N < 2: ユーザーに警告 — チャットルームには少なくとも2体のエージェントが必要。最低2。
- エージェントがすぐに全員同意: ラウンド1で停止。全会一致を報告。これは有効な（そして安価な）結果です。
- エージェントが行き詰まる: Rラウンド後も収束しない場合、正直に行き詰まりを報告。これは真の判断事項であり、支配的な答えがないという発見です。
- エージェントがトピックから逸れる: その応答を統合から除外し、有効なエージェント数を記録。
- 既存のチャットルームファイル:
active/chatroom/に既存のファイルがないか確認。確認なしで上書き（これらは一時的な議論の成果物であり、永続的なデータではありません）。 - ユーザーがカスタム役割を指定: 指定されたものをそのまま使用。特に要求されない限り、追加の役割は追加しない。
出力ファイル
| ファイル | 説明 |
|---|---|
active/chatroom/chat.json | 完全な構造化議論トランスクリプト |
active/chatroom/chatroom_report.md | 人間が読みやすい統合レポート |
以前のレポートは上書きされます — これらは一時的な議論ツールであり、アーカイブではありません。