データ基盤

メダリオンアーキテクチャとは？ブロンズ・シルバー・ゴールドの役割

2026/10/8 シリーズ「Databricks 入門」 第2回 / 全3回

🤖 AIが執筆しています

{"order_id": "A-1001", "item": "Tシャツ", "qty": 2, "amount": 2400, "ordered_at": "2026-10-01T10:15:00"}

メダリオンアーキテクチャとは：品質の段階を示す三つの層

Databricks の文書は、メダリオンアーキテクチャを、レイクハウスに置かれたデータの品質を示す一連の層と説明する¹。レイクハウスは、データレイクの安い保存先の上で、データウェアハウスのような管理を行う基盤である。同じ文書は、ブロンズ（未加工）、シルバー（検証済み）、ゴールド（エンリッチ、つまり情報を付け加えたもの）という名前が、各層のデータの品質を表すと書く。同じ文書は、この型をマルチホップアーキテクチャ（データが複数の段を順に渡っていく構成）とも呼ぶ。レイクハウスの文書は、データが層を移るにつれて少しずつ整えられる設計の型が、よくメダリオンアーキテクチャと呼ばれると説明している²。

ここで注意したいのは、同じ文書が、メダリオンアーキテクチャに従うことは推奨されるベストプラクティスだが必須ではない、と明記していることである¹。層の数も三つに決まってはおらず、設計の基本原則をまとめた Databricks の文書は三つの層を「よくある分け方」として挙げ³、レイクハウスの文書は、各層がさらに一つ以上の層を含みうると書く²。

Databricks は、自社の製品で基盤を作るときの判断の基準を、6つの基本原則にまとめた。その基本原則 1 は、データを階層化（またはマルチホップ）アーキテクチャでキュレーションすることを Databricks にとって重要なベストプラクティスとし、取り込みの層、キュレートされた層、最終の層を挙げている³。ただし、基本原則の文書には「メダリオン」という語は出てこない。本稿は、マルチホップという共通の語を手がかりに、メダリオンアーキテクチャを基本原則 1 の具体的な形と考える。

ブロンズ：届いたデータを原本のまま残す

ブロンズは、データが最初に着地する層である。Databricks の文書によれば、ブロンズは、分析者やデータサイエンティストが直接使うための層ではなく、シルバーの表を作る処理が読むための層である¹。届いたデータを忠実に保ち、すべての履歴を残すことで、作り直しと監査を可能にする。

そのため Databricks は、予期しない形式の変化でデータが失われないよう、ほとんどの項目を文字列、VARIANT（形の決まっていないデータを入れる型）、またはバイナリとして持つことを勧めている¹。一方で、データの出どころを示す列、たとえば元のファイルの名前を足すことは認めている。

シルバー：検証し、集計しない行を残す

シルバーは、データを検証し、整える層である。Databricks の文書は、取り込みからシルバーの表へ直接書き込むことを勧めない¹。直接書き込むと、データの形式の変化や壊れた行のために処理が失敗するからである。シルバーでは、形式の強制、空の値の扱い、重複の除去、遅れて届いたデータの扱い、品質の検査、型の変換、結合といった作業を行う。

シルバーには、各レコードについて、検証済みで集計していない表現を少なくとも一つ必ず持つという決まりがある¹。多くの処理が使う集計がシルバーに置かれることもあるが、集計は普通ゴールドに置く。同じ文書は、シルバーを、掘り下げた分析に要る詳細な情報を保った表として分析者が使う層と説明し、大量の履歴データは普通シルバーで参照してゴールドには持たないと書く¹。2019 年の Databricks のブログも、一つのシルバーの表を複数のゴールドの表の共通の元にすれば、部門ごとに同じ処理を繰り返さずに済み、同じ指標を部門ごとに少しずつ違えて計算する混乱も避けられると書いている⁴。別の製品では、dbt の手引きが、早い段階で集計すると、後で必要になる元のデータに戻れなくなると説明している⁵。

ゴールド：業務の目的に合わせて形を整える

ゴールドは、報告や分析のためにデータを形づくる層である。Databricks の文書は、ゴールドでは次元モデル（売上のような数値の表を、日付や商品といった切り口の表と結びつける形）でデータを組み立てると書く¹。ゴールドは業務の領域を表すので、人事、経理、IT のように、目的ごとに複数のゴールドの層を作る利用者もいる。Databricks のマーケティング用の用語集は、Kimball 流のスタースキーマ（数値の表を中心に、切り口の表を星形に並べる形）や、Inmon 流のデータマート（部門や用途ごとに切り出した小さなデータの集まり）がゴールドの層に当てはまると書く⁶。同じ用語集は、第三正規形（同じ情報を重複して持たないよう表を細かく分ける設計）に近いモデルはシルバーに当てはまるとも書いている。Kimball と Inmon は、データウェアハウスの作り方の二つの流派を代表する人物である。

Databricks で層を作る仕組み

Databricks で層を作るときに使う主な仕組みは、Lakeflow のパイプライン（旧称 Delta Live Tables）にまとまっている⁷。パイプラインでは、ストリーミングテーブルやマテリアライズドビューといった表を宣言的に（処理の手順ではなく、どんな表がほしいかを）書き、更新の順序や、直前の更新の後に増えた分だけを処理する差分の処理は、パイプラインが自動で受け持つ⁸。

取り込みには、Auto Loader が使える。Auto Loader は、クラウドのストレージに新しいファイルが届くと、それを差分だけ効率よく処理する⁹。JSON や CSV のように型の情報を持たない形式では、既定ですべての列を文字列として読む¹⁰。これはブロンズを文字列で持つという推奨と合う。

ストリーミングテーブルは、追記されていくデータの各行を一度だけ処理する表で、取り込みや差分の処理に向く。マテリアライズドビューは、元のデータの現在の状態に合うように結果を計算し直す表で、変換や集計に向く⁸。ただし、ストリーミングテーブルの結合は、結合相手の表が後で変わっても計算し直されない¹¹。結合した結果を常に正しく保ちたいときは、マテリアライズドビューを使う。

品質の検査には、エクスペクテーションを使う。エクスペクテーションは、SQL の条件式で品質の制約を書き、パイプラインを流れるデータを検査する¹²。条件に合わない行の扱いは三つある。既定の警告では、その行もそのまま書き込む。削除では、その行を書き込む前に捨て、捨てた件数を記録する。失敗では、更新そのものを止め、手で直すまで再処理できない。誤った行を止めずに別の表に隔離する作り方もある。たとえば、数量が 0 以下の注文の行をはじく検査は、シルバーの表に付けるエクスペクテーションとして書ける。

メダリオンの文書の例は、層ごとに、Unity Catalog（Databricks でデータと権限を管理する仕組み）の別のスキーマ（表をまとめる入れ物）である ops.bronze、ops.silver、ops.gold を使っている¹。同じ文書は、取り込みの例にストリーミングテーブルを、ゴールドの例にマテリアライズドビューを使っている。ただし、どの層にどの仕組みを使うかを規則として定めてはおらず、パイプラインの仕組みの文書も「メダリオン」や「ブロンズ」という語を使っていない。

費用については、Databricks の文書は、取り込みの頻度で費用を調整するよう書いている¹。続けて取り込むと遅れは小さいが費用は高く、決めた時刻に取り込むと費用は低いが遅れは大きい。ただし、数値は示されていない。

層で分ける考えは新しくない

データを裏方の層と利用者に見せる層に分ける考えは、メダリオンアーキテクチャより前からある。Kimball は 2002 年の記事で、データウェアハウスにはまずステージング領域があり、そこで多くの元のシステムからのデータを取り込み、洗い、そろえ、結合してから、利用者に見せる提示の系に渡すと書いた¹³。そして、ステージング領域の最も重要な条件は、利用者が立ち入れないことだとし、レストランの厨房にたとえた。利用者を入れない点はブロンズと同じだが、データを洗って結合するところまで含む点では、ブロンズとシルバーの作業の両方に当たる。Kimball Group の 2004 年の記事は、Corporate Information Factory と呼ぶ方式では、元のデータを第三正規形の中央のデータウェアハウスに入れ、そこから部門ごとのデータマートを作ると説明している¹⁴。

データレイクにも同じ考えがある。AWS の手引きは、個人情報を含まないような機密性のないデータについて、データレイクに少なくとも三つの層、未加工の層、処理途中の層、用途ごとに集計した層を設けるよう勧めている¹⁵。個人情報のような機密のデータを扱う場合は、その手前に着地用の層を足し、隠す処理をしてから未加工の層に移すよう書いている。分析のための変換を書くツール dbt の手引きも、元の表と 1 対 1 で対応する staging、目的に応じて組み立てる intermediate、業務の対象をまとめる marts という層を勧め、staging で集計しないよう書いている⁵。ただし、Kimball のステージング領域は利用者の立ち入らない作業場であり、dbt の staging は軽く整えたモデルなので、同じ「ステージング」でも指す層は違う。

ブロンズ・シルバー・ゴールドという名前は、Databricks のブログで、2019 年 8 月には「マルチホップ」の構成の各層の名前として使われていた⁴。このブログは機械学習の学習や予測に使う表をゴールドと呼んだが、同じブログは、一つのシルバーの表から、供給網のダッシュボードや取締役会向けの指標のような、部門ごとに用途の違うゴールドの表を作る例も挙げている。「メダリオン」という語は、確認できた範囲では 2020 年 6 月の Databricks のブログが最も古い¹⁶。だれが名付けたかを示す一次資料は見つからなかった。

同じ色の名前でも、層の意味は製品ごとに違う

Microsoft Fabric の文書も、メダリオンアーキテクチャを使う。ただし、Fabric の文書はこれを推奨の設計とし、三つの層をブロンズ（生のデータ）、シルバー（エンリッチされたデータ）、ゴールド（キュレーションされたデータ）と定義する¹⁷。Databricks は層の名前の言い換えでゴールドを「エンリッチ」と呼ぶが、Fabric はシルバーを「エンリッチ」と呼ぶ。ブロンズについては、Fabric の文書は届いたとおりに保存し変更しないと要約する一方、元の形式のほかに Parquet や Delta Lake で持つことも勧めている¹⁷。Databricks も、ブロンズを元の形式のまま生の状態を保つ層とし、そのうえでほとんどの項目を文字列などの緩い型で持つよう勧めている¹。ブロンズを元の形のまま残すことを基本にする点では、二つの文書はそろっている。

Databricks の中でも、説明はそろっていない。メダリオンの文書は、ゴールドを「エンリッチ」と言い換える一方、シルバーの説明でも、検証され、整えられ、情報を付け加えられた（enriched）データと書いている¹。また、基本原則 1 は 2 番目の層に集計したデータも置くと書くのに対し³、メダリオンの文書は、集計をシルバーに置く場合も認めつつ、集計しない表現を必ず残し、集計は普通ゴールドに置くと書いており、説明の重点が違う¹。そのため、「シルバーには何を置くか」といった問いには、色の名前ではなく、各層が何を受け持つかを決めてから答える必要がある。

批判と限界

メダリオンアーキテクチャには、名前の分かる実務者からの批判がある。Beach は 2025 年の記事で、メダリオンアーキテクチャの有無にかかわらずレイクハウスはうまく運用できるとし、この名前はマーケティングの言葉にすぎないと書いた¹⁸。彼によれば、ゴールドと呼ばれるものは、実際にはデータマートである。

Packkildurai は同じ年の記事で、メダリオンアーキテクチャがチームに共通の語彙を与えると評価する一方、ゴールドの変換を待つ遅れを許さない用途もあるとして、プラチナ層を加えることを提案した¹⁹。プラチナ層は、不正の即時の検出のような用途のために、ブロンズ、シルバー、ゴールドのどこからでもデータを読むことがある。また、業務の指標をシルバーで作ると、チームごとに指標の定義が割れると注意している。

データを製品として扱う設計を唱える Kumar らは、2025 年の記事で、メダリオンアーキテクチャは業務の領域や用途ではなく変換の段階だけでデータを分けており、データを製品ではなく流れ作業として扱うと批判した²⁰。層ごとにデータの写しを持つので、保存の費用も増えると書いている。

これらはいずれも意見であり、測定ではない。arXiv と Crossref を検索した範囲では、メダリオンアーキテクチャを他の設計と比べて、費用やデータの品質への効果を測った論文は見当たらなかった（本文を取得できなかった会議論文が 1 本ある）。arXiv の論文の中には、メダリオンアーキテクチャを「データウェアハウスの標準」と呼ぶものもあるが²¹、査読を経ていない単著の論文で、この型の出どころとして挙げるのは Databricks のブログである。同じ論文は、シルバーの構造と設計には広く受け入れられた標準が無いとも書いている。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。