データメッシュの正体は、データの事業部制である

本記事では、AIエージェントの文脈で再び関心が高まっているデータマネジメントの概念「データメッシュ」を解説します。

読み終えた時に、データメッシュとは何か、どんな会社に必要なものか、自社はどう判断すべきかが分かる状態を目指します。

データメッシュとは何か

定義と出自

データメッシュとは、「全社データの管理を、中央データチームによる管理（中央集権型）から、データを作った各事業部門への分担（分散型）に切り替える」という設計論です。

2019年に、コンサルティング会社ThoughtworksのZhamak Dehghaniが、Martin Fowlerのサイトに掲載した論文で提唱しました。

提唱者自身は、これを「組織と技術にまたがる考え方」と呼んでいます。
勘違いされやすいのですが、データメッシュは「概念」です。製品や技術ではありません。

従来型のデータ管理に存在する問題点

なぜデータメッシュという概念が注目されたのでしょうか？

従来のデータ管理（データウェアハウス / データレイク / データレイクハウス）の標準形は、中央集権型です。

例えば、営業はSalesforce、ECは自社DB、物流は倉庫管理システム、経理は会計ソフトを使っている会社が、全社横断で分析するために、これら全てのデータを分析用の1つの置き場（DWHやデータレイク）に集めます。

全社データを1箇所に集め、整形し、各部門に提供するまでを、データチームが一手に担います。

データソースと、分析を頼む部門が少数のうちは、中央で管理するデータチームは全てのデータの意味を把握できるし、部門からの依頼にも、数日で応えられます。

一方、会社が成長してデータソースと利用部門が増えていくと、データチームの負荷が高まり、この形の限界が現れてくるのです。

データチームは、部門が増えれば増えるほど、各部門の業務の中身を詳細には把握できなくなります。

例えば、物流データに「出荷ステータス：7」とあっても、それが何を意味するのか分からなければ、毎回担当部門の現場に聞く事になります。

加えて、データエンジニアリングのプロセス別に分けた組織は、ニーズ単位の変化に弱いという性質があります。

データチームは通常、取り込み担当（データエンジニアチーム）・整形担当（アナリティクスエンジニアチーム）・提供担当（アナリスト、サイエンティストチーム）で分業する事が多いですが、

「この新しい指標を見たい」というニーズは、取り込みから提供まで全工程にまたがるため、ニーズが1つ増えるたびに、全担当の協業作業と調整が発生します。

そして、依頼は中央にいるデータチームに全て集まるので、データチームのリソースを超えた分は、順番待ちになります。

待ちきれない部門は自前で集計を始めると、似た集計テーブルがバラバラに乱立し、同じ「売上」でも部門ごとに複数の指標定義が生まれていき、誰も全体管理ができなくなっていきます。

パイプラインの軽微な変更にもかかわらず数週間待つ、同じ顧客指標が部門ごとに別々に作られている、欲しいデータがどこにあるか探すだけで時間がかかる…という状態です。

データを管理する手法は、データウェアハウス、データレイク、データレイクハウスと進化してきましたが、この課題は繰り返されています。

なぜならそれらの考え方は全て、「全社データを1箇所に集めて、データチームが責任を持つ」という同じ思想の上にあるからです。

データメッシュという解決策：データを作った部門が、自分で管理する

原因が中央集権という構造にあるなら、解決は構造を変える事になります。

データメッシュの答えは、データを中央に集めて中央チームが管理するのをやめ、「データを作った部門が自分で管理して、他部門に提供する」です。

こうすると、直前に挙げた限界がそのまま消えます。

• 業務を知っている人がデータを管理するので、意味の問い合わせが不要になる

• 部門の中で完結するので、新たな分析ニーズが生まれたとき、データチーム全員がかりにならない

• 依頼が、中央の1箇所に集中することがなくなる

ただし、各部門が自分でバラバラに管理するだけなら、ただのサイロ化で統合管理されていない状態です。

データメッシュは後述する4つの原則を持っており、上記のようにならないための条件を足したものとなっています。

データメッシュは、データ版の事業部制である

この4原則は、経営者が組織づくりで、何度も通ってきた議論に対応すると思っています。

それは、中央集権的に本社が全機能を握るか、それとも事業部に権限を委譲して本社は規格と監査に回るか、という事業部制の議論です。

そのため、事業部制の勘所はデータメッシュにもそのまま通用すると思っています。

権限だけ渡して規格を渡さなければ全体がバラバラになり、規格で縛りすぎれば分権の意味が無くなります。

サイロ化との違い

「分散」と聞くと、サイロ化が連想されることもあると思います。

データメッシュでの違いは、規律の有無です。

サイロ化は、無秩序な分散です。

各部門が自分の業務のためだけにデータを持ち、他部門に見せる義務も、繋げるための共通ルールもありません。

一方、データメッシュは、統制された分散です。

「全てをドメインごとに管理する」ではなく、提供義務（第2原則）と共通規格（第4原則）という2つの縛りが入ります。

データメッシュに、新しい技術は1つもない

実装に使う技術は、全て既存の製品です。

BigQuery、Snowflake、Databricks。

データメッシュ専用のフレームワークは、提唱から7年経った今も育っていません。

構成としても新しくありません。多対多の接続の間に中継点を1つ置く構成「データハブ」は、昔からある考え方です。

データメッシュが持ち込んだ新しさは、バラバラだった実践を4原則として言語化した事にあります。

言語化には価値があります。ただしそれは、新しい技術やアーキテクチャを発明した事とは違います。

データメッシュは、なぜ流行したか

データメッシュが流行したのは、2021年から2023年頃です。

まず、当時の現場の課題に一致していました。

多くの会社が中央データチームと分析基盤を整備し終え、その限界が現れ始めた時期でした。

• パイプラインの変更依頼に数週間待つ

• 同じ顧客指標が部門ごとに重複して作られる

• 欲しいデータを探すのに時間がかかる

データメッシュはこの課題に、原因の説明（中央集権の構造問題）と解決策（4原則）をセットで与えました。

発信元であるThoughtworksはアジャイル開発とマイクロサービスを世界に広めた実績を持ち、提唱論文が載ったMartin Fowlerのサイトは、エンジニアリング界隈で最も信頼される場所の1つであるため、

信頼される概念として広まったのかもしれません。

問題の指摘は正しかったと思います。

ただし、4原則を実行できる会社は限られていたのに、流行はその範囲を超えて広がりました。

データメッシュはバズワードとして広がり、しかし現在は、「過度な期待」のピークを過ぎたあたりにあるように思います。

データメッシュが向く会社、向かない会社

提唱者の論文には「ドメインが単純で、データの利用ケースが少ない組織なら、中央集権型で機能しうる」と明記されており、データメッシュは万能の処方箋として提案されたものではありません。

向くとされる条件は、

• 事業ドメインが多く、データソースと利用者が増え続けている。つまり多対多の接続が現実に発生している

• 事業ドメインの境界が既に明確である。「このデータの責任者はどの事業の誰か」という問いに、組織としてそもそも答えられる

• 各部門にデータ人材を配置する、または育てる投資ができる

• 中央チームの増員という単純な解決策を既に試して、限界を見た

このような企業であり、裏返すと、単一事業でドメインが少ない会社や、中央データチームがまだ数人の会社には、提唱者の理屈の上でも不要です。

また、データメッシュには、定番の誤解が3つあり、どれも導入失敗の原因になっています。

日本の導入企業4社は、全て中央のデータ基盤を残した

日本でも実例が出てきています。

公開されている4社を並べると、共通の形が見えてきます。

NTTドコモは、ペタバイト級のデータをグループ6社に連携しています。

中央集権型では、関連子会社との密なデータ連携が組織構造と一致しなかった事が動機で、現場組織が自ら基盤を持ち自律的に管理する分散型へ転換しました。

技術はSnowflakeで、再共有時のコスト増加や、業務委託データと第三者提供データの物理分離など、実装の苦労も公開されています（出典：NTTデータ DATA INSIGHT、2026年3月）。

東京ガスは、1980年代からデータ活用を積み重ね、統合データ分析基盤が成功して利用者が拡大した結果、「中央のリソースがボトルネックになり、現場のニーズにスピード感を持って応えられない」状態になりました。

データ連携依頼の順番待ちが発生し、LNG取引から家庭向けサービスまで、多様な事業要件を一律ルールで運用する無理が出たためです。

各事業部門が自分の基盤を持つ形に転換しつつ、人事・経理・財務など全社共通のデータは「コーポレートドメイン」と呼ぶ中央の置き場に集約し、部門間のデータのやり取りとカタログはそこが統括する、分散と統制の両立を狙った設計です。

技術はDatabricksです（出典：NTTデータ DATA INSIGHT、2026年3月）。

freeeは、テーブル1万以上、月間クエリ80万以上、利用ユーザー300人以上の規模で、一律のセキュリティルールでは扱えるユースケースが限られていました。

自ら「ハブ・アンド・スポーク型データメッシュ」（中心に共通の置き場を1つ置き、各部門がその周りに繋がる形）と呼ぶ設計で、BigQueryの共有機能を中心に置き、プロダクト・ビジネス・全社横断など5種の部門領域を配置しています。

特徴は組織側の実装で、「全社データ寄合」という意思決定の会議体と、セキュリティ・アーキテクチャなど5つの分科会を作り、部門間の利害調整をそこで行っています（出典：freee登壇資料）。

カケハシは、スタートアップですが、複数の医療系プロダクトを持ち、複数のプロダクトチームからの依頼が1つの基盤チームに集中して順番待ちになっていました。

プロダクトを増やしていく前提では基盤チームの増員では追いつかないと判断し、プロダクトごとにDatabricksの作業環境を分離しつつ、アクセス権と管理台帳は中央で一元管理する形を約10ヶ月で構築しました（出典：カケハシ登壇資料）。

この4社を並べると、共通点が3つあります。

例から、適用条件は「大企業向け」ではなく「ドメイン（プロダクト）数が多い会社向け」と言い直すのが正確だと思います。

会社の規模が小さくても、プロダクトが多ければ中央チームへの依頼集中は起きる可能性があります。

提唱者はデータメッシュは4原則の全てに従う事を求めますが、私はこれは現実からは乖離しているように思います。

日本の事例で見ても、世界的にも、実装の多くは4原則のうち一部だけを採用したものとなっています。

業界的に4つの原則のうち2つだけ、3つだけを満たしたものを「データメッシュと呼ぶのか」は、統一された答えはないのが現状のように思います。

重要なのは何の課題を解決するために生まれた概念なのか、その原則を理解し、健全に議論をすることです。

失敗した会社は、共通基盤とルールまで各部門に任せてしまう

海外では失敗の証言が出揃いつつあります。

ある組織では、データメッシュ導入後に「顧客数は何人か」と聞くと、3つのチームから3つの違う答えが返ってくるようになりました。

顧客IDの形式が揃わず、部門間でデータを結合できない。決済チームはエンジニアリング時間の4割を、決済の仕事ではなくインフラの管理に費やしていた、という状態です（出典：Medium上の実務者による導入振り返り記事、2025年）。

提唱元のThoughtworks自身が、2026年の総括で「投資は増えているが、多くの企業で実装は停滞している。静かなプロジェクトの墓場がある」と認めています（出典：Thoughtworks「The state of data mesh in 2026」）。

調査会社のGartnerは2022年、データメッシュに「成熟する前に廃れる」という異例の判定を付けました。

失敗の原因は、

• 中央チームを解散したのに共通の道具に投資せず、各部門が自前でツールを作り始める

• 全社ルールを守るかどうかを各部門の任意にしてしまい、部門をまたいで繋がらないデータが乱立する

• つまり、統制された分散のはずが、公式に承認されたサイロに退化する

と共通しています。

データメッシュの採用を決めた場合、失敗を避けるためには、データの管理責任は各部門に渡してよいが、共通インフラ基盤と全社ガバナンスルールは、中央に残すことです。

• 全社ルールの策定、共通基盤の整備、データの説明書き（メタデータ）の管理方法は中央に残す。

• 個々のデータの整形・分析・レポート作成は各部門に渡す。

データメッシュが約束する価値は、普通のDWHでも実現できる

加えて、データメッシュが約束する価値の大半は、データの実体を中央に集める普通のDWH構成でも実現できます。

日本の4社が全て中央のデータ基盤を残した事実とも合致します。

だとすれば、ほとんどの会社にとっての実践は、分散ではなく「中央のデータ基盤を、製品と呼べる品質で運用する事」から始まります。

部門への管理移管という組織変更が本当に要るのは、事業やプロダクトの数が多く、データのやり取りの相手が多い一部の会社だけです。

AIエージェントが、同じ問題をもう一度起こしている

データメッシュがいま再び語られている理由に、AIエージェントがあります。

提唱元のThoughtworksは2026年の総括で、データメッシュの主要な導入理由が「信頼できるAIの土台づくり」に変わったと述べています。

各部門が別々のAIツールを導入し、営業のアシスタントは顧客管理システムを、経営企画のエージェントは会計データを、開発部門のエージェントはプロダクトの利用ログを読みに行きます。

ツールの数×データソースの数だけ接続が生まれ、その1本ごとに「どのデータを読ませてよいか」「品質は信頼できるか」「誰が何を読んだか」を管理する必要が生まれます。

これは、この記事の前半で見た多対多の問題の再来です。

かつては「多数の利用部門×多数のデータソース」でしたが、今回は「多数のエージェント×多数のデータソース」で、接続の数は人間だけの時より桁違いに多くなります。

しかもエージェントは、人間の分析者より条件が厳しいです。

人間は多少雑なデータでも、経験と文脈で補って読めます。
エージェントは書いていない事を補えないし、誤ったデータを渡しても、疑わずにもっともらしい答えを作ってしまいます。

だから、エージェントを本格的に使う前提としてデータに要求されるのは、定義が書いてあり、品質が保証され、説明が付いている事です。

これは第2原則（データはプロダクト）の要求そのものです。

実際に、SnowflakeとDatabricksは2026年の年次イベントで、揃ってこの領域に製品を寄せました。

指標の定義を一元管理する仕組み（セマンティック層）の強化と、エージェントに従業員と同じようにIDを与えて権限を管理する機能です。

エージェントの答えの品質は、モデルの賢さではなく渡すデータの整備で決まる、というのが両社に共通する主張です。

つまりAI時代に価値が上がるのは、第2原則と第4原則です。

この2つは、管理を部門に移すかどうかと無関係に、会社の規模によらず効いてきます。

一方で、第1原則（各部門への管理移管）は、原則自体が崩れていく可能性があります。

移管を選ぶ根本の理由は「中央チームの人手が、増え続ける依頼に追いつかない」という人の数の問題でした。

AIはまさにこの部分、データの取り込みや整形の仕組みづくりの生産性を上げます。

中央チームがAIで数倍の依頼をこなせるようになるなら、管理を部門に移すという大掛かりな組織変更をせずに、中央チームをAIで増強するという安い選択肢が生まれます。

どちらが主流になるかは、まだ分かりません。

もう1つ決着していないのは、この全ツールをまとめて管理する仕組みを、誰が提供するかです。

SnowflakeやDatabricksのような従来のデータ基盤側が拡張するのか、生成AIツールの側から新しく生まれてくるのか。

ベンダーの「データメッシュ対応」「エージェント対応」という売り文句を鵜呑みにして基盤を選ぶ段階ではないと思います。

ここまでを踏まえると、経営者が問うべきは「データメッシュをやるか」ではありません。
「自社の事業・プロダクトの数に対して、中央のデータチームがボトルネックになり始めているか」です。

• データ連携や分析の依頼から提供までのリードタイムが延び続けているか？

• 同じ指標が部門ごとに別々に作られ始めているか？

• それは中央チームの増員で解決する規模か？

ボトルネックがまだなら、やる事は変わりません。中央のデータ基盤を製品と呼べる品質で運用し、指標の定義を揃え、品質を保証し、データに説明を付ける。

それはデータメッシュのためではなく、AIエージェントにデータを使わせる前提として、どの会社にも必要な仕事です。