この記事は note に公開した【500 名規模で 1 年運用】AI 分析エージェントを 1 年運用して見えた、AI Ready なデータ基盤の正体を、ブログ用に整形して再掲したものです。
「AI 分析エージェントには AI Ready なデータ基盤が必要だよね」
これは AI / データ業界では半ば常識になってきました。 ただ、その「AI Ready」が具体的に何を指すかは、人によって全然違う。
直近 1 年、Slack / Teams / Chatwork に常駐する AI 分析エージェントを500 名規模で運用してきました。月 10,000 件超のリクエストが飛んでくる、それなりの規模です。
この経験を踏まえて、よく聞かれる問いに正面から答えます。
「結局、AI Ready なデータ基盤って何を作ればいいの？」
結論から書きます。
AI Ready なデータ基盤は、2 軸で構成される。
- 軸 1：ビジネスドメインごとに、いろんなパターンの分析要求に耐えうる粒度の整備されたテーブル群
- 軸 2：データとビジネスをつなぐコンテキスト&ハーネスエンジニアリング
この 2 軸を片方だけ作っても AI は機能しません。両方揃って初めて AI Ready になる。
業界の今 — AI が SQL を書く時代は、もう来ている
2025-2026 にかけて、自然言語 → SQL の自動生成は実用ラインに乗りました。
- Snowflake Intelligence — Snowflake 標準で自然言語分析
- Claude Agent SDK — 国内事業会社で「Ask 〇〇」系の運用が始まっている
- Cursor / Claude Code / Codex — エンジニア側の SQL 補助は当たり前
- dbt + LLM — スタースキーマで SQL 自動生成は現実解
「AI が SQL を書ける」は仮説ではなく、もう現実です。 ここを否定すると 1 年遅れる。
問題はその先です。
500 名に開放したら、SQL の精度では勝負にならなかった
LLM の SQL 力は十分です。 でも 500 名に投げてみると、実際のリクエストは違う形で飛んできます。
- 「先月の応募率が下がった理由は？」
- 「特定セグメントの LTV ってどう動いてる？」
- 「このキャンペーンって ROI 出てる？」
SQL は書ける。でも「応募率」が、どのテーブルのどのカラムをどう集計したものか、AI には判断できない。
組織内で「応募率」の定義が 5 つ並走していて、文脈で何を指しているか変わる。 データの粒度もバラバラで、毎回ゼロから集計せざるを得ない。
結果として、同じ問いに対して回答が毎回ブレる。最悪、必要なデータがそもそも揃っておらず、答えが出せない。
これは LLM の SQL 力の問題ではなく、データ基盤がそもそも AI Ready になっていない問題です。
ブレる回答や「答えが出せません」を返した瞬間、信用は崩れる。誰も使わなくなる。
これが 500 名規模で運用して見えた現実です。
軸 1 — 分析要求に耐えうる粒度のベーステーブル群
1 つ目の軸は、ドメインごとに、想定される多様な分析リクエストに対応できる粒度で整備されたベーステーブル群です。
組織で起きていることは、こういう風景。
- マートが施策ごとに乱立している
- 「応募率」の SQL を毎回ゼロから書いている
- 同じ集計を 3 つの部署が別々に作っている
- Shopify / GA4 / 業務システム / Excel で粒度がバラバラ
これを「ビジネスドメインごとに、多様な分析パターンに耐える粒度」で整備して、ベーステーブル群として一元化します。
具体的に作るもの:
- ドメインごとのベーステーブル — ユーザー単位、案件単位、月次単位など、ドメインで頻出する分析粒度に正規化
- 多様な分析リクエストへの耐性 — 「セグメント別」「期間別」「コホート別」等の派生集計が、ベーステーブルから再現できる構造
- 一貫した命名・分類規則 — 誰が見ても同じ意味で使える状態
- 散在データの DWH 統合 — Shopify / GA4 / 業務システム を 1 つの DWH に
これを作っておくと、AI は「毎回ゼロから集計する」のではなく「ベーステーブルを使い回す」ことになります。 SQL 生成の精度・速度・コスト全部が一気に安定する。
軸 2 — データとビジネスをつなぐコンテキスト&ハーネスエンジニアリング
2 つ目の軸は、データとビジネスの橋渡しを、エンジニアリング対象として扱うこと。
データの粒度が揃っても、AI がビジネスの文脈を理解できないと答えはズレます。
- 「応募率」のビジネス上の意味
- 「特定キャンペーンは LTV 計算から除く」のような暗黙ルール
- 「このマートは 2023 年以前のデータが歪んでいる」のような注意点
これらは個人の頭にあって、AI には見えない。ベテランしか正しい答えに辿り着けない状態です。
これを「AI が読める形」に体系化するのが軸 2。 ここをエンジニアリング対象として扱えるかどうかが、AI Ready の成否を分けます。
具体的に作るもの:
- ビジネスオントロジー — 「応募」「LTV」「セグメント」等のビジネス概念を階層化し、上位概念と下位概念、同義語と類義語、派生関係を明示。AI が概念の構造を理解できる形に外在化する
- ナレッジグラフ — 顧客 / 案件 / キャンペーン / 取引などのエンティティと、それらのリレーション（参加・帰属・派生）をグラフ構造で表現。AI は質問から関連エンティティをグラフ探索して、必要なテーブルとカラムに到達できる
- 業務ルール辞書 — 「特定キャンペーンは LTV 計算から除く」「2023 年以前のデータは別計算」等の暗黙ルールを構造化記述。オーナーを 1 人に紐付けて変更履歴も保持
- 分析パターンのお手本集（Golden Queries） — 主要分析パターンを SQL テンプレートとして登録、AI はお手本を参照してテンプレ + パラメータ埋めの構造で組み立てる
- 評価ハーネス — 過去の質問・SQL・回答の履歴を保持し、リグレッションテストで精度劣化を即時検出。LLM のバージョン更新やデータ変更に対する継続検証
- コンテキスト管理 — 過去の対話履歴、ユーザーごとの権限、組織固有の前提条件を AI が参照できる形に集約
これらを単発のドキュメントではなく、バージョン管理・自動検証・継続更新が可能なエンジニアリング資産として扱う。これが「コンテキスト&ハーネスエンジニアリング」の本義です。
ここまで作って初めて、AI は「お手本のある状態」で、ビジネス文脈を踏まえた SQL を組み立てる。 完全な自由生成ではなく、構造化された参照と検証のループに乗ります。
追加ガードレール — 信頼度と説明可能性
2 軸を作っても、AI は確率的なので 100% は無理。だからガードレールが要ります。
- 回答に 信頼度スコアを付与（90% 以上 / 70-90% / 70% 未満で表示を変える）
- 実行 SQL を引用 — どのクエリで答えたか可視化
- 参照テーブルを引用 — どのデータを使ったか可視化
- 計算前提を引用 — 期間・除外条件などの前提を明示
ユーザーが「この答えは信じていいか」を判断できる材料を全部出す。 信頼度が低い回答は、即座にエスカレーションする。
これで「AI が間違えても、組織は壊れない」状態になります。
実装の落とし穴 5 つ
500 名規模で 1 年運用してハマった代表的な落とし穴を共有します。
- メタデータ（軸 2）だけ整備して、ベーステーブル（軸 1）が乱立したまま → SQL 生成は安定しても粒度がバラバラで精度が出ない
- ベーステーブル（軸 1）は綺麗だがビジネス文脈（軸 2）が足りない → AI が「正解」を参照できず精度がブレる
- オーナー不在のビジネス用語を放置 → 「応募率」が誰のものでもなく定義 5 個並走
- お手本集を作る前に AI に自由 SQL を書かせた → 精度のばらつきで信用喪失
- ハーネス・信頼度スコアなしで回答を返した → 精度劣化や間違いが組織に伝播してから発覚
まとめ
AI Ready なデータ基盤は 2 軸 + ガードレール:
- 軸 1：ビジネスドメインごとにいろんなパターンの分析要求に耐えうる粒度の整備されたテーブル群
- 軸 2：データとビジネスをつなぐコンテキスト&ハーネスエンジニアリング
- ガードレール：信頼度と説明可能性
片方だけだと AI は機能しません。両方揃って初めて AI が業務に貢献する。