エージェント会話プロトコル は何をしますか？
あなたはマルチエージェント会話設計の専門家です。エージェント同士がどのように対話するか、つまり、マルチエージェントシステムを混沌ではなく首尾一貫したものにするメッセージタイプ、ターン取得ルール、委任パターン、紛争解決メカニズムを理解しています。
決定ポイント
主要パターン選択ツリー
与えられた問題の特性に基づく:
├── タスクは独立したサブタスクに分解可能か？
│ ├── YES + 品質が速度より重要
│ │ └── 冗長実行（同一タスクに3+エージェント）によるFAN-OUT/FAN-INを使用
│ ├── YES + 速度が品質より重要
│ │ └── 分割実行（作業を分割）によるFAN-OUT/FAN-INを使用
│ └── NO + タスクに順次依存関係が必要
│ └── 委任チェーンによるSUPERVISOR-WORKERを使用
│
├── 複数の有効なアプローチが存在するか？
│ ├── YES + 検証可能な正解が存在する
│ │ └── DEBATE（審判による対立型洗練）を使用
│ ├── YES + 主観的な好みの決定
│ │ └── VOTING/CONSENSUS（民主的選択）を使用
│ └── NO + 単一アプローチだが洗練が必要
│ └── CRITIQUE-REFINE（反復的改善）を使用
│
├── 多様なソースからの知識統合？
│ └── BLACKBOARD（共有状態の蓄積）を使用
│
└── シンプルな機能委任？
└── REQUEST/RESPONSE（同期的ハンドオフ）を使用
トポロジー × イニシアチブ × ターン順序決定マトリックス
| トポロジー | イニシアチブ | ターン順序 | 使用タイミング | 例 |
|---|---|---|---|---|
| スター | プッシュ | ラウンドロビン | 明確なリーダーが作業を調整する場合 | CrewAI階層プロセス |
| スター | プル | 優先順位キュー | ワーカーが準備完了時にタスクを要求する場合 | マネージャー付きAutoGen GroupChat |
| メッシュ | プッシュ | フリーフォーム | ピアコラボレーション、ボトルネックなし | マルチエージェント討論 |
| ツリー | プッシュ | 深さ優先 | 階層的分解 | 複雑な委任チェーン |
| ブロードキャスト | リアクティブ | イベント駆動 | 知識共有、更新 | LangGraph状態更新 |
終了条件の選択
会話タイプが以下の場合:
├── DEBATE → judge_confidence > 0.8 または ラウンド数 >= 3 で停止
├── CRITIQUE → verdict == 'approve' または イテレーション数 >= 4 で停止
├── VOTING → すべての投票が収集されたか、タイムアウトで停止
├── FAN-OUT → gather_policyが満たされた(all/majority/first) で停止
├── SUPERVISOR → すべてのサブタスクが完了するか、予算超過で停止
└── BLACKBOARD → goal_conditionが満たされるか、陳腐化が検出されたら停止
障害モード
1. 委任のピンポン
検出: エージェントAがBに委任し、BがAに委任し返し、無限ループが発生する 症状: メッセージ数が指数関数的に増加し、同じタスクが無限に繰り返される 根本原因: 委任チェーンにサイクル検出がなく、ワーカーが上位に委任できる 修正: チェーン追跡と上位委任ブロックを使用した委任制約を実装する
2. 同調崩壊
検出: 討論において、根拠に関わらずラウンド2までにすべてのエージェントが同じ立場に収束する 症状: 初期ラウンド後に立場が変わらず、複雑なトピックで全会一致になる 根本原因: エージェントが真実追求よりも同意を最適化する 修正: 明示的な対立する役割を割り当て、エージェントに割り当てられた視点を守るよう要求する
3. スーパーバイザーボトルネック
検出: すべての調整が単一のスーパーバイザーを通過し、並列タスクで高レイテンシが発生する 症状: ワーカーがスーパーバイザーの応答を待ってアイドル状態になり、並列化可能な作業で線形スケーリングになる 根本原因: スーパーバイザーが統合者ではなくメッセージルーターとして機能する 修正: Fan-Out/Fan-Inとして再構築するか、ワーカー間の直接通信を有効にする
4. ブラックボード状態爆発
検出: 共有状態が無制限に増大し、エージェントが無関係なエントリを読むためにトークンを浪費する 症状: クエリ応答時間が時間とともに増加し、読み取り時のトークン使用量が多い 根本原因: ブラックボードエントリにガベージコレクションや関連性フィルタリングがない 修正: 信頼度ベースの有効期限と読み取り時のセマンティックフィルタリングを実装する
5. コンテキスト劣化カスケード
検出: 深い委任チェーン（3レベル超）が各ホップで必須コンテキストを失う 症状: ワーカーが質問を明確にし、チェーン深度とともに出力品質が低下する 根本原因: コンテキスト圧縮のアーティファクトが委任ホップ間で累積する 修正: 階層を最大2レベルに平坦化するか、すべてのワーカーに完全なコンテキストを渡す
実践例
例1: コードレビューシステム設計
問題: 4エージェントコードレビュー（作成者、セキュリティレビューアー、パフォーマンスレビューアー、スタイルレビューアー）のための会話プロトコルを設計する
決定プロセス:
- パターン選択: 品質重視の出力 → CRITIQUE-REFINE + 複数視点 → DEBATEハイブリッド
- トポロジー分析: 4人のレビューアーが同じコードを見る必要あり → 作成者をハブとするスター型トポロジー
- ターン順序: セキュリティは最初に実行する必要あり（ブロッキング）、その後パフォーマンスとスタイルを並列実行
選択されたプロトコル:
フェーズ1: 作成者が初期コードを提出（REQUEST/RESPONSE）
フェーズ2: セキュリティレビュー（CRITIQUE-REFINE、ブロッキング）
フェーズ3: パフォーマンス + スタイルレビュー（FAN-OUT/FAN-IN、並列）
フェーズ4: 問題が重複する場合の紛争解決（DEBATE）
フェーズ5: 作成者がフィードバックを取り込む（CRITIQUE-REFINE）
パターントレードマトリックス:
- 純粋なCRITIQUEチェーン: 遅すぎる（逐次レビュー）
- 純粋なDEBATE: セキュリティ問題が多数決で議論され尽くす
- 純粋なFAN-OUT: セキュリティ障害のブロッキングなし
- ハイブリッド: セキュリティを最初に、次に並列、最後に紛争解決
例2: 研究論文作成
問題: 3エージェント（研究者、ライター、ファクトチェッカー）が文献レビューを作成する
決定プロセス:
- イニシアチブタイプ: プル型（エージェントが準備完了時に作業） vs プッシュ型（コーディネーターが割り当て）
- 品質 vs 速度: 品質重視 → 冗長性が必要
- 分解: トピックは研究分野ごとに分割可能
選択されたプロトコル:
研究者: 研究分野全体に分割されたFAN-OUT
ファクトチェッカー: 各セクションに対するCRITIQUE-REFINE
ライター: すべての入力を統合するSUPERVISOR役割
代替案を選ばなかった理由:
- 全エージェントが単一のDEBATEに参加: 明確な役割がなく、ライターの専門知識がファクトチェックに浪費される
- 逐次的なREQUEST/RESPONSEチェーン: 遅すぎ、並列研究ができない
- 純粋なBLACKBOARD: 統合がなく、単なる知識の蓄積
終了ロジック:
以下の場合に停止:
- すべての研究分野がカバーされた（完全性チェック）
- ファクトチェッカーの信頼度がすべてのセクションで0.85超
- ライターが首尾一貫した統合を生成
- 総トークンが予算未満 または 時間が期限未満
例3: 動的ルーティング決定
問題: 実行中、スーパーバイザーが3人のワーカーは過負荷、1人のワーカーはアイドル状態であることを検出する
リアルタイム決定ツリー:
現在の状態: 3人のワーカーが容量の90%、1人のワーカーが10%
オプション:
1. 作業の再バランス（アイドルワーカーにタスクを移行）
2. 冗長性の追加（クリティカルパスでの並列実行）
3. トポロジーの変更（スターからメッシュに切り替え、ピア委任用）
決定要因:
├── 残り時間? < 25% → オプション2（並列、より高いコストを受け入れる）
├── 残り予算? < 50% → オプション1（再バランス、コスト最適化）
└── タスク依存性? 高結合 → オプション3（メッシュトポロジー）
実行: スーパーバイザーが状態を検出し、トポロジー変更メッセージをブロードキャストし、ワーカーが委任ルールを更新し、新しいパターンで作業を継続する
品質ゲート
- 終了ポリシーが定義されている: すべての会話に明示的な最大メッセージ数、時間、コスト制限がある
- サイクル検出が有効: 委任チェーンがエージェント履歴を追跡し、A→B→Aループを防止する
- 信頼度スコアが存在する: すべての出力に品質評価のためのエージェント信頼度（0.0-1.0）が含まれている
- 進捗報告が組み込まれている: 長時間実行タスクがコーディネーターに定期的なハートビートメッセージを送信する
- コンテキストハンドオフが検証されている: 各委任にトークン見積もりが含まれ、削除可能なコンテキストセクションが特定されている
- エラー伝搬が設計されている: システムは単一エージェントの障害に対して、会話全体の崩壊なしに対処できる
- 収集ポリシーが明示的: Fan-Out操作が待機条件（all/majority/first/quorum）を指定する
- 役割の多様性が強制されている: 討論プロトコルは「これについて議論してください」という一般的なものではなく、明確な視点を割り当てる
- 状態の有効期限が設定されている: ブラックボードエントリに自動クリーンアップのためのTTLまたは信頼度しきい値がある
- トポロジーがタスクに一致している: 会話構造が問題の分解（決定ツリーを参照）と一致している
対象外の境界
このスキルは会話設計をカバーしますが、以下は対象外です:
- シリアライゼーションフォーマット (JSONスキーマ、メッセージエンコーディング) →
agent-interchange-formatsを使用 - インフラストラクチャ設定 (メッセージキュー、サービスディスカバリ) →
agentic-infrastructure-2026を使用 - 単一エージェントのツール使用 (関数呼び出し、思考連鎖) →
agentic-patternsを使用 - メモリ永続化 (ベクターストア、エピソード記憶) →
episodic-memory-algorithmsを使用 - フレームワーク選択 (AutoGen vs LangGraph vs CrewAI) →
agentic-infrastructure-2026を使用
以下の場合、他のスキルに委任してください:
- ワイヤープロトコル設計 →
agent-interchange-formats - パフォーマンス最適化 →
agentic-infrastructure-2026 - 個々のエージェント推論 →
agentic-patterns - 長期記憶 →
episodic-memory-algorithms - ツール統合 →
agentic-patterns