データモデリング理論と実践

目的駆動のモデリング：意思決定に効く設計基準

ビジネス質問から逆算する

正しいモデルは「どの意思決定を早く・確信度高く下すか」から始まります。例として「獲得チャネル別の1人当たり粗利は改善しているか？」という問いを分解すると、必要なのはイベント（購入、返品）、属性（顧客、チャネル、商品）、指標（粗利、LTV）、そして時間粒度（週・月）です。先にKPI→イベント→粒度→ディメンションの順で確定し、余計な列や未定義の概念をモデルに持ち込まないことが、将来の整備コストを劇的に下げます。

粒度・時間軸・主キーの3点セット

事実テーブルは「1行＝1イベント（または1スナップショット）」の粒度を厳守します。主キーはソースの自然キーに加えサロゲートキーを採用し、遅延到着や再処理に耐えるようにします。時間は少なくともイベント発生時刻（event_time）と取り込み時刻（ingest_time）を持ち、集計はevent_time基準、鮮度監視はingest_time基準で行うのが実用的です。

命名とデータ契約

テーブル名は役割と粒度が分かるように「fact_orders」「dim_customer」のように統一します。スキーマには所有者、期待SLA、破壊的変更の予告期間、NULLの意味、論理削除の方針を含むデータ契約を付与します。初期作成やレビューにはChatGPTやClaudeで仕様ドラフトを起こし、CopilotでSQLの型・制約を補完、Geminiで列定義の説明文を自動生成すると、手戻りが減ります。

スター/ワイド/データボルトの使い分け

スタースキーマの適用基準

集計系BIの主戦場はスタースキーマです。事実（例：orders, sessions）とディメンション（customer, product, date, channel）を分離し、参照は常に多対一。フィルタの選択肢はディメンション側に寄せ、事実は数値と外部キーだけに絞ります。これによりジョイン計画が安定し、メジャーの再利用性が上がります。

データボルトで履歴担保

複数ソースのマージや履歴完全性が最優先なら、Raw層にData Vault（Hub/Link/Satellite）を採用し、整形層でスターに投影する構成が有効です。ハブでビジネスキーを固定化し、サテライトで属性履歴を保持すれば、後追いでソースが増えても破綻しません。

ワイドテーブルは最適化として限定

ダッシュボード専用のワイドテーブルは、特定の指標とフィルタに最適化した派生物として作ります。正規の「真実の源泉」はスター/ボルト側に置き、ワイドはTTLと系譜管理を明記してコスト暴走を防ぎます。

SCDと履歴、品質テストの実装

SCD Type1/Type2/Type4の選択指針

顧客属性の履歴は意思決定に直結します。誤記修正はType1（上書き）、時点再現が必要ならType2（有効期間列start_at/end_at）、定期スナップショットならType4（別テーブル）を使います。例えばキャンペーン効果やセグメント再現性を担保したいなら顧客・チャネルはType2、商品マスタはType1、在庫は月次Type4が扱いやすいです。

品質チェックと監視

最低限の自動テストは次の通りです。

• 一意性：事実の主キー、ディメンションのサロゲートキーがユニーク
• 参照整合：全外部キーが対応ディメンションに存在
• 欠損・範囲：主要数値のNULL率・マイナス値を閾値監視
• 鮮度：ingest_timeの最大値がSLA内

テストSQLの雛形やコメント生成はCopilotやChatGPTに任せ、設計意図の文章化はClaude、用語集の表現調整はGeminiを使うと運用速度が上がります。遅延到着イベントは「最大遅延許容ウィンドウ」を決めて再計算し、再処理はビジネスキー＋ハッシュで冪等化するのが安全です。

失敗から学ぶ：小売EC企業の改善ストーリー

小売ECは、初期に「orders_wide」一枚で分析を回していました。マーケ部門がLTVを見たいと列を継ぎ足し、CRMが属性を上書き、広告チームが初回流入チャネルを逐次上書きした結果、同じ顧客の指標が日によって変わる状態に。クエリは複雑化し、BIの集計時間は30分超、意思決定会議で数字が合わず失注も発生しました。

改善では、Raw層にData Vaultを導入し、ハブにcustomer_id/order_id、リンクでorder–campaign、サテライトで属性履歴を保持。整形層はfact_order/fact_payment/fact_refundと、dim_customer（Type2）、dim_campaign（Type2）、dim_product（Type1）、dim_dateを定義。KPIは「粗利、CVR、初回購入までの日数」を中核メジャーとして集約関数を共通化。ダッシュボード専用のsales_wideはSLA別に日次とリアルタイム版の2系統に限定しました。並行してデータ契約を策定し、チャネル判定ロジックをマケチームの所有に固定、破壊的変更は2週間前予告に。品質テストを追加し、遅延到着は7日間の再計算ウィンドウで吸収しました。設計ドキュメントはGeminiで初稿、レビュー論点整理はClaude、SQLテストの雛形はCopilotとChatGPTで作成。

結果、ダッシュボードの応答は平均3.2秒、クエリコストは35%削減、数字不一致のインシデントは月8件→1件に低下。初回流入チャネル別LTVの再現性が担保でき、入札戦略の見直しでROASが12%向上しました。

データモデリングは、集計速度や可観測性だけでなく、組織の「同じ数字を見る力」を育てます。データ解析プラットフォーム事業においては、収集・保管・変換・提供の各レイヤを貫く設計原則として機能し、信頼できる基盤上での分析・自動化・生成AI活用を安定させます。モデルが整っていれば、ツールやクラウドが変わっても意思決定はぶれません。