2026.09.03 / Agent Memories

問い合わせ対応で効くAI記憶の引き継ぎ｜続きから動ける運用設計

問い合わせ対応の引き継ぎで利用者を疲れさせるのは、担当者が変わること自体ではありません。「最初から説明してください」と言われることです。一方で、過去のやり取りを丸ごと次担当へ渡せばよいわけでもありません。個人情報や感情的なメモまで無制限に共有すると、別の危険が生まれます。

良い引き継ぎ記憶は、利用者の目的、確認済み事実、未解決点、約束した次の行動を分けます。受け手が同じ質問を繰り返さず、それでも推測で回答しないための設計を、サポート現場の一件のケースとして考えます。

会話要約ではなく「次の対応」を渡す

十往復の会話を三行へ縮めても、次に何をすべきか分からなければ引き継ぎになりません。要約の先頭には、利用者が最終的に望む状態を書きます。続いて、本人から得た事実、システムで確認した事実、担当者の推測を別々に置きます。最後に、次の担当が行う一手と回答期限を示します。

たとえば「請求を取り消してほしい」という希望と、「取消が完了した」という状態は違います。前者を受け付けただけなのに後者として記憶すると、次担当は確認を省いて誤案内します。状態語は受付済み、調査中、対応済み、利用者確認待ちのように限定し、変更した証拠へ結びます。

事実・希望・約束・推測にラベルを付ける

利用者の発言は重要ですが、すべてが検証済み事実ではありません。「昨日から使えない」は観測、「障害が原因だ」は仮説です。また「今日中に確認します」は担当側の約束で、製品仕様とは別物です。ラベルがない要約は、AIが四種類を同じ確度で扱う原因になります。

• 事実：画面、ログ、注文番号などで確認した内容
• 希望：利用者が望む解決と避けたい結果
• 約束：誰が、いつまでに、何を返すと伝えたか
• 推測：未確認の原因候補と、確認に必要な情報

推測は消すのではなく、未確認と明記して残します。次担当は仮説を利用できますが、利用者へ断定してはいけないと分かります。

引き継ぎカードをケース単位で作る

カードにはケースID、対象製品、現在状態、利用者の目的、確認済み事実、未確認事項、実行済み操作、次の一手、期限、担当、閲覧範囲を持たせます。実行済み操作は特に重要です。返金、メール送信、アカウント変更などを重複させないため、結果と受付番号を残します。

「次の一手」は一つに絞ります。複数候補を並べる場合は実行順と分岐条件を付けます。受け手がカードを読んだ後、対象ケースを特定し、完了済み操作を再実行せず、次の一手を説明できれば受領完了です。単に通知を送った時点では移管済みにしません。

由来を残して誤要約を訂正できるようにする

要約文の各主張が、利用者のどの発言、どのログ、どの担当操作から生まれたかをたどれると、誤りを直せます。W3C PROV-Oは、由来をEntity、Activity、Agentと生成・利用・帰属などの関係で表現するための語彙です。サポートカードでは、メッセージやログを材料、要約作業を活動、担当者やAIを関与者として結ぶ考え方が使えます。

すべての発言へ複雑なIDを振る必要はありません。重大な主張、金銭、本人確認、利用停止に関わる記述だけは、元メッセージ時刻や操作receiptを記載します。出典が追えない要約は確定扱いせず、再確認へ戻します。

個人情報を「念のため」で渡しすぎない

引き継ぎ先が必要とする範囲を先に決めます。本人確認書類、決済情報、健康情報などは、ケース要約へ複製せず、権限管理された保管先への参照に留めます。自由記述の内部感想は対応に必要かを問い、必要がなければ長期記憶へ昇格させません。

OpenClawのMemory overviewでは、長期の要点と日次の詳細を異なる記憶層へ置く構成が説明されています。サポートでも、全会話の保管と、次回対応に使う引き継ぎ記憶を同じものにしないことが大切です。訂正・削除・保存期限もカードの作成時に決めます。記憶へ入れない情報はAI記憶に残さないものも参考になります。

再開時の三分readbackを標準にする

受け手は最初の三分で、ケースID、利用者の目的、現在状態、次の約束、禁止されている重複操作を声に出すかチェック欄へ返します。元担当との一致を確認できない時は、システム状態を読み直します。利用者へ再質問するのは、内部記録で確認できない情報だけです。

改善指標は平均対応時間だけでは足りません。再説明を求めた回数、重複操作、約束時刻の超過、誤要約の訂正時間、閲覧範囲違反を測ります。FAQへ還元できる繰り返し質問は質問をFAQ資産に変える方法へ回し、個別事情は混ぜません。

リスクの大きさで人へ戻す線を引く

NIST AI RMFは、AIの設計・開発・利用・評価へ信頼性の考慮を組み込むための自発的な枠組みです。ここで参照するのは2023年公開のAI RMF 1.0です。NIST公式は1.0を現在改訂中と案内しているため、将来の改訂版と現行1.0の内容を混同しません。

サポートでは、金銭、アカウント停止、法的主張、本人確認、健康・安全に関わるケースを人の承認へ戻す線として設計できます。低リスクの情報案内は自動化しても、例外時の停止条件と引き継ぎ先を消さないことが重要です。リスクに応じた境界はAI運用の停止線を記憶するでも整理しています。

夜間や休日の引き継ぎでは、回答できない時間を隠さず、利用者へ次の連絡予定を示します。内部カードには営業時間だけでなく、緊急時の代替窓口、そこへ渡してよい情報、渡してはいけない情報を記します。すべてを緊急扱いにせず、生命・安全、進行中の不正利用、通常質問を別の経路へ分けます。

ケースが閉じた後は、個別情報をそのままFAQへ転用しません。複数ケースに共通する質問と確認済み回答だけを匿名化して抽出し、製品担当が一般化を確認します。個別の約束や例外対応はケース履歴へ残し、全利用者向けの標準回答に混ぜないことが重要です。FAQ公開後も元ケースへの逆引きは内部だけに限定します。

よくある質問

利用者との会話全文を次担当へ渡すのが最も正確では？

全文は確認材料として役立ちますが、次の一手や確定状態を自動で示しません。閲覧範囲も広がります。引き継ぎカードを入口にし、必要な時だけ権限の範囲で原文へ戻る二段構成が実用的です。

AIが作った要約をそのまま確定してよいですか？

低リスクの一般問い合わせでも、利用者の希望と対応済み状態の混同がないか確認します。金銭や権限変更を含む場合は、元記録と操作結果を人が照合してから確定します。AIの要約には作成時刻と参照範囲を残してください。

担当が戻ってくるなら引き継ぎ記憶は消せますか？

ケース終了、保存目的、契約や法令上の保持期間を確認して判断します。終了後は現行対応列から外し、必要なら制限された履歴へ移します。検索対象、派生インデックス、バックアップまで削除範囲を説明できない場合、完全削除済みとは表現しません。

引き継ぎ完了は利用者の体験で判定する

内部でカードが作られても、次担当が同じ質問を繰り返し、約束を見落とせば失敗です。まず一種類の問い合わせに限定し、カード作成、受領readback、利用者への次回答までを通して確認してください。引き継ぎの目的は情報をたくさん残すことではなく、必要な文脈を安全に渡し、利用者を会話の出発点へ戻さないことです。