トップ / 基礎知識
UDF・UDTF・ストアドプロシージャでは対応できない「任意の言語・ランタイム・ライブラリ」をSnowflake内で動かすための、一般提供済みのコンテナ実行基盤です。
このサイトの「UDF・Vectorized UDF・UDTF・ストアドプロシージャの使い分け」で扱った4つの手段は、いずれもSnowflakeが用意したPythonの実行サンドボックスの中で動きます。使えるライブラリやランタイムのバージョンはSnowflakeが提供する範囲に限られ、GPUを使った処理や、Python以外の言語・独自のOSレベルの依存関係を必要とするアプリケーションは、この枠組みでは動かせません。
Snowpark Container Servicesは、この制約を取り払うための、Snowflake内で完結する管理型のコンテナオーケストレーション基盤です。公式ドキュメントは「アプリケーションとその依存関係をOCI（Open Container Initiative）イメージにパッケージ化でき、そこには任意のプログラミング言語・フレームワーク・ライブラリを含められる」と説明しています。つまり、UDFのようにSnowflakeが用意した実行環境の中に収めるのではなく、自分でDockerイメージを作ってSnowflakeの中で動かすという発想です。
インフラの管理（コンピュートリソースの確保・オーケストレーション）はSnowflakeが引き受けますが、コンテナの中身（OS・ランタイム・ライブラリの構成）は利用者が完全にコントロールします。
Snowpark Container ServicesはAWSで2024年8月に全商用リージョンで一般提供（GA）となり、Google Cloud Platformは2025年8月に一般提供となりました（いずれもSnowflake公式のリリースノートで確認済み）。Microsoft Azureも現在サポート対象のクラウドに含まれていますが、Azure単体でのGA化の日付は、Native Apps対応など個別機能ごとのリリースノートに分かれており、本稿では単一の日付を特定していません。現在はAWS・Azure・GCPの商用リージョンで、有償のSnowflakeエディションであれば利用できます。トライアルアカウントや無料枠のアカウントでは利用できない点に注意してください。
公式ドキュメントは主に3つの使い方を挙げています。
1. バッチジョブ：ストアドプロシージャに似た形で、柔軟なジョブを実行する。GPUを使う計算集約的なタスク（機械学習モデルの学習・推論など）に向く 2. サービス関数：SQLのクエリから、コンテナ内で動くカスタム処理を関数として呼び出す 3. APIやWeb UIの公開：Snowflake上のデータを扱うビジネスロジックを、APIやWebアプリケーションとして外部に公開する
計算プール（Compute Pool）を作成する際にマシンタイプを指定でき、GPU対応のインスタンスファミリーも選択できるため、機械学習モデルの学習・推論やAIを使った高度な分析といった、CPUだけでは重い処理にも対応します。
判断の軸は「Snowflakeが用意した実行環境で足りるか、自分でコンテナごと持ち込む必要があるか」です。前者で足りるならUDF・ストアドプロシージャの方が構築・運用ともに軽く済み、後者が必要になった時点でSnowpark Container Servicesを検討する、という順序になります。
公式ドキュメントの記載にもとづく解説です（実行検証はしていません）。確認日：2026-09-19