結論：AIデータ分析エージェントは「分析工程を進めるAI」
「AIにデータ分析を任せる」と聞くと、ChatGPTへCSVを渡すことを想像する人もいれば、 データベースへ質問できるチャットを想像する人もいます。同じ言葉で、別の仕組みを話している状態です。
結論から書くと、AIデータ分析エージェントは、目的を受け取り、必要なデータと道具を選び、 分析・検算・説明を複数段階で進める仕組みです。 SQLを生成するText-to-SQLは重要な部品ですが、それだけでエージェントになるわけではありません。
Google CloudもAIエージェントを、目標を達成するために推論し、計画し、道具を使って行動するシステムとして説明しています。 本記事ではこの一般的な定義を、データ分析の仕事へ絞って考えます（Google Cloud「AI エージェントとは」）。
一般チャット・ファイル分析・RAG・Text-to-SQL・Agentic Analyticsとの違い
最初に、似た言葉を分けます。優劣ではなく、答えたい問いと使うデータが違います。
| 方式 | 主な入力 | 得意な問い | 止まる場所 |
|---|---|---|---|
| 未接続の一般チャット | 会話に書いた情報 | 分析方法の相談、SQLのたたき台 | 社内データを取得できない |
| ファイル分析 | CSV、Excel、PDF | このファイルの集計、可視化、外れ値確認 | 更新と再実行を人の受け渡しに依存しやすい |
| RAG | 規程、議事録、仕様書などの文章 | 根拠となる文書や該当箇所の検索 | 数値の集計や表同士の結合は主目的ではない |
| Text-to-SQL | DWHの構造化データ | 自然言語からSQLを作り、最新値を集計 | 一つの質問と回答で終わる構成も多い |
| AIデータ分析エージェント | 表、文書、定義、分析ツール | 目標から分析計画を立て、取得・検算・説明を反復 | 権限、評価、停止条件がないと安全に任せられない |
| Agentic Analytics | 分析エージェント、複数データ、業務ツール | データ取得から洞察、承認後の行動までをつなぐ | 一つの製品ではなく、分析業務全体の設計を指す |
ファイル分析では、ChatGPTがアップロードされた表を調べ、Pythonによる計算やグラフ作成を行えます。 一方で、外部データが必要ならファイルの追加か接続が必要です（OpenAI「Data analysis with ChatGPT」）。
RAGは検索と生成を組み合わせ、関連文書を根拠として回答する方式です（Google Cloud「What is Retrieval-Augmented Generation (RAG)?」）。 売上を集計するText-to-SQLとは役割が違います。RAGの仕組みはRAG入門でも詳しく解説しています。
AIデータ分析エージェントが「分析を担当する実行主体」なのに対し、Agentic Analyticsは、 一つまたは複数のエージェントを使ってデータ取得から洞察、承認後の行動までをつなぐ、より広い業務設計です。 両者は同義で使われることもありますが、本記事では実行主体と全体設計を分けて扱います。
ChatGPTとの違いは、製品名ではなく接続と仕事の範囲
「ChatGPTか、AIエージェントか」という二択は、今は正確ではありません。 未接続のチャットは社内データを知りませんが、ChatGPTにはファイル分析や、外部サービスへ接続するAppsがあります。 Appsは接続先の情報を検索・参照し、構成によっては承認付きの操作も扱います（OpenAI「Apps in ChatGPT」）。
つまり違いは画面ではなく、次の三点です。
- 接続：対象データへ、利用者の権限を保ったままアクセスできるか
- 意味：「売上」「新規顧客」の定義や除外条件を共有できるか
- 仕事の範囲：一回答えるだけか、検算や深掘りまで続けるか
ChatGPT上にこの三点を組み込めば、ChatGPTを入口にした分析エージェントも作れます。 逆に、専用画面があっても単発のSQL生成だけなら、機能としてはText-to-SQLです。
分析を進める6段階の実行ループ
エージェントは、巨大な一つのAIではありません。実際には、短い工程を順番に回します。
- 目的を確認する：対象KPI、期間、比較対象、最終的に変えたい判断を確認する
- 使えるデータを探す：権限内のテーブル、文書、指標定義から必要なものを選ぶ
- 分析計画を立てる：全体差分からチャネル、商品、顧客層へ分解する順番を決める
- 道具を実行する：SQL、Python、文書検索などを使い分ける
- 結果を検算する：期間、重複、欠損、集計粒度、既知の合計値との一致を確かめる
- 根拠と限界を説明する：使ったデータ、SQL、前提、断定できない点を示す
Snowflake Cortex Analystの公式仕様でも、自然言語の質問から、意味を定義したモデルを使ってSQLを生成する構成が示されています。 曖昧な質問ではSQLを出さず、候補を返す場合がある点も重要です（Snowflake「Cortex Analyst REST API」）。分からないときに確認を返すことも、実行ループの一部です。
売上低下を調べる具体例
たとえば「先月の売上が落ちた理由を調べて」と依頼します。 人間でも、この一文だけでは分析を始められません。何と比べるのか、売上は返品後か、どの事業を含むのかが未確定だからです。
| 段階 | エージェントの処理 | 人が確認できるもの |
|---|---|---|
| 条件確認 | 前月比か前年同月比か、返品後売上かを確認 | 採用したKPI定義と比較期間 |
| 全体検算 | 会計上の月次合計と分析用テーブルの合計を照合 | 参照表、更新日時、差分 |
| 分解 | 注文数、客単価、返品を分け、変化の大きい項目を特定 | 実行SQLと集計結果 |
| 深掘り | 注文数低下をチャネル、商品、新規・既存顧客へ分解 | 次の分析を選んだ理由 |
| 説明 | 寄与の大きい差分と、追加確認が必要な仮説を分けて提示 | 事実、仮説、不確実性 |
ここで大事なのは、売上と広告停止が同時に起きたからといって、因果関係まで断定しないことです。 エージェントは「差分への寄与が大きい」ところまでは示せますが、「広告停止が原因」と言うには実験設計や追加検証が必要です。
構造化データと議事録などを横断し、途中結果に応じて処理を変える構成は、Google CloudのAgentic Analyticsアーキテクチャでも示されています。
できること・任せない方がよいこと
向いている仕事
- 定義済みKPIを、期間や切り口を変えて集計する
- 異常を見つけた後、決められた順番で要因候補を分解する
- 同じ月次分析を再実行し、根拠と一緒に下書きを作る
- SQL、参照表、前提を残し、人が検算できる形で共有する
そのまま任せない方がよい仕事
- 正解や検算方法がなく、評価できない問い
- 計測していない顧客心理や、データだけでは判定できない因果関係
- 採用、与信、価格変更など、人や金額へ重大な影響を与える自動決定
- 書き込み、削除、外部送信を、人の承認なしで行う操作
NISTのAI Risk Management Frameworkも、AIの信頼性とリスクを設計、利用、評価のライフサイクル全体で扱う考え方を示しています（NIST「AI Risk Management Framework」）。分析結果の影響が大きいほど、人の確認地点を増やします。
方式を選ぶための判断表
「エージェントを導入する」から始めると、必要以上に複雑になります。 先に問いを決めると、もっと単純な方式で足りることがあります。
| やりたいこと | 最初の選択 | エージェントへ広げる条件 |
|---|---|---|
| 一度だけCSVを集計したい | ファイル分析 | 同じ分析を更新データで繰り返す |
| 規程や議事録の根拠を探したい | RAG | 文書と数値を合わせて複数工程を進める |
| 最新の売上を自然言語で集計したい | Text-to-SQL | 結果に応じて追加の切り口を自動選択する |
| 固定KPIを毎朝確認したい | ダッシュボード・定期通知 | 例外発生時だけ原因候補を深掘りする |
| 探索、検算、説明をまとめて進めたい | AIデータ分析エージェント | 最初から対象。ただし提案までに限定する |
AIデータ分析全体の方式選定はAIデータ分析の4方式と導入手順、複数工程を自律的に進める範囲はエージェンティックアナリティクス入門で分けて解説しています。
向いている会社・まだ向いていない会社
向いている会社
- 同じ種類の分析依頼が毎週または毎月発生する
- DWHに必要な履歴があり、KPIの定義を説明できる
- 正しいSQLや期待結果を用意し、回答を評価できる
- 最初は読み取りと提案までに限定できる
まだ向いていない会社
- 元データがスプレッドシートごとに違い、合計値も一致しない
- 「売上」「顧客」の定義が部署ごとに違い、決める担当者もいない
- 何をもって正解とするか決めず、自然な文章だけで品質を判断する
- 最初から更新・送信まで完全自動化しようとしている
ただし、小規模だから向かないわけではありません。質問が一つに絞れ、元データと正解を確認できるなら、小さく試せます。 反対に大企業でも、定義と権限が整理されていなければ本番化は難しくなります。
最初の導入は一つの質問から
最初から「何でも聞ける分析AI」を作らないことです。過去に人が答えた質問を一つ選びます。
- 質問、利用者、回答後の判断を一文で決める
- 正解SQLと期待する結果を保存する
- 読み取り可能なテーブルと列を限定する
- 同じ質問を条件を変えて複数回実行する
- 結果、SQL、前提を人が確認して合否を付ける
Text-to-SQLの製品側でも、自然言語の質問と期待SQLを組にした評価が採用されています。 Snowflakeの評価機能は、生成SQLの結果をVerified Queryと比較し、正確性と回帰を確認します（Snowflake「Cortex Analyst evaluations」）。
評価セットの作り方はAIエージェント評価入門、データ側の準備状況はAI Readyデータ診断チェックリストを使うと確認できます。Slackへ置く場合のUXと製品選びはSlack AI分析エージェントの選び方に分けました。
参考文献
本記事は、次の公式資料を2026年8月7日に確認し、各方式の定義、機能範囲、評価・統制の考え方を独自に整理しました。
- Google Cloud「AI エージェントとは」 （アクセス日: 2026-08-07）— 目標、推論、計画、ツール利用を含む一般的なエージェント定義
- OpenAI「Data analysis with ChatGPT」 （アクセス日: 2026-08-07）— ファイル分析、Python実行、グラフ作成と制約
- OpenAI「Apps in ChatGPT」 （アクセス日: 2026-08-07）— 外部データの検索・参照と承認付き操作
- Google Cloud「What is Retrieval-Augmented Generation (RAG)?」 （アクセス日: 2026-08-07）— 検索と生成を組み合わせるRAGの定義
- Snowflake「Cortex Analyst REST API」 （アクセス日: 2026-08-07）— 自然言語、セマンティックモデル、SQL生成の入出力
- Google Cloud「Implement agentic analytics workflows for distributed data」 （アクセス日: 2026-08-07）— 構造化・非構造化データを横断するエージェント型分析
- Snowflake「Cortex Analyst evaluations」 （アクセス日: 2026-08-07）— Verified Queryを使った正確性と回帰の評価
- NIST「AI Risk Management Framework」 （アクセス日: 2026-08-07）— AIシステムの設計・利用・評価を通じたリスク管理
まとめ
- AIデータ分析エージェントは、目的から分析・検算・説明を複数段階で進める仕組み
- ファイル分析、RAG、Text-to-SQLは競合ではなく、異なるデータと問いを担当する部品
- ChatGPTも接続とツールを持てば入口になれるため、製品名だけでは区別できない
- 固定集計ならダッシュボード、単発CSVならファイル分析で十分な場合がある
- 最初は一つの質問、読み取り専用、正解SQL、人の確認から始める
導入判断で最初に確認するのは、モデル名ではありません。繰り返し発生する質問、使えるデータ、正解を確認する方法がそろっているかです。 ここがそろって初めて、エージェント化する意味が出ます。