データ基盤の設計レビューで、よく出る質問があります。「うちは Data Vault で作るべきですか、それともスタースキーマでよいのですか」。書籍や記事を読むほど、両者がどちらも正しく見えてきて、判断に詰まるところです。
Data Vault と スタースキーマは敵対する選択肢ではありません。役割が違うので、実務では両方を二段で使うのが現実解です。「どちらか」ではなく「どちらを、どの層で」で考えると、迷いが減ります。
両者の役割の違い
どちらが何のためのモデリングかを整理します。
| スタースキーマ | Data Vault 2.0 | |
|---|---|---|
| 主目的 | 分析クエリを速く・書きやすく | 履歴を残し、変化に追従して統合する |
| JOINの数 | 少ない（ファクト＋ディメンション） | 多い（Hub × Link × Satellite） |
| 履歴の扱い | SCDで都度設計 | Satelliteで標準装備 |
| 新属性の追加 | カラム追加と過去データの再設計 | 新しいSatelliteを足すだけ |
| BIからの直叩き | 向く | 重い（マートを別途用意） |
| 得意な層 | Gold（マート層） | Silver（統合層） |
スタースキーマは「整然と並べて読む」モデルです。Data Vaultは「漏れなく蓄えて統合する」モデルです。前者を上、後者を下に置くのが定石の組み合わせです。
判断軸：4つの問いで当たりをつける
選定で迷ったら、次の4つに答えてみてください。「はい」が多いほど、Data Vaultを採る価値が出ます。
| 問い | はいの場合 | 意味 |
|---|---|---|
| 1. ソースシステムは複数（基幹・CRM・ECなど）あるか | Data Vault寄り | 統合のためのHub・Linkが効く |
| 2. 業務側の項目変更が、半年に1回以上あるか | Data Vault寄り | 「足すだけ」の構造が活きる |
| 3. 変更履歴を厳密に残す必要があるか（監査・規制対応など） | Data Vault寄り | Satelliteで標準的に履歴を持つ |
| 4. 主な利用者は、SQLを書く分析者かBIツールか | スタースキーマ寄り | JOINを増やしたくない |
4つすべて「Data Vault寄り」なら、迷わず採用してよい場面です。1〜2個だけならスタースキーマで通せる規模かもしれません。0個ならData Vaultは過剰投資です。
二段構成のパターン：Silver は Vault、Gold はスター
実務で広まっているのが、メダリオンアーキテクチャと組み合わせた二段構成です。Silver層（統合）をData Vaultで作り、Gold層（マート）をスタースキーマやワイドテーブルで作る。両者の強みを並行して使えます。
| 層 | モデル | 役割 |
|---|---|---|
| Bronze | 生データ（ソース構造のまま） | 取り込み・保管 |
| Silver | Data Vault（Hub/Link/Satellite） | 履歴を持って統合 |
| Gold | スタースキーマ／ワイドテーブル | BIから速く読める形に配膳 |
メダリオンの考え方はメダリオンアーキテクチャの解説に、dbtでの層の作り方はdbt実装ガイドにまとめています。Vault と スターの組み合わせは、これらをベースに上下を分担して動かす形です。
既存のスタースキーマから、どう移行するか
既存のスタースキーマを全部Data Vaultに作り替えるのは、現実的ではありません。動いているものを止めるリスクが大きく、移行中の二重管理コストも重くのしかかります。
推奨は、次のような段階的アプローチです。
- ステップ1：変更が頻繁で履歴管理が課題になっている領域を1〜2業務だけ選ぶ（例：顧客マスタの統合、商品階層の変遷）
- ステップ2：その領域だけData Vaultで作り、既存のスタースキーマの隣に並走させる
- ステップ3：Gold層のマートは、新しいData VaultからもETLで作る。BIから見ると、変化は最小
- ステップ4：運用が回り、効果が見えたら、他の領域に広げる
この進め方なら、既存のBIや業務は止まりません。「いきなり全面置き換え」ではなく「変更に弱い領域から、薄く差し込む」のが、結果として最短距離になります。
Data Vaultが向かない場面
次のような場面では、Data Vaultは過剰投資になります。
- ソースが1つ、業務が安定していて、変更がほぼ発生しない
- 履歴の厳密保持が要件にない（最新値だけ見たい）
- チームに学習コストを払う余裕がなく、SQLが書ける人が少ない
- とにかく早く小さく作って、後で作り直す前提のPoC段階
これらに当てはまるなら、素直にスタースキーマで作るほうが結果が早く出ます。Data Vaultは「変化と統合の痛み」を解くための道具で、痛みのないところに入れても効果は出ません。
まとめ
- Data Vault と スタースキーマは目的が違う。役割を上下に分けて二段で使うのが定石。
- Silver層はData Vault、Gold層はスタースキーマ、という分担がメダリオンと相性がよい。
- 選定は「ソースの数・変更頻度・履歴要件・主な利用者」の4軸で当たりがつく。
- 移行は、変更に弱い1〜2領域からの並走スタートが安全。
Data Vaultの全体像はData Vault 2.0 入門、具体的なモデリング手順はモデリング手順、Snowflakeでの実装はData Vault on Snowflakeにまとめています。判断に迷うときは、DE-STKの初回相談（30分・無料）を壁打ち相手にお使いください。
よくある質問（FAQ）
Q. SCD Type 2をスタースキーマで使えば、Data Vaultは要らないのでは？
A. 一部の履歴管理はSCD Type 2でも可能です。ただし、ソースが複数あって統合が必要な場面、属性の追加が頻繁な場面、機密度ごとに分けて履歴を持ちたい場面では、SCD Type 2は手作業が増えて運用が破綻しがちです。Data VaultはSatelliteで履歴管理が標準化されているので、こうした複雑な要件にスケールします。
Q. Data VaultのSilverを作ると、Goldのマートはなくせますか？
A. なくせません。Data Vaultは履歴と統合の元として強いですが、JOINが多くBIから直叩きすると重くなります。Goldのマートは、BIや分析者が読みやすい形に「配膳」する層です。Vault側を作っても、用途別のマートは別途用意するのが基本です。SilverとGoldの役割分担は捨てない、と覚えてください。
Q. 中小規模のチームでも導入できますか？
A. 規模よりも「変更と統合の痛み」があるかで判断してください。小規模でもソースが複数あって履歴を残したい場面なら、Data Vaultは効きます。逆に、規模が大きくてもソース1本で安定運用なら、スタースキーマで十分です。導入の現実的な進め方は、変更に弱い1領域だけで試し、運用感を確かめてから広げる、です。
Q. Data Vaultで作ると、開発速度は落ちませんか？
A. 最初の学習期間は落ちます。Hub・Link・Satelliteの設計判断に慣れが要るからです。ただし運用フェーズに入ると、属性追加や履歴管理が「足すだけ」で済むため、変更コストが下がります。トータルでは、変更が多い領域ほど開発生産性が逆転します。学習投資を一度払うか、変更ごとに痛みを払い続けるか、という選択になります。