データモデリングが再び注目されている理由:そしてAIを実際に機能させるために重要な理由

Rethinking UX with AI Hero

最近、データリーダーやアーキテクトと話す機会が増えていますが、皆が同じ課題に直面しています。
どうすればAIをエンタープライズで実際に機能させられるのか?

もはやチャットボットを作ることやモデルを接続することが問題ではありません。
本当の問題は、AIが企業のビジネスロジックを理解し、判断し、行動できるだけのコンテキストをどう与えるかです。

そしてそこで、何十年も前から存在する概念が再び重要になっています。
それがデータモデリングです。

AIに必要なのはデータではなくコンテキスト

これまでデータモデリングは、BIダッシュボードを高速化したり、レポートを作りやすくしたりするための裏方の技術として扱われてきました。
当時はそれで十分でした。なぜなら、機械に意思決定をさせていなかったからです。

しかし現在、観察・推論・実行を自律的に行うエージェント型AIの登場によって、問題は変わりました。
AIはデータを読むことはできます。しかし、ビジネスロジックはモデリングされていなければ理解できません。

例えば:

  • 顧客は請求書に紐づいた時点でアカウントになる
  • リードはウェビナー参加で有効商談になる
  • 候補者はオファーがサインされた時点で社員になる

これらは世界共通のルールではありません。企業ごとに定義が異なります。
そしてAIが最も苦手なのが、意味・関係・状態遷移の理解です。
それこそがデータモデリングが本来担っていた役割です。

レポーティングから推論へ:データモデリングの進化

データウェアハウスの父とも呼ばれるRalph Kimballは、AIが登場するずっと前からこの重要性を理解していました。

彼のディメンショナルモデリングでは、

  • Fact = 測定可能なイベント(売上、取引など)
  • Dimension = ビジネスコンテキスト(顧客、地域、商品など)
    という構造でビジネスプロセスとデータの関係を定義しました。

重要なのはテーブル構造ではなく、ビジネスがどのように考えるかをモデル化することでした。

そして今、その考え方が再び重要になっています。
AIと自動化は、エンティティ間の関係やビジネスルールといった**意味理解(セマンティクス)**に依存しているからです。

Kimballのアプローチは今でも有効です:

  • 概念モデル:意味を定義する(顧客とは何か、取引とは何か)
  • 論理モデル:関係を定義する(顧客と請求書の関係など)
  • 物理モデル:データシステム上で実装する

AIがこれらを理解すると、推測ではなく推論できるようになります。

例:自動化によってデータをコンテキストに変える

あるグローバル金融企業のお客様は、AIが顧客データを分析できても意味を理解できないという課題を抱えていました。

各部門がそれぞれ
「顧客」
「アカウント」
「関係」
「ポートフォリオ」
を異なる意味で定義していたのです。

AIは不完全または矛盾したデータに基づいてアクションを提案していました。

そこで、Workatoのプラットフォームを使い、イベント駆動型のモデリングデータレイヤーを構築しました。
ビジネス定義をリアルタイムイベント構造にマッピングしたのです。

例えば:

CRMで「ポートフォリオ価値変更」イベントが発生すると、
コアシステムの「顧客リスクカテゴリ」データと自動的に関連付けられる。

自動化レシピにより、属性は標準化・強化され、AIは常に同じコンテキストで動作できるようになりました。

結果はどうなったでしょうか。

AIの意思決定が一貫し、説明可能になり、ビジネスルールと一致するようになった。
つまり、AIが初めてビジネスを理解したのです。

例:小売業におけるデータの混乱から整理へ

別のグローバル小売企業では、マーケティングAIが解約予測は得意でも、なぜ解約が起きるのか理解できないという問題がありました。

原因はデータ量ではなくコンテキスト不足でした。

顧客、注文、商品データが多数のSaaSに分散し、
「返品」
「キャンセル」
「プロモーション」
の定義がシステムごとに異なっていたのです。

Kimball型の概念モデルを適用し、顧客行動データと業務指標をモデリング構造で再定義しました。

ビジネスロジックがモデリングされ、自動化でシステム間に展開されると、AIはそれまでランダムに見えていたパターンを識別し始めました。

特定のプロモーションコード後の返品は品質問題ではなく、物流遅延による顧客不満だったことが判明したのです。

データは変わっていない。変わったのはモデルです。

AI時代における欠けているリンク:コンテキスト

AtlanのActivate 2025イベントでも、AIに必要なのはモデルではなくコンテキストだと発表されました。

彼らのApp Framework、Metadata Lakehouse、AI Governance Studioなども、同じ考え方に基づいています。

重要な言葉があります:

モデルを作るのは簡単だった。
問題はデータとコンテキストだった。

これは私たちが現場で見ていることと完全に一致しています。
AIプロジェクトが止まる理由はアルゴリズムではなく、意味の共有・関係のガバナンス・一貫したコンテキストがないからです。

KimballからCognitiveへデータモデルはAIの脳になる

BI時代、データモデルはレポートのためのものでした。
AI時代、データモデルは推論のためのものです。

AIは行と列ではなく、

  • オントロジー
  • セマンティクス
  • ロジック
    を必要とします。

成功しているエンタープライズAIは、すべてコードではなく概念モデルから始まります。

AIは次のような関係を理解する必要があります:

  • Closed Won → 請求ワークフロー開始
  • Onboarding完了 → サポートチケット作成
  • 契約期限 → 更新またはアップセル

これらの関係がモデリングされていなければ、AIは何も理解できません。

Workatoの役割:モデリングからオペレーショナルインテリジェンスへ

Workatoではモデリングを理論ではなく、企業全体でデータと意思決定がどのように流れるかを定義する実装フレームワークとして捉えています。

AI対応アーキテクチャを構築するための3つの要素:

Event Streams

JSON、API、Webhookなどの半構造データをリアルタイムのビジネスイベントに変換し、AIと自動化が状態変化を理解できるようにします。

AI@Work

イベントデータをビジネスコンテキストで解釈し、インサイトやアクションへ変換します。

Intelligent Orchestration

顧客、注文、資産、取引などのすべてのエンティティを横断ワークフローで接続し、企業全体で一貫した意思決定とアクションを実現します。

これらはAgentic Enterpriseの神経系となります。

結論:AIはデータではなくモデルで考える

Ralph Kimballはこう言いました。
モデリングの目的は、ビジネスとデータを結びつけることだ。

今、私たちは再びそれをやる必要があります。
今回はAIのために。

AIはデータを食べるのではありません。
関係・階層・意味で考えるのです。

AIで成功している企業は、単にデータ量を増やしているのではありません。
より良いコンテキストを与えているのです。データモデリングが再び注目されているのは懐古ではありません。
AIがそれなしでは機能しないからです。