Snowflakeとは？データ基盤とAI機能の見方を整理

Snowflakeは、SQL 分析の company という理解だけでは読み切れません。

公式の platform page、docs、pricing、investor presentation を横断すると、Snowflake が広げているのは単なる data warehouse ではなく、共有されたデータ面の上に AI とアプリ層まで積む構造です。

本記事では、Snowflake の product surface と導入判断に効く論点を先に整理し、そのうえで創業史や quarter ごとの資料を dated snapshot として読み分けます。

この記事でわかること

1. Snowflakeの設計思想: ストレージとコンピュートの分離を、今の product map とどう結びつけて読むか
2. 主要カテゴリ: Analytics / Data Engineering / AI / Applications & Collaboration がそれぞれ何を担うか
3. 導入判断の論点: pricing、warehouse 設計、semantic model、resource budget をどう見るか
4. AI surface の読み分け: Cortex family と Snowflake Intelligence をどう使い分けるか
5. 歴史 section の扱い方: 創業史や quarterly metrics をどこまで固定的な事実として読めるか

基本情報

Snowflakeの全体像

Snowflakeとは？Data Cloudの全貌

従来のData Warehouseは「行き止まり」だった

2012年以前、企業のデータ分析には大きな壁がありました。

オンプレミスのData Warehouse（データウェアハウス：企業の統合データ保管庫）。この仕組みには、4つの致命的な課題がありました。

1. スケーラビリティの限界: データ量が増えたら、ハードウェアを買い足す必要がある
2. 固定コストの呪い: 夜間や週末、誰も使わない時間帯でもサーバーは稼働し続ける
3. データサイロ: 部門間でのデータ共有は、毎回IT部門への依頼が必要
4. バッチ処理の遅さ: リアルタイム分析は夢のまた夢

「データは新しい石油だ」と言われ始めた時代。しかし、その石油を精製する設備が追いついていなかったのです。

Snowflakeの革命：「分離」というシンプルな発想

Snowflakeの創業者たちは、問題の本質を見抜きました。

「ストレージとコンピュートを分離すればいい」

この発想は、当時としては異端でした。従来のデータベースでは、データを保存する場所（ストレージ）と、データを処理する場所（コンピュート）は一体化しているのが常識だったからです。

Snowflakeは、この常識を覆します。

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

この分離がもたらした恩恵：

• 使った分だけ課金: コンピュートは秒単位で起動・停止可能。使わない時間は$0
• 無限のスケーラビリティ: ストレージはクラウドの限界まで拡張可能
• データ共有の民主化: 同じデータに複数のチームが同時アクセス可能

「シンプルなアイデアほど強い」——Snowflakeの成功は、この原則を証明しています。

主要機能

なぜこのような「革命」が可能だったのか？その答えは、創業者たちの異常な経歴にあります。

創業者の物語：Oracleの「王冠の宝石」たちの反逆

「エリート中のエリート」の17年

Benoit DagevilleとThierry Cruanes。

この2人は、データベース業界の巨人・Oracleで17年間を共に過ごした同僚——いえ、それ以上の存在でした。

彼らは「Oracleの王冠の宝石」と呼ばれる厳重に守られた少数精鋭の建築家集団の一員でした。Oracleが長年市場での地位を維持できた主要な理由となった技術者たちです。

Benoitは1996年、フランスの大学でデータベースの博士号を取得後、カリフォルニア州レッドウッドショアーズのOracle本社に入社。Oracle Query Optimizer（クエリを最適化するエンジン）開発のリーダーとして、データベースの心臓部を設計してきました。

Thierryも同じくフランス出身。Database Engineの開発に17年を捧げ、Oracleの技術的優位性を支えてきた人物です。

Benoitは16年間の在籍中に出会ったThierryを「bro（兄弟）」と呼び、非常に深い友情を育みました。

2人は、データベースの「内側」を知り尽くしていました。そして、その「限界」も。

Larry Ellisonに相談しなかった理由

2012年当時、2つの革命が起きていました。しかし、Oracleはそのどちらにも参加していませんでした。

1. クラウド革命: 彼らにとって「クラウドは分析、リソース、弾力性における奇跡」であり、「使用量にピークと谷があるアナリティクスワークロードにとってゲームチェンジャー」でした
2. サービス革命: 新たに台頭する「as a Service」のマインドセット

BenoitとThierryは、ある確信を持ちます。

“

"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, 共同創業者

彼らはOracle創業者のLarry Ellisonに相談しませんでした。

なぜなら、「すでに成熟したデータベース製品を持つOracleでは、このような製品を作れる可能性がゼロだと分かっていたから」です。

これは、17年間のキャリアを捧げた会社への「裏切り」とも取られかねない決断でした。同僚からは「裏切り者」と見られるリスクもあったでしょう。

しかし彼らは、過去を捨てて未来を選びました。

サンマテオのアパートで描いた設計図

2012年、2人はOracleを去ります。

次に彼らが向かったのは、オフィスではありませんでした。サンマテオのアパートの一室です。

何ヶ月もの間、2人はホワイトボードに向かい続けました。

Benoitは振り返ります：

“

"We worked solely in my apartment, for many months. We developed a scalable architecture by leveraging the resources of the cloud, and the very blueprint of the company was conceived on a whiteboard."

「私たちは何ヶ月もの間、私のアパートだけで働きました。クラウドのリソースを活用したスケーラブルなアーキテクチャを開発し、会社の設計図そのものがホワイトボードで構想されました」

— Benoit Dageville, 共同創業者

Oracle本社の豪華なオフィスから、アパートのホワイトボードへ。この風景の変化が、彼らの覚悟を物語っています。

「後から加わった」第3の創業者

ここで、物語は意外な展開を見せます。

Snowflakeには3人目の共同創業者がいます。Marcin Zukowski。しかし、彼の合流は典型的な創業ストーリーとは異なります。

Marcinは、Snowflakeの構想段階にはいませんでした。

2012年10月、BenoitとThierryと以前から友人だったMarcinに「こんな会社が存在する」と連絡がありました。Marcinは当時、自らが共同創業したデータベース企業Vectorwiseの仕事をしていました。

Sutter Hill VenturesのManaging DirectorであるMike Speiserが、Marcinに会いに来ました。何週間もの間、彼らはレストランで話し続けました。

Marcin自身の言葉：

“

"And at one moment, something in my brain clicked, and I decided to do it. A few months later, I was in California, and we were building Snowflake."

「ある瞬間、私の脳の中で何かがカチッとはまり、やることに決めました。数ヶ月後、私はカリフォルニアにいて、Snowflakeを作っていました」

— Marcin Zukowski, 共同創業者

Marcinが招かれた理由は明確でした。彼が発明した技術——ベクトル化実行（vectorised execution）と新しい軽量圧縮方法——をSnowflakeのアーキテクチャに組み込むためでした。

オランダ国立情報科学・数学研究所（CWI）での博士課程の研究が、これらの革新の基盤となっていました。

Oracle出身の2人と、アカデミックな研究者1人。この異色の組み合わせが、Snowflakeの技術的優位性を生み出したのです。

「インキュベートする」投資家

もう一人、Snowflakeの誕生に欠かせない人物がいます。

Mike Speiser。Sutter Hill VenturesのManaging Directorです。

彼は典型的なVCではありません。Snowflakeのコンセプトを創業者たちと一緒に考案しました。

2012年、元Oracle エンジニアのBenoitとThierryを説得してSnowflakeを創業させた後、Speiser自身が創業CEOに就任。数年間、SnowflakeはSpeiserのメインの仕事でした。

Sutter Hill Venturesの関与度は尋常ではありませんでした：

• Snowflakeにオフィススペースを提供
• 初期プロダクトの開発を支援
• 売上が増加するにつれ、後続ラウンドにも継続投資

リターン:

• 初期投資: $200M（約300億円）未満
• 2020年9月のIPO後の保有株価値: $12B（約1.8兆円）
• IPO直前時点で、会社の20%以上を所有

そしてSpeiserが下した最も重要な決断——それは、Frank Slootmanの引き抜きでした。

創業者たちの「静かな革命」は、ここから「爆発的な成長」のフェーズに入ります。しかし、その成長を牽引したSlootmanという人物は、一筋縄ではいかない存在でした。

Frank Slootman：「極度に対決的」なリーダー

ヨットを売った男

Frank Slootmanは、引退していました。

Data Domain（2007年IPO）とServiceNow（2012年IPO）という2つのエンタープライズ・テック企業をIPOに導いた実績を持つベテラン。十分な成功を収めた彼は、ヨット競技に打ち込む日々を送っていました。

そこへMike Speiserから電話が来ました。Pure Storageの取締役会で彼を知っていたSpeiserは、Snowflakeのポテンシャルを熱く語りました。

Slootmanは引退を中断し、ヨットの一部を売却、一部を譲渡して、Snowflakeに加わりました。

2019年、CEOに就任。彼の下で、Snowflakeは史上最大のソフトウェアIPOへと駆け上がります。

「私のCEOとしての役割は『極度に対決的』です」

Slootmanのリーダーシップスタイルは、シリコンバレーでも異質でした。

彼自身の言葉：

“

"My CEO role is 'insanely confrontational'."

「私のCEOとしての役割は『極度に対決的』です」

— Frank Slootman

彼の著書『Amp It Up』（2022年）で展開された哲学：

• 平凡さへの宣戦布告
• 現状打破
• 毎日対立的な選択をする
• ミッションへの執拗な集中

Snowflakeでは**「挑戦の文化」を設定しました。会議の大部分を「何がうまくいっているか」ではなく、「何がうまくいっていないか」を議論することに費やす**。

彼はElon Muskに例えられることもありました。

「去るべき人は去るべきです」

この哲学には、代償もありました。

新規採用者の一部は数週間で退職。「ServiceNowのペースと強度に耐えられず、システムに大きなショックだった」と告白する人もいました。

従業員の離職について尋ねられたSlootmanの回答：

“

"Those who should leave should leave. That's the beauty of it... you start attracting the right people and losing the wrong ones. So it's actually perfect."

「去るべき人は去るべきです。これが素晴らしい点です...正しい人を引き付け、間違った人を失い始める。だから実際には完璧です」

— Frank Slootman

冷徹とも取れる言葉。しかし、彼の下でSnowflakeは史上最大のソフトウェアIPOを達成します。

「物事を成し遂げる人を熱烈に受け入れ、そうでない人を拒絶する文化」——これがSlootmanのSnowflakeでした。

では、そのIPOはどのように展開されたのでしょうか？

IPOの舞台裏：$4.88Bをテーブルに残した日

価格設定の葛藤

2020年9月、Snowflakeは史上最大のソフトウェアIPOに向けて準備していました。

価格設定の経緯:

1. 当初の目標レンジ: $75/株
2. 修正レンジ: $100-$110/株
3. 最終価格: $120/株 — 目標レンジを超える価格設定

背景には投資家の旺盛な需要がありました。しかし、ここに内部の葛藤がありました。

Goldman Sachsはさらなる値上げを主張していたとされますが、CFOのMike Scarpelliは$100/株を超えることに反対していました——「馬鹿げて見えることを恐れて」。

結果として$120/株で決定。しかし、これは「控えめすぎる」価格設定だったことが、初日の取引で明らかになります。

時価総額・株価推移：IPO初日の狂騒

2020年9月16日の取引:

初日時価総額: $70B（約10.5兆円）

Snowflakeは2,800万株を売却し、$3.4B（約5,100億円）を調達しました。

「史上最大の機会損失」

しかし、この大成功には影の側面がありました。

Snowflakeは$4.88B（約7,320億円）を「テーブルに残した」 — これは12年間で最大の未取得額です。

$120/株よりはるかに高い価格を払う意思のある投資家は：

• 株を全く取得できなかったか
• 希望量のわずかな割合しか取得できませんでした

そしてSnowflakeがデビューすると、彼らが大挙して押し寄せ、株価を112%押し上げました。

もし公開価格を$200/株に設定していたら、Snowflakeは数十億ドル多く調達できたかもしれません。

創業者たちの「沈む気持ち」

ここに、この記事の冒頭で触れた「謎」への答えがあります。

興味深いことに、創業者たちは喜んでいませんでした。

共同創業者Thierry Cruanesの言葉：

“

"We had a sinking feeling because it was a reflection of the expectation that everybody else had on us."

「沈む気持ちでした。なぜなら、それは他のすべての人が私たちに持っている期待の反映だったからです」

— Thierry Cruanes, 共同創業者

Benoit Dagevilleも付け加えました：

“

"I would have rather Snowflake started with a lower valuation."

「Snowflakeはもっと低い評価額でスタートした方が良かったと思います」

— Benoit Dageville, 共同創業者

高すぎる期待。それが彼らの恐れでした。

サンマテオのアパートでホワイトボードに向かっていた2人は、今や$70Bの期待を背負うことになったのです。

Buffettの舞台裏

このIPOで最も注目を集めたのは、Warren BuffettのBerkshire Hathawayが$250M（約375億円）を投資したことです。

これはBuffettにとって:

• Ford Motor Company以来初のIPO投資
• 史上初のテックIPO投資

Salesforceも同時に$250M（約375億円）を投資しました。

誰が決めたのか？

Berkshireの保険事業が長年Snowflakeのクラウドベースのデータウェアハウスを使用していたため、Buffettの側近であるTodd CombsがSnowflakeの製品と能力を熟知していました。

Slootman自身が語ったところによると、Snowflakeとのやり取りのほとんどはTodd Combsとのものでした。

Slootmanの戦略:

Slootmanは、Buffettを投資家として引き込むことを数ヶ月前から追求していました。その理由：

“

"To raise the stature of Snowflake as a brand."

「Snowflakeをブランドとしての格を上げるため」

— Frank Slootman

彼は、10億ドル規模のポジションを買い、長期保有する可能性が高い主要な機関投資家をSnowflakeの株主として引き付けることを目指していました。

この戦略は大成功しました。

資金調達の歴史

Snowflakeの成長指標

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

Dated Snapshot: Q4 FY26 investor presentation

2026年2月25日に公開された investor presentation では、Snowflake を次の数値で説明しています。

一方で、Snowflake の company overview page では 12,062 global customers と 3,400 marketplace listings が前面に出ています。定義や更新日が page ごとに違う可能性があるため、quarterly metrics は investor materials、product surface は docs / platform page で確認するという読み分けが安全です。

ここまでで見えるのは、Snowflake を live company dashboard として追うより、product map と運用論点から読むほうが durable だということです。

導入前に詰めたいコスト / 運用論点

料金は compute / storage / transfer / AI追加費用 に分けて見る

Snowflake の pricing は「credit を消費する compute」「storage」「data transfer」「feature ごとの追加課金」を分けて見ると整理しやすくなります。

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

• batch / interactive で別々に動く warehouse の runtime
• serverless feature や AI surface の追加消費
• region をまたぐ data movement や share の設計
• retention、fail-safe、governance に伴う storage 前提

単一の「Snowflake は高い / 安い」という議論より、どの workload がどの課金面を押し上げるかを分離して見るほうが実務では重要です。

Warehouse sprawl を防ぐ担当者が必要

Snowflake の良さは、同じ storage を共有しながら compute を独立して増減できることです。裏返すと、部門ごとに warehouse を増やし続けると支出の所在がすぐ曖昧になります。

最低限、次の owner は決めておくべきです。

• warehouse size の標準
• auto-suspend と稼働時間の方針
• domain ごとの cost visibility
• AI feature 用の separate budget

Semantic model と権限設計が AI 品質を決める

Cortex Analyst や Snowflake Intelligence は、自然言語の入口が見やすいぶん、裏側の semantic model と role 設計が弱いとすぐに brittle になります。

先に確認すべきなのは次の点です。

• metric の定義を semantic model に寄せられるか
• 参照させる table / doc を role と masking policy で切り分けられるか
• AI の回答に source trace を求める運用にするか
• business user 向け AI と builder 向け AI を同じ budget に入れないか

Cross-region / cross-cloud は先に確認する

Snowflake の強みは sharing と cloud 横断性にありますが、AI inference や data transfer の前提は region と cloud の組み合わせで変わります。

設計初期に見るべきポイントは次の通りです。

• structured data だけで完結するか、document retrieval も必要か
• account region を越える inference を許容するか
• cross-cloud share を主機能にするか
• 可搬性より managed convenience を優先するか

どんなチームに向くか

Snowflake が刺さりやすいケース

Snowflake が特に刺さりやすいのは、次のようなチームです。

• SQL 中心の analytics と governed sharing を同じ platform に寄せたい
• 同じ storage を複数 team で共有しつつ compute を分離したい
• business user 向けの自然言語分析を、企業権限の内側で扱いたい
• Native Apps や Marketplace を含めた data collaboration まで見たい

先に設計が必要なケース

逆に、次のようなケースでは他の選択肢も並べて比較したほうがよいです。

• notebook / open-source 中心の ML workflow を第一義に置く
• custom model training や lakehouse engineering を起点に platform を組みたい
• cross-cloud data movement が主役で transfer cost の制約が大きい
• semantic model と権限設計の owner を置けない

ここを曖昧にしたまま導入すると、analytics 基盤、AI 基盤、app platform のどれに投資しているのかが見えにくくなります。

SnowflakeとDatabricksの見分け方

指標競争ではなく責務分解で見る

競合比較

Snowflake と Databricks を比較するときに、private valuation や short-term growth を主軸にすると判断を誤りやすくなります。実務では、誰の仕事をどの platform に寄せるのかで見るほうがぶれません。

Snowflake が強い場面

1. SQL-first の浸透: analyst が主役でも導入しやすい
2. 共有のしやすさ: marketplace や sharing を軸に社外連携まで広げやすい
3. 企業統制の一貫性: same role / masking / governance の延長で AI を置きやすい

Databricks を先に見る場面

Databricks が先に候補に入るのは、ML engineering や notebook workflow を中心に据えたいときです。つまり、分析基盤の上に AI を載せるのではなく、engineering / model workflow の延長として platform を組む場合です。

両者の境界は広く重なってきていますが、Snowflake の記事では少なくとも「shared data plane を軸にどこまで寄せたいか」を判断軸に置くと読み違いが減ります。

AI surface の読み分け: Cortex / Snowflake Intelligence / AI Observability

Snowflake AI進化タイムライン

Ramaswamy体制で変わった読み方

2024年2月28日、Snowflakeは衝撃的な発表をしました：

Frank Slootmanが退任し、Sridhar Ramaswamyが即座にCEO兼取締役に就任。

この交代を live leadership drama として追うより、Snowflake が AI を独立した product category として前面に出し、builder 向け surface と end-user 向け surface を分け始めたと読むほうが durable です。

Builder surface: Cortex family

Snowflakeアーキテクチャ

公式 docs と product page を基準にすると、Cortex family は次のように読むと整理しやすくなります。

End-user surface: Snowflake Intelligence

Snowflake Intelligence は、ai.snowflake.com で動く ready-to-use の enterprise agent として位置づけるのが分かりやすいです。公式 product page では、自然言語での深い分析、source citation、verified answer、既存 governance の内側で動く点が前面に出ています。

つまり、builder が Analyst / Search / Agents を組み合わせる世界と、business user が ready-made agent を使う世界を分けて考えると、期待値が合わせやすくなります。

実務ではこの順で見る

1. structured data だけで答えたい: Cortex Analyst
2. document grounding も必要: Cortex Search
3. 複数 tool をまたぐ task: Cortex Agents
4. business user 向け self-service: Snowflake Intelligence
5. 本番運用の評価と予算管理: AI Observability と resource budget

Buffettの投資——そして撤退が意味すること

冒頭の問いに戻りましょう。

なぜWarren Buffettは、「テックIPOには投資しない」という自身のルールを破ってまで、Snowflakeに投資したのでしょうか？

答えは、「堀（moat）」の深さです。一度導入すれば企業のデータ基盤そのものになり、移行コストは膨大で、競合への乗り換えは現実的ではない。

しかし、物語には続きがあります。

Berkshire Hathawayの全株売却をどう読むか

2024年第2四半期に Berkshire Hathaway が Snowflake 株を全売却したこと自体は historical fact です。ただし、ここで重要なのは当日の株価より、Snowflake が public market で「stickiness のある data platform」と「AI投資を続ける consumption business」の両方として評価されてきたという点です。

IPO 史を読む価値は、今日の株価を当てることではなく、Snowflake に期待され続けている責務の広さを知ることにあります。

Dated Snapshot: 2026年2月25日の investor presentation

この snapshot は useful ですが、company overview page の counter とも少しずれます。したがって、会社数値は公開日つきで引用し、title / summary / lead を live-metrics 化しないのが安全です。

主要ポイント

次のステップ

1. data platform owner: workload を Analytics / Data Engineering / AI / Applications & Collaboration に棚卸しし、どこまで Snowflake に寄せるか決める
2. analytics owner: Cortex Analyst や Intelligence を触る前に semantic model と role 設計を整える
3. AI app owner: warehouse cost、transfer、agent / search budget を別々に見積もってから pilot を始める

関連記事

参考リソース

Snowflake公式

• Snowflake Platform
• About Snowflake
• Snowflake Intelligence
• Snowflake Documentation
• Snowflake investor relations
• Snowflake Q4 FY26 investor presentation

テックメディア報道

• CNBC - Warren Buffett invests in Snowflake IPO
• TechCrunch - Snowflake IPO
• Fortune - Snowflake's IPO left $5B on the table

創業者・リーダーシップ関連

• Computer Weekly - Snowflake founders reveal 'cuckoo cloud' vision
• Fortune - Frank Slootman calls role 'insanely confrontational'

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