メダリオンアーキテクチャの概要
メダリオンアーキテクチャは、データレイクハウス（Data Lakehouse）内でデータを
「生（Bronze）」、「クレンジング済み（Silver）」、「集計済み（Gold）」
という3つの品質レベルのレイヤーに分けて管理する、非常に一般的なデータアーキテクチャパターンです。
アーキテクチャの目的
このアーキテクチャの目的は、生のデータをそのままアーカイブしつつ、徐々にデータの品質、信頼性、パフォーマンスを向上させ、最終的にビジネス利用に最適化することです。
そして、このアーキテクチャはオブジェクト指向設計（OOD）の原則と非常に強い思想的な関係性を持っています。
各レイヤーを「責務」を持つコンポーネントとして捉えると、その構造がなぜ堅牢であるかが明確になります。
メダリオンアーキテクチャの詳細
まず、各レイヤーの役割を説明します。
🥉 Bronze (ブロンズ)：生データ
目的
すべてのソースシステムから受け取った「生」のデータを、そのままの形で取り込み、保存します。
状態
未加工、未検証、非構造化（JSON、CSV、ログファイルなど）。
主な処理
データの取り込み（Ingestion）のみ。
役割
歴史的なアーカイブ
「何があっても、大元の生データはここにある」という安心感を担保します。
再処理の起点
下流の処理（SilverやGold）でバグが見つかった場合、このBronzeレイヤーからデータを再処理できます。
🥈 Silver (シルバー)：クレンジング・検証済みデータ
目的
Bronzeレイヤーの生データを「クレンジング」し、検証・整形して、信頼できる**「単一の真実（Single Source of Truth）」**を作ります。
状態
構造化済み、クレンジング済み（NULL除去、重複排除）、エンリッチ済み（他のデータと結合）、正規化または非正規化済み。
主な処理
ETL/ELT、データ品質（DQ）チェック、フィルタリング、結合。
役割
データサイエンティストや機械学習（ML）のトレーニングデータとして利用されます。
Goldレイヤーのデータソース（源泉）となります。
🥇 Gold (ゴールド)：ビジネス集計済みデータ
目的
Silverレイヤーのデータを、特定のビジネス要件に合わせて集計・加工し、BIやレポーティングに最適化されたデータマートを作ります。
状態
高度に集計済み、非正規化済み、パフォーマンス最適化済み。
主な処理
集計（Aggregation）、特定のKPIの算出。
役割
BIダッシュボードや経営レポートの直接的なデータソースとなります。
ビジネスユーザーが直接利用することを前提としています。
オブジェクト指向設計原則との関係性
この3層構造は、複雑なソフトウェアを管理可能にするためのOODの原則と、驚くほど一致しています。
データパイプラインアーキテクチャを 「オブジェクト」や「コンポーネント」の集まり として捉えると、以下の関係が見えてくると思います。
1. 単一責任の原則 (SRP: Single Responsibility Principle)
1つのクラス（モジュール）は、1つの責任だけを持つべきであり、変更理由は1つであるべき。
メダリオンへの適用
・Bronzeレイヤーの責任は、「データの取り込みとアーカイブ」 だけです。
変更理由は「新しいデータソースが追加された」時だけです。
・Silverレイヤーの責任は、「データのクレンジングと統合」 だけです。
変更理由は「データ品質ルールや結合ロジックが変わった」時だけです。
・Goldレイヤーの責任は、「ビジネスKPIへの集計」 だけです。
変更理由は「BIダッシュボードの表示項目が変わった」時だけです。
関係性
もし、Bronzeレイヤーで集計まで行おうとすると（SRP違反）、そのプロセスは「取り込み」と「集計」という2つの変更理由を持つことになり、複雑で壊れやすくなります。
メダリオンアーキテクチャは、SRPに従って責務を明確に分離することで、各レイヤーのパイプラインの保守性を高めています。
2. カプセル化
内部の複雑な状態を隠蔽し、必要なインターフェース（メソッド）だけを外部に公開する。
メダリオンへの適用
各レイヤーは、それより下流のレイヤーに対して、「データ（テーブル）」というクリーンなインターフェースのみを公開します。
Goldの利用者（BIアナリスト）は、Silverレイヤーの内部で「どれだけ複雑なクレンジングが行われたか」を知る必要がありません。
彼らは、カプセル化された「Silver」という高品質なインターフェースを利用するだけです。
同様にして、
Silverの利用者（データサイエンティスト）は、Bronzeレイヤーの内部で「どれだけ“汚れた”JSONデータが取り込まれたか」を知る必要がありません。
関係性
カプセル化により、利用者は自分の関心事（例：BIアナリストならGold）に集中でき、不要な複雑さから守られます。
3. オープン・クローズドの原則 (OCP: Open/Closed Principle)
モジュールは「拡張」に対して開いており（Open）、「修正」に対して閉じている（Closed）べき。
メダリオンへの適用
「Silverレイヤー（単一の真実）」は、一度安定化したら、「修正」に対して閉じているべきです。
ここのロジックを頻繁に変えると、このレイヤーに依存するすべてのGoldレイヤーが影響を受けてしまいます。
でも、「Goldレイヤー」は「拡張」に対して開いています。
ビジネス部門が「新しい分析ダッシュボードが欲しい」と言ってきたら、
既存のGoldパイプラインを「修正」するのではなく、安定したSilverレイヤーをインプットとする 「新しいGoldパイプライン」を「拡張（追加）」
して対応すれば良いのです。
関係性
OCPを適用することで、システムの安定性（Silver） を保ちつつ、ビジネスの変化（新しいGold）にも迅速に対応できるという、
保守性と拡張性の両立が可能
になります。
リスコフの置換原則 (LSP: Liskov Substitution Principle)
サブタイプ（子クラス）は、そのベースタイプ（親クラス）と置換可能でなければならない。
つまり、親クラスとして振る舞うことを期待されているプログラムが、子クラスに置き換わっても正しく動作し続けなければなりません。
メダリオンへの適用
この原則は、レイヤー間の 「データ契約（スキーマと品質）」の進化を規定します。
Bronze（ベースタイプ）をインプットとしていたSilverパイプラインは、
Bronze v2（サブタイプ） に置き換わっても、最低限の契約（v1のスキーマ）が守られていれば壊れてはいけません。
（例: v2で列が追加されるのはOKだけども、v1の列が削除されたらLSP違反）
同様に、Silver v1を見ていたGold（プログラム）は、より品質の高いSilver v2に置き換わっても（置換しても）、期待通りに動作し続けるべきです。
関係性
LSPは、データパイプラインのバージョニングと後方互換性のルールを定義します。
あるレイヤーのスキーマを進化させる際、LSPに違反する変更（例：列の削除、データ型の変更）を行うと、そのレイヤーに依存するすべての上位レイヤー（サブタイプを扱うプログラム）が破壊されます。
メダリオンアーキテクチャは、この契約を守ることで安定性を保ちます。
インターフェイス分離の原則 (ISP: Interface Segregation Principle)
クライアント（利用者）に、利用しないメソッド（機能）への依存を強制すべきではない。あまりに多機能な「ファット・インターフェイス」は分割すべきである。
メダリオンへの適用
これが、SilverとGoldを分離する、最も強力な論理的根拠です。
Silverレイヤーは、クレンジングされた「単一の真実」であり、あらゆる利用者のニーズに応えるため、数百の列を持つ巨大なテーブルかもしれません。
これがまさに、「ファット・インターフェイス」 です。
クライアント（例：営業部門のBIダッシュボード)は、このうち「月別・地域別の売上合計」という3つの列しか必要としません。
もしこのBIダッシュボードにSilver（ファット・インターフェイス）を直接参照させると、
不要な100列以上に依存することになり、クエリのパフォーマンスも悪化します。
関係性
Goldレイヤーは、まさにISPを適用した結果です。
Silverというファット・インターフェイスから、営業ダッシュボードという特定のクライアントが必要とする最小限のインターフェイス（sales_goldテーブル）を分離・集計して提供。
これにより、クライアントは必要なデータにのみ依存でき、パフォーマンスも最適化されます。
依存関係逆転の原則 (DIP: Dependency Inversion Principle)
上位モジュール（ビジネスロジック）は、下位モジュール（技術的詳細）に依存すべきではない。両者とも「抽象」に依存すべきである。
メダリオンへの適用
Silverレイヤーこそが、この 「抽象」レイヤーの役割を果たします。
上位モジュール
Goldレイヤーのビジネスロジック（KPI計算など）
下位モジュール
Bronzeレイヤーの生データ形式（JSON、CSVなど）
悪い設計（DIP違反）
Goldレイヤーが、Bronzeの生JSONのネスト構造を直接知っていて、それをパースするロジックを持つような状態。
これでは、生データの形式が変わる（下位モジュールの変更）たびに、Goldのビジネスロジック（上位モジュール）が壊れます。
関係性
メダリオンアーキテクチャは、
Silverレイヤーという「抽象（クリーンなテーブルスキーマ）」
を定義します。
Gold（上位）は、Silverのスキーマにのみ依存します。
Bronze-to-Silverパイプライン（下位）も、Silverのスキーマを「出力先」として依存します。
このように、依存関係が Bronze → Silver ← Gold と逆転することで、ビジネスロジック（Gold）は、生データの汚さや変更（Bronze）から完全に隔離・保護されます。
コンポーネント凝集原則との関係性
上記でSOLIDとの関係性を紹介したので、コンポーネントの凝集原則との関係性も触れておきます。
1. CCP (Common Closure Principle / 閉鎖性共通の原則)
同じ理由で、同時に変更されるクラスは、同じコンポーネントにまとめる。
メダリオンへの適用
これはGoldレイヤーのパイプライン設計で特に重要です。
事例
「売上ダッシュボード」用のGoldパイプラインを考えます。
「税率の計算ロジック」と「割引率の計算ロジック」は、どちらも
「売上計算ルールの変更」という単一のビジネス理由によって、必ずセットで変更されます。
関係性
CCPは、これら2つの変換ロジックを、単一のsales_gold_pipelineという コンポーネント（責務のまとまり） にグルーピングすることを推奨します。
もしこれらを別々のパイプラインに分離してしまうと、変更時に片方の修正を忘れる可能性があり、保守性が低下します。
2. CRP (Common Reuse Principle / 共通再利用の原則)
一緒に再利用されるクラスは、同じコンポーネントにまとめる。
メダリオンへの適用
これはSilverレイヤーのパイプライン設計で特に重要です。
事例
複数のGoldパイプライン（例：売上分析、顧客分析）が、データをクレンジングするために「住所の正規化ロジック」と「電話番号の正規化ロジック」を必ずセットで再利用します。
関係性
CRPは、これら2つの再利用ロジックを、address_cleaning_componentのような共通コンポーネントにグルーピングすることを推奨します。
これにより、Goldパイプラインは
「顧客ランク計算（CCP）」のようなビジネスロジックと、「住所クレンジング（CRP）」のような汎用ロジックを明確に分離
できます。（特性の違うものを境界で分ける）
3. REP (Reuse-Release Equivalence Principle / 再利用・リリース等価の原則)
再利用の単位と、リリースの単位は等しくなければならない。コンポーネントはバージョン管理され、リリースノートが提供されるべき。
メダリオンへの適用
これは、上記のCRPで定義した 共通コンポーネントの「ガバナンス」 です。
事例
address_cleaning_componentは、勝手に修正されてはいけません。
v1.0.0、v1.1.0のように、明確にバージョン付けされてリリースされるべきです。
関係性
REPを適用することで、データパイプラインの依存関係地獄を防げます。
Goldレイヤーのパイプラインは、「address_cleaning_component:v1.0.0に依存する」と明示的に宣言します。
これにより、プラットフォームチームがv1.1.0をリリースしても、既存のGoldパイプラインは意図せず壊れることがなくなり、安定性が飛躍的に向上します。