Google Cloud Data Loss Prevention（DLP）で Dialogflow CX 内の個人情報を秘匿化する方法

※この投稿は米国時間 2022 年 11 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

Data Loss Prevention（DLP）を使用した DialogFlow CX 内の機密情報の削除

今日のコンタクト センターは日常的な運用業務の一環として、個人を特定できる情報（PII）、保護医療情報（PHI）、支払いカード業界（PCI）データ、その他の機密情報（CI）など、あらゆるタイプの機密情報を取り扱っています。これらの情報の形態は、通話の録音、通話ログ、エージェント ノート、アプリケーション ログなどさまざまです。機密情報は、Google Dialogflow CX のような会話型 AI プラットフォームによって、受信した通話やチャットのルーティングやサービス トランザクションの自動化のために直接利用されることもあります。このようなデータは保護する必要があり、多くの場合は顧客や従業員を守るために、ログへ保存される前に秘匿化する必要があります。

個人を特定できる情報（PII）とは、直接的あるいは間接的にユーザーを特定する目的で使用できるデータです。トランザクションに関わる個人的な情報を断片的に集めて組み合わせることで、ユーザーの特定が可能な場合があります。特に氏名、生年月日、電話番号、住所、郵便番号、社会保障番号、社会保険の番号、さらにはその他の学歴などの明瞭および不明瞭な情報がその特定材料になります。

通話の発信者あるいは chatbot のユーザーが、Dialogflow CX 内に構築された仮想エージェントと会話を行う際、状況次第では、インタラクションのためにユーザーと仮想エージェントとの間で PII や機密情報のやり取りが必要になることがあります。通常、こうした情報は Dialogflow CX の会話アーキテクチャの次の要素に含まれます。

1. 会話中にエンドユーザーから取得したインテントまたはフォーム パラメータ。

2. Dialogflow CX API を呼び出すアップストリーム システムが設定したセッション パラメータ、Webhook による設定、またはルート、イベント ハンドラ、フォーム リプロンプトの設計の一部。

3. ダウンストリーム サービスとやり取りする Webhook が提供するペイロード データ。

理想的には、機密情報はソースにおいて識別、秘匿化され、ダウンストリームのログ、データ ウェアハウス、データレイク、分析、レポート システムへと伝播しないようにするべきです。以下に紹介する秘匿化アプローチは、Google Contact Center AI（CCAI）を導入する複数の大企業が本番環境で利用しているものです。

インテントとフォーム パラメータの秘匿化

インテントとフォーム パラメータでは、秘匿化は組み込まれています。インテント内のパラメータ セクションまたはコンソールのページ パラメータ設定で、[Redact in logs] のチェックボックスをオンにするだけで完了します。

セッション パラメータ、Webhook データ、レスポンス メッセージの秘匿化

セッション パラメータ、Webhook データ、フルフィルメント レスポンス メッセージを含む Dialogflow CX がログしたデータについては、秘匿化アプローチとして、Cloud Data Loss Prevention（DLP）検査テンプレートを使用する必要があります。

アップストリーム システムからのユーザーデータを用いて会話をパーソナライズする際、セッション パラメータがよく使用されます。たとえば、アップストリームのコンタクト センター プラットフォームが、CRM からユーザーのプロファイルを取得し、名前、ユーザー層データ、マーケット セグメント情報を Dialogflow CX へ渡すことがあります。次に、会話デザイナーはユーザー固有の要求事項に合わせるためにフローデザインを調整し、インテントのトレーニング フレーズ、エンティティの類義語、レスポンス（音声の長さ、音量、音程、速さなど）を変更することがあります。

同様に、Webhook データも、バックエンド システムに支えられた、ユーザーへの高度な動的レスポンスを可能にするため、会話デザインにおいて重要です。たとえば、ある顧客が新しいアパートへ引っ越す予定だとします。そこで、Dialogflow CX の仮想エージェントは、新住所を伝えるようにユーザーに頼みます。Webhook を使用して、取得した住所を Google マップの Places API などの外部サービスと照合し検証します。また、国名、郵便番号、都道府県名、市町村名のフィールドを API が自動入力する場合もあります。誤った住所取得を取得するとリスクが生じるため、仮想エージェントは確認のためにエンドユーザーに対して完全な住所を復唱します。

上述の例では両方とも、PII データは 1 つ以上のセッション パラメータ、Webhook ペイロードとして保存されます。さらに、ユーザーに対する確認のレスポンス メッセージもログに記録されます。このデータを識別、秘匿化する手段を講じないと、このデータは Google Cloud Logging（旧: Stackdriver）に到達し、ログストリームに登録しているリスナーへ届きます。

以下では、ダウンストリームのロギング システムへ到達する前に機密情報を秘匿化（ソース内秘匿化）するために、Cloud Data Loss Prevention 検査テンプレートを使用して Dialogflow CX のセキュリティ設定を構成する方法をご紹介します。これにより、機密情報はダウンストリームで利用できなくなり、かつ、仮想エージェントのデザインにおいては変わらず利用可能です。

主要コンポーネント

Data Loss Prevention（DLP）テンプレート

Google のソリューションでは、Google Cloud Data Loss Prevention（DLP）を使用します。これは、NLP とルールベースのメソッドを使用して、テキスト内の機密情報を識別、マスキング、難読化、匿名化、変換、トークン化できるサービスです。DLP を使用してすべてのログデータを Dialogflow CX のソースから秘匿化するには検査テンプレートという構成を作成します。これはドキュメント内の非構造化テキスト情報を識別、変換します。この場合、対象となるドキュメントは、セッション パラメータを含むログメッセージ、Webhook データ、フルフィルメント レスポンス メッセージ、その他のインタラクション データです。PII、PCI、PHI、CI を識別するには、事前トレーニング済みの機械学習モデル（組み込みの infoType）またはカスタム文字列検索（単語リストや正規表現）を使用するように構成を設定します。

音声合成マークアップ言語（SSML）

ここで紹介するソリューションは、音声合成マークアップ言語（SSML）を使用します。SSML について以下に簡単に説明します。

Text-to-Speech（TTS）システムを利用する際、最終的にシステムがユーザーへどのように話すのかを確認するのは困難です。ここで SSML が役立ちます。SSML は W3C 標準で XML タグを使用し、さまざまなポイントで TTS システムがどのようにフレーズを発話するべきかを記述します。音の高低、発音、音声速度、音量など、多くのプロパティを変更できます。たとえば、「555-6666」と書かれた電話番号がある場合に、「ごひゃくごじゅうご、マイナス、ろくせんろっぴゃくろくじゅうろく」ではなく、「ご、ご、ご、ろく、ろく、ろく、ろく」と発話する方が好ましいでしょう。次の SSML を TTS システムへ追加することで、このような詳細な指示を出すことができます。

<say-as interpret-as="telephone">555-6666</say-as>

Contact Center AI（CCAI）のセキュリティ設定

CCAI のセキュリティ設定を行うと、Dialogflow CX と Google Cloud Logging の間に DLP 検査テンプレートを適用できます。これにより、DLP システムは機密情報を Stackdriver へ公開される前に発見し、秘匿化できます。

ソリューション

要件に応じたセキュリティ設定は、Google Cloud コンソール経由、Google Cloud API の使用、Terraform の使用など、さまざまな方法で適用できます。

以下に、1）Google Cloud コンソールを使用した場合と 2）Terraform を使用した場合の 2 種類のアプローチの概要を示します。

重要な考慮事項

最初に、Dialogflow CX のログメッセージを使用する最初のダウンストリーム システムで DLP あるいは類するシステムを使用して機密情報を秘匿化する方法は一見明白ですが、欠点のあるソリューションです。たとえば、Cloud Storage バケット、BigQuery テーブル、Pub/Sub トピック、その他の送信先（Splunk など）へ向かうログシンクで、他のいかなる利用者がデータにアクセスする前に秘匿化が行われるとします。しかし、実際には、Cloud Logging 内のデータは容易に閲覧可能で、他のモニタリング アプリケーションへ伝播します。これによって、内外の者による作為あるいは無作為のプライバシー侵害のリスクが大きくなります。したがって、上述の方法はアンチパターンとして捉えてください。

2 点目に重要なことは、秘匿化ソリューションにおいて、PII データを含む機密情報はエンドユーザーへのレスポンスで使用できるように有効性を保つ必要があり、SSML との互換性を維持する必要があります。

手順 - Google Cloud コンソール

ここまで、要件事項と関係するすべてのコンポーネントについて説明しました。最初のステップでは、秘匿化するすべてのセッション パラメータと Webhook データに以下に示す SSML マークタグを返します。これは Webhook レベルで構成します。

<mark name="redact-start"/>123 Main Street<mark name="redact-end"/>

SSML W3C 仕様の予約済みタグであり、TTS システムによる音声出力を影響しないため、この SSML タグが使用されます。これにより、データが確実に Dialogflow CX エージェントによるレスポンス メッセージの中で使用できます。「name」属性は自由に決められます。使用する表記に合わせてください。

次に、DLP 検査テンプレートを定義し、カスタム infoType を参照します。以下に検査テンプレートを示します。

1. DLP テンプレートの作成

2. テンプレート ID と場所の定義

3. [infoType を管理] を選択して検出を構成

4. https://ccai.cloud.google.com から CCAI 内の [Create Security Settings] を開く。前のステップで作成した DLP 検査テンプレートを参照し、秘匿化戦略を選択

5. Dialogflow CX エージェント内で [Security Settings] を使用

手順 - Terraform

Terraform は、宣言型の構成ファイルを使用して Google Cloud リソースをプロビジョニングできるオープンソース ツールです。Terraform の Infrastructure-as-Code（IaC）アプローチは、チェンジ マネジメントにおける DevOps のベスト プラクティスです。クラウド サービス間の複雑な関係性を構成ファイルで定義し、ソース管理にチェックインできます。また、本番環境あるいは下位環境での理想的なプロビジョニング状態と比較したズレの識別、修正作業を支援できます。

上述の手順は、restapi_object リソースを作成することで、Terraform を使用して適用できます。この restapi_object Terraform リソースは DLP テンプレートを作成し、Dialogflow CX エージェントに適用します。以下は、Google Cloud プロバイダがすでに正しく構成されていることを前提としています。

まず、DLP 検査テンプレートを作成します。

次に、Dialogflow CX のセキュリティ設定を作成します。この投稿の執筆時点で、この目的の Terraform リソースは存在しません。よって、一般的なアプローチとして restapi_object を使用して作成します。プロバイダとリソース構成を宣言します。

次に、リソースを作成します。

最後に、dialogflow-cx-security-settings を dialogflow-cx agent に割り当て、上で行ったセキュリティ設定を参照します。

これらのステップが完了すると、以下のような概念的なデータのフローができます。

まとめ

このブログ投稿では、CCAI のセキュリティ設定と DLP を使用して機密情報を秘匿化する方法を説明しました。さらに、Google Cloud コンソールや Terraform で秘匿化を実現する方法も説明しました。上述のソリューションは Dialogflow CX 開発者にとって、容易に秘匿化が構成できる方法です。データは、セッション パラメータに適用される前に <mark name=”redact-start”/> タグと <mark name=”redact-end”/> タグで囲む必要があることに留意してください。会話デザイナーは TTS の音声出力に影響せず、想定通りパラメータを補間できます。さらに、会話のレスポンス内の機密情報ではない部分など、他のログデータは一切失われずに機密情報がログから秘匿化されます。

Deloitte は、Contact Center AI の Premier Partner です

この投稿は、Deloitte Canada の会話型 AI プラクティス担当者と Google Cloud の担当者により執筆されました。Deloitte は Google Cloud の Premier Partner で、2017 年から 2020 年まで 4 年連続で Google Cloud のグローバル サービス パートナー オブ ザ イヤーに選ばれ、2021 年にはグローバル業界ソリューション パートナー オブ ザ イヤーに選ばれました。

Deloitte は Contact Center AI（CCAI）の戦略、実装、運用におけるグローバル リーダーです。戦略、変換、アーキテクチャ、設計、ソフトウェア エンジニアリング、データ サイエンス、機械学習、分析、Cloud Ops、セキュリティの分野において総合的な専門知識を有しています。Deloitte は Google Cloud のパートナーとして、AI や自然言語処理（NLP）を用いて、お客様のデジタル チャネルの複雑な変革やサービス運用を実現します。

詳細

DLP をご自身で使ってみたいという方は、こちらのチュートリアルをご覧ください。また、投稿内でご紹介したアプローチに関する詳細にご関心をお持ちの場合や、Google Contact Center AI についてお問い合わせをご希望の場合は、Deloitte Canada または LinkedIn 経由で、この投稿の著者へご連絡ください。

この投稿にご協力いただいた Deloitte の会話型 AI アーキテクト、Miguel Mendez 氏に感謝いたします。

- Google、パートナー エンジニア Vijul Patel

- Deloitte、会話型 AI プラクティス リーダー Anand Nimkar 氏