メダリオンアーキテクチャにおける Bronze と Silver の狭間

メダリオンアーキテクチャを実運用していると、次のようなデータによく直面する。

• Bronze と呼ぶには、すでに単なる取得結果ではない
• Silver と呼ぶには、まだ再利用可能な形になっていない

本記事では、この 「名前の付かない段階」 を整理し、Silver 層の責務を守るための設計上の方向付けを試みる。

---

前提

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

メダリオンアーキテクチャとは、データを Bronze / Silver / Gold の段階に分け、
加工度と責務を明確化する設計アプローチ¹。

Bronze 層とは？

Bronze 層とは、外部システムから取得したデータを、可能な限り加工せずに格納する層²。
例としては、API レスポンス JSON、生ログ、CSV の取り込み結果などが該当。

Silver 層とは？

Silver 層とは、分析や業務利用を前提に、構造化および品質担保が施されたデータを提供する層³。
本記事では Silver 層を 「下流の利用者が安心して再利用できる状態」 として扱う。

Gold 層とは？

Gold 層とは、特定のユースケースや業務目的に最適化された、集計・加工済みデータを展開する層⁴。
本記事でGold 層は扱わないが、メダリオンアーキテクチャを構成する要素としてここに提示した。

---

問題提起

Bronze ではないが Silver とは呼べない存在

Silver 層の代表的な到達点としては、DWH におけるスタースキーマが挙げられる。（ファクトテーブル／ディメンションテーブル）
これを実現する際、実務ではその前に次のような段階が発生する。

Bronze の様に「生」ではない

• 取得形式は理解されている
• 明らかに不要な項目は除外されている
• 技術的には加工済み

Silver よりも「素材」的

• 分解あるいは結合すれば Silver になり得る
• しかし、そのまま再利用するには大きすぎたり小さすぎたりする
• 完成品ではなく、部材に近い

この段階のデータを Silver に含めると、Silver 層の責務が急速に曖昧になる。
結果として、似ているが微妙に異なる精錬過程が増殖し、再利用性がむしろ下がる。

---

例示

API コールで得られる JSON 群と正規化

たとえば、外部 SaaS の API から以下のような JSON を定期取得しているとする。

{
  "orderId": "A123",
  "customer": {
    "id": "C001",
    "name": "Alice"
  },
  "items": [
    { "productId": "P01", "qty": 2, "price": 100 },
    { "productId": "P02", "qty": 1, "price": 200 }
  ],
  "orderedAt": "2024-01-10T12:34:56Z"
}

この JSON は、取得しただけの状態であり、正しく Bronze 層に属する生データである。
問題は、その次の工程で起きる。

この JSON から 純粋に再利用可能な Silver を一気に精錬しようとすると、次のような分岐が発生しやすい。

• 注文（Order）を中心に据えた Silver
• 顧客（Customer）を中心に据えた Silver
• 商品（Product）を中心に据えた Silver

いずれも単体としては正しい姿だが、そこに至る精錬の観点・粒度・結合方針は微妙に異なる。
結果として、

• 似ているが微妙に異なる精錬過程が増殖する
• Silver 層の責務が肥大化する
• 「どれが求めるデータや精錬ロジックなのか」が分かりにくくなる

という問題を招く。

そこで、Bronze と Silver の間に 素材的な段階 を切り出し、Silver 精錬の共通土台を作る必要が出てくる。

---

提唱

責務分離（仮称: Copper 層）

ここまでの問題は、Silver の定義を曖昧にすれば「無理やり」収めることもできる。
しかしそれは、Silver 層の責務を肥大化させ、利用者に解釈を押し付け、結果として信頼性を下げる。

そこで、次の責務を Bronze と Silver から分離する。

• JSON 構造の理解と安定化
• 要素の分解（ネスト解除・配列展開）
• 粒度の統一（例：1 レコード = 何を表すか）
• Silver 精錬ロジックが増殖しないための共通前処理

この段階は、

• Bronze の「生」ではない（＝取得結果のままではない）
• しかし、即座に業務利用できる Silver でもない

いわば 素材的な層 である。
本記事では、この責務分離の結果として、仮に「Copper 層」と呼ぶ。

Copper は新しい理論ではなく、Silver 層を Silver たらしめるために切り出された設計上の帰結にすぎない。
よって、呼び名はCopper でなくとも構わない。
要は、意味合い・働きに応じた責務の分離が肝となる。

---

まとめ

• Bronze と Silver の間には、素材段階が存在する（仮称: Copper）
• 生データ（Bronze）から即用データ（Silver）へ直結すると、精錬過程が増殖しやすい
• 問題は加工度ではなく、責務の混在にある
• Copper は、その責務を分離した結果である

---

脚注

1. Databricks, Medallion Architecture
   https://docs.databricks.com/lakehouse/medallion.html ↩

2. Databricks, Bronze layer
   https://docs.databricks.com/aws/ja/lakehouse/medallion#bronze ↩

3. Databricks, Silver layer
   https://docs.databricks.com/aws/ja/lakehouse/medallion#silver ↩

4. Databricks, Gold layer
   https://docs.databricks.com/aws/ja/lakehouse/medallion#gold ↩