「データに聞く」から、「データが先に気づく」へ
月曜の朝、決まったダッシュボードを5枚開く。先週とほとんど同じグラフを眺め、「たぶん大丈夫そうだ」と閉じる。
そして数週間後、見落としていた変化に気づく。いつも見ていた人が休んでいた、別のタブに埋もれていた、そもそも見るべき指標が増えすぎていた。データを扱う会社では、珍しくない光景だと思います。
私は、この仕事がAI時代にもそのまま残り続けるのは、やはりおかしいと思っています。
AIは分析をいくらでも増やせます。でも、人間の注意力は増やせません。
「データに聞く」までは簡単になった
この20年で、BIツールはずいぶん使いやすくなりました。クラウドDWHによってデータをためやすくなり、モデリングレイヤーで指標をそろえられるようになり、可視化ツールでグラフを作るハードルも下がりました。
そこへAIが入ってきました。SQLを書き、グラフを選び、自然な言葉で質問すればレポートのたたき台まで作ってくれる。以前なら半日かかっていた分析が、数分で終わることもあります。
これは大きな進歩です。ただ、「データに聞く」ことが簡単になっても、いつ何を聞くべきかを決めるのはまだ人間です。
分析を作るコストは急速に下がっています。一方で、それを見るコストはほとんど下がっていない。この差は、これからさらに広がります。
この構造自体は新しくありません。Herbert Simonは1971年に、“a wealth of information creates a poverty of attention” と指摘しました。情報が増えるほど、それを受け取る側の時間と注意が希少になる。AIが分析の供給量を急速に増やすことで、この古い問題がBIの中心に出てきます。
ダッシュボードが人に頼んでいる仕事
ダッシュボードには、画面上には書かれていない前提があります。
「大事な変化を見逃したくなければ、定期的に見に来てください」という前提です。
実際の流れは、かなり人力です。
開く。眺める。違和感を見つける。深掘りする。
ダッシュボードは数字を表示してくれますが、いつ確認するかを決めるのも、変化に気づくのも、人間です。システムの言葉でいえば、ダッシュボードは定期的に見に行く仕組みであり、その巡回処理を人が担ってきました。
AIでダッシュボードを100個作れるようになっても、人が100個を見ることはできません。作る力が上がるほど、この矛盾はむしろ目立つようになります。
「データに聞く」だけでは、まだ人が最初に動く
では、ダッシュボードをチャットに置き換えれば解決するでしょうか。
私は、半分は解決すると思っています。自然な言葉でデータに質問できれば、SQLを書けない人でも自分で探索できます。データチームへの依頼も減ります。これは間違いなく便利です。
でも、監視という仕事は残ります。
ダッシュボードでは、人が「いつ見るか」を決めていました。チャットでは、人が「いつ、何を聞くか」を決めます。どちらも、最初に動くのは人です。
本当に怖いのは、答えられなかった質問ではありません。その日に聞くべきだったのに、誰も思いつかなかった質問です。
次は、データが先に語る
ここで変えるべきなのは、画面ではなく主導権です。
従来のBIでは、人がデータを見に行きます。AIをチャットとして足したBIでは、人がAIに頼み、AIがデータを見に行きます。
次のBIでは、この向きが逆になります。データの変化をAIが見つけ、今見るべき理由と根拠を添えて、人に届ける。
これは、単なる通知機能の話ではありません。決められた時刻にレポートを送るだけでも、しきい値を超えたらアラートを出すだけでもない。変化を見つけ、比較し、少し掘り下げ、いま人の注意を使う価値があるかを判断するところまで、ソフトウェアが引き受けるという話です。
もちろん、最終判断までAIに渡すわけではありません。
気づく。届ける。根拠を確かめる。深掘りする。そして、人が決める。
人の仕事をなくすのではなく、人の注意力を「眺めること」から「決めること」へ戻したいのです。
私は、これがAI-native BI時代の次のBIの形だと考えています。人が見に行くのを待つのではなく、見るべき変化が起きたときにBIの側から知らせる。ダッシュボードやチャットを使いやすくするだけでなく、誰が最初に動くかを変えるのです。
ダッシュボードはなくならない
ここまで読むと、「ではダッシュボードは不要になるのか」と思うかもしれません。
私は、逆だと考えています。ダッシュボードはなくなりません。ただ、BIの入口ではなくなります。
今は、何かが起きたかを探すためにダッシュボードを開きます。この形のBIでは、発見はAIが担います。ダッシュボードを開くのは、そのシグナルが正しいかを確認し、どの顧客や商品で起きているのかを掘り下げるときです。
入口から、証拠を確かめる場所へ。
役割は狭くなりますが、重要性はむしろ上がります。経営会議に届いたシグナルが本当なのか。その場で確認できる画面は、これまで以上に信頼される必要があります。
通知ではなく、検証できるシグナルをつくる
AIが先に変化を知らせるBIで一番避けたいのは、ダッシュボード疲れを通知疲れに置き換えてしまうことです。
「売上が変わりました」とだけ言われても、人は動けません。
何が変わったのか。いつと比べたのか。どの指標の、どのセグメントなのか。根拠は何か。さらに調べるにはどこを見ればいいのか。人の注意を求めるなら、同じ場所からここまでたどれなければなりません。
Squadbaseでは、レポート、裏側のダッシュボード、分析に使ったクエリやデータを、同じプロジェクトの中でつなげて扱えます。シグナルを出す場所と、確かめる場所を分断しない。これはAI-native BIにおいて、付加機能ではなく信頼の土台になります。
私たちが特に大事にしているのは、AIエージェントの調査過程を一つのスレッドとして残すことです。最終的なレポートだけでなく、「どの変化に気づき、何を調べ、なぜこの結論に至ったのか」という作業の流れを同じ文脈で追える。そのスレッドから裏側のダッシュボード、クエリ、元データへそのまま遡れることで、人はAIの結論を最初から調べ直さずに検証できます。
AIは見落とすことがあります。重要度を取り違えることもあります。だからこそ、信頼できる指標、どこまでを監視しているかの明示、そして人がすぐ検証できる経路が必要です。
AI-native BIの価値は、生成した分析の量ではなく、人間にどれだけ注意力を返せたかで測るべきです。
目指すのは、単に「データに聞きやすくする」ことではありません。データが先に語り、そのシグナルを人がすぐ確かめられる状態です。
そして、次の問題が出てくる
ここまでをうまく作れたとしても、すぐに次の壁にぶつかります。
AIは、統計的に変わったものを大量に見つけられます。でも、その中で「いま、このチームにとって重要なもの」はどれでしょうか。
売上が10％下がった。同じ変化でも、季節要因を知っている経理チームは静観するかもしれません。昨日キャンペーンを始めたマーケティングチームにとっては、すぐ調べるべき異常かもしれません。契約更新が近い顧客の利用量低下なら、カスタマーサクセスにとっては売上全体の変動より重要です。
重要かどうかは、データだけでは決まりません。今期の目標、注力している顧客、許容するしきい値、最近の施策。成果に責任を持つチームの判断があって、初めて決まります。
では、その判断をAIはどうやって知るのか。優先順位が変わったとき、データチームへの追加依頼を挟まずに、誰が監視の仕方を変えるのか。
AIが先に変化を知らせるようになると、次のボトルネックは分析ではなくコンテキストになります。
このBIの形を実用的なものにするには、AIが変化を見つけるだけでは足りません。AIが「どの変化を誰に知らせるべきか」を判断できるように、チームの目標や優先順位を伝え続ける必要があります。
売上やアクティブユーザーなど、全社で共通に使う数字の定義はデータチームが整える。一方、今期に優先するKPIや顧客、どんな変化を調べるかは、そのKPIに責任を持つマーケティング、営業、カスタマーサクセスなどの各チームが決める。
次の記事では、AIデータエージェントが「どの変化を誰に知らせるべきか」を判断するために、データチームが守る共通の定義と、各チームが更新する判断基準をどう組み合わせるかを説明します。AI-native BIを単なる通知機能で終わらせず、現場の優先順位に合わせて使い続けるための設計です。
