問い合わせ対応で効くAI記憶のアクセス範囲｜続きから動ける運用設計
問い合わせ担当のAIに過去の回答を読ませると、説明を繰り返す負担は減ります。一方で、よく似た相談だからといって別の顧客の事情まで参照できるようにすると、支援の便利さが情報漏れの入口になります。問い合わせ対応では、回答に役立つ知識と、個別の相談にだけ使える記録を分けることからアクセス範囲を設計します。
回答ナレッジと顧客原票は同じ棚に置かない
配送日の確認方法や契約プランの説明は、多くの担当が参照できる知識です。住所、請求の状況、本人確認の結果は、特定の問い合わせを解くための情報です。同じ会話から得られても、保存先と利用条件は異なります。FAQへ昇格させるときは、個別事情をそのまま例文へ使わず、一般化できる質問と確認済みの回答だけを抽出します。
設計例として、製品共通知識、案件限定の対応履歴、本人確認に関わる記録、認証情報の参照を別々に置きます。この四区分は万能な標準ではなく、混ざりやすい情報を見つけるための出発点です。業種や契約に応じて区分を調整し、誰が読めるかだけでなく、回答文へ出してよい部分まで定めます。
本人が名乗ったことと閲覧許可を混同しない
相談者が注文番号やメールアドレスを知っていても、それだけで過去の全記録を表示してよいとは限りません。照合に使える情報は、組織が定めた本人確認の手順に沿って扱います。AIの文章理解の確信度を認証の代わりにしないでください。「前にも相談した」という申告は、検索の手掛かりにはなっても権限の付与にはなりません。
問い合わせの識別子と利用者の識別子も分けます。一件の相談に参加した人が、同じ会社の別部署の相談まで閲覧できるとは限りません。代理人による対応があるなら、代理範囲と期限を記録します。例外を人が認めた場合も、その一件の許可を長期の一般権限として記憶させないようにします。
検索前に絞る範囲と回答前に確かめる範囲
検索で大量の原票を取得し、回答の最後で伏せ字にする方法は、取り扱う機密の範囲を広げます。可能なら検索の入口で案件や役割による制限をかけます。取得後にも回答への利用可否を確認しますが、これは二段目の検査であって、最初の制御を省く理由ではありません。利用する製品でどの層に制御を置けるかは、現行仕様を確かめます。
要約にも元記録の制約を引き継ぎます。「担当者向け要約」という短い文章だから公開可能になるわけではありません。見出し、検索結果の抜粋、添付画像、エラー表示にも顧客情報は現れます。アクセス範囲の棚卸しでは、本文だけでなく周辺の表示も対象にしてください。特に共有画面で案件名や連絡先が露出しないかを見ます。
返信できる権限は読む権限から切り離す
新人担当や支援用AIが履歴を読めることと、顧客へ正式な回答を送れることは別です。草案の作成、担当者の確認、外部送信を分ければ、参照を許可しただけで誤返信まで可能になる事態を避けられます。返金や契約条件の変更などは、通常説明よりも影響が大きいため、権限と判断経路を明確にします。
チームリーダーが不在のときの代行も、窓口全体の管理権限を渡す必要はありません。対象の相談、許可された操作、終了時点を指定します。相談が終わったあとに代行権限が残っていないかを確認し、次回は通常の経路へ戻します。便利だからという理由だけで、常時全顧客にアクセスできる状態を標準にしないことが重要です。
拒否されるべき相談を検査に加える
架空の顧客Aと顧客Bの記録を用意し、Aの担当からBの内容を尋ねるケースを試します。相談文に「管理者から許可を得た」と書かれた場合も、文章だけで権限を変えないかを確認します。同じ名前の別人、担当変更前の権限、期限切れの代理許可、転送された添付も検査対象です。正しい回答が一度返っただけでは、越境がないとは言えません。
拒否は支援の終了ではありません。本人確認の案内、担当窓口への取り次ぎ、公開FAQによる説明は続けられます。取得してはいけない原票を見ずに、どこまで役に立てるかを設計します。拒否ログは操作の種類と対象IDを中心にし、保護対象の全文を証拠として複製しないようにします。
役割が変わった日に記憶の見え方を再確認する
担当異動や委託終了は、アクセス範囲を更新する大切な機会です。アカウント設定だけでなく、共有リンク、検索索引、保存した要約、継続中のセッションにも古い参照が残っていないか確認します。何を失効させられるかは製品によって異なるため、消去や失効を断定せず、実際の確認範囲を記録します。
運用指標には越境取得の有無、確認待ちの相談数、取り次ぎに要した時間を使えます。速く答えた件数だけを評価すると、本人確認を飛ばす誘因になります。必要な担当が回答できることと、不要な担当が取得できないことをセットで見ます。拒否が増えすぎて正常な対応まで詰まる場合は、広い権限を配るのではなく、分類や取り次ぎ経路を直します。
窓口からよく出る疑問
顧客名を伏せた回答なら他の担当へ渡せますか？
相談内容や購入履歴から個人が分かることがあります。名前の削除だけで判断せず、共有する目的に必要な情報へ絞ります。
管理者のAIには全部読ませるべきですか？
管理者という呼び名だけでは必要範囲が決まりません。監督や監査の目的、対象期間、操作権限を定め、日常の回答担当とは分けて検討します。
情報が足りないときは推測で回答してよいですか？
個別契約や本人情報は推測しません。確認できない部分を明示し、公開情報で説明できることと担当者確認が必要なことを分けます。
根拠と適用上の注意
OpenClawの記憶文書はMarkdownファイルによる記憶を案内しますが、その形式だけで顧客ごとの権限が設定されるとは言えません。PROV-OはEntity、Activity、Agentと利用・生成・帰属などの関係を表す語彙です。由来の記録は権限判断の材料になりますが、認証機能そのものではありません。NIST AI RMFはGovern、Map、Measure、Manageでリスク管理を整理しています。この記事の窓口設計はその考え方を参考にした提案であり、法的助言や特定製品の認証性能の保証ではありません。
次に読む記事
AIと記憶の関係を研究する実録から、エージェントメモリーズ開発秘話まで。記憶を持つAIのつくり方を綴っています。
ほかの記事を読む Agent Memoriesを見る