今回参加したセッションは、「Birds of a Feather（BoF）」と呼ばれる形式のセッションでした。
BoF は、共通のテーマや関心を持つ参加者同士が集まり、課題や取り組みを共有しながらディスカッションを行う、参加者主導型のセッションです。

一般的な講演形式とは異なり、登壇者の発表を一方的に聞くのではなく、参加者同士で意見交換しながら議論を深めていく点が特徴です。

会場には画像のようにテーブルと椅子が用意されており、リラックスした雰囲気の中でセッションが進行していました。Google Cloud のエンジニアの方々がファシリテーションを担当し、全体の進行や参加者からの質問への回答を行っていました。

開始少し前に到着した時点では、会場にはまだそれほど人はいませんでしたが、セッション中は立ち見で参加する方が出るほど多くの参加者が集まっていました。

質疑応答では、初歩的な内容から実運用を前提とした高度な内容まで、さまざまなレベルの質問が挙がっていました。参加者が次々と質問を投げかけるだけでなく、参加者同士で意見交換や議論が行われていた点も印象的でした。

セッション内で議論されていた内容を簡単にまとめると、以下のようなポイントが挙げられます。

• LLM は非決定論的な性質を持つため、PII（個人識別情報）の検出やマスキングのように「漏れが許されない」用途には単独では適さない。
• SDP は動画や音声データには直接対応していないため、事前に文字起こしが必要。一方で画像には対応しており、運転免許証や身分証、スクリーンショット内のメールアドレスなど、画像に含まれる PII の検査やマスキングが可能。
• ただし、画像処理はコストが高くなりやすいため、利用時にはコスト面も考慮する必要がある。
• エージェントや MCP のようなツール連携を行う場合でも、モデルの前後にセキュリティレイヤを設ける設計が重要。例えば、入力データに対して SDP を利用し、出力時のガードレールとして Model Armor を利用する、といった構成が紹介されていた。

特に印象的だったのは、PII 保護においては曖昧さを許容せず、決定論的な仕組みで制御する必要がある、という点が繰り返し強調されていたことです。

また、SDP は与えられたテキストや定義済みパターンに基づいて処理を行う仕組みである、という説明を聞き、これまで期待したように検出できていなかった原因は、メールデータを前処理せず、そのまま利用していた点にあったのではないか、と気づきを得ることができました。

SDPは、InfoType detectorと呼ばれる仕組みに基づいて、機密情報を検出します。

InfoType detector では、正規表現やチェックサム、文脈分析、機械学習などを組み合わせることで、「どのようなパターンを機密情報として扱うか」を定義します。

つまり、SDP は「AI が自動ですべての機密情報を見つけ出す仕組み」というよりも、「定義されたルールや検出ロジックに基づいて機密情報を検出する仕組み」であると言えます。

この前提に立つと、検出結果は主に以下の 2 点に大きく依存することになります。

①どのようなInfoType（ルール）を定義しているか

②どのようなテキストを入力しているか

ここで改めてメールデータを見てみると、

・署名や引用返信が混在している

・HTMLや改行が崩れている

・同じ情報でも表記ゆれがある

といった特徴があり、機械的なパターンマッチングや文脈ベースの検出を行うには適していない状態でした。

入力データの重要性自体は当たり前の話ではありますが、SDP のような決定論的な仕組みでは、入力データの状態が検出精度に大きく影響することを改めて認識しました。

実際に、セッションでの気づきや学びを検証するため、メールデータに対して3つのパターンで処理を行い、PII検出結果を比較しました。

①生メールをそのままSDPにかける

②SDPの検出設定（InfoType）をチューニングする

③メールを正規化してからSDPにかける

今回の検証では実際の業務メールをイメージしながらも、「ノイズの多いテキスト」を再現するためAIに指示を行いデモデータを作成しました。

対象とするPIIは以下としました。

・氏名

・メールアドレス

・電話番号

・住所

・会社名

パターン①：生メールをそのままSDPにかける

まずは、前処理を一切行わず、そのままのメールデータをSDPに入力しました。

90%くらいは正常に匿名化されていたのですが、一部、電話番号や住所、氏名などが漏れていることが確認できました。

想定している電話番号の表記ではないことや、住所については都道府県や市町村、丁目などの表記もないことから検出が難しい状態になっているかと思います。

※実在する可能性のある電話番号と住所のため加工していますが、赤枠で囲った電話番号や住所の詳細がそのまま匿名化されずに残っていました。

パターン②：SDPの検出設定をチューニングする

パターン①で残ってしまった住所について、SDPの検出ロジックを見直すことで改善できないか試してみたいと思います。

SDPは、あらかじめ定義されたInfoTypeやカスタムルールに基づいて検出を行うため、標準のInfoTypeでカバーできないデータについては、自分で検出ルールを追加する必要があります。

今回漏れていた住所を漏れなく匿名化するために、地方っぽい部分＋数値部分を検出する正規表現を利用して、カスタムInfoTypeを追加します。

その後同様に、匿名化ジョブを実行するときちんと匿名化されていることが確認できました。

このような正規表現を用いると、誤検知が増えるのではないかと感じるかもしれません。
SDP では、起動ワードルール（Hotword Rule） によって特定の文脈が存在する場合のみ検出を強化したり、除外ルールや 調整ルールを設定したりすることができます。

これらの機能を組み合わせることで、検出精度と誤検知のバランスを調整することが可能です。

 
パターン③：メールを正規化してからSDPにかける

パターン②では、カスタム InfoType を作成し、ルールの調整が可能であることを確認できました。
一方で、電話番号については表記ゆれが多く、全角・半角の混在やハイフン有無など、すべてのパターンを正規表現だけで考慮するのは大きな手間になります。

そこで今回は、事前に正規化処理を行い、電話番号を 090-1234-5678 のような形式へ統一することにしました。

初回実行時には、先ほど作成したカスタムルールが電話番号にも反応してしまうことに気づきました。
そのため、除外ルールとして電話番号用の正規表現を設定したうえで再実行したところ、期待通りの結果が得られることを確認できました。

今回の検証を通じて感じたのは、PII の除去は単純な前処理ではなく、設計に近い作業であるという点でした。

当初は、Sensitive Data Protection（SDP）を利用すれば個人情報を自動的に除去できるのではないかと考えていました。しかし実際には、期待したように検出されないケースも多く、そのままでは十分に機能しない場面があることが分かりました。

その背景として、SDP は決定論的な仕組みであり、検出ルール（InfoType）と入力データの両方を適切に整備する必要がある、という点を理解することができました。

実際に検証を進める中で特に印象的だったのは、PII 除去は「どのような機密情報が含まれているか分からない状態」で実施するものではない、ということです。

あらかじめ、どのような機密情報が含まれているのか、その形式や表記ゆれの特徴を把握したうえで、検出・匿名化ルールや前処理を設計する必要があります。

また、単に検出ルールを増やすだけではなく、入力データの正規化やノイズ除去を含めて全体を設計することが、検出精度を高めるうえで重要であると感じました。

個人情報を含むメールデータには、社内や現場の暗黙知が多く含まれている一方で、今回触れたような課題も多く、活用の難しさを改めて実感しました。

AI 活用が当たり前になりつつある時代においても、「AI に安全に利用させるためのデータ準備」には、依然として決定論的なルール設計や人手による調整が必要である、という点は非常に興味深く感じました。