1.snowflakeとは近年、データ活用の高度化に伴い、クラウドDWHとしてSnowflakeを検討する企業が増えています。一方で、Snowflakeを導入すると、どのような構成になるのかPoC（検証）ではどこまで確認すべきなのか本番導入を見据えて、何を意識して設計すればよいのかといった点が不明確なまま、検証が止まってしまうケースも少なくありません。本記事では、Snowflakeの検証環境（PoC）として実際に構築した内容をもとに、アカウント設計・権限構成、AWS（Amazon S3）とのデータ連携、ETL処理、さらにStreamlitを用いた可視化までの一連の流れを整理して解説します。これからSnowflakeの導入を検討する方が、「PoCで何をどこまで確認すればよいのか」を具体的にイメージできることを目的としています。2.snowflakeの主な機能Snowflakeは、クラウドネイティブに設計されたデータプラットフォームです。AWS、Azure、Google Cloudといった主要なクラウドサービス上で利用でき、データの保存（ストレージ）と処理（コンピューティング）を分離して管理できる点が大きな特徴です。従来のオンプレミス型DWHや一部のクラウドDWHでは、性能向上のためにリソース全体を増強する必要がありました。一方でSnowflakeでは、用途に応じてコンピューティングリソースを柔軟に切り替えられるため、コストと性能のバランスを取りやすくなっています。データ基盤の刷新や分析基盤の構築を検討する際に、運用負荷を下げたい分析ニーズの変化に柔軟に対応したいクラウドの特性を最大限に活かしたいといった要件を持つ企業に選ばれるケースが増えています。3.snowflakeのメリットSnowflakeを利用する主なメリットとして、以下が挙げられます。インフラ管理が不要で、運用負荷を抑えられる利用した分だけ課金されるため、コスト管理がしやすい分析用途ごとにリソースを分離でき、性能劣化が起きにくいクラウドサービスやBIツールとの親和性が高い特にPoC段階では、環境構築に時間をかけすぎず、実際の操作感性能やコスト感運用イメージを短期間で確認できる点が大きなメリットとなります。4.Snowflake PoCの全体構成本PoCでは、Snowflakeの基礎設計からデータ連携、ETL、可視化までを一通り検証しています。本章では、今回実施した内容の全体像を整理します。① Snowflakeにおけるアカウントと権限構成まず、Snowflakeの基盤設計として以下を整理・検証しました。組織（Organization）とアカウントの関係アカウント識別子と接続方法アカウントのライフサイクル（作成・設定・削除）デフォルトロール（ORGADMIN / ACCOUNTADMIN / SECURITYADMIN など）の役割RBACに基づく権限設計PoC用業務ロール（DEVELOPER / ANALYST / PDM）の作成と継承関係管理コンソール上でのロール確認Snowflakeを安全かつ拡張性のある形で利用するためには、最初のアカウント・権限設計が重要となります。本PoCでは、将来的な本番利用を見据えた最小構成を意識しています。② 検証環境でのETL構成次に、外部データをSnowflakeへ取り込み、データ基盤として整形する流れを検証しました。検証用売上データの準備データベース／スキーマ命名設計DATALAKE / DATAWAREHOUSE / DATAMART の分離設計BigQueryとの概念対応整理Amazon S3との連携Storage Integrationの設定External Stageの作成Snowpipeによる自動取り込みDATALAKE → DATAWAREHOUSE への変換処理DATAWAREHOUSE → DATAMART への加工処理単なるデータロードではなく、「データ基盤としての役割分離」と「運用を見据えた構成」を確認することを目的としています。③ Snowflake内でのアプリケーション検証最後に、Snowflake上でのデータ活用を想定し、アプリケーションレイヤーまで検証しました。Streamlit環境の構築Snowflakeデータを参照するアプリケーション作成テストデータ（Titanic / NYC Taxi）を用いた可視化ダッシュボード形式での表示確認これにより、データの取り込みから加工、可視化までをSnowflake上で一気通貫に実行できることを確認しています。本PoCでは、「アカウント設計」→「データ基盤構築」→「アプリケーション活用」という流れで検証を実施しました。本記事では、上記の各工程について順に解説していきます。5.Snowflakeのアカウントと権限設計Snowflakeは「アカウント単位」で環境を管理する設計です。そのため、PoCにおいても最初にアカウント構造と権限モデルを整理しました。① Organizationとアカウント構造Snowflakeでは、複数アカウントを束ねるOrganizationという概念があります。組織全体はGLOBALORGADMINが管理し、各アカウントはAccount Identifier（例：<organization>-<account>）で識別されます。環境（開発／検証／本番）の分離も、このアカウント単位で行います。② 権限設計（RBAC）SnowflakeはRBAC（Role-Based Access Control）を採用しており、ユーザーではなくロールに権限を付与します。主な管理ロール：ORGADMINACCOUNTADMINSECURITYADMINUSERADMINSYSADMINPUBLICこれらは階層構造を持ち、上位ロールが下位ロールを継承できます。③ PoCで定義した業務ロールPoCでは、用途に応じて以下の業務ロールを定義しました。DEVELOPER：全テーブルの読み書きANALYST：主に参照用途PDM：参照専用継承関係：DEVELOPER > ANALYST > PDM④ 管理コンソール上での権限の確認管理者権限を持つユーザー(ACCOUNTADMIN) でログインした上でGovernance & security > Users & rolesページにアクセスするとアカウント内に構築されているロールが確認できます。Graphタブをクリックすると権限の構成が視覚的に確認可能で、継承の関係も確認できます。6.検証環境におけるETL構成検証環境で構築したETLはAmazon S3 にデータが置かれたことをイベントとし、Snowpipeを利用して、SnowflakeのDatalakeに取り込みその後、Snowflake内でETLがされ結果が DATAMART に保存されます。検証では、仮想的な売上データを使用しました。シンプルな構成とすることで、Snowflakeの基本的なデータフローやETL処理の確認に集中しています。① データベース・スキーマ設計Snowflakeでは、以下の階層構造でデータを管理します。データベーススキーマテーブル本PoCでは、DATALAKE、DATAWAREHOUSE、DATAMARTといった役割ごとにデータベースを分ける構成としました。これにより、生データ加工済みデータ分析・提供用データの責務が明確になります。② BigQueryとの対応関係BigQueryを利用した経験がある場合、Snowflakeの概念は以下のように対応付けて理解できます。Snowflake Database ⇔ BigQuery ProjectSnowflake Schema ⇔ BigQuery Datase7.AWS（S3）とSnowflakeの連携Amazon S3からSnowflakeにデータ連携するためには、Storage IntegrationとExternal Stageの設定が必要になります。Storage IntegrationStorage Integrationは、Snowflakeとクラウドストレージ間の認証・認可を安全に行うためのSnowflakeオブジェクトです。これを利用することで、AWSのアクセスキーやシークレットキーを直接管理することなく、Snowflake側に設定されたIAMロールを通じてS3へアクセスできます。本PoCでは、Snowflakeから許可されたAmazon S3バケットにアクセスできるIAMロールを設定し、そのロールをStorage Integrationとして定義しています。External StageExternal Stageは、S3上のファイルパスやファイルフォーマット情報をまとめて定義する「名前付き参照」です。Storage Integrationと組み合わせることで、COPY処理やSnowpipeの設定時にS3のパスや認証情報を都度記述する必要がなくなります。作成したExternal Stageは、管理コンソール上から確認できます。8.Snowflake内でのETL処理ここでは、取り込んだデータをどのように整理・加工したかを説明します。Snowpipe（自動取り込み機能）Snowpipeは、Amazon S3などのクラウドストレージにファイルが保存されたことをきっかけに、自動でSnowflakeへデータを取り込む仕組みです。手動でデータを読み込む方法（COPY INTO）とは異なり、ファイルが置かれるたびに自動で処理されます。本PoCでは、S3の指定フォルダにファイルが保存されると、RAW_SALESというテーブルにデータが登録される設定を行いました。この際、前章で設定したExternal Stageを利用しています。DATALAKE → DATAWAREHOUSEまず、取り込んだままのデータを保存する場所をDATALAKEといいます。そのデータをSQL（データを操作するための命令文）で加工し、整理したデータをDATAWAREHOUSEへ保存します。DATALAKEは「元データの保管場所」、DATAWAREHOUSEは「整理されたデータの保管場所」という役割です。DATAWAREHOUSE → DATAMARTさらに、分析しやすい形に集計・加工したデータをDATAMARTへ保存します。DATAMARTは、レポートやダッシュボードで利用することを想定したデータの保存場所です。このように、元データ → 整理されたデータ → 分析用データという順番で段階的にデータを整えています。9.Streamlitによる可視化検証ここでは、Snowflakeに保存されたデータをどのように画面で確認できるかを検証しました。StreamlitとはStreamlitは、Pythonを使って簡単に画面（Webアプリ）を作ることができる仕組みです。Snowflake上でも利用でき、データベースに保存されているデータをそのまま画面に表示できます。① アプリケーションの作成Snowsightの「Projects > Streamlit」からアプリケーションを作成できます。本PoCでは「CLOVE_SNOWFLAKE_POC」という名前で作成しました。② 検証で利用したデータ可視化の確認として、以下のデータを利用しました。Titanicデータ（Kaggleの生存予測データ）NYC Yellow Taxi（タクシーデータ）作成したアプリケーションでは、タブを切り替えたり、表示する項目を選択したりしながらデータを確認できるようにしています。Streamlitを利用することで、Snowflakeのコンピューティングと組み合わせてBIライクなアプリケーションを構築することが可能であることを確認しました。10.まとめ本PoCでは、Snowflakeの基礎設計からデータ連携、データ加工、可視化までを一通り検証しました。具体的には、Organizationおよびアカウント構造の整理RBACに基づく権限設計Amazon S3との連携設定（Storage Integration / External Stage）Snowpipeによる自動取り込みDATALAKE → DATAWAREHOUSE → DATAMART の段階的なデータ加工Streamlitによる可視化アプリケーションの構築という流れで環境を構築しています。これにより、Snowflake上で「データを取り込む」「整理する」「活用する」までの一連の工程を確認しました。本記事が、Snowflake導入を検討する際のPoC設計や検証範囲の参考になれば幸いです。CLOVE合同会社は、企業のデータ活用を推進するための戦略策定、データ基盤構築、データ分析、AI活用支援を提供するコンサルティング会社です。 データ活用の専門家として、マーケティング、営業、業務効率化など幅広い領域で支援を行っております。貴社の課題や目的に応じた最適な設計をご提案しますので、ご興味がありましたらぜひお問い合わせフォームからお気軽にご相談ください。