Contents
本記事は、BI 業界に出てきた "Agentic BI" の流れのなかで、特に "Push 型 BI"（Agent が能動的に変化を検知して digest を届ける機能）の部分に焦点を当て、2016 年の "Push Intelligence" 提唱まで遡って整理する解説記事です。Push 型 BI として GA 済みなのは現時点で 2 社（Tableau Pulse / Microsoft Fabric Activator）だけですが、ここから広がっていく重要な方向だと見ています。Codatum 独自の主張を述べるものではなく、Push 型 BI の現在地を俯瞰したい読者向け の地図として書いています。
1. Push 機能を持った BI が登場し始めた
ここ 2 年で、ユーザがダッシュボードを開きに来る前に Slack や Teams に変化を投げてくる、いわゆる push 機能を持った BI 製品が GA で出てきました。Agentic BI と呼ばれる AI 統合の流れのなかで、その機能群の一部として現れた形です。
ただし、Agentic BI のなかには、対話で質問に答える AI Q&A 機能と、能動的に変化を届ける push 機能が並走しています。両者は性格が違うため、本記事ではこの push 機能に絞って 整理します。GA 済みの製品とその周辺の実装の違いは §4 で詳しく見ていきます。
そして、この push 機能は新しい概念というわけではなく、10 年以上前に "Push Intelligence" として議論されていたものが、Agentic BI の流れのなかで形を変えて戻ってきた、と整理するほうが実態に近いと感じています。
2. Push Intelligence
本記事で言う Push 型 BI は、Mike Smitheman が 2016 年 2 月に LinkedIn Pulse に投稿した「Push Intelligence Vs Business Intelligence」で提唱した "Push Intelligence" というカテゴリと、本質的に同じ概念です。
Smitheman は、従来の Business Intelligence が「ユーザがダッシュボードに取りに行く」pull 型である一方、システムがダッシュボード上の変化を検知して関連性のある人に届ける push 型の analytics プラットフォームを、独立した新カテゴリとして整理しようとしました。これが Push Intelligence です。
そして、Push Intelligence が Push Intelligence として成立するために必要な性質として、記事のなかで 3 つが挙げられています。
性質 1: Change（"値" ではなく "変化" を分析する）
"BI tools focus on the values for metrics — what was Sales in California today? Push Intelligence snapshots metric values over time and applies algorithms to the data to analyze how values are changing."
要するに、従来 BI は「カリフォルニアの今日の売上はいくらか？」という値を表示します。Push 型は「どう変化しているか」をアルゴリズムで分析する、という違いです。
性質 2: Relevance（"全部" ではなく "今この瞬間 actionable なもの" を選ぶ）
"BI tools display all the metrics all the time, via dashboards and reports. Push Intelligence analyzes how metrics are changing to determine which are relevant and actionable now."
ダッシュボードは「全指標を常に表示する」。Push 型は「今この瞬間、関連性があり行動可能なもの」を選び出す、という違いです。
性質 3: Distribution（"誰" に "いつ" "どこで" 届けるか）
"BI tools rely on users to pull the information they need, when they need it. Push Intelligence determines who needs to know about the relevant changes in metrics, when they need to know, and where."
従来 BI は「ユーザに pull させる」前提に立つ。Push 型は「誰がいつどこで知るべきか」を判定して届ける、という違いです。
3 つの性質は、2016 年時点でこのように整理されていました。それでも「Push Intelligence」という言葉自体は業界用語として定着しませんでした。各 BI ベンダーは Tableau Subscriptions、Power BI Subscriptions、Looker Schedules といった通知機能を持ってはいましたが、それらは便利機能の 1 つに留まり、「push を主役に据えた analytics プラットフォーム」までは育ちませんでした。コンセプトは正しかったのに、実装が現実の業務に届かなかった、というのが 2010 年代の状況です。
その実装が、ここ数年で初めて噛み合ってきました。理由は 3 つの性質そのものが変わったからではなく、それを業務に届けるための 周辺の前提が 2 つ揃った ことにあります。
3. 動かすための 2 つの前提がここ数年で揃った
3 つの性質はコンセプトとして 2016 年時点で完成していました。一方で、それを実装に乗せるために要る周辺の前提が、ここ数年でようやく揃ってきました。本質的には 2 つ です。
前提 1: 業務 inbox の遍在化
2016 年時点の Slack DAU は数百万人規模で、Microsoft Teams はまだ誕生していませんでした。「配信先」と言ったときに現実的に取れる選択肢はメールと BI ポータル内の通知欄しかなく、メールはすでに飽和しており、BI ポータルも積極的に開いてもらえる場所ではありませんでした。
2024 年には、Slack DAU は数千万人、Teams MAU は 3 億人を超えました。全従業員が日中いる場所が、ようやく出現したことになります。push が機能するための「届ける先」が用意できた、というのが 1 つ目の前提です。
前提 2: 実用域に達した LLM
もう 1 つの前提は、LLM が業務で使えるレベルになったことです。LLM がなければ、push の中身が成立しません。重要な側面は次の 3 つです。
自然言語要約の実用化: 2016 年の Push は「Sales が 15% 下がった」のような数値とアラートだけで、受け取った側はそこから自分でデータを掘る必要があり、結局ダッシュボードを開きに行くことになりました。2024 年以降の LLM は「EMEA 売上 15% 減、主因は DACH 地域の SMB セグメントで、前四半期のキャンペーン終了タイミングと重なる」のような業務文脈付き要約を出せるようになり、「気づき」が「行動」に橋渡しできる粒度になっています。
双方向 conversational followup: 2016 年の Push は読むか無視するかの一方向でした。2024 年以降は、Slack に届いた digest に対して "なぜ？" と返信すると agent が再調査して返してくる、という体験が成立し始めています。これは元の 3 つの性質にはなかった部分で、"届ける" で完結していたものが "届けて、深掘りもさせる" 形に押し広がっています。
整理すると、2016 年の 3 つの性質を、いま揃った 2 つの前提（inbox + LLM）で動かしているのが 2026 年の Push 型 BI、ということになります。
3 つの性質そのものは形を変えていません。変わったのは、その下で動く実装側の前提です。
4. GA 済みの Push 製品 — Tableau Pulse と Microsoft Fabric Activator
Push 機能として GA で出ているのは現時点で Tableau Pulse と Microsoft Fabric Activator の 2 つです。配信先・LLM・dashboard / 指標モデルの違いを順に見ていきます。
Tableau Pulse（Salesforce / Tableau）
位置付け: metric digest を能動配信する push 専用機能（Tableau 2024.1 で GA）
配信先: Tableau for Slack / Teams app / メール / iOS-Android Push / Tableau Mobile / Salesforce Lightning ページ埋め込み
LLM: Salesforce Einstein（Trust Layer 経由）+ Q&A semantic matching に OpenAI を併用
指標モデル: 2025 GA の Tableau Semantics と統合、Salesforce Data Cloud 経由で指標を中央化（指標単位で配信）
特徴: Salesforce CRM 内の "営業ワークフロー" に埋め込むことを最優先。営業が CRM を開いた瞬間に Pulse が見えるような統合
公式発言: Tableau CEO Ryan Aytay は Pulse for Salesforce GA（2025-03）の発表で、「営業リーダーやチームは、これまで 日々の業務の中（daily flow of work） に組み込まれた、パーソナライズされアクセス可能なデータインサイトを欠いていた」と述べています
Microsoft Fabric Activator
位置付け: Power BI の measure 変化を検知して通知する alert / event エンジン（旧 Data Activator、2024-04 GA）。同じ Microsoft Fabric 内に Power BI Copilot（2024-05 GA）もありますが、こちらは AI Q&A 側で push 機能とは別レイヤーです
配信先: Microsoft Teams メッセージ / メール / Power Automate ワークフロー
LLM: Azure OpenAI Service（テナント設定で制御）
指標モデル: Power BI semantic model の measures (DAX) を直接利用。Activator のルールは report の measure / row / cell 単位
特徴: Microsoft 365 / Teams への深い統合。エンドユーザがすでに Teams にいることを最大限活用
市場ポジション: Forrester Wave: Business Intelligence Platforms, Q2 2025 で Leader、GenAI Functionality 基準で全ベンダー中最高スコア（ただし評価対象は Copilot 系 Q&A も含むので、push 機能だけの評価ではありません）
2 社の差分を整理すると、Tableau / Salesforce は CRM 内のワークフローへの埋め込みを優先、Microsoft は Teams / Office 内のユーザを最大限活用、という重力源の違いから設計が分岐しています。導入する側からすると、自社が日常的に使っているエコシステムに沿って選択肢が決まることが多くなります。
5. 過去・周辺との関係 — 2010 年代の Push 系譜と alert tooling
「Push 型 BI」は突然出てきたカテゴリではありません。2010 年代を通じて、各 BI ベンダーは局所的な機能としてアラート / 通知を持っていました。
年 | 製品 | 機能 |
2015-07 | Power BI Subscriptions / Data Alerts | GA 前後から段階追加 |
2016-02 | "Push Intelligence" 提唱（Mike Smitheman） | 業界用語として定着せず |
2017-04 | Sisense Pulse | ML 異常検知、最大 30 アラート登録 |
2017-06 | Tableau 10.3 Data-Driven Alerts | ビジュアル閾値超えで email |
2019-11 | Looker 7 Analytical Alerts | Slack / email / SMS 宛先多様化 |
「変化を検知して通知する」こと自体は、2010 年代の各 BI ベンダーが機能として持っていました。ただ、それぞれが機能の 1 つに留まり、push を主役に据えた製品形態としては育ちませんでした。
そしてもう 1 つの補助線が、インシデント管理 / SRE 系の alert toolingです。PagerDuty、Datadog、Slack の Workflow など、SRE / インフラ運用の世界はもっと前から「変化検知 → ルーティング → エスカレーション」の規律を蓄積してきました。Push 型 BI が今やろうとしていることは、この SRE 系の規律をビジネスメトリクスに持ち込む、ということでもあります。
これは、SRE 系が長年悩んできた "alert fatigue" 問題を、Push 型 BI もそのまま引き継ぐということでもあります。設計上の難しさは古くから変わっていません。
6. これから 2-3 年で進みそうな方向
向こう 2-3 年で進みそうな方向は、ベンダーの公開ロードマップというより、前提が揃ったときに自然と次に進む方向として整理できます。Slack / Teams が配信先として固まり、LLM が運用に乗ったとき、push 機能が次に拡張される論理的な先は、概ね以下の 4 つです。
6.1 双方向 conversational followup が前提になる
digest を一方向で配信して終わりではなく、Slack / Teams で "なぜ？" と返した瞬間に agent が再調査して返してくる、という形。LLM が推論できるなら、push は一方向で終わる必要がなくなります。Push 製品の差別化要因というより、前提機能に近いところに来そうです。
6.2 自律 investigation（agent 主導の深掘り）
「異常を検知 → LLM が自動で 3-5 個の仮説を立てる → データを叩いて検証 → "DACH SMB のキャンペーン終了が主因の可能性 78%" のような結論を citation 付きで返す」というフロー。LLM の推論能力が要約から仮説生成・検証まで及んでくると、自然と次に来る形です。
6.3 エージェント間連携
Agent が他の agent に仕事を委託する流れ。MCP のような共通プロトコルが整い、semantic layer も整備されてくると、社内に複数の agent を立てて連携させる構成が現実味を帯びてきます。2026-01 に v1.0 が finalize された OSI（Open Semantic Interchange） はこのレイヤーで仕様の共通化を狙っています。
6.4 Semantic / Context layer の整備が裏で進む
Push が成立するには、ダッシュボードや指標が「正しく定義されていて、業務文脈付きで解釈できる」状態になっている必要があります。GA 済みの 2 社とも、push 機能の裏側で semantic layer の整備を進めています（Tableau Semantics / Power BI semantic model）。見える側の digest UI よりも、その裏側の semantic layer の整備のほうが、Push 型 BI を長く運用するときに効いてくる部分です。
7. Codatum としての見方
私たちは、Push 型 BI の方向性そのものは素直に良いと思っています。一方で、digest の UI そのものよりも、その手前にあるダッシュボード / 指標の定義と、後ろにある "深掘り" の場のほうが、Push の運用にとっては比重が大きい、と見ています。
7.1 "気づきの後の深掘り" の場が要る
Push 型 BI が実用的に効くには、digest を受け取った人が「深掘りしたい」と思った瞬間に、摩擦なく深掘りできる環境が要ります。Slack で "なぜ？" と返したときに agent が回答してくれるだけでは足りず、その回答を自分で検証したり、次の問いに展開したりできる場所が必要になります。
Codatum は notebook 型の analytics tool として、ここを設計の重心にしてきました。Slack に届いた数字に対して、SQL を書き、データを叩き、可視化を変え、ドキュメントとして残す——この一連のフローを 1 画面で完結できる、というのが現在の体験です。
GA 製品 2 社が Slack / Teams への digest 配信を磨いているなかで、Codatum はその隣にある "深掘りの場" のほうを担っている、というのが現在の立ち位置です。
7.2 Codatum の Push 機能
Codatum でも Push 機能を提供しています。Workflow を 定期実行（hourly / daily / weekly / monthly）で走らせ、処理結果を LLM ステップで評価・サマライズ し、Slack 配信 に流す、というフローが組めます。
各ステップには if: 条件が書けるため、「LLM の評価結果が一定の条件を満たさなければ、Slack 配信ステップには進まない」という形で、定期実行のなかで「必要なときだけ "教えてくれる"」挙動を実装できます。Push 機能の中身としては、これで概ね足ります。
残りで揃っていないのは、Slack に届いた digest に対してそのまま Slack 上で「なぜ？」と返せる 双方向 followup（開発中） です。これが揃えば、Tableau Pulse 系の Push 機能と Codatum が機能面で重なる範囲はさらに広がります。
7.3 "頼まれて仕事をする" から "自分から仕事をする" へ
Conversational AI は「質問に答える AI」として議論されがちです。「先月の売上を地域別に教えて」と頼んだら、データを引いて答えてくれる、というやつです。これは便利ですが、頼まないと動かない、という形です。
Push 型 BI が向こう 2-3 年で目指している姿は、頼まれて答える AI ではなく、自分から問いを見つけて投げかけてくる AI に近いものです。"今週、EMEA の SMB セグメントで離脱率が上昇しています。仮説を 3 つ出しておきましたが、深掘りしますか？" というような形。
具体的には、自分が休んでいる間にも Agent が変化を拾って Slack に digest を残しておいてくれる、という挙動になります。金曜に長期休暇に入って、火曜に出社してきたら "先週の動きはここでした、深掘りしますか" と整理されている。この「留守中も働いている」感覚は、過去の通知機能では実現できなかった部分です。
「頼まれて仕事をする」から「自分から仕事をする」へ、という方向への舵切り。Push 型 BI の中核はここにあると考えています。Tableau Pulse と Microsoft Fabric Activator がその入口に立ち、Codatum もすでに同じ入口にいて、ここから先を組み立てているところです。
おわりに
2016 年に整理された 3 つの性質（Change / Relevance / Distribution）は、いま Tableau Pulse と Microsoft Fabric Activator が始めていることを、すでに 10 年前に書いていたものです。新しく加わったのは、それを動かすための 2 つの前提 — 業務 inbox の遍在化（Slack / Teams）と、LLM の実用化 — がここ数年で揃ってきた、という部分です。
Push 型 BI を大きな業界の転換のように語る記事も増えてきましたが、私自身は、Agent をバックグラウンドで走らせる使い方が一般化していくときに自然に出てくる形のひとつ、と感じています。Push GA は今のところ 2 社だけ、というのが地味な実態です。それでも、頼まなくても気づきが向こうから来るという挙動の変化は、長く効くタイプの方向だと思っています。
Codatum も、深掘り側（"気づきの後") を中心に作ってきましたが、"気づき" 側にも Push 機能として踏み込んでいます。定期実行 + LLM 評価 + 条件分岐 + Slack 配信が利用可能で、Slack 上での双方向 followup（開発中）が揃えば、GA 製品 2 社と機能面で並びます。"頼まれて仕事をする" から "自分から仕事をする" へ、方向は明確です。
