Databricks Certified Generative AI Engineer Associate 教科書
第6章 ガバナンス(Governance, 8%)
🎯 この節の学習目標
生成AIアプリケーションは、社内文書やユーザーの入力といった「生のテキスト」を大量に扱います。その中にはPII(Personally Identifiable Information:個人識別情報)が含まれていることが少なくありません。代表例は次のとおりです。
PIIを含むテキストをそのままLLMアプリケーションに流すと、次のような問題が起こり得ます。
これらを防ぐ基本手段が、PIIを検出して隠すマスキング(masking)です。ガバナンス(第6章)の中でも、試験で最も具体的なシナリオとして問われやすいテーマです。
RAGアプリケーションを例にとると、PIIがシステムに入り込む経路は大きく2つあります。両方に対策が必要である点が重要です。
| 経路 | PIIの入り口 | 対策のタイミング | 対策しない場合のリスク |
|---|---|---|---|
| ① インデックス作成時(データ準備) | ソース文書(問い合わせ履歴、契約書、議事録など)に含まれるPII | チャンク化・埋め込み(ベクトル化)の前に除去/マスクする | PIIがDatabricks AI Search(旧 Vector Search)インデックスに取り込まれ、検索結果として誰にでも返されてしまう |
| ② 推論時(オンライン) | ユーザーがプロンプトに入力するPII(「私の電話番号は090-…ですが」など) | LLM(特に外部モデル)へ送信する前にマスクする | PIIが外部モデル提供者へ送信され、ログや(規約次第では)学習データに残る可能性 |
①はバッチ的なデータパイプラインの中で行う処理、②はリクエストごとにリアルタイムで行う処理です。①を怠ると「インデックスに入ってしまったPIIは検索で何度でも露出する」という継続的なリスクになり、②を怠ると「1回の入力がそのまま外部に出る」リスクになります。
💼 例:カスタマーサポートRAGボット
過去の問い合わせメールをナレッジとして索引化し、外部のプロプライエタリLLMで回答を生成するボットを考えます。
[NAME]・[ADDRESS] のようなプレースホルダーに置換してから埋め込みを計算する。PIIを保護するには、まず「どこにPIIがあるか」を検出し、次にそれをどう隠すかを決めます。検出手法は精度・コスト・柔軟性のトレードオフで選びます。
| 検出手法 | 仕組み | 得意なもの | 限界 |
|---|---|---|---|
| 正規表現(ルールベース) | パターンマッチ(電話番号、メールアドレス、カード番号など形式が決まったもの) | 形式が固定的なPII。高速・低コスト・決定的 | 氏名や住所など形式が不定なPIIは検出できない |
| NERベースの検出 | 固有表現抽出(Named Entity Recognition)モデルで人名・地名・組織名などを識別。Presidio などのオープンソースライブラリが正規表現とNERを組み合わせて提供 | 氏名・住所など文脈依存のPII。バッチ処理に組み込みやすい | 言語・ドメインによって精度が変動。モデルの実行コスト |
| LLMによる検出 | LLMに「このテキストからPIIを見つけてマスクせよ」と指示する | 文脈理解が必要な複雑なケース、多様なPIIタイプ | コストとレイテンシが高い。出力が非決定的で、検出漏れの保証が難しい |
検出したPIIの処理方式にも選択肢があります。
[EMAIL]・***-****-1234 のようにプレースホルダーや伏せ字に置き換える。文の構造を保てるため、LLMの理解を妨げにくい最も一般的な方式です。CUSTOMER_0042)に置き換え、対応表は安全な場所に保管する。後段で本人向けに元の値へ戻す必要がある業務フローで使います。📝 試験のポイント
「外部のLLM(サードパーティAPI)に顧客データを送る前に何をすべきか」というシナリオでは、PIIのマスキング(検出と秘匿)が正解の軸になります。また「ソース文書のPIIをどの段階で処理すべきか」と問われたら、チャンク化・埋め込みの前(インデックスに入る前)が答えです。インデックス作成後に消しても、既に埋め込みに情報が反映されている可能性がある点に注意してください。
Databricks プラットフォーム上では、自前の前処理コードに加えて、次の機能をガバナンスの部品として使えます。
| 機能 | 保護の対象 | 概要 |
|---|---|---|
| Unity AI Gateway のガードレール(4-4) | 推論時のリクエスト/レスポンス | Model Serving エンドポイントに設定でき、PII検出を有効化すると入力・出力に含まれるPIIを検知してブロックまたはマスクできる。アプリのコードを変えずにエンドポイント側で一律に適用できるのが利点 |
| Unity Catalog のカラムマスク | 構造化データ(テーブルの列) | 権限のないユーザーがクエリしたとき、特定列(電話番号、メール等)の値をマスクして返す。RAGのソーステーブル段階での保護に使える |
| Unity Catalog の行フィルタ | 構造化データ(テーブルの行) | ユーザーの属性に応じて見える行を制限する(例:自部門の顧客レコードのみ) |
| 前処理パイプライン(自前実装) | インデックス作成時の文書 | 正規表現・Presidio 等のNERライブラリ・LLMをノートブック/ジョブに組み込み、チャンク化前にPIIを除去する |
整理すると、構造化データはUCのカラムマスク・行フィルタで、非構造化文書はインデックス作成前の前処理で、推論時の入出力はUnity AI Gatewayのガードレールで守る、という役割分担になります。
Databricks の External Models 機能(Unity AI Gateway 経由)で OpenAI や Anthropic などの外部APIを呼び出す構成では、プロンプトに含めたデータがDatabricks ワークスペースの外にあるプロバイダーへ送信されます。次の観点を確認・対策してください。
💼 例:金融機関のドキュメント要約
顧客との面談記録を要約するアプリで、規制上、顧客個人情報を国外のサービスへ送信できないとします。取り得る構成は2つです。①要約に外部モデルを使うが、送信前にNERベースの前処理で氏名・口座番号等を完全にマスクする。②そもそも外部送信をなくすため、Databricks 内でサービングされるオープンなLLMを使う。リスク許容度と品質要件に応じて選択します。
✅ この節のまとめ
問1. ある企業が、顧客の問い合わせ内容を外部のプロプライエタリLLM APIに送信して回答草案を生成するアプリを構築している。問い合わせには顧客の氏名や電話番号が含まれることがある。コンプライアンス要件を満たすために、生成AIエンジニアが行うべき対策として最も適切なのはどれか。
正解:A
外部モデルにデータを送る構成では、送信前のPIIマスキングが基本の対策です。Bの temperature は出力のランダム性の制御であり、プライバシー保護とは無関係です。Cは送信後の処理であり、PIIは既に外部へ出てしまっています。DのBase64は単なるエンコードであって暗号化でも秘匿でもなく、誰でも即座にデコードできるため保護になりません。
問2. RAGアプリケーションのソース文書(過去のサポートメール)に顧客のPIIが含まれている。AI Search インデックス経由でPIIが露出するのを防ぐには、どの段階でPIIを処理すべきか。
正解:B
PIIはインデックスに入る前、つまりチャンク化・埋め込みの前に除去/マスクするのが原則です。CやDのように後段で処理しても、PIIはインデックスやチャンクテーブルの中に残り続け、検索結果として繰り返し取得されるリスクがあります。Aの表示直前のフィルタは多層防御の一層にはなり得ますが、根本対策として「防ぐべき段階」を問われたらデータ準備段階が正解です。
問3. 文書中の「電話番号」と「クレジットカード番号」のように形式が決まったPIIを、低コストかつ決定的に検出したい。最初に検討すべき手法はどれか。
正解:C
電話番号やカード番号のように形式が固定的なPIIは、正規表現が最も低コストで決定的(同じ入力に常に同じ結果)です。AのLLMは柔軟ですが、コスト・レイテンシが高く出力も非決定的で、形式的パターンの検出には過剰です。Bの埋め込み類似検索はPII検出の手法ではありません。Dは大量文書に対して現実的ではありません。なお、氏名・住所のような形式が不定なPIIには、Presidio などのNERベースの検出を組み合わせます。
問4. Model Serving エンドポイントを通るリクエストと応答に対して、アプリケーションのコードを変更せずにPII検出を一律に適用したい。使用すべき Databricks の機能はどれか。
正解:B
Unity AI Gateway のガードレールは、エンドポイントの設定としてPII検出などの入出力チェックを適用できるため、アプリのコード変更なしに一律の保護をかけられます。AのMLflow Tracingは実行の記録・デバッグ、CのタイムトラベルはDeltaテーブルの過去バージョン参照、Dの Lakehouse Monitoring は品質メトリクスの監視のための機能であり、いずれもリクエストのPIIを検知・ブロックする機能ではありません。