Dialogは、顧客とのやり取りを一度きりの取引ではなく、継続する関係として捉え直します。従来のチャットボットは、通常セッション単位で動作していました。会話が終了すると、実際のアクションに使える記憶も失われていました。Dialogは会話履歴、好み、未完了のタスクといった関係性に基づく文脈を保持し、成果につながる作業を未完了のタスクとして扱います。そのため、顧客に代わってエージェントが作業を続け、人やシステムと連携しながら解決まで進められます。CXリーダーにとっては、複雑な成果を1つのチャット画面に押し込むのではなく、時間やチャネルをまたいで作業が継続するフローを設計することが重要になります。

Dialogの運用エンジンは、永続的なデータインデックス、管理対象のエージェントオーケストレーション、エンタープライズ向けコネクターを組み合わせています。Webexのスペース、CRMの記録、過去のやり取りから文脈を統合し、ClaudeとWebexのエージェントプラットフォームで構築された管理対象エージェントに提供します。長期実行により、エージェントはチケットの作成、訪問修理の予約、承認依頼など複数段階のプロセスを開始し、その進捗を監視できます。オブザーバビリティ用のフックが各アクションを記録し、ポリシー制御によってエージェントがアクセスまたは変更できる範囲を制限します。このアーキテクチャが重要なのは、会話の理解と、永続的なタスクの実行を分離し、システムをまたぐ信頼性の高い自動化を可能にするためです。

カスタマーサポート、フィールドサービス、プロダクト運用、ITの各チームにメリットが期待できます。サポート部門では手作業による引き継ぎが減り、解決までの時間が短縮されます。フィールドオペレーションでは、スケジュール調整や確認の自動化が可能です。プロダクトチームは、エージェントが定型的な修正を実行できるよう、フィーチャーフラグを活用できます。一方で、組織側にも対応が必要です。従業員の役割は例外対応やエージェントの監督へと移り、SREチームやセキュリティチームはコネクターとIDを管理し、ナレッジ管理の担当者はドキュメントが適切にインデックス化され、最新の状態であることを保つ必要があります。成功を左右するのは、モデルの精度だけでなく、オーケストレーションです。

Dialogの導入は、段階的なプロダクト展開として進めましょう。まずは、家電修理やサブスクリプションの返金など、手順が予測しやすく、効果の大きいワークフローを1つ選びます。完了率、解決までの時間、フォローアップに対する顧客満足度など、明確な成功指標を定め、エージェントの各アクションにテレメトリーを設定します。請求や個人情報（PII）に関わるアクションには承認プロセスを導入してください。Webexの管理対象エージェントでアクションの試作を行い、Splunkで稼働状況をリアルタイムに可視化します。最後に、ステータスの更新、完了までの見込み時間、人間の担当者へ簡単に相談できる手段など、顧客向けのUX表示を設計し、自動処理の進捗を透明で信頼できるものにしましょう。

永続的に動作するエージェントは、気づかれにくい自動化エラー、文脈のずれ、機密システムへの過剰な介入といった新たな障害リスクをもたらします。こうしたリスクを抑えるには、厳格なデータアクセス方針、判断を再現できるログ記録、機密性の高い操作に対する人間の承認基準が必要です。安全策には、バックグラウンド作業に対する顧客の同意、未完了タスクの有効期限、エージェントの判断に対する定期監査を含めるべきです。オブザーバビリティも欠かせません。チームはエージェントの判断を追跡し、意図しない変更を元に戻し、パフォーマンスデータに基づいて動作を再学習できなければなりません。こうした制御がなければ、永続的なエージェントは運用リスクを減らすどころか、増幅させる可能性があります。