データメッシュとは？4原則とデータプロダクトの設計、データレイク・ファブリックとの違い

データメッシュは、分析用データの所有と提供責任を中央のデータチームから業務ドメイン（注文・在庫・会員などの事業領域）へ移し、各ドメインがデータを「プロダクト」として公開する分散型のデータアーキテクチャです。Thoughtworks の Zhamak Dehghani 氏が2019年5月に martinfowler.com で発表し、2020年12月3日の続編で4原則と論理アーキテクチャを定めました。

以下では原典の4原則に加え、2026年9月公開の記述標準 ODPS v1.1.0 でデータプロダクトを書き、全社ルールをCIで検査するコードを示します。

まとめ：データメッシュの要点と採用を判断する条件

• データメッシュは製品名ではなく、データの所有をドメインへ分散させる組織とアーキテクチャの設計方式です。
• 4原則は、ドメイン指向の分散所有、プロダクトとしてのデータ、セルフサービス型データプラットフォーム、連合型の計算的ガバナンスです。4つは組で採用します。
• 期待できるのは、中央チームへの依頼集中の緩和と、業務知識をデータ定義に反映することによる品質改善です。代わりに、ドメインごとのエンジニアと共通基盤への投資が要ります。
• データプロダクトの記述には ODPS（データプロダクト）と ODCS（データ契約）という標準があり、全社ルールはCIでコードとして検査できます。
• データエンジニアが数人で、ドメインが数個しかない組織には過剰です。中央チームの処理待ちが常態化してから検討します。

データメッシュの定義と、中央集権型のデータ基盤が行き詰まる理由

データメッシュが解こうとしたのは、データレイクやデータウェアハウスの性能ではなく、1つの中央チームが全社のデータを取り込み・整形・提供する体制の限界です。2019年の原典「How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh」（5月13日から20日にかけて4回で掲載）は、従来の企業データ基盤に共通する失敗の型を3つ挙げています。

• 集中型でモノリシック：全ドメインのデータを1つの基盤へ集めるため、データの種類と利用者が増えるほど取り込みと変更が詰まる
• パイプラインの工程分割：取り込み・加工・提供という技術工程でチームを分けるため、新しいデータを1つ足すだけで全工程の変更が必要になる
• サイロ化した専門チーム：データ基盤のエンジニアは業務の意味を知らず、業務側のチームには正しいデータを提供する動機がない

最も根深いのは3つ目です。注文の「キャンセル」の確定条件は注文ドメインの業務知識に依存し、中央チームが正しく整形するには、その定義を業務側から共有してもらう必要があります。データメッシュは、この知識を持つ側に提供責任ごと移す発想です。

2020年の続編「Data Mesh Principles and Logical Architecture」は、運用データと分析データの分断（the great divide）を出発点に、分析データの所有と処理をドメイン単位で分け、相互につながる「メッシュ」として運用することを定義の中核に置いています。

データメッシュの4原則と原典の定義

原典の英語名は、domain-oriented decentralized data ownership and architecture、data as a product、self-serve data infrastructure as a platform、federated computational governance です。1つ目が所有の分散で、残る3つは分散で生じるサイロ化・運用コスト・相互運用性の問題に答える原則です。原典は4つを、揃って初めて必要十分（collectively necessary and sufficient）と位置づけています。

ドメイン指向の分散所有：ソース寄りと利用者寄りのデータ

データの境界を、技術工程ではなくドメイン駆動設計（DDD）の業務境界で切ります。原典は、業務システムの事実をそのまま反映したソース寄りのドメインデータと、複数ドメインを組み合わせて特定の用途向けに作る利用者寄りの共有データを区別しています。ODPS v1.1.0 の type 項目も、代表値に sourceAligned・aggregate・consumerAligned の3つを挙げています。パイプラインはドメイン内部の実装に格下げされ、注文ドメインは注文データの加工を自分たちのコードとして持ちます。

プロダクトとしてのデータ：原典が挙げる6つの品質

各ドメインがばらばらの形式で出すと利用者は使えないため、2019年の原典はドメインのデータを社内向けの「プロダクト」として扱い、次の品質を求めています。

2022年3月刊の書籍 『Data Mesh: Delivering Data-Driven Value at Scale』（O’Reilly Media） では、これが「Baseline Usability Attributes of a Data Product」として整理し直されています。とくに Discoverable と Inter-operable を欠くと、分散させた分だけサイロが増えます。

セルフサービス型データプラットフォーム：3つのプレーン

ドメインごとに基盤をゼロから組ませると重複投資になるため、共通部分はプラットフォームチームが提供し、ドメインは宣言的な設定だけでデータプロダクトを作れるようにします。2020年の原典はプラットフォームを3つのプレーンに分けています。

• Data infrastructure provisioning plane：ストレージ、アクセス制御、オーケストレーション、分散クエリエンジンなどの基盤を払い出す
• Data product developer experience plane：データプロダクト開発者が普段使う面。宣言的なインターフェースでライフサイクルを管理し、全社標準を自動で組み込む
• Data mesh supervision plane：データプロダクトのつながり全体（メッシュ）に対する検索や横断的な把握を提供する

書籍ではこの3つが Data Infrastructure (Utility) Plane、Data Product Experience Plane、Mesh Experience Plane に改名されています。2019年の原典は、基盤に「ドメイン固有の概念や業務ロジックを含めない」ことを鍵に挙げており、プラットフォームチームが加工ロジックまで引き受けたら中央集権型への逆戻りです。

連合型の計算的ガバナンス：全社共通ルールの決定範囲

ガバナンスはドメイン代表とプラットフォーム担当者の連合チームが決め、プラットフォームがコードとして自動実行します。2020年の原典は従来型との違いを次のように対比しています。

• データ品質：中央チームが品質を担保する → 連合チームは「品質をどう定義するか」だけを決める
• セキュリティ・法令対応：中央チームが対応する → 連合チームは要件を定義し、プラットフォームが組み込んで監視する
• データモデル：全社統一の正規モデルを作る → 複数ドメインの境界をまたぐデータ要素（polyseme。例：複数ドメインに現れる「顧客」）のモデリングを担う

全社で揃えるのは、相互運用に必要な最小限（ID体系、型、アクセス制御、メタデータの必須項目）に絞ります。それ以外をドメインに委ねられない組織では、データメッシュは成立しません。

データメッシュのメリットと、導入で増えるコスト

期待できるものは2つです。1つは中央チームへの依頼集中を緩和できることです。新しいデータを公開するのに中央の取り込み・加工・提供の全工程を通す必要がなくなり、ドメインが自分の判断で出せます。もう1つは業務の意味を知る人がデータを出すことによる品質で、「キャンセルの確定時点」のような定義の取り違えが減ります。

代わりに増えるコストは、ドメインごとのデータエンジニアの人件費、共通基盤（3つのプレーン）の構築・運用費、そしてドメイン間で形式がずれないようにするガバナンスの手間です。Google Cloud の解説も、最大の課題の1つに企業文化の変革（一元的なデータチームが管理を手放すこと）を挙げ、データセキュリティの確保や分散システムの管理といった技術面の課題も挙げています。

同じ解説は、初期のメリットは金銭的でないことが多いとして、データ配信の速度、データプラットフォームを使うチームの数、データへの信頼を成功の指標に挙げています。社内なら「公開依頼から利用開始までの日数」「利用チーム数」「定義の問い合わせ件数」を導入前から測っておかないと、効果を後から説明できません。

データプロダクトを構成する要素と、ODPS・ODCSによる記述

2020年の原典はデータプロダクトを「アーキテクチャ量子」（architectural quantum）、つまり独立してデプロイできる最小単位と位置づけ、コード（加工パイプライン・提供API・ポリシーの強制）、データとメタデータ（スキーマ・意味の定義・品質指標）、それらを動かすインフラの3要素をひとまとめにしています。

ODPS v1.1.0で書くデータプロダクト定義

この記述の標準は、Linux Foundation 傘下の LF AI & Data のプロジェクト Bitol が策定しています（2026年6月に Incubation を卒業し最上位の Graduate 段階）。データプロダクト用の Open Data Product Standard（ODPS） は2026年9月8日に v1.1.0 が公開されました。公式JSON Schemaで必須なのは apiVersion・kind・id の3項目だけです。

注文ドメインのソース寄りデータプロダクトを書くと、次のようになります。

apiVersion: v1.1.0
kind: DataProduct
id: 7f3c2a10-orders-daily
name: 注文日次サマリー
version: 1.2.0
status: active
domain: sales
type: sourceAligned
team:
  name: sales-data
  members:
    - username: tanaka
      role: owner
outputPorts:
  - name: orders_daily
    version: 1.2.0
    type: tables
    contractId: orders-daily-contract-v1
support:
  - channel: "#sales-data"
    url: https://example.slack.com/archives/C0123

outputPorts が利用者に公開する出口で、contractId で後述のデータ契約にひも付けます。team と support は原典の Discoverable（誰が持ち、どこで聞けばよいか）に対応します。support の各要素は channel と url の両方が必須です。公式スキーマはトップレベルで未定義の項目を受け付けない（additionalProperties: false）ため、独自項目は customProperties に入れます。

データ契約（ODCS）との役割分担

ODPSが「どのドメインのどのプロダクトか、出口はどこか」を記述するのに対し、出口ごとのスキーマ・品質ルール・SLAを記述するのが Open Data Contract Standard（ODCS）で、2026年9月8日に v3.2.0 が公開されています。1つのデータプロダクトが複数の出力ポートを持ち、ポートごとに契約を1つ持つ関係です。ODCSのYAML構造とdbtでスキーマ違反をビルド失敗にする実装は、データ契約（Data Contract）とは？ODCSとdbtでスキーマ破壊を止める実装を解説【2026年版】で扱っています。

連合型ガバナンスをCIで機械検証する実装例

計算的ガバナンスを最小構成で試すなら、全ドメインのデータプロダクト定義を1つのリポジトリに集め、プルリクエストごとに全社ルールを検査するのが早道です。次のスクリプトは、ODPSの公式JSON Schema（v1.1.0）による構造検査に加えて、連合チームが合意した3つのルール（オーナーの明記、問い合わせ窓口、公開中の出力ポートには契約が必須）を検査します。スキーマは公式リポジトリの v1.1.0 タグにある schema/odps-json-schema-v1.1.0.json を、スクリプトと同じディレクトリに置きます。

import json
import sys
from pathlib import Path

import yaml
from jsonschema import Draft201909Validator

# 全ドメイン共通で強制するルール（連合型ガバナンスで合意したもの）
REQUIRED_OWNER_ROLE = "owner"
PUBLISHED = {"active", "deprecated"}

schema = json.loads(Path("odps-json-schema-v1.1.0.json").read_text(encoding="utf-8"))
validator = Draft201909Validator(schema)


def check(path):
    doc = yaml.safe_load(path.read_text(encoding="utf-8"))
    errors = [f"schema: {e.message}" for e in validator.iter_errors(doc)]
    if errors:
        return errors
    roles = [m.get("role") for m in (doc.get("team") or {}).get("members") or []]
    if REQUIRED_OWNER_ROLE not in roles:
        errors.append("policy: team に owner がいない")
    if not doc.get("support"):
        errors.append("policy: 問い合わせ窓口（support）が無い")
    if doc.get("status") in PUBLISHED:
        for port in doc.get("outputPorts") or []:
            if not port.get("contractId"):
                errors.append(f"policy: 公開中の出力ポート {port.get('name', '(名前なし)')} に契約が無い")
    return errors


failed = False
paths = sorted(Path("products").glob("*.yaml"))
if not paths:
    print("NG: products に検査対象の .yaml ファイルがありません", file=sys.stderr)
    sys.exit(1)
for path in paths:
    errors = check(path)
    print(f"{path.name}: {'OK' if not errors else 'NG'}")
    for e in errors:
        print(f"  - {e}")
    failed = failed or bool(errors)
sys.exit(1 if failed else 0)

検査対象として、上の注文プロダクトを products/orders.yaml に、オーナーと問い合わせ窓口を書き忘れた施策ROIプロダクトを products/campaign.yaml に置きます。

apiVersion: v1.1.0
kind: DataProduct
id: 9a51e0d2-campaign-roi
name: 施策ROI
status: draft
domain: marketing
type: consumerAligned
outputPorts:
  - name: campaign_roi
    version: 0.1.0

実行前に python3 -m pip install jsonschema==4.25.1 PyYAML==6.0.3 で依存パッケージを導入し、スクリプト・スキーマ・productsディレクトリを置いたディレクトリから実行します。以下は Python 3.9.6 での実行結果です。

$ python3 mesh_policy.py
campaign.yaml: NG
  - policy: team に owner がいない
  - policy: 問い合わせ窓口（support）が無い
orders.yaml: OK
$ echo $?
1

終了コードが1になるため、CIの必須チェックに設定すれば、ルール違反の定義はマージできなくなります。スキーマにない owner: をトップレベルに書いた定義は、公式スキーマ側で Additional properties are not allowed ('owner' was unexpected) として弾かれ、url を書かずに support を置いた定義も 'url' is a required property で弾かれました。

ルールの中身は連合チームが決め、実行はプラットフォームが全ドメインに一律で行う、という分担がこの構成の要です。

データレイク・データファブリック・データレイクハウスとの違い

データメッシュは組織の分け方、データレイクやレイクハウスはデータの置き方を決める方式で、比べる軸が違うため多くは併用になります。

データレイクは保存の仕組みで、メッシュはそれを誰が持つかを決めます。2019年の原典もデータレイクやDWHを「メッシュ上のノード」の1つと位置づけており、各ドメインがレイクハウスのテーブル形式でデータプロダクトを公開する構成は、メッシュの典型的な実装です。DWHとの使い分けはデータレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説、レイク上でトランザクションを扱う構成はデータレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説にまとめています。

データファブリックとの違いは「人で解くか、技術で解くか」です。ファブリックはメタデータの自動収集と仮想化で所有を変えずに横断的につなぎ、メッシュは所有と責任を組み替えます。ファブリックのカタログや仮想化層をメッシュの基盤部品に使う併用も成り立ちます。ファブリック側の構成要素と採用条件はデータファブリックとは？構成要素とアクティブメタデータの実装・採用判断を解説で解説しています。

AWS・Google Cloud・Databricksでデータメッシュを組む部品

Google Cloud が「データメッシュは、新しいツールやテクノロジーのセットではありません」と書くとおり単体の製品はなく、主要クラウドは4原則に対応する部品を案内しています。見るべきは、ドメインの所有を表す単位、カタログでの発見、中央ポリシーの一律適用の有無です。

AWSの規範ガイダンス（Prescriptive Guidance）は、フルマネージドの Amazon DataZone、オープンソースの data.all、一から組む AWS Lake Formation の3方式を示しています。どれもドメインのアカウントを生産者と消費者に分け、中央のガバナンスアカウントにカタログを置く形で、Lake Formation 方式では生産者が中央の AWS Glue Data Catalog に公開し、Lake Formation がアクセス権を管理します。

Google Cloud では、Dataplex Universal Catalog が Knowledge Catalog に改称されました（API名は Dataplex API のまま）。公式手順「Build a data mesh」は、レイクをドメイン、ゾーンをチームとデータ契約の単位とし、Cloud Storage バケットか BigQuery データセットをアセットとして接続します。発見には BigQuery のデータ共有、全社ルールには IAM Conditions による属性ベースのアクセス制御が案内されています。Knowledge Catalog の料金と品質スキャンの手順はKnowledge Catalog（旧Dataplex）とは：機能・料金・自己学習型コンテキスト強化とgcloud手順を実装目線で解説【2026年版】で解説しています。

Databricks は Unity Catalog を、ドメインのデータプロダクトを統一ガバナンスの下で公開する仕組みとして案内しています。ODPS・ODCSで記述形式を共通化すると、定義や検査ルールを再利用しやすくなります。ただし、基盤の変更時には接続先や基盤固有の設定、ポリシー適用処理の見直しが必要です。

データメッシュを採用すべき組織と、見送るべき条件

採用を検討してよい組織の条件

次の3つが同時に当てはまるなら検討の価値があります。分析データを生むドメインが複数あり、それぞれに業務を理解したエンジニアを置ける。中央のデータチームへの依頼が恒常的に滞留し、新しいデータの追加に月単位かかっている。経営層が、データ提供をドメインの責任範囲に含める（評価や予算も含めて）と決められる。3つ目が欠けると、データ提供は本業外の雑務になり品質が続きません。Google Cloud の比較表も、データメッシュを「多様なデータと独立したビジネス ユニットを持つ大規模で複雑な組織に最適」、一元化モデルを小規模な組織向けと整理しています。

見送るべき組織と、避けるべき失敗パターン

Google Cloud の解説は、データメッシュの成功はデータエンジニアリングのスキルとガバナンス機能を備えたドメインチームに依存し、そうでなければデータウェアハウスやデータレイクのような一元化されたモデルの方が効率的なこともある、と明記しています。データエンジニアが数人で、主要なデータソースが基幹システムと数個のSaaSに収まる組織では過剰です。この規模の詰まりなら、分散より先にデータカタログの整備やdbtによる加工の整理を試します。中央集権型のままデータ基盤を整える段階なら、データ分析基盤構築・MLOps構築支援で扱うような、取り込みから加工・提供までを担う中央の基盤を先に整える方が筋です。

避けるべき失敗パターンは、セルフサービス基盤を作る前に所有だけを分散させることです。各ドメインが別々のツールで別々の形式のデータを出し始め、Discoverable も Inter-operable も満たさない「分散したサイロ」になります。安全な順序は次の3段です。

1. 業務知識とエンジニアが揃った1〜2ドメインを選び、データプロダクトを試作する
2. 試作で必要になった基盤機能と全社ルールを、プラットフォームとCI検査として確定する
3. 確定した基盤とルールの上で、対象ドメインを広げる

2段目を飛ばして横展開すると、ドメインごとに違う流儀が固まり、後から揃えるコストが膨らみます。

よくある質問

データメッシュとは簡単に言うと何ですか？

分析データの所有と提供責任を、中央のデータチームから注文・在庫などの業務ドメインへ移し、各ドメインがデータを社内向けのプロダクトとして公開する設計方式です。2019年に Thoughtworks の Zhamak Dehghani 氏が提唱しました。

データメッシュの4原則は何ですか？

ドメイン指向の分散所有、プロダクトとしてのデータ、セルフサービス型データプラットフォーム、連合型の計算的ガバナンスの4つで、2020年12月の原典で定められました。

データメッシュとデータファブリックの違いは何ですか？

データメッシュはデータの所有を組織的に分散させる設計方式、データファブリックはメタデータと仮想化の技術で所有を変えずに横断統合する設計方式です。排他的ではなく、ファブリックのカタログをメッシュの基盤部品として使う併用も成り立ちます。

データメッシュとデータレイクの違いは何ですか？

データレイクは生データを1か所に貯める保存方式で、通常は中央チームが管理します。データメッシュは所有の分け方を決める組織とアーキテクチャの方式で、各ドメインがレイクやレイクハウスの上にデータプロダクトを置く形で両立します。

「メッシュデータ」はデータメッシュと同じものですか？

別物です。統計や地図の分野でいうメッシュデータ（地域メッシュ統計）は、国土を緯度・経度で網目状に区切り、区画ごとに人口などを集計したデータです。総務省統計局の解説では、基準地域メッシュ（第3次地域区画）の一辺は約1kmです。データ基盤の設計方式であるデータメッシュとは関係がありません。

関連記事

• データファブリックとは？構成要素とアクティブメタデータの実装・採用判断を解説
• データ契約（Data Contract）とは？ODCSとdbtでスキーマ破壊を止める実装を解説【2026年版】
• Knowledge Catalog（旧Dataplex）とは：機能・料金・自己学習型コンテキスト強化とgcloud手順を実装目線で解説【2026年版】
• データレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説
• データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説