最近、Snowflake公式の「昼休みに学ぶ」Snowflake入門シリーズのオンラインセミナー（2026年5月20日版）を受講する機会があり、せっかくなので自分の理解をノートとして整理することにしました。入門とはいいながら要点がまとまっている講義かつ資料です。要点だからこそ「行間を埋めながら読まないと理解できない部分があるな」と感じる場面が結構あって…😅 そこで、その行間を補いつつ、自分が詰まった用語を整理するノートにしています。

自分はIoTやアプリケーション寄りで仕事をしてきたので、RDBは触れてもDWHやデータレイクの違いを聞かれると「は？」というレベル感です🙄

⚠️ 本記事の情報は2026年5月時点のものです。最新情報はSnowflake公式ドキュメントも併せて確認してみてください。

【関連】

uepon.hatenadiary.com

1. 用語の壁を最初に整理する
2. なぜAI活用には「データ」が要るのか
3. データ活用を阻む3つの壁
4. データ活用の3つの指針　→　Easy / Connect / Trust
5. Snowflake AI Data Cloudの全体像
6. まとめ
おわりに
付録:用語集

1. 用語の壁を最初に整理する

データウェアハウスやAIデータ基盤の話には、初見だと謎用語が結構出てきます。まずそこを整理しておかないと、後ろの章で迷子になりやすいので、まずはこの部分の調査から開始です。

1.1 データベースって、Excelと何が違うんでしたっけ

データベース（DB）は「あとから検索・集計・更新しやすい形で保存しておく仕組み」のことです。雑に言うとExcelに近いんですが、いくつか決定的な違いがあります。

大勢が同時に読み書きしても壊れない
検索や集計を高速にするための仕組み（インデックスなど）を持つ
誰がどこまで見ていいかを制御できる
途中で電源が落ちても整合性が壊れない（絶対に壊れないとは限らないけど）

これらを実現しているソフトウェアを DBMS（Database Management System）と呼びます。Oracle、PostgreSQL、MySQL、SQL Serverあたりが代表選手なんですよね。自分は個人開発がほぼ100％なのでデータ自体が少ないため設定ファイルを使用することの方が多く、もしDBを使用するとしてもSQLiteのような軽量DBをローカルで動かすくらいです。

1.2 RDBの基本（SQLの最小セット）

そんな中で、一番普及しているのが RDB（リレーショナルDB） で、データを「行と列の表」で扱うものです。複数の表を JOIN（結合） することで意味をつけてデータを取り出すのが特徴です。

ごく簡単な例で見てみます。

usersテーブル

user_id	name	dept_id
1	田中	10
2	佐藤	20

departmentsテーブル

dept_id	dept_name
10	営業
20	開発

この2つを dept_id で結合すれば「田中さんは営業」「佐藤さんは開発」と分かる、という仕組みですね。SQLで書くとこんな感じになります。

SELECT u.name, d.dept_name
FROM users u
JOIN departments d ON u.dept_id = d.dept_id;

Snowflakeも基本はSQLで操作するので、SELECT FROM WHERE JOIN GROUP BY の基本構文に慣れておくと、後の章でつまづきにくくなると思います。

1.3 構造化・半構造化・非構造化データ

SnowflakeはAIの機能も統合しているので、扱うデータの種類も多様です。AI時代に入ると、従来の構造化データだけでなく、半構造化データや非構造化データも扱える基盤が重要になってきます。このあたりの用語も最初に整理しておきましょう。

種類	特徴	代表例
構造化データ	列と型があらかじめ決まっている	RDBのテーブル、CSV、Excel
半構造化データ	表ではないが、タグやキーで意味づけされている	JSON、XML、Avro、Parquet、ORC
非構造化データ	形式が決まっていない、機械が中身を理解しにくい	画像、音声、動画、自由記述、PDF

従来のRDBは構造化データに強い反面、AI活用で重要になってくるのは画像・音声・文書を扱える基盤となっています。しかし、Snowflakeでは「（半構造化データや非構造化データを含む）すべてのデータタイプをサポート」と何度も強調していました。

ちなみに半構造化データの肌感としては、こんな感じです。

{
  "id": 101,
  "name": "クマ 太郎",
  "hobbies": ["スキー", "スノボ", "データ分析"],
  "address": { "city": "東京都中央区" }
}

RDBのように事前設計で列を先に決めなくてもよく、あとから項目が増えても入る、という柔軟性があります。Snowflakeでは VARIANT型 という特殊な型でこういうデータを受け取り、SQLから obj:address.city のようにアクセスできるようです。「とりあえず全部入れて、構造はあとで考える」という運用ができるのは心強いかもしれません（どれくらい役に立つかはケースバイケース🙄）。

1.4 OLTPとOLAP

データベースには大きく2つの流派があるようです。その2つとはOLTP（Online Transaction Processing）とOLAP（Online Analytical Processing）です。

	OLTP（Online Transaction Processing）	OLAP（Online Analytical Processing）
用途	業務処理（受注、決済、予約）	分析・レポート・BI
1回の処理	小さく速く（1件の更新）	大きく重い（数百万行を集計）
最適化方向	行単位でのアクセス	列単位でのアクセス
データ量	直近の業務データ	過去数年分の履歴
代表的なDB	MySQL, PostgreSQL, Oracle	Snowflake, BigQuery, Redshift

自分のイメージとしては以下のような感じでしょうか。

OLTP = コンビニのレジ（1件を確実に素早く）
OLAP = 月次の売上集計（大量を一気に集計）

Snowflakeはもともと OLAP側の代表選手なんですが、最近はOLTP寄りの機能も統合する方向に拡張しているそうです。

1.5 DWH / データレイク / レイクハウス

自分があまり馴染みのない用語だったのがこのあたりでした。データを保存して分析するための基盤の種類を表す用語で、以下のような違いがあります。

データウェアハウス（DWH） … 構造化データを整えて、分析しやすく溜めておく場所。SQLで集計するのに向いている
データレイク … 構造を問わず、生データ（CSV、JSON、画像、ログなど）をそのまま放り込める巨大な貯水池。Amazon S3やAzure Blob Storageの上に作ることが多い
レイクハウス … DWHとデータレイクの「いいとこ取り」。何でも入る上に、SQLで速く分析もできる

Snowflakeはもともと DWHとして始まり、現在はレイク・レイクハウス・AIまで包含する AI Data Cloud に進化した、という流れだそうです。

1.6 ETLとELT、それからメダリオン・アーキテクチャ

データを「使える状態にする」プロセスを データパイプライン と呼ぶようです。こちらも、よく出てくる2つの流派があります。

ETL … Extract → Transform → Load。外で変換してからDWHに入れる古典的なやり方
ELT … Extract → Load → Transform。先にDWHに放り込んで、中で変換する。クラウドDWHの計算力を活かす現代的なやり方

そして BRONZE / SILVER / GOLD という呼び方が出てきます。これはELTを段階で表したもので、メダリオン・アーキテクチャと呼ばれているそうです。

層	状態	例えるなら
BRONZE	生データそのまま	倉庫に届いた段ボール箱
SILVER	クレンジング・正規化済み	開梱して棚に並べた状態
GOLD	分析・AI用に整えた最終形	お客様に出せる商品

「AI READY GOLD」という言葉があり、AIにそのまま渡せるくらい整った最終層 のことを指すそうです。

1.7 セマンティックモデル

セマンティックモデルとは、表の 意味（セマンティクス） を機械が読める形で書いたマップのことです。

たとえば、

「sales_amt という列は 売上金額 を表す（単位:円、税抜）」
「product_cd は 製品マスタ の id と結合できる」

といったメタ情報を定義しておくと、AIに「7月の製品Aの売上を教えて」と聞いたときに、どのテーブルのどの列をSQLで参照すればよいかを正しく判断できるようになるっていうわけです。ちょっと便利そうですよね。

自分は知識グラフを触ったことがあるので、そのジャンルのオントロジーに近い概念のように感じました。

1.8 データガバナンスとRBAC

データ統合を進めるうえで避けて通れないのが、アクセスコントロールです。割と細かく制御できるようになっているのがSnowflakeの特徴の一つで、以下のような仕組みがあります。

RBAC（Role-Based Access Control） … ロールごとに「見ていいデータ」を決める仕組み。「営業ロールは顧客名は見えるが電話番号はマスク」のように設定できる
行レベル/列レベルポリシー … 同じ表でも、見せる範囲をきめ細かく制御できる
マスキング/匿名化 … 本人が特定できないように加工して提供する

1.9 ここまでで詰まりやすかった用語まとめ

第1章をまとめて振り返ると、自分が最初に詰まりやすかったのは以下のあたりでした。整理用に表にしておきます。

ハマりやすい用語	よくある誤解	こう捉えると楽
半構造化データ	RDBに入れられない厄介者	JSONのまま放り込んで、あとで取り出せるもの
OLAP（Online Analytical Processing）	専用の難しい技術	「大量集計向きに最適化したDB」くらいの理解でOK
データレイク	DWHの上位互換	構造を問わず生で入れる場所。整形は別
レイクハウス	単なるバズワード	DWHとレイクの統合。両方の長所が一つの基盤に乗る
ELT（Extract → Load → Transform）	ETLの誤字	順序が違う。「先に入れて中で変換」が肝
BRONZE/SILVER/GOLD	何かのランク付け	加工の段階。色が濃い順ではなく、加工が進む順
セマンティックモデル	スキーマと同じかな？	スキーマの上に被せる「意味の地図」

ここまでが前提知識でした。これで本編に入る準備ができたと思います。

2. なぜAI活用には「データ」が要るのか

2.1 同じグラフでも、文脈が違えば意味が変わる

たとえば、あるグラフがあって、横軸が「Week1〜Week4」、縦軸の値がところどころ大きく増減している。これだけを見ても、状況がよくわかりません。「Webサイトのアクセス数の落ち込み」かもしれないし、「機械の異常発生回数」かもしれないんですよね。

この状態に「これは自分の週ごとの走行距離（km）です」というラベルが付くと、急に意味が立ち上がります。さらに「同じ期間の天気データ」を重ねると、「雨だったから走らなかったんですね」と推論だって可能。そこに体重・心拍・睡眠などの周辺データが加われば、AIは「雨でもできる運動メニュー」を提案できるようになる、というわけです。

こういったDBの世界では、AIの有用性は与えられる周辺データの豊富さと文脈の精度に比例する、ということのようです。これは生成AIを業務でどう使うか考えるときにも大きな影響があるかなと感じます。

2.2 PoCは作れる、でも本番には出ない

オンラインセミナーでも語られていたのですが、企業のAI PoC（Proof of Concept）のうち 88%が本番に至らない という調査結果が報告されているそうです（CIO.com、2025年）。原因として挙げられているのは次のようなものでした。

データシステムがAI活用に耐える状態になっていない（Forbes:85%）
データガバナンスの問題（Salesforce:62%）
生成AI用のデータ統合の難しさ（Snowflake調査:64%）

この3つに共通するのは モデルの問題ではなくデータの問題で詰む ということです。確かに個人的にも心当たりがあって、PoCで盛り上がっても「で、本番のデータどうするの？どうつなぐの？」で止まる、というのは結構あるあるだなと思いました😅

2.3 データ戦略なくしてAI戦略なし？

「ChatGPTを入れる」「Copilotを入れる」だけでは社内AI活用は進まないことが如実にあらわれているのかもしれません。さらに価値を出すには、社内のビジネスデータ（売上、在庫、顧客、契約、ドキュメント、ログなど）をAIが見られて理解できる状態にしておく必要もあります。

逆に言えば、データ基盤が整った企業の 96%がAIを本番活用している というSnowflake独自調査もあるそうです。

3. データ活用を阻む3つの壁

3.1 サイロ化されたデータ

多くの企業でよくある状況が以下のようなものでしょうか。

営業データはSalesforce
経理はSAP
ログはS3
文書はSharePointやGoogle Drive
個人のExcelファイルもどこかに山ほどある

これらが互いにつながっていない状態を サイロ化 と呼ぶそうです。なんとなくは聞いたことがありますが、サイロ（穀物倉）が横方向の窓を持たない構造をしていることに由来しているようです。

3.2 複雑な管理

サイロ化を解消しようと各システム間にパイプライン（ETL）を作り始めると、今度は管理対象の数が爆発します。

どのスケジュールでどのデータを動かしているか
障害時にどこから直すか
負荷増減のスケーリングを誰が見るか

オンプレ時代にもこのような話はよくあったので、経験的にこのつらさは分かります😅

3.3 セキュリティとガバナンスの懸念

さらにデータを統合すればするほど、

誰が見ていいかのルールが複雑化
リージョン（国・地域）をまたぐデータ保護
個人情報の扱い

といった課題も増えていきます。便利になるほど守るべきものも増えるということです。

4. データ活用の3つの指針　→　Easy / Connect / Trust

先程の3つに対する答えとして、Snowflakeは次の3つの指針を提示しています。

指針	対応する壁	一言で
Easy（簡単）	複雑な管理	エンジニアもビジネスユーザーも同じデータに触れられる
Connect（接続）	サイロ化されたデータ	あらゆるデータソースを取り込み、外部とも共有できる
Trust（信頼）	セキュリティ・ガバナンス	統一されたガバナンスで安心して使える

頭文字の ECT で覚えておくと、後で何の話だっけ、となりにくいと思います。

5. Snowflake AI Data Cloudの全体像

5.1 全体像を見る

Snowflake AI Data Cloudのデータの流れだけ抜き出すとこんな感じです。

[データソース] → [取り込み Openflow] → [処理 BRONZE/SILVER/GOLD] → [AIサービス群] → [活用 Intelligence]

各層の役割を整理すると、

層	役割	主なキーワード
データソース	社内外のあらゆる発生源	SaaS、ERP、DB、Streaming、文書
データ取り込み	Snowflakeに運ぶ	Openflow
処理	段階的に整える	BRONZE/SILVER/GOLD、Cortex AI関数、AI SQL
データプロダクト	整った構造化・非構造化データ/セマンティックモデル	GOLD層の出力物
AIサービス群	データを賢く扱う	Cortex Search / Cortex Analyst
データ活用	エンドユーザーが自然言語で対話	Snowflake Intelligence

5.2 誰でも触れる

Streamlit in Snowflake

Pythonで小さなWebアプリを書けるフレームワークとして有名なのがStreamlitです。自分もStreamlitを使ったことがあるんですが、実はこのStreamlitがSnowflakeの中に同居しています。外部にデータを取りに行かずに、その場で可視化アプリが作れるのが大きな特徴です🤗

import streamlit as st

df = session.table("SALES").to_pandas()
st.line_chart(df)

これだけでSnowflakeのテーブルを折れ線グラフ化したWebアプリができてしまいます。FastAPIでフロントを組むよりも、ずいぶん早く立ち上がるイメージです。

Snowflake Intelligence

ビジネスユーザー向けの自然言語インタフェースです。「7月の売上が落ちた理由は？」と日本語で聞くと、

Cortex Analyst がSQLを組み立てて構造化データを分析
Cortex Search が関連する文書も探す
ガバナンスを守った範囲で回答する

という流れで動きます。社内データに対するChatGPT的な体験、というのが一番近い表現だと思います。

Cortex Code

エンジニア向けのターミナルベースAIアシスタントで、SnowflakeのSQL・データに最適化されているそうです。立ち位置としてはClaude Codeに近い印象を受けました。

5.3 どこからでも取り込み、誰とでも共有

Openflow

100以上のコネクタを持つデータ取り込み基盤です。SaaS（Salesforce、Workday、HubSpotなど）、DB（MySQL、PostgreSQL、Oracleなど）、ストリーミング（Kafka、Kinesisなど）、文書（SharePoint、Google Drive、Box）まで網羅されています。

ベースが Apache NiFi だそうで、NiFiを触ったことがある人なら一気に親近感が湧くポイントだと思います。

Snowflake Marketplace

ここはSnowflakeのユニークな部分なんですよね。3,700種類以上のデータセット、880社以上のプロバイダーが、ETL不要・コピー不要 でライブ参照できる形で提供されています。

たとえば「天気データ」「経済指標」「人口統計」を、自社データに直接JOINして即分析できる、というイメージです。「毎月CSVを送ってもらって取り込む」という運用が要らなくなる、と考えると体験の差は結構大きそうです。

5.4 安心して使える

Snowflake Horizon

データガバナンスの統合機能群です。第1章で整理した要素がここに集約されています。

多層 RBAC … データ・エージェント・特徴量/モデルの3層で権限を分離
列レベル/行レベルポリシー … 同じ表でも見せる範囲を制御
タグ付け/分類 … 機密度ラベルを自動付与
マスキング/匿名化 … 個人情報を自動でぼかす
アクセス履歴/オブジェクト依存関係 … 監査と影響範囲の分析

LLMをSnowflake内で完結

これは結構大きい話だなと思いました。OpenAI、Anthropic、Gemini、Meta、Mistralといった主要モデルが、Snowflakeアカウント内で動作する そうです。データを外部APIに送らないので、機密データを扱う日本企業でも採用しやすい設計になっているんですね。

5.5 すべてのデータタイプをサポート

第1章で整理した3種類（構造化/半構造化/非構造化）が、同じプラットフォームの中で同じSQLで扱える というのが、Snowflakeの設計思想の特徴です。半構造化データのためのVARIANT型、非構造化データのためのファイル参照型などが用意されていて、入口で型に困らないのはいい思想だなと感じます。

6. まとめ

これまでの内容をまとめると以下のようになるでしょうか。

AIをビジネスで使うには、AIそのものよりも データ基盤 が要になる
データ基盤を阻む3つの壁は サイロ化・複雑な管理・ガバナンス
解の方向性は Easy / Connect / Trust の3つ
Snowflake AI Data Cloudは、データ取り込みからAIによる自然言語対話までを一つの基盤で扱える設計になっている

おわりに

Snowflake公式の入門資料を眺めながら、自分の理解の足りない部分を一通り埋めてみた回でした。学び始めた当初は「DWHとデータレイクの違い、聞かれたら…😅」というレベル感だったんですが、用語をひとつずつ言語化することで、Snowflake AI Data Cloud全体の地図がだいぶ見えるようになった気がします。

付録:用語集

用語	説明
AI Data Cloud	データとAIを統合したSnowflakeの単一プラットフォーム概念
BRONZE / SILVER / GOLD	データを段階的に整える層（メダリオン・アーキテクチャ）
Cortex Analyst	自然言語の質問をSQLに変換して構造化データを分析するサービス
Cortex Search	あらゆるデータ・文書から意図を汲んで検索するサービス
Cortex AI関数	SQLから直接呼べるAI処理関数群（要約、翻訳、分類など）
DWH	データウェアハウス。分析特化のデータ蓄積基盤
ELT	Extract → Load → Transform。クラウドDWH時代の主流
ETL	Extract → Transform → Load。古典的なデータパイプライン
Openflow	Apache NiFiベースのデータ取り込みサービス
OLAP	分析処理向けのDB設計思想
OLTP	業務トランザクション向けのDB設計思想
RBAC	ロールベースのアクセス制御
RDB	リレーショナルデータベース
Snowflake Horizon	データガバナンスの統合機能群
Snowflake Intelligence	自然言語でデータと対話するAIエージェントUI
Snowflake Marketplace	3rdパーティデータを即時利用できるエコシステム
Streamlit	Pythonで書ける軽量Webアプリフレームワーク
VARIANT型	Snowflakeで半構造化データ（JSON等）を格納する型
構造化データ	表形式で型が決まったデータ
半構造化データ	JSON / XMLなどタグ付きで柔軟なデータ
非構造化データ	画像・音声・動画・自由記述テキストなど
サイロ化	データが部門・システムごとに孤立した状態
セマンティックモデル	テーブルの意味を機械可読に定義したメタデータ層

uepon日々の備忘録

日々メモ

「データウェアハウスの知識が弱い自分」がSnowflake入門シリーズのオンラインセミナーを見て、DBとAIの基礎に格闘してみた

1. 用語の壁を最初に整理する

1.1 データベースって、Excelと何が違うんでしたっけ

1.2 RDBの基本（SQLの最小セット）

1.3 構造化・半構造化・非構造化データ

1.4 OLTPとOLAP

1.5 DWH / データレイク / レイクハウス

1.6 ETLとELT、それからメダリオン・アーキテクチャ

1.7 セマンティックモデル

1.8 データガバナンスとRBAC

1.9 ここまでで詰まりやすかった用語まとめ

2. なぜAI活用には「データ」が要るのか

2.1 同じグラフでも、文脈が違えば意味が変わる

2.2 PoCは作れる、でも本番には出ない

2.3 データ戦略なくしてAI戦略なし？

3. データ活用を阻む3つの壁

3.1 サイロ化されたデータ

3.2 複雑な管理

3.3 セキュリティとガバナンスの懸念

4. データ活用の3つの指針　→　Easy / Connect / Trust

5. Snowflake AI Data Cloudの全体像

5.1 全体像を見る

5.2 誰でも触れる

Streamlit in Snowflake

Snowflake Intelligence

Cortex Code

5.3 どこからでも取り込み、誰とでも共有

Openflow

Snowflake Marketplace

5.4 安心して使える

Snowflake Horizon

LLMをSnowflake内で完結

5.5 すべてのデータタイプをサポート

6. まとめ

おわりに

付録:用語集

1. 用語の壁を最初に整理する

1.1 データベースって、Excelと何が違うんでしたっけ

1.2 RDBの基本（SQLの最小セット）

1.3 構造化・半構造化・非構造化データ

1.4 OLTPとOLAP

1.5 DWH / データレイク / レイクハウス

1.6 ETLとELT、それからメダリオン・アーキテクチャ

1.7 セマンティックモデル

1.8 データガバナンスとRBAC

1.9 ここまでで詰まりやすかった用語まとめ

2. なぜAI活用には「データ」が要るのか

2.1 同じグラフでも、文脈が違えば意味が変わる

2.2 PoCは作れる、でも本番には出ない

2.3 データ戦略なくしてAI戦略なし？

3. データ活用を阻む3つの壁

3.1 サイロ化されたデータ

3.2 複雑な管理

3.3 セキュリティとガバナンスの懸念

4. データ活用の3つの指針 → Easy / Connect / Trust

5. Snowflake AI Data Cloudの全体像

5.1 全体像を見る

5.2 誰でも触れる

Streamlit in Snowflake

Snowflake Intelligence

Cortex Code

5.3 どこからでも取り込み、誰とでも共有

Openflow

Snowflake Marketplace

5.4 安心して使える

Snowflake Horizon

LLMをSnowflake内で完結

5.5 すべてのデータタイプをサポート

6. まとめ

おわりに

付録:用語集

4. データ活用の3つの指針　→　Easy / Connect / Trust