Rakshana Balakrishnan（ラクシャナ・バラクリシュナン）は、Oracleのクラウドプロダクトリーダーであり、グローバルな顧客基盤向けのマルチクラウドと生成AIプロダクトを専門としている。
前回の記事で、私はマルチクラウド導入が組織にとって戦略的必須事項となっていることを強調した。多くの組織がこの必要性を理解している：2025年のFlexeraの調査によると、組織の86%（ダウンロードが必要）がすでにマルチクラウドを採用している。
組織がマルチクラウドの可能性を実現する上での主な課題は相互運用性だ。特にエージェント型AIの時代において、組織は自律型エージェントのネットワークがクラウド間でシームレスに連携できるようにする必要がある。
モデルコンテキストプロトコル（MCP）がエージェント中心のAIシステム向けの新しいオープンソース標準として登場する中、私はその適用範囲をマルチクラウドエコシステムにまで拡張し、相互運用性のギャップを埋める機会があると考えている。
新たなエージェント型フロンティア：マルチエージェント製品
マルチエージェント製品は、企業が手動実行やルールベースのエンジンを超えて進化するのに役立つ。このモデルでは、製品のエンドツーエンドのユーザーワークフローが、独立して認識、推論、行動する一連のエージェントによって実行される。一方、監督エージェントがワークフローを監視し、人間のユーザーと協力して信頼性と透明性を確立する。
2つのパブリッククラウド（AWSとOracle）にまたがって運用し、エージェント型セキュリティインシデント管理製品を構築したいフィンテック企業を考えてみよう。監督エージェントとともに、5つの下位エージェントがそれぞれ異なる自律的なタスクを実行する：
• 検出エージェントは各クラウドにおけるセキュリティ標準への非準拠を検出し、ワークフロー管理ツールにインシデントを記録し、インシデント対応チームに通知する。
• 評価エージェントは重大度を分析し、コンテキストデータを組み合わせ、各クラウド環境に適した自動化ランブックを選択してインシデント対応計画を作成する。
• 修復エージェントは、影響を受けた各クラウド環境でロールを引き受け、実装可能なインシデント（ストレージオブジェクトの保存時の暗号化の有効化や、古いコンテナイメージのパッチ適用など）を修復する。自動修復を超えるインシデントについては、手動修復が必要であることをインシデント対応チームに通知する。
• 監視エージェントは両方のクラウド環境を一元的に可視化し、影響を受けたインスタンスの健全性と修復までの残り時間をリアルタイムで確認できるようにする。
• レトロスペクティブエージェントは、修復が成功した後に修復レポートの要約を作成し、脆弱性の領域を概説し、インシデントの再発を減らすための行動計画を作成する。
しかし、ここに課題がある：これらのエージェントは各システム/データソースの異なるAPIに接続し、両方のパブリッククラウドにまたがるスキーマとIAMシステムを理解する必要がある。そうでなければ、評価エージェントは一方のクラウドでインシデントを診断するためのコンテキストデータを持たず、もう一方のクラウドの類似インシデントと関連付け、共有コンテキストを修復エージェントに渡すことができなくなる。
MCPのアドバンテージ
ここでMCPの出番だ。Anthropicによってオープンソース標準として開発されたMCPは、ホスト、クライアント、サーバーで構成されるプロトコルであり、相互運用性の障壁を打破し、エージェントを様々なデータソース、ツール、環境に接続する。
私の見解では、MCPがクロスクラウド環境でシステム間の対話を再定義する4つの方法は次の通りだ：
API差異の抽象化とクロスクラウドオーケストレーションの簡素化
Representational State Transfer（REST）などの最新のAPIは、リクエスト-レスポンスモデルを通じてシステムとアプリケーションが相互に通信できるように設計されており、各システムには独自の定義と構文がある。MCPはクラウドプロバイダー間のこれらのAPI差異を抽象化し、共通言語を作成することで、プラットフォームに関係なくデータ、コンピューティング、サービスへの一貫したアクセスを可能にする。
各クラウドが独自の言語を持っていると考えてみよう。MCPはエージェントに共通言語を話させる万能翻訳機のような役割を果たす。
一貫性を促進するステートフルなコンテキストの提供
システム間の通信には、各呼び出しを通じてステートレスな応答転送を行うRESTAPIで十分だ。一方、AIエージェントには、システムからステートフルで構文に依存しないコンテキストが必要であり、それがまさにMCPが提供するものだ。
上記の例では、評価エージェントはMCPサーバーを使用して、AWSクラウド上のNoSQLデータベースとOracleクラウド上のベクトルデータベースに接続し、双方向通信を確立することで、リソース構成、ログ、インシデントに関するより多くのコンテキストを取得する。
エージェント間の連携促進
エージェント同士が対話するために、GoogleはAgent2Agent（A2A）と呼ばれる別のオープンソースプロトコルをリリースした。これはMCPの使用を補完するものだ。MCPとA2Aを組み合わせることで、エージェントは進化するコンテキストを互いに共有し、タスクに関する集合的理解を構築できる。
例えば、GeminiLLMモデルを使用してGoogle Cloud上に構築されたエージェントは、動的に進化する共有コンテキストレイヤーを通じて、OpenAIモデルを使用してMicrosoft Azure上に構築されたエージェントと連携できる。
設計による可視性の実現
MCPに組み込まれた監査とコンテキストトレースにより、クラウド管理者はエージェントの活動とその思考連鎖の推論を完全に可視化できる。この透明性のレベルは監視を強化し、より安全で予測可能なマルチエージェント製品の動作をサポートする。
MCP採用時の考慮事項
どの相互運用性標準と同様に、組織は機会と課題の両方を評価する必要がある。MCPを安全に、コスト効率よく、確実に実装するのに役立つ3つの要素を以下に示す：
• セキュリティ：MCPを通じて公開されるシステムは最小権限の原則に従い、エージェントが特定のデータレコードに対して特定のアクションのみを実行するアクセス権を持つようにすべきだ。これにより攻撃対象領域が最小化され、クロスクラウドデータ侵害を試みる攻撃者からシステムを保護できる。
• エグレスコスト：あるクラウド内のエージェントがMCPを使用して別のクラウドからデータを取得する場合、ソースプロバイダーはアウトバウンドデータ転送料金を請求する可能性がある。これらのコストを効果的に管理するために、組織はペイロードを適切なサイズにし、標準的なインターネットエグレスよりも安価な場合がある専用インターコネクトオプションを検討すべきだ。
• パフォーマンス：複数のクラウドにまたがって運用されるエージェントは、マルチエージェントの目標を達成するために、高速でリアルタイムのコンテキストを必要とする。カスタマーサービスのシナリオでは、会話型チャットエージェントが顧客の問題を即座に解決するために、注文管理エージェントと連携する必要があるかもしれない。これは特に、エージェントとクラウド環境が地理的に分散している場合に困難になる。これを軽減するために、頻繁にアクセスされるコンテキスト用の短期間のキャッシュレイヤーを実装することで、クロスクラウドコールを減らし、鮮度を損なうことなく応答性を向上させることができる。
MCPはまだ発展途上だが、マルチクラウド環境におけるマルチエージェントアーキテクチャの相互運用性に対応する重要なステップだ。エージェントがコンテキストにアクセスし、異種システムと対話する方法を標準化することで、MCPは組織が単一のクラウドプラットフォームやツールセットにロックインされることなく、分散型AIワークフローを構築するのに役立つ。
