引き継ぎ失敗が本番を壊す
個々のエージェントが賢くても、受け渡し設計が甘ければシステムは壊れる。本番の8割を壊す協調ギャップを解剖する。
01 — 「引き継ぎ」とは何か：コンテキスト喪失のメカニズム
AIエージェントの連携において「引き継ぎ」とは、あるエージェントが処理した出力を、次のエージェントが入力として受け取る瞬間のことだ。この瞬間に三種類の断絶が生じる。
- コンテキスト喪失：エージェントAが保持していた「なぜこの判断をしたか」という文脈情報は、出力テキストには含まれない。エージェントBは結論だけを受け取り、その背景を知らない。推論の連鎖が最初の受け渡し時点で切断される。
- フォーマット契約違反：エージェントBがJSON形式のデータを期待するよう設計されているのに、エージェントAが自然言語テキストを返すケースは頻繁に起きる。パース失敗は静かに起こり、下流のエージェントはその事実を知らないまま処理を続けることがある。
- 状態の曖昧性：どちらのエージェントもエラーの「所有者」ではない。エージェントAは「渡した」、エージェントBは「受け取っていない（または解釈できなかった）」という状態が共存し、エラー処理の責任の所在が定まらない。
この問題が見過ごされやすい理由は、個々のエージェントが単体テスト環境では完璧に動作するからだ。テストではエージェントBに「正しい形式の入力」を与える。本番ではエージェントAからの「実際の出力」が来る。この差が本番障害として顕在化する。
02 — 8割の壊れ方：失敗モードの内訳
本番AIシステムの障害分析では、複数エージェント連携における引き継ぎ設計の欠陥が主因として繰り返し登場する。失敗は三つのパターンに収束する。
特に深刻なのは「静かな失敗」だ。フォーマット不一致や状態の曖昧性によって生じた障害は、即座にエラーとして表面化せず、下流の出力品質が静かに劣化する形で現れることが多い。障害に気づくのが遅れるほど、デバッグに要するコストは増大する。
単体では優秀なエージェントが、連鎖の中では凡庸なシステムを構成する — これが引き継ぎ問題の核心だ。個々の性能指標がいくら高くても、境界面の設計が貧弱であれば全体の信頼性は低下する。
03 — 本番を生き延びる引き継ぎ設計：三原則
エージェント連携を設計するなら、以下の三原則を引き継ぎ設計の基盤に置く。単体利用の読者は現時点でこのセクションを気にする必要はない。
原則1
明示的スキーマ
エージェント間のインターフェースをJSONスキーマや型定義で明示的に契約化する。「暗黙の了解」でフォーマットを共有する設計は、いずれ本番で破綻する。バリデーションは受信側で必ず実施する。
原則2
冪等性リトライ
引き継ぎが失敗した場合、同じ操作を安全に再実行できる設計にする。副作用のある処理は冪等性を保証し、リトライが二重実行を生まない仕組みを組み込む。エラーの「所有者」を明示的に指定する。
原則3
人間エスカレーションパス
いかなるエージェント連鎖にも、自動回復できない状況で人間にエスカレーションするパスを設計する。沈黙する失敗より、明示的に人間の判断を仰ぐ設計のほうが、長期の信頼性を担保する。
エージェントを繋ぐ設計において、引き継ぎは「実装の細部」ではなく「システムの中核」だ。境界面の設計に最初から投資しないシステムは、本番で必ず高い代償を払うことになる。
AI Navigate 編集部 — 本記事は2026-06-22時点の観測に基づく。障害率の数値は複数の事例分析から導出した参考値であり、個別環境での実測値を優先すること。