現実世界を動かす技術をシェアしよう！～身近なものづくりから最先端テクノロジーまで大募集！～

RAG開発におけるDatabricksメダリオンアーキテクチャの再定義

Posted at 2026-09-06

対象読者

Databricks上でRAGを構築中/検討中で、メダリオンアーキテクチャのBronze/Silver/Goldへの層分けに迷っているエンジニア

この記事を読むとわかること

Databricks公式のメダリオンアーキテクチャがなぜRAG開発にそのまま当てはまらないのか
Bronze/Silver/Goldそれぞれに、生成AI/RAG開発の文脈で何を配置すべきか
なぜその層分け、特に「チャンキングをどの層に置くか」を判断したのか

エグゼクティブサマリ

RAGの開発でDatabricksのメダリオンアーキテクチャに当てはめようとした際、公式の層定義がテーブル(構造化データ)を前提にしており、ドキュメントファイルやチャンキング、ベクトルDBをどこに位置づければよいのかが分かりませんでした。

実践を通じて、私はBronze=生データ(ファイル)、Silver=クレンジングとチャンキング、Gold=ベクトルストア(ベクトルデータベース)と定義することで、実務に即した形に整理できました。

本記事はベストプラクティスを提示するものではなく、実務を通じて得た一つの判断軸を共有するものです。同じ状況に立ったときの判断材料の一つとして参考にしていただければと思います。

背景

メダリオンアーキテクチャは、レイクハウスに格納されているデータの品質を段階的に高めていくためのデータ設計パターンとして、Databricksが提唱しています。データがBronze(未加工)→Silver(検証済み)→Gold(エンリッチ)という複数のレイヤーの検証・変換を経ることで、エンタープライズデータ製品の信頼できる唯一の情報源(Single Source of Truth)を構築することを目的としています。

Databricks公式ドキュメントでは、各層の役割は概ね以下のように説明されています。

層	公式ドキュメントの定義
Bronze	生データをそのまま取り込み。クレンジングや検証は行わない
Silver	クレンジング・重複排除・正規化。データ品質を高める
Gold	集計・ディメンションモデリング。BI/分析向けに最適化

ここで示されている具体例は、customer_transactionsのような顧客・取引データの結合や、account_performanceのような集計テーブルなど、構造化データのテーブルを前提としたものです。

課題認識

私がRAG開発でメダリオンアーキテクチャを採用しようとした際、次の点で判断に迷いました。

ドキュメントファイル(PDF、Wordなど)という非構造化データをどの層に置くべきか
DatabricksのVolumes(非構造化ファイルを格納する機能)がメダリオンアーキテクチャのどこに位置づけられるのか
RAG特有の処理であるチャンキングや、ベクトルDBへの格納をどの層の作業とみなすべきか

Databricks公式のメダリオンアーキテクチャ解説ページを確認しましたが、Volumesという言葉は一度も登場せず、非構造化ファイルの扱いには触れられていませんでした。一方で、同じくDatabricks公式のDelta Lakeアーキテクチャ設計ガイドの中では、「新規のレイクハウスデータにはマネージドテーブルを、ランディングゾーンと生の非構造化データにはマネージドVolumesを使う」という記載があり、Databricks公式の中でも情報が分散している状態でした。

海外に目を向けると、Piethein Strengholt氏がRAGパターンとメダリオンアーキテクチャの対応関係を詳細に論じた記事(後述)を公開しており、Bronzeで生ファイルと業務メタデータを保持する考え方は共通していました。ただし、この記事ではチャンキングをGold層の作業と位置づけており、これは私がSilver層の作業と考えた点と異なっていました。日本語では、この観点で層の対応関係を具体的に整理した記事は見当たりませんでした。

つまり、「メダリオンアーキテクチャとは何か」という一般論は十分に情報があるものの、RAG開発の文脈でBronze/Silver/Goldにどのデータ・処理を配置するか、特にチャンキングをどの層の作業とみなすかという判断は、情報源によって整理が分かれている、というのが私の理解です。

技術選定・意思決定

前述のとおり、公式の層定義は構造化テーブルを前提としており、非構造化ファイルの扱いが明文化されていない。この状況で、非構造化ファイルの置き場所をどう決めたかを整理する。

制約

Databricks環境(Unity Catalog、Volumesが利用可能)
RAG特有の要件(検索精度向上のためのメタデータ付与、チャンキング処理が必要)

選択肢

非構造化ファイルの置き場所として、以下を検討した。

Volumesを非構造化データの受け皿としてBronzeに位置づける
Volumes以外の方式(例:外部オブジェクトストレージを直接参照する等)で管理する

なお、メダリオンアーキテクチャ自体を採用しないという選択肢は検討していない。これはデータエンジニアとしての知見から、Databricks環境における最適なデータ設計パターンとしてメダリオンアーキテクチャを採用することが前提になっていたためである。

判断

Volumesに生ファイル本体を配置し、業務メタデータをテーブルで保持する形でBronzeに位置づけた。Silverではクレンジングとチャンキングを行い、Goldでベクトルストア化する。

判断理由

Volumesは未加工の生データを保持するというBronzeの定義と本質的に合致する
以前、構造化データを集計する際にテストデータとしてCSVファイルの連携を受けた際も、同様にBronze層に位置づけて開発を行っていた経緯があり、「Bronzeは未加工の生データの受け皿である」という扱い方は今回に限った判断ではなく、それまでの実践と一貫していた
SilverでのクレンジングにRAG特有のチャンキングを加えても、「データを品質面・構造面で扱いやすく整える」というSilverの役割の範囲内にあると判断した。チャンキングは検索方式(ベクトル検索かグラフ検索か等)に依存しない、汎用的な加工処理だと捉えている
Goldは「利用(検索)に最適化された最終形」と位置づけられる。構造化データにおけるViewが「クエリ用に最適化された読み取り専用の表現」であるのと同様に、ベクトルDBは「LLMからの検索に最適化された読み取り専用の表現」であり、Gold相当と考えるのが一貫すると判断した
なお、この判断は唯一の正解ではない。Strengholt氏はチャンキング戦略と埋め込みモデルの選定を「アプリケーションごとに要件が異なり一般化しづらい」処理として捉え、Gold層の作業と位置づけている。これはチャンキングという処理の性質づけの違い(汎用的な加工と捉えるか、ユースケース固有の最適化と捉えるか)によるものであり、優劣の問題ではないと考えている(詳細は「得られた示唆」で後述)
Volumes以外の非構造化データ管理方式との比較検討は行っていない

実装

実際に構築したRAGパイプラインの構成を、一般化した形で示す。

Bronze層:Volumes + 業務メタデータ

ドキュメント本体(PDF、Wordなど)はVolumesにそのまま配置する。あわせて、以下のような業務メタデータをテーブルで保持する。

メタデータ項目	内容
連携元システム名	例:SharePoint、Box
ドキュメント種別	例:契約書、マニュアル、議事録
連携日時/更新日時	データが取り込まれた/更新された日時
ファイルID	連携元システム上でファイルを一意に識別するID

これらのメタデータを事前に持たせておくことで、後続のSilver/Gold層での処理やRAGの検索精度向上に活用できると考えている。

Silver層:クレンジング → チャンキング

Bronzeから読み取ったドキュメントに対して、まずクレンジング(不要な記号の除去、フォーマット統一など)を行う。単純にデータ連携だけを目的とする場合はクレンジングのみで完結するが、RAG開発の場合はクレンジング後にチャンキングまで行う。これは、後続のGold層でベクトル化する際の入力単位を、この時点で確定させておくためである。チャンキングの具体的な手法については本記事では扱わない。

Gold層:ベクトルストア化

Silverで生成したチャンクに対してEmbeddingを付与し、Vector Search用のテーブルとして格納する。具体的なテーブル構成は本記事では扱わない。

なお、この「Gold=検索に最適化された最終形」という定義は、ベクトルDBに限定されない。GraphRAGのようにグラフDBを検索先として使う場合も、同様にGoldに位置づけられると考えている。検索方式がベクトルかグラフかは実装の違いであり、「LLM/RAGアプリケーションからの検索・取得に最適化された読み取り専用の表現」という役割は共通している。

実装してみて分かったこと

実際にこの層構成で開発を進めてみて、特に次の2点を強く感じた。

メダリオンアーキテクチャがRAG構築にもそのまま適用できた

構造化データの品質管理のために提唱された設計パターンが、非構造化データ・生成AIの文脈でも「生データ→加工→利用に最適化された形」という段階的な流れとして違和感なく当てはまったことは、大きな発見だった。

Bronze層の業務メタデータが検索の絞り込みに効いた

ドキュメント種別や連携元といったメタデータを検索対象のフィルタとして使うことで、そもそも検索候補に含めるチャンクの母数を減らすことができた。これは検索精度・効率の両面で良い効果だと感じている。

得られた示唆

公式のメダリオンアーキテクチャが掲げる「データ品質の段階的向上」という思想自体は、RAG開発においても通用すると感じている。ただし、対象が構造化テーブルか非構造化ファイルかによって、各層に配置すべきデータ・処理の中身は再定義が必要になる。

特に印象的だったのは、チャンキングをどの層に位置づけるかという論点が、参照した先行事例の間でも一致していなかったことである。以下は優劣の話ではなく、チャンキングという処理の性質づけの違いによるものだと考えている。

観点	Strengholt氏の整理	私の整理
チャンキングの性質	ユースケースごとに戦略が変わる特化処理	検索方式に依存しない汎用的な加工処理
チャンキングの位置づけ	Gold(埋め込みと一体)	Silver(クレンジングの延長)
Gold層の役割	ユースケース固有にチューニングされた最終形	検索に最適化された、構造化データのViewに相当する読み取り専用の表現

Silver層を「複数のユースケースで再利用できる汎用データを整える層」と捉えるか、「検索用の最終加工まで含める層」と捉えるかで、境界線の引き方が変わる。どちらの整理が正しいというよりは、自分のRAGアプリケーションの要件(チャンク戦略をどこまで使い回すか)に応じて、どちらの考え方に近いかを判断する必要がある、というのが得られた示唆である。

まとめ

RAG開発でDatabricksのメダリオンアーキテクチャを使う際の一つの実装知として、Bronze=Volumes+業務メタデータ、Silver=クレンジング+チャンキング、Gold=ベクトルストア(またはグラフDBなど検索に最適化されたストア)という再定義を提示した。

繰り返しになるが、本記事はベストプラクティスの提示ではなく、実務を通じて得た一つの判断軸の共有である。特にチャンキングの位置づけについては先行事例とも判断が分かれる論点であり、読者が同じ状況になった際に、自分のケースではどちらの考え方に近いかを判断するための材料の一つとして使っていただければ幸いである。

参考文献

Databricks公式ドキュメント「メダリオンレイクハウスアーキテクチャとは」 https://docs.databricks.com/aws/ja/lakehouse/medallion
Databricks公式ドキュメント「Phase 6: Design Delta Lake architecture」 https://docs.databricks.com/aws/en/lakehouse-architecture/deployment-guide/delta-lake
Piethein Strengholt「Unstructured Data Management at Scale」(Medium, 2025) https://piethein.medium.com/unstructured-data-management-at-scale-4c612f822f70 ※本文で参照した先行事例