社内のデータを繋いだ生成 AI で最初に心配になるのは、見せてはいけないものが回答に出てくることです。Drive にも Gmail にも SharePoint にも、権限の設定が甘いまま置かれているファイルはあります。それを AI が拾って要約してしまうと、探すのが面倒だっただけの情報が、聞けば出てくる情報に変わります。
2026年8月28日、Gemini Enterprise でこれを止める機能が GA になりました。Sensitive Data Protection のコンテンツポリシーを、Gemini Enterprise のコネクタとアプリ、それに Gemini Notebook Enterprise のノートブックに適用できるようになった、というのが変更点です。
Gemini Enterprise: Protect sensitive data with content policies
You can apply Sensitive Data Protection content policies to your Gemini Enterprise connectors, apps, and Gemini Notebook Enterprise notebooks.
（Google Cloud リリースノート 2026年8月28日）
コンテンツポリシーという仕組み自体は Sensitive Data Protection 側にあったもので、新しいのは適用先です。何がどこで止まるのか、そして既定のままだと何が通ってしまうのかを整理します。
守る層は2つに分かれている
先に全体像を押さえておくと、以降が読みやすくなります。Gemini Enterprise には、データを止める場所が2つあります。
| 何を見るか | 止める場所 | |
|---|---|---|
| Sensitive Data Protection のコンテンツポリシー | 取り込まれる側のデータ | コネクタの取り込みとインデックス、ファイルのアップロード |
| Model Armor | やり取りされるデータ | LLM に渡る前のプロンプトと、利用者に返る前のレスポンス |
公式の説明でも、この2つは役割が分けられています。
Sensitive Data Protection focuses on ensuring only compliant information enters the system as the source.
Model Armor helps protect the user interaction in Gemini Enterprise by screening prompts before LLM processing and in model responses before delivery to the user.
（Protect sensitive data in sources）
入口で止めるのがコンテンツポリシー、経路で止めるのが Model Armor です。Model Armor はプロンプトインジェクションや悪意のある URL も見るので、狙いも違います。
この記事で扱うのは入口のほうです。片方だけで足りるものではない、という点だけ先に置いておきます。
コンテンツポリシーとは何か
Sensitive Data Protection には元々、テキストを検査して個人情報やクレジットカード番号などを見つける機能があります。コンテンツポリシーはその上に乗るもので、返すものが違います。
In contrast to other Sensitive Data Protection inspection operations, such as a content.inspect call or an inspection job, a content policy doesn't return a list of findings. Instead, a content policy returns a single ALLOW or BLOCK verdict.
（Overview of content policies）
検出結果の一覧ではなく、ALLOW か BLOCK の判定を1つだけ返します。呼び出す側は、その判定に従って通すか止めるかを決めます。検出結果を受け取って自分で判断ロジックを書く必要がない、という設計です。Gemini Enterprise のような呼び出し側にとっては、この形でないと組み込めません。
ポリシーは4つの部分でできています。
検査構成は、何を探すかの定義です。組み込みの infoType 検出器（メールアドレス、電話番号、クレジットカード番号など）と、自分で定義したカスタム infoType を選びます。既存の検査テンプレートを取り込むこともできます。
ルールセットは、検出の精度を調整する仕組みです。3種類あります。ホットワードルールは、指定した正規表現が infoType の近く（文字数で指定）にあるかどうかで確信度を上下させます。除外ルールは、誤検出を減らすために特定の文字列や文脈に一致するものを除きます。調整ルールは、別の infoType が近くにあることを根拠に、対象の確信度を変えます。「社員番号らしき数字」を、周囲に社員名があるときだけ機微として扱う、といった調整がここでできます。
ポリシールールは、判定そのものです。条件と判定（ALLOW か BLOCK）の組を並べます。条件は「いずれかの infoType」または「特定の infoType」で指定します。評価は順番に行われ、最初に一致したルールが判定を決めます。infoType ごとに違う判定を返したいときは、ルールを複数並べます。
デフォルトアクションは、どのルールにも当てはまらなかった場合や、そもそも検査できなかった場合の判定です。ここが後述する落とし穴になります。
加えて、判定結果を BigQuery のテーブルに記録するログ設定を任意で付けられます。何がブロックされたかを後から追うなら、これは最初から入れておくものだと考えています。
Gemini Enterprise のどこに効くか
適用先は3種類あります。
コネクタ
コネクタに適用すると、機微なデータを含むエンティティが利用者に返らなくなります。対象は次のとおりです。
- サードパーティのコネクタ（取り込み型と、データを持たずに参照するフェデレーション型の両方）
- カスタムの MCP サーバー
- Google Workspace のコネクタ（Drive、Gmail、Chat、カレンダー）
検査できる中身も、テキストだけではありません。画像の OCR、画像内の物体検出、画像の安全性、PDF や DOCX、PPTX、XLSX のような文書に埋め込まれた画像まで含まれます。スキャンした画像の PDF が対象外なら意味がない、という現実に対応した範囲になっています。
メタデータラベル
中身ではなく、付けられた分類で止める経路もあります。
Microsoft の秘密度ラベル（Purview、AIP、MIP などと呼ばれるもの）は、SharePoint と OneDrive の Office 365 ファイルおよび PDF、Outlook のメールとカレンダー予定、Teams のチャットメッセージで参照できます。直接アップロードされたファイルや Microsoft 以外のコネクタでも、Office 365 ファイルと PDF にラベルが埋め込まれていれば参照できます。
Google Workspace のラベルは、Workspace コネクタ内のファイルと、Google ドライブから Gemini Enterprise のアシスタントにアップロードされたファイルで参照できます。
すでに社内で「社外秘」「関係者限り」といった分類を運用しているなら、中身の検出器を細かく作り込むより、この経路のほうが早く効きます。
ファイルのアップロード
ローカル、Google ドライブ、Microsoft OneDrive からアシスタントや Gemini Notebook Enterprise にファイルを上げるとき、スキャンしてポリシー違反ならアップロード自体を止めます。
スキャン対象の形式は公式に一覧があり、PDF、HTML、プレーンテキスト、JSON、DOCX、PPTX、XLSX、XLSM、XML、CSV、TSV、そして BMP、GIF、JPEG、PNG、TIFF、SVG の画像です。
適用の手順
必要なロールは2つに分かれます。ポリシーを作って管理する人には DLP 管理者（roles/dlp.admin）、Gemini Enterprise 側の設定には Gemini Enterprise 管理者です。加えて、Gemini Enterprise のサービスアカウントに DLP ユーザー（roles/dlp.user）を付けます。これを忘れると、ポリシーを指定しても評価されません。
ポリシーを作るときの注意が1つあります。
Make sure to create the policy in the same region as the apps you want to apply it to.
適用先のアプリと同じリージョンに作る必要があります。
適用は、コネクタの設定画面にあるコンテンツポリシーの欄へ、リソース名を丸ごと入れるだけです。
projects/PROJECT_ID/locations/LOCATION/contentPolicies/POLICY_ID
入力すると即座に適用され、欄を空にすれば即座に外れます。切り戻しが速いのは助かる一方、誤って消しても警告なしに保護が外れるということでもあります。設定変更の監査は自分で用意しておくほうが安全です。
既定のままだと通ってしまうもの
ここが本題です。コンテンツポリシーは、止められないものと、既定では止めないものがはっきりしています。
デフォルトの判定はすべて ALLOW
デフォルトアクションで指定できるのは4つの場面です。非対応の形式だったとき、対応形式だがサイズが大きすぎて検査できないとき、破損や暗号化で検査できないとき、そしてどのルールにも一致しなかったときです。
公式ドキュメントの記述はこうです。
For each of these conditions, the default verdict is ALLOW.
（Create and manage content policies）
つまり、検査できなかったものは既定で通ります。ポリシーを付けたから安心、とはなりません。厳しく運用したいなら、少なくとも「検査できなかった場合」は BLOCK に変える判断が要ります。通す設計にするなら、それは意図した選択として残しておくべきです。
サイズについても同じ考え方で、大きいファイルは既定で許可されており、ブロックに変更できると明記されています。
動画と音声は検査されない
Although you can upload video and audio files to the assistant, Sensitive Data Protection doesn't scan these file types.
アップロードはできるが検査はされない、という組み合わせです。会議の録画や録音を扱うなら、この経路は塞がっていません。
旧来のデータストアには適用されない
コンテンツポリシーが効くのはコネクタです。Cloud Storage や BigQuery、ウェブサイトを取り込む従来型のデータストアは対象外だと明記されています。すでにその形で構成しているなら、今回の機能では守れません。
暗号化された Microsoft ファイル
暗号化されたファイルは Gemini Enterprise も Sensitive Data Protection も復号できないので、検査されません。ここで注意したいのは、その後の挙動です。
If users ask questions about the content, Gemini Enterprise can't answer because the content is encrypted. But, if users ask questions that can be answered from any unencrypted snippets and metadata, then Gemini Enterprise does provide those answers.
中身は答えられませんが、暗号化されていないスニペットやメタデータから答えられることには答えます。ファイル名やプロパティに機微な情報が入っていると、そこは出ます。命名に機微な情報を入れない、という運用の作法はここでも効いてきます。
その他の制約
- 別プロジェクトのポリシーを使うことはできるが、2つのプロジェクトが同じ VPC Service Controls の境界内にある必要がある
- Gemini Notebook Enterprise へのアップロードでは、Google Workspace ラベルとコンテンツのスキャンがサポートされない
- コンテンツポリシーを適用すると、レイテンシが増える可能性があると明記されている
- Business エディションでは使えない。それ以外のエディションで使え、追加費用はかからない
- 対応リージョンは global、EU、US のマルチリージョン
どう設計するか
ここまでを踏まえると、導入の手順はこうなります。
まず、止めたいものが中身なのか分類なのかを決めます。社内にラベル運用があるならメタデータラベル経由が早く、なければ infoType の設計から始めることになります。両方使えます。
次に、デフォルトアクションを明示的に決めます。既定は全て許可なので、決めないことは「検査できないものは通す」を選んだのと同じです。
ログを BigQuery に出す設定を最初から入れます。何がブロックされたのかが見えないと、ポリシーが厳しすぎるのか緩すぎるのかを判断できません。
適用範囲を確認します。コネクタ以外の経路（旧来のデータストア、動画と音声のアップロード）は塞がらないので、そこは別の手段で対応するか、そもそも繋がない判断をします。
そして、Model Armor と組み合わせます。入口を塞いでも、プロンプトに機密を貼り付ける利用者や、応答経路での漏れは別の話です。
まとめ
- 2026年8月28日に GA。Sensitive Data Protection のコンテンツポリシーを Gemini Enterprise のコネクタ、アプリ、Gemini Notebook Enterprise に適用できるようになった
- コンテンツポリシーは検出結果の一覧ではなく
ALLOWかBLOCKの判定を1つ返す。だから呼び出し側に組み込める - 構成は、検査構成、順序評価されるポリシールール、デフォルトアクション、BigQuery へのログ出力
- 効くのはコネクタ（サードパーティ、カスタム MCP サーバー、Workspace の Drive・Gmail・Chat・カレンダー）、メタデータラベル、ファイルのアップロード
- 適用先アプリと同じリージョンにポリシーを作る。サービスアカウントには
roles/dlp.userが要る - デフォルトアクションの既定はすべて
ALLOW。検査できなかったものは通る - 動画と音声は検査されない。旧来のデータストアは対象外。暗号化ファイルは中身を見られないが、メタデータからは答えられる
- Business エディション以外で使え、追加費用はない
- 入口はコンテンツポリシー、プロンプトとレスポンスは Model Armor。層が違う
新機能の告知は「機密データをブロックできるようになった」と読めますが、実際に読むと、既定値は通す側に倒れていて、塞がらない経路もはっきり書かれています。何が守られて何が守られないかを把握したうえで設定する、という当たり前の作業は残ります。