第4章: 同型ツールと何が違うのか
第1部で Snowflake の中身を見た。本章では視点を外に向け、同型の6ツールとの比較を通して「いつ Snowflake を選ぶか」「いつ他を選ぶか」の判断軸を作る。
比較対象：
- Google BigQuery（クラウド純正：GCP）
- Amazon Redshift（クラウド純正：AWS）
- Databricks（直接競合：Lakehouse / ML+AI）
- Microsoft Fabric / Synapse（クラウド純正：Azure）
- DuckDB / MotherDuck（軽量・組み込み）
- ClickHouse（リアルタイムOLAP特化）
比較軸は 設計思想 / 価格モデル / 得意領域 / Snowflakeとの主な差。
Google BigQuery
| 項目 | 内容 |
|---|---|
| 設計思想 | 完全サーバーレス。クラスタ概念なし、Googleが裏で全自動リソース割当 |
| 価格モデル | On-Demand（$6.25/TB スキャン）/ Capacity（slot=仮想CPU、Editions: Standard/Enterprise/EE+） |
| 得意領域 | GCP エコシステム、Looker / Vertex AI 連携、ストリーミング取り込み、アドホック分析 |
| 不得意 | マルチクラウド要件、ワークロード分離（slot共有）、細かい運用制御 |
| 2025-2026 | Iceberg対応（DCU課金）成熟、BigQuery ML 強化、Geminiモデル統合 |
Snowflake との主な差
- BigQuery は「GCP前提・サーバーレス完全自動」、Snowflake は「マルチクラウド・VWH単位の細かい分離」
- スキャン量課金は「予測しにくい」「
SELECT *で破滅」と双方の側面がある。Snowflake はVWH時間で予測しやすい - Iceberg対応は両者進めているが、Snowflake は Open Catalog でカタログ層もオープン化
いつ BigQuery を選ぶか：GCP前提・サーバーレス志向・Looker/Vertex AI とのネイティブ統合が必要な場合。
Amazon Redshift
| 項目 | 内容 |
|---|---|
| 設計思想 | クラスタプロビジョニング型から始まり、RA3ノードで storage/compute 分離、Redshift Serverless で自動スケール、Spectrum で S3 直接クエリ |
| 価格モデル | Serverless $1.50/RPU-hour〜、プロビジョンドはノード時間、Reserved Instance あり |
| 得意領域 | AWS統合（IAM / S3 / Glue / Lake Formation）、既存AWS資産との一体運用 |
| 不得意 | マルチクラウド、データシェアリングのエコシステム規模 |
| 2025-2026 | デフォルトで「パブリックアクセスなし・暗号化オン・セキュア接続強制」になりセキュア・バイ・デフォルト化 |
Snowflake との主な差
- Redshift は「AWS depth」、Snowflake は「クラウドニュートラル + 運用簡便」
- Redshift はクラスタ管理（VACUUM、ANALYZE、distkey/sortkey の設計）が依然として残る、Snowflake は不要
- Redshift Serverlessでも「課金単位（RPU）の挙動」が読みにくい、Snowflake のVWH時間より複雑
いつ Redshift を選ぶか：AWS純正のデータ基盤を組みたい・IAM / Lake Formation との深い統合が必要・既存AWS資産が大きい場合。
Databricks ─ 最も直接的な競合
| 項目 | 内容 |
|---|---|
| 設計思想 | Apache Spark発のLakehouse。Delta Lake で ACID/Time Travel/Schema Evolution、Photon エンジンで高速化、Unity Catalog でマルチフォーマット/マルチエンジン/マルチクラウドのガバナンス統合 |
| 価格モデル | DBU（Databricks Unit）消費量 × ノードタイプ。Photon有効でDBU消費増だが処理高速 |
| 得意領域 | ML/AI、ストリーミング、非構造化データ（画像/動画/テキスト）、データサイエンス |
| 不得意 | BIユーザー / SQLアナリスト中心の組織には学習コストが高い |
| 2025-2026 | Iceberg REST Catalog API フルサポート（Data + AI Summit 2025）、ABAC、Data Classification（PII自動検出）、Unity Catalog Metrics、Lakebase（OLTP） |
Snowflake との主な差
| 観点 | Snowflake | Databricks |
|---|---|---|
| 主たる利用者 | SQL中心（アナリスト・BI） | Python / Notebook 中心（DS・DE） |
| 強み | 運用簡便、SQL一辺倒 | ML/AI、ストリーミング、非構造化 |
| カタログ | Snowflake Open Catalog（Apache Polaris） | Unity Catalog |
| OLTP | Hybrid Tables | Lakebase |
| 2026年の競合 | 機能収束フェーズ |
重要：従来「DWH=Snowflake / Lakehouse=Databricks」という棲み分けは2025年で消滅。両社ともIceberg + 自社カタログでオープン化を進め、Snowflake は SPCS / Notebooks / Cortex で ML/AI 領域へ進出、Databricks は Lakebase（OLTP）で「閉じたDB」化を進めて、両者が中央で競合している。
いつ Databricks を選ぶか：データサイエンス / ML / 非構造化データが主軸、Notebookベースの開発が中心の組織。
いつ Snowflake を選ぶか：BIアナリスト・SQL中心、運用負荷を抑えたい、すぐ業務で使える状態を求める場合。
Microsoft Fabric / Synapse
| 項目 | 内容 |
|---|---|
| 設計思想 | OneLake（全データを単一論理レイクに集約、データコピー不要）を中核に、データ統合 / エンジニアリング / データサイエンス / リアルタイム分析 / Power BI を SaaS として統合 |
| 価格モデル | 単一の Capacity（F SKU）モデル、Power BI Premium 込みで BI込みなら安く見える |
| 得意領域 | Microsoft 365 / Teams / Excel との統合、Copilot in Power BI、Azure 中心の組織 |
| 不得意 | マルチクラウド、Azureロックイン |
| 2025-2026 | Iceberg / Parquet 経由で Snowflake とも相互運用可能 |
Snowflake との主な差
- Fabric は「Microsoft スタック前提なら 60〜80% 安い」と言われる
- Snowflake は「マルチクラウド可搬・ワークロード分離・Marketplace 規模」で勝つ
- Fabric は Power BI 中心の組織には圧倒的に魅力的だが、それ以外の選択肢への移行コストが高い
いつ Fabric を選ぶか：Microsoft 365 中心、Power BI が主要BI、Azure ロックインを許容できる組織。
DuckDB / MotherDuck
| 項目 | 内容 |
|---|---|
| 設計思想 | 「OLAPのSQLite」。組み込み型 / シングルプロセスで Parquet/Iceberg/CSV を直接読む |
| 価格モデル | DuckDB 自体は無料（Apache 2.0）、MotherDuck はコンピュート / ストレージ課金 |
| 得意領域 | ローカル分析、ノートPC上の ad-hoc、軽量 ETL、AI エージェントの分析バックエンド |
| 不得意 | 超大規模分散、高並行アクセス |
| 2025-2026 | MotherDuck が $100M 調達 / $400M 評価、AI エージェント分析の標準位置を狙う |
Snowflake との主な差
- DuckDB は「個人・小チーム・コスト最小化」、Snowflake は「組織横断・運用統制・大規模」
- 競合ではなく補完関係。「ローカルでDuckDB → 本番でSnowflake」という使い分けが定着しつつある
いつ DuckDB を選ぶか：1台のサーバ・ノートPC で完結、データ量が数百GB以下、コスト重視。
ClickHouse
| 項目 | 内容 |
|---|---|
| 設計思想 | 分散型カラム指向OLAP。マルチノード分散、サブ秒レスポンス、リアルタイム取り込み |
| 価格モデル | OSS 無料、ClickHouse Cloud は usage-based |
| 得意領域 | ログ分析、リアルタイムダッシュボード、IoT、可観測性、高並行・低レイテンシ用途 |
| 不得意 | 複雑なジョイン / トランザクション系、エコシステム広さ |
Snowflake との主な差
- ClickHouse は「リアルタイム配信・低レイテンシ用OLAP」、Snowflake は「全社DWH・ガバナンス・データシェア」
- Snowflake は Snowpipe Streaming で 10秒未満レイテンシまで届くようになり、ClickHouse 領域に少し踏み込んだが、サブ秒の世界では依然 ClickHouse
いつ ClickHouse を選ぶか：リアルタイム可観測性・ログ分析が主軸、サブ秒応答が必須、書き込みが極端に多い場合。
6ツール × Snowflake 比較表
| Snowflake | BigQuery | Redshift | Databricks | Fabric | DuckDB | ClickHouse | |
|---|---|---|---|---|---|---|---|
| 設計思想 | 3層分離 / マルチクラウド | サーバーレス / GCP | クラスタ→分離型 / AWS | Lakehouse / Spark | OneLake / Azure | 組み込み / OSS | 分散OLAP |
| 主たる利用者 | SQL中心 | SQL中心 | SQL中心 | DS/DE中心 | BI中心 | 個人 / 小チーム | リアルタイム分析 |
| 価格軸 | 秒課金 (credit) | スキャン or slot | RPU or ノード時間 | DBU | F SKU capacity | 無料 / usage | OSS / cloud |
| マルチクラウド | ◎ | △ (GCP前提) | △ (AWS前提) | ◎ | △ (Azure前提) | ◎ | ◎ |
| オープンフォーマット | ◎ Iceberg + Open Catalog | ○ Iceberg対応 | ○ Spectrum | ◎ Delta + Iceberg | ○ OneLake | ◎ Parquet/Iceberg | ◎ |
| ワークロード分離 | ◎ VWH単位 | △ slot共有 | ○ Serverlessで改善 | ○ クラスタ単位 | △ capacity単位 | ✕ 単一プロセス | ○ クラスタ単位 |
| ML/AI統合 | ○ Cortex / Snowpark | ○ BigQuery ML | △ | ◎ Spark/Mosaic | ○ Copilot | △ | ✕ |
| OLTP | ○ Hybrid Tables | ✕ | ✕ | ○ Lakebase | ✕ | ✕ | ✕ |
| データシェアリング | ◎ Marketplace | ○ Analytics Hub | △ | ○ Delta Sharing | △ | ✕ | ✕ |
「いつ Snowflake を選ぶか」の判断軸
flowchart TD
Start[DWH選定] --> Q1{マルチクラウド要件?}
Q1 -- Yes --> Q2{SQL中心 or DS中心?}
Q1 -- No --> CloudNative[クラウド純正<br/>BigQuery/Redshift/Fabric]
Q2 -- SQL --> Snowflake[Snowflake]
Q2 -- DS/ML --> Q3{Lakehouseで全部やる?}
Q3 -- Yes --> Databricks[Databricks]
Q3 -- No --> Snowflake
Snowflake --> SF[Snowflake<br/>+ Cortex/Snowpark]簡潔に言えば：
- マルチクラウド要件 + SQL中心 + 運用簡便を求めるなら Snowflake
- クラウド純正で十分 + そのクラウドに強くロックインしてOKならBigQuery / Redshift / Fabric
- ML/DS が組織の主軸 + Notebookベース開発が中心なら Databricks
- 個人・小チーム + コスト最小なら DuckDB
- リアルタイム・サブ秒レイテンシが必須なら ClickHouse
注意：これは2026年5月時点。Snowflake と Databricks は機能収束フェーズなので、半年〜1年で判断軸が変わる可能性が高い。
エコシステム再編 ─ dbt + Fivetran 合併（2025-10）
選定の背景として知っておくべきニュース：
2025-10-13 Fivetran と dbt Labs が全株式合併（年商約 $600M）。「Fivetran で取り込み → dbt で変換 → Snowflake で保管」というモダンデータスタックが、取り込みと変換が同じ会社の製品になった。
意味：
- 個別ツールの統合がより緊密になる（DAG共有、メタデータ統一）
- 価格モデルの再編（Fivetran は2024-2025で40-70%値上げ報告）
- Snowflake / Databricks / BigQuery と連携するコネクタ層が再編される
選定時に「Fivetran + dbt + Snowflake」のセット採用がより一体感のある選択肢になる一方、ベンダー集中リスクも意識する必要がある。
本章の要点
| # | 要点 |
|---|---|
| 1 | マルチクラウド + SQL中心 なら Snowflake が最も自然な選択 |
| 2 | クラウド純正のロックイン許容 なら BigQuery / Redshift / Fabric。各クラウドのエコシステムと深く統合できる |
| 3 | ML/DS主軸 + Notebook中心 なら Databricks。ただし2025年以降は Snowflake と機能収束フェーズ |
| 4 | 個人・小チーム なら DuckDB / MotherDuck。Snowflake と補完関係 |
| 5 | リアルタイム・サブ秒 なら ClickHouse。Snowflake は Snowpipe Streaming で接近したが、サブ秒はまだ ClickHouse |
| 6 | dbt + Fivetran 合併（2025-10）でモダンデータスタックが再編フェーズ。選定時に意識する |
効いている根本原理
本章は4原理を比較の物差しとして使った：
- 原理1（3層分離）：ワークロード分離の比較で Snowflake の優位
- 原理2（Consumption-based Pricing）：価格モデル比較の中心
- 原理3（コピーを作らない）：Iceberg + Open Catalog でのオープン化比較
- 原理4（SQL から AI/Apps への拡張）：Cortex vs Mosaic / Vertex AI / Copilot 比較
ここまでで第1部 + 第2部「Snowflake を理解 + 比較する」は完了。次章から**第3部「実際に使う」**に入る。具体的なユースケースから見ていく。