InfiniteWatch と Confluent、customer interaction data を real-time intelligence へ

Confluent は 2026年5月15日、InfiniteWatch が Confluent を event backbone として使い、顧客 interaction data を real-time intelligence に変える事例を公開しました。web、call、email、CRM、サポート、AI エージェント ログ を横断する構成です。

要点

• InfiniteWatch は顧客接点の signal を continuous stream として統合する AI-native platform を構築している
• Confluent は ingestion、buffering、replay、enrichment、routing の event backbone として使われている
• AI分析には、bursty で高頻度な interaction data を失わずに処理・再処理できる基盤が必要になる
• 顧客 intelligence は BI 後処理ではなく、operational ワークフロー を動かす real-time システム になりつつある

今回のブログ記事で語られていること

この記事は、顧客接点 data が複数 システム に分断されている問題から始まります。failed checkout、form error、サポート call、email thread、CRM update、AI エージェント interaction などは、それぞれ単体では孤立した event です。しかし横断してつなぐと、顧客の intent、friction point、operational risk、action opportunity が見えてきます。InfiniteWatch は、こうした interaction data を連続的に取り込み、AI analysis と operational ワークフロー に使う platform を作っており、その event backbone として Confluent を採用しています。

ブログでは、InfiniteWatch が Confluent for Startups から production へ進んだ流れと、reference architecture が説明されています。Capture、Stream、Enrich、Understand、Act という段階で、browser セッション、mobile アプリ、call platform、email、CRM、ticketing、AI エージェント などから event を取り込み、Confluent topic に source、顧客、event type で分けて publish します。その後、ストリーミング パイプライン が スキーマ normalize、account メタデータ 付与、journey ID correlation、privacy control、business context の join を行い、AI サービス が friction、intent、severity、repeated failure、エージェント quality、revenue risk を検出します。

Confluent が担う価値は、単に event を運ぶことではありません。traffic spike や サポート outage のような burst を吸収し、下流 AI サービス を独立に scale させること、重要 event を durable に保存して 再実行 や investigation に使えること、capture パイプライン と AI 推論 layer と storage を decouple すること、detection モデル が更新されたときに historical stream を replay できることが挙げられています。

これは 顧客 analytics の読み方を変えます。従来の BI では、顧客接点 data は後から分析する record でした。AI エージェント や 音声 システム、digital channel が業務 ワークフロー と結びつくと、interaction data は即時に action を駆動する operational stream になります。replayable intelligence と privacy control を持つ event layer がないと、AI分析は局所的な ダッシュボード や一回限りの バッチ に閉じてしまいます。

実務で確認したいポイント

1. 顧客 interaction event を source、顧客、journey、event type で整理できるか確認する
2. AI分析用 stream に privacy control と retention ポリシー を組み込む
3. モデル 改善時に historical event を replay できる構成を作る
4. insight を アラート / escalation / ワークフロー に戻す action path を監査可能にする

どう読むべきか

この事例は、AI 顧客 intelligence を real-time operational システム として作るには、event backbone が必要だという話です。サポート、growth、CX、product analytics を横断するチームには、BI パイプライン と ストリーミング operation の境界を見直すきっかけになります。