本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「エンタープライズアーキテクチャ」カテゴリ第3弾として、EA観点のデータアーキテクチャ（DA）について解説する記事です。
データアーキテクチャ章（40系）が「個別システムの実装」を扱うのに対し、本記事は「企業横断の整合性」を扱います。例えば「顧客マスタを一元化する」が本記事、「どのDBに置くか」が40系の仕事です。本記事ではマスタデータ管理（MDM）・データガバナンス・全社データ流通・CDO/データスチュワードの役割まで、CDO・データ部門長向けに解説します。
本記事のテーマについてさらに詳しく知りたい方は『データ視覚化のデザイン』も参考にしてみてください。
この記事の結論
- ドメイン分割とデータオーナーで所有権を明確にする
- MDMはCoexistence方式で段階統合する
- セマンティック層でAIに全社の語彙を渡す
この記事を読む前に
本記事は会社全体のシステムをどう整理するかという話が中心で、技術用語は比較的少なめです。とは言っても、Webサービスの基本構造を知っていると読みやすくなりますので、不安な方は基礎編の「Webサービスが動く仕組み」からどうぞ。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもEA観点のデータアーキテクチャとは何か
図書館の蔵書分類を想像してください。各分館が独自の分類体系で本を整理していたら、「この本はどの分館にあるか」を誰も即答できません。全館共通の分類と検索システムがあって初めて、どの分館からでも目的の本にたどり着けます。
EA観点のデータアーキテクチャ（DA）は、企業全体のデータ資産を体系的に整理する領域です。個別システムのDB設計が「その業務のデータ」を扱うのに対し、EA-DAは全社レベルで「どのデータが・どこにあり・どう流れるか」の地図を描きます。個別DB設計＝戦術、EAのDA＝戦略──視点が一段高いのです。
もしDAがなければ、同じ顧客データが部署ごとにバラバラの形式で存在し、全社分析もAI活用も不可能になります。
なぜDAが必要か — 「今月の売上」が部署で違う会社
第一に、サイロ化したデータの統合です。部署ごとに別々のシステムでデータを持つと、同じ顧客が3つのIDで登録されている状態になります。
第二に、データドリブン経営の土台です。経営会議で財務部が出した「今月の売上」と営業部が出した「今月の売上」が5%近く食い違い、議論が毎月そこから始まる──という光景が報告されることがあります。原因を辿ると、返品・値引・消費税・計上タイミングの扱いが部署ごとに微妙に違い、誰の数字も各部署の定義では正しい状態。データそのものより、言葉の定義を全社で揃えていないことの方が深刻です。
第三に、規制・プライバシー対応です。GDPR・個人情報保護法対応には個人情報の所在地図が必須で、DAの整備が監査対応の前提になります。
DAの主要構成要素
EAのデータアーキテクチャは、単なるER図ではなく、戦略・運用・技術の全観点を含みます。
| 要素 | 内容 |
|---|---|
| 概念データモデル | 全社の主要エンティティ |
| データドメイン | 関連データのグルーピングと所有権 |
| データフロー図 | システム間のデータ移動 |
| データカタログ | 全データの目録 |
| マスターデータ管理 | 基幹データの唯一性 |
| データガバナンス | 管理体制・ルール |
概念データモデルは、全社で扱う主要なエンティティ（顧客・商品・注文・従業員・取引先）を10〜30個程度で表現します。「user_account」ではなく「顧客」とビジネスの言葉で描くのが鉄則で、業務部門と技術部門の共通言語にします。
データドメインは「顧客ドメイン」「商品ドメイン」「財務ドメイン」のようにビジネス機能別に分け、それぞれにデータオーナーを置く現代的なアプローチです。Data Meshの考え方では、ドメインがデータの所有権と責任を持ち、ドメイン内で完結した良質なデータを他ドメインに提供します。
マスターデータ管理（MDM）
基幹となるデータを全社で一元管理する仕組みです。「顧客ID」「商品コード」などのマスターデータが部署ごとに違うと全社分析が不可能になります。MDMは唯一の正しい情報源を作ります。
| MDMの構築方式 | 内容 |
|---|---|
| Registry方式 | 各システムのデータはそのまま、IDだけ統合 |
| Consolidation方式 | 読取専用の統合データ |
| Coexistence方式 | 各システムと双方向同期 |
| Centralized方式 | 単一のマスタシステムに集約 |
現実にはCoexistence方式が選ばれます。理由は明確で、Centralizedは理想的ですが既存の基幹系・CRM・ERPを止めて単一マスタに寄せる移行コストが巨大で、稼働中の事業を止めずにやり切れる企業はほぼありません。Consolidationは読取専用のため結局二重管理が続き、RegistryはIDだけ繋げる軽い方式ですが属性値の不整合（同じ顧客で住所が違う等）を解消できません。Coexistenceは既存システムの更新を生かしたまま双方向同期でマスタを整えるため、既存資産を壊さず・初期コストを抑え・完全統合の失敗リスクを避ける三拍子が揃います。
データフロー・カタログ・ガバナンス体制
データフロー図はシステム間のデータ移動を全社単位で可視化します。このレベルの図があれば「あるシステムを止めると影響範囲はどこか」が一目でわかり、インシデント対応にも直結します。
データカタログはデータのメタデータ・所有者・利用状況を統合管理し、データに関するGoogle Searchを実現します。主役は商用エンタープライズのCollibraとLinkedIn発OSSのDataHub。その他、AI搭載のAlation・Hadoop系のApache Atlas等があります。部門別カタログの統合がEAレベルの課題です。
ガバナンス体制は技術だけでなく役割と権限の設計が重要です。全社データ戦略を担うCDO（Chief Data Officer、2015年以降のトレンドでデータを経営資産として扱う企業では必須）、ルールを決めるデータガバナンス委員会、ドメイン責任者のデータオーナー、日常管理のデータスチュワードという階層で運用します。
データの機密性分類（公開・内部・機密・極秘）も EA-DAの守備範囲です。個人情報の所在地図（PII Inventory）はGDPR対応で必須の成果物で、DAが整っていないと作れません。なお現代のDAはクラウドDWH（Snowflake・BigQuery）・データレイク・レイクハウスを前提に設計されます（実装詳細はデータ基盤の記事参照）。
規模・戦略性で変わる投資水準
DAの重装度はデータ利用の戦略性と組織の複雑さで決まります。スタートアップ・単一事業なら概念モデル + BigQuery / Snowflake + dbtで十分で、専任CDOは不要、カタログはdbt docsで代替できます。BIドリブンの中堅企業は3〜5ドメインに分割して兼任スチュワードを置き、MDMはCoexistenceで段階統合します。多角化した大企業はCDO設置 + Collibra / Informatica + MDM専用チームで、ガバナンス委員会を経営直下に置きます。データ自体が商品の企業（広告・金融・SaaS）はData Mesh + セマンティック層 + AI Ready設計まで踏み込み、全データに鮮度・品質SLAを付与します。
MDM統合の段階別実務表
MDMは「完璧な中央集権」を目指すと破綻するため、既存システムを壊さない段階的統合が現実解です。
| フェーズ | 期間目安 | 対応範囲 | 投資目安 |
|---|---|---|---|
| ①現状棚卸し | 1〜3か月 | 主要マスタ（顧客・商品）のID体系を把握 | 数百万円 |
| ②Registry統合 | 6〜12か月 | 各システムのIDを相互参照可能に | 数千万円 |
| ③Coexistence双方向同期 | 1〜2年 | 各システムと双方向同期、属性値統一 | 数千万〜億円 |
| ④Golden Record確立 | 3〜5年 | 唯一の正本データを確立 | 数億円規模 |
| ⑤Centralized（理想） | 長期 | 単一マスタへ完全集約 | 事実上不可能な企業多数 |
MDM投資の実質下限は中堅企業以上です。スタートアップ・小規模SaaSではMDMは過剰で、PostgreSQLのマスタテーブル + 共通ID命名規則で十分です。
AI判断軸 ― AIが理解できる語彙でデータを設計する
セマンティック層がAIのデータ理解を正確にする
dbt semantic layerやCube.jsで「売上＝注文テーブルのamountの合計（返品を除く）」のようなビジネス用語の計算定義を明文化しておけば、AIに「今月の売上を出して」と質問した際に正確なSQLが生成されます。セマンティック層なしでは、AIが「売上」の定義を推測してテーブルを間違える事故が起きます。EAのDAがない企業では、AIエージェントに「今月の売上は？」と聞いた時点で、AIも3つの違う答えを返すだけです。
データメッシュとAIの相性
データメッシュ（ドメインチームがデータの品質と公開に責任を持つ方式）は、AIエージェントが必要なデータを自律的に発見・取得する構成と相性が良いです。各ドメインがAPIでデータプロダクトを公開していれば、AIはカタログ経由でデータを見つけ、API経由で取得する自律的なワークフローを構築できます。APIで参照可能・継続更新のカタログ・定義済みの語彙──AI Readyなデータ空間が競争力を決めます。
やってはいけないこと
EAのDAで事故る典型を、特に危険な6つに絞ります。どれも「同じ顧客が3つのIDで登録」「経営会議で数字がずれる」の原因になります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 用語定義を全社で揃えない | 「今月の売上」が部署で3〜8%ずれ議論が平行線 → 技術より先に言葉の定義を揃える |
| マスタ統合を一気にCentralizedで目指す | 既存基幹系を止める移行で事業停止リスク → Coexistenceで段階統合する |
| データカタログを入れただけで放置 | メタデータが更新されず腐る → スチュワードと更新運用をセットにする |
| データドメインを組織名で分割 | 組織変更で所有権が消失 → 能力単位で分割する |
| PII Inventoryを作らない | GDPR対応不能（Meta €1.2B制裁金と同種のリスク） → データ分類と所在地図を整備する |
| セマンティック層なしでAIにDB直結 | AIが「売上」を誤解しハルシネーション量産 → dbt semantic layer等で語彙を定義する |
なお「DB設計があればEAのDAは不要」という考えも誤りです。個別DB設計と全社視点は別物で、ドメイン分割・マスタ整合はDB設計の外側の仕事です。
筆者メモ — 「数字が合わない」が新プロジェクトを止めた事例
中堅小売企業で「全社売上ダッシュボードを作る」DXプロジェクトが始まり、財務系・販売系・EC系のDBから売上データを集約したところ、3系統の数字が毎月3〜8%ずれることが判明。原因は「売上計上は注文時か出荷時か」「消費税込みか別か」「返品処理はいつ反映するか」がシステムごとに違ったためで、調査と定義合意に半年以上費やし、ダッシュボードは着手から1年半遅れで稼働した、という話は業界で繰り返し語り草になっています。
もう一つ、Uberの2014年「ダッシュボード戦争」も有名な事例です。Uberは急成長期にチームごとに独立したデータパイプラインを作った結果、同じ「週次ライド数」という指標が社内ダッシュボードで3〜5種類並存し、CEOが見る数字と現場が見る数字が食い違う事態に陥りました。最終的にUberはMichelangelo（MLプラットフォーム）とQuerybuilder（セマンティック層）を内製し、全社で指標を1回だけ定義して再利用する仕組みに切り替えました。以降「指標の定義はGitHubのPRで合意する」文化が根付き、指標論争がエンジニアリング作業に変換されました。
どちらも「技術より先に、言葉の定義を全社で揃える」ことの決定的な価値を突きつけます。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 概念データモデル（主要エンティティ10〜30）
- データドメイン分割（誰が所有するか）
- マスターデータ戦略（統合方式）
- データカタログ（ツール・運用）
- ガバナンス体制（CDO・委員会）
- データ分類ポリシー（公開 / 内部 / 機密 / 極秘）
- セマンティック層（AIに渡す語彙の定義）
この記事に関連する記事
まとめ
本記事はEA観点のデータアーキテクチャについて、概念モデル・ドメイン・MDM・カタログ・PII Inventory・セマンティック層・AI Ready設計まで含めて解説しました。如何だったでしょうか。
ドメイン分割とデータオーナーで所有権を明確化、MDMはCoexistenceで段階統合、データ分類でプライバシー対応、セマンティック層でAIに語彙を渡す。これが2026年のEA観点DAの現実解です。
次回はアプリケーションアーキテクチャ（AA）（システムポートフォリオ・連携パターン）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS データ分析サービス も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（77/95）