1. はじめに
最近、仕事でMicrosoft Fabricを本格的に触り始めました。
キャッチアップのためにMicrosoft Learnや各種ドキュメントを読むことが多いのですが、Fabricのデータ基盤設計として頻繁に登場するのが「メダリオン・アーキテクチャ」です。
Bronze・Silver・Goldの3層でデータを管理し、段階的に品質を高めていく考え方は非常に分かりやすく、学習段階では「まずはこの構成を覚えよう」と考えていました。
しかし、実際の案件でデータを扱う中で、次第にある疑問を持つようになりました。
本当に毎回3層必要なのだろうか？
実際には、すでに十分に構造化されたデータを扱うケースも多く、必ずしも大規模なクレンジングや標準化が必要とは限りません。
そのため、メダリオン・アーキテクチャをそのまま適用すると、かえってレイヤーが増え、運用が複雑になることもあります。
この記事では、Fabric を実際に触る中で感じたこの疑問について、メダリオン・アーキテクチャの目的を整理しながら、実務でどのように考えるべきかという私なりの見解をまとめます。
2. そもそもメダリオン・アーキテクチャとは何か
本題に入る前に、まず前提を整理しておきます。
メダリオン・アーキテクチャは、データを段階的に精製しながら管理するためのレイクハウス設計パターンです。
一般的には以下の3層で構成されます。
| レイヤー | 役割 | 主な処理 | 主な利用者 |
|---|---|---|---|
| ブロンズ（Raw） | 生データをそのまま保持 | 検証・加工せず、到着したまま格納。取り込み日時などメタデータのみ付与 | データエンジニア・監査 |
| シルバー（Enriched） | クレンジング・検証・統合 | 型変換、NULL処理、重複排除、表記ゆれ補正、マスタ結合 | エンジニア・データサイエンティスト |
| ゴールド（Curated） | ビジネス活用・可視化 | KPI集計、スタースキーマ、ダッシュボード用マート | BI開発者・業務部門 |
それぞれを一言で表現すると、
- ブロンズ は「そのまま入れる」層。後からロジックのミスが見つかっても、原本が残っていれば作り直せる“データの保険”です。
- シルバー は「きれいに整える」層。生データではなく、検証・統合済みの“エンタープライズビュー”を提供します。
-
ゴールド は「見せる・使う」層。スタースキーマなど読み取りに最適化された、消費に近いデータマートです。
メダリオン・アーキテクチャの目的は、データを加工することそのものではなく、データの役割や用途を分離しながら品質を高めていくことにあります。
3. 私の結論：実務では必ずしも3つの物理レイヤーが必要とは限らない
結論から言うと、私は アーキテクチャを必ず3層で構成する必要はない と考えています。
重要なのは Bronze・Silver・Gold という形を守ることではなく、データの役割や目的を適切に分離すること です。
実際のプロジェクトでは、
- 2層になることもある
- 3層になることもある
- 4層以上になることもある
でしょう。本来考えるべき順序は、次のようなはずです。
必要な役割を整理する
↓
必要な境界を決める
↓
結果として層数が決まる
つまり、
3層は目的ではなく手段である
ということです。なぜそう考えるのか、その理由を順に説明します。
3-1. 層を分けることには、メリットとコストの両方がある
レイヤーを分けることには、明確なメリットがあります。
レイヤーを分けることで得られるもの
- データの品質を段階的に管理できる
- 各処理の責任範囲を明確にできる
- 共通の変換ロジックを再利用できる
- 問題が発生した箇所を特定しやすくなる
- データへのアクセスを段階ごとに制御できる
- ガバナンスや監査に対応しやすくなる
- 複数の分析用途にデータを展開しやすくなる
例えば、Bronze に元データを残しておけば、Silver や Gold の変換処理に誤りがあった場合でも、元データから再処理できます。また、Silver でデータの標準化や統合を行っておけば、複数の Gold やレポートから同じ処理結果を再利用できます。
このように、レイヤーを適切に分けることで、データの 信頼性・再利用性・保守性 を高めることができます。
一方で、レイヤーは無料ではありません。
レイヤーを増やすことで発生するコスト
- 開発対象の増加
- パイプラインや変換処理の増加
- 運用・監視対象の増加
- 障害が発生するポイントの増加
- ストレージ使用量の増加
- 計算リソースの消費
- アクセス権管理の複雑化
- データの依存関係を追跡する負荷
Fabric で物理レイヤーを増やす場合、レイヤー間のデータ更新や変換を実行するために、Notebook、Dataflow Gen2、Data Pipelineなどの処理が必要になることがあります。例えば、次のような構成です。
データソース
↓
Bronze
↓
Silver
↓
Gold
↓
セマンティックモデル
↓
Power BIレポート
この構成では、それぞれの責任を明確に分けられる一方で、更新処理や依存関係も増えていきます。もし Silver が複数段階に分かれていたり、Gold が部門や利用目的ごとに複数存在していたりすれば、その依存関係はさらに複雑になります。
その結果、
- 「このデータはどこで加工されたのか」
- 「どの処理でエラーが発生したのか」
- 「上流の変更がどこまで影響するのか」
を追跡する負荷も大きくなります。
もちろん、レイヤーが増えること自体が問題なのではありません。必要な役割を分離した結果としてレイヤーが増えるのであれば、そこには意味があります。問題なのは、
明確な役割や目的がないまま、「メダリオン・アーキテクチャだから」という理由だけでレイヤーを増やすこと
です。
物理レイヤーを追加する場合には、少なくとも次の問いに答えられる必要があると考えます。
- このレイヤーは何を保証するのか
- 前後のレイヤーと何が違うのか
- どの処理やデータを再利用するために存在するのか
- このレイヤーを省略すると、どのような問題が起きるのか
- 追加される開発・運用コストに見合う価値があるのか
つまり、層が多いほど優れたアーキテクチャになるわけではありません。 重要なのは層の数ではなく、それぞれの層が担う責任と、独立させる理由が明確になっていることです。
さいごに
ここまで見てきたように、実際のプロジェクトでは次のような構成が考えられます。
- Silver を独立して保持せず、2層に見える構成
- Bronze・Silver・Gold を分離した3層構成
- Silver などを複数段階に分けた4層以上の構成
重要なのは、見かけ上の層数ではありません。そのレイヤーがなぜ存在するのかを説明できること です。
レイヤーを設計する際は、次の観点を整理する必要があります。
- 何を入力として受け取るのか
- どのような処理を行うのか
- どの品質を保証するのか
- 誰が利用するのか
- どこから再利用されるのか
- なぜ独立して保持する必要があるのか
メダリオン・アーキテクチャの本質は、Bronze・Silver・Gold という名前や層数ではなく、データの役割と責任を適切に分離することにある と私は考えています。
- Bronze では、元データと再処理可能性を担保する
- Silver では、品質・標準化・統合・再利用性を担保する
- Gold では、特定の分析や業務利用に適した形を提供する
これらの責任を整理したうえで、どこを独立した物理レイヤーとして保持するかを判断する。その結果として、プロジェクトに必要な層数が決まります。
3層にすることから設計を始めるのではなく、必要な役割を整理した結果として3層になる。
これが、現時点で私が Fabric を触りながらたどり着いた結論です。