コールセンターの個人情報マスキング検証、消したい項目と残る項目を分ける

通話の文字起こしを研修やVoC分析、生成AIへの入力に回すとき、手前に置くのが個人情報の自動マスキングです。先に本稿の結論を言うと、マスキング機能の評価は「消すべきものが残った（見逃し）」と「残すべきものまで消えた（過剰削除）」を別々に数えることに尽きます。この2つを混ぜて「正解率95%」のような1つの数字にすると、どちらの失敗がどれだけあるか見えなくなり、導入判断を誤ります。手順は4つ。対象項目と利用先を決め、架空データで検証セットを作り、2つの失敗を別集計し、失敗したログの扱いを先に決める。情シスや品質管理の担当者が半日から数日で回せる粒度で書きます。

対象項目と利用先を決める

最初に決めるのは「何を消すか」ではなく「どこで使うか」です。同じ文字起こしでも、社内の応対品質レビューに使うのか、VoC分析基盤に貯めるのか、外部の生成AIサービスに入力するのか、ベンダーに学習データとして渡すのかで、消すべき範囲が変わります。利用先ごとの線引きの考え方は個人情報を業務のどこまで使えるかの整理で、生成AIに渡す場合の規程の作り方は通話録音と生成AIの社内規程の記事で書いたので、本稿は機能の評価に絞ります。

消す項目のリストは、製品が対応するエンティティ（氏名・住所・電話番号・口座やカード番号・認証情報など）から自社で選びます。たとえばAmazon Connectのマスキング機能は、全エンティティを一括で消す設定と項目を選んで消す設定があり、置き換え文字を項目別にするか汎用にするかも選べます。音声は該当区間が無音になります。同じ公式ドキュメントが、この機能はHIPAA（米国の医療情報規制）の非識別化要件を満たさないと明記している点は示唆的で、ベンダーの「自動でマスキングします」は法的な匿名化の保証ではありません。

対応言語も製品ごとに違い、しかも動きます。同じAmazon Connectでも2025年9月に対応言語が7つ追加されたように、対象言語・対象項目・マスキング後のデータの保存先は、導入検討の時点で最新のドキュメントと営業担当への質問で確かめるものです。日本語の対応状況と対応エンティティの範囲は、本稿で一般論として断定せず、必ず製品ごとに確認してください。

ここで「残す項目」のリストも同時に作ります。品番、注文番号、エラーコード、プラン名。VoC分析で使うのはこちら側で、過剰削除の被害を受けるのもこちら側です。

架空データで検証セットを作る

検証に実際の顧客の通話を使うと、検証作業そのものが個人情報の目的外利用になりかねません。検証セットは架空データで作ります。架空の氏名・住所・電話番号・会員番号を台本に埋め込み、オペレーター役と顧客役で読み上げて録音するか、テキストで直接流します。

台本で意識するのは、現場の言い方のゆらぎです。電話番号を「090の、1234の」と区切って言う。氏名を言い直す。オペレーターが復唱する。住所を途中まで言って訂正する。名前の読みの説明（「ヤマサキではなく、濁るヤマザキです」のような言い直し）を挟む。マスキングの見逃しはこういうゆらぎの箇所で起きるので、1項目につき素直な言い方と崩れた言い方を混ぜて20〜30発話ほど用意します。同時に、残す項目（品番・注文番号）を含む発話も同じ比率で混ぜます。消す対象しか入っていない検証セットでは、過剰削除が測れません。

音声から入る場合はもう1つ手前に注意点があります。文字起こしが「09012345678」を誤認識すれば、マスキングは正しく動いても結果は漏れます。音声経由の検証では、文字起こしの誤りとマスキングの誤りを分けて記録しておくと、改善の依頼先（音声認識側かマスキング側か)を間違えません。

見逃しと過剰削除を別集計する

集計は2つの表に分けます。1つめは見逃しの表で、検証セットに埋めた「消すべき項目」の総数に対し、マスキング後に残っていた数。2つめは過剰削除の表で、「残すべき項目」の総数に対し、消されていた数です。

なぜ分けるか。2つはトレードオフの関係にあるからです。検出を厳しくすれば見逃しは減りますが、品番や注文番号が電話番号と誤認されて消える過剰削除が増えます。緩めれば逆になる。1つの正解率に混ぜると、この綱引きが数字から消えます。そして、どちらを優先するかは利用先で決まります。外部の生成AIに入力するデータなら見逃しゼロに寄せ、過剰削除は許容する。社内の品質レビュー用なら、文脈が壊れる過剰削除の方が実害が大きいこともあります。

合格ラインは製品カタログからではなく、利用先の被害から逆算して自社で置きます。ここが分かれ目です。「見逃し率◯%以下なら外部入力可」という基準は、どの製品を選ぶかより先に、自社の規程側で決めておく数字だと考えています。

失敗したログの扱いを定める

検証で精度が分かっても、本番の見逃しはゼロにはなりません。だから導入時には、失敗を前提にした運用を3つ決めておきます。

1つめは、マスキング前の原文の扱いです。マスキング後のテキストだけを下流に流すとして、原文（録音と生の文字起こし）を誰が・どこで・いつまで保持するか。マスキングは原文を消す仕組みではないので、原文側の保存期間と権限の設計が別に要ります。

2つめは、見逃しを見つけたときの経路です。利用者が下流データで個人情報を見つけたら、どこに報告し、誰が該当レコードを差し替え、同じパターンを検出辞書やルールに追加するか。報告の受け口がないと、見逃しは「見なかったこと」になります。

3つめは、再検証の時期です。マスキングのモデルや辞書は更新され、対応言語や項目も変わります。製品のアップデート時と、少なくとも年1回、同じ検証セットを流し直して精度の変化を記録する。検証セットを架空データで作ってあれば、再検証は流すだけで済みます。

まとめ

• マスキングの評価は「見逃し」と「過剰削除」の2表に分ける。1つの正解率に混ぜない

• 検証セットは架空データで、言い方のゆらぎと「残す項目」を必ず混ぜる

• 対応言語・対象項目・保存先は製品ごとに動くので、導入時点の最新ドキュメントで確認する

• 失敗前提の運用（原文の権限・報告経路・再検証）を導入時に決める

自社の規程には、「見逃しがどこまでなら、どの利用先に出せるか」の数字がもう書いてあるでしょうか。

音声データを現場の改善にどうつなぐかは、RevComm中村氏への取材記事で扱っています。無料会員登録で読めます。

よくある質問

マスキングすれば個人情報保護法上の匿名加工情報になりますか。 なりません。自動マスキングは漏えいリスクを下げる技術的な措置であり、法令上の匿名加工情報・仮名加工情報の要件を満たすかは別の検討が要ります。該当性の判断は専門家への相談をおすすめします。

検証セットは何件くらい必要ですか。 目安として、消す項目1種類につき20〜30発話、残す項目も同じ比率で用意すると、項目ごとの傾向が見える粒度になります。精密な統計値を出すためではなく、どの項目のどの言い方で失敗するかを特定するための件数です。

どの製品が一番精度が高いですか。 公開カタログの精度値は検証条件が揃っておらず、横並び比較はできません。本稿の手順で自社の検証セットを作り、候補製品に同じデータを流して比べるのが、現実的に唯一の比較方法です。

注記: 本稿は2026年10月16日時点の公開情報と、編集部の実務設計案によるものです。Amazon Connectに関する記述は同日時点の公式ドキュメントによります。法的な適法性の判断は行っておらず、個人情報の取り扱いに関する判断は専門家への相談を推奨します。本稿はAI著者によるデスクリサーチと設計案であり、特定製品の推奨ではありません。

出典

• AWS「Use sensitive data redaction to protect customer privacy using Contact Lens」

• AWS「Amazon Connect Contact Lens now provides sensitive data redaction in 7 additional languages」

この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。