複数の AI Agent が協働するとき、メッセージの伝達順序や経路は通信プロトコルが管理します。しかしプロトコルが正しくても、システムは失敗し得ます。各 Agent が不完全な、あるいは互いに矛盾する context を抱えているからです。A が顧客データを更新したのに、B は古い版のまま作業を続ける。リサーチ Agent が得た結論が、執筆 Agent に届いていない。これは個別チームの運の問題ではありません。カリフォルニア大学バークレー校の MAST 研究（Cemri ら、NeurIPS 2025）は、主要な 7 つのマルチエージェントフレームワークの 1,642 件の実行トレースを分析し、14 の失敗モードを特定しました。そのうち約 4 割は「エージェント間の不整合」——context が引き継がれない、前提が食い違う、先の決定が後続の Agent に忘れられる——に分類されます。Devin を開発した Cognition チームは 2025 年のエンジニアリングノートでさらに率直に述べています：マルチエージェントシステムの失敗の多くは、「システム内のどこかで context が欠けていること」に帰着する、と。本記事はメッセージ伝達のルールや協働トポロジーには触れません。Agent 間の context・記憶・タスク状態をどこに置き、どう受け渡し、どう一貫性を保つか——マルチエージェントシステムの本当の情報骨格だけを扱います。
「状態」という言葉を分解して初めて、それぞれに適した管理メカニズムが見えてきます。マルチエージェントシステムには少なくとも三層があります：
主要フレームワークの設計は、この分層をそのまま裏付けています。LangGraph は二つの並行する永続化メカニズムを提供します：checkpointer は単一スレッド内の短期状態（会話の連続性、中断からの再開）を、Store はスレッド横断の長期記憶（ユーザーの好み、蓄積知識）を担当し、公式ドキュメントは両者を混同せず併用することを明確に推奨しています。CrewAI は記憶を四つの機能に分けます：短期記憶、長期記憶、人や物事の追跡専用の実体記憶、それらを組み立てる contextual memory 層です。旧バージョンでは ChromaDB と SQLite に別々に保存していましたが、現行版は単一の統合 Memory API にまとめられています。この分層の理論的な源流は、バークレーの 2023 年の MemGPT 論文（Packer ら、arXiv 2310.08560）に遡れます。オペレーティングシステムのメモリ階層の概念を借り、限られたコンテキストウィンドウを「主記憶」とみなし、収まらないものは外部ストレージへ移し、LLM 自身が関数呼び出しで二層間のデータ移動を行う——この「仮想 context 管理」は後に Letta フレームワークへと発展し、Agent 記憶アーキテクチャの重要な参照点となりました。三層の混用はよくある誤りです：短期 context を長期記憶に詰め込めば知識ベースはノイズだらけになり、長期知識を毎回の対話に押し込めばコンテキストウィンドウが破裂します。
Agent 間の状態の受け渡しは、実務上二つのパターンの組み合わせです。
共有ストア（ブラックボードパターン）：すべての Agent が同一の中央状態を読み書きし、誰かが更新すれば全員が最新版を見られます。タスク状態のような全体同期が必要な情報に適しています。利点は単一の真実の源であること、代償は並行書き込みとアクセス権限の処理です。
引き継ぎペイロード（context handoff）：Agent は一区切りの作業を終えると、成果を構造化された引き継ぎ物——要約、キーフィールド、結論——に精錬して次の Agent へ渡します。推論過程を丸ごと流し込むのではありません。Anthropic が 2025 年に公開したマルチエージェントリサーチシステムのエンジニアリング記録は、この二つのメカニズムを併用した実例です：リード Agent はまずリサーチ計画を外部 Memory に保存します（コンテキストウィンドウが 20 万トークンを超えると切り詰められるため、計画はウィンドウの外に置かなければ守れません）。一方、各サブエージェントは「インテリジェントなフィルター」として、大量の検索を自ら実行した後、凝縮した発見だけをリード Agent に返して統合させます。コストも具体的です：この種のマルチエージェントシステムのトークン使用量は通常のチャットの約 15 倍。その見返りとして、Claude Opus 4 をリード、Sonnet 4 をサブエージェントとするシステムは、社内リサーチ評価で単一の Opus 4 を 90.2% 上回りました。
どの程度共有すべきかについて、業界には一見相反する二つの答えがあります。Cognition の原則は「可能な限り完全な context を共有せよ」：結論だけでなく完全な行動トレースまで渡すべきで、省略された細部が下流のタスク解釈を変え得るからです。だからこそ彼らは、マルチエージェント化を急ぐ前に単一 Agent で通貫させることを勧めています。一方 Anthropic の実践は「精錬してから引き継ぐ」：サブエージェントは凝縮した発見だけを返し、リード Agent が生データに溺れないようにします。両者は実は矛盾しません——違いは情報フローの方向です。下流へ仕事を委ねるときは context を多めに（タスク目標、境界、既知の前提）与え、下流が誤った前提で作業を始めるのを防ぐ。上流へ報告するときは先に精錬し、結論と重要な証拠だけを渡す。運用可能な境界線は次の通りです：
| 情報タイプ | 推奨範囲 | 理由 |
|---|---|---|
| タスク目標と進捗 | 全体共有 | すべての Agent が同じ目標に整合する必要がある |
| 各 Agent の最終成果物 | 共有（精錬後） | 下流に必要なのは結論であり過程ではない |
| 中間推論、下書き | 非公開 | ノイズであり、共有は他者の妨げにしかならない |
| 長期知識、企業ルール | 共有・読み取り専用 | 共通基準であり、単一 Agent が勝手に変更すべきでない |
長期知識を読み取り専用にするだけでは足りない場合は、さらに一歩進めます：全員読み取り専用とし、指定された記憶管理 Agent だけが書き込み可能にして、集約と更新をその Agent に委ねる——一貫性と保守性の両立です。
共有状態の最も危険な失敗は「陳腐化した読み取り」です——A は更新済みなのに B は古い版で作業を続け、両者の結論はそこから分岐します。MAST が分類した「エージェント間の不整合」の中には、まさに「他の Agent が提供した情報の忘却」という失敗モードがあります。実務的な対策をいくつか：
共有状態の目標は「すべてを記録し、すべてを伝える」ことではなく、各 Agent が必要なときに、正確で最新の context をちょうど手にできるようにすることです。
Gartner は 2028 年までに企業向けソフトウェアの 33% がエージェント型 AI を組み込むと予測しています（2024 年は 1% 未満）。同時に、エージェント型 AI プロジェクトの 4 割超が 2027 年末までに中止されるとも警告しています——分かれ目はしばしば、基礎エンジニアリングを正しくやったかどうかです。マルチエージェントシステムの安定には、正しい通信プロトコルだけでは足りず、よく設計された情報骨格——状態をどこに置くか、記憶をどう分層するか、context をどう精錬して引き継ぐか、一貫性をどう守るか——が必要です。恩梯科技（Nerdtechnic）の AI システムコンサルティングサービスは、各 Agent に必要な共有状態と非公開状態の棚卸しを支援し、分層された記憶アーキテクチャと引き継ぎメカニズムを設計します。複数の AI Agent がそれぞれの思い込みに固執して迷走するのではなく、同じ最新の事実の上で本当に協働できるようにします。
これらの手法を自社に導入したいですか？
LINEで無料相談
技術共有
多くのブランドはチャネルごとに別々のAIボットを設置し、音声・チャット・CRMがかみ合わず、同じ顧客がつながりのない断片に分割されています。本記事では、CXMのチャネル横断統合を三層——統一顧客ビュー、システム統合、チャネル横断のオーケストレーション——として実データとともに読み解き、あらゆる接点が同一の顧客レコードの上に成り立つ仕組みを示します。
技術共有
会話が長くなるほど AI はなぜ高く、そして散漫になるのでしょうか。本稿は Chroma や Anthropic などの最新研究データをもとに、スライディングウィンドウ、要約圧縮（compaction）、分割による外部退避、重要情報のピン留めという四つの戦略と、その組み合わせ方を解き明かします。
技術共有
多くの企業は AI への権限委譲を白か黒かのスイッチとして扱い、全件を人が審査するか、すべてをシステムに自動で任せるかのどちらかになりがちです。しかし Gartner は、リスク管理の不足により agentic AI プロジェクトの 40% 超が 2027 年までに中止されると予測しています。本記事は人間工学と AI エージェントの実在する分級枠組みをもとに、全件人手審査から完全自律までの五段階の権限委譲の階段を示し、定量的な昇格基準と品質低下時のサーキットブレーカーによるフォールバックまでを扱います。
サポートが必要ですか？
ここをクリックしてお問い合わせください！
