Thunai社がAIエージェントとIBM® Confluentを使用してカスタマー・サポートを自動化する方法

サポート・チームは、同じ繰り返しの質問、断片化されたツール、高まる顧客の期待にさらされています。カスタマー・サービス・エージェントは、顧客が待っている間、顧客関係管理（CRM）システム、チケット発行、Eメール、チャット間を行き来し、多くの場合、チャネル間で同じ情報を繰り返します。バッチベースのシステムはAIにとってスケーラブルではありません。コンテキストは常に一歩遅れ、エスカレーションが積み重なり、時間内に介入することが困難になります。

Thunai社では、リアルタイムであらゆるやり取りを深く理解し、サポート・チームが既に使っているツール上で安全に対応できるエージェント型AIプラットフォームを構築しました。エージェント型AIプラットフォームのリーダーになることが私たちの使命です。これには、顧客とのライブ会話のキャプチャからCRMレコードの更新、ワークフローの自動化が含まれます。私たちは、カスタマー・サポートの自動化と強化に重点を置いて、顧客体験を向上させながらレベル1（L1）タスクの効率を最大化することを中核的な目標としています。

この使命を達成するために、単なる強力な大規模言語モデル（LLM）以上のものが必要でした。私たちはリアルタイムのデータ・ストリーミング・プラットフォームに依存し、AIエージェントに常に新鮮で信頼できるコンテキストを常に提供しています。だからこそ、私たちはConfluent for Startupsプログラムに参加しました。これはThunai社のような初期段階の企業が初日からデータ・ストリーミングを導入できるよう支援するものです。

トゥーナイ社では、データ品質や新鮮なコンテキストは「あったらいい」というものではなく、エージェント型AIにとって存在感のある要件です。このプラットフォームの中核となる約束は、やり取りの要約と理解だけでなく、ユーザーとサポート・チームに代わって行動できることです。

AIは、当社のオペレーションの中核です。会議、ユーザー・リクエスト、マルチチャネル・インタラクションの深いコンテキストの理解に基づいて、人々が既に使用しているツール全体で安全に動作するエージェントの自動化を推進しています。

当社のエージェント型AIプラットフォームは、以下の目的で設計されています。

• カスタマー・サポートを最適化するには、一般的な問題を解決し、L1タスク（基本的なトラブルシューティングやヘルプデスク・タスクなど）に最大限の回避を提供します。
• 定型的なやり取りを自動化し、ユーザーの意図を正確に解釈することで、人間の担当者の負担を大幅に軽減し、応答時間を改善します。
• 日常的なタスクをシームレスに自動化し、CRMやTo-Doリストなどのツール間で統合し、すべてのやり取りにリアルタイムで深くコンテキストを理解させることで、ユーザーの生産性を向上させます。

内部で、このアプローチはコンテキスト・エンジニアリングに依存しています。データ品質が悪いと、誤解、誤ったアクション、自動化の失敗、L1デフレクション率の低下につながり、私たちのビジネス目標全体が損なわれることになります。

そのため、リアルタイムの会議記録、CRMの更新、ユーザー・インタラクションをストリーミング・コンテキストとして扱い、夜間のバッチではなく、イベントとしてキャプチャし、強化し、Thunai社のAI脳が利用できるようにする必要があります。Thunai社は継続的に以下について処理と分析を行っています、

顧客とのライブ会話（音声、チャット、Eメール、WhatsAppなど）

• 通話からのリアルタイム文字起こし
• CRMおよびチケット発行システムからのイベント
• ツール間のユーザー・アクションとワークフロー・イベント

このプロセスすべてが、すべての生成AIとエージェントの意思決定を強化する、継続的に更新されるナレッジ・ベースであるThunai Brainに流れ込んでいます。データ・ストリーミングとは、静的な知識ベースをすべてのやり取りにおける生きた記録システムへと変えるものです。

IBM® Confluentは、Thunai社のAI製品にとって最も重要な高品質で新鮮なコンテキストを提供します。なぜなら、IBMの中核機能であるエージェント型自動化とL1タスク・デフレクションは、ユーザーの状況と意図を正確かつリアルタイムで理解することに全面的に依存しているからです。

IBM® Confluentをデータ・ストリーミングプラットフォームとして採用する前は、ビジネス上の課題と技術的な課題が重なって、カスタマー・サポートにおけるエージェント型AIのビジョンを実現することが困難でした。

• バッチ処理への依存により、意思決定が遅くなり、事後対応的なものとなっていました。データが届く頃には、行動する時は過ぎてしまっていました。
• データはCRM、エンタープライズ・リソース・プランニング（ERP）、ロジスティクス、サポートツールに分散していたため、ワークフローがサイロ化され、カスタマージャーニーを統一的かつリアルタイムで把握することができませんでした。
• エージェントはシステム間の切り替えに時間を費やしており、これにより運用効率が大幅に低下し、コンテキスト切り替え疲労が生じていました。
• リアルタイムの洞察が欠如しているため、遅延、エスカレーション、顧客の不満の増大などの問題を事前に検知できませんでした。
• チャネル間で情報に一貫性がなく、同期が取れていなかったため、顧客体験に問題が生じていました。
• 顧客とのやり取りが増えると、特にアクティビティの急増時に、古いアーキテクチャーにおける拡張性の制約が露呈しました。
• リアルタイムのコンテキストが限られていたため、エスカレーションの優先順位付けが難しく、緊急の問題と日常的なノイズを区別することが困難でした。

技術面では、バッチ指向のパイプラインとレガシー統合アプローチはリアルタイムAIには適していませんでした。

• 既存のシステムでは、呼び出し、ログ、ユーザーのアクションから得られる高スループットのワークロードを取り込んで処理するのに苦労していました。
• バッチ・パイプラインは高遅延をもたらし、リアルタイムのAI分析を事実上不可能にしていました。
• リアルタイムの文字起こし、センチメント分析、キーワード検知はすべて、レガシー・インフラストラクチャーでは対応できなかった低遅延のストリーミングが必要でした。
• Thunai社のナレッジ・保管はバッチ・ワークフローで継続的に更新できなかったため、AIが古いコンテキストの上で推論していました。
• 従来のETLツールには、音声ストリームやログストリームに必要な耐障害性、順序保証、および耐久性が欠けていました。
• 私たちのインフラストラクチャーでは、品質が低下しない限り、通話やイベント、エージェントのワークフローによるトラフィックの急増に確実に対応することはできませんでした。
• モデル再トレーニング、デバッグ、エラー回復のためにイベント再生と再処理が必要でしたが、バッチシステムはこのパターン向けに構築されていませんでした。
• 複数のシステム（ERP、CRM、在庫など）を接続する統一された方法が欠けていた：既存の統合方法は脆弱で、進化が困難でした。

私たちの主な目標は、最大のL1タスク分散とシームレスなエージェント自動化ですが、AI固有の課題にも対応する必要がありました。

1. 文脈の誤解（ハルシネーション・リスク）：当社のエージェントは、CRMの更新やToDoistタスクの作成などのアクションを実行する可能性があります。これを正しく実行できるかどうかは、会議やユーザーのクエリから得られる深くリアルタイムのコンテキストを正確に理解できるかどうかにかかっています。微妙なニュアンスを誤解すると、自動化されたアクションにつながり、潜在的に有害なアクションを起こす可能性があります。
2. アクションの失敗とロールバック：サードパーティー製ツール間でアクションを自動化するには、堅牢な統合が必要です。実行の失敗、APIのダウンタイム、またはデータの形式が正しくないと、ワークフローが中断され、エクスペリエンスが低下する可能性があります。トランザクションの整合性と、アクションを安全にロールバックできる機能を確保することは、複雑ですが、クリティカルな要件です。

これらの複合的な圧力により、Thunai Brainを継続的に更新し、データ損失を最小限に抑え、リアルタイムで安全なエージェント・アクションを支援できるストリーミング優先のアーキテクチャーが必要であることが明らかになりました。

リファレンス・アーキテクチャーの概要は次のとおりです。

このアーキテクチャーは、音声、チャット、Eメール、CRMイベント、接続されたアプリケーションでのユーザー・アクションにわたるライブの顧客との会話から始まります。

Confluentクラウド内では、Apache Kafkaのトピックがイベントをタイプ別に整理します。図には、通話記録、新たに特定された問題、ネット・プロモーター・スコア（NPS）データのトピックが示されており、楕円はより多くのイベント・タイプを表しています。この構造により、ソース・システムがダウンストリーム・サービスから分離され、生産者と消費者が独立して運用し、拡張できるようになります。

120を超える事前構築済みのコネクターが外部システムをデータ・ストリームに統合し、ストリーム処理で移動中のイベントを変換・強化します。ストリーム・ガバナンスにより、一貫したデータ定義と品質管理が実施されます。Confluentは、エンタープライズ・セキュリティー、耐久性のあるイベント・ストレージ、フルマネージドのクラウドネイティブ・サービスも提供します。イベントは変更不可能なため、復旧、デバッグ、または再処理のために再生できます。

次に、アーキテクチャーはストリームを3つのパスに分割します。1つ目では、文字起こしされた音声がベクトル埋め込み（意味の数値表現）に変換され、MongoDBに保管されます。MongoDBは、検索拡張生成（RAG）のベクトル・データベースとして機能します。受信したトランスクリプトを処理することで、最近の会話をリアルタイムのセマンティック検索で利用できるようになります。

2番目のパスでは、Confluentはリアルタイムのコンテキストと強化されたデータをThunaiのエージェントに送信します。エージェントはMongoDBから関連するナレッジを取得し、大規模言語モデル（LLM）とリクエストと応答を交換します。各コンポーネントにはそれぞれ次のような役割があります。MongoDBは関連するコンテキストを提供し、LLMは言語を解釈・生成し、Thunaiのエージェントはワークフローとアクションを調整します。

その組み合わせたコンテキストに基づいて、エージェントはCRMレコードを更新し、サポート・チケットを作成し、アラートをトリガーすることができます。楕円はその他の関連するアクションを表します。これにより、生成された応答で停止するのではなく、顧客とのやり取りデータが運用ワークフローに変換されます。

3番目のパスでは、Kafkaイベントをアーカイブとモデル・トレーニングのためにGoogleクラウド・ストレージ・バケットに送信します。履歴ストレージを低遅延のエージェント・パスから分離することで、現在のイベントがライブ・サポート・ワークフローを強化している間、後で分析やAI開発のためにデータを保持することができます。3つのパスを組み合わせることで、即時の意思決定、セマンティックな検索、および長期的なモデル改善のために耐久性のあるEvent Streamsを再利用します。

音声を書き起こし、結果として得られるテキストをベクトル化し、ナレッジ・インフラストラクチャーの一部としてMongoDB Vector DBを使用してこれらの埋め込みを保管します。また、このストリーミング・コンテキストとベクトル化された知識に加えて、Gemini 2.5 Flash、Claude Sonnet、DeepSeek（研究用）を含む複数のLLMに依存しています。

エージェント型AIプラットフォームのリアルタイムかつコンテキスト認識機能を強化するために、データ・ストリーミングのプラットフォームとしてIBM® Confluentを採用しました。私たちはこれを使用して、Thunai Brainとサポート・システムに供給されるストリームを取り込んでいます。

IBM® Confluent のデータ・ストリーミング・プラットフォームのいくつかの側面は、当社にとって重要でした。

複数のツールとチャネルにわたる音声通話、ログ、ユーザー・アクションからのライブ・データを処理する必要がありました。IBM® Confluentはリアルタイム取り込みを提供します。これは、これらのストリームに適用するライブ・トランスクリプション、リアルタイムのセンチメント、およびキーワード分析にクリティカルです。

私たちはIBM® Confluentを使用して、通話中にライブ・トランスクリプトをナレッジ・ベースであるThunai Brainにストリーミングすることで、エージェントが生成されたコンテキストを確認し、それに基づいて行動できるようにしています。このアプローチにより、必要に応じて人間のエージェント向けに、リアルタイムのエージェント支援、提案と推奨アクション、感情に配慮したエスカレーションキューをサポートできるようになります。

IBM® Confluentの高スループットとフォールト・トレランスは、音声データの急増、ユーザー・イベントと対話量のバースト、および実稼働サポート環境の高可用性要件に対処するのに役立ちます。

私たちは、Thunai Brainを継続的に更新されるナレッジ・ベースとして扱い、処理済みデータが定期的な負荷でバッチ処理されるのではなく、リアルタイムでストリーミングされます。この方法により、AIが継続的に学習し、最新の状態に保たれるため、正確なL1回避と信頼性の高い自動化を実現できます。

IBM® Confluentにはスキーマ管理とガバナンス機能も備わっています。これにより、消費者、コンプライアンス、安全なデータ処理を損なうことなく、データ品質とスキーマの進化を保証します。

IBM® Confluentのフルマネージド型Apache KafkaおよびApache Flinkサービス、そして Confluent Intelligence機能が、私たちに次の道筋を提供します。

• リアルタイムで状況認識型のAI
• イベント駆動型ストリーミング・エージェントとリアルタイム・モデル推論
• 個別のシステムの統合を回避する簡素化されたアーキテクチャー

現在、私たちはIBM® Confluentを主要のストリーミング・プラットフォームとして使用しており、エージェントはナレッジ・ベースであるThunai Brainからのリアルタイム・データに基づいて行動しています。

データソース・システムはプロデューサーとして機能し、Kafkaトピックにインタラクション・イベントを継続的に公開します。一方、Thunai社のエージェントはこれらのイベントをリアルタイムで利用します。消費されたデータはベクトル埋め込みとして正規化、強化、保管され、バッチ処理なしでナレッジ・ベースが継続的に更新されます。

データ・ストリーミングにより、Thunai社は複数の主要な生成AIおよびエージェント型AIのユースケースを構築してきました。

レベル1のサポート問い合わせのほとんどは、人間の担当者ではなくThunaiによってエンドツーエンドで自動化されており、顧客の回避率は約70～80%に達しています。Thunai社のAIはThunai Brainを活用して、以前のやり取り、ドキュメンテーション、リアルタイム・イベントからの最新の知識に基づいて、文脈を考慮した応答を生成します。WhatsApp、Eメール、音声、チャットなどのチャネルでも同じロジックが機能し、コンテキストの一貫性を維持します。

ライブ通話中、ストリーミング・データを使用してトランスクリプトを生成し、感情を検知し、エスカレーション・リスクをリアルタイムで特定します。その後、エージェントは、静的なFAQではなくストリーミングのナレッジ・ベースを活用した提案、手がかり、ナレッジ・スニペットを使用して、次善のアクションのガイダンス・チームを提供します。

リアルタイムのイベント・ストリーミングは、チケットのバックログ、サービス・レベル契約（SLA）違反、問題の急増に対応するためのダッシュボードを強化します。Thunaiはチャネル全体のインタラクションのタイムライン全体を追跡し、より適切な優先順位付けと根本原因分析を可能にしています。イベントは、課金および使用量測定のために消費に関連付けられており、すべてストリーミング層によって実現されます。

カスタマー・サポート以外にも、Thunaiは同じアーキテクチャーを使用して、会議への参加やアクションアイテムの要約など、専門的な生産性ワークフローを自動化しています。

これらのエクスペリエンスはリアルタイムのストリーミング・データに基づいているため、Thunaiは高い自信を持って行動し、ハルシネーション・リスクを最小限に抑えることができます。

IBM® Confluentを採用し、リアルタイムでコンテキスト化された信頼できるデータ・ストリーム上にThunai BrainエージェントとAIエージェントを構築することで、Thunai社は顧客とエンジニアリング・チームの両方にとって有意義な利益を実現しました。

Thunaiを支えるストリーミング・ファーストのアーキテクチャーにより、以下が可能になりました。

• 私たちは、ほとんどのL1問い合わせを人間のオペレーターに転送する代わりに自動化することができ、お客様に対して約70～80％の問い合わせ転送率を達成しています。
• AIが古いデータではなくライブ・コンテキストに基づいて動作するため、多くのケースでは、解決時間が数時間から数分へと大幅に短縮されました。
• 全体として、このアーキテクチャーにより、ユーザーはチャネル間でタイムリーかつ一貫性のある応答を受け取ることができるようになり、顧客体験が向上しました。

技術面では、次のことがわかりました。

• Kafkaのキューイング動作により、データ損失を最小限に抑えます。エラーが発生した場合、メッセージを失うことなく処理を安全に停止でき、必要に応じて再開または再生できます。
• より堅固なエラー処理モデルで、キュー・システムによって、問題となるイベントがチェックされずに下流へ伝播するのを防ぎます。

これらの改善により、適切な安全策を講じたユーザーに代わって、CRMの更新や自動タスク作成などのエージェント・アクションを、Thunaiに実行させることに、私たちは自信を持てるようになりました。

IBM® Confluentとエージェントを導入することで、ゼロから再構築することなく、時間をかけてより高度なストリーミングとAI機能へと拡張するための強力な基盤が手に入りました。

その結果、エージェント型AIが単なるオーバーレイではなく、リアルタイムの顧客とのやり取りや運用ワークフローの構造に深く統合されたプラットフォームが実現しました。

IBM® Confluentはこちら