Snowflakeとは？数字でなく設計から読む導入判断ガイド

Snowflakeとは？（30秒で理解）
Snowflake（スノーフレーク）は、データ分析、データエンジニアリング、AI、アプリ共有を同じ基盤に寄せようとしているmanaged data platformです。理解の起点は四半期ごとの会社指標ではなく、ストレージとコンピュートを分離した設計と、Analytics / Data Engineering / AI / Applications & Collaborationという4つの製品カテゴリーに置くべきです。

Snowflakeの公式サイトを2つ開くと、顧客数がずれます。company overview pageでは「12,062 global customers」、2026年2月25日公開のQ4 FY26 investor presentationでは「13,328 customers」。同じ会社の、近い時期の数字のはずなのに、参照するページによって1,000社以上の差が出ます。

これは矛盾ではありません。集計の基準日と定義が、ページごとに違うだけです。ただしこの事実は、Snowflakeという会社をどう読むべきかについて、はっきりした示唆を持っています。Snowflakeを導入判断の対象として読むとき、どこまでが設計として変わらない部分で、どこからが日付つきでしか意味を持たない数字なのか。この読み分けを先にしないと、ウェアハウス、semantic model、AI予算のどこで費用と品質が崩れるかを見誤ります。

私は、Snowflakeの導入判断を会社の成長物語や創業史から始める読み方を信用していません。判断に効くのは、ストレージとコンピュートを分離したという設計上の不変量と、semantic model・ロール・予算のオーナーを自社側に置けるかどうかだけです。このオーナーを置けない組織は、CortexやSnowflake IntelligenceのようなAI機能にまだ手を出すべきではないと考えています。

ただしこれは、SQL中心の分析基盤を選ぶ場面に限った話です。MLエンジニアリング起点の基盤選定は、別の一次変数で判断が変わります（後述のDatabricksとの見分け方で扱います）。

この立場は、Databricksとの選定を扱った以前の記事の議論をそのまま延長したものです。そこでは、DatabricksとSnowflakeの併用が壊れる典型パターンは、正本データを二重に持ってしまい、責任分界を決めずに両方を導入した結果として起きる構成上の必然だと整理しました。同じ構造は、基盤の外側にあるAI機能でも起きると私は見ています。semantic modelやロールのオーナーが決まらないまま、CortexのようなAI機能の名前だけが先に決まると、責任分界が空席のまま導入が進み、正本データの二重化と同じ型の事故が、今度はsemantic modelや権限設計の側で起きるとみています。

以下では、「設計の不変量」と「日付つきの数字」という区別を軸に、Snowflakeの製品構成、AI機能、導入前に詰めるべき論点を整理します。

前提：2つの区別で読む

設計の不変量と日付つきの数字

Snowflakeを読むときに起きる典型的な事故は、四半期の数字と設計上の事実を同じ重みで扱ってしまうことです。この記事では次の2つを分けます。

設計の不変量：ストレージとコンピュートを分離しているという設計、共有されたデータ面の上にAI・アプリ層を積む構造など、四半期が変わっても崩れない設計上の事実
日付つきの数字：顧客数、売上、株価、時価総額のように、公開された日付と紐づけて初めて意味を持つ数値。同じ会社でも、参照するページや四半期が変われば数字は変わる

冒頭の顧客数のずれ（12,062と13,328）は、後者の典型例です。この区別を持たずに読むと、「今のSnowflakeは○○社の顧客を持つ大企業だ」という理解自体が、数ヶ月後には古くなります。

builder面と利用者面

SnowflakeのAI機能を評価するときも、同じ理由で読み違いが起きます。ここでも2つを分けます。

builder面：Cortex Analyst、Cortex Search、Cortex Agents、AI Functions、Cortex Codeなど、エンジニアやアナリストが組み合わせて使う部品群
利用者面：Snowflake Intelligenceのように、業務ユーザーがそのまま使う完成品のエージェント

導入前に確認すべき点（semantic model、ロール設計、予算）が、どちらの面に効くのかを判定する道具として、以降この2つの用語だけを使います。

設計の不変量：ストレージとコンピュートの分離

2012年以前のオンプレミス型data warehouseには、明確な限界がありました。データ量が増えるたびにハードウェアを買い足す必要があり、夜間や週末に誰も使わなくてもサーバーは稼働し続け、部門間のデータ共有はIT部門への依頼が毎回必要でした。

Snowflakeの共同創業者であるBenoit DagevilleとThierry Cruanesは、Oracleで17年間、Query OptimizerとDatabase Engineの開発に携わった技術者でした。2人は2012年にOracleを離れ、サンマテオのアパートで数ヶ月間、ホワイトボードを使って設計を練り直します。

"From our experience at Oracle, we knew the limitations of existing Data Warehouses inside and out. By redesigning from scratch for the new cloud infrastructure, we were convinced that entirely new possibilities would open up."

「Oracleでの経験から、既存のData Warehouseの限界を知り尽くしていました。クラウドという新しいインフラに合わせてゼロから設計し直すことで、まったく新しい可能性が開けると確信していました」

— Benoit Dageville, 共同創業者

同年、Sutter Hill VenturesのMike Speiserがこの構想を後押しし、自らインキュベート役として創業初期のCEOを務めました。3人目の共同創業者Marcin Zukowski（Vectorwiseの共同創業者）が、自身の研究であるベクトル化実行と軽量圧縮の技術を持って合流したのは、同年10月のことです。

彼らが持ち込んだ設計上の決定が、ストレージとコンピュートの分離です。

┌─────────────────────────────────────────────┐
│              Snowflake Architecture          │
├─────────────────────────────────────────────┤
│  ┌─────────────────────────────────────┐    │
│  │     Cloud Services Layer            │    │
│  │  (認証、最適化、メタデータ、セキュリティ)  │    │
│  └─────────────────────────────────────┘    │
│  ┌─────────────────────────────────────┐    │
│  │     Virtual Warehouse (Compute)     │    │
│  │  (独立してスケール可能)               │    │
│  └─────────────────────────────────────┘    │
│  ┌─────────────────────────────────────┐    │
│  │     Storage Layer                   │    │
│  │  (AWS S3 / Azure Blob / GCS)        │    │
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

この分離がもたらした恩恵は3つです。コンピュートは秒単位で起動・停止できるため、使わない時間は課金されません。ストレージはクラウドの限界まで拡張できます。そして、同じデータに複数のチームが同時にアクセスできます。

これが、2012年の設計判断が2026年の今も崩れていない理由です。四半期ごとに変わる顧客数や売上と違い、この設計は当時読んでも今日読んでも同じ事実として成立します。

Snowflakeの全体像

この分離を土台に、Snowflakeは現在4つのカテゴリーへ製品を広げています。

全体像：4つのカテゴリー

カテゴリ	何を担うか
Analytics	Virtual Warehouses、SQL、BI、semantic modelを使った分析
Data Engineering	取り込み・変換・オーケストレーション、Snowpark、オープンなテーブル形式
AI	Cortex familyとSnowflake Intelligenceによる自然言語分析・検索・エージェント
Applications & Collaboration	Native Apps、Streamlit、Marketplace、clean rooms、データ共有

個別の論点に入る前に、まずこの一覧で全体の輪郭を掴んでおきます。

AI機能の読み分け：builder面と利用者面

2024年2月28日、CEOがFrank SlootmanからSridhar Ramaswamyに交代しました。この交代の是非より重要なのは、この前後でSnowflakeがAIを独立したカテゴリーとして扱い、builder面と利用者面をはっきり分けて出すようになったことだと私は見ています。

Snowflakeアーキテクチャ

builder面：Cortex family

公式ドキュメントと製品ページを基準にすると、Cortex familyは次のように整理できます。

面	何をするか	導入前の確認点
Cortex Analyst	semantic modelを前提に構造化データへ自然言語で質問する	metricの定義、semantic model、ウェアハウス、ロール
Cortex Search	ドキュメントや非構造化データをgrounding用に検索する	インデックスの鮮度、アクセス制御、検索対象の粒度
Cortex Agents	Analyst / Search / カスタムツールを束ねてタスクを進める	ツールの権限、リソース予算、評価方法
AI Functions	SQLやAPIから分類・要約・抽出を呼ぶ	モデルの選択、プロンプトのバージョン管理、処理単価
Cortex Code	Snowsightやbuilderの作業フローの中でデータ・アプリ開発を支援する	アカウントのロール、リポジトリの境界、開発フロー
AI Observability	trace / eval / 品質モニタリングでAIアプリの挙動を測る	監視対象、評価基準、telemetryの保持方針

利用者面：Snowflake Intelligence

Snowflake Intelligenceは、ai.snowflake.comで動く、業務ユーザーがそのまま使える完成品のエージェントと位置づけると分かりやすいです。公式製品ページでは、自然言語での深い分析、根拠の引用、検証済みの回答、そして既存のガバナンスの内側で動く点が前面に出ています。

builderがAnalyst / Search / Agentsを組み合わせる世界と、業務ユーザーが完成品のエージェントを使う世界は別物です。ここを混同すると、期待値がずれます。

semantic modelと権限が品質を決める

Cortex AnalystもSnowflake Intelligenceも、自然言語の入り口はやさしく見えます。しかし公式ドキュメントを読む限り、Cortex Analystの回答精度はsemantic modelの設計に、Snowflake Intelligenceの安全性は既存のロール・マスキングポリシーの設計に、それぞれ直接依存します。つまりAI機能の品質を決めているのはモデルの性能ではなく、その手前にあるsemantic modelと権限設計のオーナーが自社にいるかどうかです。

変換ロジックとsemantic modelの運用そのものについては、別記事「dbt Labs徹底解説：SQLでデータ変換を運用する実務ガイド」で整理した変換レイヤー側の設計論点と地続きです。

実際に検証環境で触って確かめた話ではありませんが、公開されているCortex Analystの説明を読み解くと、この依存関係は仮定の話ではありません。たとえば「売上」という一語だけでも、semantic modelがgross revenueとnet revenueのどちらを指すか、どの期間を既定の集計単位にするかを定義していなければ、自然言語からSQLへの変換はそのつど推測に頼ることになります。同じ質問文を投げても、semantic model側の定義次第で返ってくる集計対象が変わってしまうのは、モデルの不具合ではなく、semantic modelが曖昧なまま運用すればCortex Analystの設計上避けられない挙動だと考えています。

Snowflake AI進化タイムライン

実務でAI機能を検討するときは、次の順で見るのが安全です。

構造化データだけで答えたい：Cortex Analyst
ドキュメントのgroundingも必要：Cortex Search
複数ツールをまたぐタスク：Cortex Agents
業務ユーザー向けのセルフサービス：Snowflake Intelligence
本番運用の評価と予算管理：AI Observabilityとリソース予算

導入前に詰めておく論点

料金は「コンピュート・ストレージ・転送・AI追加費用」の4つに分けて見る

Snowflakeの料金は、公式pricing pageが示す構造に沿うと、「クレジットを消費するコンピュート」「ストレージ」「データ転送」「機能ごとの追加課金」の4つに分けて見ると整理しやすくなります。単一の「Snowflakeは高い/安い」という議論より、どのワークロードがどの課金項目を押し上げるかを分離して見るほうが実務では重要です。

見積もり時に分けて考えるべき項目は次の4つです。

バッチ処理とインタラクティブ処理で別々に動くウェアハウスの稼働時間
サーバーレス機能やAI機能の追加消費
リージョンをまたぐデータ移動や共有の設計
retention、fail-safe、ガバナンスに伴うストレージの前提

この4項目は、finance側とplatform側のどちらか一方だけで決めると必ず漏れが出ます。事前にどちらが何を承認するかを決めておくべき論点です。

ウェアハウスの乱立を防ぐ

Snowflakeの良さは、同じストレージを共有しながらコンピュートを独立して増減できることです。裏返すと、部門ごとにウェアハウスを増やし続けると支出の所在がすぐ曖昧になります。

最低限、次の項目にはオーナーを置くべきです。

ウェアハウスサイズの標準：platform team
auto-suspendと稼働時間の方針：platform team
ドメインごとのコスト可視化：finance側と各ドメインの共同
AI機能用の独立予算：AI app owner

クロスリージョン/クロスクラウドは先に確認する

Snowflakeの強みは共有とクラウド横断性にありますが、AI推論やデータ転送の前提はリージョンとクラウドの組み合わせで変わります。設計初期に見るべき点は次の通りです。

構造化データだけで完結するか、ドキュメント検索も必要か
アカウントのリージョンを越える推論を許容するか
クラウドをまたぐ共有を主機能にするか
可搬性より運用の手間の少なさを優先するか

Databricksとの見分け方

比較の軸を記事ごとに立て直すより、シリーズ内で一貫させたほうが読者にとって使いやすいと考えています。ここで使う軸も、以前の記事でDatabricksとSnowflakeの選定に立てた一次変数をそのまま前提に置き、今回はそれをSnowflake単体の記事として、実務の確認点まで具体化する側に回しています。

以前の記事「Databricks vs Snowflake徹底比較｜データ分析基盤の選び方」では、DatabricksとSnowflakeの選定を機能比較ではなく、「提供面（serving surface）か処理面（processing surface）か」「正本データをどちらの責任で持つか」という一次変数で整理しました。この記事が足すのは、Snowflakeを選んだ場合に確認すべき点の解像度です。ウェアハウスのガバナンス、semantic model、共有、AI予算という4点は、その一次変数を実際の導入判断に落とし込んだときに必ず出てくる論点です。

Snowflakeが刺さりやすいのは、SQL中心のanalyticsとガバナンスの効いた共有を同じ基盤に寄せたいチーム、同じストレージを複数チームで共有しつつコンピュートを分離したいチーム、業務ユーザー向けの自然言語分析を企業の権限の内側で扱いたいチームです。逆に、notebook中心のML workflowやカスタムモデルの学習を起点に基盤を組みたい場合、クロスクラウドのデータ移動が主役で転送コストの制約が大きい場合、そしてsemantic modelと権限設計のオーナーを置けない場合は、Databricksを含めて比較したほうがよいと考えます。

競合比較

観点	Snowflake	Databricksを先に見るべき場面
中心思想	管理された共有データ面の上にanalytics / sharing / AIを積む	lakehouseとオープンなエコシステムを中心にengineering / MLを広げる
入口になりやすい人	アナリスト、BIチーム、data platform team	data engineer、ML platform team、notebook中心の開発者
AIの広げ方	Cortex Analyst / Search / AgentsとSnowflake Intelligenceを企業データに重ねる	カスタムワークフロー、学習、servingをengineering側から伸ばす
重要な確認点	ウェアハウスのガバナンス、semantic model、共有、AI予算	catalog、job / notebook運用、オープンなテーブル形式、serving運用

両者の境界は年々重なってきていますが、Snowflakeを検討する場面では「共有データ面を軸にどこまで寄せたいか」を判断軸に置くと、読み違いが減ります。関連する責務分解は「Databricksとは？データ/AI基盤の見方と導入論点を整理」でも扱っています。

日付つきの数字の読み方

ここまでの論点は、設計の不変量として今読んでも成立します。ここからは逆に、日付をつけて初めて意味を持つ数字を、そのように扱って読みます。

Q4 FY26 investor presentationのスナップショット（2026年2月25日公開）

指標	スナップショット
FY2026 product revenue	$4.472B（約6,708億円）
Q4 FY26 product revenue	$1.227B（約1,841億円、前年比+30%）
Remaining Performance Obligations	$9.772B（約1.47兆円）
Net Revenue Retention	125%
Total customers	13,328
$1M+ product revenue customers	733

※日本円換算は1ドル=150円で計算

一方、company overview pageでは「12,062 global customers」「3,400 marketplace listings」が前面に出ています。冒頭で触れた通り、この差は矛盾ではなく、定義と更新日がページごとに違うだけです。したがって、四半期ごとの経営指標は投資家向け資料で、製品の全体像は公式ドキュメントや製品ページで確認する、という読み分けが安全です。

Snowflakeの成長指標

同じ会社の数字が4年でどう振れたか

日付つきの数字がどれだけ動くかは、Snowflake自身の株式の歴史がよい実例です。2020年9月16日のIPOでは、公開価格$120に対して終値は$253.93（+112%）、初日時価総額は$70Bでした（TechCrunch）。Warren BuffettのBerkshire Hathawayは、このIPOで$250M相当を取得しています。Buffettにとって、Ford Motor Company以来のIPO投資であり、史上初のテックIPO投資でした（CNBC）。しかし2024年第2四半期までに、Berkshireはこの株式をすべて売却しています。

同じ会社の、同じ保有者による数字が、4年でここまで振れました。IPO初日の株価も、2024年の全売却も、どちらも「その日の事実」としては正しく、しかしどちらも今日のSnowflakeを説明する数字ではありません。

結び：役割別に、最初の1点を決める

ここまでの材料を、読者の役割別に並べ直します。まとめではなく、私がその役割ならまず何を確認するか、という判断です。

data platform ownerなら、私はまずワークロードをAnalytics / Data Engineering / AI / Applications & Collaborationの4つに棚卸しし、どこまでをSnowflakeという単一の共有データ面に寄せるかを決めます。全部を寄せる必要はありません。

analytics ownerなら、私はCortex AnalystやSnowflake Intelligenceを触る前に、semantic modelとロールの設計を先に固めます。ここのオーナーが決まっていない状態でAI機能を触り始めると、後から「なぜ回答がぶれるのか」を機能のせいにしてしまいます。

AI app ownerなら、私はウェアハウスのコスト、データ転送、agent / searchの予算を別々に見積もってからpilotを始めます。ひとつの予算に混ぜると、どのAI機能が実際に効いているのかが最後まで分からなくなります。

そしてどの役割であっても、最初に確認すべきなのは製品機能の一覧ではなく、semantic modelと権限設計のオーナーを自社の誰に置くか、だと私は考えています。ここが空席のままCortexやSnowflake Intelligenceを導入すると、AI機能そのものではなく、その手前の設計が壊れます。

参考リソース

Snowflake公式

報道

本記事はネクサフローのAI研究シリーズの一部です。

この記事の著者

中村知良

代表取締役

早稲田大学卒業後、ソフトバンク株式会社にてAI活用やCEO直下案件のプロジェクトマネージャーに従事。その後、不動産スタートアップPit in株式会社の創業、他スタートアップでの業務改善・データ活用を経験後、2023年10月、株式会社ネクサフローを創業し代表取締役CEO就任。

Snowflakeとは？（30秒で理解）
Snowflake（スノーフレーク）は、データ分析、データエンジニアリング、AI、アプリ共有を同じ基盤に寄せようとしているmanaged data platformです。理解の起点は四半期ごとの会社指標ではなく、ストレージとコンピュートを分離した設計と、Analytics / Data Engineering / AI / Applications & Collaborationという4つの製品カテゴリーに置くべきです。

以下では、「設計の不変量」と「日付つきの数字」という区別を軸に、Snowflakeの製品構成、AI機能、導入前に詰めるべき論点を整理します。