顧客対応の履歴をAIに読ませる時の権限と匿名化：見せてよい範囲を先に決める

先に答え：AIは権限を広げないが、広すぎる権限はそのまま映し出す

問い合わせ履歴や対応記録をAIで検索・要約すると、似た事例や過去の解決策をすぐに探せます。一方で、顧客の名前や電話番号が入った記録を、閲覧権限のない人がAI経由で目にしてしまう事態は避けなければなりません。

Microsoftの公式文書によると、Microsoft Copilotが要約・参照できるのは、使う人がもともとアクセスを許されている内容に限られます。AIが新しく閲覧権限を与えるわけではありません。ただし裏を返すと、共有設定が広すぎる場所は、AIを通じて見つけやすくなります。これまでは「誰も探しに行かなかったので表に出なかった」だけの記録も、質問ひとつで答えの材料になり得ます。

そのため、順番は二つです。まず、誰がどの履歴を開けるかを正しく整えます。次に、開ける人に対しても見せなくてよい項目を伏せるか、AIに渡さないようにします。この記事では、この二段構えの考え方を、顧客対応の履歴に絞って整理します。

公式文書で確かめたこと：参照範囲・ラベル・検索対象

今回取得できたのは、Microsoft Learnにある2つの文書です。1つはCopilotのデータ保護と監査の仕組みの解説、もう1つは導入時の安全対策と管理の基本方針です。以下は、その内容を自分の言葉でまとめたものです。製品ごとに仕様は異なるため、ほかのAIサービスにもそのまま当てはまるとは限りません。

1つ目の文書は、AIに見せる範囲をどう絞れるかについて、次のような点を挙げています。まず、暗号化された内容をCopilotが扱うには、使う人に閲覧と抽出の利用権限が必要です。次に、秘密度ラベルの付いた資料をもとに新しい文章を作った場合、対応していれば、元の資料のうち最も優先度の高いラベルが引き継がれます。さらに、SharePointやOneDrive側の設定でも範囲を絞れます。具体的には、検索や発見の設定でCopilotや全社検索に出てくるサイトを限ることや、共有とメンバーの管理、秘密度ラベルとDLP（情報漏えい防止）の条件に応じてCopilotのアクセスを制限することです。

2つ目の文書は、導入の柱として三つを示しています。過剰な共有の是正、ガードレールの設定、規制への対応です。リスクの高いサイトやファイルを特定し、必要に応じて一時的にアクセスを制限してから直す、という管理者の進め方も示されています。顧客対応の履歴に当てはめると、「AIを入れる前に、受付記録の置き場所の共有範囲を棚卸しする」ことが最初の作業になります。

保存と監査：AIとのやりとりはどこに残るか

見落とされやすいのが、AIに質問した内容や答えそのものの行方です。顧客の名前を入れて質問すれば、その質問文にも個人情報が含まれます。

Microsoftの文書では、Copilotとのやりとりのデータは、Microsoft 365のサービスの中に保存されます。そして、Microsoft Purviewの機能で探す、監査する、保持することができます。記録できるものとして挙げられているのは、質問・回答・参照した内容の監査記録、電子情報開示や調査のためのやりとりのデータなどです。保持と削除は、組織で設定した保持ポリシーに従います。

ここから言えるのは、「何日残るか」は製品が一律に決めるのではなく、自社の設定次第の部分があるということです。導入前に、保持ポリシーをどう設定するか、監査記録を誰が見るかを決めておく必要があります。監査記録を見る管理者も、顧客の情報に触れる立場になります。その人を誰にするかも、権限設計の一部として扱ってください。

なお、企画段階ではOpenAIの企業向けプライバシーの説明も確認対象でした。しかし今回は原文を取得できなかったため、保存期間や管理者の閲覧範囲についての記述は保留します。ほかのサービスを使う場合は、契約プランごとの公式文書で同じ観点を確かめてください。

項目ごとに「残す・伏せる・渡さない」を決める

権限を整えたら、次は記録の中身です。対応の質を上げたいなら、AIに必要なのは「誰が」より「何が起きて、どう解決したか」です。この視点で項目を三つに分けると、判断がぶれにくくなります。

迷ったときは「この項目がなくても、AIは対応のヒントを返せるか」と問います。返せるなら伏せるか、渡さない側に寄せます。答えの質に直結する項目だけを残す、という順番で考えるのが安全です。

伏せ方の違い：黒塗り・記号・仮の名前・幅でくくる

個人情報を伏せる方法は一つではありません。何に使いたいかで選び方が変わります。ここでは業界で一般的に使われる考え方を整理します。特定の製品の機能説明ではありません。

黒塗り（削除）は、該当部分を消すか「＊＊＊」などで塗りつぶす方法です。最も単純で、元に戻せません。記号での置き換えは、「［電話番号］」のように種類だけを示す印に置き換えます。文の意味は保たれるので、AIが要約しても不自然になりにくい方法です。

仮の名前への置き換えは、「顧客A-0123」のような番号や仮名を振る方法です。同じ人には毎回同じ仮名を振るので、「この顧客は過去に3回同じ症状で問い合わせている」といったつながりを追えます。ただし、元の名前との対応表が社内に残る場合、その対応表自体が重要な管理対象になります。仮名にした記録をどこまで個人情報として扱うかは、社内の個人情報担当や法務に確認してください。

幅でくくる方法は、年齢を「40代」に、住所を市区町村までに、日付を「月単位」にするといったやり方です。細かさを落としても、傾向の分析には十分使える場合が多くあります。日付は、記録ごとに一定の日数だけずらす方法もあります。これなら前後関係を保ったまま、正確な日付を隠せます。

なお、企画段階ではGoogle Cloudの機密データ保護の資料も確認対象でした。しかし今回は原文を取得できなかったため、その製品の具体的な機能名や仕様には触れていません。

判断の目安：導入前に決める5つのこと

ここまでの内容を、導入前のチェックとしてまとめます。上から順に決めていくと、後で設定をやり直す手間が減ります。

• ①権限：AIは使う人の閲覧権限の範囲で答えます。全社公開のリンク、異動者の権限の消し忘れ、親フォルダから引き継がれた広い共有が残っていないかを確かめます。AIに見せたくない場所は、検索・参照の対象から外します。
• ②項目ごとの扱い：対応の質に効く項目（内容・原因・解決策・型番）は残します。氏名・電話番号・メールアドレス・住所は伏せるか置き換えます。カード番号や健康情報など、なくても答えられる項目は渡しません。
• ③伏せ方の選択：同じ顧客の履歴をつなげる必要があるなら、同じ人に同じ仮名を振ります。不要なら黒塗りか記号で十分です。年齢や日付は、幅でくくるかずらして使います。
• ④保存と監査：質問と回答がどこに何日残るか、管理者が閲覧・削除できるか、監査記録を取れるかを、契約プランの公式文書で確かめます。監査を見る担当者も決めます。
• ⑤少人数で試す：一つのチームで試し、伏せ漏れの件数を数えてから広げます。広げる条件（例：伏せ漏れが一定期間ゼロ）を先に決めておくと、判断が感覚頼みになりません。

仮例：ハルカゼ電機サービスの修理受付記録

架空の家電修理会社「ハルカゼ電機サービス」（従業員60名）の仮例です。実在の会社や実績ではありません。過去3年分の修理受付の記録をAIで検索し、似た故障の対処法をすぐ引けるようにしたいと考えました。

最初に置き場所の権限を確かめると、受付フォルダが全社公開になっていて、営業部からも開ける状態でした。このままAIを入れると、営業担当が質問したときにも受付記録が答えの材料になり得ます。そこで、サポート課だけが開ける設定に直しました。

次に、AIに読ませる記録を作り直します。氏名と電話番号は「顧客A-0123」のような番号に置き換え、同じ人には同じ番号を振りました。再修理の履歴をつなげて見たいからです。住所は市区町村までに短くし、症状・型番・対処内容はそのまま残しました。支払い情報の列は、AIに渡す記録から外しました。番号と実名の対応表は、AIの参照対象とは別の場所で、限られた担当者だけが開けるようにします。

試しに一つの班が1か月使い、伏せ漏れが見つかった記録を数える計画です。たとえば、自由記述の欄に顧客が自分で電話番号を書いていた、といったケースです。その結果を見て、全体に広げるかどうかを決めます。自由記述の欄は決まった列より伏せ漏れが起きやすいため、試行では特に注意して見る対象にしています。

使い始める前に自社で確かめること

今回の内容のうち、製品の仕様として確かめられたのは、取得できたMicrosoft Learnの2文書の範囲だけです。ほかのAIサービスや匿名化ツールを使う場合は、同じ観点で各社の公式文書を確認してください。観点は、参照範囲が使う人の権限に従うか、質問と回答の保存先と保持期間、管理者の閲覧・削除、監査記録の4つです。

顧客対応の履歴は、対応の質を上げる材料として価値があります。その分、個人情報も多く含みます。「誰が開けるか」を先に整え、「何を残し、何を伏せ、何を渡さないか」を項目ごとに決めてから、小さく試す。この順番を守ることが、AI経由の思わぬ閲覧を防ぐいちばん確実な方法です。