メダリオンアーキテクチャ(Medallion Architecture)

1. 概要

定義: メダリオンアーキテクチャ(Medallion Architecture)とは、データレイクハウス(lakehouse)内部のデータを品質と加工度に応じてブロンズ(Bronze)・シルバー(Silver)・ゴールド(Gold)の層(layer)へ段階的に精製・構造化するデータ設計パターンであり、各層を経るほどデータの整合性・ビジネス上の意味・活用性が高まるように構成する多段(multi-hop)精製モデルである。

企業のデータアーキテクチャは長らく、データウェアハウス(DW)の厳格なスキーマオンライト(schema-on-write) とデータレイク(data lake)の柔軟なスキーマオンリード(schema-on-read) という二つの極の間で揺れてきた。DWは構造化データに対し高い品質とガバナンスを提供したが半構造化・非構造化データや大容量・リアルタイム処理には弱く、データレイクはあらゆる形態のデータを安価に保存したものの品質・一貫性の管理ができず、結局データの沼(data swamp) に陥る事例が頻発した。信頼できないデータがレイクに積み上がると、アナリストは毎回ソースを再検証せねばならず、組織全体が同一の数値を共有できない「単一の真実の源泉(Single Source of Truth)」の欠如という問題が生じる。

レイクハウスはこの両者の長所を結合し、レイクの低コストなオブジェクトストレージの上にACIDトランザクション・スキーマ適用・バージョン管理といったDWの信頼性機能を載せた構造である。しかしレイクハウスという保存基盤があるからといって、データが自ずと整うわけではない。「どこまでがソースそのままで、どこから検証を経ており、何が最終消費用か」を組織が約束した標準化された流れの規律が必要である。メダリオンアーキテクチャはまさにこの規律を提供する設計上の慣例(convention)であり、Databricksがレイクハウスの模範パターンとして普及させた。

このパターンの核心的価値は段階的な品質向上(progressive refinement) にある。オリンピックのメダルの等級(銅-銀-金)に由来するように、データはソースから収集される際に最も加工度の低いブロンズに入り、精製・統合を経てシルバーへ昇格し、ビジネス集計・モデリングを経て最終的に金色のゴールドとして完成する。このように段階を明示的に分離すれば、ソースデータの不変保存(監査・再処理が可能)、中間成果物の再利用、消費層の性能最適化を同時に達成でき、データパイプラインの信頼性と保守性が大きく向上する。

2. 全体構造と設計原則

メダリオンアーキテクチャは、ソースシステム(OLTP DB・ログ・IoT・APIなど)から収集されたデータが三つの層を順次通過しながら価値が蓄積されるパイプライン型の構造を持つ。各層は物理的に別個のテーブル(あるいはストレージパス)として保存され、上位層は直下の層を入力とする。全体構造は次のとおりである。

graph LR
  subgraph SRC["ソースシステム"]
    S1["OLTP DB"]
    S2["ログ/イベント"]
    S3["IoT/API"]
  end
  subgraph LH["レイクハウス"]
    B["ブロンズ(Bronze)<br/>ソースそのまま投入"]
    SV["シルバー(Silver)<br/>精製・検証・統合"]
    G["ゴールド(Gold)<br/>集計・ビジネスモデル"]
  end
  subgraph CON["消費層"]
    C1["BIダッシュボード"]
    C2["ML学習/推論"]
    C3["アドホック分析"]
  end
  S1 --> B
  S2 --> B
  S3 --> B
  B -->|"精製(Cleansing)"| SV
  SV -->|"集計(Aggregation)"| G
  G --> C1
  G --> C2
  SV --> C2
  G --> C3

この構造を支える設計原則は次のように要約される。

• 不変性と再処理可能性(immutability & replayability)。 ブロンズはソースを加工せず保存するため、上位層の変換ロジックに誤りが見つかったり要件が変わったりしても、ブロンズを再度読み込んで全層を再構成できる。すなわちブロンズはデータパイプラインの「バックアップ兼リプレイログ」の役割を担う。
• 関心の分離(separation of concerns)。 収集(ingestion)・精製(quality)・活用(serving)という異なる責務を層に分けることで、各段階を独立に開発・テスト・最適化できる。
• 段階的な品質上昇。 層が上がるほど品質と凝集度が高まる。下へ行くほど汎用的・原始的で、上へ行くほど特定のビジネス目的に特化する。
• 単一の真実の源泉。 シルバーという共通の精製基盤をすべてのゴールドが共有することで、部門間の数値の不一致を防ぎ、組織レベルの一貫した指標を保証する。

これらの原則のおかげで、メダリオンは「速く保存し、慎重に消費せよ」という現代のデータエンジニアリングの要求を自然に満たす。ソースは遅延なくブロンズに受け入れてデータ喪失を防ぎ、消費は検証済みの上位層でのみ行われるよう強制することで、収集の俊敏性と活用の信頼性という相反する要求を層の分離で両立させる。

注意すべきは、メダリオンが必ずしも「ちょうど三つの層」を意味するわけではない点である。MicrosoftとDatabricksの双方のガイドが、このパターンは柔軟(flexible) であり、組織の要求に応じて層の数と名称を調整できると明記している。実務ではブロンズの前に生ファイルを受ける「Raw/Landing」領域を設けたり、ゴールドを用途別(BI用・ML用)マートに再分割したりする。核心は層の数ではなく、加工度に応じた明示的な分離とそれに対する組織的合意である。

3. 層ごとの役割とデータフロー

実際のデータが各層でどのような変換を経るかを詳細なプロセスで表すと次のとおりである。

flowchart TB
  R["ソースデータ(構造化/半構造化/非構造化)"] --> I["増分収集(Incremental Ingestion)"]
  I --> B["ブロンズ: append-only投入<br/>+ 投入メタデータ(出所・時刻)を付与"]
  B --> V{"データ品質検証"}
  V -->|"通過"| SV["シルバー: 重複除去・型整合・結合/統合"]
  V -->|"失敗(隔離)"| Q["隔離テーブル(Quarantine)"]
  SV --> A["ビジネス集計・次元モデリング(スタースキーマ)"]
  A --> G["ゴールド: 集計指標・特徴量・マート"]
  G --> O["消費: BI/ML/レポート"]

A. ブロンズ層(Bronze — ソース保存層)。 ブロンズはソースシステムから収集したデータを可能な限り原形のまま(as-is) 投入する着地点である。この層の設計哲学は「変換しない」である。スキーマ変更やクレンジングを最小化し、代わりに投入時刻・ソース識別子・ファイルパスといったメタデータを追加カラムとして付与してデータの系統(lineage)を追跡できるようにする。投入方式は既存レコードを上書きしない追記専用(append-only) が基本であり、これはソースの変更履歴まで保存して監査(audit)と時点再現(time travel)を可能にするためである。

ブロンズを原形保存する理由は再処理の柔軟性にある。たとえばシルバー変換ロジックにバグがあり過去六か月分の指標が誤って計算されていた場合、ソースシステムに再アクセスせずともブロンズだけをリプレイして復旧できる。もし収集段階で既に精製してしまっていれば原本情報が失われ、このような復旧は不可能である。電子商取引企業を例にとると、注文APIのJSON応答をパース・加工せずまるごとブロンズに保存しておけば、後に「決済手段別の返金率」のような新たな要求が生じても過去データから即座に抽出できる。

B. シルバー層(Silver — 精製・統合層)。 シルバーはブロンズの生データを検証・精製・統合して「信頼できる企業ビュー(enterprise view)」を構築する層である。ここで行われる核心的な変換は、(1)欠損・異常値の処理と重複除去、(2)データ型・単位・コード値の標準化、(3)複数のソースを共通キーで結合してエンティティ(顧客・商品・注文)を統合する作業である。品質検証を通過しなかったレコードは捨てずに隔離テーブル(quarantine) へ分離して原因を分析するのが模範的な慣例である。こうすれば不良データが上位へ伝播するのを防ぎつつ、損失なく追跡できる。

シルバーが重要なのは、この層が大半のデータ消費者が共有する共通基盤となるためである。ゴールドが特定部門の特定指標に特化するのに対し、シルバーは「精製されているが、まだ特定の用途に偏っていない」汎用資産である。機械学習エンジニアは自由な特徴量探索のため、しばしばゴールドではなくシルバーを直接用いるが、これはゴールドの集計が原本の細かな情報を失わせるためである。金融業界の場合、複数のコアバンキングシステムの口座・取引データをシルバーで一つの標準取引モデルに統合すれば、以後のリスク・マーケティング・規制報告など多様なゴールド成果物がこの単一基盤の上で一貫して作られる。

C. ゴールド層(Gold — ビジネス消費層)。 ゴールドはシルバーの精製データを特定のビジネス目的に合わせて集計・モデリングした「消費準備完了(business-ready)」データを格納する最上位層である。典型的にはBIツールが高速に照会できるよう事前集計された指標(日別売上・KPI)、分析に適した次元モデル(スタースキーマのファクト・ディメンションテーブル)、あるいはMLモデルがそのまま学習に使える特徴量テーブルの形で構成される。ゴールドの設計目標は読み取り性能と使いやすさであるため、結合を事前に行って非正規化(denormalization)し、よく使う集計を物理化(materialize)する戦略を採る。

ゴールドを用途別に複数持つのが一般的である点も重要である。財務チームの「月次損益マート」、マーケティングチームの「キャンペーン成果マート」、データサイエンスチームの「解約予測特徴量セット」は、いずれも同一のシルバーから派生した異なるゴールドである。こうすれば部門別の要求を独立に受け止めつつ、根本データはシルバーという単一基盤を共有するため数値の不一致が防がれる。下表は三つの層の特性を比較したものである。

区分	ブロンズ(Bronze)	シルバー(Silver)	ゴールド(Gold)
データ状態	ソースそのまま(raw)	精製・統合(cleansed)	集計・モデリング(curated)
主な変換	投入・メタデータ付与	重複除去・標準化・結合	集計・次元モデル・非正規化
スキーマ	ソーススキーマ/緩い	構造化・強制	ビジネス指向
主な消費者	データエンジニア	MLエンジニア・アナリスト	BI・経営層・現場
投入方式	append-only	upsert/merge	overwrite/集計
品質水準	低(保存優先)	中(信頼基盤)	高(完成形)

4. 実装技術と運用パターン

メダリオンアーキテクチャは概念的パターンであるため特定製品に依存しないが、実務の実装ではオープンテーブルフォーマット(open table format) が核心的役割を果たす。Delta Lake・Apache Iceberg・Apache Hudiといったフォーマットはオブジェクトストレージの上でACIDトランザクション・スキーマ進化(schema evolution)・時点照会(time travel)・アップサート(MERGE)を提供し、各層のテーブルを信頼性高く更新できるようにする。たとえばシルバー層で変更データのみ反映するMERGE INTO(upsert)演算は、Delta LakeのACID保証なしに安全に実行するのは難しい。典型的な実装スタックは次の要素で構成される。

• 保存・フォーマット層: オブジェクトストレージ(S3・ADLS・GCS)+オープンテーブルフォーマット(Delta・Iceberg・Hudi)。
• 処理エンジン: Spark・Flink・Trinoなどの分散処理エンジンとSQL変換ツール(dbt)。
• 収集・増分: CDCコネクタ、ストリーミング投入(Auto Loader・Kafka)、宣言型パイプライン(Delta Live Tables)。
• 品質・検証: Great Expectations・DLT expectationsなどで層遷移ゲートを実装。
• ガバナンス・カタログ: Unity Catalog・OneLake・オープンカタログで系統・権限・監査を中央管理。

データフローの効率のためには増分処理(incremental processing) が必須である。毎回全データを再処理するとコストと遅延が急増するため、変更分のみを下位層へ流すCDC(Change Data Capture) とストリーミング投入(例: Spark Structured StreamingのAuto Loader)を組み合わせる。このとき各層をストリーミングで接続すれば、バッチとリアルタイムを単一コードで処理するラムダを超えた統合パイプラインを構成できる。品質規律をコードで強制するため、Delta Live Tables・dbtのテストやGreat Expectationsといったデータ品質フレームワークの期待値(expectation) を層遷移の時点で適用し、不良データが昇格されないようゲートを設ける。

運用の観点では各層の物理的最適化も重要である。ブロンズは小さなファイルが多数生成される傾向があり照会性能が低下するため、定期的に小ファイルを統合するコンパクション(compaction) と照会パターンに合わせたパーティショニング・クラスタリング(例: Z-Order・Liquid Clustering) を適用する。またブロンズは保存コスト最適化のため保持期間を定め古いバージョンを整理(vacuum)する一方、ゴールドは頻繁に照会されるためキャッシュ・物理化ビューで応答速度を高める。このように層ごとに相反する最適化目標(ブロンズ=保存・コスト、ゴールド=性能) を持つ点が、メダリオン運用の核心的な設計ポイントである。

比較: 従来のETL/DWとの違い。 従来のDWは収集前にスキーマを確定しETLで精製してから投入するschema-on-writeであった。この方式は原本を捨てるため要件変更時の再処理が難しく、非構造化データを扱えない。これに対しメダリオンはELT(先に投入し後で変換)の哲学に従い、原本(ブロンズ)をまず保存して変換を層ごとに遅延・分散させる。その結果柔軟性(再処理・新規要求の受容) と拡張性(低コストストレージ) で優位に立つ。ただし層が多くストレージの重複と遅延が生じるトレードオフがある。

比較: データメッシュ(Data Mesh)との関係。 メダリオンが一つのレイクハウス「内部」の垂直的な精製フローを規定する技術的パターンであるのに対し、データメッシュはドメイン別のチームがデータを「製品(data product)」として所有・供給する組織的・ガバナンスのパラダイムである。両者は競合ではなく補完的である。実務では各ドメインチームが自らのデータ製品を内部的にメダリオン構造(ブロンズ→シルバー→ゴールド)で実装する形で結合されることが多い。

比較: ラムダ(Lambda)アーキテクチャとの違い。 かつてリアルタイム分析はバッチレイヤとスピードレイヤを別々に運用しサービング段階で併合するラムダアーキテクチャで実装されたが、これは同一ロジックをバッチ・ストリーミングの二つのコードベースで重複保守せねばならない負担が大きかった。メダリオンはオープンテーブルフォーマットのACIDとストリーミングテーブルを活用して一つの層パイプラインにバッチと増分ストリーミングを統合することで、コードの二重化を排し同一の精製ルールを両方に一貫して適用する。これは「カッパ(Kappa)指向」の単一パイプライン哲学に近い。

具体事例(定量的)。 グローバル小売企業の需要予測パイプラインを例にとると、数百店舗のPOS取引ログ(日あたり数億件)と天候・プロモーションデータがブロンズにそのまま投入される。シルバーでは決済取消・返金を相殺し、商品コードを標準分類体系にマッピングし、店舗マスタと結合して「正規化された日別販売ファクト」を構築する。ゴールドではこれをSKU×店舗×週単位で集計した特徴量テーブルを作り需要予測モデルへ供給する。この構造を導入した組織は、前処理コードの重複排除と増分処理により日次パイプラインの処理時間と再処理コストを数十%短縮し、シルバーという単一基盤のおかげで財務・物流部門が同一の販売数値を共有するようになったと報告している(具体的な数値は組織・環境により異なるため、一般化された傾向として理解すべきである)。

5. 深化: 最新動向とアンチパターン

近年メダリオンアーキテクチャはガバナンス・自動化・リアルタイムの三つの軸で進化している。第一に、DatabricksのUnity CatalogやMicrosoft FabricのOneLakeのように統合カタログ・ガバナンス層が結合し、層間のデータ系統(lineage)・アクセス制御・監査が中央で管理される。かつてはブロンズ/シルバー/ゴールドが単なるフォルダの慣例であったが、今やカタログが各層テーブルの所有者・品質・活用をメタデータとして追跡する。第二に、Delta Live Tables(DLT)のように宣言型パイプラインで層間の変換をコードではなく宣言で定義し、品質期待値・依存関係・増分処理をフレームワークが自動管理する方向である。第三に、ストリーミングテーブルを層ごとに接続して収集からゴールドまで準リアルタイム(near real-time) で流す「ストリーミングメダリオン」が普及しつつある。

反対に、実務で頻発するアンチパターンも明確に認識せねばならない。以下は現場で繰り返し観察される代表的な失敗類型である。

• 過度なブロンズ加工。 収集段階でクレンジング・変換を行い原本を失うと、ロジック変更時の再処理が不可能になり、メダリオンの核心的利点であるリプレイ能力を失う。
• シルバー省略(ブロンズ→ゴールド直行)。 精製・統合層を飛ばすと品質ゲートが消え、各ゴールドがそれぞれ生データを解釈して数値の不一致が再発する。
• 名ばかりの層化。 層ごとの責務・品質基準(SLA)・所有者を文書化・強制しなければ、フォルダが三つに分かれただけの別のデータの沼になる。
• 規模を無視した教条的な三層。 小規模・単純なデータにまで三層を機械的に適用すると、不要な複製・遅延・コストばかりが増える。データ規模と組織成熟度に合わせた層数の調整が推奨される。
• 品質失敗データの無断破棄。 検証失敗レコードを隔離なしに捨てると原因追跡と補正が不可能になるため、必ず隔離テーブルへ分離・保存せねばならない。

6. 考慮事項および示唆点

メダリオンアーキテクチャは単なるフォルダの区画ではなく、データ品質とガバナンスを流れの規律として制度化する戦略である。技術士の観点から導入を検討する際には、次を総合的に判断せねばならない。

• 適用戦略(層設計の柔軟性)。 三層を教条的に強制するよりも、データ特性と活用目的に合わせて層の数・名称を調整すべきである。生ファイル着地用のLandingを追加したり、ゴールドをBI用・ML用に分割したりと、組織の要求を反映したカスタム設計が核心である。小規模・単純なデータには二層へ縮小する判断も必要である。

• トレードオフ(品質 vs コスト・遅延)。 層を多く設けるほど再処理の柔軟性と品質統制力は高まるが、同一データが層ごとに複製されストレージコストと端から端までの遅延(latency) が増加する。増分処理・ストリーミングで遅延を減らし、ブロンズの保持期間(retention)・圧縮(compaction)・ファイル最適化でコストを管理する運用設計を並行せねばならない。

• 展望(ガバナンスとの統合)。 今後メダリオンは単独のパターンではなく、データカタログ・系統・アクセス制御・データ品質自動化と結合したガバナンス体系の一部として定着するであろう。統合カタログが各層の信頼水準をメタデータとして保証すれば、消費者は「このテーブルがどの層のどの検証を経たか」を信頼の根拠とできる。

• 連携技術(テーブルフォーマット・CDC・品質フレームワーク)。 メダリオンの実効性は、ACIDを保証するオープンテーブルフォーマット(Delta・Iceberg・Hudi)、増分を可能にするCDC・ストリーミング、そして層遷移ゲートとしてのデータ品質フレームワークが揃ったときに発揮される。これらなしに層だけを分ければパターンの核心的利点は失われる。

• 運用・観測(Observability)。 層間遷移の成功・失敗、品質指標(欠損率・重複率)、端から端までの遅延、データ鮮度(freshness)を常時監視し、SLA違反時に警報する体系が必要である。隔離テーブルの投入量の推移は、ソース品質の低下を早期に検知する信号として活用できる。

• 組織・ガバナンスの観点。 層の責任主体と品質基準(SLA)を明文化し、データメッシュのドメイン所有権の概念と結合して、各層のデータ製品の所有者・品質・活用ルールを定義せねばならない。技術パターンだけではデータの沼を防げず、組織的合意と運用規律が成否を左右する。

参考資料

• OneLake medallion lakehouse architecture (Microsoft Learn): https://learn.microsoft.com/fabric/onelake/onelake-medallion-lakehouse-architecture
• Describe medallion architecture (Microsoft Learn): https://learn.microsoft.com/training/modules/describe-medallion-architecture/2-describe-medallion-architecture
• Demystifying the Medallion: Practical Insights into the Layers (O'Reilly): https://www.oreilly.com/library/view/building-medallion-architectures/9781098178826/ch02.html

---

一言まとめ: メダリオンアーキテクチャは、レイクハウスのデータをブロンズ(ソース保存)・シルバー(精製・統合)・ゴールド(集計・消費)の層へ段階的に精製し、原本の再処理の柔軟性と消費データの信頼性を同時に確保する多段データ設計パターンである。