障害や顧客離れにつながる情報を、対処できる時期が過ぎてから知っても、活用は難しい。Salesforceは2026年10月13日付の公式記事で、業務の稼働中のデータをAIが継続して読み解く構想を「operational intelligence」と呼んだ。同社AI Researchのチーフサイエンティスト、Silvio Savarese氏が目指す方向として紹介されている。では、何を読み、何を得ようとしているのか。公開記事で確認できることと、本稿の解釈を分けて見ていこう。
入力は稼働中の業務データ。狙いは早く気づける状態をつくること
Salesforceの記事が明示する入力は、企業の「live data（稼働中のデータ）」だ。AIがそれを継続して推論する、というのが構想の中心にある。特定の時点だけを切り出すのではなく、変化を見続けるという時間軸が強調されている。一方、対象となるデータ項目や推論方法の詳細は、提供された記事の抜粋からは分からない。
同記事は、障害を防げたかもしれない情報、顧客離れを避けられたかもしれない情報、取引先との関係を守れたかもしれない情報が、行動できる時期を過ぎて表面化するという問題を挙げる。これらは同社による課題の説明であり、AIが実際に障害や顧客離れを予測・防止した実績を示すものではない。
入力と出力を具体的に考えるため、障害の兆候を扱う場面を仮定しよう。時刻の付いた稼働状態の変化を入力とし、「確認すべき変化が起きている」という手がかりを担当者に示すなら、判断までの時間を短くできる可能性がある。ただし、これは仕組みを理解するための仮例だ。Salesforceがそのデータを取り込めること、通知画面を備えること、担当者に知らせることまで確認できたわけではない。
事後に分かる情報と、判断に間に合う情報
元の記事はレーダーをたとえに使う。電波の反射という現象を、人が状況を把握して行動できる像に変えた点に着目している。業務に置き換えると、データが存在するだけでは足りない。変化を読み取れる形にし、判断できるうちに届けることが狙いだ、と本稿は解釈する。
ここで確認できる違いは、継続してデータを見るという構想と、情報が事後に表面化することへの問題提起である。既存の監視製品やダッシュボードより検知が速い、正確だ、安いといった比較結果は示されていない。通知の自動化や、検知後の対応までAIが実行するかも、この抜粋では未確認だ。
違いが意味を持つかどうかは、情報を受け取る時刻で判断が変わるかにかかる。障害なら「発生後に原因を説明できた」場合と「影響が広がる前に確認を始められた」場合では、情報の使い道が異なる。ただし、どれだけ早く兆候を捉えられるか、誤報や見逃しがどの程度あるかは、今回の資料から評価できない。早期発見による効果は、現時点では期待として扱うのが適切だ。
自律的に作業するAIとの関係
Salesforceが2026年5月27日に公開した別の記事は、同社の開発工程で自律ツールがコード作成、プルリクエストのレビュー、デプロイの進行を担うと説明している。こちらは作業の実行に焦点を当てた記事だ。10月の記事が焦点を当てるのは、業務データを継続して読み、変化を判断材料にするという構想である。
両記事を並べると、「作業を進める」と「状況を読み取る」という異なる役割を理解しやすい。ただし、二つが同じ製品で連携するのか、検知から作業実行まで一続きで動くのかは示されていない。5月の記事にある社内開発の成果を、10月の構想の性能や提供状況の証拠として使うこともできない。
接続方法と効果は、まだ確かめる必要がある
実際の使い道を考える際は、まず「どの変化を、いつまでに知れば判断を変えられるか」を定めると分かりやすい。障害の兆候でも、知らせを受けた人が確認できる時間が残っているかどうかで価値は変わる。これは本稿の評価方法の提案であり、Salesforceが公表した導入手順ではない。
次に確かめたいのは接続と出力だ。どの業務システムのどのデータを扱えるのか、データはどの頻度で更新されるのか、異なる情報をどう結びつけるのか、結果はどこに表示されるのか。提供された抜粋には、これらを特定できる実装情報がない。対応製品、利用条件、精度、導入事例も同じく判断できないため、現時点で特定の連携や効果を前提にすることはできない。
今回の発表から読み取れる核心は、業務データを後から説明する材料としてだけでなく、まだ行動できる時点の判断材料にしようという発想だ。使える技術かどうかを見極める次の問いは明確である。対象のデータと知らせ方を確認したうえで、その知らせによって実際の判断が間に合うのかを確かめたい。
出典：参照した一次発表（確認日：2026-10-13）。