なぜ「Slack で分析を頼む」が定着しているのか
BI ツール（Tableau、Power BI、Looker など）はこれだけ浸透したのに、 経営会議でダッシュボードを開く役員はあまりいない。これは多くの会社で見られる風景です。
理由はシンプルで、「ダッシュボードを毎日開きに行く習慣」が、ほとんどのユーザーにないから。 BI の全社浸透率は、業界調査でずっと 30〜40% 程度に頭打ちになっています。 ツールを買っても、ユーザーが触りに来ない。これが BI の構造的な限界です。
一方、同じ役員が Slack は 1 日に何十回も開きます。 メンションが来れば反応し、スレッドで議論し、ファイルを共有する。業務の中心が Slack に移っているのが現状です。
だったら、業務質問を Slack でそのまま投げて、AI が即答する方が現実に乗る。 これが「Slack 常駐 AI 分析エージェント」が一気に広まった理由です。 Snowflake、Databricks、ThoughtSpot、Tableau のような大手も、 ここ 1-2 年で一斉に Slack 対応を入れました。
何が起きているのか — Slack から AI に質問する流れ
ユーザー側からは、こんな体験になります。
- Slack でボットをメンション：「@DecisionFlow 先月の応募率がチャネル別にどう動いた？」
- ボットが「分析中」と返事し、進捗を 1 行更新で見せる （「🔍 SQL を生成中...」→「⚡ クエリ実行中...」→「📊 グラフ生成中...」）
- 30 秒〜 1 分で、結果がスレッドに投稿される。グラフ画像 + 数値 + 使った SQL + 参照テーブル + 計算前提が全部揃う
- 「期待どおり / データ不足 / 集計違う」など、フィードバックボタンを押す
- 必要なら、追加質問でドリルダウン。「Email 流入だけで再集計して」「前年同月比で見せて」のように、自然言語で深掘れる
内部で起きていることは、こんな流れです。
- ボットが Slack の発言を受信する（Slack Events API）
- 業務質問を AI（Gemini / Claude / GPT 等）に渡す
- AI が業務語彙の辞書とお手本集を参照して、SQL を組み立てる
- DWH（BigQuery / Snowflake 等）に対して SQL を実行
- 結果を整形してグラフ化（Playwright で HTML を PNG にレンダリングするのが標準パターン）
- グラフ + 引用 + 信頼度スコアを Slack に投稿
ユーザー側からは「業務質問を投げたら、答えが帰ってくる」だけ。 ダッシュボードを開きに行く必要はないし、SQL を書く必要もない。 これが、データ専任ゼロ〜薄い組織でも「データドリブン」を成立させる、現実的な道です。
選択肢は 3 系統 — 既製品 / 単機能 SaaS / 自作
Slack から呼べる AI 分析エージェントは、ざっくり 3 つの系統に分かれます。 それぞれ向き不向きがあるので、規模と既存スタックで選びます。
①大手データ基盤の内蔵機能
代表：Snowflake Cortex Analyst、Databricks Genie、Tableau Pulse、ThoughtSpot Sage。 すでに使っているデータ基盤にビルトインされている AI 機能を、Slack 連携で呼び出すパターン。
メリット
- 既存基盤との接続作業がほぼ不要。1〜2 日で動く
- データ権限管理が既存のものをそのまま使える
- ベンダーが業務語彙レイヤー（Semantic Model、Verified Query Repository など）を提供
デメリット
- その基盤を使っていることが大前提。別の DWH に分散しているデータは扱えない
- 業界特化（EC、HR、メディアなど）の業務語彙テンプレは弱い。自社で全部書く必要がある
- 機能の自由度が低い。出力フォーマットや UX を細かく変えられない
向いている会社
すでに Snowflake / Databricks / Looker を全社統一で使っている 中〜大規模組織。 データ基盤は揃っていて、ユーザー数が多くて「同じ基盤の上で AI を有効化したい」場合に最適。
②自然言語分析の単機能 SaaS
代表：ThoughtSpot、Hex、Delphi、Zenlytic、Fabi.ai、Seek AI。 Slack 連携 + 自然言語分析に特化した、独立系の SaaS。
メリット
- 複数の DWH（BigQuery + Snowflake + Postgres など）を横断して分析できる
- 業務語彙レイヤー（Semantic Layer）を自前で持っている。組織横断で定義を統一できる
- UX が洗練されている。ボット側の機能（ダッシュボード化、共有、フィードバック）が完成している
デメリット
- 月額が固定で乗ってくる。月数十万〜数百万円のレンジ
- 業界特化の業務語彙テンプレは、自社で書き起こす必要がある
- ベンダーロックイン。乗り換えコストが高い
向いている会社
中〜大規模で、複数の DWH を横断して分析したい組織。 データチームが 2〜5 名いて、業務語彙を自分たちで整備できる体制がある場合に向く。
③自作（業界テンプレ + LLM + Slack ボット）
Google ADK、LangChain、Anthropic Claude SDK などのフレームワーク + Slack ボット SDK + 自社 DWH を組み合わせて、自分たちのデータと業務語彙に合わせたエージェントを作るやり方。
メリット
- 業界特化の業務語彙・お手本集を自由に組み込める
- UX を自社のニーズに合わせて細かく調整できる
- 月額固定費がほぼゼロ（LLM API の従量課金のみ）。月 10,000 件のリクエストでも、API 費用は数万円〜十数万円
デメリット
- 開発と運用の責任を全部自分で持つ必要がある
- 業務語彙レイヤー、お手本集、評価ハーネスを自前で作る工数がかかる
- LLM のバージョン更新、Slack API の仕様変更に追従する必要がある
向いている会社
30〜200 名規模で、データ専任ゼロ〜薄い組織。 業界特化の業務語彙（EC/D2C、HR、マッチングなど）が必要な場合や、 月額固定費を抑えたい場合に最適。 DecisionFlow はこのパターンに特化しています。
500 名で 1 年運用してわかった現実
直近 1 年、Slack / Teams / Chatwork に常駐する AI 分析エージェントを500 名規模 / 月 10,000 件超のリクエストで運用してきました。
結論を先に書くと、「ボットを Slack に置けば終わり」ではないです。 ボットを入れた後、こういう壁が次々にきます。
- 「応募率」と聞いても、組織内に定義が 5 つ並走している。 管理画面に出る応募率、レポート用の応募率、チャネル別応募率（クリック ÷ 応募）、 セッション応募率（セッション ÷ 応募）、CV 応募率（特定 CV からの応募）。 AI には文脈で何を指しているか判断できず、毎回違う SQL を組み立てる
- データの粒度が施策ごとにバラバラで、毎回ゼロから集計し直す。 キャンペーン A 用のマート、キャンペーン B 用のマート、月次レポート用のマートが乱立し、 AI は「セグメント別」「コホート別」の派生集計を毎回スクラッチする
- 暗黙ルールがどこにも書かれていない。 「特定キャンペーンは LTV から除外」「2023 年以前のデータは別計算」「テスト注文は除く」のような ルールが個人の頭にしかなく、AI は知らずに集計する
- ボットが毎回違う答えを返すと、初日で信用を失う。 朝の経営会議で 3 万円と回答、午後の同じ質問で 4.5 万円。 「このボット信用できない」が初週に確定すると、誰も使わなくなる
これは LLM の SQL 力の問題ではなく、データ基盤側が AI Ready になっていない問題です。 全体像はAI Ready なデータ基盤の正体に書きました。Text-to-SQL 精度の壁はこちら。
本番に乗せるために必要な 4 つの準備
① ベーステーブルの整備
ユーザー単位、案件単位、月次単位など、ドメインで頻出する分析粒度に整えたテーブル群を整備。 施策ごとの一品マートを乱立させず、AI が「使い回せる土台」を作る。
典型的に整える粒度：
- ユーザー単位（属性、初回流入、累積購入、最終接触日）
- 注文単位（注文ID、ユーザー、商品、チャネル、粗利）
- セッション単位（流入元、滞在、コンバージョン）
- 月次集計（売上、新規、リピート、Churn）
- コホート集計（獲得月 × 経過月）
② 業務語彙とルールの辞書化
「応募率」「LTV」「セグメント」「アクティブ顧客」「F2 転換率」のビジネス概念に、 定義とオーナーを 1 箇所に紐付ける。同義語・派生関係も明示する。
暗黙ルールも必ず書き出す。
- 「特定キャンペーンは LTV 計算から除外」（理由：ノベルティ配布だから）
- 「2023 年以前のデータは別計算」（理由：トラッキング仕様変更）
- 「テスト注文は除く」（特定メールドメインで判定）
- 「法人案件は別ロジック」（取引額 100 万円超を法人と扱う）
③ お手本集（Golden Queries）と評価ハーネス
主要分析パターンを SQL のお手本として登録。 「先月の LTV 高い顧客の特徴」「カテゴリ別売上の前年比」「チャネル別 ROAS の前月比」のような頻出パターンを、 パラメータ化された SQL として保管する。 AI はゼロから書くのではなく、お手本をベースに組み立てる。
評価ハーネスは、過去の質問・SQL・回答を保持して、 リグレッションテストで精度劣化を即時検出する仕組み。 LLM のバージョンを上げたとき、データの集計ロジックを変えたとき、 「同じ質問に対する回答が悪化していないか」を毎回チェックします。
④ 信頼度と説明可能性のガードレール
回答に信頼度スコアを付与（90% 以上 / 70-90% / 70% 未満で表示を変える）。 実行 SQL、参照テーブル、計算前提を毎回引用する。 これがないと、AI が間違えた瞬間に組織の意思決定が壊れます。
ボットの UX で必ず実装すべき 5 要素
1 年運用して、「ここを外すとユーザー離れが起きる」と痛感した UX 要素を 5 つ。
① 進捗の 1 行更新
回答までに 30 秒〜 1 分かかる。 黙って待たせるとユーザーは離脱する。 「🔍 SQL を生成中...」「⚡ クエリ実行中...」「📊 グラフ生成中...」のように、 1 つのメッセージを書き換える形で進捗を見せる。
② グラフ画像での即時表示
数値の表より、グラフ画像の方が圧倒的に「見て理解される」。 HTML レポートを Playwright で PNG にして Slack に添付するのが標準。 スレッド内で全部完結させる（外部リンクに飛ばさない）。
③ 実行 SQL と参照テーブルの引用
「数字怪しい」と思ったときに、ユーザーが自分で確認できる材料を全部出す。 ・使った SQL（Slack のコードブロックで添付） ・参照したテーブル名 ・計算前提（期間、除外条件、グループ化）
④ フィードバックボタン
回答ごとに、ユーザーが 1 クリックで反応できるボタンを置く。 「期待どおり」「集計が違う」「データが足りない」「依頼内容を取り違えている」など、 数種類のラベルを用意して、押したログを残す。 このフィードバックを記録しないと、何が刺さって何が外れたか分からなくなり、改善が止まる。
⑤ スレッド内ドリルダウン
一発で答えが出るとは限らない。「Email 流入だけで再集計」「前年同月比で見せて」のように、 スレッド内で追加質問できる UX が必須。 会話履歴を文脈として保持して、深掘り質問に答えられる構造にする。
権限管理と監査 — 機密データを開放するときの最低ライン
AI 分析エージェントは、データ基盤の SQL を直接実行する。 つまりデータに対する強い権限を持つので、ガバナンス設計が必須です。
最低限実装すべき 3 つ
- ユーザーごとの実行権限制御： Slack ユーザーと DWH の権限ロールを紐付ける。 役員と一般社員で見られるテーブルを分ける、PII（個人情報）を含むテーブルへのアクセスを限定する
- 監査ログ： 「誰が、いつ、どの質問をして、どの SQL を実行したか」を全記録する。 事故調査と、利用統計の両方に使う
- クエリコスト上限： BigQuery / Snowflake のような従量課金 DWH では、 悪意のないユーザーでも「全件スキャン」するクエリで月の請求が跳ねる事故がある。 実行前にバイト数推定（dry_run）を回し、上限を超える場合は確認ダイアログを出す
落とし穴 5 つ
- ボットを入れて即フル開放した — 業務語彙の整備前に開放すると、初週で信用喪失。 まずは 1 部門 / 5 名で限定運用し、業務語彙を整備しながら範囲を広げる
- 「全社開放」を最初の目標にした — 1 部門で精度を作ってから広げる。 初期は「マーケ部 5 名で 1 ヶ月」「営業部 10 名で 2 ヶ月」のように段階的に
- ダッシュボードと並行で「両方どうぞ」とした — ユーザーは結局見やすい方しか使わない。Slack ボットに振り切る決断が必要
- フィードバック収集を後回し — 何が刺さって何が外れたか分からなくなり、改善が止まる。 初日からフィードバックボタンを実装する
- SQL や参照テーブルを引用しなかった — 数字を疑った瞬間にユーザーが離れる。 「ボットが正しいか」をユーザーが自分で検証できる材料は、出力ごとに必ず添える
どう選ぶか — 規模と既存スタックで決まる
- すでに Snowflake / Databricks / Looker を全社統一で使っている → ① 内蔵機能から試す。追加コストが小さい
- 複数 DWH を横断したい中〜大規模組織 → ② 単機能 SaaS が候補。月額数十万〜数百万円
- 30〜200 名規模、データ専任薄い、業界テンプレを使いたい → ③ 自作（業界テンプレ + LLM + Slack ボット）が現実解
いずれの選択肢でも、ボット単体で完結することはありません。 上に書いた 4 つ（ベーステーブル / 辞書 / お手本集 / ガードレール）の整備が、 選んだ後の本番運用の質を決めます。
まとめ
- BI ダッシュボードは「開く習慣がない人」には届かない。 Slack に常駐させる AI 分析エージェントは、その問題に対する現実的な答え
- 選択肢は 3 系統（大手内蔵 / 単機能 SaaS / 自作）。 規模と既存スタックで自然に絞られる
- ボットを Slack に置くだけでは機能しない。 ベーステーブル / 業務語彙の辞書 / お手本集 / 信頼度のガードレール、この 4 つの整備が前提
- UX は 5 要素（進捗 / グラフ / 引用 / フィードバック / ドリルダウン）が必須
- 権限管理・監査ログ・クエリコスト上限は、本番投入前に必ず実装する