モデルの出力段階で対策が完了していると考えられていたAI駆動型サポートシステムが、CRMレコードをプロンプトに供給する「サイドドア」を通じて顧客データを漏洩させていた。開発者による事後分析（ポストモーテム）によれば、モデルが生成するテキストのみを保護するのでは不十分であることが示されている。受信リクエスト、内部ツールから取得されたデータ、そして最終的な出力のすべてに独立した保護策が必要である。さもなければ、モデルの出力における漏洩が発生していなくても、氏名、メールアドレス、IDなどの情報が露出してしまう可能性がある。

なぜ3つの境界が重要なのか

ほとんどの運用者は、言語モデルが学習・参照した機密情報を繰り返したときに漏洩が発生すると考えている。しかし実際には、最大の露出はモデルがデータを見る前に発生する。AIエージェントは、以下の3つの情報の流れを受け取る。

  • Ingress（入力） – 顧客が入力する生のクエリ。
  • Return path（リターンパス） – エージェントがCRMなどのダウンストリームシステムから取得する情報。
  • Emission（出力） – モデルがユーザーに返すテキスト。

これらの流れのいずれかに保護されていない識別子が含まれている場合、出力レイヤーでフィルタリングを行っていても、エージェントは意図せずそれらを回答に組み込んでしまう可能性がある。

デモから本番環境へ：苦い経験から得た教訓

プロトタイプを実際のヘルプデスクに導入した際、単純な「伏せ字にしてから送信する（redact-then-send）」というアプローチでは見逃されてしまう具体的な失敗が明らかになった。

  • 伏せ字ではなくトークン化を行う – モデルに届く前に名前やメールアドレスを削除してしまうと、システムが正しい回答を再構成できなくなる。元の値を安全な保管庫（vault）に保存し、プロンプト内ではランダムなUUIDに置き換え、モデルの処理が終わった後にそのUUIDを元の値に戻す。これにより、機能を維持したまま、生のデータをモデルのコンテキストから排除できる。

  • チェックサムで識別子を検証する – 正規表現はアカウント番号のように見える文字列を特定するが、チェックサムはその文字列が本物のIDであるかどうかを確認する。チェックサムフィルタを使用することで、エージェントが任意の数値を機密データとして扱ってしまうのを防ぎ、不要な伏せ字処理を引き起こす誤検知（false positives）を減らすことができる。

  • 重複するスパンを結合する – 顧客レコードには、名前の後にメールアドレスが続き、それらが一部の文字を共有していることがよくある（例：「John Doe john.doe@example.com」）。名前だけをトークン化すると、メールアドレスの断片がプレーンテキストとして残り、それがそのまま出力されてしまう可能性がある。重複している領域全体を単一のトークンとして扱うべきである。

  • 正しい境界をテストする – 出力（emission）レイヤーのみをチェックしてパスするテストは、誤った安心感を与える。リターンパス（return path）での漏洩を検知して失敗するテストこそが、修正を促す。3つの境界のそれぞれを明示的に検証するテストスイートを設計すること。

  • グラウンドトゥルース（正解データ）を追跡する – 人間が送信前にAIのドラフトを編集する場合、その時点でモデルはすでに誤った回答を生成している。AIのドラフトと、最終的に人間が承認したメッセージを比較することで、信頼性のギャップを明らかにし、システムが間違いを繰り返すように学習してしまうのを防ぐことができる。

ビジネスにおけるリスク

カスタマーサービスAIエージェントは、外部とのやり取りと内部データストアの交差点に位置している。

反論：なぜ依然として伏せ字（redaction）を支持する者がいるのか

まとめ

AIを活用したカスタマーサービスエージェントのセキュリティ確保は、単一の入り口の問題ではない。受信リクエスト、内部システムから取得されたデータ、そして出力テキストを、それぞれ独立した壁として扱うべきである。そのうちのどれか一つでも突破されれば、サービス全体が侵害される。機密フィールドのトークン化、識別子の検証、重複するスパンの結合、正しい境界のテスト、そしてAIのドラフトと最終的な人間によるメッセージの継続的な比較。これらこそが、「コパイロット」を信頼できるエージェント型サービスへと変えるための実践的なステップである。