メダリオンアーキテクチャ図：ブロンズ、シルバー、ゴールドの各レイヤー

どんなデータ基盤も、いずれ沼になります。orders という名前のテーブルが 5 つあり、経理がどれを使っているのか誰も確信がなく、誰かが上流のバグを直したせいでダッシュボードが壊れる。メダリオンアーキテクチャは、この混乱に対するシンプルな答えです。レイクハウスをブロンズ、シルバー、ゴールドの 3 つのレイヤーに整理し、それぞれに、データがどれだけ信頼できるか、誰が使ってよいかという明確な契約を持たせます。

この考え方は説明しやすいので人気があり、説明しやすいからこそ誤って適用されることもよくあります。この記事では、各レイヤーが何を持ち、何を持つべきでないか、レイヤー間でデータがどう動くか、データ品質チェック、再処理、ガバナンス、よくある落とし穴、そしてこのパターンがまったく不要な場合について、応用できる図とともに解説します。

3 つのレイヤーの概要

この名前は Databricks に由来し、そのドキュメントでは各レイヤーを、生、検証済み、エンリッチ済みと説明しています。実際には次のようになります。

レイヤーは処理ステップの数ではなく、品質の契約として捉えてください。ブロンズは完全性を、シルバーは正確性を、ゴールドは特定の利用者にとっての有用性を約束します。

ブロンズ：すべて保持し、何も変えない

ブロンズは生データが着地する場所です。オブジェクトストレージのファイル、Kafka のトピック、業務データベースからの変更データキャプチャのストリーム、SaaS ツールからのエクスポートなどです。ルールは次のとおりです。

• 追記のみ。 通常の処理の一環としてブロンズのレコードを更新したり削除したりしてはいけません。
• 最小限のパース。 Databricks は、上流で予期しないスキーマ変更があってもデータが失われないよう、ブロンズではほとんどのフィールドを文字列、variant、またはバイナリ値で保存することを推奨しています。
• メタデータを付けます。 取り込み時刻、ソースシステム、ファイル名やトピックのオフセットです。デバッグや再処理に必要になります。
• 再構築できるだけの期間保持します。 ブロンズの保持期間が、バグ修正後にシルバーとゴールドをどこまでさかのぼって再計算できるかを決めます。

ブロンズにはすべてが含まれます。あとでコピーしなければよかったと思うような個人データもです。アクセスはパイプラインに限定し、機密性の高いフィールドは取り込み時にトークン化や暗号化を検討してください。個人データの流れの追跡には GDPR データマッピング図が役立ちます。

シルバー：正しくする

エンジニアリングの労力の大半はシルバーに注がれます。

• フィールドをパースして型を付け、タイムスタンプを UTC に正規化し、単位やコードを標準化します。
• 2 回届いたレコードを重複排除します。at-least-once のソースでは必ず起きることです。
• 変更を適用します。 変更データキャプチャのソースでは、挿入、更新、削除を現在の状態を表すテーブルにマージします。
• キーを標準化し、顧客が CRM から来ても請求システムから来ても同じ識別子を持つようにします。
• 破棄せず隔離します。 検証に失敗した行は、理由とともに隔離テーブルに入れ、誰かが確認できるようにします。

Spark SQL で Delta Lake や Apache Iceberg を使った典型的なシルバーのマージでは、各注文の最新バージョンだけを残します。

MERGE INTO silver.orders AS t
USING (
  SELECT * FROM (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC) AS rn
    FROM bronze.orders_raw
    WHERE _ingested_at > '2026-11-01T00:00:00Z'
  ) WHERE rn = 1
) AS s
ON t.order_id = s.order_id
WHEN MATCHED AND s.updated_at > t.updated_at THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

データ品質のルールは、この境界に置きます。たとえば Databricks のパイプラインでは、警告する、問題のある行を破棄する、更新を失敗させる、のいずれかを行う expectations としてルールを宣言します。

CREATE OR REFRESH STREAMING TABLE silver_payments (
  CONSTRAINT positive_amount EXPECT (amount > 0) ON VIOLATION DROP ROW,
  CONSTRAINT known_currency EXPECT (currency IN ('USD', 'EUR', 'GBP')) ON VIOLATION DROP ROW
)
AS SELECT * FROM STREAM(bronze_payments);

どのツールを使うにしても、ルールを見える化し、ルールが除外した行を数えてください。

ゴールド：役に立つものにする

ゴールドのテーブルは利用者のために作ります。財務報告用のスタースキーマ、経営ダッシュボード用の地域別の日次売上、解約予測モデル用の顧客特徴量などです。ゴールドの各テーブルには、オーナー、文書化された定義、鮮度の目標を持たせるべきです。「アクティブ顧客」や「純売上」といった指標の定義はここに置き、ダッシュボードごとに実装し直すのではなく、一度だけ書きます。

ゴールドは、速度のために非正規化や集計を行う場所でもあります。シルバーは詳細を保持し、ゴールドは問いに答えます。

バッチ、ストリーミング、またはその両方

レイヤーがレイテンシーを決めるわけではありません。各段階は、夜間バッチ、1 時間ごとの増分ジョブ、チェックポイント付きの継続的なストリームのいずれでも実行できます。多くのチームは、ソースからブロンズとシルバーまではストリーミングにしてデータを数分以内に最新の状態に保ち、ゴールドの集計は、見られる頻度に合ったスケジュールで更新します。できる限り増分で処理してください。前回の実行以降の新しいブロンズデータだけを読むことが、データが増えてもコストを一定に保つ鍵です。

再処理と履歴

ブロンズは不変なので、シルバーのロジックのバグは取り返しがつきます。コードを修正し、影響を受けたシルバーのパーティションをブロンズから再構築し、続いてゴールドを再構築します。Delta Lake や Iceberg のようなテーブル形式はスナップショットを提供するので、昨日時点のテーブルを照会したり、変更を監査したり、不正なロードをロールバックしたりできます。最初からこれを計画しておきましょう。変換は決定的に保ち、1 か月分を再構築するのにすべてを再構築しなくて済むよう、テーブルをパーティション分割します。

レイヤーごとのガバナンス

カタログでは、各レイヤーをそれぞれ独自のスキーマに置きます。たとえば ops.bronze、ops.silver、ops.gold で、これは Databricks が自身の例で使っているレイアウトです。そのうえで、アクセスはレイヤーごとに付与します。パイプラインがブロンズに書き込み、エンジニアとアナリストがシルバーを読み、社内の大半はゴールドだけを読みます。レイヤーをまたぐリネージは、インシデントのときに誰もが尋ねる問い、つまり「この壊れたソースに依存しているダッシュボードはどれか」に答えてくれます。

落とし穴

• 3 をルールとして扱う。 ステップが多く必要なソースもあれば、少なくて済むソースもあります。大事なのは契約であって、段階の数ではありません。
• シルバーにビジネスロジックを入れる。 シルバーは多くの利用者が再利用できるものであるべきです。1 つのレポートのためのロジックはゴールドに置きます。
• ゴールドを物置にする。 オーナーがいないと、ゴールドは誰もメンテナンスしない使い捨てのテーブルであふれます。見直して廃止しましょう。
• すべてを 3 回コピーする。 大きな生データセットを 3 つの形で保存すると、相当な費用がかかります。シルバーには、実際に必要な列と履歴だけを残します。
• 隔離を省く。 黙って破棄された行こそが、誰も気づかないうちに数字がずれていく原因です。

メダリオンが過剰な場合

データがクラウドのデータウェアハウスに無理なく収まり、ソースが数えるほどしかないなら、そもそもレイクハウスは不要かもしれません。dbt でよく使われる staging、intermediate、marts という規約は、1 つのウェアハウスの中で段階的に洗練させるという同じ考え方を表しています。

名前よりも規律のほうが重要です。生データを手つかずのまま保持すること、各エンティティのクリーンなバージョンを 1 つにすること、そしてオーナーのいる目的別のテーブルを持つことです。

メダリオンの図

図の読み方は次のとおりです。

• 左側はソースです：Postgres の変更データ、Kafka のイベント、CRM のエクスポートです。
• 3 つの色付きフレームがレイヤーです。ブロンズは生ファイルを、シルバーはクレンジング済みテーブルと隔離用ストアを、ゴールドはビジネステーブルを持ちます。
• フレーム間のエッジはパイプラインのステップで、パース、重複排除、マージ、集計といった処理内容をラベルにしています。
• 右側は利用者です：BI ダッシュボードと機械学習用の特徴量ストアは、ゴールドだけを読みます。
• Markdown ブロックには各レイヤーの契約をまとめています。

迷わずたどれるデータ基盤の図を描くには

• レイヤーに色を付けます。 ブロンズ、シルバー、ゴールドが覚えやすいのは、視覚的だからこそです。色を活用しましょう。
• 各段階には矢印だけでなく、処理内容のラベルを付けます。 「重複排除してマージ」と書けば、レビュアーはバグをどこで探せばよいか分かります。
• 誰が何を読むかを示します。 レイヤーごとのアクセスは設計上の判断であり、ダッシュボードがブロンズを決して読まないことが図から明らかであるべきです。
• 隔離の経路も描きます。 除外されたデータの行き先をレビュアーに示せます。

レイクハウスを取り巻くより広いパイプラインはデータパイプラインのアーキテクチャ図で、ストリーミングのソースは Kafka アーキテクチャ図で、ML の利用者は MLOps アーキテクチャ図で扱っています。

Archboard で作る

1. Google または GitHub でサインインし、図を作成します。
2. ソースとして、データパックの Postgres ノードと Kafka ノード、CRM 用に C4 モデルパックの 外部システム を追加します。
3. Bronze、Silver、Gold という名前の基本パックの フレーム ノードを 3 つ追加し、それぞれに合った色を付けます。
4. ブロンズの中に、生ファイル用としてデータパックの オブジェクトストア を追加します。シルバーの中には、クレンジング済みテーブル用の データウェアハウス ノードと、隔離用の オブジェクトストア を追加します。ゴールドの中には、ビジネステーブル用にもう 1 つ データウェアハウス ノードを追加します。
5. 利用者として、BI ダッシュボード用に基本パックの ボックス を、ML パックの 特徴量ストア を追加します。
6. 各エッジにステップのラベルを付け、レイヤーのルールを書いた基本パックの Markdown ブロックを追加します。

この例で使うダイアグラムノードは 13 個で、Free プランの範囲に収まります。

よくある質問

メダリオンアーキテクチャとは何ですか？ レイクハウスを、品質が段階的に高まる 3 つのレイヤーに整理する方法です。受け取ったままの生データを置くブロンズ、クレンジングと標準化を済ませたデータを置くシルバー、特定の用途向けに作ったビジネスですぐ使えるテーブルを置くゴールドです。

シルバーとゴールドの違いは何ですか？ シルバーは、詳細レベルの正確で再利用できるデータを、エンティティやイベントの種類ごとに 1 テーブルで保持します。ゴールドは、集計、スタースキーマ、ML の特徴量など、目的に合わせて形を整えたテーブルを、オーナーと定義付きで保持します。

ブロンズのデータを変更することはありますか？ 通常の処理の一環としてはありません。ブロンズは追記のみなので、下流のすべてを再構築できます。例外は法的な削除要求と保持期間の制限で、これらには専用のプロセスが必要です。

メダリオンアーキテクチャは Databricks 専用ですか？ いいえ。名前は Databricks に由来しますが、このパターンはどんなレイクハウスやウェアハウスでも使えます。Delta Lake、Apache Iceberg、Snowflake、BigQuery と、Spark、dbt などのツールの組み合わせです。

レイヤーは必ず 3 つ必要ですか？ いいえ。ソースが必要とするだけのステップを使ってください。大切なのは、手つかずの生データのコピー、各エンティティのクリーンなバージョン、そしてオーナーのいる目的別のテーブルです。

無料で始める — 1 シート、クレジットカード不要。