メダリオンアーキテクチャとは？Bronze・Silver・Goldの層設計と再処理を解説

メダリオンアーキテクチャは、レイクハウスに置いたテーブルを品質段階でBronze・Silver・Goldの3つに分け、層をまたぐたびに構造と品質を上げていく設計パターンです。図としては分かりやすい一方、実装で詰まるのは「どの型でBronzeに落とすか」「どこまで遡って再処理できるか」「層をいくつに割るか」という値の決定です。この記事では各層のテーブル設計とファイルサイズの目安、VACUUMの保持制約から逆算する再処理の起点、Databricks・Microsoft Fabric・OSS構成でのデプロイ単位の違いを整理し、3層を敷かないほうがよい要件まで条件付きで示します。

まとめ：メダリオンアーキテクチャの層分割で先に決める3つの設計値

層の名前を決めても実装は進みません。着手前に確定させる値は3つです。第一にBronzeの履歴保持期間、第二に再処理の起点となる層、第三に層の分離単位（スキーマ・カタログ・ワークスペースのどれで割るか）。この3点が決まれば、テーブル定義とジョブ設計は機械的に埋まります。

3層は義務ではありません。Azure Databricksのドキュメントは「medallion アーキテクチャに従うことをお勧めするが、必須条件ではありません」と明記しています（2026-05-07更新時点）。一方でMicrosoft FabricはOneLake上のレイクハウスに3層を敷く形を推奨設計として案内しており（2026-02-12更新時点）、製品によって前提が違う点は押さえておく必要があります。

判断の目安はソース数です。データソースが1〜2系統、更新が日次バッチ、用途がBIレポートだけなら、Silverを省いた2層で足ります。名寄せや遅延データの調停が発生した時点で、はじめてSilverを置く価値が出ます。

メダリオンアーキテクチャの定義とマルチホップ構成が示す品質段階の違い

層の呼び名はデータの品質ラベルであって、ストレージ製品の種類ではありません。ここを取り違えると、層ごとに別サービスを買う設計に流れます。

品質段階でテーブルを分けるマルチホップ設計のデータ管理上の位置づけ

メダリオンアーキテクチャは、データを論理的に整理するための設計パターンで、マルチホップアーキテクチャとも呼ばれる方式です。Bronzeは到着したままの未加工データ、Silverは検証と重複除去を通した状態、Goldは分析に向けて集計・整形した状態を指します。ホップ（層の移動）ごとにテーブルを作り直すため、どの段階でデータが壊れたかを切り分けやすい構造です。土台となるレイクハウス側の構造はデータレイクハウスの定義とアーキテクチャを解説した記事に整理しており、本記事はその上に置くテーブル層の設計だけを扱います。層はメタルの色に由来する呼称で、金額的な価値ではなく精製度を表す言葉です。

ブロンズ・シルバー・ゴールドの各層が担う利用者と処理内容の分担

層の責務は、処理内容と読み手の両方で分かれます。Azure Databricksのドキュメントが示す分担を整理すると次の通りです。

読み手の欄がそのままアクセス権限の設計図になります。Bronzeはシルバーテーブルを作るワークロードのためのもので、アナリストが直接触る前提では設計しません。監査とコンプライアンスの参照だけは例外的にBronzeへ向きます。

Delta LakeとIcebergのどちらでも層設計が成立する理由

層を分ける行為そのものはフォーマット非依存です。成立の前提は、テーブル単位でACIDトランザクションとスキーマ管理が効くこと。Delta LakeでもApache Icebergでも、この条件は満たされます。Microsoft FabricはDelta Lakeを既定のストレージ形式に据え、すべてのワークロードエンジンが新規テーブルをDeltaで書き込む設計です。テーブルログがどう版を管理するかはDelta Lakeのトランザクションログの仕組みを解説した記事で確認できます。逆に、素のParquetをディレクトリに並べただけの状態では、Silverでの更新処理が書き込み途中の読み取りと衝突します。フォーマット選定を先に済ませてから層を切る順序が安全です。

Bronze・Silver・Goldの層別テーブル設計とスキーマ・ファイルサイズの基準

ここからは各層で具体的に何をどう格納するかに入ります。設計値の根拠は各社の公式ドキュメントに揃っています。

Bronze層で型を文字列やVARIANTへ寄せる取り込み設計とメタデータ列

Bronzeでの型付けは緩めが基本です。Azure Databricksは、破棄されるデータを確実に防ぎ想定外のスキーマ変更から守るため、ほとんどのフィールドを文字列・VARIANT・バイナリで格納する構成を推奨しています。型を厳しく当てると、ソース側の仕様変更でジョブが落ち、その日の生データを失う原因になります。加えて、どのファイルから来たかを示す _metadata.file_name のようなメタデータ列を足しておけば、後から取り込み元を追跡可能です。Bronzeは追記中心で時間とともに増え、全履歴を持つことで再処理と監査を成立させる層です。ソースがAmazon S3やADLS Gen2、Google Cloud Storageに既にあるなら、FabricではコピーせずショートカットでBronzeに参照を作る方法も選べます。生データを二重に持たずに済むため、保管費が下がる構成です。

Silver層で重複除去とスキーマ適用を行い非集計表現を残す設計

Silverで行う処理は、スキーマの適用、null・欠損値の処理、重複除去、順序が乱れて到着したデータの調停、型キャスト、結合です。設計上の要点はひとつ。各レコードについて検証済みかつ非集計の表現を最低1つ残すこと。ここで集計まで済ませてしまうと、後から粒度の違う分析要件が来たときにBronzeまで戻る羽目になります。取り込み処理から直接Silverへ書き込む構成も避けます。ソース側のスキーマ変更や壊れたレコードがそのままエラーになるためで、Bronzeからの読み取りを挟むのが定石です。読み取りは追記前提のストリーミング読み取りを基本とし、小さなディメンションテーブルだけバッチ読み取りに回します。検証ルールをコード側に持たせるなら、Great Expectationsによるデータ品質検証の実装を層の境界に挟む構成が扱いやすいところです。

Gold層のディメンションモデル化と部門別に複数持たせる基準

Goldはビジネス部門が読む層で、ファクトとディメンションの関係を定義し、メジャーを持たせたモデルにします。週次売上のような定型の集計は、マテリアライズドビューとして事前計算しておくと、閲覧のたびに再集計が走りません。Goldはビジネスドメインをそのままモデル化するため、人事・財務・ITのように部門ごとに複数のGoldを作る構成も採れます。判断基準は「同じ集計を3つ以上のチームが別々に書いているか」。重複が見えてから分けるほうが、使われないテーブルが増えません。大量の履歴データはSilverで参照させ、Goldには実体化しないのが基本形です。Goldのテーブル数がSilverより多くなっている基盤は、粒度設計に失敗しています。

層ごとに変えるファイルサイズとパーティション設計の切り替え判断基準

小さなファイルが増えるとメタデータ操作が膨らみ、クエリのプランニングが遅くなります。Microsoft Fabricのガイダンスは、テーブルサイズと利用パターンに応じて128MBから1GBのファイルサイズを目標に置く方針です（2026-02-12更新時点）。層ごとの当て方は次のように分かれます。

• Bronze：生データの性質上、小さめのファイルを許容してよい（変換はSparkに寄せる）
• Silver：書き込みと読み取りの釣り合いを取る中間サイズにする
• Gold：利用エンジンのクエリ性能を優先し、大きめのファイルと行グループにする

分割方式も層で変わります。Bronzeのパーティション分割は許容されるものの、新規実装では推奨されていません。SilverとGoldではパーティションの代わりにリキッドクラスタリングを使う指針が示されています。パーティション済みのテーブルへMERGEをかける場合は、パーティションフィルタを併用して更新対象外を除外させます。

層をまたぐ再処理とバックフィルを成立させる保持期間と冪等性の設計

メダリオンの実務価値は、壊れたときにどこから流し直せるかで決まります。設計の起点は保持期間です。

Bronzeの履歴保持とVACUUM既定7日制約から決める再処理の起点

Bronzeが全履歴を持つ限り、Silver以降はいつでも作り直せます。ところがDelta Lakeは既定で変更履歴を残し続けるため、履歴メタデータは時間とともに膨らみます。古い版の削除には VACUUM を使いますが、既定では直近7日以内の履歴データを消せません。一貫性を守るための制約で、テーブルプロパティ delta.deletedFileRetentionDuration で日数を変更できます。ここで決めた保持期間が、そのまま遡って再処理できる最大期間になります。監査要件で3年分の再現が要るなら、Bronzeのファイル本体は消さずに残し、履歴メタデータの保持だけを1か月程度に絞る組み合わせが現実的です。保持期間を決めないまま運用に入ると、ストレージ費用が積み上がる一方で、いざ障害時に「どこまで戻せるか」の答えが誰にも出せません。

冪等な変換とMERGEで再実行時の重複を防ぐパイプライン実装

再処理は同じジョブを二度走らせる操作です。追記だけで組んだ変換では、二度目の実行時に行が倍になる結果を招きます。自然キーと更新時刻を決めてMERGEによるアップサートに寄せれば、何度流しても結果が変わらない状態を作れます。ストリーミング読み取りで組む場合は、チェックポイントの保存先を層ごとに分け、テーブルを作り直したらチェックポイントも捨てる運用が必要です。冪等性の考え方そのものはデータパイプラインの構成要素と冪等性から考える設計判断に整理しており、層をまたぐ設計にもそのまま適用できます。バックフィルの範囲指定は日付パーティションで切るのが扱いやすく、対象期間のSilverを削除してから流し直す手順を運用に組み込む設計です。

継続・トリガー・バッチという取り込み頻度3方式のコストと遅延

取り込み頻度は、そのまま計算資源の費用になります。Azure Databricksのドキュメントが整理する3方式の関係は次の通りです。

実務でまず試すのはトリガー実行です。ファイル到着トリガーなら、常時起動のクラスタを抱えずに数分単位の鮮度を作れます。継続実行が要るのは、秒単位の鮮度が業務要件になっている場合に限られます。

Databricks・Fabric・OSS構成で分かれるデプロイ単位と権限境界

層をどの単位で物理分離するかは製品で変わります。同じ3層でも、置き場所と権限の切り方が違います。

Databricksでカタログとスキーマを使い層を分離する権限設計

Databricksの標準形は、1つのカタログの下に層ごとのスキーマを並べる構成です。運用チーム向けの基盤なら ops.bronze、ops.silver、ops.gold のように、カタログ名で用途を、スキーマ名で品質段階を表します。権限はスキーマ単位で付与し、BIツールにはGoldスキーマだけを見せます。テーブル作成と削除の権限を分析者全員に配ると、破損時の原因追跡ができなくなるため、書き込みはパイプライン用のサービスプリンシパルに限定する設計が定石です。層をまたぐ系統（リネージ）はカタログ側で自動記録されるため、Gold のテーブルがどの Bronze から来たかを後から追えます。

Fabricで層ごとにレイクハウスとワークスペースを分ける構成

Fabricでは各層をOneLake上の別のレイクハウスとして作ります。よく採られる型は2つで、全層をレイクハウスにしてSQL分析エンドポイントから読ませる構成か、BronzeとSilverをレイクハウス・Goldをデータウェアハウスにしてウェアハウスのエンドポイントから読ませる構成です。すべてを1つのワークスペースに置くこともできますが、ドキュメントは層ごとに別ワークスペースへ分ける方針を推奨しています（2026-02-12更新時点）。層の単位で統制と権限を効かせやすくなるためです。層間の変換をパイプラインで組む代わりに、マテリアライズドレイクビューをSQLで宣言し、依存関係の解決と更新順序をサービス側に任せる選択肢も用意されています。

IcebergとTrinoで組む自前構成の名前空間とジョブ配置

OSSだけで組む場合は、カタログの名前空間を層に対応させます。Icebergカタログに bronze・silver・gold の名前空間を切り、書き込み権限を名前空間単位で分けるのが最小構成です。ジョブはSparkやTrinoで実装し、層ごとに実行スケジュールを変えます。小ファイル統合と旧スナップショット削除は自分で組み込む前提になるため、マネージド構成より運用の重さが増します。ストレージからクエリエンジンまでの組み上げ手順はデータレイクハウス実装の手順6ステップを解説した記事に分けて整理しました。自前構成を選ぶ条件は、SparkやTrinoの運用経験者が複数名いること。この条件を満たさないなら、層設計だけ持ち込んでマネージド基盤に載せる判断を勧めます。

3層固定を見送る判断基準とメダリオンが不向きな要件の切り分け

ここからは立場を明確にします。メダリオンは万能の型ではなく、噛み合わない要件がはっきりあります。

単一ソースとBI限定の要件で3層が過剰になる境界と2層への集約

データソースが1〜2系統、更新が日次バッチ、用途が定型BIだけ、規模が数十GB程度。この4条件が揃うなら、3層は敷きません。生データを受けるBronzeと、BIが読むGoldの2層で足ります。Silverの存在価値は、複数ソースの名寄せ・遅延データの調停・重複除去といった調停処理にあり、ソースが1本ならその処理自体が発生しないためです。層を1つ減らせば、テーブル定義もジョブも監視対象も減ります。判断を先送りして3層で始めると、実体としてSilverがBronzeの単なるコピーになり、保管費と実行時間だけが二重に乗ります。切り替えの目安は、2つ目の基幹データを取り込む段階です。

不正検知などリアルタイム性が最優先の用途で多段構成を避ける判断

層をまたぐたびにコミットが挟まるため、遅延は積み上がります。決済の不正検知のように、秒単位で判定を返す用途では、メダリオンの多段構成を判定経路に置くべきではありません。この場合はストリーム処理側で直接判定し、メダリオンは事後の分析・学習データ整備用として並置します。判定経路と分析経路を分ける設計です。両方を1本の層構成でまかなおうとすると、鮮度を上げるために継続実行のコストを払い、それでも層数ぶんの遅延は消えないという中途半端な結果に落ちます。リアルタイム判定と履歴分析は、要件が違う以上、経路も分けるのが結論です。

Platinum層を足す前に見直すGoldの粒度とSilverの責務

Goldの上にPlatinum層を置く構成が語られることがありますが、層の追加はデータのコピーと運用対象を1段増やす判断です。着手前に見るべきは2点。Goldのテーブルが増えすぎている原因が粒度設計の失敗ではないか、そしてSilverに集計処理が混入していないか。Silverで集計してしまうとGoldとの責務が重なり、どちらを直せばよいか分からないテーブル群ができます。層の追加を認めてよいのは、部門をまたいだ同一のKPI定義が3チーム以上で重複実装されている場合に限ります。それ以外は、Goldの粒度を切り直すほうが早く、費用も増えません。

内製で層設計を保守できるデータ基盤チームの条件と受託開発への線引き

層設計は作って終わりではなく、保持期間の見直しとファイル統合を回し続ける運用です。内製が成立する条件は、SparkまたはクラウドDWHの運用経験者が複数名いて、基盤整備に半年単位の工数を確保できること。分析要件は決まっているのに基盤の担当者がいない状況で3層を敷くと、Silverのジョブが止まったまま誰も気づかない状態になります。当社ではデータ分析基盤構築・MLOps構築支援として、層設計とテーブル定義から再処理の運用設計までを受託しています。層数の判断だけを相談し、構築範囲を後から広げる進め方も可能です。内製か外注かを決めないまま着手する進め方だけは避けてください。

よくある質問

メダリオンアーキテクチャの設計段階でよく挙がる質問に、実装の観点から答えます。

メダリオンアーキテクチャは必ず3層にする必要がありますか？

必須ではありません。Azure Databricksのドキュメントも、メダリオンに従うことを推奨しつつ必須条件ではないと明記しています（2026-05-07更新時点）。ソースが1〜2系統で名寄せや重複除去が発生しないなら、BronzeとGoldの2層で足ります。逆にMicrosoft Fabricでは3層が推奨設計として案内されており、採用製品によって前提が変わります。層数は要件から決め、図に合わせて増やさないでください。

Bronze層のデータは分析者が直接参照してよいですか？

設計としては想定しません。Bronzeは検証前の未加工データを保持する層で、読み手はSilverテーブルを作るワークロードです。分析者が直接参照すると、型が文字列のまま解釈され、部門ごとに違う集計結果が出ます。例外は監査・コンプライアンス目的の参照で、この場合も読み取り専用の権限に絞ります。分析者へはSilverかGoldを見せる構成が基本です。

Silver層とGold層の違いはどこで判断しますか？

集計しているかどうかで分けます。Silverは各レコードの検証済みかつ非集計の表現を最低1つ持つ層で、クレンジング・重複除去・結合までを担当します。Goldはビジネス要件に沿ってディメンションモデル化し、集計値やマテリアライズドビューを置く層です。Silverに集計が混ざり始めたら責務が崩れているサインで、集計処理をGold側へ寄せ直します。

メダリオンアーキテクチャはDatabricks以外でも実装できますか？

Databricks以外でも実装可能です。層分割はテーブルフォーマットに依存しない設計パターンで、ACIDトランザクションとスキーマ管理が効けば成立します。Microsoft FabricはOneLake上のレイクハウスで3層を組み、AWSではS3とIcebergにGlueカタログの名前空間を層として割り当てる構成が採れます。製品で変わるのは層の物理的な分離単位（スキーマ・レイクハウス・名前空間）と権限の切り方です。

既存のデータレイクからメダリオン構成へ移行できますか？

移行できます。手順は、既存のParquet群をテーブル化してBronzeに位置づけ、そこから読み取るSilverの変換を新規に組む流れです。データ本体を書き直さずにテーブル化できる場合が多く、移行費用を抑えられます。着手前に、Bronzeの保持期間・再処理の起点・層の分離単位の3点を決めておくと、移行後の作り直しを避けられます。

関連記事

• データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説：層設計の土台となるデータレイクの構造と使い分けを整理しています。
• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説：層をまたぐ変換処理そのものの設計原則を、ツール選定の観点から補完します。
• Dagsterとは？アセット指向の仕組み・実装手順とAirflowとの使い分けを実装者目線で解説【2026年版】：層間のジョブ依存と再実行をどう管理するか、オーケストレータ側から扱っています。