「データ基盤を組みたい」けど何を入れればいいか分からない
経営層が「データドリブンな経営を」と言い、現場が「何を入れればいいんですか？」となる。 ベンダー名を 30 個並べた比較記事を読んでも、自分の会社にとって何を選ぶべきか、結局分からない。 これが多くの会社の現状です。
結論を先に書きます。 2026 年のデータ基盤は「役割で 4 つの層」に分解できます。 各層に必要なのは 1 つだけ。10 個のツールを並べる必要はありません。
そして、AI 分析エージェントを乗せる時代になり、 この 4 層の上に「+ 2 つの層」が必要になりました。 詳細は後半で書きます。
2026 年のデータ基盤は 4 層に分解できる
どんな規模の会社でも、データ基盤は次の 4 つの役割に分かれます。 各層が 「何をする場所か」を覚えれば、ツール選びは一気に楽になります。
重要なのは、4 層のうち 1 つでも欠けていると、データドリブンは成立しないということ。 「BI ツールを買ったから OK」「DWH を立てたから OK」ではなく、4 層が揃って初めて意思決定が回ります。
①取込 — 散らばっているデータを 1 箇所に集める
役割
Shopify、GA4、業務システム、広告プラットフォーム、Excel など、 バラバラに置かれているデータを定期的に 1 箇所に運ぶ。 毎日決まった時間に「Shopify の昨日分の注文を BigQuery に書き込む」ような自動化です。
代表ツール
- Fivetran：最も普及。多くのコネクタが完成度高い。料金は処理量に応じた従量課金
- Airbyte：OSS 版が無料。Self-hosted で運用するなら大規模ほど効く
- Hevo：処理レコード数課金。レコード量が予測できれば計算しやすい
- Stitch：シンプルでレガシー価格帯。中小規模向け
選び方
年商 1〜30 億の D2C なら、「アクティブ顧客数で月額が爆発しない」選択を最初にする。 Fivetran の MAR（Monthly Active Rows）課金は、EC が成長すると線形に高くなるので注意。 詳細はShopify ETL ツールの選び方に書きました。
②蓄積 — 集めたデータを置く場所
役割
集まってきたデータを、SQL で扱える形で保管する場所。 「データウェアハウス（DWH）」と呼ばれます。 数 TB〜数百 TB の規模を高速にスキャンする専用設計になっています。
代表ツール
- BigQuery（Google Cloud）：従量課金、初期投資ほぼゼロ。 日本の中小規模で最も普及している
- Snowflake：マルチクラウド対応、企業ガバナンス機能が強い。中〜大規模向け
- Databricks：データサイエンス・機械学習との統合が強い
- Redshift（AWS）：すでに AWS 全面使用なら自然な選択
選び方
30〜200 名規模なら、ほぼ BigQuery 一択でいいです。 理由：従量課金で初期投資が小さく、無料枠もある（月 1TB のクエリ実行が無料）。 GA4 や Google Ads のデータが標準で連携できる。 運用コストが軽い（管理者ゼロでも動く）。
中規模で複数チームが使い分ける、ガバナンスを厳密にしたい場合は Snowflake。
③整形 — 業務で使える形に整える
役割
取り込んだ生データを、「業務で使えるテーブル」に整える。 顧客テーブル、注文テーブル、月次売上テーブル、コホートテーブルなど、 使いやすい粒度に再構成します。
なぜ必要か：取り込んだ生データは「Shopify 側のテーブル構造そのまま」だから。 ユーザー単位、月次単位、コホート単位の集計には毎回ゼロから組み直す必要があり、 業務に直接使うには使いにくい。
代表ツール
- dbt：圧倒的標準。SQL で整形ロジックを書き、Git でバージョン管理
- SQLMesh：dbt の競合。スキーマ進化、ステート管理に強み
- Dataform：BigQuery にビルトイン、追加費用ゼロ
整形の典型的な階層（dbt 標準パターン）
- staging：生データを軽く正規化（カラム名統一、型変換）
- intermediate：複数の staging を結合した中間テーブル
- marts：業務で直接使うテーブル（コホート LTV、月次売上、ユーザーマート）
整形を飛ばして「BI ツールから生データを直接見る」と、毎回フルスキャンが走るためコストが跳ねます。 整形でテーブルを作っておけば、BI 側のクエリは軽く済みます。
④表示 — データを使う側に届ける
役割
整った数値を、人の判断につなげる場所。 ダッシュボード、レポート、メール通知、Slack 通知などが該当します。
代表ツール
- Looker Studio（Google）：無料、BigQuery と直接連携。中小規模で最も普及
- Tableau：自由度が高く、複雑な可視化向き。中〜大規模
- Power BI：Microsoft 365 環境が中心の組織で自然な選択
- Looker（Google）：Semantic Layer 内蔵、組織横断のデータ定義統一向き
- Metabase：OSS で無料、シンプルなダッシュボード用途
- Hex / Mode：分析ノートブック型、データ分析者向け
- Slack 常駐 AI 分析エージェント：BI ツールに来ない役員向け
選び方の現実
表示層の選択は、「ユーザーが普段どこで仕事しているか」で決めるのが現実的です。
- 普段 Slack を見ているユーザー → Slack 常駐 AI
- 普段 Excel を使っているユーザー → Excel に出力する仕組み
- 分析職がいる → Looker / Tableau / Hex
- 「全社にどこかひとつ統一」が目標 → Looker（高価）
ダッシュボードを「自分で開きに行く習慣」がない人には、何を作っても届きません。 BI ダッシュボードと Slack 通知 / 常駐 AI を組み合わせるのが、 全社浸透を現実的に達成する組み合わせです。
規模別の組み方 — 小・中・大の標準形
小（30〜200 名規模、データ専任 0〜1 名）
- ① 取込：Fivetran（無料枠 / 安いプラン）または Airbyte Cloud
- ② 蓄積：BigQuery（従量課金、初期投資ほぼゼロ）
- ③ 整形：dbt Core（OSS、無料）
- ④ 表示：Looker Studio（無料）+ Slack 常駐 AI 分析エージェント
月額コストは 5 万〜 30 万円程度に収まります。 大手 SI が見積もる「数千万円のデータ基盤」とは別世界の話で、 このパターンが今は 30〜200 名規模の標準形です。
中（200〜1000 名規模、データチーム 2〜5 名）
- ① 取込：Fivetran（有償プラン）
- ② 蓄積：BigQuery / Snowflake
- ③ 整形：dbt Cloud（チーム機能、CI/CD）
- ④ 表示：Tableau / Looker / Hex + Slack AI 分析エージェント
月額 100 万〜 300 万円程度。データチームの管理コストが乗ってきます。
大（1000 名以上、データ組織 10 名以上）
ここからは、個別最適より組織別のガバナンスが主題になります。 複数の DWH の統合、データのオーナーシップ、業務契約に基づくスキーマ管理、 データカタログ、データオブザーバビリティなど、人月とプロセスで解く領域に入る。 ツール選定の話はあまり意味がなく、「誰が責任を持つか」の組織設計が本題です。
AI 時代に追加で必要になった「+ 2 つの層」
2024 年以降、AI が SQL を書いて分析を返す体験が普通になりました。 ただ、上の 4 層だけでは AI を本番に乗せられません。 直近 1 年、500 名規模で AI 分析エージェントを運用してきましたが、追加で 2 つの層が必要でした。
⑤ 業務語彙の置き場
「応募率」「LTV」「セグメント」のようなビジネス語彙の定義を、 AI が読める形で外在化する場所。具体的に作るもの：
- ビジネスオントロジー：業務概念の階層（応募 ⊃ チャネル別応募 ⊃ Email 応募）と同義語
- 業務ルール辞書：「特定キャンペーンは LTV から除外」のような暗黙ルールを構造化記述
- 分析パターンのお手本集（Golden Queries）：頻出分析パターンの SQL テンプレート
これがないと、AI は質問のたびに違う SQL を組み立てて、回答が毎回ブレます。
⑥ 評価ハーネスとガードレール
AI が返した SQL と回答を保持して、精度劣化を継続検出する仕組み。
- 評価ハーネス：過去の質問・SQL・回答の履歴。LLM 更新やデータ変更で精度が落ちていないか自動で検知
- 信頼度スコア：回答ごとの自信度を表示。低信頼の回答は明示する
- 引用：使った SQL、参照テーブル、計算前提を毎回出力する
この 2 層について詳しくは、AI Ready なデータ基盤の正体に書きました。 つまり 2026 年のデータ基盤は、 伝統的な 4 層 + AI 時代の 2 層で計 6 層と捉え直すのが現実的です。
運用で必ず効いてくる 4 つの仕組み
基盤を構築した後、運用で「あるとなしで違いが出る」仕組みを 4 つ。
① データ品質チェック
毎日のデータ取込が終わるごとに、「異常な数値が混入していないか」を自動でテスト。 dbt の test 機能、Great Expectations、Monte Carlo のようなツールで実装します。 検知した瞬間に Slack に通知する。
② コスト監視
BigQuery / Snowflake は従量課金なので、フルスキャンが走ると月の請求が跳ねます。 INFORMATION_SCHEMA から日次でクエリ統計を集計、上位コストクエリを Slack に流す。 ダッシュボードのフルスキャン依存を早期発見できます。
③ データカタログ
テーブル一覧、カラム定義、サンプル値、オーナー、業務語彙との紐付けを 1 箇所にまとめる。 200 テーブルを超えたら、カタログがないと「どのテーブルを見ればいいか」が分からなくなる。 Atlan、DataHub、Select Star、または Notion / GitHub README で代用可。
④ データ契約（Schema 安定性）
上流のシステム（Shopify、GA4、業務 DB）が「いつ何を変えるか」のルールを決めておく。 スキーマ変更がいつでも来る前提だと、毎月修正に追われる。 重要なソースは「変更時は事前通知」のような契約を結ぶ（社内システムなら開発チームと、 外部 SaaS なら API バージョンの追従ポリシーを決める）。
ツール選定の判断軸はシンプルでいい
ベンダー名を 30 個比較する記事を読むより、次の 3 問だけ自分に聞けば 80% 決まります。
- 従業員数は？ 30〜200 名なら「小」のパターン、それ以上なら「中」を出発点にする
- データ専任は何人いるか？ 0〜1 名なら、運用が軽いツールに寄せる（dbt Cloud より dbt Core、Snowflake より BigQuery）
- ユーザーは普段どこで仕事しているか？ Slack なら Slack 常駐 AI、Excel が中心なら Excel に出力、というように合わせる
これ以上の細かい比較は、運用 6 ヶ月後に必要になったら考えれば十分です。 最初から完璧を目指すと、構築が終わらないまま 1 年が過ぎます。
コスト感の現実 — 月額レンジの目安
実運用で見てきた、規模別のおおよその月額レンジ。
- 30〜100 名 / 年商 1〜10 億：月 5 万〜 15 万円 （Fivetran 最安プラン + BigQuery 従量 + dbt Core + Looker Studio）
- 100〜500 名 / 年商 10〜50 億：月 30 万〜 100 万円 （Fivetran 標準 + BigQuery + dbt Cloud + Tableau / Looker Studio + Slack 常駐 AI）
- 500〜1000 名 / 年商 50〜200 億：月 100 万〜 300 万円 （Fivetran 上位 + Snowflake / BigQuery + dbt Cloud + Tableau + AI 単機能 SaaS）
大手 SI が見積もる「初期構築 3,000 万円」のような世界とは、桁が違います。 中小規模なら、SI に頼らず標準形で組めば、半年で数億円かかる差は吸収できます。
よくある失敗 5 つ
- ツール選定に 3 ヶ月かける — 30 名規模なら、最初は標準形でいい。判断する前に動かす。 運用しながら必要なものを足す
- 大手 SI に 3,000 万円の見積もりを取る — 30〜200 名規模では、月額 5〜30 万円の標準形でほぼ事足りる。 SI が必要になるのは 1000 名超 + 複数 DWH 統合フェーズ
- 整形（③）を飛ばして、生データに AI / BI を直接当てる — 業務で使える粒度の整形がないと、何度作り直しても精度が出ない。 BI のクエリコストも跳ねる
- 表示（④）から決めてしまう — 「Tableau にしたい」が先にくると、データ整形の判断が歪む。 まず ①②③ を整えてから、表示は最後に決める
- 業務語彙の整備（⑤）を「あとで」と言って永遠にやらない — AI を入れた瞬間に問題が表面化するが、その時点では遅い。 BI 段階から定義を 1 箇所にまとめておく
まとめ
- データ基盤は 4 層（取込 / 蓄積 / 整形 / 表示）に分解できる。 各層に必要なのは 1 つだけ
- AI 時代は + 2 層（業務語彙 / 評価ハーネス）が必要。計 6 層
- 規模別の標準形がある。30〜200 名規模なら、月額 5〜30 万円で組める
- 選定は 3 問で 80% 決まる：人数 / データ専任 / ユーザーが普段使う場所
- 運用では、データ品質チェック / コスト監視 / カタログ / 契約 の 4 つを実装する
- 最初から完璧を目指さない。動かしてから足りないものを足す