本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「データアーキテクチャ」カテゴリ第4弾として、データ基盤について解説する記事です。
貯めるだけの基盤は負債、引き出せる基盤は資産。本記事ではDWH／データレイク／レイクハウス3つの選択肢、BIツール連携、規模別の推奨構成、そして「貯める」が目的化した瞬間に基盤が「データスワンプ（沼）」になる構造を解説します。
本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
この記事の結論
- 規模に応じてDWH→レイクハウスと段階的に選ぶ（スタートアップは基盤を作らない）
- 既存クラウドのマネージドサービスに寄せる（マルチならSnowflake）
- データカタログを整備してデータスワンプ化を防ぐ
- クエリ課金はパーティション・列指定・キャッシュの3点で制御する
この記事を読む前に
本記事はデータベース周りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「データベースの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもデータ基盤とは何か
データ基盤とは、ざっくり言えば「全社のデータを集めて、誰でも分析・活用できる状態にするための土台」です。
図書館の蔵書システムを想像してください。各部署が本（データ）を個別に管理していると、他部署の本を読みたい時に存在すら分かりません。蔵書を一元管理し、検索できる仕組み（DWH）を作れば、誰でも目的の本を見つけられます。AI時代はこのデータ基盤がLLMやBIの「読み取り元」になるため、基盤の質がそのままAI活用の上限を決めます。
なぜデータ基盤が必要なのか
理由は3つあります。第一に、業務DBで「全データ集計」のような分析クエリを回すと業務側が遅くなるため、業務と分析の分離が事実上の標準であること。第二に、営業・マーケ・経理のデータを全社で繋ぐ集約基盤がないと部署ごとに同じ数字が違う問題が起きること。第三に、機械学習もLLMのRAGも「整ったデータ」があって初めて成立し、基盤が貧弱だとAI活用の上限が決まってしまうことです。
3つの選択肢
| 選択肢 | ざっくりした説明 |
|---|---|
| DWH | 構造化データの分析専用DB。整えて入れる |
| データレイク | 生データを形式問わず貯める巨大ストレージ |
| レイクハウス | 両者のいいとこ取り。レイクに直接SQLが当たる |
DWH ― 集計分析の主戦場
分析専用に最適化された列指向DBで、月次レポート・経営ダッシュボード・KPIモニタリングの主戦場です。現代は全てクラウドマネージドで、BigQuery・Snowflakeが二強（RedshiftはAWS縛りでない限り選ぶ理由が減少）。TB〜PB級でも秒単位で集計でき、SQLで誰でも扱えます。弱点は非構造データが入らないことと、ベンダーロックインの強さです。
データレイク ― 何でも入るが沼化に注意
CSV・JSON・画像・動画・ログ、形式を問わず生データを貯める巨大ストレージで、実体はS3等のオブジェクトストレージです。DWHが「整えてから入れる」のに対し、レイクは「入れてから整える」発想で、機械学習の前処理・非構造データ・監査ログ保管を担当します。ストレージコストは極めて安い反面、運用ルールなしで貯めるだけだとデータスワンプ（沼）化します。カタログ・命名規則の整備が必須です。
レイクハウス ― 新規構築の新しい第一候補
S3に置いたParquetファイルに直接SQLを当て、ACIDトランザクションもサポートする「いいとこ取り」の構成です。Databricksが提唱し、Delta Lake・Apache Icebergがデータ形式の標準として定着しつつあります。1基盤で構造化・非構造化の両用途をカバーできロックインも弱い反面、運用ノウハウがまだ発展途上で、小規模では過剰です。既にDWHで回っている組織が無理に乗り換える必要はありません。
BIツールとの連携
データ基盤を作っても、可視化ツール（BI）が無いと業務部門が使えません。機能最強で業界標準のTableau（大企業向け）、Microsoft 365利用企業ならPower BI、小〜中規模・エンジニア主体ならOSSのMetabase / Redashが定番です。業務部門が自分で触れるかどうかでBI浸透度が決まるため、非エンジニアが使えるUIを優先して選びます。
どう選べばいいのか ― 規模別の段階表
※ 2026年4月時点の業界相場値です。
データ基盤は「流行で選ぶ」と運用で破綻します。規模と月額コストを軸に段階的に選びます。
| 組織規模 | データ量 | 推奨基盤 | BIツール |
|---|---|---|---|
| 個人・MVP | 〜10GB | PostgreSQLのみ（基盤は作らない） | Metabase（無料） |
| スタートアップ | 〜1TB | BigQuery | Metabase / Looker Studio |
| 中規模SaaS | 〜10TB | BigQuery or Snowflake | Looker / Tableau |
| 大企業・多部署 | 〜100TB | Snowflake（マルチクラウド） | Tableau / Power BI |
| 超大規模・ML中心 | 100TB〜 | Databricks（レイクハウス） | 専用ダッシュボード |
クラウドベンダーとの整合も重要で、AWSならRedshift+S3、GCPならBigQuery、AzureならSynapse、と既存クラウドに合わせるのが運用・課金の両面で有利です。Snowflakeは唯一のマルチクラウドDWHとして、ロックインを避けたい企業に支持されています。
コスト面の注意点はクエリ課金の爆死パターンです。BigQueryで SELECT * を無制限に使うと月数十万円が一晩で到達する事例が定番で、パーティション必須・列指定必須・クエリキャッシュ活用の3点セットで制御します。Snowflakeも開発環境はXS固定・本番のみAuto-scaleが鉄板です。
3つのシナリオで考える
個人開発・スタートアップの場合
この段階では、そもそもデータ基盤を作らないのが正解だと私は考えています。10GB程度まではPostgreSQLに分析クエリを直接投げて、無料のMetabaseで可視化すれば十分事足りてしまいます。データが1TBに近づいてきたらBigQueryを足して、Looker Studioで無料のダッシュボードを作る、という流れで問題ありません。
中小SaaSの場合
BigQueryかSnowflakeを軸に、FivetranやAirbyteで同期してdbtで変換する、という組み合わせが現在の鉄板構成です。本番DBから日次〜時間次でELT同期して、OLTPとOLAPを分離します。ただし、クエリ課金で請求書が爆発する事故が本当によくあるので、パーティション必須・列指定必須・クエリキャッシュ活用の3つは最初からルール化しておくことをお勧めします。
大企業の場合
多部署で100TB規模まで見えているならSnowflake（唯一のマルチクラウドDWH）、機械学習が中心の超大規模ならDatabricks（レイクハウス）という選択になります。ここで気を付けたいのは、データカタログ（DataHubやCollibra）とガバナンス体制をセットで整備しないと、「貯めたのに誰も使えない」という沼に沈んでしまうことです。基盤より先に体制の方が大事だったりします。
AI判断軸 ― カタログ整備がAI活用の前提
主流DWHはAI生成SQLの精度が高い
BigQuery・Snowflakeは学習データに大量のSQLパターンが含まれるため、AI生成SQLの精度が安定します。マイナーなDWHでは方言SQLの精度が下がり手動修正が多発します。プラットフォーム選定時に「AIが書けるか」を評価軸に入れる時代です。
Text-to-SQLの前提はメタデータ整備
BigQuery・Snowflakeは自然言語クエリ機能の搭載を進めており、テーブルのメタデータ（カラム説明・テーブル間の関係）が整備されていれば、AIが正確なSQLを生成できる基盤が整います。この恩恵を受けるにはdbt docsレベルのメタデータ整備が前提条件で、カタログとリネージュの整備は「AIエージェントが自己紹介できる基盤」への投資です。
やってはいけないこと
「貯める」が目的化した瞬間、基盤はゴミ置き場になります。特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| スキーマも命名規則もなしでS3に貯め続ける | 3年後に誰も掘れない沼になる → カタログ・命名規則を最初に整える |
| DWHに画像・動画のバイナリを入れる | クエリ課金が月数百万になる → 非構造データはデータレイクへ |
BigQueryで SELECT * を無制限に使う | 月額が一晩で数十万円になる → 列指定+パーティションを必須にする |
| 業務DBで直接分析を回す | 業務側の性能劣化で顧客に影響する → DWHにETL/ELTで分離する |
| 個人情報をマスキングせずDWHへ投入 | GDPR違反。Meta 2023年の巨額制裁金と同じリスク → 規制要件を最初に確認する |
| dbtなしで手書きSQLが社内に散在 | 変換ロジックが属人化する → dbtでGit管理する |
筆者メモ ― 「貯めたのに誰も使えない」沼の事例
ある事業部では「いつか分析するから」と部署全員のログをS3に3年間貯め続けたものの、スキーマも命名規則もないJSONファイルが数億個積み上がった結果、誰も使えず沼化した、という話がしばしば聞かれます。日付フォーマットがファイルごとに違い、フィールド名がサービス改修のたびに揺れ、分析用の加工コストが新しくログ収集を設計するコストより高くなるという本末転倒に至ったと言います。
逆に「全部BigQueryに入れれば安心」と画像・動画のバイナリまでDWHに突っ込んだ結果、クエリ課金が月数百万円に膨れ上がった事例もあります。どちらも貯めること自体が目的化すると基盤ではなくゴミ置き場になる、という共通の教訓です。データ基盤は「貯める」ではなく「掘り出せる」が目的です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 基盤の種類（DWH / データレイク / レイクハウス）
- クラウドベンダー（既存クラウドに寄せるか / Snowflake）
- BIツール（Tableau / Power BI / Metabase等）
- データ取り込み方法（ETL / ELT / ストリーミング）
- 保存期間とコスト階層（ホット / コールド / アーカイブ）
- カタログ・リネージュ・権限管理の体制
この記事に関連する記事
まとめ
本記事はデータ基盤について、DWH・データレイク・レイクハウスの3択・BIツール連携・規模別の段階表・データスワンプを避けるカタログ運用まで含めて解説しました。如何だったでしょうか。
業務系と分析系を分離し、規模に合わせて段階的に選び、既存クラウドに寄せ、カタログでAIエージェントが触れる基盤にする。これが2026年のデータ基盤の現実解です。
次回はETL・ELT（データの抽出・変換・ロードの仕組み）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Amazon Redshift も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（48/95）