コールセンターの生成AIをレッドチームで評価する|文字起こし・要約に潜むセキュリティリスク

はじめに

近年、コールセンターでも生成AIの活用が進んでいます。

例えば、

  • 通話内容の文字起こし
  • 通話内容の要約
  • 問い合わせ内容の分類
  • オペレーターへの回答支援

などです。

業務効率化が期待できる一方で、生成AIを業務フローに組み込むことで、新たなセキュリティリスクも発生します。

そこで本記事では、生成AIセキュリティのレッドチームという観点から、

「コールセンターの生成AIが実際に攻撃された場合、どのような問題が起こり得るのか?」

を考えてみます。


想定する構成

今回、以下のようなコールセンターを想定します。

一見すると単純な処理ですが、セキュリティの観点では重要なポイントがあります。

それは、

顧客の発話も、最終的にはLLMへの入力になる

ということです。

つまり、顧客が電話で悪意のある発話をすることで、間接的にLLMへ攻撃を仕掛けられる可能性があります。


レッドチームで何をするのか

AIレッドチームでは、攻撃者の視点から意図的に攻撃を行い、

  • どの攻撃が成功するか
  • どこで防御できるか
  • 攻撃の影響がどこまで広がるか
  • どのような対策が必要か

を検証します。

コールセンターの場合、LLMだけを見るのではなく、

という一連の業務フロー全体をAttack Surfaceとして考えることが重要です。


1. Prompt Injection

まず確認したいのがPrompt Injectionです。

例えば顧客が、電話中に次のような発話をしたとします。

これが文字起こしされると、

という形でLLMに渡ります。

本来、この文章は「顧客の発話」であり、LLMが実行すべき命令ではありません。

しかし、LLMが入力データと命令を適切に区別できなければ、Prompt Injectionにつながる可能性があります。

レッドチームで確認すること


2. System Prompt Leakage

次に、システムプロンプトの漏えいを確認します。

例えば、

のような入力を与えます。

直接的な要求だけではなく、言い換えや役割変更など、複数のパターンから内部情報が漏れないかを確認します。

ここで重要なのは、

「直接聞いたら拒否された」

だけで終わらないことです。

別の入力経路から内部情報が取得できないかまで確認します。


3. 個人情報の漏えい

コールセンターでは、通話内容に個人情報が含まれることがあります。

例えば、

  • 氏名
  • 電話番号
  • 住所
  • メールアドレス
  • 契約情報

などです。

レッドチームでは、例えば、

といった入力を行い、生成AIが不要な個人情報まで出力しないか確認します。

理想的には、

のように必要最小限の情報に留めたいところです。

しかし、

などがそのまま要約に含まれてしまうのであれば、情報漏えいリスクがあります。


4. 他の顧客情報が見えないか

さらに重要なのが、顧客間のデータ分離です。

もしLLMがCRMや過去の問い合わせ履歴などを参照している場合、

などの入力によって、別顧客の情報が出力されないか確認します。

特に、

という経路が存在する場合、セッション分離やアクセス制御が適切に実装されているかを確認する必要があります。

ここは単純なLLMの問題ではなく、RAG・データアクセス権限・アプリケーション設計の問題である可能性もあります。


5. 要約結果を改ざんできないか

コールセンターでは、機密情報だけでなく要約結果の正確性も重要です。

例えば実際の会話では、

と言っているにもかかわらず、

となってしまえば、業務上の大きな問題につながります。

そのためRed Teamでは、

のような入力を与え、要約結果を意図的に操作できないか確認します。

これは情報漏えいではなく、Integrity(完全性)の問題です。


6. CRMなどの業務システムまで攻撃できないか

さらに重要なのが、LLMの「その先」です。

例えば、

という構成だったとします。

もしLLMからCRM APIを直接呼び出せるのであれば、

という攻撃経路が成立しないかを確認する必要があります。

ここで重要なのは、

「LLMがその命令を理解できるか」ではなく、「その命令によって実際に何が実行されるか」

です。

例えばLLMがCRMの住所変更APIを呼び出せる設計なら、LLMの権限が過剰になっていないか、別途認可処理があるかを確認します。


7. RAGやナレッジ経由の攻撃

生成AIがFAQや社内ナレッジを参照している場合は、そこも攻撃対象になります。

例えばナレッジに、

のような悪意ある文章が混入していた場合、LLMがそれを命令として解釈しないかを確認します。

このように、攻撃者が直接LLMへ入力しなくても、外部データを経由してLLMを誘導する攻撃を考える必要があります。


8. レッドチームで何が可視化できるのか

最終的には、単純な「脆弱性一覧」ではなく、攻撃経路と業務影響を整理すると分かりやすくなります。

例えば、

攻撃 結果 リスク
Prompt Injection 一部成功 High
System Prompt Leakage 成功 Medium
個人情報漏えい 一部成功 Critical
他顧客情報へのアクセス 失敗 Low
要約改ざん 成功 High
CRM不正操作 成功 Critical
RAG Injection 成功 High

という形です。

これにより、

「生成AIは危険か?」

ではなく、

「どの攻撃が成功し、どこまで影響が広がるのか?」

を具体的に把握できます。


9. レッドチームの結果を対策につなげる

評価で終わらせず、結果をもとに対策を検討します。

例えば、

のように複数の防御レイヤーを設けます。

特に重要なのは、LLM自身にすべてのセキュリティ判断を任せないことです。

Prompt Injection対策だけでなく、

  • 個人情報の検知・マスキング
  • RAGのアクセス制御
  • API / Toolの権限制御
  • セッション分離
  • 出力内容の検証
  • Runtime Monitoring

などを組み合わせます。


10. まとめ

コールセンターで生成AIを利用する場合、

という一連の流れ全体がセキュリティ上の評価対象になります。

特に重要なのは、

顧客の発話そのものが、LLMへの攻撃入力になり得る

という点です。

生成AIレッドチームを実施することで、

  • Prompt Injectionが成立するか
  • 個人情報が漏えいしないか
  • 他顧客の情報にアクセスできないか
  • 要約結果を改ざんできないか
  • CRMなどの業務システムまで攻撃が到達しないか

を実際に検証できます。

そして、

というサイクルを回すことで、生成AIを利用するコールセンターのセキュリティを継続的に改善できます。

単に「生成AIは安全か?」を見るのではなく、

「攻撃者がこの業務フローを攻撃したら、最終的に何ができるのか?」

という視点で評価することが、生成AIを本番業務に組み込むうえで重要になります。

最後に

「現在のセキュリティツールが散乱している」
「新しいセキュリティ要件に対応できていない」
「セキュリティ運用コストを削減したい」

という方は、ぜひご相談ください。初回相談は無料です。貴社のセキュリティ環境を診断し、最適なソリューションをご提案させていただきます。

お問い合わせはこちら

この記事を書いた人

azure-recipe-user