AIデータ分析は、方式選びで成否が決まる
「AIでデータ分析をしたい」と言っても、実際には少なくとも4つの方式があります。 CSVを会話画面へ渡す分析、社内文書を検索するRAG、業務質問をSQLへ変換するText-to-SQL、 将来値や確率を推定する予測モデルです。
これらは代替関係ではありません。入力データ、答えられる問い、必要な評価、事故の起き方が違います。 方式を決めずに製品比較から始めると、単発のファイル分析にリアルタイム性を求めたり、 RAGに売上集計をさせたりして、要件と技術がずれます。
この記事では、AI分析エージェントの製品機能ではなく、自社の問いに合う方式を選び、安全に評価して導入する手順を整理します。 Text-to-SQL型のエージェントそのものを知りたい場合は、AI分析エージェントとChatGPTの違いを参照してください。
4方式の違いと使い分け
| 方式 | 向く問い | 主な入力 | 強み | 主な限界 |
|---|---|---|---|---|
| ファイル分析 | このCSVの傾向、外れ値、集計を知りたい | CSV、Excel、PDFなどの単発ファイル | 準備が少なく探索を始めやすい | 更新・再現性・権限管理を手作業に依存しやすい |
| RAG | 規程、議事録、仕様書の根拠を探したい | 文章、FAQ、ナレッジベース | 関連文書を検索し、出典付きで回答できる | 数値の集計・JOIN・予測には向かない |
| Text-to-SQL | 先月の売上や顧客別LTVを切り口を変えて知りたい | DWHの構造化データと業務定義 | 最新データへ自然言語で反復的に質問できる | 曖昧な語彙、複雑な結合、権限漏れが誤答につながる |
| 予測モデル | 需要、解約確率、将来売上を推定したい | 履歴データ、説明変数、正解ラベル | 将来や未観測の結果を確率・予測値で扱える | 学習データの偏り、ドリフト、因果との混同に注意が必要 |
迷ったときの選び方
- 一度だけ調べるならファイル分析
- 文章の根拠を探すならRAG
- 最新の表データを集計するならText-to-SQL
- 将来や確率を推定するなら予測モデル
実務では組み合わせもあります。たとえばText-to-SQLで売上を集計し、RAGでキャンペーン議事録を検索して、 両方を根拠としてレポートを作れます。ただし、最初の実証では方式を1つに絞った方が、失敗原因を判別できます。
導入前に要件を定義する
「分析工数を減らす」のような抽象目標だけでは評価できません。対象となる意思決定、利用者、入力、出力、 許容できない誤りを1枚にまとめます。
| 要件 | 確認する質問 | 成果物 |
|---|---|---|
| 意思決定 | 回答を見て、誰が何を変えるのか | 利用シナリオと非対象範囲 |
| 質問 | 頻出質問と難しい例外は何か | 実質問を使った評価セット |
| 鮮度 | 日次、月次、リアルタイムのどれが必要か | 更新頻度と締め時刻 |
| 精度 | 誤答時に止める判断と、人が確認する判断は何か | 合格条件と人手確認ルール |
| 根拠 | 引用文書、SQL、参照表のどれを表示するか | 回答フォーマット |
| 権限 | 誰がどの行・列・文書を見られるか | ロール別アクセス表 |
問いを「経営会議の月次サマリー」のように広く取りすぎず、 「商品カテゴリ別の売上差分を、承認済み定義で説明する」のように、評価できる単位へ落とします。
データと業務定義の準備
AIは、接続したデータに存在しない意味を自動で補完できません。「アクティブ顧客」「売上」「解約」の定義が 部署ごとに違えば、モデルを替えても回答は安定しません。
方式共通で必要な準備
- データのオーナー、更新頻度、品質責任を決める
- 個人情報・機密情報・公開情報を分類する
- 正解として使う一次データと、参考情報を区別する
- 質問、入力、出力、利用者フィードバックを監査可能にする
方式ごとに追加する準備
- ファイル分析：列説明、単位、欠損、抽出日時、匿名化方針
- RAG：文書版、公開範囲、分割方法、失効日、引用元URL
- Text-to-SQL：テーブル粒度、結合キー、業務語彙、承認済みSQL、クエリ上限
- 予測：予測時点、ラベル、学習期間、データ分割、再学習条件
AIが再利用できるデータ基盤の全体像はAI Readyなデータ基盤が必要な理由、業務語彙と物理データを結ぶ方法は統合オントロジーの設計で解説しています。
セキュリティと権限設計
AI分析では、モデルの賢さより先に「何を渡し、誰に返すか」を決めます。 NISTのAI Risk Management Frameworkも、設計・開発・導入・利用・評価のライフサイクル全体で 信頼性とリスクを扱う考え方を示しています。
最低限のガードレール
- データ最小化：質問に不要な個人情報・自由記述・秘密列をモデルへ渡さない
- 最小権限：利用者のロールをDWHや文書ストアまで引き継ぎ、共通の強い権限で代行しない
- 読み取り専用：Text-to-SQLは参照用アカウントを使い、書込・削除・DDLを許可しない
- 行・列の制御：人事、顧客、財務などの機密領域はビューやポリシーで制限する
- 実行前検査：対象テーブル、スキャン量、SQL種別、個人情報列を確認する
- 監査ログ：質問、取得データ、SQL、モデル出力、承認・却下を追跡できるようにする
- 保持と削除：入力・出力・埋め込み・ログの保存期間と削除手順を契約前に確認する
方式別の評価方法
「回答が自然だった」では本番品質を判断できません。実際の質問と正解を固定し、方式に合う指標で評価します。
| 方式 | 正解データ | 主な評価観点 | 失敗時に確認する場所 |
|---|---|---|---|
| ファイル分析 | 人が検算した集計・グラフ | 数値一致、欠損処理、再現性 | 列型、単位、前処理、計算コード |
| RAG | 質問と正しい文書・該当箇所 | 検索到達、引用一致、根拠外の断定 | 文書分割、メタデータ、検索、生成 |
| Text-to-SQL | 質問、承認済みSQL、期待結果 | 実行可否、結果一致、権限、コスト | 語彙、結合、フィルタ、SQL生成 |
| 予測モデル | 時間で分離した検証データ | 業務損失に合う誤差、校正、ドリフト | ラベル、特徴量、分割、母集団変化 |
評価セットの作り方
- 実際の利用者から、頻出・重要・失敗しやすい質問を集める
- 質問ごとに正解、根拠、許容範囲、禁止される回答を定義する
- 開発で参照する例と、最終評価にだけ使う例を分ける
- モデル、プロンプト、データ定義を変えるたびに回帰評価する
- 本番では不正解だけでなく、未回答・低信頼・人への引継ぎも記録する
Snowflake Cortex Analystの公式評価も、自然言語の質問と検証済みSQLを正解として、 生成SQLの結果、回帰、レイテンシを追う方式を採用しています。 Text-to-SQLではSQL文字列の一致だけでなく、実行結果が正しいかを確認することが重要です。
導入を7段階で進める
- 意思決定を1つ選ぶ：利用頻度があり、正解を検証でき、誤答時の影響を制御できる業務から始める
- 方式を選ぶ：ファイル、RAG、Text-to-SQL、予測のどれが問いに合うか決める
- データ境界を決める：正本、対象期間、更新、機密区分、権限を合意する
- 評価セットを先に作る：実装前に質問と正解を固定し、合格条件を決める
- 限定利用で実証する：少数の利用者と対象データで、ログを取りながら使う
- 人手確認を残して広げる：低信頼回答、重大判断、未知の質問は人へ戻す
- 運用へ移す：品質、利用率、コスト、権限、データドリフトを定期的に見直す
基盤の構成を先に整理したい場合は、データ基盤の組み方ガイドを参照してください。
小さな実証の設計例
例として「営業責任者が、前月の商談化率をチャネル別に確認する」Text-to-SQL実証を考えます。 製品名ではなく、検証可能な境界から設計します。
対象
- 利用者：営業責任者とデータ定義のオーナー
- データ：承認済みの商談・流入チャネルビューのみ
- 質問：月次、チャネル別、前月比較に限定
- 出力：数値、定義、期間、実行SQL、参照ビュー、注意事項
ガードレール
- 読み取り専用ロールと許可リスト方式のビュー
- 個人名・メールアドレスを出力しない
- 期間未指定なら確認を返し、勝手に補わない
- クエリ上限を超える場合は実行せず、集計粒度の変更を求める
合格条件
- 承認済み質問で期待結果と一致する
- 禁止列・禁止テーブルへアクセスしない
- 定義が曖昧な質問は、推測せず確認を返す
- 不正解の原因を、データ・語彙・検索・SQL・生成のどこかへ分類できる
この範囲で安定してから、日次更新、追加指標、Slack連携、定期配信へ広げます。 最初から全社・全データ・全質問を対象にすると、精度と権限のどちらが原因か判断できません。
よくある失敗
- RAGに集計をさせる — 文書検索と構造化データの計算を分け、数値はSQLや分析コードで算出します。
- デモの数問だけで精度を判断する — 頻出、例外、権限違反、曖昧質問を含む評価セットを先に作ります。
- 高性能モデルへの変更だけで誤答を直す — 語彙、データ粒度、検索、権限、正解SQLのどこが原因か分解します。
- 予測を因果とみなす — 解約確率が高い特徴は、施策で解約を減らせる原因とは限りません。介入効果は別に検証します。
- ログを残さず全社公開する — 誤答、権限、費用、利用状況を改善できなくなります。限定公開から始めます。
- 回答率だけを追う — 危険な問いに答えないことも品質です。正答、未回答、確認、人への引継ぎを分けます。
Text-to-SQLの設計層をどこまで作るかは、セマンティックレイヤーが不要になる条件も参考になります。
参考にした公式一次情報
- OpenAI API: File search — アップロード済みファイルを意味検索・キーワード検索する仕組み
- OpenAI API: Retrieval — ベクトルストア、検索、属性フィルタを使うRAGの構成
- OpenAI API: Working with evals — テストデータと評価基準を使った継続評価
- NIST: AI Risk Management Framework — AIの設計・導入・利用・評価を通じたリスク管理
- Snowflake Documentation: Cortex Analyst evaluations — 検証済み質問・SQLを使ったText-to-SQLの正確性と回帰評価
- Google Cloud: Introduction to ML in BigQuery — SQLによる予測、分類、時系列、異常検知などの公式概要
まとめ
- 単発ファイル、RAG、Text-to-SQL、予測は、答える問いと評価方法が違う
- 製品比較の前に、意思決定、利用者、鮮度、精度、根拠、権限を定義する
- 個人情報の最小化、最小権限、読み取り専用、監査ログを先に設計する
- 実質問と正解を固定し、方式別の評価と回帰テストを行う
- 1つの意思決定・限定データ・少数利用者から始め、運用ログを見て広げる