「データ基盤を組みたい」けど何を入れればいいか分からない
経営層が「データドリブンな経営を」と言い、現場が「何を入れればいいんですか？」となる。 ベンダー名を 30 個並べた比較記事を読んでも、自分の会社にとって何を選ぶべきか、結局分からない。 これが多くの会社の現状です。
結論を先に書きます。 2026 年のデータ基盤は「役割で 4 つの層」に分解できます。 各層に必要なのは 1 つだけ。10 個のツールを並べる必要はありません。
そして、AI 分析エージェントを乗せる時代になり、 この 4 層の上に「+ 2 つの層」が必要になりました。 詳細は後半で書きます。
構成を決めた後の要件定義、棚卸し、PoC、運用移管は、データ基盤構築の5ステップと成果物で工程別に解説しています。
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 と BigQuery の連携方法に書きました。
②蓄積 — 集めたデータを置く場所
役割
集まってきたデータを、SQL で扱える形で保管する場所。 「データウェアハウス（DWH）」と呼ばれます。 数 TB〜数百 TB の規模を高速にスキャンする専用設計になっています。
代表ツール
- BigQuery（Google Cloud）：サーバーレスで、保存量と分析量を中心に課金
- Snowflake：マルチクラウド対応、企業ガバナンス機能が強い。中〜大規模向け
- Databricks：データサイエンス・機械学習との統合が強い
- Redshift（AWS）：すでに AWS 全面使用なら自然な選択
選び方
30〜200 名規模でGoogle系サービスとの連携が多く、専任の基盤運用者が少ない場合は、BigQueryが有力候補です。 サーバー管理が不要で、GA4やGoogle Adsとの連携経路を作りやすいためです。 一方、AWSへの統一、複数クラウド、厳密なワークロード分離などが優先なら、 RedshiftやSnowflakeも同じ要件表で比較します。
中規模で複数チームが使い分ける、ガバナンスを厳密にしたい場合は 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 分析エージェント
費用はデータ量よりも、取込コネクタの課金単位、更新頻度、BIライセンス、 運用を内製するか委託するかで大きく変わります。 まず1業務の実測値から月額を見積もり、全社展開の前に上限アラートを設定します。
中（200〜1000 名規模、データチーム 2〜5 名）
- ① 取込：Fivetran（有償プラン）
- ② 蓄積：BigQuery / Snowflake
- ③ 整形：dbt Cloud（チーム機能、CI/CD）
- ④ 表示：Tableau / Looker / Hex + Slack AI 分析エージェント
この規模では製品費だけでなく、権限管理、品質保証、利用者支援を担うチームの工数も見積もります。
大（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 年が過ぎます。
コスト感の現実 — 月額レンジの目安
データ基盤の費用は従業員数だけでは決まりません。見積もりでは次の変数を分けます。
- 取込：コネクタ数、変更行数、API制限、更新頻度
- 蓄積・処理：保存量、スキャン量、予約容量、再処理の頻度
- 利用：BIライセンス数、同時実行数、AIの推論量
- 運用：監視、障害対応、定義変更、権限申請、利用者支援の人件費
各社の料金体系は変わるため、記事上の固定レンジを予算根拠にせず、 自社の直近30日分を使った小規模検証で月額を測るのが安全です。 クラウド料金だけでなく運用工数を含む総保有コストで比較します。
よくある失敗 5 つ
- ツール選定に 3 ヶ月かける — 30 名規模なら、最初は標準形でいい。判断する前に動かす。 運用しながら必要なものを足す
- 製品費だけで案を比較する — 内製・委託を問わず、監視、障害対応、定義変更、利用者支援まで含む 総保有コストで比較する
- 整形（③）を飛ばして、生データに AI / BI を直接当てる — 業務で使える粒度の整形がないと、何度作り直しても精度が出ない。 BI のクエリコストも跳ねる
- 表示（④）から決めてしまう — 「Tableau にしたい」が先にくると、データ整形の判断が歪む。 まず ①②③ を整えてから、表示は最後に決める
- 業務語彙の整備（⑤）を「あとで」と言って永遠にやらない — AI を入れた瞬間に問題が表面化するが、その時点では遅い。 BI 段階から定義を 1 箇所にまとめておく
参考にした一次情報
- Google Cloud Architecture Center: Enterprise data management and analytics platform — 取込、処理、ガバナンスを分離したレイヤー設計
- dbt Labs: How we structure our dbt projects — staging、intermediate、martsの責務分離
- Google Cloud: BigQuery pricing — 保存・分析料金と無料利用枠の最新条件
まとめ
- データ基盤は 4 層（取込 / 蓄積 / 整形 / 表示）に分解できる。 各層に必要なのは 1 つだけ
- AI 時代は + 2 層（業務語彙 / 評価ハーネス）が必要。計 6 層
- 規模別の出発点はあるが、費用はコネクタ、処理量、利用者、運用体制から実測する
- 選定は 3 問で 80% 決まる：人数 / データ専任 / ユーザーが普段使う場所
- 運用では、データ品質チェック / コスト監視 / カタログ / 契約 の 4 つを実装する
- 最初から完璧を目指さない。動かしてから足りないものを足す