複数のAIエージェントを組み合わせ、問い合わせ対応、業務自動化、意思決定支援までを一気通貫で回す「マルチエージェント」への期待が高まっています。ところが現場では「エージェント同士が会話（メッセージ交換）はできるのに、なぜか全体最適にならない」「連携しているのに手戻りが増える」という壁に突き当たります。
CiscoのOutshiftが提案する「Internet of Cognition（IoC）」は、このギャップを“通信”ではなく“意味的な協調”の問題として捉え直し、意図・文脈・学習を共有するための新しいアーキテクチャを提示します。本稿では、MCP/A2Aの到達点と限界、医療予約の例で見える実害、そしてIoCの全体像と導入検討の論点をB2B視点で整理します。
1. AIエージェントは「会話」できても「共同思考」できない理由
現在のAIエージェントは、API呼び出しやツール実行、他エージェントへのメッセージ送信など「やり取り」の能力が急速に整備されました。しかし、業務で求められるのは単なる分業ではなく、同じゴールに向けて推論をすり合わせ、学びを積み上げ、矛盾を解消しながら意思決定する「共同思考」です。
共同思考が難しい根本原因は、エージェントが内部で持つ推論の前提（なぜそれをするのか、何を優先するのか、どこまで確信しているのか）が、次のエージェントに引き継がれない点にあります。結果として、各エージェントは自分のタスク範囲の中で合理的に動いても、全体としては最適化されません。
さらに、マルチエージェントでは「調整コスト」が顕在化します。目標の解釈違いを埋めるための確認、重複作業、例外処理の往復が増え、処理サイクル（時間・トークン・API費用）を消費します。個々の性能が上がるほど、皮肉にも“つながっているのに噛み合わない”問題が目立つようになります。
2. MCP/A2Aの限界：メッセージは共有できても意図・文脈が共有できない
MCP（Model Context Protocol）やA2A（Agent-to-Agent）系の枠組みは、エージェントがツールを発見し、メッセージを交換し、連携するための「接続性と識別」のレイヤーを整えました。OutshiftがLinux Foundationに寄贈したAGNTCYのような取り組みも含め、業界は“エージェントが話せる”状態に近づいています。
一方で、これらが主に扱うのは構文（syntax）です。つまり「どのツールをどう呼ぶか」「どの相手にどう送るか」といった機械的な連携であり、意味（semantics）である「意図」「優先順位」「前提」「制約」「不確実性」「交渉の余地」を共有する仕組みは弱いままです。
このギャップが生む典型症状は次の通りです。
- 同じゴールを別々に解釈し、部分最適の結果が衝突する
- 文脈が引き継がれず、毎回“最初から説明”が必要になる
- あるエージェントの学び（発見・例外パターン）が他に波及せず、組織知にならない
- コンプライアンスやポリシー制約が推論に統合されず、後段で差し戻しが起きる
Outshiftの指摘は明快です。「メッセージは送れるが、エージェント同士が相手の狙いを理解できない」。この状態では、グラウンディング（共通の前提合わせ）、ネゴシエーション（条件調整）、コーディネーション（役割分担の最適化）が成立しにくく、マルチエージェントの価値である“学習の複利”が生まれません。
3. 医療予約の例で見る実害：連携しているのに最適化できない多エージェント
実害をイメージするために、患者が専門医の予約を取るケースを考えます。症状評価エージェント、予約エージェント、保険確認エージェント、薬局（在庫）エージェントが連携しているとします。MCPのような仕組みで、症状評価が診断コードを渡し、予約が空き枠を探し、保険が適用可否を確認し、薬局が薬の在庫をチェックする。ここまでは「連携している」ように見えます。
しかし、共同思考ができないと次のようなズレが起きます。薬局エージェントが推奨した薬が、患者の既往歴と相性が悪い可能性があるのに、症状評価エージェントは「薬物相互作用の検討」が自分のスコープ外だと判断して情報を渡さない。予約エージェントは最短の空き枠を押さえるが、保険エージェントは別施設の方が自己負担が小さいことを見つけている。それでも予約は確定してしまい、患者にとっての最適解（適切なケアを、適切な条件で受ける）が実現しません。
重要なのは、どのエージェントも“自分のタスク”は完遂している点です。失敗の原因は能力不足ではなく、ゴール状態の共有と、意思決定の前提・制約の共有が欠けていることにあります。企業システムでも同様で、営業支援・在庫・与信・物流がそれぞれ最適化しても、顧客価値や利益最大化に結びつかない「連携の空回り」が起こり得ます。
4. Outshift提案「Internet of Cognition」全体像：意味的コラボレーションへの転換
Outshiftが提案するInternet of Cognition（IoC）は、マルチエージェントを「メッセージ交換する個体の集合」ではなく、「共有された認知状態の上で協調するシステム」として再設計しようという構想です。狙いは、接続性の上に“意味のレイヤー”を追加し、エージェントが行動前に目標と前提をすり合わせ、行動後に学びを共有して複利を生む状態を作ることです。
Outshiftは、共同思考には少なくとも次の共有が必要だと整理します。
- データセットを横断したパターン認識（何が起きているか）
- 行動と結果の因果関係（何をすると何が起きるか）
- 明示的なゴール状態（何を達成したいか、何を優先するか）
この共有がない限り、エージェントは「意味的に孤立」し、調整にコストを払い続けます。IoCは完成品というより、インターネット初期のように業界の合意形成と標準化を促す“呼びかけ”として位置づけられています。企業にとっては、今使っているエージェント基盤を否定する話ではなく、「連携の次に何を足すべきか」を示すロードマップとして読むのが実務的です。
5. 3つの構成要素：Cognition State Protocols／Cognition Fabric／Cognition Engines
Cognition State Protocols：意図と理由を運ぶセマンティック層
Cognition State Protocolsは、メッセージパッシングの上位に位置する“認知状態”のプロトコルです。データや指示だけでなく、「何を目指しているのか」「なぜその判断に至ったのか」「どの制約を満たす必要があるのか」を表現し、エージェント間で合意形成できるようにします。行動してから誤解を解くのではなく、行動前にゴール整合を取る設計思想が中心です。
Cognition Fabric：共有文脈を維持する分散ワーキングメモリ
Cognition Fabricは、エージェントが参照する共有コンテキストを構築・維持する基盤です。単なるログではなく、コンテキストグラフのように関係性を保った形で、やり取りをまたいで文脈を永続化します。加えて、何を誰と共有してよいかを制御するポリシーが重要になります。企業利用では、部門境界、顧客情報、規制対象データなど、共有してはいけない情報が常に存在するためです。
Cognition Engines：学習の複利と統制を両立する実行レイヤー
Cognition Enginesは大きく2つの役割を想定します。1つはアクセラレーターで、あるエージェントの発見（有効な手順、例外パターン、推奨判断）を他のエージェントが再利用し、学習を複利で増やす仕組みです。もう1つはガードレールで、共有推論がコンプライアンスや社内ポリシーを逸脱しないように境界を設けます。共同思考は強力であるほどリスクも増えるため、推論の共有と統制を同じ設計の中で扱う必要があります。
6. 導入・標準化の論点：ガバナンス、相互運用性、企業利用でのチェックポイント
IoCのようなアーキテクチャを企業が検討する際、技術以上に重要になるのがガバナンスと標準化の設計です。特にマルチベンダー環境では、特定製品に閉じた“共有文脈”は新たなロックインになり得ます。Outshift自身も、業界全体の協調が必要だと示唆しています。
ガバナンス：共有するほどリスクが増える
意図・文脈・学びを共有するほど、漏えい、目的外利用、説明責任の問題が増えます。誰がどの認知状態にアクセスでき、どの目的で利用でき、いつ破棄されるのか。さらに、誤った共有（古い情報や偏った判断）が全体に伝播するリスクもあります。ガバナンスは「禁止」ではなく、共有の単位・範囲・監査可能性を設計することが要点です。
相互運用性：エージェントの“意味”をどう揃えるか
相互運用性の焦点はAPI互換だけではありません。「ゴール状態」「制約」「確信度」「根拠」などの表現を、異なるモデル・異なるベンダーのエージェント間でどう一致させるかが本丸になります。業務ドメインでは用語体系も異なるため、オントロジーやポリシー言語、コンテキストのスキーマ設計が実装成否を左右します。
企業利用でのチェックポイント
- 目的定義：全体ゴールと優先順位（コスト、品質、リスク、顧客体験）を明文化できているか
- 共有範囲：どの文脈を共有し、どれを分離するか（顧客別、部門別、リージョン別）
- 監査性：誰が何を根拠に判断したかを追跡できるか（後追い説明が可能か）
- 安全性：ガードレールが推論・共有のプロセスに組み込まれているか（後段の人手審査頼みになっていないか）
- 学習の再利用：成功パターンが“別案件でも”再利用される設計になっているか（単発自動化で終わらないか）
- ベンダー戦略：共有文脈やプロトコルが特定基盤に閉じないか（将来の乗り換え余地）
マルチエージェントの投資対効果は、単体自動化の積み上げではなく、協調による“複利”が出るかどうかで決まります。そのため、PoCではタスク成功率だけでなく、調整回数、差し戻し、例外処理の減少、学びの再利用率といった指標も合わせて設計すると、IoC的な価値を評価しやすくなります。
エージェントはすでに会話できます。しかし企業が本当に欲しいのは、会話の先にある共同思考です。MCP/A2Aは連携の土台を作りましたが、意図・文脈・学びが共有されない限り、マルチエージェントは“つながっているのに最適化できない”状態から抜け出せません。OutshiftのInternet of Cognitionは、認知状態のプロトコル、共有文脈の基盤、学習の複利と統制を担うエンジンという3層で、意味的コラボレーションへ転換する方向性を示します。導入にあたっては、ガバナンスと相互運用性を最初から設計に織り込み、「接続できたか」ではなく「同じゴールに向けて協調できたか」を評価軸に据えることが、次の競争力につながります。
