データの集め方と更新：ETL・DWH・データモデルの基本｜BIとダッシュボード設計 第3回

ETLとDWH

型Cで使う2つの言葉を整理しておきます。

ETLは、Extract（取り出す）、Transform（整える）、Load（入れる）の頭文字です。各ツールからデータを取り出し、形や定義を整え、DWHに入れる作業を、自動で定期的に行うための仕組みやツールを指します。最近は、先にDWHに入れてからDWHの中で整える「ELT」という順番もよく使われます。

DWH（データウェアハウス）は、分析のためにさまざまなデータをためておく「倉庫」です。広告、GA4、CRM、販売管理などのデータを1か所に集めておくことで、ツールをまたいだ計算ができるようになります。代表的なサービスに、Google の BigQuery、Snowflake、Amazon Redshift などがあります。

ETLやDWHの具体的なツールについては、ETLツールおすすめ比較とDWHおすすめ比較で、導入の例はETLツールの成功事例とDWHの成功事例で紹介しています。顧客データに絞ってためる仕組み（CDP）との違いは、顧客データ活用とCDP 第2回で整理しています。

データモデル：明細とマスタをIDでつなぐ

複数のデータをつないで計算するには、データの「つなぎ方」を決めておく必要があります。この設計を「データモデル」と呼びます。分析向けのデータモデルとしてよく使われるのが、「スター型（スタースキーマ）」です。

スター型では、データを2種類の表に分けます。

• ファクト（明細）の表：注文、訪問、広告の配信など、出来事の記録。金額や数量など、合計や平均を計算する数字が入る
• ディメンション（マスタ）の表：顧客、商品、日付、流入元など、「切り口」になる情報。顧客の地域、商品のカテゴリ、日付の曜日など

真ん中の明細の表を、まわりのマスタの表がIDで囲む形が星のように見えることから、スター型と呼ばれます。Microsoftのドキュメントでも、分析のための問い合わせに適した設計として、DWHでの利用が推奨されています。

この形にしておくと、「商品カテゴリ別の売上」「地域別・月別の新規客数」のような集計が、マスタの項目を切り替えるだけでできるようになります。姉妹編の「データ分析・統計入門」第9回で学んだ「1行＝1件の明細データ」と「切り口になる列」の考え方を、複数の表に広げたものと考えると分かりやすいでしょう。

つなぐ前に「粒度」をそろえる

データをつなぐときに、いちばんつまずきやすいのが「粒度」の違いです。粒度とは、1行が何を表しているかという細かさのことです。

A社の例では、広告管理画面のデータは「1日の1キャンペーン」が1行、GA4は「1日の1流入元」が1行、注文データは「注文1件」が1行でした。このまま並べても、そのままでは計算できません。そこで、

1. 共通の粒度を決める（例：「日×チャネル」）
2. それぞれのデータを、その粒度に集計する（キャンペーンをチャネルにまとめる、注文を日・チャネルごとに合計する）
3. チャネル名の対応表を作る（広告の「Search_Brand」とGA4の「Paid Search」を同じ「検索広告」にそろえる）

という手順で、「チャネル別の広告費・訪問・売上」を1つの表にします。この作業が、ETL（またはELT）の「整える」にあたります。

よくある誤解：「つなげば数字は合う」

広告管理画面のコンバージョン数とGA4のキーイベント数、カートの注文数は、同じ「購入」を数えていても、たいてい一致しません。数え方（いつの購入をどの広告の成果とするか）、計測の仕組み（Cookieの同意、ブラウザの制限）、タイミング（集計の時刻、タイムゾーン）が違うからです。ダッシュボードでは「売上は注文データ、広告の成果は広告管理画面」のように、指標ごとに正とするデータ元を決め、第2回の定義書に書いておきましょう。

この記事の監修者に相談できます

監修者の田中磨生が代表を務める株式会社Abinで、ご相談をお受けしています。

相談無料ツギノテ編集部に相談する→

更新の頻度と方式

データを集める仕組みができたら、「どれくらいの頻度で新しくするか」を決めます。

更新の頻度は「その数字を見て判断する頻度」に合わせるのが基本です。経営会議で月に1回見る数字を、1時間ごとに更新する必要はありません。多くのマーケティングのダッシュボードは、毎朝前日までの数字に更新されれば十分です。頻度を上げるほど、ツールの費用、データ元への負荷、ツールごとの更新回数の制限に当たりやすくなります。

ツールによって、更新の仕組みには違いがあります。たとえば次のとおりです（2026年11月時点）。

• Google の Data Studio（旧 Looker Studio）：データ元ごとに「データの更新頻度」が決まっており、公式ドキュメントでは、Google アナリティクスは既定で12時間ごと（1時間・4時間ごとにも変更可能）、Google スプレッドシートは既定で15分ごと、Google 広告は12時間ごと（変更不可）と説明されています。編集者は手動でいつでも更新できます。
• Microsoft の Power BI：データをBIの中に取り込む「インポート」方式と、表示のたびにデータ元に問い合わせる「DirectQuery」方式があります。公式ドキュメントでは、インポートを基本とし、データの新しさや量、管理上の要件で必要な場合にDirectQueryを選ぶよう案内されています。インポートの定期更新は、Proライセンスで1日8回まで、Premium・PPUで1日48回までとされています。

ダッシュボードの隅には、必ず「最終更新：2026/11/12 06:00」のように、いつ時点のデータかを表示しておきましょう。「今日の数字が出ていない」という問い合わせの多くは、これで解決します。

自動の仕組みは「止まる」前提で見張る

データの取り込みを自動にすると、手作業のミスはなくなりますが、代わりに「気づかないうちに止まる」という問題が起きます。広告管理画面の接続の認証が切れた、元のスプレッドシートの列名が変わった、GA4の設定が変わってイベント名が変わった、などが典型です。次のような簡単な点検を仕組みに入れておくと安心です。

• 前日のデータ件数が0件、または前週の同じ曜日より極端に少なければ、担当者に通知する
• 主要な指標の合計を、元のツールの管理画面の数字と月に1回突き合わせる
• 列名やイベント名を変えるときは、BIの担当者に事前に知らせるルールを作る

実務ではこう使う：データの流れ図を1枚描く

BIの仕組みを作るときは、次のような「データの流れ図」を1枚にまとめておくと、トラブルのときに原因を探しやすくなり、担当者が変わっても引き継げます。

この回のまとめ

• データの集め方は、直接つなぐ・スプレッドシート経由・ETL→DWH→BIの3つ。必要な指標に合わせて選び、段階的に移る。
• ETLはデータを取り出し・整え・入れる仕組み。DWHはデータをためてつなげる倉庫。
• 分析向けのデータモデルは、明細（ファクト）とマスタ（ディメンション）をIDでつなぐスター型が基本。
• つなぐ前に粒度をそろえ、指標ごとに正とするデータ元を決める。
• 更新の頻度は判断の頻度に合わせ、画面には最終更新の日時を表示する。

確認テスト

次回予告

次回は、いよいよダッシュボードの「見せ方」を学びます。どこに何を置くか、色をどう使うか、どのグラフを選ぶか、数字をどう表示するか。ひと目で分かるダッシュボードの原則を、悪い例と良い例で比べながら紹介します。

参考資料

• Google Cloud「Data Studio：Manage data freshness」（確認日：2026年11月12日）https://docs.cloud.google.com/data-studio/manage-data-freshness
• Google Cloud Blog「Looker Studio is Data Studio」（2026年4月10日、確認日：2026年11月12日）https://cloud.google.com/blog/products/data-analytics/looker-studio-is-data-studio
• Microsoft Learn「DirectQuery in Power BI」（確認日：2026年11月12日）https://learn.microsoft.com/power-bi/connect-data/desktop-directquery-about
• Microsoft Learn「Dimensional modeling in Fabric Data Warehouse」（確認日：2026年11月12日）https://learn.microsoft.com/en-us/fabric/data-warehouse/dimensional-modeling-overview