Snowflakeの動的モデルルーティングとは？ Cortex AI GatewayがタスクごとにAIモデルを選ぶ仕組み

Snowflakeは、AIエージェントやアプリケーションからのリクエストを、毎回同じ高性能モデルへ送るのではなく、タスクごとに適切な承認済みモデルへ振り分ける「動的モデルルーティング」を発表しました。対象はCortex AI Gatewayで、機能は近日中にプライベートプレビューへ移行する予定です。したがって、現時点では一般提供済みの製品機能ではなく、発表段階の新機能です。

Snowflakeが掲げる狙いは、単に1トークンあたりの価格を下げることではありません。タスクを許容できる品質で完了させるために必要な知能の水準だけを使い、ビジネス成果1件あたりのコストを最適化することです。同社はこの考え方を「インテリジェンス・エフィシェンシー（intelligence efficiency）」と呼んでいます。

Snowflakeが発表したこと

動的モデルルーティングはCortex AI Gatewayを通じて提供され、SnowflakeのAI製品であるCoCoとCoWorkにも統合されます。Cortex AI Gatewayに接続されたサードパーティー製のAIエージェントも、この機能を利用できるとSnowflakeは説明しています。

利用企業は、ルーティング候補として認めるモデルを指定できるほか、コスト、品質、レイテンシーのどれを重視するかといった方針も設定できます。ルーターは、管理者が承認したモデルの中から、タスクを十分な品質で完了できると判断した最も安価なモデルを選ぶことを目指します。

たとえば、定型的な分類、反復的なデータ処理、比較的単純な生成タスクは効率的なオープンモデルに任せます。一方、複雑な推論や難易度の高いエージェント処理は、Anthropic、OpenAI、Googleなどが提供するフロンティアモデルへ振り向けます。

自動化を常に使う必要はありません。利用企業は特定のモデルを固定したり、候補となるモデルを絞り込んだりすることで、手動に近い運用も維持できます。

さらにSnowflakeは、ルーティングがデータレジデンシー要件やガバナンスポリシーを考慮し、各リクエストで選択されたモデルを記録できると説明しています。これにより、動的ルーティングはAI利用料の管理だけでなく、モデル選択を監査可能なプロセスにする仕組みとしても位置づけられます。

ルーティングの仕組みは2種類

Snowflakeは、タスクにどの程度のモデル性能が必要かを判断する方法として、主に2つの仕組みを説明しています。

小さなモデルから始める「アドバイザーパターン」

アドバイザーパターンでは、まず小規模なモデルがタスクを試みます。十分に処理できない場合は、より大きなモデルをツールとして呼び出し、処理を継続します。

この方式なら、小規模モデルで対応できるリクエストにフロンティアモデルの料金を支払わずに済みます。同時に、難しいタスクを上位モデルへ引き継ぐエスカレーション経路も確保できます。

ただし、最初の試行が失敗したり、上位モデルへの切り替えや再試行が発生したりすれば、トークン数、処理時間、システムの複雑さが増える可能性があります。

過去のクエリを使う分類器ベースのルーティング

もう1つは、過去のクエリに見られるパターンを学習した分類器を使い、比較的簡単なリクエストを事前に判別して、シンプルなモデルへ送る方法です。

つまり、システムには「まず小さなモデルで試して必要なら引き上げる」経路と、「リクエストを先に分類して適切なモデルを選ぶ」経路が用意されます。重要なのは、安いモデルを選べたかではなく、最終的なタスクの結果が改善したかどうかです。

Snowflakeが報告した効率化の数字

Snowflakeは、dbtパイプラインを扱う社内ワークロードで、フロンティアモデルだけを使った場合と同等の品質を保ちながら、動的ルーティングによって最大3倍のトークン効率を実現したと報告しています。また、別のコーディング・ワークロードのテストでは、エンジニアリングチームがプルリクエストの処理量を維持しつつ、トークン使用量を約25％削減したとしています。

ただし、これらはSnowflakeが実施した社内評価であり、顧客環境で独立検証された結果ではありません。反復的なデータエンジニアリングやコーディング作業で有効だったルーターが、長いコンテキストを扱う調査、複雑なツール呼び出し、リスクの高い意思決定でも同じ成果を出すとは限りません。

企業が見るべき指標は、単純な「削減トークン数」ではありません。品質、レイテンシー、信頼性、人による修正を含め、承認可能な成果を1件完了するための総コストを測る必要があります。

DeepSeekとGLMをモデル候補に追加

Snowflakeは、Cortex AIで利用できるモデルの選択肢も広げます。追加されるのはDeepSeek-V4-Flash 0731と、Z.aiのGLM-5.3です。DeepSeek-V4-Flash 0731はCoCoを含むプライベートプレビューで提供され、GLM-5.3は提供可能になり次第、プライベートプレビューへ追加される予定です。

Snowflakeによると、CoCoをエージェント実行基盤として使った社内テストで、DeepSeek-V4-FlashはADE-benchで74.4％を記録しました。一方、GLMについて同社が示したのはGLM-5.3ではなく、以前に行ったGLM-5.2のテスト結果で、スコアは66％、同ベンチマークで最も少ないトークン使用量だったとされています。このGLM-5.2の結果を、GLM-5.3の評価結果と解釈してはいけません。

利用できるモデルが増えれば、タスクの要求水準とコスト、性能の組み合わせを細かく合わせやすくなります。Anthropic、OpenAI、Googleといった既存のフロンティアモデルだけでなく、オープンモデルも候補に加わることで、ルーティングの選択肢そのものが広がります。

Snowflakeが強調する「統制されたデータ境界」

Snowflakeの主な差別化ポイントは、モデルの振り分け機能そのものではありません。ルーティングとモデル利用を、Snowflakeがすでに提供している統制されたデータ環境に結び付ける点です。

同社は、新たに追加するオープンモデルを単に第三者APIへ中継するのではなく、自社で提供すると説明しています。データ、推論用コンピュート、モデルの重み、エージェントのオーケストレーションがSnowflakeのセキュリティ境界内で動作し、既存のロールベースアクセス制御（RBAC）や監査機能も利用できるという主張です。

もっとも、これはSnowflakeによるアーキテクチャ上の説明であり、すべての導入環境に対する一律の保証ではありません。企業は、実際の導入リージョン、データレジデンシー要件、契約条件、ログの扱い、ワークロードごとに利用可能なモデルを確認する必要があります。

Snowflakeをすでに分析データやAIアプリケーションの基盤として利用している企業にとっては、モデルを安く選べること以上の意味があります。データアクセスと同じ統制・監査の枠組みの中で、モデル選択も管理できる可能性があるためです。

他のAIルーティングサービスとの違い

モデルルーティングという発想自体はSnowflake独自のものではありません。たとえばAmazon BedrockのIntelligent Prompt Routingは、同じモデルファミリー内の基盤モデル間でリクエストを振り分け、予測される応答品質とコストの最適化を目指します。

DatabricksのUnity AI Gatewayも、モデルやMCPサービスへのリクエストを中央の制御プレーンからルーティングし、複数プロバイダーにまたがる容量、可用性、支出を管理する仕組みです。 Google CloudのAPI Gatewayは、OpenAI互換のリクエストを受け、設定したGemini Enterprise Agent Platformのモデルエンドポイントへ転送する管理レイヤーとして機能します。

NVIDIAのNeMo Switchyardは、特定のプロバイダーに依存しないSDK・ルーティング層として、利用可能なモデルを定義し、選択したエンドポイントへの呼び出しを管理します。 OpenRouterは、複数のモデルプロバイダーを集約し、可用性や価格などに基づいてプロバイダーを選択する仕組みを提供しています。

したがって、比較すべきなのは「どのサービスが安いモデルを選べるか」だけではありません。次の要素が、どこで管理・実行されるのかが重要です。

• データへのアクセス権限
• ルーティングポリシー
• モデルの実行環境
• データレジデンシーと監査
• 利用量や請求の可視化
• プロバイダー間の移植性

Snowflakeは、ガバナンスされたデータ環境との緊密な統合を重視します。一方、より中立的なゲートウェイは、複数クラウドや複数プロバイダー間の柔軟性を重視する傾向があります。どちらが優れているかではなく、企業の運用基盤に合うかどうかが判断の軸になります。

コスト削減を検証する際のチェック項目

導入前には、自動ルーティングを固定したフロンティアモデルの構成と比較し、実際の本番ワークロードに近いデータで評価する必要があります。少なくとも、次の項目を測定すべきです。

• 選択されたモデルのトークン単価ではなく、タスクを正常に完了し承認されるまでの総コスト
• ルーターや分類器の利用料が発生する場合の追加コスト
• アドバイザーによるエスカレーション、フォールバック、再試行、ツール実行失敗による追加呼び出し
• ルーティング、検索、コンテキスト組み立て、2回目のモデル呼び出しを含むエンドツーエンドのレイテンシー
• タスク分類ごとの成功率と品質
• 小規模モデルによる幻覚、ポリシー違反、品質低下
• 人によるレビュー、修正、再処理、エスカレーションのコスト
• データレジデンシー、可観測性、データ転送、ベンダーロックインの制約

Snowflakeは、ルーティング判断そのものに別料金を課さず、トークン消費に基づいて請求すると説明しています。それでも、エスカレーションや再試行が増えれば、総トークン数と処理時間は増加します。評価の基準は、トークン数が減ったかではなく、品質とガバナンスの要件を満たした成果を、より低い総コストで完了できたかどうかです。

まとめ

今回の発表は、2つの動きを組み合わせたものです。1つは、承認済みモデルの中からタスクごとに利用モデルを自動選択する動的ルーティング。もう1つは、Cortex AIで利用できるモデルの拡充です。動的モデルルーティングは近日中にプライベートプレビューへ移行する予定で、DeepSeek-V4-Flash 0731はプライベートプレビュー、GLM-5.3は提供可能になり次第のプレビュー開始とされています。

簡単なリクエストを安価なモデルへ送り、難しい処理だけを高性能モデルに任せるという考え方自体は新しくありません。Snowflakeの戦略的な特徴は、その判断を同社の統制されたデータとセキュリティの境界内に置こうとしている点です。

Snowflakeが報告した最大3倍のトークン効率は注目に値しますが、企業がその数字をそのまま導入効果とみなすべきではありません。自社のワークロードを使って、エンドツーエンドのコスト、品質、レイテンシー、信頼性、人による修正量を検証することが、導入判断の前提になります。