Data Meshとは？4原則とデータガバナンスを国内事例つきで解説

本記事には広告が含まれています

2025/07/062026/10/09

「データは新しい石油」と言われて久しいものの、組織が大きくなるほどデータ活用は難しく感じられます。そこで近年注目を集めているのが「Data Mesh（データメッシュ）」という考え方です。

先に結論をお伝えすると、Data Meshとは「データの所有と責任を事業ドメインごとのチームに分散させ、全社共通のルール（ガバナンス）でつなぐ」ためのデータ基盤の設計思想です。特定の製品を導入すれば完成するものではなく、組織の役割分担そのものを変える取り組みである点が、従来のデータウェアハウスやデータレイクとの大きな違いです。

この記事では、その概要から四つの原則、Data as a Productとデータガバナンスの考え方、国内での活用事例、導入のメリット・デメリットまでを網羅的に解説します。分散と集中を両立する次世代データ基盤の設計思想を、やさしく紐解いていきましょう。

Data Meshとは何か？従来モデルとの違い

Data Meshとは、ソフトウェアエンジニアのZhamak Dehghani氏が2019年に提唱したデータプラットフォームの分散アーキテクチャです。最大の特徴は「ドメインチームが自分たちのデータを所有し、製品（Product）として提供する」点にあります。

ETLで一か所に集める従来型とは異なり、データは各チームに残したままAPIやイベントストリームを通じて共有されます。この手法によりビジネス要求の変化へ迅速に対応でき、全社横断のガバナンスも保てます。

また、中央プラットフォームチームは共通インフラと標準を提供するのみで、スキーマ設計や品質担保はドメイン側が責任を持つ点がユニークです。

結果として、巨大組織でも「小さなスタートアップがたくさん存在する」ようにデータが自律的に流通し、モノリシックな基盤のボトルネックを解消できます。こうした思想はマイクロサービスアーキテクチャの成功パターンをデータ領域に転用したものとも言えるでしょう。

中央集権型のデータ基盤が抱える三つの課題

Data Meshが生まれた背景には、「全社のデータを一か所に集め、専門チームが一括で管理する」という従来のやり方の行き詰まりがあります。代表的な課題は次の三つです。

依頼の順番待ち：データの追加や加工の依頼が中央のチームに集中し、現場が欲しいタイミングでデータが手に入らない
業務知識の断絶：中央のデータエンジニアは各事業の業務に詳しいとは限らず、データの意味や品質の良し悪しを判断しにくい
責任の所在があいまい：データを生み出す部門と管理する部門が分かれているため、品質問題が起きても誰が直すのかが決まらない

つまり問題の中心は、処理性能よりも「人と組織」にあります。Data Meshは、データを最もよく知っている現場のチームに所有権と責任を渡すことで、この構造的なボトルネックを解こうとする考え方です。

集中型と分散型を比較：Data Meshのメリット・デメリット

Data Meshが解決しようとする課題を理解するには、データウェアハウスやデータレイクとの比較が役立ちます。以下の表は、主導部門やガバナンスの在り方を整理したものです。

	Data Warehouse	Data Lake	Data Mesh
主導部門	IT部門	IT／分析チーム	各ドメインチーム
スケーラビリティ	垂直	水平（実装により集中管理されがち）	完全水平（分散）
ガバナンス	中央管理	中央＋一部自律	フェデレーションガバナンス
データ提供	ETLで集約	Rawファイル／ストリーム	Data as a Product
品質の責任	中央のデータチーム	中央のデータチーム	データを生み出すドメイン
位置づけ	技術（保存・分析の仕組み）	技術（保存の仕組み）	組織と設計の考え方

Data Lakeはクラウドオブジェクトストレージと分散処理エンジンを組み合わせれば大規模並列処理にも向きますが、多くの導入形態では依然として中央集権的な運用が採られやすい点に留意しましょう。

結果として組織が拡大するとプラットフォームチームがボトルネックになりやすく、この課題を解消するアプローチとしてData Meshが注目されています。
参考：Atlan社ブログ（Data Mesh vs Data Lake）

なお、Data MeshとData Lakeは対立するものではありません。Data Meshは「誰がどう責任を持つか」という設計の考え方で、Data LakeやData Warehouseはその中でデータを保存・処理する手段として引き続き使われます。実際、後述する国内事例でも、クラウドのデータウェアハウスやレイクハウスの上にData Meshを構成しています。

Data Meshのメリット

提供までの時間が短くなる：中央への依頼と順番待ちが減り、ドメインが自分の判断でデータを公開・改善できる
データ品質が上がりやすい：業務を最もよく知るチームが品質に責任を持つため、意味の取り違えや放置された不具合が減る
組織の拡大に合わせて広げられる：事業や部門が増えても、ドメインを追加する形で対応できる
責任の所在が明確になる：データプロダクトごとにオーナーが決まり、問い合わせ先や改善の窓口がはっきりする

Data Meshのデメリットと注意点

各ドメインにデータ人材が必要：事業部門側にデータエンジニアやデータプロダクトの責任者を置けなければ、負担だけが増える
重複投資やサイロ化のおそれ：共通ルールが弱いと、似たデータが各所で作られ、かえって分断が進む
ドメインをまたぐ分析が難しくなる場合がある：顧客IDや商品コードなどの共通キーをそろえておかないと、データ同士を結合できない
立ち上げのコストが大きい：セルフサービス基盤の整備、役割の再定義、評価制度の見直しなど、技術以外の作業が多い
小規模な組織には過剰：数人のデータチームで全社をまかなえている段階では、分散するメリットよりも運用の複雑さが上回る

データファブリックとの違い

Data Meshとよく比較される言葉に「データファブリック（Data Fabric）」があります。どちらも分散したデータを活用しやすくする考え方ですが、力点が異なります。

	Data Mesh	Data Fabric
中心となる発想	組織と責任の分散	技術による統合と自動化
主役	ドメインチーム（人と組織）	メタデータと統合技術
データの扱い	ドメインがデータプロダクトとして提供	散在するデータを仮想的に一つの層としてつなぐ
導入の難所	組織変革・人材配置	メタデータの整備・統合技術の実装

両者は二者択一ではなく、Data Meshの組織設計に、データファブリック的な技術（メタデータの自動収集やデータ仮想化）を組み合わせる企業も増えています。

四つの原則とキーワード（データガバナンス／Data as a Product）

Data Meshを理解するうえで欠かせないのが、次の四原則です。第一に「ドメイン指向の所有」。業務チームが自分たちのデータを直接管理し、素早い意思決定を可能にします。

第二に「Data as a Product」。データを製品とみなし、カタログやSLAを整備して再利用性を高めます。

第三に「セルフサービス型データプラットフォーム」。クラウドインフラやETLテンプレートを共通化し、チームは価値創出に集中できます。

最後に「フェデレーションデータガバナンス」。中央が最小限の標準とガードレールを示しつつ、各ドメインの自律性を尊重するモデルです。

この四原則は、Dehghani氏が2020年12月に公開した論考で整理されたものです。四つは独立した選択肢ではなく、互いに補い合う関係にあります。所有を分散するだけではサイロになるため「プロダクト」として他チームに使ってもらう責任を課し、その負担を減らすために「セルフサービス基盤」を用意し、全体がバラバラにならないよう「ガバナンス」でつなぐ、という構造です。
参考：Data Mesh Principles and Logical Architecture（Zhamak Dehghani, 2020）

Data as a Product：データを「製品」として扱うとは

Data as a Productは、データの利用者を「顧客」と捉え、使いやすさに責任を持つという考え方です。ただテーブルを公開するだけでは製品とは呼べません。一般に、データプロダクトには次のような性質が求められます。

発見できる：データカタログに登録され、検索すれば見つかる
アドレスで参照できる：決まった場所・決まった方法でアクセスできる
信頼できる：鮮度・欠損率などの品質目標（SLO）が示され、守られている
自己記述的である：項目の意味、単位、更新頻度、サンプルが文書化されている
相互運用できる：共通のIDや形式に従っており、他ドメインのデータと組み合わせられる
安全である：アクセス権限や個人情報の扱いが全社ルールに沿って制御されている

これらを担保する責任者として、ドメインごとに「データプロダクトオーナー」を置きます。データの提供側と利用側のあいだで、スキーマや品質、変更時の通知ルールを取り決めた「データコントラクト（データ契約）」を結ぶ方法も広く使われるようになっています。

フェデレーション型データガバナンス：中央で決めること・任せること

Data Meshのガバナンスは、「すべてを中央が承認する」方式でも「各自の自由に任せる」方式でもありません。ドメインの代表者とプラットフォームの担当者が合議で共通ルールを決め、そのルールをできるだけ基盤側で自動的に適用します。役割分担の例は次のとおりです。

全社共通で決めること	ドメインに任せること
顧客ID・商品コードなど共通キーの定義	ドメイン固有のデータモデル・スキーマ設計
個人情報・機密データの分類とアクセス制御の方針	データプロダクトの企画と優先順位づけ
メタデータの必須項目とカタログへの登録ルール	加工ロジックと更新頻度
品質指標の測り方と公開方法	品質目標の具体的な水準と改善活動

例えば、製造部門と営業部門が異なるスキーマを持つ在庫データを扱う際でも、共通メタデータ仕様とAPI契約を守れば統合分析が容易になります。

反対に、標準を破れば自ドメインのユーザー体験が悪化するため、ガバナンスは自然と効く構造です。こうした自己強化サイクルが、Data Mesh導入企業でのスケールアウトを支えています。

国内企業・公共部門の導入事例

日本でも、Data Meshの考え方を取り入れたデータ基盤の事例が公開されるようになってきました。ここでは、公開情報で確認できる国内企業の事例二つと、海外・公共部門の例を紹介します。

NTTドコモ：社内マーケットプレイスでデータを「資産化」

NTTドコモは、数十ペタバイトのデータを保有し、日々数百テラバイトを処理する大規模なデータ基盤を運用しています。報道によると、同社は複数のデータウェアハウスの併用による二重管理や、集中型のETL処理がデータ量の急増に追いつかないといった課題を受け、2024年にSnowflakeとApache Icebergを使った基盤刷新に踏み切りました。

この刷新でData Meshの考え方が採り入れられ、ドメインごとに責任と管理を分散。各ドメインが提供するデータセットを社内の「インターナルマーケットプレイス」にカタログ化し、利用頻度や品質に応じてスコアリングすることで、提供部門に品質維持の責任感を持たせる仕組みが紹介されています。運用工数が最大で5分の1に削減されたとも報告されています。
参考：NTTドコモのデータメッシュ戦略（TECH+, 2025年7月）

東京ガス：ハブドメインで束ねる連邦型の基盤

東京ガスは、あらゆるデータを一か所に集約する統合基盤を運用してきましたが、利用が広がるにつれて中央のリソースがボトルネックになり、データ連携の依頼に順番待ちが生じていました。LNGトレーディング、ガス導管の保守、法人営業、家庭向けサービスなど、事業ごとにデータの要件が大きく異なることも、一律のルールで運用する難しさにつながっていたといいます。

そこで同社は、各事業部門がデータのオーナーシップを持ち、全体を統括する「ハブドメイン」がデータカタログやドメイン間のデータ流通といったガバナンスを担う方式へ転換しました。基盤にはDatabricksを採用し、メタデータとアクセス権限を一元管理する機能を活用しています。既存データを全件移行せず、別の基盤にあるデータを仮想的に参照することで、コストと移行リスクを抑えた点も特徴です。
参考：東京ガスが挑む「データメッシュ」への大転換（NTTデータ, 2026年3月）

NTTデータが支援した海外事例：イタリアの郵便・物流事業者

国内のSIerが関わった事例としては、NTTデータが公開している成功事例があります。イタリア最大の郵便事業者を対象に、Microsoft Azureのデータサービス群とDatabricksを用いてData Meshを実装したもので、ドメイン指向の分散、データのプロダクト化、セルフサービス基盤、フェデレーションガバナンスという四原則に沿って設計されています。

期待される効果として、業務上の洞察を得るまでの応答時間やアプリケーション開発の市場投入までの時間の短縮、より多くの部門へのデータ提供（データの民主化）などが挙げられています。詳細な数値は非公開です。
参考：Data Mesh Application（NTT DATA, 2022）(PDF)

公共部門でのユースケース

またElastic社ブログでは、公共部門におけるData Meshのユースケースが紹介されています。多数の政府機関がそれぞれデータの管理権を保ったままセキュリティデータを横断的に可視化する例や、衛星画像・センサー・SNSの情報を分析して被害の大きい地域を特定し、機関同士で即時に共有する災害対応の例などです。

各機関が自ドメインのデータを保有したまま公開し、全体としてガバナンスとアクセス制御を効かせるという構図は、自治体と中央省庁のあいだのデータ連携にも当てはめて考えることができます。

ただし、記事で紹介されているのは主に米国の政府機関を想定した例で、日本の行政機関での導入事例ではありません。
参考：Elastic Blog

現時点で国内における大規模本番稼働の事例は多くありませんが、通信やエネルギーといった大規模な事業会社から具体的な取り組みが公開され始めており、組織横断データ活用の障壁と効率性のトレードオフを解決する手段として関心が高まっています。

Data Mesh導入の進め方：五つのステップ

Data Meshは一度に全社へ展開するものではなく、小さく始めて広げるのが基本です。一般的な進め方を五つのステップにまとめます。

課題を特定する：ボトルネックが本当に「中央チームへの集中」にあるのかを確認する。性能やコストの問題であれば、基盤の刷新だけで解決できる場合もある
最初のドメインを選ぶ：データ人材がいて、他部門から利用ニーズのあるデータを持つドメインを一つか二つ選ぶ
データプロダクトを定義する：オーナー、利用者、品質目標、公開方法を決め、カタログに登録する
共通基盤と最小限のルールを整える：パイプラインのテンプレート、カタログ、権限管理をセルフサービスで使えるようにし、共通キーやメタデータの必須項目を決める
利用状況を測り、ドメインを増やす：利用数や利用者の満足度を確認しながら、成功パターンを他ドメインへ展開する

東京ガスの事例でも、短期間の概念検証（PoC）を経て、全社共通データを扱うコーポレートドメインから構築を進めています。最初から完全な形を目指さず、段階的に参加者を増やせる点はData Meshの利点です。

成功に導く組織・技術・文化のポイント

Data Meshはツール選定だけでは成立しません。まず経営層が「データはプロダクトである」という共通言語を掲げ、各ドメインにデータオーナーとプロダクトマネージャーを配置する体制が必要です。

技術面では、データカタログ／APIゲートウェイ／ポリシー管理をInfrastructure as Codeで統合し、自動テストとモニタリングを整えると運用負荷を抑えられます。

さらに、スキーマ変更通知やSLIレポートをチャットOpsに連携することで、データ品質の可視化が浸透しやすくなります。

基盤となる製品は一つに決まっているわけではありません。SnowflakeやDatabricksといったクラウドのデータ基盤、各クラウド事業者のデータカタログやアクセス制御のサービス、Apache Icebergのようなオープンなテーブル形式などを組み合わせて構成するのが一般的です。製品選びより先に、「誰がどのデータに責任を持つか」を決めることが重要です。

文化面では「他ドメインに価値を届けると自チームの評価につながる」インセンティブ設計が鍵です。KPIに「再利用数」「データ利用者のNPS」などを組み込むと、プロダクト思考が自然と根づきます。

最後に、PoCではあえてデータスワンプ化の危険が低いワークロードを選び、小さな成功事例を早期に共有することで、抵抗勢力を巻き込みながらスケールアウトが可能です。

よくある失敗パターン

名前だけのData Mesh：既存のデータレイクのフォルダを部門別に分けただけで、所有権や品質責任が現場に移っていない
ガバナンスなき分散：共通キーやメタデータのルールを決めずに権限だけ渡し、部門ごとのサイロが増える
基盤が未整備のまま責任だけ移す：セルフサービスの仕組みがないため、各ドメインがインフラ構築から始めることになり疲弊する
提供する動機がない：他部門にデータを出しても評価されず、データプロダクトが更新されなくなる
ツール導入が目的になる：製品を入れた時点で完了とみなし、役割や評価制度の見直しに手を付けない

どんな組織に向いている？今後の展望

複数の事業部が独立したP/Lを持ち、かつデータをレバレッジして迅速に意思決定したい企業にとって、Data Meshは強力な選択肢です。

一方、単一プロダクトで高速なOLTPが中心のスタートアップでは、導入コストと運用複雑度が上回る場合もあります。

自社に向いているかどうかは、次の点で判断できます。当てはまる項目が多いほど、検討する価値があります。

事業や部門ごとにデータの種類・要件が大きく異なる
中央のデータチームへの依頼が滞留し、提供までに時間がかかっている
事業部門側にデータを扱える人材がいる、または育成する意思がある
経営層がデータ活用を戦略の中核に置き、組織や評価制度の変更に関与できる
データカタログや権限管理など、基盤の基礎がある程度整っている

今後の見通しについては、評価が分かれている点も知っておきましょう。調査会社のGartnerは2022年のハイプ・サイクルで、Data Meshは成熟期に達する前に別の概念に置き換わる可能性があるという見方を示しました。一方で、データをプロダクトとして扱う発想や、連邦型のガバナンス、社内データマーケットプレイスといった中核の考え方は、名称にこだわらず多くの企業のデータ基盤に取り込まれつつあります。「Data Meshを完全な形で導入するか」よりも、「四原則のうち自社に必要な要素をどう取り入れるか」で考えるのが現実的です。

生成AIの普及により高品質データの需要が高まった結果、Data Meshの「ドメイン自律 × ガバナンス」という思想は、AIモデルの説明責任やフェアネス確保とも相性が良く、法規制対応の観点でも注目が高まるでしょう。意味や品質、責任者が明示されたデータプロダクトは、AIエージェントや自然言語での分析機能が参照するデータとしても扱いやすく、国内事例でも生成AI機能の活用が併せて検討されています。

導入を検討する際は、レガシーシステムのデータフローを段階的にストリーム化し、メタデータやポリシーをコードとして一元管理するなど、前提整備を怠らないことが成功の近道です。