データ活用のパラダイムシフト「データメッシュ」｜分散型アーキテクチャがもたらす価値

1.  「データメッシュ」とは何か

日本企業によるデジタルトランスフォーメーション（DX）の取り組みが本格化するなか、データ活用に乗り出すところも増えています。独立行政法人 情報処理推進機構（IPA）の調査レポート「DX動向 2025」によると、データを「全社で利活用している」「事業部門・部署ごとに利活用している」とする日本企業は全体の60.2％に上り、その割合は米国よりも多くなっているといいます。

日本におけるデータ利活用の状況

図1：国別の企業におけるデータ利活用状況
出典：独立行政法人 情報処理推進機構（IPA）「DX動向 2025」を元に作成

一方で、データの整備・管理・流通を巡っては課題も多く、特に日本では、データ活用を推進するための「人材の確保が難しい」「データ管理システムが整備されていない」といった理由から、データ活用に踏み出せないでいる企業が多いようです。

データ整備・管理・流通を巡る課題

※データ利活用の状況の設問で「今後も取組む予定はない」以外を回答した企業が対象

図2：国別のデータを利活用する予定がない企業の理由
出典：独立行政法人 情報処理推進機構（IPA）「DX動向 2025」を元に作成

こうした状況で全社的なデータ活用を支える環境を整備するのは、なかなか大変なことです。実際、全社でのデータ活用を推進している企業では、そのための環境、あるいはデータ基盤を整備するために相応の業務負担を中央のIT組織やデータチームにかけてきたといえます。

そんななかで注目され始めているのが、データ管理の新しいアーキテクチャ「データメッシュ」です。

データメッシュは、企業のデータを「網の目状」に分散配置して管理していくためのアーキテクチャです。企業内の現業部門・部署（以下、ドメイン）に、それぞれが活用するデータを保持・管理させることを基本としています。各ドメインは、活用するデータの所有権を保持し、それぞれのニーズに応じてデータを整備し、活用していくことになります。

2.  従来型のアーキテクチャとの違い

従来型のデータ管理、活用の在り方は、中央のIT組織やデータチームが、全社的に活用すべきデータをさまざまなデータソースから収集して「データウェアハウス」や「データレイク（あるいは、データレイクハウス）」に保持させて一元管理し、そこから各ドメインが活用したいデータを提供するというものでした。データの所有権は、中央のIT組織やデータチームに帰属し、その点で「中央集権型」といえます。

一方のデータメッシュは、データの分散管理を基本とする「分散型」のアーキテクチャです。従来型のアーキテクチャとの違いをまとめると、下表のようになります。

従来型のアーキテクチャとデータメッシュアーキテクチャとの違い

3.  データメッシュの起源と発展の経緯

データメッシュは、テクノロジーコンサルティングファームのThoughtworks社でテクニカルコンサルタントを務めるジャマク・デガニ(Zhamak Dehghani)氏が、2019年と2020年にそれぞれ発表した2つの記事（*1）で提唱した概念です。その後、Amazon Web Services（AWS）やMicrosoft、Googleといった有力なクラウド事業者が、具体的な機能を使ったデータメッシュの実装や、構築のガイドライン、フレームワークの開発に取り組みました。それによってデータメッシュに対する市場での認知が広がり、大規模環境におけるデータ管理の新しい選択肢として定着していったといえます。

また、例えば、AWSの技術解説サイト「Cloud Computing Concepts Hub（*2）」や、Microsoft Azureの「Microsoft Learn（*3）」、Google Cloudの「Cloud Architecture Center（*4）」などには「データメッシュとは何か」を解説するページが展開されています。その他にもSnowflakeやDatabricksといった企業でもデータメッシュの解説ページを設けて（*5）（*6）います。

ちなみに、デガニ氏の記事では、データメッシュの明確な実装方法や技術要件は示されていません。ただ、データメッシュの実装に取り組んでいる事業者は、後述する「データメッシュの原則」に則ったかたちでシステムの構築を進めています。

*1 記事の参照URL
https://martinfowler.com/articles/data-monolith-to-mesh.html
https://martinfowler.com/articles/data-mesh-principles.html

*2 Cloud Computing Concepts Hubにおけるデータメッシュの解説ページ： https://aws.amazon.com/what-is/data-mesh/

*3 Microsoft Learnにおけるデータメッシュの解説ページ：https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/cloud-scale-analytics/architectures/what-is-data-mesh

*4 Google Cloudの「Cloud Architecture Center」におけるデータメッシュの解説ページhttps://docs.cloud.google.com/architecture/data-mesh?hl=ja

*5 Snowflakeにおけるデータメッシュの解説ページ：
https://www.snowflake.com/ja/blog/empower-data-teams-with-a-data-mesh-built-on-snowflake/

*6 Databricksにおけるデータメッシュの解説ページ：https://www.databricks.com/jp/glossary/data-mesh

4.  データメッシュが求められる背景

データメッシュに対する世界的な注目度やニーズが高まった背景としては、企業におけるクラウドやエッジの活用が進んだことで、企業のデータがさまざまな場所に分散してサイロ化し、それらを一元的に管理したり、活用のための環境を整えたりする難度が高まった点が挙げられます。

従来型のアーキテクチャでは、こうしたデータのサイロ化の問題を、データの収集・統合という手法によって解決することを前提にしています。それゆえに、全社的なデータの活用に向けては、各所のデータソースからデータを集め、分析・活用が可能な状態にする前処理（データの欠損やノイズなどを補正する処理）や「ETL（抽出・変換・格納）」処理を行う必要が出てきます。

加えて、近年ではデータマネジメントの在り方も変化しています。従来はデータの前処理やETL処理、マスターデータ管理などがデータマネジメントの主要な取り組みでした。それに加え今日では、データのガバナンスやセキュリティ管理、コンプライアンスといった取り組みを推進することが求められるようになっています。

データ管理を巡るこうした変化や処理への対応負担を低減させるべく、データ管理の在り方を抜本的に変革したいというニーズが膨らみました。それがデータメッシュを求める企業の動きにつながっているといえます。

5.  データメッシュの原則

データメッシュのアーキテクチャには4つの原則があります。それは「①ドメインによるデータの所有（Domain ownership)」をはじめ、「②プロダクトとしてデータを扱うこと（Data as a Product）」「③セルフサービス型データプラットフォームを構築すること（Self-serve Data Platform）」「④連邦型コンピュテーショナルガバナンスを実現すること（Federated Computational Governance）」の4つです。

これらの原則は、先に触れたデガニ氏の記事で提示されたもので、AWSやMicrosoftも同じ原則を踏襲しています。

（1）ドメインによるデータ所有（Domain ownership）

「ドメインによるデータの所有」とは、企業内の各ドメインにデータ管理の責任・権限を担ってもらう原則です。この原則は「分散ドメインドリブンアーキテクチャ」や「データドメイン」などと言い換えられることもあります。また、各ドメインがデータの収集や変換、提供に責任を持ち、ドメインが所有権を持つデータは「ドメインデータ」と呼ばれています。

（2）プロダクトとしてデータを扱うこと（Data as a Product）

これは文字通り、データをプロダクトとして扱うという原則です。ドメインが所有権を持つドメインデータは「検索性」や「アクセス性」「信頼性」「相互運用性」「セキュリティ」などの点で問題を引き起こしやすいといえます。そこで、データをプロダクトとして扱わせ、これらの問題の発生を低減させることがデータメッシュの原則とされたわけです。

（3）セルフサービス型データプラットフォームを築くこと（Self-serve Data Platform）

ここでいう「セルフサービス型データプラットフォーム」とは、データの管理を各ドメインが主体的（＝セルフ）に行うことを可能にするデータ基盤を指しています。このプラットフォームには、データのパイプライン（データの収集・変換・整理などの処理）やデータの保管（データストレージ）、さらにはストリーミングといった処理を自動化・効率化する機能を実装します。

（4）連邦型コンピュテーショナルガバナンスを実現すること（Federated Computational Governance）

「連邦型コンピュテーショナルガバナンス」とは、各所に分散したドメインデータのガバナンス（統制）をとること（あるいは、そのための仕組み）を意味し、「連邦型データガバナンス」とも呼ばれます。分散したドメインデータとデータ基盤の管理を共通のポリシーをベースに自動化し、ガバナンスの欠如を防ぎます。

6.  データメッシュがもたらすメリット

企業がデータメッシュを採用するメリットは、現業部門・部署のニーズに合致したデータ活用を促進しやすくなる点です。とはいえ、データメッシュはすべての企業に適したアーキテクチャではありません。部門ごと、あるいは業務ごとにデータの分断が数多く、かつ広範囲に起きている大規模な企業にはデータメッシュが適しているといえます。

そうした企業に対してデータメッシュがもたらすメリットはいくつかあります。

大きなメリットの1つは、上で触れたように、データ管理の権限が各ドメインに移管されることで、ビジネス現場でのデータ活用が促進される可能性が高まることです。これにより、各ビジネス現場が、それぞれの担当するビジネスの知識（あるいは、ドメインの知識）を生かしながら、データを分析し、活用する文化が醸成されやすくなります。加えて、データメッシュの採用には、ビジネス現場が欲するデータを入手するスピードを高められるという効果も生みます。

データメッシュの採用により、データをプロダクトとして扱おうとする意識が高められ、それがデータの検索性やアクセス性、信頼性、相互運用性、セキュリティなどの向上につながることも期待できます。

ビジネス現場では、活用したいデータを保持している他部門・他部署との交渉が難航し、使いたいデータがなかなか取得できないといったことがよくあります。また、社内のどの部門・部署にどのようなデータがあるかが見えないことも珍しくありません。各ドメインでのデータメッシュの活用が進み、それぞれがデータをプロダクトとして社内の他のドメインに提供するようになれば、他部門・他部署のデータがなかなか使えない、あるいは他部門・他部署が保持しているデータが見えないといった問題が解消されるはずです。

データメッシュの原則に従うかたちで、各ドメインでのセルフサービス型データプラットフォームの構築が進むことで、中央のIT組織やデータチームが全社のデータ活用を促進するためのデータ基盤の整備に手間をかけずに済むようになります。

さらに、連邦型データガバナンスの仕組みづくりを進めれば、分散型でデータを管理しながら、全体のガバナンスを適切にとることも容易になります。これにより、全社的なガバナンスを利かせる中央の業務負担が低減されるほか、中央集権的なガバナンスで起こりがちな「ガバナンスの不徹底」と、それによる「セキュリティリスク、コンプライアンスリスクの増大」といった問題も発生しにくくなります。

7.  データメッシュを実装する方法

データメッシュの実装方法については、多くのクラウド事業者が自社サービスの活用シナリオの1つとして、具体的な手法を提唱しています。

例えば、AWSではデータベースやデータレイク、分析システム、ML/AI（機械学習/人工知能）、データガバナンスなどのサービスを組み合わせて構築する「Modern Data Architecture」の中の1つとして、データメッシュの構築パターンを紹介しています。

またMicrosoft Azureの解説サイトでは、データメッシュの原則に沿った仕組みをどう実装していくかについて、そのための製品である「Data Factory」「Azure Synapse Analytics」「Azure Datalake Storage」を例として使いながら解説しています。

8.  中央集権型の経験が活きる分散型への移行

現在データメッシュの導入を検討する企業の中には、過去に中央集権型のデータ基盤構築に取り組んだ経験を持つ組織もあるでしょう。実は、この経験こそが、分散型であるデータメッシュの成功につながる重要な資産となります。

中央集権型の構築を通じて、どのようなデータは全社共通で管理すべきか、どのようなデータは各部門に委ねるべきかという「データ管理の境界」を判断する知見が情報システム部門に蓄積されています。それを踏まえ現在では、分散型構築の構想段階から情報システム部門が積極的に各部門を巻き込むようになっています。

単にシステムを提供するのではなく、データをどのように業務課題の解決に活用できるか、将来のビジネスビジョンの実現にどう貢献できるかを、各部門と共に検討する体制が生まれているのです。これは、過去の中央集権型の挑戦があったからこそ実現できた進化といえるでしょう。

9.  今このタイミングでデータメッシュが実現可能になった理由

データメッシュという概念自体は2019年に提唱されています。それが時を経て、なぜ今になって多くの企業が実装に踏み切れるようになったのでしょうか。その最大の理由は、技術環境の劇的な変化にあります。

特に重要なのは、分散型の思想に基づいたクラウドサービスの登場です。これらのサービスは、データメッシュの原則に沿った設計思想を持ち、スモールスタートが可能な料金体系を提供しています。それにより、企業はデータ利活用の進捗状況やデータドリブンな文化の浸透度に見合った段階的な投資が可能となったのです。

過去には、オンプレミスのデータウェアハウス（DWH）など、大規模な初期投資を必要とする技術しか選択肢がありませんでした。そのため、データ基盤の構築には一括かつ大型の投資判断が必要で、失敗のリスクも大きかったのです。また、投資に見合う効果が得られるまでに長い時間がかかることも珍しくありませんでした。

現在のクラウドベースのデータプラットフォームは、使った分だけ課金される従量課金制や、必要に応じて拡張・縮小できるスケーラビリティを提供しています。これにより、各ドメインが小規模にデータ活用を始め、効果を確認しながら段階的に拡大していくことが可能になりました。

さらに、これらの最新のプラットフォームは、データの共有やガバナンス機能も標準で備えており、データメッシュの4つの原則を技術的に実現しやすい環境が整っています。例えば、Snowflakeのデータシェアリング機能は、各ドメインが管理するデータを他のドメインに安全に共有する仕組みを提供し、「プロダクトとしてのデータ」という原則の実現を支援します。

10.  まとめ

以上に示したとおり、データメッシュは、データ管理の在り方を大きく変える新しいアーキテクチャであり、概念です。それを採用することで、中央のIT組織やデータチームが、全社的なデータの活用を支えるデータ基盤を整備する手間を大きく低減させることが可能になります。また、ビジネス現場は、それぞれのニーズに沿ったデータの収集・分析・活用を自ら主導し、スピード感をもってそれに取り組めるようになります。

ただし、データメッシュは、あくまでもアーキテクチャであり、データ管理の1つの選択肢にすぎません。その原則に従ってシステムを実装しても、それだけで各ビジネス現場でのデータ活用が自動的に活性化され、「データドリブン」のビジネス文化が一気に定着するわけではありません。

したがって実際には、ビジネス現場でのデータ分析・活用のニーズがどの程度あり、そのニーズを満たすために中央のIT組織やデータチームにどれほどの業務負荷がかかっているかを見定めながら、データメッシュの採用や同アーキテクチャへの移行を検討するのが適切といえるでしょう。過去の経験や最新の技術環境を活用しながら、自社に適したデータ活用の形を模索していくことが、これからのデータ戦略の鍵となります。