過去数年間で、エンタープライズAIスタックは高度でありながらも断片化された、扱いにくいエコシステムへと進化しました。現在では、ベクトルデータベース、監視システム、パイプラインチューニングなどすべてを網羅し、エンタープライズシステムとインターフェースをとるコーディングエージェント、組み込みエージェント、Model Context Protocol（MCP）サーバーの無秩序な組み合わせを通じて接続されており、これらすべてが数週間ごとに変化するモデルポートフォリオによってサポートされています。異なるチームが異なるタイムラインでスタックの一部を採用するため、セキュリティに影響を与える可能性のある管理およびガバナンスのギャップが生じる可能性があります。
このような断片化された環境において、これらの領域全体にわたる基本的な質問に正確に答えるために必要な完全なコンテキストを持つ企業はほとんどありません。どのモデルを呼び出しているのか、誰が呼び出しているのか、どのようなアクションを実行しているのか、そして関連するコストはいくらかといった質問です。
これに対する直感的な対応は制限することですが、これは長期的な解決策としては実行可能ではありません。従業員がAIを使用する能力を妨げることは、未承認のAIツールの使用につながるだけであり、リスクをさらに増大させます。
そのギャップはツールの問題ではなく、レイヤーの欠落です。モダンなAIスタックには、すべてのAIクライアントとそれらがアクセスするエンタープライズシステムとの間に位置する制御ポイントが必要です。Cortex AI Gateway（パブリックプレビュー3）は、一元化されたコントロールプレーンとして機能することでこれに対処し、このモダンで多面的なインフラストラクチャが必要とする統合された可視性、ガバナンス、監視を提供します。当社の見解では、モダンな企業のAIインフラストラクチャスタックにおいて、次の6つの要素は不可欠です。
統合されガバナンスが効いた推論
動的なモデルルーティング
MCPおよびツールガバナンス
一元化されたオブザーバビリティ
セキュリティポリシーとガードレール
コストガバナンスと制御
現在パブリックプレビュー中のCortex AI Gatewayにより、プラットフォームチームはモデルやMCPサーバーへのアクセス権の付与、支出の属性付けと制御、AIがユーザーに代わって実行した内容の確認を1か所で行うことができます。アプリケーションチームは、構築の対象となる単一のエンドポイントを取得します。それがスタックの各レイヤーにどのようにマッピングされるかを見てみましょう。
Cortex AI Gatewayは、エンタープライズAIインフラストラクチャにおけるSnowflakeの「一元管理されたコントロールプレーン（統制基盤）」です。ガバナンスが担保されたモデル推論、動的モデルルーティング、MCPツールのガバナンス、オブザーバビリティ（可観測性）、セキュリティガードレール、そしてコスト管理を単一のエンドポイントで提供します。これにより、プラットフォームチームは組織内のあらゆるAIクライアントやエージェント全体に対して、統合された可視性を獲得できます。
統合されガバナンスが効いた推論：エージェントに対する単一のエンドポイントの使用
成長するAIスタックで最初に破綻するのは、モデルへのパスの数です。エンジニアは、あるプロバイダーに対してコーディングエージェントを構成します。プラットフォームチームは、アプリケーションを別のプロバイダーに接続します。別の誰かが3つ目のプロバイダーに対してスクリプトを作成します。各パスには独自の認証情報、独自のログ、独自の請求があります。
Cortex AI Gatewayは、これらを1つのエンドポイントに統合します。OpenAI、Grok、GLM、Gemini、Llama、Mistral、DeepSeekモデル用のChat Completions API と、Claude用のMessages API を実装しています。これらは、モデルサービングが収束した2つのプロトコルです。ストリーミング、ツール呼び出し、構造化出力、プロンプトキャッシング、画像入力、推論はすべてネイティブと同じように機能するため、既存のクライアントをCortex AI Gatewayに向けるには、別のベースURLとトークンが必要になるだけです。OpenAI Responses APIのサポートも間もなく提供される予定です。次の例は、Cortex AI GatewayでOpenCodeを構成するために必要なすべてのセットアップを示しています。
export PAT="<pat>"
export BASE_URL="<base_url>"
export OPENCODE_CONFIG_CONTENT='{
"$schema": "https://opencode.ai/config.json",
"model": "snowflake-cortex/openai-gpt-5.4",
"small_model": "snowflake-cortex/openai-gpt-5.4",
"provider": {
"snowflake-cortex": {
"options": {
"baseURL": "${BASE_URL}",
"account": "<ACCOUNT>.snowflakecomputing.com",
"apiKey": "<PAT>",
"headers": {
"snow-agent-name": "opencode"
}
}
}
}
}'
アクセス制御には、Snowflakeの既存のロールベースのアクセス制御（RBAC）フレームワークを使用します。管理者は、ゲートウェイを通じて利用可能なモデルを構成し、組織によって承認されたモデルのみがアクセス可能であることを確認できます。
Cortex AI Gatewayでコーディングエージェントをさらに使いやすくするために、Snowflake CLIはトラフィックがゲートウェイを通過するようにセットアップを処理できるようになります。1つのコマンドを実行するだけで、アクティブなSnowflake接続から認証情報を読み取り、コーディングエージェントの構成に挿入し、トラフィックがCortex AI Gatewayを経由するようにルーティングされた状態でエージェントを起動できます。たとえば、Snowflake CLIを使用してOpenCodeを起動することは、現在ではsnow ai opencodeを実行するのと同じくらい簡単です。
Cortex AI Gatewayにおける動的なモデルルーティング：各タスクに対する適切なモデルの選択
ほとんどのチームは、すべてに対して単一のフロンティアモデルを使用することに落ち着いています。これは開始するには合理的な方法ですが、拡張するにはコストがかかる方法です。エージェントのステップの大部分は、ファイルの編集、フォーマット、ルックアップであり、これらはより安価なモデルでも同じ品質と精度で処理できます。
Cortex AI Gatewayを通じて間もなくプライベートプレビューで提供される動的なモデルルーティングは、エージェント実行の各ステップでタスクを確実に完了できる最も手頃なモデルを（利用可能なオプションから）選択します。Snowflakeの調査チームによって微調整されているため、複雑度の低い反復的な作業は効率的なモデルに割り当てられ、より深い推論が必要な作業はフロンティアモデルに割り当てられます。内部評価では、同等の品質でフロンティアモデルのみのアプローチと比較して最大3倍のトークン効率でdbtパイプラインワークロードを完了し、別のコーディングテストでは、エンジニアリングチームが約25%少ないトークンを使用しながらプルリクエストのスループットを安定して維持しました。1これらの結果は、企業にとって現実世界のコスト削減につながる可能性があります。
ルーティングは、手動のモデル選択と同様にガバナンスが効いています。承認されたモデルのみが使用され、既存のデータレジデンシー設定が尊重され、すべてのルーティング決定がログに記録されるため、コンプライアンスチームはどのモデルがどのリクエストを処理したかを確認できます。ルーティングは各アプリケーションではなくCortex AI Gatewayに存在するため、Snowflakeはエージェントの構成を変更することなく、モデルの価格設定やパフォーマンスの変化に応じて決定を更新できます。
ここではオープンソースモデルの側面も重要です。エージェントハーネスとしてSnowflake CoCoを使用してADE-benchで評価した結果、DeepSeek-V4-Flashは74.4%のスコアを記録し、2テストした主要なプロプライエタリモデルを上回りました。GLM-5.3は間もなくプライベートプレビューで提供される予定ですが、その前身であるGLM-5.2は、ベンチマーク内のどのモデルよりも低いトークンフットプリントでADE-bench2で66%のスコアを記録しました。2これはまさに大量のワークロードが求めるプロファイルです。SnowflakeはこれらのモデルをセキュアなSnowflake境界内で提供するため、推論はガバナンスが効いたデータの隣で、すでにそれをカバーしている同じRBACと監査証跡の内部で行われます。
動的なモデルルーティングの詳細をご覧ください。
MCPおよびツールガバナンス：エージェントが実行できる内容の制御
エージェントがツールを呼び出せるようになった瞬間、それは企業内のアクターになります。そして、MCPはそれを非常に簡単にしました。従業員がインストールする管理されていないすべてのMCPサーバーは、本番システムへの新しいパスであり、アクセス権を使用して何を行うかをランタイムに決定するものによって操作されます。これはシャドーITですが、未承認のソフトウェアが本番データベースを読み取り、エンタープライズSaaSのレコードを変更できる点が異なります。
APIゲートウェイは、クライアントがエンドポイントにアクセスする権限を持っているかどうかを尋ねます。ツールゲートウェイは、別の質問に答える必要があります。このエージェントは、このユーザーに代わって、今すぐこのツール呼び出しを実行する権限を持っていますか。SnowflakeによるNatomaの買収に続き、Cortex AI Gatewayのツールがそれに答えます。現在プライベートプレビュー中のこの機能には、100を超えるMCPサーバーの厳選されたカタログが付属しており、それぞれでOAuthが処理されるため、MCPサーバーの無秩序な広がりを排除するのに役立ちます。
管理者は、特定のツール、現在公開されているすべてのツール、または現在および将来のすべてのツールを有効にするかを選択します。有効になっていないツールはクライアントに表示されず、呼び出すこともできないため、拒否された機能は通常、呼び出し時に失敗するのではなく、アドバタイズされることはありません。ツール呼び出しをログに記録できるため、1つのプロンプトからの完全なエージェントシーケンスをシーケンスとして読み取ることができます。ツール呼び出しは推論と同じトレーステーブルにスパンを出力するため、単一のトレースで推論とアクションをカバーできます。
その監査証跡は、このレイヤーに特有の攻撃に対する防御となります。承認されたサーバーがツールの定義を悪意のあるものに密かに更新し、クライアントがその変更を自動的に取得するツールポイズニング、ツールシャドウイング、ラグプルは、設計上エンドユーザーには見えません。すべてのツール定義とすべての呼び出しを記録するシステムにとっては、それらは見えないものではありません。
オブザーバビリティ：エージェントのトレースを1か所で確認
組織にどのエージェントがシステムに対して実行されているかを尋ねると、ほとんどの場合、古くなったエージェントのスプレッドシートから正直な答えが返ってきます。これは当社が実施した調査の結果によって裏付けられており、調査対象のお客様の約3人に1人が、エージェントのオブザーバビリティのためにカスタム構築された内部ダッシュボードを使用していました。Cloud Security Allianceの調査によると、過去1年間に82%の組織が、セキュリティ部門やIT部門がこれまで知らなかったAIエージェントまたは自律型ワークフローを少なくとも1つ発見しています。さらに、Cost of a Data Breach Report 2026によると、シャドーAIの使用率が高い組織では、平均侵害コストが539万ドルに達し、シャドーAIのインシデントが侵害を受けた組織の43%に影響を与えています。
通常の対応はすべてのクライアントをインストルメント化することですが、知らないものをインストルメント化することはできないという一般的な理由で失敗します。Cortex AI Gatewayは別のルートを採用し、オブザーバビリティをサービングレイヤーのプロパティにします。開発者のラップトップでローカルに実行されているエージェントからのものであっても、リモートのKubernetesクラスターからのものであっても、ゲートウェイを通過するモデルまたはMCPツール呼び出しは、SnowflakeのOpenTelemetryスパンとして記録されます。これにより、エージェントコードを変更することなく、サードパーティのランタイム全体で完全な実行の可視性が得られます。
これらのスパンは、OpenTelemetryの生成AIセマンティック規則を使用してAGENT_TRACE_TABLEに格納されます。各レコードには、リクエストされたモデル、入力および出力トークン、キャッシュの読み取りと書き込み、期間、ステータスコード、MCPサーバーとツール、および呼び出しを行ったクライアントのバージョンとセッションが含まれます。プロンプト、応答、およびツール呼び出しの入力と出力は、管理者がペイロードキャプチャをオンにした場合にのみキャプチャされ、オンにした場合、そのテキストは組織がすでに実行しているアクセス制御の下でSnowflake内に配置されます。テレメトリはAGENT_TRACE_TABLEなどのお客様が所有するイベントテーブルに直接格納されるため、Snowflakeのセキュリティ境界内に厳密に留まります。
Cortex AI Gatewayは、独自のエンドポイントでクライアント側のOTLPトレースも受け入れます。サーバー側とクライアント側の両方のトレースの可視性により、エージェントのオブザーバビリティのリーダーが必要とするレベルのイントロスペクションが提供されます。
CoCoを使用すると、AGENT_TRACE_TABLE内のテレメトリの調査が1つのプロンプトステップになります。以下の例は、キャッシュヒット率の低下を見つけ、モデルコストを削減する機会を特定する方法を示しています。
セキュリティとガードレール：最も重要な領域の保護
エージェント型AIはまったく新しい方法で攻撃対象領域を拡大しており、その最も明確な証拠は、過去数か月に見出しを飾ったインシデントから得られます。
これらのインシデントから簡単に導き出せる結論は次のとおりです。ガードレールは、セキュアなAIスタックに不可欠です。エージェント自身の判断こそが失敗するものであるため、ガードレールはエージェントの内部ではなく、エージェントが越えなければならない境界に配置する必要があります。
Snowflake Cortex AI Guardrails は、CoCo、Snowflake CoWork、Cortex Agents全体で、プロンプトインジェクションやジェイルブレイクの試みに対するランタイム保護をすでに提供しています。システムの指示を上書きしようとする間接的なプロンプトインジェクションがないかツール出力をスキャンし、モデルの安全境界をバイパスしようとする試みを検出し、これまでに見られなかった攻撃パターンをリアルタイムで特定します。
Cortex AI Gatewayは、このインフラストラクチャをゲートウェイトラフィックに間もなく導入します。これにより、Snowflake独自のAI領域から、ゲートウェイを経由してルーティングされるサードパーティのエージェントやハーネスへと保護が拡張され、露出する攻撃対象領域が最小限に抑えられます。
詳細については、Cortex AI Guardrailsのドキュメントをご確認ください。
コストガバナンス：AI投資の価値の最大化
2026年にはAIへの支出が多くの予算を圧迫しましたが、本当の問題は無駄遣いではなく、予測の甘さにあります。それに伴い、トークン量を生産性の代用として扱う「トークンマキシング」という慣行も生まれました。一部の企業は社内リーダーボードを公開しましたが、ユーザーがAIに過剰な支出をしてリーダーボードのトップに立とうとしたため、最終的に閉鎖されました。トークン使用量の増加が必ずしも高いROIに結びつくわけではないことは、すぐに明らかになりました。
これに対処するため、Snowflakeの既存のコスト制御がCortex AI Gatewayにも拡張されました。
Budgetsは確立されたコストガバナンス制御を提供し、Cortex AI Gatewayを経由してルーティングされるすべてのAIトラフィックで利用できるようになりました。制御のレベルは、管理者に委ねられています。Budgetsは、ゲートウェイレベルで設定して詳細な管理を維持することも、リソースやユーザーのタグを通じて設定し、必要なあらゆる次元でコスト制御を細分化することもできます。部門、ロール、コストセンター、ユーザーID、エージェント、アプリケーションのいずれであっても、Cortex AI Gatewayはこれらすべてにわたるコストの可視性と制御をサポートします。
ユーザーごとのクォータにより、個人ごとに月間およびオプションの1日あたりの制限を設定し、数分以内にブロックを適用できます。
ゲートウェイのトラフィックはAI_GATEWAY_USAGE_HISTORYにレポートされ、モデルごとに分類されたクレジットと、AGENT_TRACE_TABLEに直接結合するリクエストIDが含まれます。これにより、どのエージェントの会話、ワークフロー、タスク、モデルリクエスト、ツール呼び出しが暴走した支出につながったのかについて、きめ細かい可視性が得られます。CoCoは、トレースデータを簡単に掘り下げてAIコストを理解するための優れた方法です。
AIコストガバナンスの詳細をご確認ください。
Cortex AI Gatewayを開始する
Snowflakeは、企業にとってAIを安全かつ経済的なものにすることに専念しており、Cortex AI Gatewayはその出発点です。ぜひご自身でご体験ください。1つのクライアントをCortex AI Gatewayに向けてトレースを確認したり、詳細なコスト制御の実装を開始したり、モデルの使用傾向を掘り下げたりすることができます。
Cortex AI Gatewayは、AWSの商用リージョンでパブリックプレビュー中です。3機能や開始方法の詳細については、Cortex AI Gatewayのドキュメントをご確認ください。
このページには、Snowflakeが将来提供する製品に関する記述を含め、将来の見通しに関する記述が含まれていますが、これはいかなる製品の提供も約束するものではありません。実際の結果や提供内容は異なる場合があり、既知および未知のリスクや不確実性の影響を受けます。詳細については、最新の四半期報告書（10-Q）をご覧ください。
1 トークン効率とADE-benchの結果は、Snowflakeの内部テストに基づいています。方法論と条件はリクエストに応じて提供可能であり、個々の結果はワークロードや構成によって異なる場合があります。https://www.snowflake.com/en/blog/dynamic-model-routing-open-models-cortex-ai/
2効率スコアは、現実世界のアナリティクスおよびデータエンジニアリングのタスクでAIエージェントを評価するためにdbtによって作成されたフレームワークであるADE-benchを使用した内部テストに基づいています。
3Amazon Web Services（AWS）の商用リージョンのアカウントでのみ利用可能です。ただし、アジアパシフィック（ニュージーランド）、アジアパシフィック（マレーシア）、ヨーロッパ（スペイン）を除きます。
