[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blogEntry::post\u002Fpush-bi-revival:ja":3},{"title":4,"slug":5,"description":6,"body":7,"author":8,"category":9,"coverImageUrl":13,"ogImageUrl":14,"createdAt":15,"updatedAt":16,"datePublished":17,"locale":18,"related":19},"再評価される Push 型 BI — 休みでも気づいてくれる LLM Agent","push-bi-revival","Tableau Pulse \u002F Power BI Copilot \u002F Looker (Gemini) の Push 型 BI 機能を、2016 年 Mike Smitheman の Push Intelligence 提唱まで遡って整理。コンセプトは 10 年前から完成済みで、動き出したのは周辺の前提（Slack 遍在化 \u002F LLM コスト下落 \u002F 自然言語要約 \u002F 双方向 followup）が揃ったからという構造を読み解きます。","\u003Cblockquote>\u003Cp>本記事は、BI 業界に出てきた \u003Cb>"Agentic BI"\u003C\u002Fb> の流れのなかで、特に \u003Cb>"Push 型 BI"\u003C\u002Fb>（Agent が能動的に変化を検知して digest を届ける機能）の部分に焦点を当て、2016 年の \"Push Intelligence\" 提唱まで遡って整理する解説記事です。Push 型 BI として GA 済みなのは現時点で 2 社（Tableau Pulse \u002F Microsoft Fabric Activator）だけですが、ここから広がっていく重要な方向だと見ています。Codatum 独自の主張を述べるものではなく、\u003Cb>Push 型 BI の現在地を俯瞰したい読者向け\u003C\u002Fb> の地図として書いています。\u003C\u002Fp>\u003C\u002Fblockquote>\u003Ch2>1. Push 機能を持った BI が登場し始めた\u003C\u002Fh2>\u003Cp>ここ 2 年で、ユーザがダッシュボードを開きに来る前に Slack や Teams に変化を投げてくる、いわゆる push 機能を持った BI 製品が GA で出てきました。Agentic BI と呼ばれる AI 統合の流れのなかで、その機能群の一部として現れた形です。\u003C\u002Fp>\u003Cp>ただし、Agentic BI のなかには、対話で質問に答える AI Q&A 機能と、能動的に変化を届ける push 機能が並走しています。両者は性格が違うため、本記事ではこの \u003Cb>push 機能に絞って\u003C\u002Fb> 整理します。GA 済みの製品とその周辺の実装の違いは §4 で詳しく見ていきます。\u003C\u002Fp>\u003Cp>そして、この push 機能は新しい概念というわけではなく、\u003Cb>10 年以上前に "Push Intelligence" として議論されていたもの\u003C\u002Fb>が、Agentic BI の流れのなかで形を変えて戻ってきた、と整理するほうが実態に近いと感じています。\u003C\u002Fp>\u003Cfigure class=\"EmbeddedContent_Wrapper\">\u003Cimg src=\"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F1BdUnmsem2raaVGUoyyldV\u002F5489b76584b87f04cef6416101164b42\u002Fpull-vs-push.png\" alt=\"Pull vs Push (padding fixed)\">\u003C\u002Ffigure>\u003Ch2>2. Push Intelligence\u003C\u002Fh2>\u003Cp>本記事で言う \u003Cb>Push 型 BI\u003C\u002Fb> は、Mike Smitheman が 2016 年 2 月に LinkedIn Pulse に投稿した「\u003Ca href=\"https:\u002F\u002Fwww.linkedin.com\u002Fpulse\u002Fpush-intelligence-vs-business-mike-smitheman\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Push Intelligence Vs Business Intelligence\u003C\u002Fa>」で提唱した \u003Cb>"Push Intelligence"\u003C\u002Fb> というカテゴリと、本質的に同じ概念です。\u003C\u002Fp>\u003Cp>Smitheman は、従来の Business Intelligence が「ユーザがダッシュボードに\u003Cb>取りに行く\u003C\u002Fb>」pull 型である一方、システムがダッシュボード上の変化を検知して関連性のある人に\u003Cb>届ける\u003C\u002Fb> push 型の analytics プラットフォームを、独立した新カテゴリとして整理しようとしました。これが Push Intelligence です。\u003C\u002Fp>\u003Cp>そして、Push Intelligence が Push Intelligence として成立するために必要な性質として、記事のなかで 3 つが挙げられています。\u003C\u002Fp>\u003Ch3>性質 1: Change（"値" ではなく "変化" を分析する）\u003C\u002Fh3>\u003Cblockquote>\u003Cp>\"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 \u003Ci>how\u003C\u002Fi> values are changing.\"\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>要するに、従来 BI は「カリフォルニアの今日の売上はいくらか？」という\u003Cb>値\u003C\u002Fb>を表示します。Push 型は「\u003Cb>どう変化しているか\u003C\u002Fb>」をアルゴリズムで分析する、という違いです。\u003C\u002Fp>\u003Ch3>性質 2: Relevance（"全部" ではなく "今この瞬間 actionable なもの" を選ぶ）\u003C\u002Fh3>\u003Cblockquote>\u003Cp>\"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 \u003Ci>now\u003C\u002Fi>.\"\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>ダッシュボードは「全指標を常に表示する」。Push 型は「\u003Cb>今この瞬間、関連性があり行動可能なもの\u003C\u002Fb>」を選び出す、という違いです。\u003C\u002Fp>\u003Ch3>性質 3: Distribution（"誰" に "いつ" "どこで" 届けるか）\u003C\u002Fh3>\u003Cblockquote>\u003Cp>\"BI tools rely on users to pull the information they need, when they need it. Push Intelligence determines \u003Ci>who\u003C\u002Fi> needs to know about the relevant changes in metrics, \u003Ci>when\u003C\u002Fi> they need to know, and \u003Ci>where\u003C\u002Fi>.\"\u003C\u002Fp>\u003C\u002Fblockquote>\u003Cp>従来 BI は「ユーザに pull させる」前提に立つ。Push 型は「\u003Cb>誰がいつどこで知るべきか\u003C\u002Fb>」を判定して届ける、という違いです。\u003C\u002Fp>\u003Cp>3 つの性質は、2016 年時点でこのように整理されていました。それでも「Push Intelligence」という言葉自体は業界用語として定着しませんでした。各 BI ベンダーは Tableau Subscriptions、Power BI Subscriptions、Looker Schedules といった通知機能を持ってはいましたが、それらは便利機能の 1 つに留まり、「push を主役に据えた analytics プラットフォーム」までは育ちませんでした。コンセプトは正しかったのに、実装が現実の業務に届かなかった、というのが 2010 年代の状況です。\u003C\u002Fp>\u003Cp>その実装が、ここ数年で初めて噛み合ってきました。理由は 3 つの性質そのものが変わったからではなく、それを業務に届けるための \u003Cb>周辺の前提が 2 つ揃った\u003C\u002Fb> ことにあります。\u003C\u002Fp>\u003Ch2>3. 動かすための 2 つの前提がここ数年で揃った\u003C\u002Fh2>\u003Cp>3 つの性質はコンセプトとして 2016 年時点で完成していました。一方で、それを実装に乗せるために要る周辺の前提が、ここ数年でようやく揃ってきました。本質的には \u003Cb>2 つ\u003C\u002Fb> です。\u003C\u002Fp>\u003Ch3>前提 1: 業務 inbox の遍在化\u003C\u002Fh3>\u003Cp>2016 年時点の Slack DAU は数百万人規模で、Microsoft Teams はまだ誕生していませんでした。「\u003Cb>配信先\u003C\u002Fb>」と言ったときに現実的に取れる選択肢はメールと BI ポータル内の通知欄しかなく、メールはすでに飽和しており、BI ポータルも積極的に開いてもらえる場所ではありませんでした。\u003C\u002Fp>\u003Cp>2024 年には、Slack DAU は数千万人、Teams MAU は 3 億人を超えました。\u003Cb>全従業員が日中いる場所\u003C\u002Fb>が、ようやく出現したことになります。push が機能するための「届ける先」が用意できた、というのが 1 つ目の前提です。\u003C\u002Fp>\u003Ch3>前提 2: 実用域に達した LLM\u003C\u002Fh3>\u003Cp>もう 1 つの前提は、LLM が業務で使えるレベルになったことです。LLM がなければ、push の中身が成立しません。重要な側面は次の 3 つです。\u003C\u002Fp>\u003Cp>\u003Cb>自然言語要約の実用化\u003C\u002Fb>: 2016 年の Push は「Sales が 15% 下がった」のような数値とアラートだけで、受け取った側はそこから自分でデータを掘る必要があり、結局ダッシュボードを開きに行くことになりました。2024 年以降の LLM は「\u003Cb>EMEA 売上 15% 減、主因は DACH 地域の SMB セグメントで、前四半期のキャンペーン終了タイミングと重なる\u003C\u002Fb>」のような業務文脈付き要約を出せるようになり、「気づき」が「行動」に橋渡しできる粒度になっています。\u003C\u002Fp>\u003Cp>\u003Cb>双方向 conversational followup\u003C\u002Fb>: 2016 年の Push は読むか無視するかの一方向でした。2024 年以降は、Slack に届いた digest に対して \"\u003Cb>なぜ？\u003C\u002Fb>\" と返信すると agent が再調査して返してくる、という体験が成立し始めています。これは元の 3 つの性質にはなかった部分で、\"届ける\" で完結していたものが \"届けて、深掘りもさせる\" 形に押し広がっています。\u003C\u002Fp>\u003Cp>整理すると、2016 年の 3 つの性質を、いま揃った 2 つの前提（inbox + LLM）で動かしているのが 2026 年の Push 型 BI、ということになります。\u003C\u002Fp>\u003Cfigure class=\"EmbeddedContent_Wrapper\">\u003Cimg src=\"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F5mFywy4Kbjj2XW7N5CkXvL\u002F81441dc73f902ca5eb41d77e256db283\u002Fprerequisites-timeline.png\" alt=\"Prerequisites timeline (no cost)\">\u003C\u002Ffigure>\u003Cp>3 つの性質そのものは形を変えていません。変わったのは、その下で動く実装側の前提です。\u003C\u002Fp>\u003Ch2>4. GA 済みの Push 製品 — Tableau Pulse と Microsoft Fabric Activator\u003C\u002Fh2>\u003Cp>Push 機能として GA で出ているのは現時点で \u003Cb>Tableau Pulse\u003C\u002Fb> と \u003Cb>Microsoft Fabric Activator\u003C\u002Fb> の 2 つです。配信先・LLM・dashboard \u002F 指標モデルの違いを順に見ていきます。\u003C\u002Fp>\u003Ch3>Tableau Pulse（Salesforce \u002F Tableau）\u003C\u002Fh3>\u003Cul>\u003Cli>\u003Cp>\u003Cb>位置付け\u003C\u002Fb>: metric digest を能動配信する \u003Cb>push 専用機能\u003C\u002Fb>（Tableau 2024.1 で GA）\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>配信先\u003C\u002Fb>: Tableau for Slack \u002F Teams app \u002F メール \u002F iOS-Android Push \u002F Tableau Mobile \u002F \u003Cb>Salesforce Lightning ページ埋め込み\u003C\u002Fb>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>LLM\u003C\u002Fb>: Salesforce \u003Cb>Einstein\u003C\u002Fb>（Trust Layer 経由）+ Q&A semantic matching に \u003Cb>OpenAI\u003C\u002Fb> を併用\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>指標モデル\u003C\u002Fb>: 2025 GA の \u003Cb>Tableau Semantics\u003C\u002Fb> と統合、Salesforce Data Cloud 経由で指標を中央化（指標単位で配信）\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>特徴\u003C\u002Fb>: Salesforce CRM 内の \"営業ワークフロー\" に埋め込むことを最優先。\u003Cb>営業が CRM を開いた瞬間に Pulse が見える\u003C\u002Fb>ような統合\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>公式発言\u003C\u002Fb>: Tableau CEO \u003Cb>Ryan Aytay\u003C\u002Fb> は Pulse for Salesforce GA（2025-03）の発表で、「営業リーダーやチームは、これまで \u003Cb>日々の業務の中（daily flow of work）\u003C\u002Fb> に組み込まれた、パーソナライズされアクセス可能なデータインサイトを欠いていた」と述べています\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Ch3>Microsoft Fabric Activator\u003C\u002Fh3>\u003Cul>\u003Cli>\u003Cp>\u003Cb>位置付け\u003C\u002Fb>: Power BI の measure 変化を検知して通知する \u003Cb>alert \u002F event エンジン\u003C\u002Fb>（旧 Data Activator、2024-04 GA）。同じ Microsoft Fabric 内に \u003Cb>Power BI Copilot\u003C\u002Fb>（2024-05 GA）もありますが、こちらは AI Q&A 側で push 機能とは別レイヤーです\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>配信先\u003C\u002Fb>: \u003Cb>Microsoft Teams\u003C\u002Fb> メッセージ \u002F メール \u002F Power Automate ワークフロー\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>LLM\u003C\u002Fb>: \u003Cb>Azure OpenAI Service\u003C\u002Fb>（テナント設定で制御）\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>指標モデル\u003C\u002Fb>: Power BI semantic model の \u003Cb>measures (DAX) を直接利用\u003C\u002Fb>。Activator のルールは report の measure \u002F row \u002F cell 単位\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>特徴\u003C\u002Fb>: \u003Cb>Microsoft 365 \u002F Teams への深い統合\u003C\u002Fb>。エンドユーザがすでに Teams にいることを最大限活用\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cb>市場ポジション\u003C\u002Fb>: \u003Cb>Forrester Wave: Business Intelligence Platforms, Q2 2025 で Leader、GenAI Functionality 基準で全ベンダー中最高スコア\u003C\u002Fb>（ただし評価対象は Copilot 系 Q&A も含むので、push 機能だけの評価ではありません）\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>2 社の差分を整理すると、\u003Cb>Tableau \u002F Salesforce\u003C\u002Fb> は CRM 内のワークフローへの埋め込みを優先、\u003Cb>Microsoft\u003C\u002Fb> は Teams \u002F Office 内のユーザを最大限活用、という重力源の違いから設計が分岐しています。導入する側からすると、自社が日常的に使っているエコシステムに沿って選択肢が決まることが多くなります。\u003C\u002Fp>\u003Ch2>5. 過去・周辺との関係 — 2010 年代の Push 系譜と alert tooling\u003C\u002Fh2>\u003Cp>「Push 型 BI」は突然出てきたカテゴリではありません。2010 年代を通じて、各 BI ベンダーは局所的な機能としてアラート \u002F 通知を持っていました。\u003C\u002Fp>\u003Ctable>\u003Ctr>\u003Ctd>\u003Cp>年\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>製品\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>機能\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>2015-07\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>Power BI Subscriptions \u002F Data Alerts\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>GA 前後から段階追加\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>2016-02\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>\"Push Intelligence\" 提唱（Mike Smitheman）\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>業界用語として定着せず\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>2017-04\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>Sisense Pulse\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>ML 異常検知、最大 30 アラート登録\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>2017-06\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>Tableau 10.3 Data-Driven Alerts\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>ビジュアル閾値超えで email\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>\u003Cp>2019-11\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>Looker 7 Analytical Alerts\u003C\u002Fp>\u003C\u002Ftd>\u003Ctd>\u003Cp>Slack \u002F email \u002F SMS 宛先多様化\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftable>\u003Cp>「変化を検知して通知する」こと自体は、2010 年代の各 BI ベンダーが\u003Cb>機能として持っていました\u003C\u002Fb>。ただ、それぞれが機能の 1 つに留まり、push を主役に据えた製品形態としては育ちませんでした。\u003C\u002Fp>\u003Cp>そしてもう 1 つの補助線が、\u003Cb>インシデント管理 \u002F SRE 系の alert tooling\u003C\u002Fb>です。PagerDuty、Datadog、Slack の Workflow など、SRE \u002F インフラ運用の世界はもっと前から「変化検知 → ルーティング → エスカレーション」の規律を蓄積してきました。Push 型 BI が今やろうとしていることは、この SRE 系の規律をビジネスメトリクスに持ち込む、ということでもあります。\u003C\u002Fp>\u003Cp>これは、SRE 系が長年悩んできた \"alert fatigue\" 問題を、Push 型 BI もそのまま引き継ぐということでもあります。設計上の難しさは古くから変わっていません。\u003C\u002Fp>\u003Ch2>6. これから 2-3 年で進みそうな方向\u003C\u002Fh2>\u003Cp>向こう 2-3 年で進みそうな方向は、ベンダーの公開ロードマップというより、\u003Cb>前提が揃ったときに自然と次に進む方向\u003C\u002Fb>として整理できます。Slack \u002F Teams が配信先として固まり、LLM が運用に乗ったとき、push 機能が次に拡張される論理的な先は、概ね以下の 4 つです。\u003C\u002Fp>\u003Ch3>6.1 双方向 conversational followup が前提になる\u003C\u002Fh3>\u003Cp>digest を一方向で配信して終わりではなく、Slack \u002F Teams で \"なぜ？\" と返した瞬間に agent が再調査して返してくる、という形。LLM が推論できるなら、push は一方向で終わる必要がなくなります。Push 製品の差別化要因というより、前提機能に近いところに来そうです。\u003C\u002Fp>\u003Ch3>6.2 自律 investigation（agent 主導の深掘り）\u003C\u002Fh3>\u003Cp>「異常を検知 → LLM が自動で 3-5 個の仮説を立てる → データを叩いて検証 → \"DACH SMB のキャンペーン終了が主因の可能性 78%\" のような結論を citation 付きで返す」というフロー。LLM の推論能力が要約から仮説生成・検証まで及んでくると、自然と次に来る形です。\u003C\u002Fp>\u003Ch3>6.3 エージェント間連携\u003C\u002Fh3>\u003Cp>Agent が他の agent に仕事を委託する流れ。MCP のような共通プロトコルが整い、semantic layer も整備されてくると、社内に複数の agent を立てて連携させる構成が現実味を帯びてきます。2026-01 に v1.0 が finalize された \u003Cb>OSI（Open Semantic Interchange）\u003C\u002Fb> はこのレイヤーで仕様の共通化を狙っています。\u003C\u002Fp>\u003Ch3>6.4 Semantic \u002F Context layer の整備が裏で進む\u003C\u002Fh3>\u003Cp>Push が成立するには、ダッシュボードや指標が「正しく定義されていて、業務文脈付きで解釈できる」状態になっている必要があります。GA 済みの 2 社とも、push 機能の裏側で semantic layer の整備を進めています（Tableau Semantics \u002F Power BI semantic model）。見える側の digest UI よりも、その裏側の semantic layer の整備のほうが、Push 型 BI を長く運用するときに効いてくる部分です。\u003C\u002Fp>\u003Ch2>7. Codatum としての見方\u003C\u002Fh2>\u003Cp>私たちは、Push 型 BI の方向性そのものは素直に良いと思っています。一方で、digest の UI そのものよりも、その手前にあるダッシュボード \u002F 指標の定義と、後ろにある \"深掘り\" の場のほうが、Push の運用にとっては比重が大きい、と見ています。\u003C\u002Fp>\u003Ch3>7.1 "気づきの後の深掘り" の場が要る\u003C\u002Fh3>\u003Cp>Push 型 BI が実用的に効くには、digest を受け取った人が「深掘りしたい」と思った瞬間に、摩擦なく深掘りできる環境が要ります。Slack で \"なぜ？\" と返したときに agent が回答してくれるだけでは足りず、その回答を自分で検証したり、次の問いに展開したりできる場所が必要になります。\u003C\u002Fp>\u003Cp>Codatum は notebook 型の analytics tool として、ここを設計の重心にしてきました。Slack に届いた数字に対して、SQL を書き、データを叩き、可視化を変え、ドキュメントとして残す——この一連のフローを 1 画面で完結できる、というのが現在の体験です。\u003C\u002Fp>\u003Cp>GA 製品 2 社が Slack \u002F Teams への digest 配信を磨いているなかで、Codatum はその隣にある \"深掘りの場\" のほうを担っている、というのが現在の立ち位置です。\u003C\u002Fp>\u003Ch3>7.2 Codatum の Push 機能\u003C\u002Fh3>\u003Cp>Codatum でも Push 機能を提供しています。Workflow を \u003Cb>定期実行\u003C\u002Fb>（hourly \u002F daily \u002F weekly \u002F monthly）で走らせ、処理結果を \u003Cb>LLM ステップで評価・サマライズ\u003C\u002Fb> し、\u003Cb>Slack 配信\u003C\u002Fb> に流す、というフローが組めます。\u003C\u002Fp>\u003Cp>各ステップには \u003Ccode class=\"hljs\">if:\u003C\u002Fcode> 条件が書けるため、「LLM の評価結果が一定の条件を満たさなければ、Slack 配信ステップには進まない」という形で、定期実行のなかで「\u003Cb>必要なときだけ "教えてくれる"\u003C\u002Fb>」挙動を実装できます。Push 機能の中身としては、これで概ね足ります。\u003C\u002Fp>\u003Cp>残りで揃っていないのは、Slack に届いた digest に対してそのまま Slack 上で「なぜ？」と返せる \u003Cb>双方向 followup（開発中）\u003C\u002Fb> です。これが揃えば、Tableau Pulse 系の Push 機能と Codatum が機能面で重なる範囲はさらに広がります。\u003C\u002Fp>\u003Cfigure class=\"EmbeddedContent_Wrapper\">\u003Cimg src=\"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F5vpOVoPpVpTfh2344m6ni0\u002Fe517ec8e4d40bb6898e98923e678a41b\u002Fcodatum-status.png\" alt=\"Codatum Push status (no event-trigger)\">\u003C\u002Ffigure>\u003Ch3>7.3 "頼まれて仕事をする" から "自分から仕事をする" へ\u003C\u002Fh3>\u003Cp>Conversational AI は「質問に答える AI」として議論されがちです。「先月の売上を地域別に教えて」と頼んだら、データを引いて答えてくれる、というやつです。これは便利ですが、頼まないと動かない、という形です。\u003C\u002Fp>\u003Cp>Push 型 BI が向こう 2-3 年で目指している姿は、頼まれて答える AI ではなく、\u003Cb>自分から問いを見つけて投げかけてくる AI\u003C\u002Fb> に近いものです。\"今週、EMEA の SMB セグメントで離脱率が上昇しています。仮説を 3 つ出しておきましたが、深掘りしますか？\" というような形。\u003C\u002Fp>\u003Cp>具体的には、自分が休んでいる間にも Agent が変化を拾って Slack に digest を残しておいてくれる、という挙動になります。金曜に長期休暇に入って、火曜に出社してきたら \"先週の動きはここでした、深掘りしますか\" と整理されている。この「\u003Cb>留守中も働いている\u003C\u002Fb>」感覚は、過去の通知機能では実現できなかった部分です。\u003C\u002Fp>\u003Cfigure class=\"EmbeddedContent_Wrapper\">\u003Cimg src=\"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F450nkJYmFq8Ed5rGkmTx3x\u002F12bd61608c5ea5279ce13e5f8d08f79e\u002Ffind-not-ask.png\" alt=\"Find vs Ask (new keyphrase)\">\u003C\u002Ffigure>\u003Cp>「頼まれて仕事をする」から「自分から仕事をする」へ、という方向への舵切り。Push 型 BI の中核はここにあると考えています。Tableau Pulse と Microsoft Fabric Activator がその入口に立ち、Codatum もすでに同じ入口にいて、ここから先を組み立てているところです。\u003C\u002Fp>\n              \u003Caside class=\"BlogCTA\">\n                \u003Cdiv class=\"BlogCTA_Body\">\n                  \u003Cp class=\"BlogCTA_Title\">BI 選定で迷っていませんか？\u003C\u002Fp>\n                  \u003Cp class=\"BlogCTA_Description\">データ環境・分析内容・チーム体制を伺って、Codatum を含めたデータ基盤の組み立て方を 30 分で一緒に考えます。\u003C\u002Fp>\n                \u003C\u002Fdiv>\n                \u003Cdiv class=\"BlogCTA_Actions\">\n                  \u003Ca class=\"BlogCTA_Button _outline\" href=\"https:\u002F\u002Fapp.codatum.com\u002Fsignup?utm_source=blog&utm_medium=mid-cta\" target=\"_blank\" rel=\"noopener noreferrer\">\n                    無料ではじめる\n                  \u003C\u002Fa>\n                  \u003Cbutton type=\"button\" class=\"BlogCTA_Button _primary\" data-cta-action=\"consultation\">\n                    相談する\n                  \u003C\u002Fbutton>\n                \u003C\u002Fdiv>\n              \u003C\u002Faside>\n            \u003Ch2>おわりに\u003C\u002Fh2>\u003Cp>2016 年に整理された 3 つの性質（Change \u002F Relevance \u002F Distribution）は、いま Tableau Pulse と Microsoft Fabric Activator が始めていることを、すでに 10 年前に書いていたものです。新しく加わったのは、それを動かすための \u003Cb>2 つの前提\u003C\u002Fb> — 業務 inbox の遍在化（Slack \u002F Teams）と、LLM の実用化 — がここ数年で揃ってきた、という部分です。\u003C\u002Fp>\u003Cp>Push 型 BI を大きな業界の転換のように語る記事も増えてきましたが、私自身は、Agent をバックグラウンドで走らせる使い方が一般化していくときに自然に出てくる形のひとつ、と感じています。Push GA は今のところ 2 社だけ、というのが地味な実態です。それでも、頼まなくても気づきが向こうから来るという挙動の変化は、長く効くタイプの方向だと思っています。\u003C\u002Fp>\u003Cp>Codatum も、深掘り側（\"気づきの後\") を中心に作ってきましたが、\"気づき\" 側にも Push 機能として踏み込んでいます。定期実行 + LLM 評価 + 条件分岐 + Slack 配信が利用可能で、Slack 上での双方向 followup（開発中）が揃えば、GA 製品 2 社と機能面で並びます。\"頼まれて仕事をする\" から \"自分から仕事をする\" へ、方向は明確です。\u003C\u002Fp>\u003Ch2>参考文献\u003C\u002Fh2>\u003Cul>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.linkedin.com\u002Fpulse\u002Fpush-intelligence-vs-business-mike-smitheman\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Push Intelligence Vs Business Intelligence | Mike Smitheman, LinkedIn Pulse, 2016-02-24\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.salesforce.com\u002Fnews\u002Fstories\u002Ftableau-pulse-general-availability-news\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Tableau Pulse GA announcement | Salesforce, 2024-02\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.salesforce.com\u002Fnews\u002Fstories\u002Fpulse-for-salesforce-available\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Pulse for Salesforce GA | Salesforce, 2025-03\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fhelp.tableau.com\u002Fcurrent\u002Fonline\u002Fen-us\u002Fpulse_intro.htm\" target=\"_blank\" rel=\"noopener noreferrer\">Tableau Pulse 公式 doc | Tableau Help\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.salesforce.com\u002Fnews\u002Fstories\u002Ftableau-next-announcement\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Tableau Next agentic 体系 | Salesforce, Dreamforce 2025\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fpowerbi.microsoft.com\u002Fen-us\u002Fblog\u002Fcopilot-in-microsoft-fabric-is-now-generally-available-in-the-power-bi-experience\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Copilot in Microsoft Fabric GA | Microsoft, 2024-05-21\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Ffabric\u002Freal-time-intelligence\u002Fdata-activator\u002Factivator-get-data-power-bi\" target=\"_blank\" rel=\"noopener noreferrer\">Fabric Activator + Power BI alerts | Microsoft Learn\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fpowerbi.microsoft.com\u002Fen-us\u002Fblog\u002Fmicrosoft-named-a-leader-in-the-forrester-wave-business-intelligence-platforms-q2-2025\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Forrester Wave Q2 2025 | Microsoft Power BI Leader\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca href=\"https:\u002F\u002Fa16z.com\u002Fllmflation-llm-inference-cost\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">LLMflation | Guido Appenzeller, a16z, 2024-11\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>\u003C\u002Fp>","Naoki Shibayama",{"title":10,"slug":11,"description":12},"マーケットインサイト","market-insights","","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F4nR1TyJcxZ3sA6yCKa3agU\u002F0427372c0492669734b4f763d3848211\u002Fcover.png","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F37bHi4cyLug0uRa73kAHVB\u002Fd17d4a33a88ded0c8cbce37a775c906d\u002Fhero.png","2026-05-19T00:00:16.503Z","2026-05-21T09:46:15.188Z","2026-05-19T09:00:00+09:00","ja",[20,30,40],{"title":21,"slug":22,"description":23,"author":8,"category":24,"coverImageUrl":25,"ogImageUrl":26,"createdAt":27,"updatedAt":28,"datePublished":29,"locale":18},"ソフトウェアを「どの深さまで」生成させるか — 適合と負担のトレードオフ","dynamic-generation-boundary","ソフトウェアを顧客ごとにどこまで深く生成するかは、適合と「抱える負担」のトレードオフ。UI・app・db・infra\u002Fauth の各層で、深く生成するほど自社への適合は増すが、構築・運用・セキュリティ・保守の負担も増す。エージェントが下げるのは構築コストで、運用・保守の負担は残る。Salesforce・Notion・Palantir の違いを「どの層を固定し、どの層を生成するか」で読み解き、データ分析でのアナロジーまで、どこまで生成すべきかの枠組みを示す。",{"title":10,"slug":11,"description":12},"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002FQHcCTFntE5dCFaWlkIRq6\u002F3f9e09bca03d181a8f680fc9b365d340\u002Fdynamic-generation-boundary-cover-blueprint.png","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F7ensVq3DvkDku6miK4tuAF\u002F10aa3e9e7017952cdd8ea42e23d05b0c\u002Fdynamic-generation-boundary-hero-blueprint-fixed.png","2026-06-09T01:00:10.816Z","2026-06-16T03:05:20.410Z","2026-06-11T08:30+09:00",{"title":31,"slug":32,"description":33,"author":8,"category":34,"coverImageUrl":35,"ogImageUrl":36,"createdAt":37,"updatedAt":38,"datePublished":39,"locale":18},"「人間の」意思決定までもAIに任せられるようになるのか","agent-orchestrator-unit","AIに作業を任せても楽にならないのはなぜか。増えているのは「判断」だ、という観点から、判断は人間に残るとする見方（Nova Spivackの\"The Orchestrator\"）と、評価や実務をAIに渡す動き（LLM-as-a-judge・τ-bench・Constitutional AI・AlphaEvolve）を整理し、意思決定を「上（目的設定）」と「下（細かい判断）」に分けて考えます。",{"title":10,"slug":11,"description":12},"https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F6Inwc4RDQBMptAMzjs96Gs\u002Fce704cfbfda741de21853c068d2f79d9\u002Fagent-orchestrator-unit-cover-blueprint.png","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F63KIUwzvi7m0c9NA4zdbIS\u002Fc9576f265084fd6c85da393159baffd6\u002Fagent-orchestrator-unit-hero-blueprint-fixed.png","2026-06-04T01:00:05.117Z","2026-06-16T03:05:26.133Z","2026-06-04T10:00+09:00",{"title":41,"slug":42,"description":43,"author":8,"category":44,"urlCategorySlug":45,"coverImageUrl":46,"ogImageUrl":47,"createdAt":48,"updatedAt":49,"datePublished":50,"locale":18},"内製データ Agent の現在地 — OpenAI と Meta が見せた \"6 層の context\"","in-house-data-agent","OpenAI \u002F Meta が公開した内製データ Agent の構造（OpenAI 6 層 \u002F Meta Cookbook-Recipe-Ingredient）を、dbt SoAE 2026 の業界数字と並べて整理。\"context engineering\" は schema 以外の組織知を retrievable に整理する地味な作業、というのが核。中堅企業向け Skeptics 視点も提示。",{"title":10,"slug":11,"description":12},"product","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F2cnf7pCQu7OQdiHrnea0NN\u002F345e3a5a0bf68af3097eecb51833c72e\u002Fcover-blueprint.png","https:\u002F\u002Fimages.ctfassets.net\u002Fggtw2zqmifs5\u002F4S5t1uJmGZRVH0JXx92LAy\u002Fe9ea86158fc39f04cef5e2c08effa752\u002Fhero-blueprint.png","2026-05-12T00:00:10.863Z","2026-05-21T09:46:17.058Z","2026-05-12T09:00:00+09:00"]