第3章データロード・アンロードと接続 / 想定学習時間:30〜40分 / 最終確認:2026年8月

3-6. アンロードと統合(COPY INTO location・storage/API/Git integration)

🎯 この節の学習目標

COPY INTO <location> によるアンロードの既定動作(gzip 圧縮 CSV・ファイル分割)と主なオプションを説明できる
storage integration が資格情報を秘匿する仕組みと利点を説明できる
API / notification / catalog / Git repository の各 integration の役割を対応付けられる
ドライバ・コネクタ(Kafka Connector など)による外部システム接続を整理できる

1. アンロード:COPY INTO の向きを逆にする

これまで学んだロードとは逆に、テーブルのデータをファイルとして書き出す操作をアンロード(unload)と呼びます。使うコマンドはロードと同じ COPY INTO ですが、向きが逆です。

	ロード	アンロード
構文	`COPY INTO <table> FROM @stage`	`COPY INTO @stage FROM <table>`(またはクエリ)
データの流れ	ステージのファイル → テーブル	テーブル(またはクエリ結果) → ステージのファイル

-- テーブルをステージへアンロードする(既定:gzip 圧縮 CSV・複数ファイルに分割)
COPY INTO @my_stage/export/
  FROM sales;

-- クエリ結果をアンロードすることもできる
COPY INTO @my_stage/export/
  FROM (SELECT sale_id, amount FROM sales WHERE sale_date >= '2026-01-01');

-- その後、内部ステージなら GET でローカルへダウンロードする
GET @my_stage/export/ file:///local/download/;

アンロードの既定動作とよく使うオプションを整理します。

項目	既定・オプション
形式と圧縮	既定は gzip 圧縮された CSV。FILE_FORMAT の指定で Parquet や JSON へのアンロードも可能
ファイル分割	既定(SINGLE = FALSE)では並列処理により複数ファイルに分割して出力される。1ファイルにまとめたい場合は SINGLE = TRUE。分割サイズの上限は MAX_FILE_SIZE で調整
PARTITION BY	式の値(日付など)ごとにサブディレクトリを分けて出力する
HEADER = TRUE	先頭行に列名ヘッダーを出力する

テーブル / クエリ結果SELECT で列の絞り込み・加工も可能

↓COPY INTO @stage FROM ...(既定:gzip 圧縮 CSV・複数ファイルに分割)

ステージ上のファイル内部ステージ or 外部ステージ(S3 / Azure Blob / GCS)

GET でローカルへ内部ステージからのダウンロード

外部システムが直接利用クラウドストレージ経由で他システムへ連携

図:アンロードの流れ。テーブル → ステージ → ローカルまたは外部システムへ

📝 試験のポイント

アンロードの既定は「gzip 圧縮 CSV」「複数ファイルへの分割(SINGLE = FALSE)」です。「1つのファイルに出力されるはずが複数に分かれた」という状況を問う問題では、この既定動作が答えの軸になります。また「内部ステージからローカルに取り出すコマンドは GET」という 3-1 との接続も再確認しておきましょう。

2. storage integration:資格情報を SQL に書かない

外部ステージ(3-1)の作成には、クラウドストレージへのアクセス権が必要です。アクセスキーとシークレットを SQL 文に直接書くこともできますが、キーの漏えい・ローテーションの手間などの問題があります。そこで推奨されるのが storage integration です。

storage integration は、IAM ロール(AWS の場合)などクラウド側の認証の仕組みに委任するためのアカウントレベルのオブジェクトです。
一度作成すれば、複数の外部ステージから再利用できます。
ステージ作成時は STORAGE_INTEGRATION = ... と参照するだけで、シークレットが SQL 文・ステージ定義のどこにも現れません。

💡 具体例:storage integration を使った外部ステージ

-- 管理者が一度だけ作成する(アカウントレベルのオブジェクト)
CREATE STORAGE INTEGRATION my_s3_int
  TYPE = EXTERNAL_STAGE
  STORAGE_PROVIDER = 'S3'
  ENABLED = TRUE
  STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::123456789012:role/snowflake-role'
  STORAGE_ALLOWED_LOCATIONS = ('s3://my-bucket/export/');

-- ステージは integration を参照するだけ。キーはどこにも書かない
CREATE STAGE my_ext_stage
  URL = 's3://my-bucket/export/'
  STORAGE_INTEGRATION = my_s3_int;

-- 外部ステージへ直接アンロードできる
COPY INTO @my_ext_stage/daily/ FROM sales HEADER = TRUE;

STORAGE_ALLOWED_LOCATIONS により、この integration を使ってアクセスできる場所を制限できる点も、ガバナンス上の利点です。

3. integration ファミリー:外部との「接続点」を担うオブジェクト

storage integration のほかにも、Snowflake には外部サービスとの接続を担う integration オブジェクトがあります。試験では「どの integration が何のためか」の対応付けを問われます。

integration	つなぐ相手	役割
storage integration	クラウドストレージ(S3 / Azure Blob / GCS)	外部ステージの資格情報を秘匿して安全にアクセスする
API integration	API Gateway 経由のリモートサービス	外部関数(external function)などから外部の API を呼び出すための接続を定義する
notification integration	クラウドのメッセージング・通知サービス	イベント通知の送受信を担う(エラー通知の送信など)
catalog integration	外部の Iceberg カタログ	Apache Iceberg テーブルのメタデータ(カタログ)へ接続する
Git repository integration	Git リポジトリ	Git リポジトリを Snowflake に接続し、リポジトリ内のコードをステージのように参照できるようにする

4. ドライバ・コネクタと Kafka Connector

最後に、外部のアプリケーションから Snowflake に接続する手段を復習します。1-3 で学んだとおり、Snowflake には ODBC / JDBC ドライバ、Python・Node.js・Go などのコネクタ・ドライバ、Snowpark ライブラリ、そして SnowSQL(CLI) といった接続手段が用意されています。いずれもクラウドサービス層への接続を通じて SQL を実行する、という基本は同じです。

本章の文脈で特に押さえたいのが Snowflake Connector for Kafka です。

Kafka のトピックに流れるメッセージを、Snowflake のテーブルへ継続的に取り込むためのコネクタです。
取り込み経路として、ファイルを経由する Snowpipe 方式と、行単位・低レイテンシの Snowpipe Streaming 方式(3-3)を選べます。ストリーミングデータの取り込みでは後者との組み合わせが低レイテンシです。

✅ この節のまとめ

アンロードは COPY INTO @stage FROM テーブル(またはクエリ)。既定は gzip 圧縮 CSV で複数ファイルに分割(SINGLE = FALSE)。MAX_FILE_SIZE・PARTITION BY・HEADER = TRUE で出力を制御し、Parquet などへの出力も可能。内部ステージからは GET でローカルへ。
storage integration=IAM ロールなどに認証を委任し、資格情報を SQL に書かずに外部ステージへアクセスする推奨手段。複数ステージで再利用できる。
integration の対応付け:API=外部関数、notification=通知、catalog=Iceberg、Git repository=Git リポジトリ接続。
外部からの接続は ODBC / JDBC・各言語コネクタ・Snowpark・SnowSQL。Kafka Connector は Snowpipe または Snowpipe Streaming と組み合わせて継続取り込みを行う。

練習問題

問1. COPY INTO @stage FROM table をオプション指定なしで実行した場合の既定動作として正しいものはどれか(2つ選べ)。

出力ファイルは gzip で圧縮された CSV になる
出力は必ず1つのファイルにまとめられる
並列処理により複数のファイルに分割して出力される
先頭行に列名のヘッダーが自動的に出力される

解答と解説を見る

正解:A・C

アンロードの既定は gzip 圧縮 CSV で、SINGLE = FALSE のため複数ファイルへの分割出力になります。Bは SINGLE = TRUE を明示した場合の動作です。Dも誤りで、ヘッダー出力は HEADER = TRUE を指定した場合のみです。

問2. 外部ステージを作成する際に storage integration を使う主な利点はどれか。

アンロードするファイルのサイズが自動的に最適化される
クラウドストレージのアクセスキーやシークレットを SQL 文に書かずに済む
内部ステージへの PUT が Snowsight から実行できるようになる
ロードメタデータの保持期間が64日から無期限に延長される

解答と解説を見る

正解:B

storage integration は IAM ロールなどクラウド側の認証の仕組みに委任するオブジェクトで、シークレットを SQL 文やステージ定義に書かずに外部ステージへアクセスできるのが最大の利点です。Aのファイルサイズ最適化は MAX_FILE_SIZE などで行うもので、integration の機能ではありません。Cの PUT の制約は integration とは無関係に変わりません。Dのようなメタデータ保持期間の変更もできません。

問3. integration オブジェクトと役割の組み合わせとして誤っているものはどれか。

API integration — 外部関数からリモートサービスを呼び出すための接続を定義する
notification integration — クラウドの通知サービスとイベント通知を送受信する
catalog integration — 外部の Iceberg カタログに接続する
Git repository integration — Git リポジトリのコードを実行する専用の仮想ウェアハウスを作成する

解答と解説を見る

正解:D

Git repository integration は Git リポジトリを Snowflake に接続し、リポジトリ内のファイルをステージのように参照できるようにするオブジェクトであり、専用ウェアハウスを作る機能ではありません。したがってDが誤りです。A・B・Cはいずれも正しい対応付けで、この「integration 名 → 接続相手」のマッチングは整理して覚えておきましょう。

問4. Kafka トピックのメッセージを、できるだけ低いレイテンシで Snowflake のテーブルへ継続的に取り込みたい。最も適切な構成はどれか。

Kafka Connector を Snowpipe Streaming と組み合わせて行単位で取り込む
メッセージを日次で CSV にまとめ、翌朝 COPY INTO でバルクロードする
メッセージを1件ずつ手動で INSERT 文にして実行する
GET コマンドで Kafka から直接ファイルを取得する

解答と解説を見る

正解:A

Kafka Connector と Snowpipe Streaming の組み合わせは、ファイルを経由せず行単位・秒レベルのレイテンシで取り込める、この要件に最適な構成です。Bはバッチ処理であり、レイテンシが1日単位になってしまいます。Cは手動運用で継続的な取り込みに耐えません。Dは誤りで、GET は内部ステージからローカルへのダウンロードコマンドであり、Kafka との接続には使えません。