データファブリックとは？構成要素とアクティブメタデータの実装・採用判断を解説

データファブリックは、社内に散らばったデータを物理的に1か所へ集めずに、メタデータを軸として横断参照できる状態を作る統合アーキテクチャを指します。製品名ではなく設計方式なので、「どの製品を買えば実現するか」という問いの立て方をすると失敗します。この記事では構成要素をメタデータ層・仮想化層・ガバナンス層の3層に分解し、Microsoft OneLakeのショートカット制限値やTrinoのプッシュダウン条件といった一次情報の実測値を示しながら、実装時に当たる性能と権限の制約、そして採用を見送るべき条件まで整理しました。

まとめ：データファブリックの実装範囲と採用を見送るべき条件

データファブリックの実体は、メタデータを常時更新し続ける仕組みと、データを移動せずに問い合わせる仮想化層の組み合わせです。両方がそろって初めて「探す時間」と「コピーの数」が減ります。片方だけ導入した場合、カタログが飾りになるか、遅いクエリ基盤が増えるかのどちらかに落ちます。

採用条件はデータソースの数と所有部門の数で判断してください。連携対象が10システム未満で所有部門が1〜2部門に収まるなら、データウェアハウスへの集約のほうが総コストは下がります。逆に、30を超えるソースが複数クラウドと基幹系にまたがり、部門ごとにデータ所有者が分かれている場合は、集約型の設計が破綻する側に回ります。

実装の入口はメタデータの収集です。着手順序は、メタデータ収集、ガバナンス定義、仮想化層の順で固定してください。

データファブリックの定義とデータ統合基盤における実装レイヤの構造

定義が曖昧なまま製品比較に進むと、カタログ製品とクエリエンジンを別々に買って接続できない状態になります。

物理的なデータ移動を置き換える論理データ統合の位置づけと前提条件

従来のデータ統合は、各システムから抽出したデータをETLでデータウェアハウスへ集約し、そこを唯一の参照先にする方式でした。データファブリックはこの前提を変えます。データは元の場所に置いたまま、参照経路とメタデータだけを統合するのが基本形です。

この方式が成立する前提が2つあります。1つは、各データソースが外部からのクエリを受けられること。もう1つは、参照時の遅延を業務が許容できることです。日次バッチで集計する用途なら問題は出にくいものの、画面表示のたびに基幹系へ問い合わせる設計にすると、本番システムへ負荷を持ち込むことになります。

メタデータ層・仮想化層・ガバナンス層の3層に分けた責務の切り分け

構成要素は3層に分けると設計しやすくなります。メタデータ層は、テーブル定義・系譜・利用実績を収集して検索可能にする層。仮想化層は、複数のデータソースに対して単一のSQLインタフェースを提供し、実行時に各ソースへ問い合わせを分配する層。ガバナンス層は、行や列の単位でアクセス可否を判定し、監査ログを残す層です。

この切り分けが効くのは、製品選定のときです。データカタログ製品はメタデータ層だけを、フェデレーテッドクエリエンジンは仮想化層だけを担当します。1製品で3層すべてを埋められるという前提は成り立ちません。層ごとに担当製品を決め、層と層の接続点をAPIで定義するほうが、後から部品を差し替えられます。

ETLやリバースETLと共存させる場合のデータ移動経路の残し方

データファブリックを入れてもETLは消えません。集計済みの指標を毎晩作る処理や、SaaSへ書き戻す処理は、仮想化層では代替できないからです。残すべき経路は2種類あります。第一に、変換コストが高く再計算のたびに待てない集計。第二に、外部SaaSへの書き込みなど参照ではなく更新を伴う処理です。

整理の順序としては、既存のETLジョブを「参照のためだけの複製」と「変換・書き戻しの処理」に分類し、前者から仮想化層へ寄せます。参照専用の複製ジョブは、テーブルの中身をそのまま別の場所へコピーしているだけのことが多く、廃止しても業務影響が出ません。ここを削るだけでジョブ本数が2〜3割減るケースがあります。

アクティブメタデータとナレッジグラフが駆動する自動化の実装経路

「アクティブメタデータ」は、収集したメタデータを人が読むためではなく、システムが判断に使う状態を指す言葉です。実装の中身は系譜の自動収集と、それを使った推論に分かれます。

OpenLineageで系譜を収集する構成と対応コネクタの現状

系譜（リネージ）の収集で事実上の標準になっているのが、OpenLineageの仕様です。2026年8月11日時点でリリースされている系列は1.52系（1.52.0が2026年7月23日公開）で、Apache Airflow・Apache Spark・dbtといった実行基盤側にインテグレーションを持ちます。ジョブの実行イベントを受け取り、入力データセットと出力データセットの関係を記録する構造です。

実装上の分岐点は、収集をジョブ側に仕込むか、SQLのパースで後追いするかの選択です。ジョブ側に仕込む方式は正確ですが、対応していない実行基盤（社内バッチのシェルスクリプト等）は取りこぼします。SQLパース方式は網羅しやすい代わりに、動的に生成されるクエリで系譜が切れます。現実的な折衷は、主要なパイプラインをOpenLineage経由、残りを手動登録とする二本立てで始め、手動登録の比率を四半期ごとに測る運用です。

ナレッジグラフで関係を推定できる場面と推定が外れる典型パターン

ナレッジグラフは、テーブル・カラム・利用者・業務用語をノードとして持ち、関係を辺として持つ構造です。ここに推論を載せると、「このカラムは顧客IDと同義」「このテーブルは個人情報を含む」といった判定を自動で付けられます。効くのは、命名規則がある程度そろっていて、かつサンプル値から型と分布が取れる場合です。

外れるパターンははっきりしています。同じ名前のカラムが部門ごとに別の意味を持つケース、コード値の意味がマスタ外に暗黙で存在するケース、そして歴史的にカラムが転用されているケースの3つです。とくに3つ目は、定義書とも実データとも一致しないため、機械では判定できません。推定結果は候補として提示し、データ所有者が承認する経路を必ず挟んでください。

メタデータの鮮度と網羅率を保つ運用設計と品質指標の具体的な置き方

メタデータは放置すると腐ります。腐り方は2種類で、新しいテーブルが登録されない（網羅率の低下）と、説明文が実態と合わなくなる（鮮度の低下）です。これを検知するために、収集対象システムのテーブル総数に対する登録済み比率と、直近90日以内に更新されたエントリの比率を定点で取ります。

指標を置いたら、閾値を割ったときの担当を決めます。網羅率が下がったときはコネクタの故障か新規システムの追加漏れなので基盤担当。鮮度が下がったときは、業務側のオーナーが不在になっている可能性が高いため、データ所有者の再割り当てが必要です。

データ仮想化層で発生する性能制約とフェデレーテッドクエリの限界

データファブリックの導入で最も想定が外れるのが、仮想化層の性能です。「移動しないから速い」という説明は、単一ソースへの問い合わせにしか当てはまりません。

プッシュダウンが効く範囲とカタログをまたぐ結合で性能が崩れる条件

フェデレーテッドクエリエンジンは、処理をできる限りデータソース側へ委譲することで性能を出します。この委譲がプッシュダウンです。Trinoの公式ドキュメント（Trino 483系・2026年7月18日公開の系列）では、述語・射影・集約・結合・LIMITなど複数の種類が定義されています。

問題は結合です。同ドキュメントは、結合のプッシュダウンが成立する条件として、結合対象のテーブルが同一カタログから取得されることを明記しています。つまり、基幹系のOracleとクラウド上のオブジェクトストレージにまたがる結合はソース側へ委譲されません。両方から必要な行を引き出したうえで、エンジン側のメモリで結合することになります。片側が数億行あれば、そこで詰まります。

対処は単純です。頻発する横断結合の組み合わせを先に洗い出し、その部分だけ物理的に同じカタログへ寄せる。全部を仮想化せず、結合頻度の高い箇所だけ集約する折衷案が現実解になります。

キャッシュとマテリアライズ化で負荷を逃がす設計と保持期間の決め方

もう1つの逃がし方がキャッシュです。Microsoft OneLakeのショートカットには、外部ソースから読んだファイルをワークスペース側に保持する機能があり、公式ドキュメント（日本語版・2026年7月13日時点）では保持期間を1日から28日の範囲で設定できると記載されています。クラウドをまたぐ読み出しの下り転送料を抑える機能です。

ただし制限があります。同ドキュメントによれば、サイズが1GBを超える個々のファイルはキャッシュされません。大きなParquetファイルを1本で置いている構成だと、キャッシュがまったく効かない状態になります。保持期間だけを長くしても解決しないため、ファイル分割の粒度を先に見直してください。目安として、キャッシュを効かせたい対象は数百MB以下に分割しておくと想定どおりに動きます。

データメッシュ・データレイクハウスとの役割分担と併用時の設計境界

この3つは競合ではありません。層が違うため併用が前提で、混同したまま比較検討すると同じ機能を二重に買うことになります。

技術層のファブリックと組織モデルのメッシュを併走させる場合の分担

データファブリックは技術的な仕組みで統合を実現する設計方式、データメッシュはドメインごとにデータの所有と提供責任を分散させる組織モデルです。前者は「どうつなぐか」、後者は「誰が責任を持つか」に答えます。データメッシュアーキテクチャの基本構造と設計原則で扱うドメイン分割やデータプロダクトの考え方は、ファブリックの上に載る運用ルールとして機能します。

併走させる場合の分担は明確にできます。ファブリック側が提供するのは、カタログ登録の口・共通の権限モデル・系譜の記録。メッシュ側が決めるのは、ドメインごとの品質基準とSLA、そして公開するデータプロダクトの単位です。基盤チームが品質基準まで決めると、当事者意識が育たないまま窓口業務で埋まります。

データレイクハウスを保存層に置く3層構成と重複投資が起きる境目

実装としてよく組まれるのが、保存層にレイクハウス、統合とメタデータの層にファブリック、所有と運用のモデルにメッシュを置く構成です。保存形式の選定や移行手順はデータレイクとデータウェアハウス・レイクハウスの違いを実装視点で整理した解説の側に寄せて考えると、層の責務が混ざりません。

重複投資が起きる境目は、保存層の製品が持つカタログ機能と、独立したカタログ製品が並んだときです。どちらも系譜を持つため、系譜の正が2つになります。回避策は、系譜の記録先を1つに決め、もう一方は参照のみに落とすことです。

データカタログ製品との機能重複を切り分ける導入順序と優先度の決め方

データカタログはデータファブリックの一部であって、全体ではありません。この関係を踏まえると、導入順序は「カタログを先、仮想化層を後」になります。理由は、仮想化層が参照先を判断するためにメタデータを必要とするからです。逆順で入れると、接続先を人手で登録し続ける運用が固定化します。

優先度は、社内に「どこにデータがあるか分からない」という声があるかどうかで決めてください。その声が出ている段階ならカタログの単独導入で効果が出ます。すでにカタログが機能していて、それでも部門をまたぐ分析でデータのコピーが増えているなら、仮想化層へ進む段階です。

主要製品の実装アプローチとOSSを組み合わせた代替構成の部品

製品ごとに得意な層が違うため、実装時に効く仕様値を公式ドキュメントの記載に沿って挙げます。

OneLakeのショートカットで参照する構成と数量上の制限値

Microsoft Fabricは、OneLakeという単一の論理データレイクにショートカットを張る形で外部ソースを参照します。日本語版の公式ドキュメント（2026年7月13日時点）が挙げる接続先は、Amazon S3、S3互換ストレージ、Azure Data Lake Storage Gen2、Azure Blob Storage、Dataverse、Google Cloud Storage、Iceberg、OneDriveおよびSharePointです。オンプレミス側へはデータゲートウェイ経由で接続します。

設計時に効く制限値も同ドキュメントに明記されています。1つのFabricアイテムがサポートするショートカットは最大100,000個、1つのOneLakeパスに対しては最大10個、ショートカットのリンク先をさらにショートカットで辿れるのは5段までです。テーブルとして認識させる場合、ショートカットを作成できるのはTablesフォルダーの最上位のみで、サブディレクトリには置けません。加えて、ラテン文字以外を含む名前はサポート対象外です。日本語のテーブル名やフォルダー名をそのまま持ち込む計画だと、ここで作り直しになります。

委任IDモードで呼び出し元の権限が伝わらない設定上の落とし穴

権限まわりで実装者が踏みやすい箇所があります。同じ公式ドキュメントは、Power BIのセマンティックモデル経由でショートカットにアクセスする場合の挙動として、委任IDモードのDirect Lake over SQLやT-SQLエンジンでは、呼び出したユーザーのIDがショートカットのターゲット側へ渡らないと記載しています。代わりに渡るのは、呼び出し元アイテムの所有者のIDです。

これが何を意味するかというと、ソース側で行レベルの権限を設計していても、その判定が効かない経路ができるということです。所有者の権限で読めてしまう以上、ガバナンス層の設計が抜けます。同ドキュメントが示す回避策は、Direct Lake over OneLakeモードを使うか、ユーザーIDモードのT-SQLを使うかの2択です。設計レビューでは、レポートがどちらのモードで動いているかを必ず確認項目に入れてください。

OSSで組む場合の部品構成と自前運用で増える保守工数の見積り

商用製品を入れずにOSSで組む選択肢もあります。2026年8月11日時点の主要な部品は次のとおりです。

• メタデータ層：DataHub（v1.7.0が2026年8月4日公開）またはOpenMetadata（1.13.3が2026年7月31日公開）
• 系譜の収集：OpenLineage（1.52.0が2026年7月23日公開）
• 仮想化層：Trino（483系が2026年7月18日公開）
• 変換の管理：dbtなどSQLベースの変換ツール

それぞれの選定基準はDataHubのOSSメタデータ基盤としての構成と取り込み実装の解説で扱った取り込み方式の違いが参考になります。OSS構成で増えるのは、コネクタのバージョン追従と、認証連携の実装です。商用製品なら設定で済む箇所を、自前でIDプロバイダと接続する作業が発生します。月単位で見ると、基盤担当0.5人月前後の常時稼働を見込んでおくと計画が破綻しません。

データファブリックを採用すべき条件と見送るべき組織規模の目安

データファブリックは万能の設計方式ではなく、成立する規模の下限があります。

導入を見送る判断になる条件と代わりに先行して着手すべき施策の順序

次の状態に当てはまるなら、データファブリックの導入は見送るべきです。第一に、連携対象のシステムが10未満で、しかもすべて同一クラウド上にある場合。この規模ならデータウェアハウスへ集約したほうが、参照性能も運用コストも有利になります。第二に、データの所有部門が1〜2部門しかない場合。ガバナンス層が解く「誰の許可で読むか」という問題がそもそも存在しません。

第三に、既存のテーブル定義書が更新されておらず、データ所有者が特定できない状態。この状態で仮想化層を先に入れると、参照できるが意味が分からないテーブルが大量に見える結果になります。この場合に先行して着手すべきは、主要テーブルへの所有者の割り当てと、定義の棚卸しです。順序としては、所有者の特定、定義の更新、カタログへの登録、その後に仮想化層の検討という並びを守ってください。

段階導入の実装順序と最初の90日間で確認すべき成果指標の定義

採用すると決めた場合、最初の90日で範囲を絞ります。手順は次の順序で進めます。

1. 対象ドメインを1つに限定し、連携ソースを3〜5に絞る
2. メタデータの自動収集を設定し、網羅率を測れる状態にする
3. データ所有者を割り当て、権限モデルを1パターンで確定させる
4. 横断参照が必要なクエリを3本選び、仮想化層で実行して応答時間を計測する
5. 計測値と既存のコピー運用を比較し、範囲を広げるか判断する

成果指標は「探索から利用までの時間」と「同一データの複製本数」の2つに絞ってください。前者は、分析担当が必要なテーブルを見つけてアクセス権を得るまでの日数で測ります。後者は、同じ元テーブルから派生したコピーの本数です。この2つが動かないなら、範囲を広げても結果は変わりません。

外部委託と内製の分界点になる工程と社内に残すべき設計判断の範囲

工程ごとに委託の向き不向きが分かれます。コネクタの実装、認証連携、パイプラインの構築といった作り込みは外部委託と相性が良く、短期間で立ち上げられます。社内に残すべきなのは、データ所有者の割り当てと品質基準の定義です。ここは社内の業務理解がないと決められないため、委託しても差し戻しが続きます。

判断が難しいのが仮想化層の設計です。どのソースを物理集約し、どこを仮想参照にするかは、業務の応答要件と既存システムの負荷余力の両方を知らないと決まりません。この工程は、社内の要件を持つ担当と外部の実装担当が同席して決める形が現実的です。データ分析基盤構築・MLOps構築支援のように、設計段階から入って要件整理とプロトタイプ検証を並行して進める形なら、上の分界点をそのまま体制に落とし込めます。

よくある質問

データファブリックの検討で実際に挙がる質問を5つ取り上げます。

データファブリックとデータ仮想化は同じものですか？

同じではありません。データ仮想化は、複数のデータソースへ単一のインタフェースでクエリを実行する技術で、データファブリックの構成要素の1つにあたります。データファブリックはこれにメタデータの自動収集とガバナンスの仕組みを加えた、より広い設計方式です。仮想化だけを導入した場合、参照はできても「どのデータを使うべきか」の判断材料が残りません。

小規模なデータ基盤でもデータファブリックは効果がありますか？

連携ソースが10未満で所有部門が1〜2部門なら、効果は限定的です。この規模ではデータウェアハウスへの集約のほうが構築も運用も簡単で、参照性能も出ます。検討の目安は、ソース数が30前後を超え、複数クラウドや基幹系にまたがって所有部門が分かれてきた段階です。規模が小さいうちは、データカタログの単独導入から始めるほうが投資対効果は高くなります。

データファブリックを導入すると既存のETLは不要になりますか？

不要にはなりません。廃止できるのは、参照のためだけにテーブルをコピーしていたジョブです。重い集計を事前計算する処理や、SaaSへ書き戻す処理は仮想化層では代替できないため残ります。既存ジョブを「参照用の複製」と「変換・書き戻し」に分類し、前者から順に整理する進め方が現実的です。

Microsoft Fabricを入れればデータファブリックが実現しますか？

製品名にFabricとありますが、導入すれば設計方式が完成するわけではありません。OneLakeのショートカットで外部ソースを参照する仕組みは統合層の一部を担いますが、データ所有者の割り当てや品質基準の定義は製品では埋まりません。加えて、ショートカット数の上限やキャッシュ対象外となるファイルサイズなど、設計に影響する制限値もあります。製品導入と並行して、運用モデルの設計を進めてください。

導入効果はどの指標で測ればよいですか？

「探索から利用までの時間」と「同一データの複製本数」の2つを軸に置いてください。前者は分析担当が必要なデータを見つけてアクセス権を得るまでの日数、後者は同じ元テーブルから派生したコピーの数です。この2つは既存の運用でも計測でき、導入前後で比較しやすい指標になります。

関連記事

• OpenMetadataとは？データカタログOSSの構成・実装手順と採用判断を解説【2026年版】：メタデータ層をOSSで組む場合の構築手順を扱っています。
• データカタログとは？意味・メタデータ管理の仕組みからAI時代の導入判断まで解説：カタログ単独での導入判断を検討する段階の読者向けです。
• データレイクハウス実装の手順6ステップ｜アーキテクチャ選定と移行判断を実務視点で解説：保存層をレイクハウスで構成する場合の移行手順をまとめています。
• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説：残すべきETL処理を見極める際の前提知識になります。
• リバースETLとは？同期モードと差分検出の仕組み・API制約から実装判断を解説【2026年版】：SaaSへの書き戻し経路を設計する場合の制約を整理しています。