データ基盤 ― DWH・データレイク・レイクハウスの選び方 ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「データアーキテクチャ」カテゴリ第4弾として、データ基盤について解説する記事です。

貯めるだけの基盤は負債、引き出せる基盤は資産。本記事では DWH／データレイク／レイクハウス3つの選択肢の特徴、BIツール連携、規模別の推奨構成、そして「貯める」が目的化した瞬間に基盤が「データスワンプ（沼）」になる構造を解説します。

このカテゴリの他の記事

データ基盤が担うもの

BIダッシュボード、経営KPI、機械学習、AIエージェント──これら全ての土台がデータ基盤です。基盤がないと個別システムごとにデータを集めることになり、部署を跨いだ全社分析が不可能になります。

データ基盤の有無が、DX（Digital Transformation、デジタル前提への業務転換）成功の分かれ目。ここで手を抜くと全社AI活用に到達できません。

なぜ必要か

① 業務DBを分析に使うと性能が落ちる

業務DBは「1トランザクションを速く・安全に」最適化されており、「全データ集計」のような分析クエリを回すと業務側が遅くなります。業務と分析の分離は事実上の標準です。

② データは組織を横断する

営業・マーケ・経理・CSのデータを全社で繋ぐには、「1箇所に集約する基盤」が必要です。これが無いと部署ごとに同じ数字が違う問題が起きます。

③ AIの精度はデータの質で決まる

機械学習モデルも LLM の RAG も、「整ったデータ」があって初めて成立します。データ基盤が貧弱だとAI活用の上限が決まってしまいます。

3つの選択肢

flowchart LR
    SRC[業務システム<br/>ログ/IoT/SNS]
    DWH["DWH<br/>構造化データ専用<br/>(整えて入れる)<br/>BigQuery/Snowflake"]
    LAKE["データレイク<br/>生データ何でも<br/>(貯めるだけ)<br/>S3/Azure Blob"]
    LH["レイクハウス<br/>両方のいいとこ取り<br/>Delta Lake/Iceberg"]
    SRC -->|構造化のみ| DWH
    SRC -->|形式問わず| LAKE
    SRC -->|構造+非構造混在| LH
    DWH -.- L1[整っている分<br/>柔軟性は低い]
    LAKE -.- L2[柔軟だが<br/>沼化リスク]
    LH -.- L3[2024年以降の本命]
    classDef src fill:#fef3c7,stroke:#d97706;
    classDef dwh fill:#dbeafe,stroke:#2563eb;
    classDef lake fill:#fae8ff,stroke:#a21caf;
    classDef lh fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
    class SRC src;
    class DWH dwh;
    class LAKE lake;
    class LH lh;

選択肢	ざっくりした説明
DWH（データウェアハウス）	構造化データの分析専用DB。整えて入れる
データレイク	生データを形式問わず貯める巨大ストレージ
レイクハウス	両者のいいとこ取り。データレイクに直接SQLが当たる

どれか1つで済むケースもあれば、「DWH + データレイク併用」で運用する大企業もあります。規模と用途で決めていきます。

データウェアハウス（DWH）

分析専用に最適化された列指向DBで、構造化されたデータを整えて入れる場所です。1980年代から存在する歴史ある概念で、月次レポート・経営ダッシュボード・KPIモニタリングといった「集計分析」の主戦場です。

現代のDWHは全てクラウドマネージドで、BigQuery・Snowflake・Redshift が三強です。TB〜PB級でも秒単位で集計でき、SQLでアクセスできるため学習コストも低めです。

メリット	デメリット
集計分析が超高速	非構造データは入らない
SQLで誰でも扱える	生データを貯めるのは不経済
権限制御が細かい	クラウドごとに料金体系が独特
運用がほぼ不要（マネージド）	ベンダーロックインが強い

代表例：BigQuery・Snowflake・Amazon Redshift・Azure Synapse

既定はBigQueryかSnowflake。RedshiftはAWS縛りでない限り選ぶ理由が減っています。

データレイク

形式を問わず生データを貯める「巨大ストレージ」です。CSV・JSON・画像・動画・PDF・ログ──何でも入る柔軟性が特徴で、「とりあえず全部取っておいて、後で使い方を考える」というスタンスで運用されます。クラウドのオブジェクトストレージ（S3・GCS・ADLS）がそのまま基盤になります。

DWHが「整えてから入れる」のに対し、データレイクは入れてから整える発想です。機械学習・非構造データ分析・監査ログ保管など、「DWHでは扱えない領域」を担当します。

メリット	デメリット
形式問わず何でも入る	雑に使うと「データスワンプ」化
ストレージコストが極めて安い	そのままではSQL不可（別エンジン必要）
スケール無制限	権限管理・ガバナンスが難しい
機械学習の前処理に最適	検索・集計は遅い

代表例：Amazon S3・Google Cloud Storage・Azure Data Lake Storage

運用ルールを作らず貯めるだけだとデータの沼化。必ずカタログ・命名規則を整えます。

レイクハウス

データレイクにDWHの機能を乗せた現代的なアプローチです。S3に置いたParquetファイルに対して直接SQLを当て、ACIDトランザクションもサポートする、という「いいとこ取り」の構成。Databricksが提唱し、Delta Lake・Apache Iceberg・Apache Hudi がデータ形式の標準として定着しつつあります。

「DWHとデータレイクの両方を運用するのは重すぎる」という課題から生まれた概念で、新規構築ではレイクハウスが第一候補になりつつあります。ただし運用ノウハウがまだ発展途上で、チームが慣れていないと難易度が高めです。

メリット	デメリット
1基盤で両用途をカバー	運用ノウハウが発展途上
ストレージコストが安い	チームの学習コストが必要
ベンダーロックインが弱い	ツールチェーンがまだ完成途上
構造化・非構造化の両対応	小規模では過剰になることも

代表例：Databricks・Snowflake（Iceberg対応）・BigLake

2024年以降、レイクハウスが新規構築の主流に。既存DWHからの移行は段階的に進めます。

3者の比較

観点	DWH	データレイク	レイクハウス
構造化データ分析	◎	△	◎
非構造化データ	×	◎	◯
ストレージコスト	高	低	低〜中
SQLの直接利用	◎	×	◯
運用の簡単さ	◎	△	△
ベンダーロックイン	強	弱	中
機械学習との相性	△	◎	◎

レイクハウスが新しくバランス型に見えますが、既にDWHで回っている組織が無理に乗り換える必要は無いのも実情です。

BIツールとの連携

データ基盤を作っても、可視化ツール（BI）が無いと業務部門が使えません。BIツールはDWH/レイクハウスにSQLを投げ、ダッシュボードやレポートとして表示します。

BIツール	特徴	向くケース
Tableau	機能最強・業界標準	大企業・高度な分析
Power BI	Microsoft系と好相性	Microsoft 365利用企業
Looker	モデル層が強い・Google連携	BigQueryユーザー
Metabase	OSS・軽量・無料	小〜中規模・個人利用
Redash	OSS・SQL中心	エンジニア主体の組織

業務部門が自分で触れるかどうかでBI浸透度が決まります。非エンジニアが使えるUIが揃ったものを選ぶのが定石です。

判断基準

① データの種類

扱うデータの種類によって最適な基盤が変わります。構造化データだけならDWH一択で済みますが、画像・動画・非構造データが絡む場合はデータレイクかレイクハウスが必須になります。

データ種	推奨
業務系の構造化データのみ	DWH（BigQuery・Snowflake）
機械学習・AI前処理あり	レイクハウス or DWH + レイク併用
ログ・画像・動画の大量保管	データレイク中心
履歴・監査目的の長期保管	データレイク（S3 Glacier等）

② 規模と予算

DWHはクエリ課金が主流で、無駄なクエリを投げると請求額が跳ね上がります。一方でデータレイクはストレージが極めて安く、「とりあえず貯める」のに向きます。予算管理の思想も選定に影響します。

③ クラウドベンダー

データ基盤はクラウドベンダーと強く結びつきます。既に AWS を使っているなら Redshift + S3、GCP なら BigQuery、Azure なら Synapse + ADLS というように、既存クラウドに合わせるのが運用・課金の両面で有利です。

ベンダー	DWH	データレイク
AWS	Redshift	S3 + Glue
Google Cloud	BigQuery	GCS + BigLake
Azure	Synapse	ADLS + Fabric
マルチクラウド	Snowflake	–

Snowflake は唯一のマルチクラウドDWHで、ベンダーロックインを避けたい企業に支持されています。

ケース別の選び方

中小企業の経営KPI可視化

BigQuery + Metabase/Redash。安価（月数万円〜）・シンプル・学習コスト低。業務DBからのETLは dbt（data build tool、SQLでデータ変換パイプラインを定義するツール）で管理します。

大企業・多部署・マルチクラウド

Snowflake。マルチクラウド対応・権限管理が強力・契約規模のディスカウントも利く。BIは Tableau か Power BI。

機械学習・AI活用重視

レイクハウス（Databricks）。ノートブック・MLOps（機械学習版DevOps）まで一気通貫。既存DWHがある場合は並行運用から始めます。

スタートアップ・MVPフェーズ

データ基盤は作らない。PostgreSQLのリードレプリカ + Metabaseで十分。売上が伸びたら本格導入を検討します。

組織規模・データ量別の基盤選定段階表

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

データ基盤は「流行で選ぶ」と運用で破綻します。規模と月額コストを軸に段階的に選ぶのが実務の定石です。

組織規模	データ量	推奨基盤	月額目安	BIツール
個人・MVP	〜10GB	PostgreSQLのみ	0〜5,000円	Metabase（無料）
スタートアップ	〜1TB	BigQuery	数千〜数万円	Metabase / Looker Studio
中規模SaaS	〜10TB	BigQuery or Snowflake	数万〜数十万円	Looker / Tableau
大企業・多部署	〜100TB	Snowflake（マルチクラウド）	数十万〜数百万円	Tableau / Power BI
超大規模・ML中心	100TB〜	Databricks（レイクハウス）	数百万〜	専用ダッシュボード

クエリ課金の爆死パターン：BigQuery で SELECT * を無制限に使うと、月数十万円が一晩で到達する事例が定番。パーティション必須・列指定必須・クエリキャッシュ活用の3点セットでコスト制御します。Snowflake もウェアハウスサイズ × 稼働時間で課金されるため、開発環境は XS 固定・本番のみ Auto-scale が鉄板です。

スタートアップで Snowflake は過剰投資。BigQuery 無料枠で数GB〜数百GB は十分回ります。

筆者メモ — 「貯めたのに誰も使えない」沼の事例

ある事業部では「いつか分析するから」と部署全員のログを「S3に3年間貯め続けた」ものの、スキーマも命名規則もないJSONファイルが数億個積み上がった結果、誰も使えず沼化した、という話がしばしば聞かれます。日付フォーマットがファイルごとに違い、フィールド名がサービス改修のたびに揺れ、同じ意味の値に複数の表記が混在。分析用の加工コストが、そこから新しくログ収集を設計するコストより高くなるという「本末転倒」に至ったと言います。

別の現場では、逆に「全部BigQueryに入れれば安心」と画像・動画のバイナリまでDWHに突っ込んだ結果、クエリ課金が月数百万円に跳ね上がった、という笑い話のような事例もあります。DWHは構造化データ向け、非構造データはデータレイク、という基本の住み分けを無視するとコスト面で跳ね返ってきます。

筆者自身、過去のプロジェクトでログ設計を甘く考えて「とりあえずJSONで」と判断し、半年後に分析担当から「これ読めないです」と告げられた経験があります。どちらも貯めること自体が目的化すると基盤ではなくゴミ置き場になる、という共通の教訓を残した事例です。カタログ・命名・用途別基盤の使い分けが、基盤を沼にしないための基本装備になります。

データ基盤は「貯める」ではなく掘り出せるが目的。カタログと保存ポリシーで負債化を防ぎます。

データ基盤の鬼門・禁じ手

データ基盤で事故る典型を整理します。「貯める」が目的化した瞬間、基盤はゴミ置き場になります。

禁じ手	なぜダメか
スキーマも命名規則もなしでS3に生データを貯め続ける	3年後に「誰も掘れない沼」加工コストが新しい収集設計より高くなる
DWHに画像・動画のバイナリを入れる	クエリ課金が月数百万に。非構造データはデータレイクへ
BigQueryで SELECT * を無制限	月額が一晩で跳ね上がる。カラム指定 + LIMIT必須
Snowflakeのウェアハウスを常時Large固定	開発・ステージングもLargeは無駄。XS + Auto-scaleで制御
業務DBで直接分析を回す	業務側の性能劣化、顧客影響。必ずDWHにETL/ELTで分離
dbt / ELTなしで手書きSQLが社内に散在	変換ロジックが属人化。退職者のPCにだけ秘伝のSQLが残る
個人情報をマスキングせずにDWHへ投入	GDPR / 個人情報保護法違反。Meta 2023年の€1.2B制裁金と同じリスク
データカタログなしで運用	「このデータどこ？」を毎回人に聞く。分析速度が1/10に
保存期間ポリシーなし	5年前の全データが Standard クラス課金で垂れ流し。階層ストレージへ
レイクハウスを小規模から採用	運用ノウハウが発展途上。中規模以上で段階的に

2023年5月のMeta GDPR制裁金 €1.2B（約2,000億円）は、データ保管場所の設計ミスが企業存続レベルの罰金に直結することを示した事件です。「業種ごとの規制要件（GDPR / HIPAA / PCI DSS）を最初にインプット」するのが基盤設計の出発点です。

AI時代の視点

AI駆動開発（バイブコーディング）とAI活用が前提になると、データ基盤はAIエージェントがアクセスする基盤としての重要性が跳ね上がります。LLMのRAG、Text-to-SQL、AIエージェントが業務データを照会する時代には、整ったデータ基盤がそのままAIの精度上限になります。

AI時代に有利	AI時代に不利
BigQuery / Snowflake（主流・学習データ豊富）	マイナーなDWH
dbt + データカタログ整備	ドキュメントなしの生SQL
スキーマ・命名が整っている	雑なCSV投入
データリネージュ（データの出所・加工経路の追跡）可視化	ブラックボックスのETL

データ基盤がAIエージェントに自己紹介できる状態を目指すのが新しい基準です。メタデータ・カタログ・リネージュが整っていれば、AIが自律的にデータを選んで分析できます。

AI時代のデータ基盤は、AIエージェントが触れる場所。説明可能・構造明示・主流技術で作ります。

よくある勘違い

• 最初からデータレイクを作らないと後悔する → 小規模では過剰。BigQuery等のDWH単体で数TBまで戦えます。データレイクは「非構造データが増えてから」
• DWHがあれば業務DBは要らない → 全く別物。業務DB（OLTP）は取引処理、DWHは分析。両方必要です
• 高価なBIツールを買えば分析が進む → ツールよりデータの整備度が重要。雑なデータに高級ツールを当てても何も出ません
• レイクハウスはDWHの上位互換だから全部置き換える → まだ発展途上。運用ノウハウが薄く、安定稼働しているDWHを無理に乗り換える必要はありません

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• 基盤の種類（DWH / データレイク / レイクハウス）
• クラウドベンダー（AWS / GCP / Azure / マルチ）
• BIツール（Tableau / Power BI / Metabase等）
• データ取り込み方法（ETL / ELT / ストリーミング）
• 保存期間とコスト階層（ホット / コールド / アーカイブ）
• 権限管理方式（Row-Level Security・IAM）
• ガバナンス体制（カタログ・リネージュ）

最終的な判断の仕方

データ基盤の核心は業務系と分析系の分離であり、業務DBに分析クエリを投げない規律を組織として持つことです。基盤がない状態では「部署ごとに同じ数字が違う」という全社課題が必ず発生し、BIも機械学習もAI活用も土台を欠いたまま進みません。規模が小さいうちはDWH単体で十分、非構造データが増えた段階でデータレイクを足し、運用ノウハウが育ってからレイクハウスに収束する、という段階的な判断が合理的です。

決定的な軸はAIエージェントがアクセスする基盤という視点です。LLMのRAGやText-to-SQLがデータ基盤に直接問い合わせる時代、主流DWH（BigQuery / Snowflake）とメタデータ・リネージュ整備が揃った基盤は、そのままAIの精度上限を押し上げます。マイナーなDWHやブラックボックスのETLは、AI時代にむしろ負債になります。

選定の優先順位

1. 業務系と分析系を分離 — 業務DBで分析を回さない、これが全ての出発点
2. 規模に合わせて段階的に — 小はBigQuery / Snowflake単体、大はレイクハウスへ段階移行
3. 既存クラウドに寄せる — 課金・IAM・運用の統合メリットを優先、マルチならSnowflake
4. カタログとリネージュを整備 — AIエージェントが自己紹介できる基盤を目指す

「既定はBigQueryかSnowflake」主流を選び、AI時代の読めるデータ基盤にします。

まとめ

本記事はデータ基盤について、DWH・データレイク・レイクハウスの3択・BIツール連携・規模別の段階表・データスワンプを避けるカタログ運用まで含めて解説しました。如何だったでしょうか。

業務系と分析系を分離し、規模に合わせて段階的に選び、既存クラウドに寄せ、カタログでAIエージェントが触れる基盤にする。これが2026年のデータ基盤の現実解です。

次回はETL・ELT（データの抽出・変換・ロードの仕組み）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。