Bronze / Silver / Gold：メダリオン層の考え方
Stage 3 — 第3章 | データマネジメント入門 推定学習時間：35〜45分 | 難易度：★★★☆☆
この章で学ぶこと
レイク・DWH・マートの 大枠 を押さえたら、次は 層の名前 です。 Databricks 等で広まった メダリオンアーキテクチャ（Medallion Architecture） は、Bronze → Silver → Gold と、データを 段階的にきれいにする 命名規則です。
さくら商事では、staging テーブルと mart が混在し、「これは生データ？ クレンジング済み？ 公式？」 が一目で分かりませんでした。
この章を終えると、こんなことができるようになります：
- Bronze / Silver / Gold の 目的と中身 を説明できる
- メダリオン層と lake/DWH/mart の 対応関係 を説明できる
- dbt の
staging/martsフォルダが どの層に相当するか を説明できる（実装は別トラック） - 層を混ぜると起きる品質・ガバナンス問題を具体例で説明できる
1. orders が 4 種類ある
山田さんが BigQuery を検索したところ、注文っぽい表が 4 つ見つかりました。
| テーブル | 中身 | 誰が作ったか |
|---|---|---|
raw_shopify_orders |
JSON ほぼ生 | DE・取込 |
stg_orders |
型変換済み | AE |
int_orders_cleaned |
テスト注文除外 | AE |
mart_finance_orders |
経理向け粒度 | AE + 経理 |
どれを触ればいいか分からず、山田さんは 一番上の raw を JOIN してしまい、テスト注文が売上に混ざりました。
鈴木
「層が 名前で分かる ようにしよう。Bronze / Silver / Gold で。」
2. メダリオン層
メダリオンは 品質と利用目的が段階的に上がる 3 層（+ 場合により Raw 入力）です。
| 層 | 別名イメージ | 中身 | 品質 | 主利用者 |
|---|---|---|---|---|
| Bronze | Raw | ソースのほぼそのまま | 低（欠損・重複あり） | DE |
| Silver | Cleaned | 型・キー・重複処理済み | 中（分析可能） | AE |
| Gold | Curated | 業務・指標向け | 高（公式提供可） | アナリスト、BI |
次の図は、さくら商事の注文データが どの段階を経て公式マートになるか の標準パターンです。
(Raw)
ソースそのまま"] S["Silver
(Clean)
型・キー・重複処理"] G["Gold
(Curated)
公式提供・指標"] B --> S --> G Q["品質 ↑"] B -.-> Q G -.-> Q classDef bronze fill:#ecfeff,stroke:#0891b2,color:#1f2937 classDef silver fill:#f5f3ff,stroke:#7c3aed,color:#1f2937 classDef gold fill:#f0fdf4,stroke:#16a34a,color:#1f2937 class B bronze class S silver class G gold
利用者は原則 Gold（または mart_*） から触る。 Bronze は DE のデバッグ用、Silver は AE の中間作業場です。
3. 各層でやること・やらないこと
3.1 Bronze（Raw）
| やる | やらない |
|---|---|
| ソースからの取込 | ビジネスルールの適用 |
| 到着時刻・ソース ID の付与 | テスト注文除外（Silver 以降） |
| スキーマ変更の履歴保持 | 会議数字の提供 |
さくら商事: bronze_shopify_orders, bronze_google_ads
3.2 Silver（Cleaned）
| やる | やらない |
|---|---|
| 型変換、主キー付与 | 部門別 KPI の最終定義 |
| 重複排除、基本的 NULL 処理 | セマンティックレイヤー公開 |
| テーブル間 JOIN の準備 |
さくら商事: silver_orders, silver_order_lines
3.3 Gold（Curated）
| やる | やらない |
|---|---|
| 公式指標向け粒度 | ソース生データの長期保管（Bronze 担当） |
| 部門マート、ディメンション | 個人探索用の乱立 |
| 品質テスト、カタログ登録 |
さくら商事: mart_finance, mart_marketing（Gold 相当）
4. lake / DWH / mart との対応
| 前章の概念 | メダリオンでの位置 |
|---|---|
| レイク（オブジェクト） | Bronze の 物理入力 になりがち |
| DWH | Silver〜Gold を 含む 分析 DB |
| データマート | Gold 層 の代表 |
完全な 1:1 ではありませんが、会話では次のように言い換えられます。
「lake に置いた raw CSV が Bronze。BigQuery で整えたのが Silver。会議で使う
mart_financeが Gold。」
5. dbt との対応（概念のみ）
dbt は SQL ベースの変換ツールです。本トラックでは書き方を扱いません。 フォルダ構成とメダリオンの 対応だけ 押さえてください。
| dbt レイヤ（典型） | メダリオン | さくら商事の例 |
|---|---|---|
sources / raw |
Bronze 入力 | Shopify source |
staging |
Bronze〜Silver | stg_shopify_orders |
intermediate |
Silver | int_orders_cleaned |
marts |
Gold | mart_finance |
sources → staging → intermediate → marts
↓ ↓ ↓ ↓
Bronze Silver Silver Gold
現場メモ
dbt を入れる = メダリオンが自動で完成、ではありません。 層の意味とオーナー を決めてから、ツールはその規約を enforce する、が順序です。
6. 層を混ぜると起きること
| 反パターン | 結果 |
|---|---|
| Bronze を Looker 直結 | テスト注文・重複が KPI に |
| Gold に手修正 | リネージ断絶、監査不能 |
| Silver を 10 人が各自改変 | 野良マート化 |
層名なし orders_v2_final |
山田さんインシデント再発 |
さくら商事では 命名規約 を導入しました。
| プレフィックス | 層 |
|---|---|
bronze_ |
Bronze |
silver_ |
Silver |
mart_ / gold_ |
Gold |
7. 品質・ガバナンスとの接続
| 層 | 品質期待 | ガバナンス |
|---|---|---|
| Bronze | 取込成功、件数ログ | DE 監視 |
| Silver | スキーマテスト | AE レビュー |
| Gold | ビジネスルールテスト | スチュワード承認、SSOT |
Stage 4 で学ぶ 品質 6 軸 は、層が上がるほど要求が厳しくなります。
体系コラム：カリキュラム上の位置づけ
| 項目 | 内容 |
|---|---|
| Stage / 章 | Stage 3 — 第3章「メダリオン層」 |
| 今回の論点 | Bronze / Silver / Gold で 層の意味 を固定し、混在を防ぐ |
| DAMA 領域 | データ統合、データ品質（層ごとの期待値） |
| ライフサイクル | 加工段階の 段階的な品質昇格 |
| 前章との接続 | レイク・DWH・マート の三層を、運用上の 命名と責任 に落とす |
| 次章への伏線 | テーブル・ビュー・MV — Gold 層の 物理オブジェクト選定 |
コラム：さくら商事メモ — orders が 4 種類あった日
鈴木さんが棚卸ししたところ、orders という名前のオブジェクトが 4 つありました。Bronze の生 JSON、Silver のクレンジング済み、Gold の公式マート、個人 sandbox のコピー——利用者は同じ「orders」と呼んでいました。
山田さんは sandbox を使い、経営会議用の数字を誤ってそこから出してしまいました。層ラベルがなければ、名前だけでは正本かどうか分かりません。
対策として、Gold のみ mart_* プレフィックス、Bronze/Silver は raw_* / int_* と命名規則を統一。カタログに「会議利用可」フラグを付けました。メダリオンは流行語ではなく、どの層を触っていいか を全員に示す看板です。
まとめ
| 層 | 一行定義 |
|---|---|
| Bronze | ソースの記録。触るのは主に DE |
| Silver | 分析可能なクリーン層。AE の作業場 |
| Gold | 公式提供・指標向け。会議はここ |
この章のキーメッセージ：
メダリオンは 流行の名前 ではなく、「生と公式の間に段階を置く」設計です。 dbt の staging/marts はその 実装の一例 であり、層の意味が先、ツールは後です。
次に読む
- 前章: レイク・DWH・マート
- 次章: テーブル・ビュー・MV の使い分け
- 関連: CTE とサブクエリ（analytics）
確認問題
問題 1
山田さんが raw_shopify_orders（Bronze）から直接売上を集計し、テスト注文が混ざった。
最も適切な再発防止 はどれですか。
A. raw テーブルを削除する
B. 利用者は Gold / mart_* から取得するルールと権限を整える
C. テスト注文を本番 DB に残す
D. メダリオンをやめて 1 表に統合する
正解: B
解説: Bronze は 意図的に汚い 層です。層の意味とアクセス設計で防ぎます。A はデバッグ不能、C/D は問題悪化です。
問題 2
dbt の staging フォルダのモデルが、メダリオンで 最も近い 位置はどれですか。
A. Gold
B. Bronze〜Silver（取込直後の整形）
C. OLTP 本番
D. セマンティックレイヤー
正解: B
解説: staging は ソースに近い整形 です。Gold は marts、セマンティックレイヤーはその上（Stage 2）です。
問題 3
「Gold 層だから品質は自動的に保証される」という理解について。
A. 正しい。Gold と名付ければテスト不要
B. 不十分。Gold には ビジネスルールテスト・オーナー承認・カタログ が別途必要
C. 誤り。Gold は Bronze より品質が低い
D. 関係ない。品質は統計検定のみ
正解: B
解説: 層は 期待値のラベル であり、テストとガバナンスなしでは Gold もただの接頭辞です。
用語メモ（この章）
| 用語 | 意味（この章での使い方） |
|---|---|
| メダリオンアーキテクチャ | Bronze / Silver / Gold で段階的に品質を上げる設計 |
| Bronze | ソースに近い raw 層 |
| Silver | クレンジング・統合済みの中間層 |
| Gold | 業務・指標提供向けの curated 層 |
| staging（dbt） | ソース取込直後の変換モデル。Silver 相当が多い |