マルチベンダーエージェントの現実
2026年の典型的なエンタープライズは、少なくとも3つのベンダーのAIエージェントを運用しています：
- Salesforce AgentforceがSales、Service、Marketing自動化を処理
- Microsoft Copilot StudioがOffice中心のワークフローとITヘルプデスクを管理
- Google Vertex AIがデータ分析とカスタムMLパイプラインを駆動
- ServiceNowがITサービス管理とHRリクエストを自動化
- カスタムエージェントがLangGraph、CrewAI、または社内フレームワークで構築されギャップを埋める
これは仮説的な未来ではありません。既存のソフトウェアベンダーからAIエージェントを採用したすべてのエンタープライズの現実です。そしてこれらのベンダーのどれも解決する装備を持っていないガバナンス問題を生み出します。
シングルベンダーガバナンスが失敗する理由
各ベンダーは自社のエージェントのみガバナンスします：
- SalesforceはEinstein Trust Layerを使用してAgentforceエージェントをガバナンス — ただしSalesforce内で実行されるエージェントのみ
- ServiceNowはNow Assistガードレールを使用して自律エージェントをガバナンス — ただしITSMとHRワークフローのみ
- MicrosoftはCopilot Studioポリシーを通じてCopilotアクションをガバナンス — ただしOffice 365インタラクションのみ
- GoogleはVertex AIモニタリングを提供 — ただしGCPにデプロイされたモデルのみ
結果はガバナンスサイロです。AgentforceのSalesエージェントが、顧客がメールを好むことを学びます。ServiceNowのITエージェントが同じ顧客のVPN問題をトラブルシューティングします。コンテキストは共有されません。統一された監査証跡もありません。一貫した承認ポリシーもありません。クロスベンダーメモリもありません。
CISOが「今四半期AIエージェントは何をしたか？」と尋ねた時、どの単一システムも答えられません。
プロトコル収束がクロスベンダー連携を可能にする
2つの新興標準がクロスベンダーエージェント連携を技術的に可能にしています：
MCP（Model Context Protocol） — AIエージェントを外部ツールとデータソースに接続するための標準。Microsoft Copilot Studio、n8n、100以上のプラットフォームがMCPをサポート。
A2A（Agent-to-Agent Protocol） — エージェントが機能を発見し、タスクを委任し、プラットフォーム間で状態を同期するための標準。Salesforce、Google、ServiceNow、SAP、PayPalが100以上のサポーターの中に。
MCP + A2Aは標準的なエンタープライズエージェント通信スタックを形成します。エージェントはMCPを使用してツールにアクセスし、A2Aを使用して他のエージェントと連携できます — どのベンダーが構築したかに関係なく。
しかしプロトコルサポートだけではガバナンスではありません。以下も必要です：
クロスベンダーガバナンスに実際に必要なもの
すべてのベンダーにわたって機能するガバナンスレイヤーには5つの機能が必要です：
1. プロトコル非依存の接続性
ガバナンスレイヤーはMCPとA2Aの両方を話す必要があります。一方を使用するベンダーもあれば、他方を使用するベンダーもあり、両方を使用するベンダーもあります。ガバナンスレイヤーはどちらかを選ぶことはできません — 両方のプロトコルを橋渡しする必要があります。
2. プロバイダー非依存のポリシー
承認ゲート、RBAC、予算コントロール、エスカレーションルールは、エージェントがSalesforce、ServiceNow、カスタムフレームワークのいずれで実行されているかに関係なく一貫して適用される必要があります。「ベンダーXのエージェントは$1,000以上のアクションに承認が必要」は、5つのベンダー固有の設定ではなく、単一のポリシーであるべきです。
3. 統一メモリ
異なるベンダーのエージェントが同じ顧客、プロジェクト、部門で作業する場合、共有コンテキストが必要です。すべてのエージェントプラットフォームにまたがる5層メモリ階層 — エンティティ、会話、ワークフロー、部門、仮想ファイルシステム。
4. 統合された監査証跡
すべてのベンダーにわたるすべてのエージェントアクションを記録する1つの監査ログ。誰が何をいつ、なぜ承認したか。どのエージェントがどのデータにアクセスしたか。コストはいくらか。既存のコンプライアンスインフラにエクスポート可能。
5. 部門レベルのオーケストレーション
エンタープライズの部門はベンダー境界にきれいにマッピングされません。法務は2つのベンダーのエージェントを使用。財務は3つ使用。ガバナンスレイヤーはベンダーごとではなく部門ごとにエージェントを整理する必要があります — ビジネスはそのように考えるからです。
市場が緊急性を裏付ける
数字が物語っています：
- エグゼクティブの**88%**がエージェンティックAIのAI予算を増加中（Capgemini）
- **79%**がAIエージェントが組織で既に採用されていると回答
- 100以上のエンタープライズがA2Aプロトコルをサポートし、マルチベンダーエージェント連携が業界の優先事項であることを示す
これは理論的な需要ではありません。エンタープライズは積極的に複数ベンダーのエージェントをデプロイし、ガバナンスが欠けているレイヤーであることを発見しています。
JieGouのアプローチ
JieGouはベンダー固有のエージェントプラットフォームの上のガバナンスレイヤーとして設計されています：
- デュアルプロトコルブリッジ：MCP（3層認証の245認証サーバー）とA2A（ホスト、コンシューマー、レジストリ）の両方を1つのガバナンスレイヤーでサポート
- 10層ガバナンス：承認ゲート、RBAC、監査ログ、BYOK暗号化、予算コントロール、プロンプトインジェクション検出、段階的自律性 — すべてのエージェントに一貫して適用
- 5層メモリ階層：エンティティ、会話、ワークフロー、部門、仮想ファイルシステムメモリがベンダーの出自に関係なくすべてのエージェントで共有
- 20部門カバレッジ：Sales、Marketing、Support、HR、Finance、Operations、Legal、Engineering、Executive、IT、Product Management、R&D、Product、Customer Success、Data & Analyticsの事前構築部門パック
- クロスベンダーアーキテクチャ：JieGouはSalesforce、Microsoft、Google、ServiceNow、カスタムエージェントプラットフォームの上に位置し、いずれも置き換えることなく統一ガバナンスを提供
エンタープライズアーキテクトへの意味
エンタープライズのエージェントアーキテクチャを設計する際、以下の原則を検討してください：
-
エージェント能力とエージェントガバナンスを混同しない。 Salesforceはセールスエージェントの構築に優れています。すべてのエージェントのガバナンスに最適な選択とは限りません。
-
初日からマルチベンダーを計画する。 1つのエージェントベンダーから始めても、追加します。ガバナンスアーキテクチャはマルチベンダーを前提とすべきです。
-
プロトコルコンプライアンスは調達に重要。 AAIFメンバーシップは拡大中（Salesforce、SAP、PayPal、Samsung）。標準コンプライアンスは調達のチェックボックスになりつつあります。
-
ガバナンスは別のレイヤー。 CRMをIDプロバイダーとして使用しないのと同じく、CRMをエージェントガバナンスプラットフォームとして使用すべきではありません。
ベンダー間で統一ガバナンスがどう機能するか見る準備はできましたか？
- アーキテクチャ図を見る — JieGouのクロスベンダーガバナンスアーキテクチャ
- ガバナンスアセスメントを受ける — マルチベンダーガバナンス準備状況を評価
- Enterpriseトライアルを開始 — フルガバナンス機能付き14日間トライアル