日本語

SnowflakeがNatomaを買収。MicrosoftがAgent 365を出荷。AnthropicがMCPをトンネリング。CTOのエージェントガバナンスロードマップに向けたパターンとは

CTOのエージェントガバナンスロードマップを巡って争うSnowflake、Microsoft、Anthropicの3つのMCP control plane

30日間で、主要なエンタープライズベンダー3社がModel Context Protocol（MCP）のガバナンスで動きました。CTO（最高技術責任者）への問いは、どれが勝つかではありません。次の更新サイクルの前にこのパターンを見抜けるかどうかです。

Snowflakeが実際に買収したもの

2026年5月27日、Snowflakeは AI エージェント向けに特化して構築されたエンタープライズMCPガバナンスプラットフォームNatomaを買収する確定契約を発表しました。Snowflakeのプレスリリースによると、この取引でSnowflakeのスタックに3つの機能が追加されます：認証済みMCPサーバーレジストリ、アイデンティティ層、アクセスポリシープレーンです。

実際の意味：Snowflakeの Cortex Agents、Snowflake Intelligence、Cortex Codeは、単一のガバナンスサーフェスを通じてエンタープライズのSaaSアプリ、データベース、API、プライベートクラウド（VPC）、オンプレミスシステムに到達できるようになります。サードパーティのAIプラットフォームも同じアクセスを得ます。すべてのエージェントアクションは監査可能で、すべての接続はポリシーによってゲート管理され、すべてのMCPサーバーはエージェントが使用できる前にレジストリを通過する必要があります。

Snowflakeの技術ブログは動機を直接的に述べています：MCP採用により、エンタープライズシステム全体でエージェントが増殖するにつれて、断片化されたガバナンス、shadow AI活動、データ漏洩リスクが生じているとしています。Natomaはデータウェアハウスをデータストアとしてだけでなく、ガバナンスファブリックに変えます。この取引に関するCIOの報道は、データ重力がガバナンスの判断を既存のデータウェアハウスが置かれている場所に引き寄せるという賭けとして捉えています。

重要なポイント

  • Snowflakeは2026年5月27日にNatomaを買収する意向を発表し、スタックに認証済みMCPサーバーレジストリ、アイデンティティ層、アクセスポリシープレーンを追加しました（Snowflakeプレスリリース、2026年）
  • Natoma取引は30日間で3件目の主要MCP-ガバナンスの動きです：Anthropicが5月19日にself-hosted sandboxesとMCP tunnelsを出荷し、Microsoftが5月28日から29日にAgent 365をAIのcontrol planeとして位置づけ、Snowflakeが5月27日に締めくくりました
  • 現在、3つの異なるプラットフォーム層がエージェントcontrol planeの所有権を争っています：データ層（Snowflake）、生産性層（Microsoft）、モデル層（Anthropic）

ほとんどのCTOがまだ言語化していないMCP買収パターン

Snowflake+Natomaのデータ層をハイライトした3層MCPコントロールプレーンの図

落とし穴は間違ったベンダーを選ぶことではありません。落とし穴は、これらの動きのそれぞれを孤立した製品発表として扱い、順序に沿って展開する単一のパターンとして捉えないことです。

パターンはこうです：すべての主要エンタープライズプラットフォームベンダーが、MCPが技術的に成熟しているからではなく、今ガバナンスの所有権を確立した者が次の5年間のエンタープライズエージェント購買ルールを設定するから、MCP control planeの所有権を競っています。

3社はどの層がガバナンスのアンカーを得る権利を持つかについて、構造的に異なる3つの賭けを代表しています。

データ層（Snowflake+Natoma）。 ここでの賭けはデータ重力が勝つというものです。エンタープライズはすでにセンシティブなデータをウェアハウスに集中させています。ガバナンスがデータに追随するなら、ウェアハウスのオペレーターはそのデータに触れるすべてのエージェントのポリシー実施者として自然な立場になります。Natomaのレジストリ、アイデンティティ層、ポリシープレーンはそのデータ重力に直接落ち込みます。

生産性層（MicrosoftのAgent 365経由）。 Agent 365を通じた5月下旬のMicrosoftの賭けは、エンタープライズのワークフロー層がガバナンスを所有するというものです。なぜならエージェントがワークフローから価値を引き出すからです。エージェントがMicrosoft 365、Teams、Copilot Studioに存在するなら、Entra IDとAzureに織り込まれたアイデンティティとポリシーのファブリックがエージェントコントロールの自然な拠点です。生産性スイートはすでにユーザーが誰か、何を行う権限があるか、どのシステムに到達できるかを知っています。

モデル層（self-hosted sandboxesとMCP tunnels経由のAnthropicによる）。 5月19日に出荷されたAnthropicの動きは異なる議論です：顧客のセキュリティ境界内でエージェント実行環境を運用する。Anthropicのself-hosted sandboxesとMCP tunnelsは、エンタープライズエージェントが単一のアウトバウンドゲートウェイを通じてプライベートシステムに到達できるようにします。インバウンドのファイアウォール露出はありません。モデルベンダーが信頼のアンカーとなります。なぜなら推論がどこで起き、プライベートシステムにどのようにアクセスするかをコントロールするからです。

これらの賭けのどれも間違っていません。3つとも一貫性があります。しかし、唯一のガバナンス層としては互換性がなく、3社のベンダーはそれぞれ自社のものをまさにそのように売り込んでいます。

パターンが安定する前に1つの層のcontrol planeにコミットするCTOは、更新サイクルが想定外のロックイン状況を生む瞬間まで機能するガバナンスアーキテクチャを構築するリスクを負います。

データ層の主張が異なる理由

Snowflakeの議論は他の2つと構造的に異なるため、個別に検討する価値があります。

生産性層の主張（Microsoft）とモデル層の主張（Anthropic）はどちらも、既存のソフトウェア関係を通じたネットワーク効果に依拠しています。Microsoftのレバレッジは、従業員がすでにTeamsとOutlookで生活しているというものです。Anthropicのレバレッジは、開発者がすでにClaudeで構築しているというものです。両方の主張が言うのは：あなたはすでにXについて私たちを信頼している、今はそれをエージェントガバナンスに拡張してほしいということです。

Snowflakeの主張は異なります。ガバナンスはデータが動かないからデータに追随すべきだと言います。センシティブなエンタープライズレコードはウェアハウスにあります。コンプライアンス要件はすでにウェアハウスに付随しています。セキュリティコントロールはすでにウェアハウスを包んでいます。Natomaのレジストリとポリシープレーンは、新しいサーフェスへの信頼の拡張を求めません。すでに信頼されているサーフェスにガバナンスを付加します。

その議論は製品ブリーフィングで見えるよりも構造的に強力です。Snowflakeが最良のAI企業であることを信じる必要はありません。データ重力が実在し、コンプライアンスチームがエージェントアクションを承認する前に常に「データはどこにあるか」を聞くということを信じるだけでよいのです。

ただし「構造的に一貫している」を「戦略的に安全」と混同しないでください。Snowflakeのデータ層ガバナンス主張を受け入れることは、Snowflakeのインフラ上に構築されていないエージェントを含む、スタック全体のすべてのエージェントに対するポリシー実施ポイントとしてSnowflakeを受け入れることを意味します。議論がどれほどきれいであっても、これは重大なアーキテクチャの集中化です。

ガバナンス層でのベンダーロックインリスクの評価フレームワークについては、AIソブリンティとベンダーロックインに関する記事で依存パターンをより詳細に扱っています。

MCPのcontrol planeに対する4問のCTOテスト

Snowflake、Microsoft、AnthropicのどのベンダーのMCPガバナンスアプローチにコミットする前でも、これら4つの問いを実施してください。

1. 認証済みMCPサーバーレジストリ：MCPサーバーのインストールが安全であることを誰が保証するか？ MCP control planeには、承認済みサーバーの署名付き集中管理リストが必要です。各ベンダーに問いてください：サーバーをレジストリに登録するプロセスは何か？誰が監査するか？登録済みサーバーが侵害された場合どうなるか？その答えで、レジストリが実際のセキュリティメカニズムか製品チェックリスト項目かがわかります。

2. アイデンティティモデル：エージェントはユーザーのアイデンティティを継承するか、エージェント自身のサービスアイデンティティを使用するか、その両方か？ この問いには重大な下流の結果があります。エージェントがユーザーのアイデンティティを継承する場合、そのユーザーが到達できるすべてのシステムへのユーザーレベルのアクセスを持ちます。独自のサービスアイデンティティを使用する場合、別の権限モデルが必要です。両方を使用する場合（一部のアクションには委任されたアイデンティティ、他のアクションにはサービスアイデンティティ）、どのアクションがどちらのモデルを使用するかについて明確にする必要があります。ここでの曖昧な答えは製品のギャップではなくガバナンスリスクです。

3. ポリシーエンジン：「エージェントXがシステムZでアクションYを実行できる」はどこで実際に評価されるか？ ポリシーエンジンは、特定のコンテキストでエージェントが何を許可されるかを決定するランタイムロジックです。一元化されている（システム全体でポリシーの断片化がない）、監査可能（判断を再構成できる）、エージェントを使用不能にするレイテンシを引き起こさない速度を持つ必要があります。ポリシーエンジンがどこで動くか、どのように更新されるか、ポリシー評価が同期かキャッシュかをベンダーに問いてください。

4. 監査証跡：どのエージェントが誰のために、どのレコードに対して何をしたかを完全に再構成できるか？ 「監査証跡」は「ログ」と同じではありません。監査証跡は因果関係の問いに答えます：エージェントはなぜこのAPI呼び出しを行ったか、どのデータを取得したか、誰の承認を使用したか、その結果何が変わったか。ベンダーの監査に関する説明が「サーバーログが得られる」であれば、「発生したユーザーアクションへの因果リンクを持つ構造化されたイベントストリームが得られる」とは異なる答えです。どちらを購入しているかを把握してください。AI実行アクションの監査証跡リソースでは、本番対応の監査アーキテクチャの内容を取り上げています。

より広い評価フレームワークについては、AI承認ゲートとベンダー審査ガイダンスが有用な補完となります。

よくある質問

SnowflakeのNatoma買収とは何ですか？

NatomaはAIエージェントのデプロイに認証済みサーバーレジストリ、アイデンティティ層、アクセスポリシープレーンを追加するエンタープライズMCPガバナンスプラットフォームです。Snowflakeは2026年5月27日にNatomaを買収する意向を発表しました。この取引により、Snowflakeはデータウェアハウスの既存のセキュリティコントロールをバイパスすることなく、Cortex AgentsとサードパーティのAIプラットフォームが単一の監査可能なコントロールサーフェスを通じてエンタープライズシステムに接続できるガバナンスファブリックを手に入れます。

2026年にMCP control planeが突然調達の戦場になったのはなぜですか？

MCP（Model Context Protocol）はAIエージェントが外部ツールやデータソースに接続する方法の新興標準です。エンタープライズのエージェント採用が加速するにつれて、どのエージェントがどのシステムに接続できるかを管理するポリシー層を制御する者は、大きな調達レバレッジを得ます。3社の主要ベンダー（Snowflake、Microsoft、Anthropic）が30日間でMCPガバナンスについて異なる動きをしました。競争はMCPが成熟しているからではありません。標準がまだ形成中で、エンタープライズがまだアーキテクチャにコミットしていない今のうちにガバナンスの所有権を確立するためです。

CTOは1つのベンダーのMCP層にロックインされることをどうやって避けるべきか？

最初の動きは、ベンダーを評価する前に上記の4つの問いを使って独自のMCP control plane評価基準を作成することです。それによりベンダー中立な基準が得られます。2番目の動きは、現在MCPを使用しているエージェントと、それらがすでに触れているコントロールサーフェスを洗い出すことです。MCPに接続されたエージェントのほとんどがMicrosoft 365を通じて動作している場合、意図せずとも生産性層のキャンプに部分的に入っています。それを可視化することで、製品採用を通じて引き継ぐのではなく、意図的なアーキテクチャ上の選択をすることができます。

今月CTOがすべきこと

完全なベンダー評価サイクルより少ないコストで、必要なガバナンス姿勢を確立する4つの具体的なアクション：

  • 1ページのMCP control plane評価基準を作成してください。 上記の4問テストを使用してください。1ページは優先順位付けを強制します。ベンダーが発表する前にセキュリティチームと調達チームに共有してください。そうすればベンダーのプレゼンをベンダーの基準ではなく、自社の基準で評価できます。

  • 現在MCPを使用しているエージェントと、それらが触れているコントロールサーフェスを洗い出してください。 これは完全な監査を必要としません。エンジニアリングリードに問いてください：どのエージェントが動作しているか、MCPコネクションを使用しているものはどれか、今日それらのコネクションのアイデンティティやポリシー層を処理しているのはどのベンダーか。答えはおそらく驚くべきものです。

  • 次の更新サイクルの前に、3社のベンダーそれぞれとの30分の会話をスケジュールしてください。 製品デモではありません。ガバナンスアーキテクチャの会話です。4つの問いを持参してください。具体的に問いてください。ベンダーが明確に（流暢に、ではなく）答える能力が、control planeの物語が実際にどれほど成熟しているかを多くのことを語ります。

  • エージェントをデータ分類フレームワークにマッピングしてください。 本番環境でMCPコネクションが承認される前に、エージェントはアクセスするデータ分類層を把握すべきです。AIアクセスのためのデータ分類リソースでは、そのマッピングの構築方法を扱っています。これがなければ、上記のcontrol plane評価は実施可能なサーフェスのないポリシー判断です。

パターンは急速に動いています。しかし正しい対応は最初に信頼性があるように見えるベンダーを選ぶことではありません。3つのオプションがまだ真に利用可能な今のうちに、独自の評価フレームワークを確立することです。

さらに詳しく