データは、“貯める”から“使わせる”へ？── データアーキテクチャは、“保管する構造”から“判断に届ける構造”へ

3. 中央集権は、なぜAI時代に行き詰まるのか？

従来のデータアーキテクチャは、中央集権型DWHを中心に発展しました。基幹データを集約し、データ連携基盤で加工し、BIや定型帳票で可視化するこの構造は、部門ごとにバラバラだった数字を一元管理し、経営指標を標準化するうえで、大きな役割を果たしてきました。

しかし、この構造は、「過去を正確に記録し、定期的に確認する」前提で設計されており、AI時代には構造的限界を迎えつつあります。例えば、分析要件ごとにデータ変換処理の変更が必要で時間がかかる、バッチ処理前提のため意思決定の鮮度が低下する、構造化データ中心で非構造データを活用しづらく、データ活用がSIer依存になりやすいといった課題が顕在化してきています。また、「人がBIを見て判断する」前提が、AIが意思決定を支援する時代の構造とは根本的に合わなくなってきているのです。

4. データを流通させれば、意思決定は速くなるのか？

クラウド・デジタル時代には、データレイクハウス、データファブリック、データカタログ、リアルタイム連携が重要になりました。データファブリックの考え方は、「データを1カ所に集める」から「分散したデータを意味・権限・品質でつなぎ、流通させる」へのパラダイム転換を象徴しています。

では、データを流通させれば、それだけで意思決定は速くなるのでしょうか。一見すると、データがつながることで、より迅速な意思決定が可能になるようにも思えます。

しかし、実際には新たな課題が生まれています。AI活用ではPoCが乱立し、業務プロセスや意思決定モデルに組み込まれないまま終わるケースが頻発しました。PoCで検証するのは「技術の有効性」ですが、業務への組み込みに必要なのは「意思決定との接続」です。予測モデルの精度を確認しても、その予測を誰がどのタイミングでどの判断に使うかが設計されていなければ、実装には進みません。これは、データアーキテクチャの問題であると同時に、「問いの設計」が欠けていることにも起因しています。

5. AIが、データの”意味”を理解する日が来る？

AI時代のデータアーキテクチャは、AIエージェントが、目的に応じて必要なデータ、API、ナレッジを探索し、意味を理解し、選択肢を提示し、実行まで支援するための構造として再定義されます。ここで重要になるのが、Agentic データファブリックという考え方です。経営層が「来四半期の利益リスクを教えてほしい」と問えば、AIは売上見込み、受注残、在庫、為替、物流コスト、顧客別収益性などを横断参照する必要があります。このとき必要なのは、単なるDB（データベース）接続ではありません。どのデータが正式な売上か、どの予測値は参考値か、どの部門は締め処理前か、どの情報は役員のみ閲覧可能か――こうした意味・文脈・権限・品質・制約を理解することで、AIは経営判断に堪える示唆を出すことができるのです。つまりデータを、AIが「理解して使える」状態にする必要があります。

AI時代のデータアーキテクチャ要素は5つあります。

1. Semantic Layer：業務上の意味、KPI定義、業務ルールを管理する層です。
2. Knowledge Graph：顧客、製品、契約、組織、リスクの関係性を構造化し、AIが文脈として理解できるようにします。
3. Vector DB／RAG基盤：契約書、議事録、設計書、問い合わせ履歴などの非構造データを検索・参照可能にします。
4. Agent Orchestration：複数AIエージェントが業務目的に応じてデータ、ツール、API、アプリケーションを呼び出し、人の判断や業務実行を支援します。
5. Policy & Governance Layer：AIのデータアクセス、自律実行範囲、人の承認要件を制御します。ガバナンスを「障壁」ではなく「ガードレール」として設計します。

6. データは集約するべきか、分散のまま流通するべきか？

今後必要なのは、個別技術の導入ではなく、意思決定・データ・AI・業務・組織・ガバナンスを統合した全体最適の設計です。そこでは、データはFederated Data（分散したまま管理・活用されるデータ）として存在します。ERP、SaaS、クラウド、DWH、データレイク、外部・非構造データが分散したまま、それらを意味・権限・品質・文脈でつなぎ、AIと人が判断に使える状態にします。意思決定スピードを根本から制約する、従来の「全データを中央集約してから活用する」という発想からの転換が重要なのです。

このような分散前提の環境では、データをつなぐだけでなく、意思決定と業務をどのように実行するかまで設計することが求められます。Agentic Workflowでは、AIエージェントが単一業務の補助だけでなく、データ取得、分析、仮説生成、選択肢提示、承認依頼、業務実行までを横断支援します。Human-in-the-loop設計で、AIの自律範囲と人の介在点を明確にします。また、Product Operating Modelも欠かせません。データ・AI基盤を作って終わりにせず、データプロダクト・AIプロダクト・エージェント機能として継続改善する運営モデルが不可欠です。最も避けるべきは部分最適であり、これらを「経営の実行構造」として統合する必要があります。

7. データ整備の前に、何を問うべきか？

Phase 1：問いの設計と意思決定の可視化

最初に行うべきは、データ項目の整理でもツール選定でもなく、「どの経営課題を、どの意思決定で解くのか」の定義です。売上成長、原価低減、在庫最適化、顧客体験向上――強化すべき経営能力を定義し、それを支える意思決定を分解します。どの会議体で、誰が、どの情報を見て、何を判断しているのか。そしてその意思決定を、AIによってどう速く、正確に、先回りできるかを整理します。そのうえで、必要なデータ、AI機能、業務プロセス、組織体制、ガバナンスを定義します。「問い」と「意思決定」を設計する順序が、成否を分けます。

Phase 2：PoCで終わらせず、業務に組み込む

PoCで終わらせないためには、業務プロセス、会議体、KPI、権限、運用体制まで含めて業務に組み込む必要があります。

需要予測AIであれば、予測結果を誰が確認し、どの条件で生産計画を変更し、どの例外は人が判断するかまで設計します。精度検証はPoCで行いますが、「意思決定との接続」は業務設計として別途行います。この二段階を整理して進めない限り、PoCと本番の間に壁が生まれます。

さらに、こうした取り組みを一過性のもので終わらせないためには、初期テーマで得たデータ定義、Semantic Layer、AIエージェント設計、ガバナンスルールを、他領域へ展開可能な形で整備し、全社の意思決定モデルとしてスケールさせることが重要です。

8. データの”量”より”使わせ方”が勝負を分けるか？

EYは、データアーキテクチャを単なるデータ基盤整備やAIツール導入としては捉えていません。経営、事業、業務、データ、AI、テクノロジー、ガバナンスを統合し、企業の意思決定構造を変革する取り組みとして支援します。

構想フェーズでは、経営、事業、IT、データ、AIを統合し、高度化すべき意思決定を明確化します。そのうえで、AI時代におけるデジタル・エンタープライズ・アーキテクチャの将来像を描き、ロードマップを定義します。実行フェーズでは、業務への組み込みと実行支援まで伴走し、KPI、権限、運用体制、データガバナンス、AIガバナンスを整備します。

AI時代の競争優位は、データ量では決まりません。どの意思決定を変えるために、どのデータを、どのAIに、どのルールで使わせるかを設計できる企業こそが、競争に勝つのです。データアーキテクチャとは、もはやIT基盤の設計ではなく、AI時代の経営を動かす意思決定アーキテクチャそのものです。