Confluent のロゴ

Confluent / 公式ブログ / 2026/05/15 / 通常

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

AIdatabi

公式ブログ原文

Confluent は 2026年5月15日、InfiniteWatch が Confluent を event backbone として使い、customer interaction data を real-time intelligence に変える事例を公開しました。web、call、email、CRM、support、AI agent log を横断する構成です。

要点

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

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

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

ブログでは、InfiniteWatch が Confluent for Startups から production へ進んだ流れと、reference architecture が説明されています。Capture、Stream、Enrich、Understand、Act という段階で、browser session、mobile app、call platform、email、CRM、ticketing、AI agent などから event を取り込み、Confluent topic に source、customer、event type で分けて publish します。その後、streaming pipeline が schema normalize、account metadata 付与、journey ID correlation、privacy control、business context の join を行い、AI service が friction、intent、severity、repeated failure、agent quality、revenue risk を検出します。

Confluent が担う価値は、単に event を運ぶことではありません。traffic spike や support outage のような burst を吸収し、下流 AI service を独立に scale させること、重要 event を durable に保存して retry や investigation に使えること、capture pipeline と AI inference layer と storage を decouple すること、detection model が更新されたときに historical stream を replay できることが挙げられています。

これは customer analytics の読み方を変えます。従来の BI では、顧客接点 data は後から分析する record でした。AI agent や voice system、digital channel が業務 workflow と結びつくと、interaction data は即時に action を駆動する operational stream になります。replayable intelligence と privacy control を持つ event layer がないと、AI分析は局所的な dashboard や一回限りの batch に閉じてしまいます。

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

  1. customer interaction event を source、customer、journey、event type で整理できるか確認する
  2. AI分析用 stream に privacy control と retention policy を組み込む
  3. model 改善時に historical event を replay できる構成を作る
  4. insight を alert / escalation / workflow に戻す action path を監査可能にする

どう読むべきか

この事例は、AI customer intelligence を real-time operational system として作るには、event backbone が必要だという話です。support、growth、CX、product analytics を横断するチームには、BI pipeline と streaming operation の境界を見直すきっかけになります。