Snowflake「内部ステージ」でSnowpipe自動取り込み機能を試してみた (Auto-ingest)
🚀 はじめに
前回の記事（COPYコマンドと何が違う？ Snowflake「Snowpipe」自動取り込み入門）では、S3 などの外部ステージを使った Snowpipe の構築方法について記事にしました。
復習になってしまいますが、S3 イベント通知を使った Snowpipe は強力ですが、構築するには以下のハードルがありました。
- 「AWS コンソールで SQS や IAM ロールの設定が必要（権限がないと辛い…）」
- 「検証したいだけなのに、クラウド側の設定が面倒…」
- 「そもそもデータを外部に出さず、Snowflake の内部ステージだけで完結させたい」
現在（2025/11時点）、内部ステージをソースとする Snowpipe パイプに対しても、AUTO_INGEST = TRUE（自動取り込み）が設定可能 になっています（※一部環境でプレビュー）。
これにより、AWS/Azure/GCP 側のイベント通知設定を一切行わずに、Snowflake だけで完結する自動パイプラインが構築できます。
この記事では、この「内部ステージ版 Snowpipe Auto-ingest」を実際に構築し、ファイルを PUT するだけでデータがロードされる様子を検証します。
🏗️ 仕組み：カギは「ディレクトリテーブル」
外部ステージ（S3など）の場合は、クラウドプロバイダーからの「イベント通知（SQSなど）」がトリガーでした。
では、内部ステージの場合は何がトリガーになるのでしょうか？
答えは、「ディレクトリテーブル (Directory Table)」 です。
内部ステージにファイルをアップロードすると、Snowflake 内部でそのファイル一覧を管理する「ディレクトリテーブル」が更新されます。
内部ステージの自動取り込みは、「ディレクトリテーブルの自動更新（AUTO_REFRESH）＋ Pipe の AUTO_INGEST」の組み合わせ によって実現されています。
構成の違い
| 比較軸 | これまで (S3連携) | 今回 (内部ステージ) |
|---|---|---|
| ステージ | 外部ステージ (S3/GCS/Azure) | 内部ステージ |
| トリガー | クラウド側のイベント通知 (SQS等) | ディレクトリテーブル (AUTO_REFRESH) |
| 設定範囲 | Snowflake + AWS/Azure/GCP | Snowflake だけで完結 |
🧪 検証環境の構築
それでは、実際にやってみましょう。
今回は ACCOUNTADMIN ロールで実行します（権限周りをシンプルにするため）。
ステップ1：ターゲットテーブルの作成
まずはロード先のテーブルを作ります。
CREATE DATABASE IF NOT EXISTS PIPE_TEST_DB;
CREATE SCHEMA IF NOT EXISTS PIPE_TEST_DB.PUBLIC;
USE SCHEMA PIPE_TEST_DB.PUBLIC;
CREATE OR REPLACE TABLE TARGET_TABLE (
col1 VARCHAR,
col2 VARCHAR
);
ステップ2：ディレクトリテーブル付き「内部ステージ」の作成
ここが最大のポイントです。
通常の内部ステージ作成に加えて、DIRECTORY パラメータで AUTO_REFRESH = TRUE を指定します。
CREATE OR REPLACE STAGE MY_INTERNAL_STAGE
-- ディレクトリテーブルを有効化し、自動更新をONにする
DIRECTORY = (
ENABLE = TRUE,
AUTO_REFRESH = TRUE
)
-- (オプション) 暗号化方式などはお好みで
ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
ステップ3：Auto-ingest Pipe の作成
内部ステージを指定して、AUTO_INGEST = TRUE のパイプを作成します。
外部ステージのときのような AWS_SNS_TOPIC などの指定は不要です。シンプル！
CREATE OR REPLACE PIPE MY_INTERNAL_PIPE
AUTO_INGEST = TRUE
AS
COPY INTO TARGET_TABLE
FROM @MY_INTERNAL_STAGE
FILE_FORMAT = (TYPE = 'CSV' FIELD_OPTIONALLY_ENCLOSED_BY = '"');
これで構築は完了です。AWS コンソールを開く必要は一度もありませんでした。
📤 動作検証：ファイルをPUTして自動ロード
では、実際にファイルをアップロードして、自動的にロードされるか確認してみましょう。
内部ステージへのアップロードには、SnowSQL (CLI) や Python Connector の PUT コマンドを使います。
（※Snowsight の UI からファイルをアップロードした場合も同様にトリガーされます）
1. ローカルでCSVファイルを作成
data1.csv という名前で以下の内容のファイルを作成します。
"A","Data1"
"B","Data2"
2. SnowSQL でファイルをPUT
ターミナル（コマンドプロンプト）から SnowSQL で接続し、PUT コマンドを実行します。
# SnowSQLでログイン後に実行
PUT file://path/to/data1.csv @MY_INTERNAL_STAGE AUTO_COMPRESS=FALSE;
3. 自動ロードの確認
ファイルがアップロードされたら、少し待ってからテーブルを確認します。
（通常は数十秒〜数分程度で反映されます ※負荷状況により変動します）
-- テーブルを確認
SELECT * FROM TARGET_TABLE;
実行結果:
| COL1 | COL2 |
|---|---|
| A | Data1 |
| B | Data2 |
無事、自動的にロードされました！🎉
4. パイプの状態確認
もしロードされない場合は、SYSTEM$PIPE_STATUS で状態を確認できます。
SELECT SYSTEM$PIPE_STATUS('MY_INTERNAL_PIPE');
"executionState":"RUNNING" となっていれば正常に稼働しています。
Snowsightで「Pipe」の状況を見ても正常に取り込めていることが確認できます！
🚨 知っておくべき「注意点」とコスト
非常に便利な機能ですが、いくつか注意点があります。
1. ディレクトリテーブルのコスト（Snowpipeとして計上）
この機能は「ディレクトリテーブル」に依存しています。
ディレクトリテーブルはメタデータを管理するため、ストレージコストとは別に、Snowpipe と同じ課金レートで少額のクレジット（イベント通知やメタデータ更新のオーバーヘッド）が発生します。
これらのコストは ACCOUNT_USAGE.PIPE_USAGE_HISTORY などで確認できます。
（※自動クラスタリングのコストではありません）
2. 対応ステージは主に「名前付き内部ステージ」
Auto-ingest は主に名前付き内部ステージ (Named Internal Stage) を対象としてプレビュー提供されています。
テーブルステージ (%table_name) については、アカウントやリージョン、今後のアップデートで扱いが変わる可能性があるため、利用時は最新ドキュメントを確認してください。また、各ユーザーに紐づくユーザーステージ (~) は対象外です。
😌 おわりに
外部クラウド（AWS/Azure/GCP）の設定なしで、Snowflake だけで完結する自動取り込みパイプライン。
検証環境や、外部クラウドの権限取得が難しいプロジェクトでは、まさに「救世主」のような機能です。
- S3/SQS連携: 本格的なデータレイク連携、大規模運用向け
- 内部ステージ連携: サンドボックス、一時的なデータ連携、Snowflake完結型アプリ向け
前回の記事と合わせて、この2つのパターンを使い分けることで、データエンジニアリングの幅がさらに広がります。
ぜひ、みなさんも手元の環境で試してみてください！
Discussion