2026.09.16 / Agent Memories

問い合わせ対応で効くAI記憶の正本管理｜続きから動ける運用設計

問い合わせ対応で最も困るのは、回答文が書けないことより「どの情報が今も正しいか」を判断できないことです。過去メール、FAQ、担当者メモ、製品画面に少しずつ違う説明があると、AIは検索で見つけた古い文をもっともらしく返します。速い回答でも、料金、利用条件、復旧手順が古ければ顧客価値を損ないます。

問い合わせ対応の正本管理では、すべての情報を一ファイルへ集めるのではなく、質問の種類ごとに「現在の答えを決める場所」を一つにします。回答履歴は事例、正本は現在の判断です。この区別を保ちながら、AIが安全に下書きを作り、人が必要な境界だけ確認できる運用を設計します。

最初に問い合わせを答えの種類へ分ける

同じ顧客対応でも、製品仕様、契約・料金、障害状況、個別アカウント、使い方では正本が異なります。FAQを唯一の正本と決めると、障害中の最新状況や個別契約を誤って一般化します。質問を分類し、各分類の正本、更新責任者、確認方法を対応表にします。

たとえば操作方法は公開ヘルプ、料金は契約・価格表、障害はstatusとincident Current、個別事情は顧客記録を参照します。AIは回答前に分類を示し、複数分類にまたがる時は情報を混ぜずに確認します。分類不能な問い合わせを過去回答へ無理に合わせないことも停止線です。

正本には対象範囲と版を付ける

ファイル名が「最新版」でも、それだけでは安全ではありません。対象プラン、地域、アプリ版、適用開始日、更新責任者を持たせます。旧プランの顧客へ現行プランの制限を答えたり、ベータ機能を全利用者向けに案内したりする事故を防ぐためです。

AIへは正本の全文コピーではなく、参照先と確認時刻を渡します。作業開始時と送信直前で版が変わった場合は再読込し、古い下書きをそのまま送信しません。正本が二つ見つかった時は更新日時だけで選ばず、適用範囲と決定者を確認して競合として扱います。

過去の回答は「事例」として保存する

うまく解決したメールは有用ですが、現在の仕様を決める資料ではありません。事例には質問の要約、参照した正本の版、回答、解決確認、個別条件を残します。個人情報は必要最小限にし、FAQ候補へ戻す時は匿名化します。

AIが似た問い合わせを検索した場合、事例の文章をコピーする前に現行正本との差を確認します。過去には手動対応した例でも、今はセルフサービス化されているかもしれません。事例は説明の仕方を学ぶ材料、正本は答えの内容を決める材料として役割を分けます。

回答下書きへ根拠と確信度を添える

顧客へ送る本文に内部URLを並べる必要はありませんが、確認者がたどれる根拠欄は必要です。主張ごとに正本名、該当節、確認日を持たせます。画面観測しかない場合は「確認済み画面」、推測は「仮説」として、公式仕様と同じ欄へ混ぜません。

確信度が低い時に、自然な文章で穴を埋めるのが最も危険です。料金、返金、個人情報、security、アカウント変更は人へ戻す条件を決めます。一方、正本に明記された一般的な操作案内は自動下書きへ進め、すべてを包括的な承認待ちにしないことで応答速度も守れます。

訂正は回答と正本へ二方向で反映する

顧客から「画面が違う」と指摘された時、そのメールだけ直して終えると再発します。まず対象顧客への訂正を行い、次に正本が古いのか、回答生成が正本を誤読したのか、個別条件の確認漏れかを分けます。正本が古ければ更新責任者へ戻し、検索索引やFAQの反映も確認します。

影響範囲も調べます。同じ版の回答を受けた件数、公開FAQ、テンプレートを列挙し、必要な対象だけ修正します。訂正済みという状態には、顧客への到達、正本更新、派生物更新、次回回答で旧文が出ない負例確認を含めます。

障害時は状況正本を短く更新する

障害中の長いチャットは数分で古くなります。現状、影響範囲、回避策、次回更新時刻、未確認事項を一つのCurrentへ集約し、回答担当はそこだけを参照します。「復旧見込み」は確定時刻と仮の目安を区別し、未確認の原因を断定しません。

復旧後も、サービスが動いたことだけで問い合わせ対応を閉じません。滞留した依頼、二重処理、誤案内した顧客、回避策の撤回を確認します。恒久対策の完了を待って顧客への応急回答を遅らせず、復旧と再発防止を別phaseとして追います。

正本運用を確認するチェック

1. 問い合わせ分類ごとの正本と更新責任者が一意か。
2. 対象プラン、版、地域、適用期間が明記されているか。
3. 過去回答を現行仕様として再利用していないか。
4. 送信直前に正本の版と顧客条件を照合したか。
5. 訂正が顧客、FAQ、索引、テンプレートへ届いたか。
6. 別プランや期限切れ情報が拒否される負例を試したか。

一次資料と適用境界

OpenClawのMemory文書は、利用者が確認・編集できるMarkdown記憶を案内しています。回答根拠を人が訂正可能な場所へ置く考え方に使えます。W3C PROV-Oは、回答、参照資料、対応活動、担当者の由来をEntity、Activity、Agentの関係で表現する語彙を定義しています。

NIST AI Risk Management Frameworkは、Govern、Map、Measure、ManageとしてAIリスク管理を整理しています。本記事はAI RMF 1.0を参照し、NISTが進める改訂の内容を先取りしません。ここで示すのは運用設計であり、契約や法的判断、特定製品の内部仕様を断定するものではありません。

よくある質問

FAQを一つ作れば正本になりますか？

質問の種類によります。操作案内には向きますが、個別契約や進行中障害の正本を兼ねると古くなりやすいため、分類ごとの参照先を持ちます。

AIへ過去メールを全部読ませてもよいですか？

個人情報、契約差、古い仕様が混ざります。必要範囲と保持目的を決め、匿名化した事例と現行正本を分離してください。

正本が見つからない時はどう答えますか？

過去回答から推測で確定せず、確認中であることと次の連絡時点を示します。内部では欠落を記録し、更新責任者と作成条件を固定します。

あわせて整えたい記憶

正本と履歴の違いはAIに「正本はこれ」を教える、問い合わせを再利用可能な知識へ変える方法は質問をFAQへ戻すAI記憶、保存範囲を絞る考え方はAI記憶に入れない情報も参考になります。速いサポートは、AIが何でも覚えることではなく、今の答えを決める場所へ迷わず到達できることで実現します。