3行でいうと

  • 各社のフィルタは、文章の中から個人情報などを見つけ、動作を選べます。遮断（ブロック）、置き換え（マスク）、検出だけして記録（何もしない）の3つが基本で、入力と出力で別々に決められる製品もあります。
  • 公式の文書自身が、限界を書いています。検出は確率的で完全ではないこと、AIが道具を呼ぶときの引数や結果は対象外のものがあること、元の文章がログに残る場合があること、直接アップロードしたファイルは検査されない場合があることなどです。
  • 入口のフィルタは、対策の一部です。OWASPは、入力の無害化に加えて、アクセス制御と利用者への教育を並べています。システムへの指示だけで守ろうとすると、プロンプトインジェクションで回避されうる、とも書かれています。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認しました。製品の機能や状態（プレビューなど）は変わることがあります。

先に結論

前提：DLPとは、AIの入口とは

DLP（Data Loss Prevention、情報漏えい防止）は、機密情報が外へ出るのを、検出して防ぐ考え方や製品の総称です（ここは一般的な説明で、読んだ文書からの要約ではありません）。AIの場合、出ていく道が増えます。利用者がAIの入力欄に貼る、アプリがユーザーの文章をそのままAIのAPIに送る、AIの返事に機密が混ざる、などです。

OWASP（Webの安全を扱う団体）のLLM向けリスク一覧には、「機密情報の漏えい」（LLM02:2025）があります。説明によると、AIが出力を通じて個人データ、財務や健康の記録、事業の秘密、認証情報などを出してしまうことで、利用者が入力した機密があとで応答に現れる場合も含みます。対策として挙がっているのは、次のものです。

同じ文書は注意も書いています。システムプロンプトで返してよいデータの種類を制限しても、プロンプトインジェクションなどで回避されうる、というものです。つまり、フィルタはAIへの指示とは別に、AIの外側に置く必要があります。

3つの動作：遮断・置換・検出のみ

製品ごとに言葉は違いますが、動作は3つに整理できます。

動作 AWS Bedrock Guardrails Google Model Armor 意味
遮断 BLOCK 検査して遮断 全体を止めて、設定した定型の文言を返す
置換 ANONYMIZE（マスク） （詳細設定のSensitive Data Protectionで非識別化） 検出した部分を{NAME}のような種類名や伏せ字に置き換える
検出のみ NONE 検査のみ 止めずに、検出の結果を返す・ログに残す

Bedrock Guardrailsは、入力と出力で別の動作を設定できます（項目名はinputActionとoutputActionなど）。たとえば、メールアドレスを入力では遮断し、出力では置換する、という設定が考えられます。

小さな設定例（公式の項目名をもとにこの記事で組んだ形、動作確認はしていません）

AWSの文書にある項目名（inputAction、outputAction、inputEnabled、outputEnabledなど）を使った、設定の形の例です。外側のsensitiveInformationPolicyConfigやpiiEntitiesConfigなどの名前は、読んだ記録では確認できていないため、実際の仕様で確かめてください。

"sensitiveInformationPolicyConfig": {
  "piiEntitiesConfig": [{
    "type": "EMAIL",
    "action": "ANONYMIZE",
    "inputAction": "BLOCK",
    "inputEnabled": true,
    "outputAction": "ANONYMIZE",
    "outputEnabled": true
  }]
}

また、ApplyGuardrailというAPIは、文章をsource（INPUTかOUTPUT）つきで送ると、actionがGUARDRAIL_INTERVENEDかNONEで返ります。マスクした場合は、置換後の文章がoutputsに入ります。ただし、読んだページでは、例とスキーマの間に、項目名の食い違い（outputとoutputsなど）がありました。実際に使うときは、APIの正式な仕様で確かめる必要があります。

3つの製品の見比べ

AWS Bedrock Guardrails Google Model Armor + Sensitive Data Protection Microsoft Purview DLP（Copilot向け）
置き場所 モデルとは独立のAPI（ApplyGuardrail）で任意の場所から プロンプトと応答を検査するサービス Microsoft 365のCopilotの場所（ポリシーの対象）
検出 組み込みのPII種類 + 独自の正規表現 基本は決まった種類の検査のみ。詳細設定でテンプレート 機密情報の種類（組み込みと独自）、機密ラベル
動作 遮断／マスク／検出のみ 検査のみ／検査して遮断。詳細設定で非識別化 プロンプトの処理のブロック（プレビュー）、Web検索のブロック、ラベル付きの除外
明記された限界 ツール呼び出しは対象外、ログに元の文が残る 1ターンずつ検査、エンコードは見ない アップロードしたファイルは検査されない、反映に最大4時間

Microsoftの文書は、Microsoft 365のCopilotやCopilot Chat向けです。自前で作るAIアプリの入口ではなく、Microsoftの製品に組み込まれたAIを管理する仕組みなので、他の2つとは対象が違います。

オープンソースの選択肢として、Presidioがあります。公式のページによると、テキストや画像の中の私的なデータを見つける分析（Analyzer）と、伏せる処理（Anonymizer）があり、固有表現認識、正規表現、ルール、チェックサム、文脈を組み合わせて検出します。多言語に対応し、独自の検出器や外部のモデルをつなげられます。HTTPサービスとして動かせる、とも書かれています。

各社が書いている検出の範囲と制限の数字

AWS Bedrock Guardrails（Sensitive information filters）

  • 組み込みのPII種類（一部）：一般（NAME、EMAIL、PHONE、ADDRESS、PASSWORDなど）、金融（CREDIT_DEBIT_CARD_NUMBER、PIN、SWIFT_CODEなど）、IT（IP_ADDRESS、AWS_ACCESS_KEY、AWS_SECRET_KEYなど）、米国5種、カナダ2種、英国3種。日本固有の項目は、一覧にありませんでした。
  • 独自の正規表現：名前は1〜100文字、パターンは1〜500文字、説明は1〜1000文字。ルックアラウンド（前後を見る指定）には対応しません。
  • 検出の性格：機械学習による確率的で、文脈に依存します。文脈が多いほど正確になるので、単語や短い句の単独の検査は避けるよう、文書が注意しています。
  • コードや文字列リテラルの中の機密も検出対象と書かれています。

Google Model Armor（Overview）

  • Sensitive Data Protectionの基本設定は検査のみで、クレジットカード番号、米国の社会保障番号、金融口座番号、米国の個人納税者番号、Google Cloudの認証情報とAPIキーが対象です。詳細設定はテンプレートで細かく指定でき、非識別化にも対応します。
  • 各プロンプトと応答は、会話の履歴なしの1ターンとして検査されます。
  • Base64、16進、URLエンコード、暗号文は、復号も検査もされません。
  • 画像はJPEG、PNG、BMPで4 MBまで、ファイルも4 MBまで。1回のリクエストでテキストと画像は併用できません。音声と動画は非対応です。
  • 応答の読み方：SanitizeUserPromptの応答にはfilterMatchState（MATCH_FOUNDかNO_MATCH_FOUND）が含まれます。検査を飛ばした場合はEXECUTION_SKIPPEDなどが返りますが、その扱い方をアプリ側でどうすべきかは、再確認したページに書かれていませんでした。

Microsoft Purview DLP（Copilot向けの場所）

  • 「プロンプトの処理のブロック」と「外部メールの除外」はプレビューと表示されています。機密情報の種類と機密ラベルの条件は、同じルールで併用できません。
  • ブロックされたプロンプトには応答が返らず、検索にも使われません。
  • ファイルをプロンプトに直接アップロードした場合は、DLPの検査対象外で、入力した文字だけが検査されます。
  • ポリシーの更新が反映されるまで、最大4時間かかります。

抜け道：公式が書いている「守れない場所」

3社の文書に共通して見られる限界を、僕らが整理しました。

  1. 検出は完全ではない。 AWSは確率的な検出と書き、Presidioは自動の検出なので、すべての機密を見つける保証はなく、追加の安全策を勧める、と書いています。見逃し（機密が通る）と、誤検知（問題ない文章が止まる）の両方が起きうる、と考えるのが無難です。
  2. 道具の呼び出しは別の経路。 AWSの文書は、モデルが道具に渡す引数や、道具が返す結果のPIIは評価しない、と明記しています。AIが外部のシステムを操作する構成では、入口のフィルタを通らない流れが残ります。
  3. ログと記録に元の文章が残る。 AWSの文書では、モデルの呼び出しログの入力は元のまま残り、診断用の出力のmatchにも元のPIIの値が入ります。マスクしても、ログに残ればそこから漏れる可能性があります。ログを守る別の対策が要ります。
  4. エンコードやファイルは見ない場合がある。 Model Armorは、エンコードされた内容は検査しません。Purviewは、直接アップロードしたファイルを検査しません。
  5. 会話全体では見ない場合がある。 Model Armorは1ターンずつ検査します。複数回に分けて少しずつ入れる流れは、1回ごとの検査では見えにくくなります（これは僕らの推測です）。
  6. 未対応の言語や形式。 Model Armorは、テキストか画像の片方だけを指定したときや、地域によって多言語検出が限られる場合に、検査が飛ばされた結果（EXECUTION_SKIPPEDやSkipped Detection）を返すことがあります。その結果を通すか止めるかは、アプリ側で決めることになる、というのは僕らの見立てです。

設計の考え方

ここからは僕らの見立てです。公式の資料から、設計の論点を整理しました。

個人情報保護法の扱いは、別の記事で扱っています。この記事は、法律の解釈ではなく、技術の設計の話です。

気をつけること

出典

更新履歴