全社データを「組織で運営する」データメッシュの考え方

全社のデータを、中央の1チームが集めて整えて配る。 このやり方は、データの種類と使う人が増えるほど、どこかで行き詰まります。 事業部門が自分たちのデータに責任を持ち、共通のルールで共有する「データメッシュ」の考え方と、先行する企業の取り組みを整理します。

なぜ「中央の1チーム」では回らなくなるのか

多くの会社は、データ活用をまず情報システム部門やデータ専門チームに集めるところから始めます。 最初はそれで十分です。ところが、使う部門が増え、扱うデータが増えるにつれて、2つの問題が表に出てきます。

1つは、中央チームがボトルネックになることです。 「このデータを使えるようにしてほしい」という依頼が積み上がり、数か月待ちが当たり前になります。 もう1つは、中央チームには業務の意味が分からないことです。 「この項目は何を表しているのか」「この数字はどの時点のものか」を知っているのは、そのデータを生み出している現場です。

かといって、各部門が好き勝手にデータを持てば解決するわけでもありません。 完全に分散させると、データは部門ごとのサイロに閉じ、項目の定義や権限のルールもばらばらになります。 隣の部門のデータは「あるらしいけれど、どこにあるか分からない」状態になってしまいます。

集めすぎても、ばらけすぎても回らない。必要なのは、その中間の設計です。

データメッシュとは：分散した責任 × 共通の基盤とルール

データメッシュは、この中間を形にした考え方です。 データの中身に責任を持つのは、そのデータをいちばんよく知る事業部門。 一方で、データを置く基盤、権限やマスキングの仕組み、品質の基準、共有の方法は、全社で共通にします。

ポイントは、責任は分けても、ルールと基盤は分けないことです。 部門ごとに別々のツールや別々の権限の考え方を持ち込むと、それはメッシュではなく、ただのサイロの集まりになります。

データを「製品」として扱う

データメッシュの中心にあるのが、「データプロダクト」という考え方です。 部門が持つデータを、他の部門がそのまま使える「製品」として整えて公開します。 製品なので、中身の説明、更新の頻度、品質の基準、問い合わせ先がはっきりしていて、使う側が安心して再利用できます。

ある大手製薬会社では、研究、顧客、リアルワールドデータ、安全性、臨床といった複数の事業領域で、それぞれデータ基盤が稼働しています。 2021年から段階的に導入を進め、2024年にデータメッシュの方針を策定しました。全社の領域は2026年下期の稼働を予定しています。 顧客の統合データは、各部門が再利用できるデータプロダクトとして提供されています。

この会社は、取り組みから得た学びを4つにまとめています。

• 価値を先に：基盤づくりそのものではなく、業務の価値から始める
• まず取り込んでから加工する：先にデータを基盤へ集め、加工は後から柔軟に行う
• 製品として考える：使う人を想定し、説明と品質を備えたデータとして公開する
• 共有する：部門の中に閉じず、全社で使い回せるようにする

どれも当たり前に聞こえますが、実際には逆の順番で進めてしまう会社が少なくありません。 完璧な基盤とデータモデルを先に設計し、整えてから取り込み、部門ごとに作り込み、最後に共有を考える。 これでは、価値が見えるまでに何年もかかり、その間に現場の関心が離れていきます。 まず使い道を決め、データを集め、使われる形で公開する。この順番が、データメッシュを前に進めます。

事業部門に「データの責任者」を置く

責任を分散させるといっても、「各部門でよろしく」では動きません。 誰がそのデータの中身と品質に責任を持つのかを、役割として明確にすることが出発点です。

ある大手電機メーカーでは、事業領域ごとに環境を分け、各事業領域にデータの責任者を置く体制をとっています。 グループ全体では、2030年度に2万人のDX人財を育てる目標を掲げています。

ある大手通信グループの1社では、データの管理者を数百名規模で配置しています。 中央の数人ではなく、現場に近い数百人がそれぞれのデータを見る。 この厚みがあって初めて、全社のデータを「組織で運営する」ことが現実になります。

データの責任者に期待する役割は、おおむね次のとおりです。

• 意味を決める：項目の定義や計算のしかたを決め、説明として残す
• 品質を保つ：欠損や重複、更新の遅れに気づき、直す
• 公開を判断する：どのデータを、誰に、どの粒度で共有してよいかを決める
• 問い合わせに答える：使う側からの質問や改善の要望の窓口になる

専任である必要はありません。業務を知る人が、役割として明示的に引き受けていることが大切です。

統制は「使わせないため」ではなく「安全に使うため」

データを広く共有すると聞くと、情報漏えいを心配する声が必ず上がります。 先ほどの通信グループの会社は、統制の目的を「使わせないため」ではなく「安全に使うため」と位置づけています。 そのうえで、見る人によって機密項目を隠す動的マスキング、外部の仕組みによるトークン化、個人を特定できないようにする差分プライバシー、行単位のアクセス制御を組み合わせています。

ルールを人の手で守るのには限界があります。 ある小売向けのマーケティング企業は、1日7億行を取り込み、100TBを超えるデータを扱っています。 この規模では、データメッシュの構成も、統制のルールも、コードとして管理しています（Governance as Code）。 ルールがコードになっていれば、部門が増えても同じ基準が自動で効き、変更の履歴も残ります。 この会社は、古い分散処理基盤を廃止することで、コストを95%削減しました。

「探せる・頼める・使える」共有の仕組み

データプロダクトを公開しても、見つけてもらえなければ使われません。 ある大手通信会社は、数ペタバイトから十数ペタバイト級のデータ基盤を2つ持ち、社内のデータマーケットプレイスとデータ共有の仕組みでメッシュを構成しています。 利用者はマーケットプレイスでデータを探し、利用を申請して、使い始めることができます。

物理的にデータを1か所へ集めない方法もあります。 ある通信会社では、グループ会社とのデータ共有にあたり、各社のデータベースを仮想的に集約しています。 データを物理的に1か所へ写さなくても、まとめて扱えるようにする工夫です。

この通信グループの会社は、データの所在を探すAIエージェントも開発しています。 「こういうデータはないか」と聞けば、どこに何があるかを教えてくれる。 データが増えるほど、探す手間を減らす仕組みの価値は大きくなります。

マーケットプレイスやカタログに載せる情報は、人にとってもAIにとっても同じです。 何のデータか、誰が責任者か、いつ更新されるか、誰が使ってよいか。 この4点が揃っていれば、使う側は担当者を探し回らずに判断できます。

AIが、データメッシュの運営を速くする

データプロダクトを1つずつ人手で作っていては、数が揃うまでに何年もかかります。 先の大手製薬会社は、生成AIを使ってデータプロダクトを量産する「データプロダクト工場」に取り組んでいます。

ある大手通信会社では、AIを使った開発ツールの利用者が1,500人を超え、一次分析にかかる時間が約260時間から約0.3時間に短縮されました。 仕様書を起点にAIがデータの構成を生成し、人が承認してからデプロイする流れです。 AIに任せる部分と、人が判断する部分の線引きがはっきりしています。 今後は、データだけでなく、AIエージェントやAIと業務システムをつなぐ接続ツールもカタログに載せていく計画です。

この通信グループの会社では、社内のAI基盤の利用者が2.4万人を超えています。 AIを使う人がこれだけ増えると、AIが参照するデータの責任の所在とルールが、そのまま回答の品質と安全性を左右します。 データメッシュは、AI活用を全社に広げるための土台でもあります。

人と役割をそろえる

組織で運営するには、担い手の定義も欠かせません。 国のデジタルスキル標準も改訂され、「データマネジメント」の人材類型が追加されました。 ロールは、データの意味と品質を守るデータスチュワード、データの流れをつくるデータエンジニア、全体の設計を担うデータアーキテクトの3つです。 新しい試験は2027年度夏以降に始まる予定です。

企業の側でも動きがあります。 ある大手人材企業は、データの意味（定義）をまとめた層を、AIとの窓口にする方針を掲げています。 ある大手通信会社は、職種名を「データサイエンス＆マネジメント」に改め、分析とデータの管理を一体の職種として位置づけています。 この会社は、新しい進め方をまず1つのユースケースで検証し、うまくいってから横に展開しています。

いきなり全社の体制を変える必要はありません。 1つの事業部門、1つのデータプロダクトから始め、責任者・ルール・共有の仕組みを試しながら広げていくのが現実的です。

まとめ：始める前に確認したい5つの質問

• 中央のデータチームへの依頼は、どれくらい待ちが発生しているか
• 主要なデータごとに、中身と品質に責任を持つ人が決まっているか
• 権限・マスキング・品質の基準は、全社で共通になっているか（コードで管理できているか）
• 他部門のデータを、探して、申請して、使える仕組みがあるか
• 最初に試す事業部門とデータプロダクトを、1つに絞れているか

データメッシュは、新しいツールの名前ではなく、データを「誰が責任を持ち、どう共有するか」という組織の設計です。 私たちは、事業部門ごとのデータの整理から、共通の基盤とルールづくり、部門をまたぐデータ連携の開発までを一緒に進めています。 中央チームの負荷が限界に近づいていると感じたら、それが見直しのタイミングです。