---
title: "Streamlit in Snowflakeの料金・課金体系｜ウェアハウスとコンテナランタイムの費用と使い方"
url: "https://www.issoh.co.jp/tech/details/5956/"
published: 2025-03-21
updated: 2026-10-15
categories: ["データ分析・BI"]
publisher: "株式会社一創"
---

# Streamlit in Snowflakeの料金・課金体系｜ウェアハウスとコンテナランタイムの費用と使い方

Streamlit in Snowflakeに追加のライセンス料はありません。請求されるのは、アプリのPythonコードを動かすランタイムと、アプリ内のSQLを実行するクエリウェアハウスが消費したSnowflakeクレジットです。ここにストレージが加わります。費用の差を生むのはランタイムの選び方です。ウェアハウスランタイムは接続中と自動停止までの待機中に課金され、コンテナランタイムは閲覧が3日間途切れてサーバーが終わるまでノードの課金が続きます。2026年9月に既定で有効になった2026\_06バンドルが適用されるアカウントでは、SQLでランタイム指定を省いた新規アプリがコンテナランタイムになります（政府機関・中国リージョンとNative Appは対象外）。この記事では、東京リージョンの単価での月額試算、課金を止める設定、費用を確認するSQL、アプリの作り方を順に説明します。

## まとめ：Streamlit in Snowflakeの料金の要点

- **機能そのものは無料**です。基本の課金はランタイム（ウェアハウスかコンピュートプール）とクエリウェアハウスのクレジット、それにストレージです。外部へのデータ転送など、使い方によって加わる費用もあります。
- **ウェアハウスランタイム**は閲覧者が開くとウェアハウスが起動します。通常は各閲覧者の最後の操作から約15分で接続が切れ、すべての接続が終了した後、自動停止設定に従ってウェアハウスが停止します。X-Smallは1時間1クレジットで、起動ごとに最低60秒分が課金されます。
- **コンテナランタイム**はノード単価が安く（CPU\_X64\_XSで1時間0.06クレジット）、通常は閲覧が3日間ないとサーバーが終了し、プールはその後、自動停止設定に従って停止します。毎日利用する場合は、手動停止を組み込まない限り常時稼働として見積もります。
- 東京リージョンのオンデマンド単価は1クレジットあたり**Standard 2.85ドル／Enterprise 4.30ドル／Business Critical 5.70ドル**です（2026年10月12日発効の料金表）。
- 2026\_06バンドルが有効なアカウントでは、`RUNTIME_NAME`を省いた`CREATE STREAMLIT`がコンテナランタイムになります。ウェアハウスランタイムを使うなら明示が必要です。
- Streamlit本体はApache-2.0のOSSで無料、Streamlit Community Cloudも無料です。Snowflakeのデータを社外に出さずに配りたいときにSnowflake版を選びます。

## Streamlit in Snowflakeの料金の内訳

公式ドキュメントの[Managing costs for Streamlit in Snowflake](https://docs.snowflake.com/en/developer-guide/streamlit/object-management/billing)は、課金を「アプリのランタイム環境」と「クエリウェアハウス」の2つで説明しています。ここにストレージを足したものが基本的な費用です。利用内容によっては、クラウドサービスやデータ転送などの料金も発生します。

| 課金対象             | 何に使われるか               | 課金の単位              |
| ---------------- | --------------------- | ------------------ |
| ランタイム（ウェアハウス）    | Streamlitサーバーとアプリのコード | 稼働秒数×サイズ別クレジット     |
| ランタイム（コンピュートプール） | 同上（コンテナランタイム）         | ノード数×稼働秒数×ノード単価    |
| クエリウェアハウス        | アプリ内で発行するSQL          | 稼働秒数×サイズ別クレジット     |
| ストレージ            | アプリのファイル・テーブル         | 月平均TB（東京は1TB 25ドル） |

ソースコードだけならストレージ費用は小さくなりやすい一方、画像などの同梱ファイルや保存テーブルが大きい場合は、月平均の保存容量を別途見積もります。費用を決めるのはランタイムとクエリウェアハウスの稼働時間です。ウェアハウスランタイムでは、何も指定しなければ同じウェアハウスがコードの実行とSQLの両方を受け持ちます。コンテナランタイムでは、コードはコンピュートプール、SQLは`QUERY_WAREHOUSE`で指定したウェアハウスで動くので、請求も自然に2本に分かれます。

## ウェアハウスランタイムの課金：閲覧中と約15分の待機時間

ウェアハウスランタイムでは、閲覧者がアプリを開くとコード用のウェアハウスが再開し、閲覧者ごとにStreamlitサーバーのプロセスが起動します。同時に5人が開けば、同じウェアハウスの上で5つのプロセスが動きます。

### 課金が止まるまでの流れと最低60秒の課金

ブラウザとサーバーのあいだのWebSocket接続がウェアハウスを動かし続け、接続は閲覧者の最後の操作から**約15分**で切れます。アプリの上でマウスを動かすだけでも操作とみなされます。接続が切れたあと、ウェアハウスは自身の`AUTO_SUSPEND`の秒数が過ぎてから止まります。`AUTO_SUSPEND`の既定値は600秒なので、設定を変えないと「最後の操作から約15分＋10分」課金が続きます。

ウェアハウスの課金は[秒単位で、起動・再開のたびに最低60秒分](https://docs.snowflake.com/en/user-guide/cost-understanding-compute)です。停止と再開を1分以内に繰り返すと、そのたびに1分ずつ課金されます。アプリ専用のウェアハウスを作り、待機時間を短くしておきます。公式は初期化中に止まらないよう30秒以上を勧めています。

```
CREATE WAREHOUSE IF NOT EXISTS streamlit_app_wh
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE;
```

### スリープタイマーによる待機時間の短縮

約15分のWebSocketタイムアウトはアカウント単位の設定で、変更するにはSnowflakeサポートへの依頼が必要です。アプリ単位では[カスタムスリープタイマー](https://docs.snowflake.com/en/developer-guide/streamlit/features/sleep-timer)を使います。アプリの`.streamlit/config.toml`に次のように書くと、8分間操作がなければアプリが停止します。設定できるのは5〜240分です。

```
[snowflake]
[snowflake.sleep]
streamlitSleepTimeoutMinutes = 8
```

スリープタイマーが効くのはウェアハウスランタイムだけです。また、ブラウザが非アクティブなタブのタイマーを止めると、WebSocketタイムアウトのほうが先に効くことがあります。タイマーを15分より短くしても、その通りに止まらない場面がある点は見込んでおきます。急いで止めたいときは、Snowsightからアプリを手動で停止するか、アプリを開いているタブをすべて閉じます。

## コンテナランタイムの課金：3日間続くコンピュートプールの稼働

コンテナランタイムは[2026年3月9日に一般提供（GA）](https://docs.snowflake.com/en/release-notes/2026/other/2026-03-09-sis-container-runtime-ga)になりました。アプリはSnowpark Container Services（SPCS）のコンピュートプール上で常駐するサービスとして動き、閲覧者全員が1つのStreamlitサーバーにつながります。課金対象はコンピュートプールのノードです。

### ノード単価とSYSTEM\_COMPUTE\_POOL\_CPUの既定設定

[Snowflake Service Consumption Table](https://www.snowflake.com/legal-files/CreditConsumptionTable.pdf)（2026年10月12日発効）では、CPU\_X64\_XSのノード単価は1時間0.06クレジットで、Gen1の標準X-Smallウェアハウスの約17分の1です。

| コンピュート            | クレジット/時 | 最低課金     |
| ----------------- | ------- | -------- |
| ウェアハウス X-Small    | 1       | 起動ごとに60秒 |
| ウェアハウス Small      | 2       | 起動ごとに60秒 |
| CPU\_X64\_XS（ノード） | 0.06    | 起動ごとに5分  |
| CPU\_X64\_S（ノード）  | 0.11    | 起動ごとに5分  |
| CPU\_X64\_M（ノード）  | 0.22    | 起動ごとに5分  |

コンピュートプールを指定せずに作ったアプリは、アカウントパラメータ`DEFAULT_STREAMLIT_COMPUTE_POOL`のプールで動きます。新しいアカウントでは`SYSTEM_COMPUTE_POOL_CPU`が設定されています。[公式ドキュメント](https://docs.snowflake.com/en/developer-guide/snowpark-container-services/working-with-compute-pool)によると、このプールはCPU\_X64\_Sで、`MIN_NODES=1`・`MAX_NODES=150`・`AUTO_SUSPEND_SECS=259200`（3日）が既定です。1ノードで3つのアプリが動き、プールが動いているあいだは待機用ノードが1台無料で確保されます。自分で作ったプールでは、1アプリが1ノードをまるごと使います。

```
-- アカウントの既定プールを確認する
SHOW PARAMETERS LIKE 'DEFAULT_STREAMLIT_COMPUTE_POOL' IN ACCOUNT;
```

### 課金が止まる条件と止め方

コンテナランタイムには、ウェアハウスのようなスリープタイマーがありません。Streamlitサーバーは、閲覧が**3日間**ないときに初めて終了し、そのあとプールが自身の`AUTO_SUSPEND_SECS`に従って止まります。プールは稼働中の状態（ACTIVE）だけでなく、空いている状態（IDLE）でも課金されます。平日に毎日開かれるアプリは、週末をはさんでも3日に届かないので、実質24時間365日の課金になります。

止める手段は[ALTER COMPUTE POOL](https://docs.snowflake.com/en/sql-reference/sql/alter-compute-pool)です。`SUSPEND`はプール上のサービスをすべて一時停止し、`STOP ALL`はサービスを削除します。どちらもプール全体に効くので、Notebookなど他のワークロードと共有する`SYSTEM_COMPUTE_POOL_CPU`に夜間停止をかけるのは避け、Streamlit専用のプールを作ってから使います。

```
-- Streamlit専用のプール（XSノード1台）
CREATE COMPUTE POOL streamlit_pool
  MIN_NODES = 1
  MAX_NODES = 1
  INSTANCE_FAMILY = CPU_X64_XS
  AUTO_SUSPEND_SECS = 300
  AUTO_RESUME = TRUE;

-- 業務時間外に止める（タスクから呼ぶ想定）
ALTER COMPUTE POOL streamlit_pool SUSPEND;
```

停止したプールのアプリを次に開いたとき、どう再開するかは公式ドキュメントに記載がありません。夜間停止を運用に入れる前に、検証用のアプリで翌朝の再開と所要時間を確かめてください。ノードは起動のたびに最低5分分が課金されるので、短い間隔で停止と再開を繰り返す運用は逆効果です。

## 東京リージョンの単価による月額試算

単価だけ見るとコンテナが安く、稼働時間まで含めると答えが変わります。AWS東京リージョン・Enterpriseのオンデマンド単価（1クレジット4.30ドル）を使い、ウェアハウスはGen1の標準ウェアハウス・単一クラスターを前提として、アプリ1本を30日動かしたときのランタイム分を計算しました。クエリ用に別のウェアハウスを使う構成では、その費用を加算します。ウェアハウスランタイムでコードとSQLを同じウェアハウスで処理する場合、同じ稼働時間を二重に計上しません。

| 構成                      | 稼働時間/月 | クレジット | 費用（USD） |
| ----------------------- | ------ | ----- | ------- |
| ウェアハウスXS・1日1時間×20日      | 20時間   | 20    | 86.0    |
| ウェアハウスXS・1日2時間×20日      | 40時間   | 40    | 172.0   |
| ウェアハウスXS・1日8時間×20日      | 160時間  | 160   | 688.0   |
| コンテナCPU\_X64\_XS・常時稼働   | 720時間  | 43.2  | 185.8   |
| コンテナCPU\_X64\_XS・平日13時間 | 260時間  | 15.6  | 67.1    |
| 既定プールCPU\_X64\_S・常時稼働   | 720時間  | 79.2  | 340.6   |

XSノード1台の常時稼働は43.2クレジットで、XSウェアハウスの43.2時間分にあたります。ウェアハウスの稼働時間には、閲覧後の約15分と`AUTO_SUSPEND`の待機も含まれます。誰かが開いている時間に待機を足して**月43.2時間を超えるなら、ランタイム単体では専用XSプールのコンテナランタイムのほうが安く**なります。下回るなら、ウェアハウスランタイムのほうが安く済みます。

既定の`SYSTEM_COMPUTE_POOL_CPU`はCPU\_X64\_Sなので、ノード1台の常時稼働で79.2クレジットです。1ノードに3アプリが載るので、3本を並べればノード代は分け合えます。アプリが1本だけなら、専用のXSプールを作ったほうがノード単価は半分近くになります。この表はStandardなら0.66倍（2.85÷4.30）、Business Criticalなら1.33倍（5.70÷4.30）で読み替えてください。

実測の例として、クラスメソッドが社内ダッシュボード（利用者15名程度・月初に集中）をCPU\_X64\_XSのコンテナランタイムへ移した[比較記事](https://dev.classmethod.jp/articles/streamlit-warehouse-vs-container-runtime-cost/)を公開しています。毎日22時にプールを止めるタスクを入れた条件で、月の合計はウェアハウスランタイムの約12.44クレジットに対し、プールとクエリ用ウェアハウスの合計で約11.58クレジットでした。夜間停止を入れても、合計ではほぼ横ばいという結果です。

## ランタイムの選び方：判断の基準と避けたい構成

費用で選ぶには、ランタイム単体の分岐点である月43.2時間を目安に、クエリウェアハウスの実消費も含めて比較します。費用以外の差も大きいので、次の表で確認します。

| 項目           | ウェアハウスランタイム          | コンテナランタイム        |
| ------------ | -------------------- | ---------------- |
| サーバー         | 閲覧者ごとに起動             | 全員で1つを共有         |
| 停止           | 約15分・スリープタイマー        | 閲覧なし3日で停止        |
| Python       | 3.9・3.10・3.11        | 3.11のみ           |
| Streamlit    | 1.22以降の一部の版          | 1.50以降の全版        |
| パッケージ        | Snowflake Condaチャンネル | PyPIなど（外部アクセス統合） |
| キャッシュ        | セッション内のみ             | 閲覧者間で共有          |
| 表示データ・アップロード | 32MB・200MB           | 設定で変更可           |

出典は[Runtime environments for Streamlit apps](https://docs.snowflake.com/en/developer-guide/streamlit/app-development/runtime-environments)と[Limitations and library changes](https://docs.snowflake.com/en/developer-guide/streamlit/limitations)です。毎日多くの人が開く社内ダッシュボードや、`st.cache_data`で重い集計を閲覧者間で使い回したいアプリはコンテナランタイムが向いています。月に数回しか開かない確認用のアプリや、検証用に作って放置しがちなアプリは、ウェアハウスランタイムにしてください。

避けたいのは、使われなくなったコンテナランタイムのアプリを残すことです。誰かが3日に1回でも開けば、ノードは止まりません。もう1つは、ウェアハウスランタイムで分析用の大きなウェアハウスをコード実行に割り当てることです。Mediumなら1時間4クレジットで、閲覧後の待機時間もこの単価で課金されます。

## 2026\_06バンドルによる新規アプリの既定ランタイム変更

[BCR-2342](https://docs.snowflake.com/en/release-notes/bcr-bundles/2026%5F06/bcr-2342)により、2026\_06バンドルが有効なアカウントでは、`RUNTIME_NAME`を省略した`CREATE STREAMLIT`が`SYSTEM$ST_CONTAINER_RUNTIME_PY3_11`のアプリを作ります。以前の既定は`SYSTEM$WAREHOUSE_RUNTIME`でした。このバンドルは2026年9月の10.32リリースで「既定で有効」に変わり、管理者が無効にしない限り適用されます。既存のアプリは変わりません。

以前の手順書のSQLをそのまま流すと、意図せずコンテナランタイムのアプリができ、既定プールで常時課金が始まります。ウェアハウスランタイムを使い続けるなら、次のように明示します。政府機関・中国リージョンのアカウントと、Native Appが作るアプリは対象外です。

```
CREATE STREAMLIT sales_dashboard
  FROM '@my_db.my_schema.app_stage/sales_dashboard'
  MAIN_FILE = 'streamlit_app.py'
  QUERY_WAREHOUSE = streamlit_app_wh
  RUNTIME_NAME = 'SYSTEM$WAREHOUSE_RUNTIME';
```

## 費用を確認するSQL：ウェアハウスとコンピュートプール

ウェアハウス分は`WAREHOUSE_METERING_HISTORY`、コンピュートプール分は[SNOWPARK\_CONTAINER\_SERVICES\_HISTORY](https://docs.snowflake.com/en/sql-reference/account-usage/snowpark%5Fcontainer%5Fservices%5Fhistory)で、どちらも1時間単位のクレジットが取れます。アプリ専用のウェアハウスとプールに分ければ、名前で絞って消費クレジットを集計できます。ただしウェアハウスのCREDITS\_USEDはクラウドサービスの調整前で、請求クレジットとは一致しない場合があります。実請求との照合にはMETERING\_DAILY\_HISTORYも確認します。

```
-- ウェアハウスランタイム・クエリウェアハウス分（月別）
SELECT DATE_TRUNC('month', start_time) AS month,
       warehouse_name,
       SUM(credits_used) AS credits
FROM snowflake.account_usage.warehouse_metering_history
WHERE warehouse_name = 'STREAMLIT_APP_WH'
  AND start_time >= DATEADD('month', -3, CURRENT_DATE())
GROUP BY 1, 2
ORDER BY 1;

-- コンテナランタイム分（月別）
SELECT DATE_TRUNC('month', start_time) AS month,
       compute_pool_name,
       SUM(credits_used) AS credits
FROM snowflake.account_usage.snowpark_container_services_history
WHERE compute_pool_name = 'STREAMLIT_POOL'
  AND start_time >= DATEADD('month', -3, CURRENT_DATE())
GROUP BY 1, 2
ORDER BY 1;
```

`SNOWPARK_CONTAINER_SERVICES_HISTORY`は反映まで最大3時間かかります。共有のウェアハウスで複数のアプリを動かしている場合は、`QUERY_HISTORY`の`QUERY_TAG`を見ます。[BCR-1571](https://docs.snowflake.com/en/release-notes/bcr-bundles/2024%5F03/bcr-1571)以降、Streamlitから出たクエリには`"StreamlitName": "DB.SCHEMA.APP"`形式のJSONが入り、アプリ別に実行時間を集計できます。ただしこれは実行時間の内訳で、請求額そのものではありません。Snowsightの画面からコストを追う方法は[Snowsightとは：Workspaces移行後の使い方・Git連携・コスト確認SQLを解説【2026年版】](/tech/details/18040/)で扱っています。

## Streamlit本体・Community Cloudとの料金比較

Streamlitのライブラリは[PyPI](https://pypi.org/project/streamlit/)でApache-2.0として配布されているOSSで（2026年10月時点の最新は1.66.0）、商用利用も無料です。公開アプリの置き場であるStreamlit Community Cloudも、[公式](https://docs.streamlit.io/deploy/streamlit-community-cloud)が無料と案内しています。

| 項目     | Community Cloud  | Streamlit in Snowflake |
| ------ | ---------------- | ---------------------- |
| 料金     | 無料               | クレジット従量                |
| リソース   | メモリ最大約2.7GB      | ウェアハウス・ノードで選択          |
| スリープ   | 12時間アクセスなしで休止    | ランタイムによる               |
| 非公開アプリ | 1本まで             | ロールで共有範囲を管理            |
| データ接続  | 外部からSnowflakeへ接続 | アカウント内で完結              |

Community Cloudのリソース上限は[公式](https://docs.streamlit.io/deploy/streamlit-community-cloud/manage-your-app)が「2024年2月時点のおおよその値」としており、予告なく変わります。社外に公開するデモや個人のプロトタイプならCommunity Cloudで足ります。社内データを扱うアプリでは、Snowflake内の接続と共有管理を使えるSnowflake版が候補になります。ただし既定の接続は所有者権限で動くため、閲覧者のロールや行アクセスポリシーがそのまま適用されるわけではありません。閲覧者別の制御には、ランタイムに応じたコンテキスト関数と権限設定の確認が必要です。Streamlitそのものの書き方は[Streamlitとは？できること・使い方・料金を実例コードで解説【Python】](/tech/details/3321/)にまとめています。

## Streamlit in Snowflakeの使い方：アプリの作成と接続

現在の公式手順では、Snowsightの「Workspaces」でワークスペースを開き、「+ Add new」→「Streamlit app」から作成します。「Projects」→「Streamlit」はデプロイ済みアプリの閲覧に使います。SQLで作るときは`FROM`句を使います。掲載例を実行した後は、`ALTER STREAMLIT sales_dashboard ADD LIVE VERSION FROM LAST;`を実行するか、所有者ロールでSnowsightからアプリを開いて初期化します。旧来の`ROOT_LOCATION`はレガシー扱いで、コンテナランタイムでは使えず、複数ファイル編集とGit連携にも対応しません。

### コンテナランタイムで作成するSQL

コンテナランタイムでは、`QUERY_WAREHOUSE`はアプリ内のSQLを実行するウェアハウスです。アプリを作るロールには、プールとクエリ用ウェアハウスの`USAGE`、配置先データベースとスキーマの`USAGE`、スキーマの`CREATE STREAMLIT`などが必要です。以下は、指定する内部ステージに`streamlit_app.py`を配置済みで、ステージを読み取れることを前提とした例です。オブジェクト名は利用環境に合わせて変更します。

```
CREATE STREAMLIT sales_dashboard
  FROM '@my_db.my_schema.app_stage/sales_dashboard'
  MAIN_FILE = 'streamlit_app.py'
  RUNTIME_NAME = 'SYSTEM$ST_CONTAINER_RUNTIME_PY3_11'
  COMPUTE_POOL = streamlit_pool
  QUERY_WAREHOUSE = analytics_wh;
```

依存ライブラリは、ウェアハウスランタイムでは`environment.yml`（Snowflake Condaチャンネル）、コンテナランタイムでは`requirements.txt`か`pyproject.toml`に書きます。PyPIから入れるには外部アクセス統合を`EXTERNAL_ACCESS_INTEGRATIONS`で付けます。

### データ接続とクエリ用ウェアハウスの切り替え

ウェアハウスランタイムでは、`QUERY_WAREHOUSE`に指定したウェアハウスが**コードの実行に使われ**、何もしなければSQLも同じウェアハウスで動きます。重い集計だけ大きなウェアハウスに回すには、アプリのコードで切り替えます。以下は、アプリ所有者が利用できる`analytics_wh`と、現在のデータベース・スキーマ内に`month`列・数値型の`amount`列を持つ`sales`テーブルがあることを前提とした例です。小さいウェアハウスで待機時間を払い、重いSQLの時間だけ大きいウェアハウスを使う構成です。

```
import streamlit as st

conn = st.connection("snowflake")
session = conn.session()
session.use_warehouse("analytics_wh")

@st.cache_data(ttl=600)
def load_sales():
    return session.sql(
        "SELECT month, SUM(amount) AS sales FROM sales GROUP BY month ORDER BY month"
    ).to_pandas()

df = load_sales()
st.bar_chart(df, x="MONTH", y="SALES")
```

接続情報をコードに書く必要はありません。`st.cache_data`は、コンテナランタイムでは既定で閲覧者間に共有されるため、同じキャッシュが有効な間は集計結果を再利用できます。この例ではTTLが600秒なので、期限切れ後の呼び出しではSQLを再実行します。ウェアハウスランタイムではキャッシュがセッション内に閉じるため、同じ効果は出ません。Snowflake上のデータで社内ダッシュボードやBIの置き換えを検討している場合は、[BIツール導入支援](https://www.issoh.co.jp/service/ai/bi/)でランタイムの選定から相談を受けています。LLMを使うチャット画面を作るなら、Cortexの関数と組み合わせる[Snowflake Cortex AIとは？機能一覧・料金・日本リージョンの制約と読み方](/tech/details/5958/)を参照してください。

## よくある質問

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

かかりません。請求されるのは、ランタイム（ウェアハウスかコンピュートプール）とクエリウェアハウスが消費したクレジット、それにストレージです。外部へのデータ転送など、使い方によって加わる費用もあります。東京リージョンのオンデマンド単価は1クレジット2.85〜5.70ドルで、エディションによって変わります。

### アプリを閉じたのに課金が続くのはなぜですか？

ウェアハウスランタイムでは、すべての閲覧タブを閉じるとWebSocket接続が切れますが、その後もウェアハウスの`AUTO_SUSPEND`の秒数だけ稼働します。コンテナランタイムでは、閲覧が3日間ないとサーバーが止まらないため、閉じても課金が続きます。前者はスリープタイマーと短い`AUTO_SUSPEND`で、後者は専用プールの停止で抑えます。

### Streamlit Community Cloudは無料ですか？

無料です。ただしメモリは最大約2.7GBで、12時間アクセスがないアプリは休止し、非公開アプリは1本までです。社内データを扱うアプリにはSnowflake版が向いています。

### Streamlitは商用利用できますか？

できます。StreamlitはApache-2.0ライセンスのOSSで、社内アプリや商用サービスに組み込んでも利用料はかかりません。Streamlit in Snowflakeで動かす場合も、ライブラリ自体への支払いは発生しません。

### 無料トライアルで試せますか？

試せます。Snowflakeの無料トライアルには400ドル分の利用枠があり、登録から30日か、枠を使い切るまでのどちらか早いほうで終わります。トライアル中もランタイムの課金の仕組みは同じなので、試算表の構成を小さく再現して、クレジットの減り方を先に確かめておくと本番の見積もりに使えます。

## 関連記事

- [Streamlitとは？できること・使い方・料金を実例コードで解説【Python】](/tech/details/3321/)
- [Snowsightとは：Workspaces移行後の使い方・Git連携・コスト確認SQLを解説【2026年版】](/tech/details/18040/)
- [BigQueryとSnowflakeの比較：課金モデルの構造差と同時実行で決める選定基準](/tech/details/16670/)
- [Snowflake Cortex AIとは？機能一覧・料金・日本リージョンの制約と読み方](/tech/details/5958/)
- [StreamlitでチャットボットのUIを作る手順｜st.chat\_input・session\_stateで会話履歴を保持する実装](/tech/details/4412/)

---

出典: [Streamlit in Snowflakeの料金・課金体系｜ウェアハウスとコンテナランタイムの費用と使い方](<https://www.issoh.co.jp/tech/details/5956/>)（株式会社一創）