SnowflakeのCortex AI Gateway、エージェント制御の主導権を争う

SnowflakeはCortex AI Gatewayの発表後、google newsに登場した。これまでModel Context Protocolの接続は、エンタープライズ向けインフラというより開発者向け統合に近いものと見られていた。7月28日に発表されたこのゲートウェイは、アクセス方針、認証、アクティビティ記録、モデルルーティング、利用量制御を一元化する。Snowflakeによれば、100を超えるMCPサーバーに対応するという。

重要な変化は、コネクターカタログがまた一つ増えたことではない。Snowflakeは、AIエージェントと、それらのエージェントがアクセスできるモデル、ツール、データ、アプリケーションとの間に制御レイヤーを置こうとしている。この位置付けは、エンタープライズソフトウェア導入の初期段階でAPIゲートウェイやアイデンティティプラットフォームが担った役割に似ている。

Snowflakeだけではない。Databricks、Cloudflare、セキュリティベンダー、専門スタートアップも、同様の制御ポイントを構築している。争点はもはや、Model Context Protocolが広くサポートされるかどうかではない。エージェントが重大なアクションを実行し始めたとき、どのプラットフォームがMCPトラフィックを統制するかだ。

Snowflake、Cortex AI Gatewayをエージェントの制御ポイントに

Cortex AI Gatewayは、Snowflakeのガバナンス範囲を保存データからAIエージェントが実行するアクションへと拡張する。

Snowflakeはこの製品を、自社製およびサードパーティ製エージェントのための集中型ゲートウェイと説明している。前者にはSnowflake CoWorkとSnowflake CoCoが含まれる。後者には、Claude CodeやCursorといった外部のコーディングエージェントが含まれる。

Model Context Protocol、すなわちMCPは、AIアプリケーションが一貫したインターフェースを通じて外部ツールを検出し、呼び出せるようにするオープンプロトコルだ。MCPサーバーは、データベースクエリ、ドキュメント検索、メッセージング操作、ビジネスアプリケーションを呼び出し可能なツールとして公開できる。

このプロトコルにより、エージェントがこうしたリソースを利用するために必要な個別統合作業は減る。一方で、すべての接続を承認し、すべてのアクションを監視し、すべての費用を割り当てるための一元的な場所が、企業に自動的に提供されるわけではない。

Cortex AI Gatewayは、その運用上のギャップを埋めるよう設計されている。ゲートウェイの発表によると、組織はこれを使用して、どのエージェントが特定のモデル、MCPサーバー、アプリケーション、ツールにアクセスできるかを定義できる。

Snowflakeは、このゲートウェイがエンドツーエンドのアクティビティ記録も作成するとしている。この記録は、エージェントが何を行い、どのシステムに接続し、どのような順序でアクションを実行したかを示すことを想定している。

これは、エージェントとのやり取りが一度のモデル応答で終わることはほとんどないため重要だ。コーディングエージェントは、リポジトリを調査し、Issueを取得し、ファイルを変更し、テストを実行し、別のサービスに接続する場合がある。各ステップは異なるセキュリティ境界または所有権の境界をまたぐ可能性がある。

ゲートウェイは、こうしたステップの共通チェックポイントを提供できる。呼び出し元を認証し、権限を評価し、リクエストを記録し、承認済みのアクションを宛先へ渡せる。

Snowflakeは、このチェックポイントに財務管理機能も追加している。同社によると、Cortex AI GatewayはAI利用量をチーム、エージェント、またはワークロードに帰属させることができる。管理者は、エージェントが制御不能なモデル利用を生じさせないよう意図した支出上限も設定できる。

さらに、このゲートウェイは承認済みモデル間でのリクエストルーティングを提供するとしている。Snowflakeによれば、ルーティングの判断では品質、レイテンシー、可用性、利用コストを考慮できる。そのためこの製品は、モデルトラフィックも統制するという点で、単なるMCPプロキシより広範なものとなる。

100を超えるMCPサーバーへの対応は、接続範囲の初期指標となる。ただし、この数は本番導入、信頼性、セキュリティ品質を示すものではない。対応とは技術的互換性を表す場合があり、重要なワークフローでこれらの接続を運用している顧客数を明らかにするものではない。

それでも、この発表はSnowflakeの姿勢を変える。Cortex AIはすでにモデルを呼び出し、データエージェントを構築する場だった。Cortex AI Gatewayは現在、主なインターフェースがSnowflake外にあるエージェントを含め、他所で開発されたエージェントに対する統制権も求めている。

これがインフラのシグナルだ。Snowflakeは、エージェントを自ら作成していない場合でも、エージェントのリクエストと企業内アクションの間にある経路を制御したいと考えている。

Cortex AI Gatewayが今Google Newsに登場した理由

Snowflakeは、統合標準としてMCPが成功したことで生じたガバナンス上の課題に対応している。

MCPは、ツール接続をポータブルにする方法として始まった。開発者は一度機能を公開すれば、複数の互換AIクライアントから利用できる。このモデルは、別々のチームにまたがる数百のツールに数十のエージェントが接続するようになると、管理が難しくなる。

プロトコル自体は、メッセージと対話パターンを定義する。その認可仕様は、アクセス制限されたリモートサーバー向けにOAuth標準に基づくフレームワークを提供している。しかし、エンタープライズガバナンスは通信認可の範囲を超える。

セキュリティチームは、エージェントがどの人間またはサービスを代理しているかを把握する必要がある。そのアイデンティティが、特定のパラメーターで特定のツールを呼び出せるかを判断しなければならない。さらに、承認ルール、データ流出対策、監査記録の保持、緊急時の権限取り消しが必要になる場合もある。

財務チームも同様の問題に直面する。一つのワークフローが結果を返すまでに、複数のモデルやツールを呼び出すことがある。従来のクラウド課金では消費されたサービスを特定できるが、どのエージェントが一連の処理を開始したのか、どの部門がその恩恵を受けたのかまでは説明できない可能性がある。

こうした課題が仲介者の市場を生み出す。ゲートウェイは、トラフィックがモデルやMCPサーバーに到達する前に確認できる。この可視性により、アクションの実行地点に近い場所でポリシーを適用し、コストを記録できる。

SnowflakeはNatomaを通じてこの動きに備えた。5月27日、AIエージェント向けエンタープライズMCPプラットフォームを構築した同社を買収する最終契約を締結した。Snowflakeは、この取引によりガバナンスをデータ資産からAIのアクションとインタラクションへ拡張すると述べた。

Natomaの買収では、検証済みのMCPサーバーライブラリも提供するとされた。Snowflakeは、同社のプラットフォームにすでに保有されているデータを充実させる情報源として、メール、Slack、その他の接続アプリケーションを具体的に挙げた。

この契約からCortex AI Gateway発表までの短い間隔は、戦略上の優先度を示している。Snowflakeは、買収したMCP機能を孤立したコネクター製品として維持するのではなく、より広範なプラットフォーム戦略に統合している。

そのタイミングは、SnowflakeによるこれまでのAIガバナンスへの取り組みにも続くものだ。同社は2025年のサミットで、モデルアクセス、利用状況追跡、ロールベースの制御、予算執行のためのAI Governance Gatewayを説明した。また、Cortex AnalystおよびCortex Search向けのMCPサーバー対応も別途発表している。

Cortex AI Gatewayは、それまで隣接していたこれらの課題を組み合わせる。モデル選択、MCPアクセス、エージェントのアクティビティ、利用量を、提案された一つのコントロールプレーンで統制する。

この統合は、エンタープライズエージェントの変化を反映している。従来のチャットボットは、ユーザーが確認するためのテキストを生成する。エージェントは、ユーザーが結果を見る前に、非公開情報を取得し、業務システムを呼び出し、変更を開始できる。

こうした能力により、ツールアクセスはモデルアクセスと同じくらい重要になる。企業はLLMを承認しても、スコープが不適切なコネクターを通じてリスクにさらされる可能性がある。各アプリケーションを保護していても、エージェントのアクションの全連鎖にわたる可視性を失うことがある。

Snowflakeのセキュリティ統合は、この課題の一部に対応する。初期グループには1Password、Aembit、Linx Security、Okta、SailPoint、Saviyntが含まれる。これらの存在は、エージェントのアイデンティティとアクセスガバナンスが、共通インフラ上の課題になりつつあることを示唆している。

そのため、google newsの結果にゲートウェイが登場したことは、より大きな変化と結び付いている。MCP接続は、開発者の利便性から、アイデンティティチーム、セキュリティ運用、財務、プラットフォームエンジニアリングの領域へ移行している。

SnowflakeとDatabricks、同じコントロールプレーンをめぐり競合

中心的な争いは、既存のデータプラットフォームがすべてのモデルおよびMCPリクエストを統制すべきかをめぐる、SnowflakeとDatabricksの対立だ。

DatabricksはUnity AI Gatewayで、きわめて近い主張を展開している。同社のドキュメントでは、このサービスをエージェント、モデルエンドポイント、MCPサーバー、コーディングツールのための中央ガバナンスレイヤーとして説明している。

類似点は明確だ。両プラットフォームは、異なるプロバイダーにまたがるAIトラフィックのルーティング、権限の適用、利用状況の監視、消費量の管理を目指している。いずれも、このランタイムレイヤーをエンタープライズデータですでに使われているガバナンスシステムに接続している。

Databricksは、Unity Catalogをそのアプローチの中心に据える。このカタログは、モデル、関数、MCPサーバーといった資産を統制する。Unity AI Gatewayは、リクエストがシステムを通過する際に、それらの権限とポリシーを適用する。

最新のAIガバナンスガイドによると、このゲートウェイはClaude Code、Cursor、Codex、Gemini CLIを含む外部コーディングエージェントを統制できる。また、レート制限、予算、利用状況追跡、リクエスト単位のサービスポリシーについても説明している。

Snowflakeも自社発表でClaude CodeとCursorを挙げている。この重なりは重要だ。どちらの企業も、ゲートウェイを自社プラットフォーム内で構築されたエージェントに限定していない。

両社はそれぞれ、外部で作成されたエージェントの中立的な制御ポイントになろうとしている。ただし、制御レイヤーは周辺のデータプラットフォームも強化するため、中立性は相対的なものにとどまる。

顧客にとって、当面の選択は既存インフラに沿うことが多いだろう。Snowflakeのポリシー、データ、運用知識を広範に持つ企業は、Cortex AI Gatewayを通じてそれらの制御を拡張することを選ぶ可能性がある。Databricksの顧客にとっては、Unity Catalogを基盤とする経路の方が摩擦が少ないと映るかもしれない。

より長期的な競争は予測しにくい。エージェントは日常的に、データウェアハウス、ソフトウェアリポジトリ、メッセージングシステム、顧客プラットフォーム、クラウドサービスを横断して作業する。単一のデータプラットフォームがこれらすべての宛先を所有しているわけではない。

そのため、ゲートウェイは、すべてのワークフローを閉じたスタックに押し込むことなく、ホームプラットフォームの外にあるリソースを統制できることを証明する必要がある。Snowflakeのセキュリティ統合とNatomaコネクターは、その主張を支えるためのものだ。

Databricksも、外部プロバイダーとコーディングエージェントをカバーすることで、同様の相互運用性を訴えている。同社のゲートウェイは、2026年7月に更新されたドキュメントでもベータ版と表示されており、可用性や実装には変更の余地がある。

いずれのベンダーも、公開されている導入データを通じて決定的な優位性を確立してはいない。機能一覧は戦略的な収束を示すが、どのゲートウェイがより多くの本番トラフィックを処理しているか、あるいはより多くのポリシー違反を阻止しているかは示さない。

競争相手はデータプラットフォームのカテゴリー外にもいる。Cloudflareは、アクセスレイヤーの背後で複数のサーバーを集約するMCPサーバーポータルを導入している。そのポータルのドキュメントでは、OAuth対応と個別ツールリクエストのログについて説明している。

Cloudflareは、ネットワークおよびアクセスインフラの観点からこの問題に取り組んでいる。アイデンティティベンダーは認証情報と認可を通じてアプローチする。専門ゲートウェイ企業は、MCPの検出、検査、ポリシー適用に焦点を当てている。

これらのアプローチは、単一の企業内で共存し得るものの、重複する制御機能は運用上の摩擦を生む。チームは、どこに権威あるポリシーを置くか、またどのシステムで完全な監査証跡を保持するかを決める必要があるかもしれない。

ゲートウェイの重複は、責任の所在も曖昧にし得る。リクエストは、エージェントプラットフォーム、モデルゲートウェイ、MCPゲートウェイ、ネットワークプロキシ、アプリケーション認可レイヤーを通過する可能性がある。各システムが異なるアイデンティティや判断を記録することもある。

Snowflakeの狙いは、制御機能を統合することで、この分断を減らすことにある。リスクは、顧客が多数の切り離されたツールを、単一ベンダーと密接に結び付いたコントロールポイントへ置き換えることだ。

この緊張関係が購買判断を形作る。企業は一貫したガバナンスを求める一方、モデル、エージェント、データシステムを切り替える自由も求める。成功するゲートウェイには、相互運用性を依存関係へ変えてしまうことなく、集中管理を提供することが求められる。

ゲートウェイの仕組みがMCPをインフラのように見せる

MCPゲートウェイがインフラとして定着しつつあるのは、有用なエージェント接続のすべてが、アイデンティティ、ポリシー、ルーティング、可観測性、コスト配賦を継続的に必要とするためだ。

素のMCP接続は技術的な問いに答える。エージェントはどのようにツールを発見し、呼び出せるのか。エンタープライズ向けゲートウェイは運用上の問いに答える。その呼び出しは、どのような条件の下で許可されるべきか。

従業員が、コーディングエージェントに本番障害の調査を依頼する場面を考えてみよう。エージェントは技術文書を検索し、リポジトリを調べ、ログを照会し、チケットを起票して、変更案を作成するかもしれない。

各ツール呼び出しは、それ以前のステップからコンテキストを引き継ぐ。エージェントは、従業員のアイデンティティ、権限、意図に関する何らかの表現も保持している。この連鎖でミスが起きれば、データが露出したり、従業員が一度も求めていない操作が認可されたりする可能性がある。

ゲートウェイは、実行前に呼び出しを評価できる。ユーザーがアクセスできないツールを拒否し、パラメーターを制限し、書き込み操作には承認を要求できる。また、操作を開始したユーザーとエージェントに結び付ける記録を保持することもできる。

これはポリシー執行ポイント、すなわち抽象的なルールが許可、拒否、承認の判断へ変換される場所である。この概念は、API管理、ゼロトラストアクセス、クラウドアイデンティティシステムで広く知られている。

エージェントのトラフィックは、この判断をより複雑にする。リクエストは確率的に生成されることが多く、次に使うツールは、前のステップで取得した信頼できないコンテンツに依存する可能性がある。

悪意のある指示を含む文書が、別のツールを呼び出すようエージェントに影響を与える可能性がある。侵害されたMCPサーバーが、その後の振る舞いを変えることを目的としたコンテンツを返すこともある。その場合、広範な権限を持つトークンによって、エージェントが元のタスクの範囲を超えたデータへ到達できてしまう。

一元化された活動記録は、調査担当者がこうした連鎖を再構築する助けとなる。ただし、すべての攻撃を防ぐものではない。防止には、制限された認証情報、安全なツール設計、入力検証、隔離、慎重な承認ワークフローも必要となる。

ルーティングも、インフラとしての機能を追加する。組織は異なるワークロード向けに複数の言語モデルを承認している場合がある。あるモデルは複雑な推論に適している一方、別のモデルは低レイテンシーで定型的な抽出を処理できる。

ゲートウェイは、各アプリケーションに個別のプロバイダーロジックを実装させることなく、承認済みの選択肢からモデルを選べる。エンドポイントが利用不能になった場合には、トラフィックを再ルーティングすることも可能だ。

こうした柔軟性は、アプリケーション間の結合度を下げ得る。ただし、ルーティングの品質は評価データと明確なワークロードポリシーに依存する。組織が許容できるトレードオフを定義しない限り、ゲートウェイがビジネス上の優先順位を確実に推測することはできない。

コスト配賦も同様に価値があるが、難しい。単一リクエストのトークン数を数えるのは容易だ。複数ステップのワークフローの総コストを部門、プロジェクト、またはユーザーに割り当てるには、すべての経路で一貫したアイデンティティが必要となる。

Snowflakeは、Cortex AI Gatewayが、消費量を担当するチーム、エージェント、またはワークロードに帰属させられるとしている。購入者は、外部エージェントが別々のシステムにまたがって複数のツールやモデルを呼び出す場合、その帰属がどのように機能するかを検証すべきだ。

また、予算の執行がワークフローを安全に中断できるかもテストすべきである。エージェントを途中で停止すると、部分的な変更、未完了のトランザクション、不完全な記録が残る可能性がある。

こうした制御機能が個々のアプリケーションから見えなくなるとき、インフラとの類比は最も強くなる。開発者は、新しいエージェントごとに認証、ログ、ルーティング、予算ロジックを作り直す必要がないはずだ。

これらの機能を標準化すれば、導入を加速できる。一方で、ゲートウェイは高価値の標的となり、重要な依存先にもなり得る。

これが、市場がゲートウェイアーキテクチャへ収束している理由だ。MCPがツールアクセスをよりポータブルにするほど、企業にはそのポータビリティを制約する一貫したレイヤーが必要になる。

セキュリティに関する主張には、なお本番環境での証拠が必要

一元化されたゲートウェイは制御を改善するが、MCP接続を初期状態で安全にするわけではなく、ツール自体に内在するリスクも排除しない。

Snowflakeの発表は、エージェントの相互運用性の基盤としてセキュリティと信頼を掲げている。これは合理的な目標だが、同社はその主張を独立して確立されたものとして扱うには十分な証拠を公表していない。

発表では、Cortex AI Gatewayの本番導入数は示されていない。ブロックした攻撃、ポリシー違反、ルーティング精度、消費管理による削減額も定量化していない。

100を超えるMCPサーバーへの対応は、信頼性ではなく互換性を測るものだ。ゲートウェイには依然として、各サーバー、そのツール、バージョン、必要な権限に関する正確な情報が必要となる。

セキュリティ上の課題は、ゲートウェイの下位層にも及ぶ。承認済みのサーバーに脆弱なコードが含まれている可能性がある。正規のツールが危険なパラメーターを公開していることもある。エージェントが悪意あるコンテキストを処理した後、許可された機能を誤用する可能性もある。

政府のガイダンスは、こうした限界を強調している。NSAの2026年5月付 MCP security guidance は、MCPを事実上の通信標準と位置付ける一方で、そのセキュリティ態勢には依然としてばらつきがあるとしている。

同レポートは、動的なツール呼び出し、暗黙の信頼、コンテキスト共有、弱いアクセス制御、プロンプトインジェクション、トークンライフサイクルの欠落を指摘している。多くの保護策は、プロトコル上の保証ではなく、実装上の規律に依存するとしている。

この区別は、Cortex AI Gatewayを評価するうえで重要だ。ゲートウェイは認証と認可を一元化できるが、接続されるすべてのサーバーを後から安全にすることはできない。

また、エージェントがユーザーの依頼を正しく解釈したことも保証できない。ある操作を実行する権限があっても、その操作がユーザーの意図に合致することの証明にはならない。

承認ワークフローは、この隔たりを縮められる。高リスクの変更では、正確に提案された操作、そのパラメーター、予想される影響を人間が確認する必要がある。ユーザーがエージェントの実行内容を確認できない場合、一般的な権限プロンプトの保護効果は限定的だ。

購入者は、Snowflakeが委任されたアイデンティティをどのように扱うかを問うべきだ。従業員の代わりに動くエージェントには、そのタスクに必要な権限だけを与えるべきである。ワークフローが複数システムにまたがるというだけで、広範なサービス認証情報を引き継ぐべきではない。

失効についても検証すべきである。ユーザーの役割が変わった場合やトークンが侵害された場合、ゲートウェイは以後のアクセスを迅速に停止しなければならない。キャッシュされた認証情報や長時間稼働するエージェントセッションは、この対応を複雑にし得る。

ログ記録には独自のトレードオフもある。詳細な記録は監査とインシデント対応に役立つが、プロンプトやツールパラメーターには機微な情報が含まれる場合がある。組織には、ログ自体に対する保持、マスキング、アクセスのルールが必要だ。

ゲートウェイのモデルルーティングも同様に精査すべきである。品質、レイテンシー、可用性、消費量を横断して最適化することは有用に聞こえる。しかし、これらの目標は衝突し得るため、自動選択が出力品質やデータ取り扱い上の義務に影響する可能性がある。

企業は、ルーティングによってデータが承認済みのリージョンとプロバイダー内に留まるかを確認すべきだ。また、モデルの変更がアプリケーション所有者に可視化され、監査時に再現可能かも判断する必要がある。

ベンダー集中は別のリスクをもたらす。エージェントトラフィック、ツール権限、モデルルーティング、コスト制御を一つのシステムに置くと、広範な運用上の依存関係が生まれる。そのレイヤーで障害やポリシーエラーが起きれば、多数のワークフローが同時に中断する可能性がある。

これはゲートウェイモデルを否定するものではない。ゲートウェイは便利な機能ではなく、アイデンティティ、ネットワーク、APIインフラと同様に評価されるべきだという意味である。

Snowflakeの立場は、すでに同社のガバナンスモデルに投資している顧客にとって有利に働くかもしれない。それでも購入者には、独立したテスト、最小権限設計、サーバーのインベントリ、隔離実行、インシデント対応手順が必要だ。

したがって、Google Newsの見出しを責任を持って読むなら、Snowflakeのマーケティング表現よりも狭い解釈となる。Cortex AI Gatewayは市場の進む方向を示しているが、一つのプラットフォームがエージェントのライフサイクル全体を保護できるかどうかを決着させるものではない。

Google Newsの読者が次に注視すべきこと

ゲートウェイという論旨が信頼に足るものとなるのは、導入状況、執行の証拠、クロスプラットフォームでの挙動がローンチ時の主張を超えたときだけだ。

最初のシグナルは本番利用である。Snowflakeは、単に対応するMCPサーバー数ではなく、Cortex AI Gatewayを通じて稼働中のサードパーティー製エージェントをルーティングしている顧客数を明らかにすべきだ。

有用な証拠には、ガバナンス下にあるツール呼び出し数、外部システムの範囲、強制ポリシーを利用するワークフローの割合が含まれる。顧客事例では、信頼に関する一般的な説明を繰り返すのではなく、具体的な操作を特定すべきである。

Meltwaterは、エージェントをデータやツールへ安全に接続することに関心を持つ組織として、Snowflakeの発表に登場した。その表現は、Cortex AI Gatewayをその結果に向けた一歩として説明していた。測定可能な成果を伴う完了済みの導入を立証したものではなかった。

この違いは追跡する価値がある。デザインパートナーは製品の方向性を検証できる一方、継続的な本番トラフィックは、信頼性、アイデンティティマッピング、運用コストを検証する。

2番目のシグナルは執行品質である。Snowflakeは、ユーザーアイデンティティやタスクコンテキストを失うことなく、ファーストパーティー製とサードパーティー製のエージェントにまたがってポリシーが機能することを示す必要がある。

購入者は、個々のツールとパラメーターに対するきめ細かな制御を探すべきだ。また、承認ポリシー、トークン失効、データ損失防止、既存のセキュリティ監視システムとの統合にも注目すべきである。

公表されたインシデントレポートは、価値ある証拠となる。信頼できるコントロールプレーンは、危険な振る舞いをどのように検出したか、何をブロックしたか、管理者がどのように事象を再構築したかを説明できるべきだ。

3番目のシグナルは競合の対応である。Databricks、Cloudflare、アイデンティティベンダー、独立系ゲートウェイプロバイダーは、それぞれのエージェント制御機能を引き続き拡張していくだろう。

これらの製品がポータブルなポリシー形式と共通の監査標準へ収束すれば、企業はすべてのルールを再構築することなくゲートウェイを切り替えられる。この結果は、MCPをオープンなインフラとして強化する。

各プラットフォームが独自のアイデンティティ、ポリシーモデル、ログを作り出すなら、MCPは接続レイヤーではオープンなままでも、ガバナンスは分断されたままとなる可能性がある。それは、交換可能なエージェントツールという約束を弱めることになる。

開発者は、ゲートウェイがデバッグ情報をどのように公開するかを追うべきだ。拒否されたリクエストには理解可能な理由が必要であり、ルーティングされたリクエストには、どのモデルとポリシーが影響したかを示すトレースが必要となる。

セキュリティチームは、一つのゲートウェイが完全な操作連鎖を把握できるかを評価すべきである。エージェントが監視されていないシステムを横断する場合、部分的な可視性は誤解を招く安心感を生みかねない。

エンタープライズの購入者は、コントロールプレーンの障害モードも比較すべきだ。ゲートウェイに障害が起きた際にエージェントが安全に停止するか、読み取りと書き込みの操作で挙動が異なるか、緊急アクセスがどのように機能するかを把握する必要がある。

ナレッジワーカーは、ゲートウェイのポリシーがアシスタントがアクセスできる情報を左右するため、こうした選択に利害関係を持っています。より優れた制御により、すべてのエージェントにメール、ドキュメント、メッセージングシステムへの恒久的なアクセスを与えることなく、有用な連携を支援できます。

検索可能な技術コンテキストを構築するチームは、権限をソース資料に紐付けたままにすべきです。適切に設計されたエンジニアリング・ナレッジベースは、エージェントが必要とするのが選択された情報だけである場合に、広範なリポジトリを公開する必要性を減らします。

今後1〜3か月で、Cortex AI Gatewayが実用的な統制ポイントとなるのか、それとも戦略的な発表にとどまるのかが明らかになるはずです。実名の本番導入、測定可能な強制適用の成果、そしてSnowflakeの自社環境を超えたより深い統合に注目してください。

Snowflakeは、インフラに関する賭けを明確に示しました。同社は、企業がモデルルーティング、MCPガバナンス、活動記録、消費量の制御を組み合わせた中央集約型レイヤーを通じてエージェントを管理すると考えています。

ポータブルなツールはポータブルな制御の必要性を生むため、この賭けは方向性として妥当に見えます。未解決の問いは、そのコントロールプレーンを運用する権利を誰が得るのかです。

Googleニュースの報道は、ローンチの瞬間を捉えています。より重要な試練は、企業が機密データを読み取り、実際のリソースを消費し、本番システムを変更できるエージェントを接続するときに始まります。MCPゲートウェイを信頼できるインフラとして扱う前に、自組織がすべてのエージェントを特定し、すべてのツールを制約し、すべての行動を再構成できるかを問うべきです。