データアーキテクチャ ― 全社データを戦略資産として設計する ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第3弾として、EA観点のデータアーキテクチャ（DA）について解説する記事です。

データアーキテクチャ章（40系）が「個別システムの実装」を扱うのに対し、本記事は「企業横断の整合性」を扱います。例えば「顧客マスタを一元化する」が本記事、「どのDBに置くか」が40系の仕事です。本記事ではマスタデータ管理（MDM）・データガバナンス・全社データ流通・CDO/データスチュワードの役割まで、CDO・データ部門長向けに解説します。

このカテゴリの他の記事

概要 ― 企業の地図を描く4層モデル ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-overview/

ビジネスアーキテクチャ ― 事業を技術と接続可能な形にする ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-ba/

アプリケーションアーキテクチャ ― 全社システム群を地図化する ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-aa/

テクノロジーアーキテクチャ ― 企業の技術選択の憲法 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-ta/

EAフレームワーク ― TOGAF+ArchiMateをTailorして使う ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-ea-framework/

「今月の売上」が部署で違う会社は、DAが壊れている

EA の2番目のレイヤー（DA）で、企業全体のデータ資産を体系的に設計します。データアーキテクチャ章で扱った「データベース選定・データ基盤」とは視点が違い、組織全体で扱うデータの種類・関係・流れ・所有者を企業レベルで整理するのが目的です。

個別システムのデータアーキテクチャは「その業務を動かすためのデータ」を扱いますが、EA のデータアーキテクチャは企業の戦略資産としてのデータ全体を扱います。どのシステムがどのデータを持ち、どこが原本で、どこに流れているかを全社一枚絵で描きます。

個別 DB 設計＝戦術、EAのDA＝戦略。視点が一段高いです。

なぜDAが必要か

サイロ化したデータを統合する

部署ごとに別々のシステムでデータを持つと、同じ顧客が3つのIDで登録されている状態になります。全社視点でデータを整理する必要があります。

データドリブン経営の土台

経営判断に全社データを使うには、どこに何があるかの地図が必要です。DA がない企業は経営会議で「数字が違う」問題が頻発します。

経営会議で財務部が出した「今月の売上」と営業部が出した「今月の売上」が5%近く食い違い、議論が毎月そこから始まる──という光景が報告されることがあります。原因を辿ると、返品・値引・消費税・計上タイミングの扱いが部署ごとに微妙に違い、誰が出した数字も各部署の定義では正しい状態。データそのものより、言葉の定義を全社で揃えていないことの方が深刻だと示す典型例です。

規制・プライバシー対応

GDPR（General Data Protection Regulation＝EU一般データ保護規則）・個人情報保護法対応には個人情報の所在地図が必須です。DA の整備が監査対応の前提になります。

DAの主要構成要素

EA のデータアーキテクチャは、複数の視点で全社データを捉えます。単なる ER 図ではなく、戦略・運用・技術の全観点を含みます。

要素	内容
概念データモデル	全社の主要エンティティ
論理データモデル	関係・属性の詳細
物理データモデル	実際の DB 設計
データフロー図	システム間のデータ移動
データカタログ	全データの目録
マスターデータ管理	基幹データの唯一性
データガバナンス	管理体制・ルール

概念データモデル

全社で扱う主要なエンティティ（実体）を描くのが概念データモデルです。「顧客・商品・注文・従業員・取引先」──企業活動の核となるモノを10〜30個程度で表現します。業務部門も理解できる粒度が重要です。

[顧客] ─── 購入 ─── [商品]
   │                   │
   │                   │
   └── 配送先 ──[住所]──在庫 ─── [倉庫]

概念モデルはビジネスの言葉で描くのが鉄則です。「user_account」ではなく「顧客」と書き、業務部門と技術部門の共通言語にします。

データドメイン

関連するデータをグルーピングした領域をデータドメインと呼びます。「顧客ドメイン」「商品ドメイン」「財務ドメイン」──のようにビジネス機能別に分け、それぞれにデータオーナーを置くのが現代的なアプローチです。

ドメイン	主要データ
顧客	顧客マスタ・行動履歴・セグメント
商品	商品マスタ・カテゴリ・価格
取引	注文・配送・返品
財務	会計・予算・実績
人事	従業員・給与・評価
パートナー	取引先・契約

Data Mesh の考え方では、ドメインがデータの所有権と責任を持ち、ドメイン内で完結した良質なデータを他ドメインに提供します。

マスターデータ管理（MDM）

基幹となるデータを全社で一元管理する仕組みです。「顧客ID」「商品コード」「取引先コード」などのマスターデータが部署ごとに違うと、全社分析が不可能になります。MDMは唯一の正しい情報源を作ります。

flowchart TB
    subgraph BEFORE["MDMなし (典型的な失敗)"]
        SYS1[CRM<br/>顧客ID=A001] -.| SYS2[ERP<br/>顧客ID=12345]
        SYS2 -.| SYS3[会計<br/>顧客ID=東京 太郎]
        SYS3 -.| Q1[全社分析<br/>不可能]
    end
    subgraph AFTER["Coexistence方式 MDM"]
        MDM[(MDM<br/>顧客マスタ)]
        SYS4[CRM] <-->|双方向同期| MDM
        SYS5[ERP] <-->|双方向同期| MDM
        SYS6[会計] <-->|双方向同期| MDM
        MDM --> ANALYTICS[全社分析<br/>可能]
    end
    classDef bad fill:#fee2e2,stroke:#dc2626;
    classDef good fill:#dcfce7,stroke:#16a34a;
    classDef mdm fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
    class BEFORE,SYS1,SYS2,SYS3,Q1 bad;
    class AFTER,SYS4,SYS5,SYS6,ANALYTICS good;
    class MDM mdm;

MDMの構築方式	内容
Registry方式	各システムのデータはそのまま、IDだけ統合
Consolidation方式	読取専用の統合データ
Coexistence方式	各システムと双方向同期
Centralized方式	単一のマスタシステムに集約

現実には Coexistence方式が多く、既存システムを壊さず段階的に整合性を取る現実的な方法です。

他方式と比べて Coexistence が選ばれる理由は明確です。Centralized は理想的ですが、既存の基幹系・CRM・ERP を止めて単一マスタに寄せる移行コストが巨大で、稼働中の事業を止めずにやり切れる企業はほぼありません。Consolidation は読取専用のため更新が各システムに残り、結局二重管理が続きます。Registry は ID だけ繋げる軽い方式ですが、属性値の不整合（同じ顧客で住所が違う等）を解消できません。Coexistence は既存システムの更新を生かしたまま双方向同期でマスタを整えるため、既存資産を壊さず・初期コストを抑え・完全統合の失敗リスクを避ける三拍子が揃い、段階導入を前提とする現実の企業に最もフィットします。

データフロー図（全社）

システム間のデータ移動を全社単位で可視化します。「どのシステムがどこからデータを受け取り、どこへ送るか」を描くと、データの依存関係が見えます。

[基幹系] ──注文──▶ [在庫管理]
   │                    │
   │                    ▼
   └──顧客情報──▶ [CRM] ──分析──▶ [DWH]
                     │              │
                     ▼              ▼
                [メール配信]      [BI]

このレベルの図があれば、「あるシステムを止めると影響範囲はどこか」が一目でわかります。インシデント対応にも直結します。

データカタログ（企業レベル）

データアーキテクチャ章で扱ったデータカタログを、EA レベルで全社展開したものです。データのメタデータ・所有者・利用状況を統合管理し、データに関するGoogle Searchを実現します。

ツール	特徴
Collibra	商用・エンタープライズ
DataHub	LinkedIn OSS
Alation	AI 搭載・商用
Apache Atlas	Hadoop 系 OSS
Informatica EDC	統合スイート

部門別カタログの統合が EA レベルの課題で、バラバラのカタログを連携させる工夫が必要です。

データガバナンス体制

全社データを管理する組織体制です。技術だけでなく役割と権限の設計が重要で、データガバナンス委員会を設置するのが一般的です。

役割	責任
Chief Data Officer（CDO）	全社データ戦略
データガバナンス委員会	ルール・優先順位
データオーナー	ドメイン責任者
データスチュワード	日常管理
データユーザー	利用者・準拠義務

CDOの設置は2015年以降のトレンドで、データを経営資産として扱う企業では必須のポジションです。

データとクラウド

現代 EA の DA は、クラウド DWH（Data Warehouse＝データウェアハウス、分析用に整理された統合データベース）・データレイク・レイクハウスを前提に設計されます。「社内DBを集約」から「クラウド上に統合データ基盤」へ設計パラダイムが変わっています。

役割	主要ツール
DWH	Snowflake・BigQuery
データレイク	S3・GCS・ADLS
レイクハウス	Databricks・BigLake
ストリーミング	Kafka・Kinesis
ETL／ELT	Fivetran・dbt
カタログ	DataHub・Collibra

クラウド前提で EA の DA を描き直すのが、2020年代のエンタープライズアーキテクトの仕事になっています。

データセキュリティとプライバシー

EA の DA はデータの機密性分類も含みます。「公開・内部・機密・極秘」のラベリングで、どのデータを・誰が・どう扱うかをガバナンスします。

分類	対象	扱い
公開	Webページ・IR 情報	自由
内部	社員向け情報	社内限定
機密	営業計画・契約情報	アクセス制限
極秘	個人情報・財務機密	強暗号・監査ログ

個人情報の所在地図（PII Inventory＝Personally Identifiable Information、個人を特定できる情報の目録）は GDPR 対応で必須の成果物で、EA の DA が整っていないと作れません。

判断基準①：データ利用の戦略性

データを経営資産として活用する企業ほど、EA の DA が重要になります。データを業務ログとしか見ない企業では、詳細な DA は過剰です。

戦略性	推奨
データ単なる記録	DA は最小限
BI（Business Intelligence＝データ分析による経営意思決定）で意思決定	概念モデル + カタログ
AI で自動判断	フル DA + ガバナンス
データ自体が商品	CDO + 専門組織

判断基準②：組織の規模と複雑さ

複雑な組織ほど DA の整備コストは上がりますが、投資対効果も大きくなります。単一製品の中小企業と、多角化した大企業では必要な DA の深さが違います。

組織	推奨
単一事業	概念モデル + 主要 DB 設計
複数事業	ドメイン分割 + MDM
M&A 実行中	統合前提のマスタ整合
グローバル	地域別・規制別の設計

ケース別の選び方

スタートアップ・単一事業

概念モデル + BigQuery／Snowflake + dbt。専門 CDO は不要、エンジニアリングマネージャが兼任。データカタログは dbt docs で十分、マスタ統合は必要になったら着手します。

中堅企業・BIドリブン経営

ドメイン分割 + DataHub／Alation + データスチュワード配置。3〜5ドメインに分割し、各ドメインに兼任スチュワードを置く。MDM は Coexistence 方式で段階統合、BI ツール（Tableau／Looker）で意思決定層に届けます。

大企業・多角化事業

CDO 設置 + Collibra／Informatica + MDM 専用チーム。データガバナンス委員会を経営直下に設置、M&A 対応のマスタ統合プロジェクトを常設化。地域別・規制別の DA を ArchiMate で管理、GDPR／個人情報保護法対応の PII Inventory を自動生成します。

データ自体が商品の企業（広告・金融・SaaS）

Data Mesh + セマンティック層（dbt semantic layer／Cube.js）+ AI Ready 設計。ドメインがデータプロダクト化して他部署／顧客に提供、AI エージェントがセマンティック層経由で自律クエリ。全データに鮮度・品質 SLA を付与します。

よくある勘違い

DB設計があればEAのDAは不要

個別 DB 設計と全社視点は別物です。ドメイン分割・マスタ整合は DB 設計の外側の仕事。

データカタログを買えばDAが完成

ツールは手段。体制・ルール・運用が実体。カタログだけ入れても放置されて腐ります。

CDOは大企業だけのもの

近年は中堅でも CDO を置く。データ戦略を経営アジェンダにするかどうか。

マスターデータ統合すれば問題解決

統合自体が難事業です。段階的・現実的に進めるのが成功の秘訣。

MDM統合の段階別実務表

MDM は「完璧な中央集権」を目指すと破綻するため、既存システムを壊さない段階的統合が現実解です。

フェーズ	期間目安	対応範囲	投資目安
①現状棚卸し	1〜3か月	主要マスタ（顧客・商品）のID体系を把握	数百万円
②Registry統合	6〜12か月	各システムのIDを相互参照可能に	数千万円
③Coexistence双方向同期	1〜2年	各システムと双方向同期、属性値統一	数千万〜億円
④Golden Record確立	3〜5年	唯一の正本データを確立	数億円規模
⑤Centralized（理想）	長期	単一マスタへ完全集約	事実上不可能な企業多数

MDM投資の実質下限は中堅企業以上。スタートアップ・小規模 SaaS では MDM は過剰で、PostgreSQLのマスタテーブル + 共通ID命名規則で十分です。Uber の2014年「ダッシュボード戦争」（同じ「週次ライド数」が3〜5種類並存、CEO と現場の数字が食い違う事態）は、中央MDMの必要性を示した典型事例です。

MDM はCoexistenceで段階統合。完璧な中央集権を目指すと必ず失敗します。

EA観点DAの鬼門・禁じ手

EA の DA で事故る典型パターン。どれも「同じ顧客が3つのIDで登録」「経営会議で数字がずれる」の原因になります。

禁じ手	なぜダメか
用語定義を全社で揃えない	「今月の売上」が部署で3〜8%ずれる、議論が平行線
マスタ統合を一気にCentralizedで目指す	既存基幹系を止めて移行、事業停止リスク
データカタログを入れただけで放置	スチュワードなし、メタデータ更新されず腐る
データドメインを組織名で分割	組織変更で所有権が消失、能力単位で分割
PII Inventoryを作らない	GDPR 対応不能、Meta €1.2B 制裁金と同じリスク
セマンティック層なしでAIにDB直結	AI が「売上」を誤解、ハルシネーション量産
CDOを置かずに全社データ戦略を語る	経営アジェンダに乗らず、部門戦争で頓挫
データ分類（公開／内部／機密／極秘）を運用せず	個人情報の扱いが曖昧、法規制違反
既存システムを止めてMDM導入を試みる	事業停止で大炎上、Coexistence で段階統合
メタデータをPDF／Excelで管理	AI が読めない、継続更新されず陳腐化

Uberの2014年ダッシュボード戦争は、Michelangelo（ML プラットフォーム）と Querybuilder（セマンティック層）の内製で「指標の定義は GitHub PR で合意する」文化を根付かせ、指標論争をエンジニアリング作業に変換した成功事例として語られます。

EA 観点の DA は「技術より先に言葉の定義」全社で用語を揃えるのが第一歩です。

AI時代の視点

AI 駆動開発（バイブコーディング）と AI 活用が前提になると、EA の DA はAIエージェントにとってのアクセス可能なデータ空間として再設計されます。AI がデータを自律的に探す時代には、全社データが AI から見えるかが競争力を決めます。

AI時代に有利	AI時代に不利
データメッシュ（ドメイン所有）	中央集権サイロ
APIで参照可能なデータ	Excel・ファイル
セマンティック層（用語定義）	未定義のカラム名
継続更新のカタログ	半年前のスナップショット

AI Ready なデータアーキテクチャとして、セマンティック層（dbt semantic layer・Cube.js 等）の整備が注目されています。AI が「売上」と聞いて正しい集計ロジックにたどり着ける設計が必要です。

AI 時代の DA はAIが理解できる語彙で設計する。セマンティック層が鍵です。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

概念データモデル（主要エンティティ10〜30）
データドメイン分割（誰が所有するか）
マスターデータ戦略（統合方式）
データカタログ（ツール・運用）
ガバナンス体制（CDO・委員会）
データ分類ポリシー（公開／内部／機密／極秘）
クラウドDWH戦略（Snowflake／BigQuery等）

筆者メモ — 「数字が合わない」が新プロジェクトを止めた事例

全社データの定義がバラバラであることの本当の怖さは、障害時ではなく「意思決定時」に表面化します。

中堅小売企業で「全社売上ダッシュボードを作る」DX プロジェクトが始まり、財務系・販売系・EC 系の DB から売上データを集約したところ、3系統の数字が毎月3〜8%ずれることが判明。原因は「売上計上は注文時か出荷時か」「消費税込みか別か」「返品処理はいつ反映するか」がシステムごとに違ったためで、調査と定義合意に半年以上費やし、経営会議向けダッシュボードは着手から1年半遅れで稼働した、という話は業界で繰り返し語り草になっています。

もう一つ、Uberの2014年の「ダッシュボード戦争」も有名な事例です。Uber は急成長期にチームごとに独立したデータパイプラインを作った結果、同じ「週次ライド数」という指標が社内ダッシュボードで3〜5種類並存し、CEO が見る数字と現場が見る数字が食い違う事態に陥りました。最終的に Uber は Michelangelo（ML プラットフォーム）と Querybuilder（セマンティック層）を内製し、全社で指標を1回だけ定義して再利用する仕組みに切り替えました。以降 Uber の社内では「指標の定義は GitHub の PR で合意する」文化が根付き、指標論争がエンジニアリング作業に変換されました。

どちらも「技術より先に、言葉の定義を全社で揃える」ことの決定的な価値を突きつけます。EA の DA がない企業では、AI エージェントが「今月の売上は？」と聞いた時点で、AI も3つの違う答えを返すだけです。

最終的な判断の仕方

EA 観点の DA の核心は個別DBではなく、全社データを戦略資産として設計するという視点です。サイロ化したデータ・同じ顧客が3つのIDで登録・経営会議で数字が違う──これらは DB の技術問題ではなく、企業レベルのデータ体系の欠陥です。ドメイン分割してデータオーナーを置き、MDM で基幹データの唯一性を確保し、概念モデル・データフロー・カタログで全社の地図を作るのが EA レベルの DA の仕事になります。MDM は Coexistence 方式で段階統合するのが現実的で、完璧な中央集権を目指すと破綻します。

もう一つの決定的な軸はAIエージェントが自律的に理解できるデータ空間の構築です。AI が「売上」と聞いて正しい集計ロジックにたどり着けるためには、セマンティック層（dbt semantic layer・Cube.js）が必須です。Data Mesh でドメインがデータプロダクトを他部署・AI に提供し、API 参照可能・継続更新のカタログが整っている企業だけが、AI 活用でも競争力を持てます。

選定の優先順位

ドメイン分割とデータオーナー — 所有権を明確化、ガバナンスの土台
MDMはCoexistence方式で段階統合 — 完璧な中央集権は失敗、既存を壊さない
データ分類でプライバシー対応 — 公開／内部／機密／極秘、PII Inventory 整備
セマンティック層でAIに語彙を渡す — dbt semantic layer・Cube.js、AI Ready 設計

「AIが理解できる語彙でデータを設計する」ドメイン分割 + MDM + セマンティック層が核です。

まとめ

本記事はEA観点のデータアーキテクチャについて、概念モデル・ドメイン・MDM・カタログ・PII Inventory・セマンティック層・AI Ready設計まで含めて解説しました。如何だったでしょうか。

ドメイン分割とデータオーナーで所有権を明確化、MDMはCoexistenceで段階統合、データ分類でプライバシー対応、セマンティック層でAIに語彙を渡す。これが2026年のEA観点DAの現実解です。

次回はアプリケーションアーキテクチャ（AA）（システムポートフォリオ・連携パターン）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。