フレームワーク活用ガイドひとことで言うと#
データを**Bronze（生データ）→ Silver（クレンジング済み）→ Gold（ビジネスで使える形）**の3層に分けて段階的に品質を上げていくデータレイクハウスの設計パターン。Databricksが提唱し、データ基盤設計のデファクトになりつつある。
押さえておきたい用語#
- Bronze層
- ソースシステムから取り込んだ生データをそのまま保存する層。加工せず、取り込み日時だけ付与する。障害時の再処理に備えた「データの原本」にあたる。
- Silver層
- Bronzeのデータをクレンジング・型変換・重複排除した分析可能な状態のデータ層を指す。ビジネスロジックはまだ適用しない。
- Gold層
- Silverのデータにビジネスロジック（集計、KPI算出、ディメンション結合）を適用した意思決定に使える層。BIツールやMLモデルの入力になる。
- データレイクハウス
- データレイク（大量の生データ保存）とデータウェアハウス（構造化された分析基盤）の良いとこ取りをしたアーキテクチャである。
メダリオンアーキテクチャの全体像#
こんな悩みに効く#
- データレイクに生データを溜めているが構造がカオスで使い物にならない
- BIダッシュボードの数字が部門ごとに食い違う
- ETLパイプラインが複雑化してメンテナンスが困難
基本の使い方#
ソースシステムのデータを加工せずに保存する。
- 原則: 元データの構造を変えない。カラム追加は取り込み日時（_ingested_at）のみ
- 形式: ParquetやDelta形式で保存（列指向で圧縮効率が高い）
- 保持期間: 原本として長期保存。障害時の再処理に備える
- Bronzeは「何が入ってきたか」の記録。ここで加工してしまうと後から原因追跡ができなくなる
Bronzeのデータを分析可能な状態に整える。
- 型変換: 文字列の日付をDATE型に、数値文字列をINT/FLOATに
- 欠損処理: NULLの扱いルールを統一（削除 or 補完 or フラグ付与）
- 重複排除: 主キーベースでのデデュプリケーション
- 正規化: テーブルの正規化、カラム名の統一（snake_caseなど）
- ビジネスロジック（「売上＝単価×数量」など）はまだ適用しない
Silverのデータにビジネスロジックを適用し、BIやMLの入力として使える形にする。
- ファクトテーブル: 日次売上、月次KPI、イベントログ集計
- ディメンションテーブル: 顧客マスタ、商品マスタ、地域マスタ
- 利用者ごとのビュー: マーケ用、営業用、経営用にテーブルを分ける
- Gold層はdbtのモデルとして管理し、テスト（not_null、unique、accepted_values）を設定する
具体例#
年商30億円のEC企業。S3にCSVやJSONが雑多に溜まっており、分析のたびにデータエンジニアが手動で加工していた。ダッシュボードの数字が担当者ごとに異なるのが慢性的な問題だった。
メダリオンアーキテクチャをDatabricks上に構築。
| 層 | 内容 | テーブル数 |
|---|---|---|
| Bronze | S3の生ファイルをそのまま取り込み | 28テーブル |
| Silver | 型変換、重複排除、NULL処理 | 22テーブル |
| Gold | 日次売上、顧客LTV、在庫KPIなど | 15テーブル |
ダッシュボードの数値はすべてGold層から参照する運用に統一。以前は分析依頼から結果提供まで平均 5営業日 かかっていたが、Gold層にテーブルが整備されたことで 半日 で対応可能に。部門間の数字の食い違いもゼロになった。
従業員80名のBtoB SaaS。BigQueryにデータを集約していたが、変換ロジックがクエリに散在し、誰がどのテーブルを使っているか把握できなかった。
dbtを導入し、メダリオンアーキテクチャに沿ってモデルを整理。
- stg_（Bronze相当）: ソースからの初期取り込み。schema.ymlでソース定義
- int_（Silver相当）: 型変換、正規化、ビジネスキーの統一
- mart_（Gold相当）: KPIテーブル、部門別マート
dbtのテストを各層に設定し、Silver→Goldの変換でnot_null、unique、accepted_valuesをチェック。テスト違反があればSlackに自動通知される仕組みを構築。データ品質の問題検知までの平均時間が 3日 → 2時間 に短縮された。
自動車部品メーカー（従業員600名）。工場のIoTセンサーから日次 200万レコード のデータが生成されるが、分析チームが使えるデータになるまでに手動の前処理が毎週10時間かかっていた。
| 層 | 処理内容 | 更新頻度 |
|---|---|---|
| Bronze | センサー生データをそのまま取り込み（JSON） | リアルタイム |
| Silver | 異常値フィルタ、タイムスタンプ正規化、センサーID紐づけ | 1時間ごと |
| Gold | ライン別稼働率、不良品率、エネルギー消費KPI | 日次 |
Bronze層にリアルタイムで取り込むことで、異常検知は1時間以内に可能に。以前は「先週のデータを今週分析する」状態だった。Gold層のKPIダッシュボードは工場長が毎朝確認し、前日の稼働率低下の原因をSilver層まで遡って調査する運用が定着。手動前処理の 週10時間が完全に不要 になった。
やりがちな失敗パターン#
- Bronze層で加工してしまう — 取り込み時にカラムを削ったり型変換したりすると、ソースデータの原本が失われる。Bronze層は「何も触らない」が原則
- Silver層とGold層の責務が曖昧 — Silver層にビジネスロジックが混入すると、ロジック変更時にSilverまで影響が及ぶ。Silver層は「データの物理的な品質向上」、Gold層は「ビジネスロジックの適用」と明確に分ける
- Gold層のテーブルが増殖する — 部門ごとに独自のGoldテーブルを乱造すると、同じ指標の定義が複数存在する状態に逆戻りする。Gold層のテーブルはデータチームが一元管理する
- 品質テストを入れない — 3層に分けただけでは品質は保証されない。各層の境界にデータテスト（not_null、unique、期待レコード数など）を設定し、自動チェックする
まとめ#
メダリオンアーキテクチャは、データをBronze→Silver→Goldの3層に分けて段階的に品質を上げていく設計パターン。原本を保持したまま加工できるため再処理性が高く、各層の責務が明確なのでメンテナンスしやすい。データ基盤を「溜める」から「使える」に変えるための、現代的なデータアーキテクチャの基本形になっている。