【ITニュース解説】RecallDesk: Giving Customer Support Conversations a Long-Term Memory

企業がITシステムを運用する上で、サポートチームとのやり取りは非常に重要だ。しかし、従来のサポートシステムにはいくつかの課題があった。例えば、大規模なシステム障害が発生した場合、顧客は自身のシステムの構成や過去のトラブルシューティング履歴を、シフトごとに異なる担当者に対して何度も説明しなければならないというフラストレーションを感じることが多かった。これは、サポート担当者が過去の文脈を把握できていないために生じる。過去に解決したはずの証明書関連の問題が再発した際、アカウントが使用しているKubernetesのバージョンや、以前に試みて失敗に終わった対策について、顧客が毎回詳細に伝える必要があるのだ。

一般的なヘルプデスクでは、個々の問い合わせは独立したイベントとして扱われる。一つの問題が解決されれば、その診断履歴はデータベースにアーカイブされ、その後の別のインシデント発生時には、新しい担当者が膨大な過去の記録を掘り起こす時間がないのが実情だ。このような断片的なサポート体制は、顧客がサポート側の記憶の代わりを務めなければならない「顧客側の繰り返し説明の疲弊」、過去の経緯を知らない担当者がゼロから調査を始める「担当者の文脈不足」、そして過去に失敗したと分かっている解決策を再度試してしまう「既知の行き詰まりの再試行」という、三つの主要な問題を引き起こしていた。これらの問題を解決するには、単に会話の記録を検索可能にするだけでなく、会話から得られた情報を永続的で構造化された「記憶」として保持することが求められる。

RecallDeskは、このようなサポートワークフローにおける会話履歴の扱いに変革をもたらす。単なる受動的なメッセージログに頼ったり、人が手動で古いチケットを検索する手間をかけたりする代わりに、顧客ごとのアクティブな会話記憶を中心にシステムが構築されている。ここで重要なのは、「チャット履歴」と「会話記憶」は根本的に異なるという点だ。チャット履歴は、単にメッセージを時系列に並べたものであり、挨拶や誤字脱字、無関係な会話の断片も含まれるため、情報量が多すぎて本質を見つけるのが難しい。一方、会話記憶は、この生のチャット履歴から重要な事実、技術的な制約、診断における決定、そして検証された結果といった情報を抽出し、要約したものだ。例えば、30往復の会話から「顧客がどんなシステムを動かしていたか、何が壊れたか、何を試して何がうまくいき、何が失敗したか」という簡潔な知識に凝縮される。RecallDeskでは、会話が行われると、バックエンドがそのやり取りをクリーンアップし、構造化してから永続的な記憶バンクに保存する。そして、担当者が新しい会話を開くと、この記憶バンクから顧客の現在の問題に関連する事実のみを抽出して提供する。

特に、ミッションクリティカルなサポートにおいては、「何がうまくいかなかったか」という「ネガティブな知識」が、「何がうまくいったか」と同じくらい価値を持つ。例えば、エッジプロキシで双方向TLS（mTLS: Mutually Authenticated Transport Layer Security）認証が失敗している障害が発生した場合、あるエンジニアがTLSプロトコルバージョンのダウングレードを提案するかもしれない。しかし、もし二ヶ月前に別のエンジニアがまったく同じダウングレードを試み、それが中間CA（認証局）の検証をバイパスできなかったと記録していれば、この「失敗した経験」を事前に知ることで、緊急性の高いインシデント中に無駄なテストに何時間も費やすことを避けられる。RecallDeskは、成功した解決策だけでなく、失敗した試みも明確に追跡し、記憶ストア内で診断結果を「うまくいったこと」「失敗したこと」「環境の状況」という具体的なカテゴリに分類して保存する。これにより、サポートチームは過去の誤りを繰り返すことなく、より効率的に問題解決に取り組めるようになる。

このような記憶の文脈は、特定の顧客アカウントを中心に整理されている場合に最も効果的だ。同じ顧客からの異なるチケットID、サポートチャネル、担当者間でのやり取りであっても、それらが一つの連続した履歴として統合されることで、より深い洞察が得られる。RecallDeskは、この目的のために顧客エンティティタグを使用して記憶操作を整理する。システムがやり取りを保存したり、コンテキストを問い合わせたりする際、そのリクエストを顧客のIDと関連付けるためのメタデータタグを付与する。これにより、「customer:顧客ID」といったタグを使って、現在の顧客に関連する記憶だけを効率的に検索し、抽出することが可能となる。

具体的な例として、EnvoyというプロキシサービスでのmTLS証明書ローテーションのインシデントを考えてみよう。ある顧客のエンジニアが、証明書の更新後にエッジプロキシがクライアント証明書を拒否しているという緊急チケットを開いた。従来のシステムであれば、担当者はまずKubernetesのバージョン、プロキシの設定、証明書生成プロセスなど、基本的な情報を顧客に尋ねるところから始めるだろう。しかしRecallDeskでは、担当者がチケットを選択するとすぐに、バックエンドが顧客IDとチケットの件名を使って記憶バンクを検索し、関連する文脈を「記憶インテリジェンスパネル」に表示する。そこには、顧客の環境（AWS EKS v1.29、Envoy Ingress Gateway、HashiCorp Vault）、過去の調査（以前、Vaultエージェントが完全な証明書チェーンではなく、単一のリーフ証明書を出力し、完全なチェーンを参照するように変更して解決したこと）、そして過去に失敗した試み（TLSプロトコルバージョンのダウングレードが中間CA検証をバイパスできなかったこと）といった情報が含まれる。この歴史的文脈があるため、担当者は基本的な質問を繰り返したり、過去に失敗した解決策を推奨したりすることなく、すぐに「Envoy v1.28以降では、証明書のチェーンはfullchain.pemにバンドルされている必要がある」という具体的なアドバイスを返せる。顧客がConfigMapを修正し、証明書のパスを更新すると、問題は数分で解決した。このように、チームが過去の経験を記憶することで、何時間もかかったかもしれない調査が短時間で解決するのだ。

会話の記憶は、その保持パイプラインの品質に依存する。生の会話を保存すると、一時的な認証情報や内部のチャット、機密情報などで記憶バンクが汚染されるリスクがあるため、RecallDeskではメッセージの送受信やチケットのステータス変更時に、三段階の構造化された保持パイプラインを実装している。まず、機密情報（ベアラートークン、パスワード、APIキー、秘密鍵、セッションクッキーなど）を正規表現で検出し、無害な文字列に置き換える「機密情報のリダクション」が行われる。次に、断片的なチャットメッセージをそのまま保存するのではなく、やり取りを顧客名、ID、会社、環境、チケット番号、件名、カテゴリ、優先度、ステータス、解決結果、そして詳細なトラブルシューティングログといった情報を含む統一された「サポートインタラクション記録」に統合する「構造化された知識の統合」が行われる。最後に、この記録は「cust_顧客ID_conv_会話ID」のような決定論的な文書IDと、「customer:顧客ID」「conv:会話ID」「status:ステータス」「tier:ティア」といった構造化されたタグを付けてインデックス化され、保存される「決定論的なインデックス化とタグ付け」が行われる。チケットのステータスが「解決済み」に更新されると、その解決結果も再インデックスされ、将来の検索で最終的な検証済みの解決策が確実に取得されるようにしている。

RecallDeskの重要な設計思想は、記憶をユーザーにどのように提示するかという点にある。AIエージェントが自動的に返信を作成・送信するのではなく、人間がプロセスに関与する「ヒューマン・イン・ザ・ループ」アーキテクチャを採用している。ユーザーインターフェースでは、現在の顧客との会話スレッドが表示されるアクティブな会話スレッド、アカウントのティアや残りSLA（サービスレベル合意）期間、環境メタデータなどの情報が表示される顧客コンテキストとSLA、そして「うまくいったこと」や「失敗したこと」を含む過去のトラブルシューティング履歴が表示される記憶インテリジェンスパネルが分かれている。この設計により、サポート担当者は常に完全にコントロールを維持できる。記憶サブシステムは賢いコパイロットとして機能し、関連する過去の解決策を提示しながら、担当者が顧客の現在のインシデントに対して判断を下すことを支援する。

現在のRecallDeskの実装にはいくつかの制約がある。運用上の顧客プロファイル、チケットキュー、ライブ会話スレッドなどのデータは、現在、外部のデータベースではなくインメモリのモックリポジトリで管理されている。また、大規模言語モデルによる自動応答生成機能は現在スタンバイモードで、記憶コンテキストは人間のサポートエンジニアを支援するにとどまり、自動的なAI応答を送信することはない。さらに、外部の記憶サービスにアクセスできない場合、システムは過去の記憶を偽造することなくスタンバイ状態を報告し、ユーザーインターフェースはクリーンにローカルのアカウントメタデータにフォールバックする仕組みになっている。

結論として、技術的な顧客サポートは、ドキュメントの不足に悩むのではなく、「記憶の欠如」に苦しんでいると言える。あるエンジニアが検証した解決策は、次のエンジニアには簡単に忘れ去られ、顧客は先月すでに答えたはずの質問に、貴重な障害発生時に再度答えなければならない。RecallDeskは、サポートの会話に永続的で顧客スコープの記憶レイヤーを提供することで、個々のチケットスレッドと長期的な技術的文脈との間のギャップを埋める。何がうまくいったか、そして同じくらい重要なことだが、何が失敗したかを記憶することで、サポートチームは受動的な対応者から、複雑なインフラ問題をより迅速に解決する、情報に基づいたパートナーへと変貌するのだ。