メダリオンアーキテクチャとは、Databricksが提唱したデータレイクハウスの設計パターンで、Bronze（生データ）・Silver（クレンジング済み）・Gold（ビジネス用）の3層でデータ品質を段階的に高めていく考え方です。各層の設計指針とコード例、dbtの3層構造（Raw / Staging / Mart）との対応、そして層の境界を守る原則までを順に見ていきます。

メダリオンアーキテクチャとは

メダリオンアーキテクチャは、Databricksが自社のレイクハウス設計で広めた概念で、メダル（金銀銅）になぞらえた3層構造を特徴とします。Bronze層にソースの原形を格納し、Silver層でクレンジングと整形を行い、Gold層でビジネスロジックを適用します。この段階的な品質向上が基本の思想です。

発祥はDatabricksですが、概念自体はクラウドDWH（BigQuery、Snowflake）でも適用できます。dbtコミュニティの「3層構造（Raw / Staging / Mart）」と本質的に同じ思想であり、呼び方が違うだけと考えて差し支えありません。

実装基盤としては、DatabricksのDelta Lakeが参照実装として広く使われています。各層でACIDトランザクション、スキーマ進化、タイムトラベル（過去のデータ状態への遡及）が使えるため、「先週時点のデータで再分析したい」といった要件にも応えられます。オープンソースで組むなら、Apache IcebergとTrinoやDuckDBの組み合わせでも同等のアーキテクチャを実現できます。

Bronze層の設計

Bronze層の役割は「生データを忠実に保存すること」です。ソースシステムから受け取ったデータをそのままの形で保持し、将来の再処理や監査に備えます。変換・集計・結合は行いません。ここで気を付けるべきはスキーマ進化への対応で、Delta Lakeの場合はschema evolutionを有効化して後方互換性を確保します。

以下はDelta LakeでBronzeテーブルを作成する例です。

CREATE TABLE bronze.orders (
    id STRING,
    amount STRING,
    created_at STRING,
    _ingested_at TIMESTAMP,
    _source_file STRING
) USING DELTA
PARTITIONED BY (DATE(_ingested_at))
TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true');

Silver層の設計

Silver層はBronzeを受けて、クレンジング・正規化・ビジネスキーの付与を行います。型変換、NULLハンドリング、重複除去、軽いJOINによるエンリッチメントといった処理を施し、「整った元テーブル」を準備します。ここまで到達したデータは、分析利用者が安心して触れるベースラインになります。

ひとつ意識したいのは冪等性（何度実行しても同じ結果になること）です。dbtのインクリメンタルモデルとmerge戦略を組み合わせると、冪等性を保ちながら大量データを効率よく処理できます。BronzeからSilverへの変換例をSQLで示します。

CREATE OR REPLACE TABLE silver.orders AS
SELECT
    id AS order_id,
    CAST(amount AS DOUBLE) AS amount,
    CAST(created_at AS TIMESTAMP) AS created_at,
    _ingested_at
FROM bronze.orders
WHERE id IS NOT NULL
  AND amount IS NOT NULL;

Gold層の設計

Gold層は分析・BI・業務還流で利用する最終形です。ビジネスロジックの適用、KPI計算、ファクト／ディメンション構築、集計マートの作成など、ビジネス文脈に即したテーブルを用意します。「ビジネスの質問に直接答えるテーブル」を原則とし、汎用的すぎるワイドテーブルを避けると、クエリ性能と保守性を両立できます。ドメイン別にフォルダを分け、テーブル数が爆発しないよう統治することも大切です。

CREATE OR REPLACE TABLE gold.daily_sales AS
SELECT
    DATE(created_at) AS sale_date,
    COUNT(*) AS order_count,
    SUM(amount) AS total_amount,
    AVG(amount) AS avg_amount
FROM silver.orders
GROUP BY DATE(created_at);

全体像とdbt 3層構造との対応

メダリオンアーキテクチャ全体を俯瞰すると、単純な1本の直線ではありません。複数のソースがBronzeへ集約され、Silverで整えられたあと、用途別の複数のGoldマートへ枝分かれし、BI・機械学習・業務SaaSへと届きます。入口で集約し、出口で分岐するのが特徴です。

flowchart LR S1[“業務DB”] –> B[“Bronze（生データ）”] S2[“SaaS・API”] –> B S3[“イベントログ”] –> B B –> SV[“Silver（クレンジング・統合）”] SV –> G1[“Gold：売上マート”] SV –> G2[“Gold：顧客360”] SV –> G3[“Gold：KPI集計”] G1 –> BI[“BI・ダッシュボード”] G2 –> BI G2 –> ML[“機械学習・予測”] G2 –> RE[“Reverse ETL→業務SaaS”] G3 –> BI B -.->|障害時は再処理| SV

各層の設計ルールを表にまとめました。

観点BronzeSilverGold
データ品質保証なし型とNULLを整備ビジネス品質
変換内容なしクレンジング・軽JOIN集計・KPI・ロジック
アクセス制御限定的データチーム分析者・全社員
保持期間長期（再処理用）中期短〜中期（再計算可能）
テスト密度取り込み完了確認型・NULL・ユニークビジネスルール検証
更新頻度取り込みごと日次〜時次日次
ストレージ形式Delta LakeDelta LakeDelta Lake / 集計テーブル

dbtの3層構造との対応は次の通りです。呼び名は違っても、担う役割はそのまま重なります。dbtでの具体的な実装手順（プロジェクト構成・命名・テスト）はdbtで3層構造を実装するにまとめています。

メダリオンdbt 3層構造役割
BronzeRaw原形保存
SilverStaging / Intermediateクレンジング・共通ロジック
GoldMart分析用・ビジネス

層の境界を守る：原則とよくある失敗

メダリオンアーキテクチャが破綻するときは、たいてい層の境界があいまいになっています。どの層に何を置くかさえ守れば、多くのトラブルは未然に防げます。よくある失敗と、その裏返しである守るべき原則を整理しました。

よくある失敗なぜ起きるか守るべき原則
Bronzeを加工してしまう早く整えたいBronzeは無変換で生データを保存。障害時に完全再処理できる状態を保つ
Silverを飛ばしてGoldを作る手早く結果を出したい必ずSilverを通す。後からSilverを挿入するのは全書き直しになる
Silver層の肥大化変換を積み上げすぎるSilverにビジネスロジックを持たせない。整形までで止める
Gold層の粒度ミス集計しすぎて詳細が出せない完全集計と詳細の両方を用意し、ビジネスの質問に答える粒度にする
層・派生の増やしすぎ「念のため」で分岐する中間層は最小限に。どこを参照するかを1つに定める
コストの膨張保持と再計算が積み重なるBronzeの保持期間を絞り、Goldは必要に応じてマテリアライズする

とくに効くのは、Silverの変換を冪等に保つことです。何度実行しても同じ結果になれば、再処理や差分更新が安全になり、上の失敗の多くを同時に避けられます。

まとめ

メダリオンアーキテクチャは、データの品質段階を明確に意識させる優れた設計パターンです。Databricks環境だけでなく、SnowflakeやBigQueryでも同じ思想を取り入れられます。各層の役割と境界を守り、dbtの3層構造と併せて理解すれば、チーム内の共通言語が生まれ、保守性の高いデータ基盤を築けます。

よくある質問

メダリオンアーキテクチャはDatabricks専用ですか?

いいえ。Databricksが提唱しましたが、概念自体はクラウドDWH（BigQuery、Snowflake）でも適用できます。dbtの3層構造と本質的に同じ考え方です。ツール選定と設計思想は切り離して考えましょう。

Bronze/Silver/Goldの3層は必須ですか?

規模に応じて2層（Raw / Mart）にすることも可能です。ただし中規模以上ではSilver層が品質ゲートとして重要な役割を果たします。最初は3層で設計し、必要に応じて簡略化するのが安全です。

各層にどのようなテストを設定すべきですか?

Bronze層は取り込み完了の確認、Silver層は型チェック・NULL制約・ユニーク制約、Gold層はビジネスルール検証が基本です。層が進むほどテストを厳密にします。dbt testsやElementaryで自動化するのが定石です。

関連記事：データプロダクトとは？データをプロダクトとして扱うための5原則｜広告データ基盤設計：マルチチャネル広告データの統合とアトリビューション分析｜Airbyte vs Fivetran：オープンソースと商用ETLの選び方