Streamlit in Snowflakeとは？料金・課金体系と使い方を徹底解説

Streamlit in Snowflakeは、PythonのデータアプリフレームワークであるStreamlitを、Snowflakeのデータクラウド内で直接動かせる機能です。多くの人がまず気にするのが料金ですが、結論から言うとStreamlit in Snowflakeそのものに追加のライセンス料はなく、課金対象はアプリの実行で消費したSnowflakeのコンピュート（クレジット）とストレージだけです。つまり「Snowflakeを普段使っている料金の延長線上」でアプリを動かせます。本記事では、この課金体系の仕組みを中心に、通常のStreamlitやCommunity Cloudとの料金の違い、コストを抑える運用のコツ、セットアップから可視化までの使い方を整理します。

まとめ：Streamlit in Snowflakeの料金と使い方の要点

• 機能そのものは無料。課金は消費したSnowflakeクレジット（コンピュート）とストレージのみで、Streamlit利用の別料金は発生しません。
• ウェアハウスで動かす場合、料金はコードウェアハウス（Streamlitサーバーを動かす）とクエリウェアハウス（SQLを実行する）の稼働時間に対して発生します。
• 閲覧者がアクセスするとコードウェアハウスが起動し、最後の操作から約15分接続が維持されたのち、AUTO_SUSPEND設定に従って自動停止します。この「アイドル中の稼働」がコスト増の主因です。
• Snowflakeのコンピュートは秒単位（起動・再開ごとに最低60秒）で課金され、クレジット単価はエディション・リージョンで異なります。
• StreamlitのOSSライブラリ自体はApache 2.0で無料、公開アプリを共有するStreamlit Community Cloudも無料です。Snowflake版はガバナンスとデータ近接性が強みになります。

Streamlit in Snowflakeとは？Snowflake内でPythonアプリを動かす仕組み

Streamlitは、数十行のPythonコードだけでグラフやフォームを備えたWebアプリを作れるオープンソースフレームワークです。Streamlit in Snowflakeは、そのStreamlitをSnowflakeのアカウント内部で実行できるようにしたもので、アプリのコードもデータもSnowflakeの境界の中で完結します。ローカルにサーバーを立てたり、外部クラウドにデプロイしてからSnowflakeへ接続したりする必要がありません。

通常のStreamlit・Community Cloudとの違い

従来、Streamlitでデータアプリを作るには、自前の環境（ローカルPCやクラウドVM、Community Cloud）でアプリを動かし、そこからSnowflakeへネットワーク接続してデータを取り出していました。この構成ではデータが一度Snowflakeの外へ出るため、認証情報の管理やネットワーク経路のセキュリティが課題になります。Streamlit in Snowflakeはアプリの実行環境をSnowflake側に置くため、データを外に出さずにアプリを配布でき、アクセス制御もSnowflakeのロール（RBAC）でそのまま管理できます。

コードウェアハウスとクエリウェアハウスという2つの実行主体

料金と挙動を理解するうえで欠かせないのが、アプリの実行に関わる2種類のコンピュートです。この分離が、そのまま課金の分離につながります。

ウェアハウスランタイムで動かす場合、この2つを同じウェアハウスにまとめることも、分けて割り当てることもできます。分けておくと、どちらの費用が膨らんでいるかを切り分けやすくなります。

Streamlit in Snowflakeの料金・課金体系

ここが本記事の中心です。料金の全体像は「機能は無料、動かした分のコンピュートとストレージに課金」で一貫しています。以下、課金が発生する箇所を分解します。

追加ライセンス料は不要｜課金は消費したクレジットだけ

Streamlit in Snowflakeを使うために、Snowflakeの通常料金とは別のプラン契約やアプリ利用料を払う必要はありません。課金対象は、アプリが動くために消費したコンピュート（Snowflakeクレジット）と、アプリのファイルやデータを置くストレージだけです。アプリを誰も開いていない時間帯にウェアハウスが停止していれば、その時間のコンピュート課金は発生しません。

ウェアハウスランタイムの課金：起動から自動停止までの流れ

標準的なウェアハウスランタイムでは、閲覧者がアプリのURLを開いた時点でコードウェアハウスが再開（起動）し、閲覧者ごとにStreamlitサーバープロセスとWebSocket接続が確立されます。このWebSocket接続は最後の操作から約15分維持され、その後に接続が切れると、ウェアハウスに設定されたAUTO_SUSPEND（自動停止までの無稼働時間）に従って停止します。課金はコードウェアハウスが稼働している間ずっと発生するため、「誰も操作していないのにウェアハウスが動き続けている15分＋AUTO_SUSPENDまでの猶予」がコストとして積み上がる点に注意が必要です。同時に複数人が同じアプリを開くと、それぞれのStreamlitサーバーが同一のコードウェアハウス上で動くため、同時アクセスが多いアプリではウェアハウスのサイズや停止設定が費用に効いてきます。

コンテナランタイム（Snowpark Container Services）の課金

アプリをコンテナランタイムで動かす構成を選んだ場合は、コードウェアハウスではなく、その基盤となるSnowpark Container Servicesのコンピュートプールに対して課金されます。より大きな依存ライブラリや長時間稼働のワークロードを想定する場合の選択肢で、料金の計算対象がコンピュートプールに変わる点を押さえておきます。

クレジット単価の目安と秒単位課金

Snowflakeのコンピュートはクレジットで測られ、ウェアハウスが起動・再開するたびに最低60秒、その後は秒単位で課金されます。クレジットの単価はエディション・リージョン・契約形態で変わり、オンデマンド課金のおおよその目安（2026年時点・AWS 米国東部）はStandardで1クレジット約2ドル、Enterpriseで約3ドル、Business Criticalで約4ドルです。実際の請求額は「稼働時間 × ウェアハウスサイズ（消費クレジット/時）× 単価」で決まるため、正確な金額は自社のエディションとリージョンで公式の料金表を確認してください。

コストを抑える運用のコツ

料金の仕組みが分かると、削れるコストのほとんどが「アイドル時間」と「過大なウェアハウス」に集中していることが見えてきます。競合記事では触れられにくい、実運用でのコスト最適化を具体的にまとめます。

AUTO_SUSPENDを短くしてアイドル課金を減らす

コードウェアハウスは約15分のWebSocket維持に加え、AUTO_SUSPENDの猶予時間だけ稼働を続けます。既定のまま長いAUTO_SUSPENDを使うと、閲覧が終わった後も課金が続きます。アプリ用のウェアハウスはAUTO_SUSPENDを短め（例：60秒）に設定し、無操作になったら速やかに止まるようにするのが基本です。次のように専用ウェアハウスへ設定します。

ALTER WAREHOUSE streamlit_app_wh SET
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

コードウェアハウスは小さめ（XS）から始める

Streamlitサーバーの起動やUIの描画そのものは軽く、重い処理の大半はSQLを実行するクエリウェアハウス側で起きます。そのため、コードウェアハウスはX-Small（XS）から始め、体感が重いときだけサイズを上げるのが無駄のない出発点です。最初から大きなウェアハウスを割り当てると、消費クレジット/時が跳ね上がり、アイドル時のコストも比例して増えます。

クエリ用ウェアハウスを分けて費用を可視化する

コードウェアハウスとクエリウェアハウスを分けて割り当てると、ACCOUNT_USAGEやウェアハウスごとのクレジット消費から「アプリ描画の費用」と「データ処理の費用」を切り分けられます。どちらが膨らんでいるかが分かれば、重いクエリのチューニングか、アプリの停止設定かという打ち手を選びやすくなります。

通常のStreamlit・Community Cloudの料金との比較

「streamlit 料金」と検索したときに気になるのは、Snowflake版ではないStreamlit本体の費用でしょう。ここを整理しておくと、どの構成を選ぶべきかが判断しやすくなります。

Streamlit本体（OSS）とCommunity Cloudは無料

StreamlitのライブラリはApache 2.0ライセンスのオープンソースで、インストールも利用も無料です。公開アプリをデプロイして共有できるStreamlit Community Cloudも無料で使えます。つまり「Streamlitを動かすこと自体」にソフトウェア料金はかかりません。費用が発生するのは、アプリを動かすためのインフラ（Community Cloud以外の自前サーバーやクラウド、あるいはSnowflakeのコンピュート）を用意したときです。

どちらを選ぶか：判断の基準

データがSnowflakeにあり、社内向けにガバナンスを効かせて配布したいならStreamlit in Snowflakeが有利です。データを外に出さず、アクセス権をSnowflakeのロールで一元管理できます。一方、外部の一般公開アプリや、Snowflakeを使っていない小規模なプロトタイプなら、無料のCommunity Cloudで十分なことが多いです。Snowflake版のコストは前述のコンピュート課金なので、常時多数のユーザーが触れる公開アプリでは料金設計を先に見積もっておくべきです。

セットアップと有効化の手順

Streamlit in Snowflakeは、Snowflakeの管理画面Snowsightから数ステップで作成できます。

事前準備：ロールとウェアハウス

アプリを作成するロールに、Streamlitオブジェクトを作成する権限（対象データベース・スキーマでのCREATE STREAMLIT）と、割り当てるウェアハウスの利用権限が必要です。あわせて、アプリ用のコードウェアハウス（XS推奨）を用意しておくと、既存の分析用ウェアハウスとコストを分離できます。

Snowsightからアプリを作成する

SnowsightのProjects配下にあるStreamlitから新規アプリを作成し、配置先のデータベース・スキーマと実行ウェアハウスを選ぶと、サンプルコード付きのエディタが開きます。ここにPythonを書けば、その場でプレビューしながら開発できます。SQLでStreamlitオブジェクトを直接作成することもできます。

CREATE STREAMLIT my_app
  ROOT_LOCATION = '@my_db.my_schema.my_stage/app'
  MAIN_FILE = 'streamlit_app.py'
  QUERY_WAREHOUSE = 'analytics_wh';

アプリの作成・実行とデータ可視化

アプリの中身は通常のStreamlitと同じ書き方ですが、Snowflakeデータへの接続方法が簡潔になります。

Snowflakeデータへの接続

Streamlit in Snowflakeでは、接続情報を書かずに現在のセッションを取得してSQLを実行できます。認証情報をコードに埋め込む必要がないため、資格情報の漏えいリスクを減らせます。

import streamlit as st
from snowflake.snowpark.context import get_active_session

session = get_active_session()
df = session.sql("SELECT month, sales FROM sales_summary").to_pandas()
st.bar_chart(df, x="month", y="sales")

グラフとダッシュボードの作り方

取得したデータは、Streamlit標準のst.line_chartやst.bar_chartで手早く可視化でき、より作り込んだ図はPlotlyやAltairで描けます。st.selectboxやst.sliderなどの入力ウィジェットと組み合わせると、閲覧者が条件を切り替えられるインタラクティブなダッシュボードになります。フィルタ条件の変更ごとにクエリウェアハウスへSQLが飛ぶため、重い集計はビューやキャッシュ（st.cache_data）でクエリ回数を抑えると、応答も費用も改善します。

ロール管理とデータ非流出で担保するセキュリティ・ガバナンス

Streamlit in Snowflakeのアプリは、閲覧・実行の権限をSnowflakeのロールで管理します。アプリを共有する相手にロールを付与し、その相手が持つデータアクセス権の範囲内でだけデータが見えるため、行レベルセキュリティやマスキングポリシーといった既存のガバナンス設定がそのまま効きます。データはSnowflakeの外に出ず、通信も暗号化されるため、外部ホスティングで課題になりがちな認証情報の受け渡しやネットワーク経路の管理から解放されます。

主なユースケース

社内向けの分析ダッシュボード、部門別のKPIモニタリング、データ入力・申請フォーム、機械学習モデルのスコアを確認する簡易UIなどが典型です。いずれも「Snowflake上のデータをそのまま業務担当者に見せたい」場面で、BIツールを別途契約するほどではないが表計算では足りない、という中間の需要に向いています。SnowflakeのAI機能と組み合わせれば、抽出・分析の結果を確認するフロントエンドとしても使えます。文書からの情報抽出を扱うSnowflake Document AIとは何か？その概要と提供される価値や、エージェント連携のSnowflake AIプラットフォームにおけるCortex Agentsとは何か？概要・定義と仕組みを徹底解説すると合わせて、分析基盤の全体像を描くと理解が進みます。

Anacondaチャンネルからのパッケージ追加とバージョン固定

Streamlit in Snowflakeでは、Snowflakeが用意するAnacondaチャンネルのパッケージを、アプリの環境設定から追加できます。エディタ上でパッケージを選ぶか、環境定義ファイルに依存ライブラリとバージョンを記述して固定します。バージョンを明示しておくと、後からライブラリが更新されても挙動が変わらず、安定した環境を保てます。利用できるパッケージはチャンネルに収録されているものが対象になるため、必要なライブラリが含まれるかを事前に確認しておくとつまずきません。

よくある質問（FAQ）

Streamlit in Snowflakeの利用に別料金はかかりますか？

機能そのものに追加のライセンス料はありません。課金されるのは、アプリの実行で消費したSnowflakeのコンピュート（クレジット）とストレージだけです。誰もアプリを開いておらずウェアハウスが停止していれば、その時間のコンピュート課金は発生しません。

アプリを閉じたのに料金が発生し続けるのはなぜですか？

閲覧者の最後の操作から約15分はWebSocket接続でコードウェアハウスが維持され、その後もAUTO_SUSPENDの猶予時間だけ稼働が続くためです。アプリ用ウェアハウスのAUTO_SUSPENDを短く設定すると、このアイドル課金を抑えられます。

Streamlit本体（Community Cloud版）は無料ですか？

StreamlitのライブラリはApache 2.0のオープンソースで無料、公開アプリを共有するStreamlit Community Cloudも無料です。費用が発生するのは、アプリを動かすインフラ（Snowflakeのコンピュートなど）を用意した場合です。

どのくらいのウェアハウスサイズを割り当てればよいですか？

Streamlitサーバーの描画自体は軽いため、コードウェアハウスはX-Small（XS）から始めるのが無駄がありません。重いのはSQLを処理するクエリウェアハウス側なので、必要に応じてそちらのサイズやチューニングで調整します。

コンテナランタイムとウェアハウスランタイムの料金の違いは？

ウェアハウスランタイムはコードウェアハウスの稼働時間に課金され、コンテナランタイムはSnowpark Container Servicesのコンピュートプールに課金されます。標準的な用途ではウェアハウスランタイム、より大きな依存や長時間稼働にはコンテナランタイムが選択肢になります。

関連記事

• Snowflake Document AIとは何か？その概要と提供される価値
• Snowflake AIプラットフォームにおけるCortex Agentsとは何か？概要・定義と仕組みを徹底解説する
• Snowflake Horizonとは何か？基本的な概念と利点を紹介
• Snowflakeの新AI機能「AI_EXTRACT」と「AI_PARSE_DOCUMENT」が日本語に対応