Cortex AI GatewayによるモダンなAIインフラストラクチャスタックの構築

Cortex AI GatewayによるモダンなAIインフラストラクチャスタックの構築

コンテンツにスキップ

Blog / 製品 & テクノロジー / Cortex AI GatewayによるモダンなAIインフラストラクチャスタックの構築

2026年10月8日 / 約9分で読めます 製品 & テクノロジー 投稿リンクをコピー Claudeで開く ChatGPTで開く

Cortex AI GatewayによるモダンなAIインフラストラクチャスタックの構築

Ali Taha +2

過去数年間で、エンタープライズ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="" export 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": ".snowflakecomputing.com", "apiKey": "", "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における動的なモデルルーティング：各タスクに対する適切なモデルの選択

ほとんどのチームは、すべてに対して単一のフロンティアモデルを使用することに落ち着いています。これは開始するには合理的な方法ですが、拡張するにはコストがかかる方法です。エージェントのステップの大部分は、ファイルの編集、フォーマット、ルックアップであり、これらはより安価なモデルでも同じ品質と精度で処理できます。

Figure 1: Cortex AI Gateway offers dynamic model routing (private preview soon).

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...