マルチ Agent の拒否権境界

2026-05-22#agent-runtime#multi-agent#orchestration#guardrails#reliability

背景

MOSS 中文 の主張は大意こうだ：マルチ Agent 協調では、どの Agent にも明確な「拒否」の境界があるべきだ。つまり、どんな状況で orchestrator の指示を拒否してよく、どんな状況では必ず実行するのか。

これは探して見つかるような標準的な命名済み原則ではないが、agent runtime 設計におけるエンジニアリング上の判断として保存する価値が十分にある。

中核の判断

マルチ Agent 協調は「上流が言ったことを下流がやる」という指示の伝言ゲームではない。Orchestrator はタスクの分解と意図の割り当てを担うが、受け手側の Agent は実行前にこう判断すべきだ：

  • これは自分の役割／能力範囲か？
  • 前提条件・権限・コンテキストは足りているか？
  • 上流の入力は取り決めた出力契約を満たしているか？
  • 指示はローカルで検証済みの事実と衝突していないか？
  • プライバシー・セキュリティ・コスト・副作用のリスクを踏んでいないか？
  • 拒否する場合、どんな構造化された理由と次の一手の提案を返すべきか？

一言で言えば：

Agent は関数呼び出しではない。delegation needs an acceptance contract.

この境界の層がなければ、下流の Agent は上流の出力を高信頼の事実として受け取り、そのまま伝播させ続ける。上流が一度間違えば、後続の Agent は一歩ごとに「実行は成功したように見える」まま、チェーン全体はすでに航路を外れている。

系譜をたどる

古典的な Agent 理論において、autonomy はそもそも Agent が自身の行動と内部状態にある程度の制御権を持つことを意味し、外部システムに直接駆動されるだけの存在ではない。Wooldridge & Jennings による弱い Agent 概念の記述では、autonomy、social ability、reactivity、pro-activeness が中核の属性である。

Contract Net / FIPA というより古いマルチ Agent 研究の系譜も、タスク割り当てを一方向の命令とは捉えていない。割り当てを交渉としてモデル化する：initiator が call for proposals を出し、participant は propose も refuse もでき、initiator がそれを accept または reject する。「受け手がまず参加の可否を判断する」の原型はここに既にある。

現代の LLM Agent エンジニアリングにおける guardrails、tripwires、tool safeguards、human-in-the-loop interrupt も、本質的には同じ問題を扱っている：ルールを orchestrator の prompt で宣言するだけでなく、handoff や action の境界で実行可能な判断を行うことだ。

近年の LLM-MAS 失敗研究はリスク側の証拠を提供する。Cemri et al. の MAST（Multi-Agent System Failure Taxonomy）はマルチ Agent の失敗を system design、inter-agent misalignment、task verification などのカテゴリに整理する。error cascades、online auditing、constraint drift に関する論文も同じことを示している：初期の単一エラーが下流の Agent に受け入れられると、長いチェーンの中で軌跡レベルの失敗になる。

設計上の落とし穴

Veto boundary を「拒否してよい」とだけ書いてはいけない。実際に使える境界は、少なくとも次を返す：

  • 拒否タイプ：scope / precondition / policy / evidence / budget / schema
  • トリガーとなった証拠：どの入力か、どの制約か、どのツールリスクか
  • 回復の提案：どのコンテキストを補うか、どのツールへ降格するか、人間の確認が要るか
  • 終了セマンティクス：この拒否は hard stop（FATAL）か、再試行可能（RETRYABLE）か、orchestrator の仲裁に委ねる（ESCALATION）か

さもなければ「拒否権」は別種の不確実性になる：Agent 同士の責任の押し付け合い、無限の確認、リトライのループだ。

発展させうる記事の切り口

Agent 協調の境界についての記事に育てられる：

  • タイトル方向：Agent は関数呼び出しではない：マルチ Agent 協調に拒否権境界が要る理由
  • 主線の問い：orchestrator の命令権と sub-agent の自律性をどう線引きするか？
  • 鍵となる対比：prompt 内のロール宣言 vs runtime 内の acceptance contract
  • 既存の方向と接続：Trace Log、tool result role design、agent iteration harness
  • 結びの着地点：良い Agent runtime はすべての Agent をより従順にするのではなく、すべての handoff をより監査可能に、より拒否可能に、より回復可能にする

参考文献