この記事は note に公開したなぜ AI Ready なデータ基盤が必要なのか — AI 分析が必ず失敗する 3 つの構造的理由を、ブログ用に整形して再掲したものです。
「AI で分析を自動化しよう」と試みた多くの企業が、思うように使えず挫折している。理由は AI モデルの性能ではない。
500 名規模で月 10,000 件の分析を自動化してわかった、なぜ AI 分析が失敗するのか、なぜ AI Ready なデータ基盤が必要なのかを解説します。
前提: 本記事では、AI 分析エージェントを業務で実際に動かすために必要な「AI Ready なデータ基盤」に主軸を置いて話していきます。
AI で分析、失敗していませんか?
「AI を業務に入れたけど、思ったほど使えてない」って、最近よく聞きます。
LLM の精度はもう十分なはず。ChatGPT も Claude も Gemini も、SQL を書かせれば動くものが返ってくる時代です。それなのに、AI に業務質問を投げると、答えがふわっとして「明日の判断には使えないな」になることが多い。
私も最初は「もっといい AI モデルがあれば解決する」と思っていました。
でも、500 名規模で月 10,000 件の分析依頼を捌く AI エージェントを 1 年運用して気づいたのは、問題は AI モデルではなく、データ基盤とハーネス側にあるということでした。
本記事では、AI 分析がうまくいかない 3 つの構造的理由を整理して、なぜ「AI Ready なデータ基盤」が必要なのかを解説します。
AI 分析が失敗する 3 つの構造的理由
AI 分析がうまくいかない理由は、コンテキストと、データモデル、そしてその「紐づけ」の 3 つに分けられます。順番に見ていきます。
理由 1: 貴社固有のコンテキストを AI は知らない
「アクティブ顧客の LTV を出して」と AI に聞いた時、答えは正しく返ってきますか?
おそらく、教科書的な平均 LTV か、定義のはっきりしない数字が返ってきます。なぜなら、「アクティブ顧客って何?」「LTV はどう計算する?」を、AI は知らないからです。
これは AI の性能の問題ではなく、貴社固有のコンテキストが コンテキスト層 として整備されていないことが原因だと思っています。
コンテキスト層とは: 業務語彙(LTV / アクティブ顧客 / 解約 など)・事業ルール・同義語の正規化情報がまとめられている層。AI が「LTV って何?」「アクティブ顧客の定義は?」を解釈するために参照する、業務辞書のような位置づけです。
理由 2: コンテキストがわかっても、どのデータでそれを表現するのか知らない
仮にコンテキスト層が整って、AI が「アクティブ顧客 = 直近 30 日に注文した顧客」「LTV = 顧客生涯の購入累計額」と理解できたとします。
それでもまだ AI は答えを返せません。
なぜなら、「アクティブ顧客」を表現するデータがどのテーブルに入っていて、「LTV」をどう集計するかが定まっていないからです。これが データモデル層 の問題です。
データモデル層とは: コンテキスト層で定義された業務語彙を、データとして表現したテーブル群(ベーステーブル群)と、その使い方を定義しておく層のこと。AI が SQL を組み立てる時に直接読みに行く層です。
理由 3: 2 つの層を紐づける仕組みがない
ここまでで 2 つの層が整ったとしても、まだ AI は迷子になります。
たとえば「LTV」をコンテキスト層で定義し、データモデル層でテーブルとカラムを揃えても、両者が バラバラに管理されている 状態だと、業務側で LTV の定義が更新されたのにデータモデル層は古いまま、というズレが起きます。
実際の現場でよくあるのが、「LTV の定義が部署で 3 通り並走している」という状態。マーケ部門は半年で計算、CS 部門は 1 年で計算、経営層は累計で計算。同じ「LTV」と呼んでいるのに、出る数字が全部違う。
これを解決するために必要なのが、「コンテキスト層」と「データモデル層」を 1 つの定義ファイルで紐づけて管理する仕組み —— 統合オントロジー です。
詳細は 分析自動化AIエージェントの全体像 — 中核に置く『統合オントロジー』とは で書いています。
だから "AI Ready なデータ基盤" が必要
3 つの失敗理由を裏返すと、必要な構成要素が見えてきます。
- 理由 1(コンテキストを知らない)→ コンテキスト層 が必要
- 理由 2(データで表現できない)→ データモデル層 が必要
- 理由 3(2 つが紐づいていない)→ 統合オントロジー が必要
さらに、AI がこれらの層を使って分析する フロー全体 を回すには、AI の暴走を止める ガードレール と、運用を継続改善する 評価ハーネス も必要になります。
これを 1 枚の図にまとめると、次のような構成になります。
[ユーザーリクエスト]
│
│ コンテキスト層で意図分類
▼
[業務語彙レベルの分析要件]
│
│ データモデル層で SQL 組み立て
▼
[text-to-SQL]
│
│ 事前ガードレール(危険 SQL / 誤った前提を弾く)
▼
[SQL 実行 & 結果]
│
│ 事後ガードレール(信頼度・根拠を必ず付ける)
▼
[ユーザー(回答 + 根拠)]
⑤ 評価ハーネス(全層をまたぐ運用層)ユーザーが質問してから AI が回答を返すまでに、コンテキスト層・データモデル層・統合オントロジー・ガードレール・評価ハーネスがすべて機能しています。逆に言えば、どれか 1 つでも欠けると AI 分析は信頼できる答えを返せません。
これが、AI Ready なデータ基盤を「総合的に整える」必要がある理由です。
AI Ready なデータ基盤の 4 つの構成要素
具体的に、何をどう作っていくのか。4 つの構成要素を順番に見ていきます。
構成要素 1: コンテキスト層の整備
業務語彙(LTV / アクティブ顧客 / 解約 など)・事業ルール・同義語の正規化情報を、AI が読める形でまとめます。組織で「LTV って何?」「アクティブ顧客の定義は?」を 1 つに決める作業です。
ここで大事なのは、データ整備の前にコンテキストを決めること。「何を整備するか」が決まっていない状態でデータ整備に走ると、想定外の分析が来た時にズレが必ず出ます。
部署で 3 通り並走している LTV の定義を 1 つに揃える、解約の判定基準を統一する、といった泥臭い合意形成がここに含まれます。
構成要素 2: コンテキスト層とマッチするベーステーブル群を含むデータモデル層の整備
コンテキスト層で決めた業務語彙を、データとして表現します。データモデル層は次の 2 つで構成されます:
- ベーステーブル群: ビジネスドメイン単位(顧客 / 注文 / 解約 / 行動ログ など)で整理され、想定外の分析要求にも耐えうる粒度を持つテーブル群。集計済みの指標ではなく、原因分析や属性別比較の深掘りに使える粒度のまま整備されている。設計の肝は 一貫した命名規則(テーブル名・カラム名の prefix / suffix を揃える)と キー設計(
customer_id/order_idなどの結合キーを全テーブルで統一) - コンテキスト層との紐づけ(統合オントロジー): 「LTV はこの定義で(コンテキスト)、このテーブルのこのカラムで計算する(データモデル)」が 1 ファイルに同居している状態
たとえば「LTV」というエンティティについて、1 つのファイルに以下が全部書かれている状態を作ります:
- 業務定義(コンテキスト層): 「顧客生涯の購入累計額。アクティブ顧客に限定する場合は直近 30 日に注文した顧客のみ」
- 物理表現(データモデル層):
ordersテーブルのamountカラムをcustomer_idで group by して sum
こうすると、業務定義の更新と物理 SQL の更新が 必ず同じ場所で同時に 起きるので、「LTV の定義が 3 通り並走」が起きません。
ベーステーブル群の設計思想は 【500 名規模で 1 年運用】AI 分析エージェントを 1 年運用して見えた、AI Ready なデータ基盤の正体 で、統合オントロジーの中身は 分析自動化AIエージェントの全体像 — 中核に置く『統合オントロジー』とは で、なぜ独立した Semantic Layer ではなく統合オントロジーが良いのかは セマンティックレイヤーが要らない理由 で、それぞれ詳しく書いています。
構成要素 3: 事前・事後ガードレール
AI が SQL を実行する前に危険なクエリや誤った前提を弾く(事前)、回答を返した後に信頼度と根拠を必ず付ける(事後)、の 2 段階チェック です。
事前で弾くもの:
- 全件 DELETE / DROP のような破壊的操作
- 異常に重いクエリ(コスト爆発を防ぐ)
- 曖昧な前提(「全部見せて」のような明らかに範囲不明な質問)
事後で必ず付けるもの:
- 信頼度スコア(AI 自身がこの答えにどれくらい自信があるか)
- 参照したテーブル・カラム
- 実行した SQL の全文
これがあると、AI の回答に対して「本当にこの答えで意思決定していいのか?」のセルフチェックが回ります。
構成要素 4: 評価ハーネス(運用継続層)
AI を導入して終わりではなく、「継続的に育てる」ための仕組みです。
- 回答の正答率(人手レビューで「正しい / 違う」をラベル付け)
- 1 回あたりのコスト(LLM トークン消費 + BigQuery クエリ料金)
- カバレッジ(どんなパターンの質問にちゃんと答えられているか)
これらを定期的に計測して、失敗パターンをコンテキスト層・データモデル層にフィードバックします。「LTV の質問は答えられるけど、解約予測の質問が弱い」が見えたら、解約周りのコンテキストやベーステーブルを補強する、という運用ループ。
まとめ
AI で分析がうまくいかない原因は、AI モデルの性能ではない。
業務語彙(コンテキスト層)、それを表現したデータ(データモデル層)、両者を紐づける統合オントロジー、AI を制御するガードレール、継続改善する評価ハーネス —— この 4 つの構成要素が揃って初めて、AI は「明日の判断に使える答え」を返せるようになります。
「AI 分析を導入したけど、うまく使えていない」と感じている方の参考になれば嬉しいです。
DecisionFlow として、AI Ready データ基盤の構築 + 分析自動化 AI エージェント導入を一気通貫で提供しています。それ以外でもデータ関連のご相談などお気軽にご連絡ください。