「AI 分析エージェント」とは何で、何が新しいのか
ここ 1〜2 年で「AI エージェント」という言葉が一気に広まりました。 ただ、業務にどう効くのか、ChatGPT を使うのと何が違うのか、明確な説明は少ないです。
結論から書くと、AI 分析エージェントは「自社のデータを使って、業務質問に自分で SQL を組み立てて、答える AI」です。 ユーザーが業務の言葉でそのまま質問でき、AI が裏で SQL を実行し、グラフと数値で返してくる。 これが普通になったのが 2025-2026 年です。
この記事では、AI 分析エージェントが「何で、何ができて、何ができないか」を、 直近 1 年の 500 名 / 月 10,000 件超の実運用ベースで整理します。
ChatGPT に貼るのとは、何が違うのか
ChatGPT に「うちの先月の応募率を分析して」と書いても、答えは出ません。 ChatGPT はあなたの会社のデータを知らないからです。 一般論として「応募率は分母を◯◯にして……」と返ってくるだけ。
AI 分析エージェントは違います。
- 自社の DWH（データの倉庫）に直接接続している。 BigQuery / Snowflake / Redshift などにユーザー権限で接続し、SQL で生データを引ける
- 「応募率」「LTV」のような業務語彙の定義を、内部に持っている。 「応募率は応募ログの完了フラグ ÷ クリック数で、特定キャンペーンは除外」のような定義を、 事前に教えてあるので、毎回同じ計算で答えを返せる
- 業務質問を受け取ると、自分で SQL を書いて、実行して、結果を返す。 人間が SQL を書く必要がない
単発の質問だけでなく、複数の作業をつなげて自分で実行するのも特徴です。
- 「先月のデータを取って、セグメント別に分けて、グラフを作って、Slack に投稿する」
- 「2 つのチャネルの売上推移を比較して、有意差を検定して、結論を文章でまとめる」
- 「異常値が出たカテゴリを特定して、その原因を仮説立てて、関連データを引いて検証する」
これらを「人間の手作業 → AI に丸投げ」できるのが、エージェントと呼ばれる理由です。
何ができて、何ができないか
できること
- 業務質問を SQL に変換して、データを引いてくる。 「先月の LTV 高い顧客の特徴は？」「カテゴリ別売上の前年比は？」のような質問に即答
- 結果をグラフ化して Slack や Teams に投稿する。 棒グラフ、折れ線、ヒートマップを動的に生成
- CSV や HTML レポートを生成する。 ファイルとして共有可能
- 業務語彙の辞書とお手本集を参照して、定義のブレない数値を返す。 「応募率」が組織で統一定義されていれば、何度聞いても同じ答え
- 過去の質問履歴を踏まえて、深掘り質問に答える。 「Email 流入だけで再集計して」「前年同月比に変えて」のように、文脈を保持して再分析
できないこと（または苦手）
- 業務語彙が辞書化されていない組織では、回答が毎回ブレる。 これは AI の問題ではなく、データ基盤側の問題
- データ自体が存在しない問いには答えられない。 計測されていない指標は、聞いても出ない（「離脱した理由」を知りたくても、ログが取られていなければ無理）
- 「なぜそうなったか」の因果推論は、別途仮説を入れない限り限界がある。 相関は見られるが、因果は人間の解釈とドメイン知識を含めないと判定できない
- 機密性の高いデータを、権限管理なしで開放するのは危険。 ユーザー / ロール別のアクセス制御が前提
- 複雑な多段 JOIN や、500 行を超えるような複雑な SQL は精度が落ちる。 お手本集（Golden Queries）に登録された分析パターンに乗せるのが現実的
実務で使われている代表的な質問パターン
500 名規模で運用したログから、実際にユーザーが投げてくる質問を分類すると、 だいたい次の 5 パターンに収まります。
① 直近の異常検知系
- 「先月の応募率がチャネル別にどう動いた？」
- 「今週の売上が下がってる、原因は何？」
- 「リピート率が悪化している層を特定して」
② セグメント別の深掘り
- 「LTV 高い顧客の特徴を出して」
- 「離脱した顧客と継続した顧客の違いは？」
- 「カテゴリ別の購入頻度の差を見たい」
③ 効率指標の比較
- 「広告チャネル別 ROAS の前月比」
- 「ストア別 CVR の業界平均との比較」
- 「メールフロー別 RPR の改善余地」
④ 仮説検証 / 効果測定
- 「先週やったキャンペーンの効果は？」
- 「価格変更後の購入率変化を、A/B テスト形式で見せて」
- 「特定のメール送信が翌週の売上に効いてる？」
⑤ 経営層向けレポート生成
- 「今月の経営会議用に、KPI 5 つをまとめて」
- 「投資家向けに、直近の主要指標を 1 ページにまとめて」
- 「四半期サマリーを作って、Slack 投稿用に整形して」
①②③が頻度高、④⑤は経営層・分析担当の専門質問で頻度は低いが価値が高い、という分布です。
500 名 / 月 10,000 件運用してわかった現実
直近 1 年、Slack / Teams / Chatwork に常駐する AI 分析エージェントを500 名規模 / 月 10,000 件超のリクエストで運用してきました。
見えてきた現実は、「AI を入れる」ことより 「AI が答えられる準備」が大事ということでした。 AI が幻覚するパターンは、ほぼ次のどれかです。
- 業務語彙が組織内で複数並走しているので、AI が毎回違う SQL を書く。 「LTV」が 3 万円と 4.5 万円の 2 通り出てきて議論が止まる
- データの粒度が施策ごとにバラバラで、毎回ゼロから集計する羽目になり、 同じ質問なのに微妙に違う数字が返る
- 「特定キャンペーンは LTV から除く」のような暗黙ルールがどこにも書かれていない。 ベテランしか正しい答えに辿り着けないが、AI は知らずに集計する
- テスト注文や社内購入が含まれてしまう。 管理画面では除外するロジックが、生データには反映されていない
これは LLM の性能の問題ではなく、データ基盤側がAI が読める状態になっていないことが原因です。 全体像はAI Ready なデータ基盤の正体、SQL 精度の話はこちらに書きました。
本番に乗せるために必要な 4 つの準備
1 年運用して、「これがないと AI 分析エージェントは使われない」と痛感した 4 点。 順番にやらないと、いくらモデルを差し替えても精度は出ません。
① ベーステーブルの整備
ユーザー単位、案件単位、月次単位など、ドメインで頻出する分析粒度に揃えたテーブル群を整備。 施策ごとの一品マートを乱立させない。
典型的に整える粒度（EC/D2C の場合）：
- users（ユーザー属性、初回流入、累積購入、最終接触）
- orders（注文、商品、チャネル、粗利）
- sessions（流入元、滞在、コンバージョン）
- monthly_metrics（月次の売上 / 新規 / リピート）
- cohorts（獲得月 × 経過月）
整形は dbt のような SQL ベースのツールでコード化し、Git で管理します。 全体像はデータ基盤を組むときに考えることを参照してください。
② 業務語彙とルールの辞書化
「応募率」「LTV」「セグメント」などの定義と、暗黙ルールを構造化して書き出す。 オーナーを 1 人に紐付けて、変更履歴も残す。
辞書に書く項目：
- 定義（一行で言える形）
- 計算式（SQL や疑似コード）
- 使う期間（直近 24 ヶ月、など）
- オーナー（1 人）
- 除外するもの（特定キャンペーン、テスト注文、社内購入など）
- 同義語と派生関係（「応募率」⊃「チャネル別応募率」⊃「Email 応募率」）
③ お手本集（Golden Queries）と評価ハーネス
主要分析パターンを SQL のお手本として登録。 AI はゼロから書くのではなく、お手本を参照する。 パラメータ部分（期間、セグメント、チャネル）だけ埋める形にすると、精度が安定します。
評価ハーネスは、過去の質問・SQL・回答を保持して、 リグレッションテストで精度劣化を即時検出する仕組み。 LLM のバージョン更新やデータ変更で精度が落ちないかを継続的に検証します。
④ 信頼度と説明可能性のガードレール
回答に信頼度スコアを付与（90% 以上 / 70-90% / 70% 未満で表示を変える）。 実行 SQL、参照テーブル、計算前提を毎回引用する。 ユーザーが「この答えを信じていいか」を判断できる材料を、出力ごとに添える。
信頼度が低い回答は、即座に「自信がない」ことをユーザーに伝える。 そこで人が判断する。 これで「AI が間違えても、組織は壊れない」状態になります。
市場の選択肢は 3 系統
自社で AI 分析エージェントを使うなら、選択肢はおおむね 3 つに分かれます。
- ① 大手データ基盤の内蔵機能（Snowflake Cortex、Databricks Genie、Tableau Pulse、ThoughtSpot Sage など） — その基盤を既に使っている会社向け。追加投資が小さい
- ② 自然言語分析の単機能 SaaS（ThoughtSpot、Hex、Delphi、Zenlytic、Fabi.ai など） — 中〜大規模で、複数の DWH を横断したい会社向け。月額固定費が乗る
- ③ 自作（業界テンプレ + LLM + Slack ボット）— 30〜200 名規模で、業界特化の業務語彙を持ち込みたい会社向け。 月額固定費がほぼゼロ。DecisionFlow はこのパターン
詳細と選び方はSlack 常駐 AI 分析エージェントの選び方に書きました。
コスト感の現実 — LLM API は意外と安い
「AI を 500 名に開放したら、API 費用が爆発するのでは？」とよく聞かれますが、現実はそうでもないです。
1 リクエストあたりのコスト目安
Gemini 2.5 Flash や Claude Sonnet などの主要モデルだと、 1 質問 → SQL 生成 → 結果整形までで、1 リクエストあたり数円〜数十円のレンジです。
月の総コスト
月 10,000 リクエストで計算すると、 1 リクエスト 5 円 × 10,000 = 月 5 万円程度。 複雑な質問（多段 JOIN、長い文脈）が多い組織でも、月 10〜20 万円のレンジに収まります。
意外と安く見える理由
人を 1 人雇って同じ仕事（業務質問への回答）をさせると、 月 50 万〜 100 万円の人件費がかかります。 LLM API の月 5〜20 万円は、人件費の 1 / 5〜1 / 20。 1 人のアナリストが 24 時間稼働する状態を作れる、と考えれば桁違いに安い。
落とし穴 5 つ
- 「AI を入れれば全部解決」と期待する — データ基盤の整備が前提。AI は答える機械であって、整備する機械ではない
- 業務語彙の辞書を作る前に、フル開放した — 初週で「答えがバラバラ」と評価され、信用を失う。 まず 1 部門 / 5 名で限定運用、語彙を整備しながら範囲を広げる
- モデルの差し替えで精度が上がると思った — GPT-4o → Claude → Gemini を回しても、業務語彙の問題は解決しない
- SQL や参照テーブルを引用しなかった — 数字を疑った瞬間にユーザーが離れる。引用は必須
- 評価ハーネスを後回しにした — LLM 更新やデータ変更で精度が落ちても、誰も気づかない。 最初から実装する
まとめ
- AI 分析エージェントは「自社データに直接接続して、業務質問に自分で SQL を書いて答える AI」。 ChatGPT 単体とは別物
- 実務で使われる質問は 5 パターンに収束する：異常検知 / セグメント深掘り / 効率比較 / 効果測定 / レポート生成
- 選択肢は 3 系統。規模と既存スタックで自然に絞られる
- 本番に乗せるには 4 つの整備が必要：ベーステーブル / 辞書 / お手本集 / ガードレール
- LLM API のコストは、人件費の 1 / 5〜1 / 20 程度。意外と安い