GeminiとChat DLPで機密情報を守る統合設計

Google Workspace の Chat で Gemini を利用できる環境が整い、組織外ユーザーとの会話でも AI を活用するケースが広がっています。この記事では、Chat DLP（Data Loss Prevention：データ損失防止）と Gemini for Workspace の適用範囲の関係を整理し、外部ユーザーとの会話で機密情報が漏れるリスクパターンと統合ガバナンス設計の判断軸を解説します。

この記事を読んだほうが良い人

• Gemini for Workspace と Chat DLP をともに利用中、または導入を検討している情シス担当者
• 外部ユーザーが参加できる Chat スペースのセキュリティポリシーを設計したい方
• 「@Gemini の返答に DLP は適用されるのか」という疑問を持っている方
• 個別の設定ガイドは読んだが、2つを組み合わせたときの設計判断が分からない方

Gemini for Workspace と Chat DLP の適用範囲の違いとは？

Chat DLP が「何を」スキャンするか

Chat DLP は、ユーザーが送信したメッセージとファイル添付を対象に、機密情報を検出してブロック・警告・ログ記録などのアクションを実行する仕組みです。Google Workspace の公式ヘルプによると、スキャンは 1:1 チャット・グループチャット・スペースのいずれにも対応し、ユーザーがメッセージを送信するタイミングで実行されます。

添付ファイルもスキャン対象です。PDF や一般的なドキュメント形式も検出対象に含まれますが、パスワード保護付き圧縮ファイルや極端に大きなファイルは検出できない場合があります。DLP のカバー範囲を「すべてのファイル形式を完全に検出できる」と過信しないことが設計の前提として重要です。

Chat DLP が利用できるエディションは、Enterprise Standard / Enterprise Plus・Enterprise Essentials Plus・Frontline Standard / Frontline Plus・Education Fundamentals / Education Standard / Education Plus に限られます（公式ヘルプより）。Business Starter / Business Standard などのエディションでは Chat DLP 機能を利用できないため、エディションの確認が最初のステップです。

ここで重要なのは「ユーザーが送信する」という条件です。この前提が、Gemini との組み合わせで設計上の問いを生み出します。

Gemini の Chat 利用形態と DLP 適用の境界

Gemini を Chat で活用する場面は、大きく2パターンに分かれます。

パターン A: Gemini サイドパネルで文章を生成し、ユーザーが送信する

Gemini に文章を生成させ、ユーザー自身がそのテキストをメッセージとして送信する形式です。この場合、「ユーザーが送信したメッセージ」として Chat DLP のスキャン対象になります。

パターン B: スペースで @Gemini をメンションし、Gemini が直接返答する

ユーザーが @Gemini でメンションすると、Gemini（ボット）が AI 応答を会話に投稿します。この返答は「ユーザーが送信したメッセージ」ではなく、AI が生成して投稿したメッセージです。この AI 生成応答に対して Chat DLP が同様にスキャンを実行するかどうかは、公式ヘルプ上で明示的な記述を確認できません。

「パターン B の AI 応答の扱い」が、統合設計における最大の盲点です。

Chat DLP × Gemini 回答フィルタの適用・非適用マトリクス

シナリオ	Chat DLP の適用	根拠・補足
ユーザーが Chat メッセージを送信	◎ 適用	公式ヘルプで確認済み
Gemini 生成テキストをユーザーがコピーして送信	◎ 適用	ユーザー送信扱いのためスキャン対象
@Gemini への AI 応答メッセージ	△ 公式未明示	ユーザー送信ではなく AI 生成投稿のため不明
IRM 設定済みファイルを Gemini が参照	◎ IRM で制御	IRM（情報権限管理）により Gemini のアクセス自体を制限できる（公式確認済み）
Gmail での Gemini 生成コンテンツ	◎ Gmail DLP 対象	公式ドキュメント（Workspace AI セキュリティ）で適用を確認
外部ユーザー参加スペースへの @Gemini 回答	△ 要設計	AI 生成応答に加えて外部露出のリスクが重なる

◎ は公式情報で適用が確認できる項目、△ は公式文書上の明示がなく設計上のリスクとして扱うべき項目です。

注目したいのは Gmail DLP との違いです。Gmail での Gemini 生成コンテンツについては、Google の公式ドキュメント（Workspace AI セキュリティ）で DLP ルールの適用が確認されています。一方で Chat DLP については、@Gemini 応答への同様の適用が明記されていません。同じ「DLP」という名称でも、サービスごとに適用範囲が異なる点は設計上の重要な前提として押さえておく必要があります。

外部共有シナリオで生まれる機密情報漏洩リスク

「外部スペース」での Gemini 回答が持つリスク

Google Chat では、ゲストアクセスや外部組織との共有スペースを設定できます。こういった外部ユーザー参加スペースで @Gemini を呼び出すと、Gemini の回答は外部参加者にもそのまま表示されます。

Chat DLP には「外部所有スペース」や「ゲストアクセスあり」の会話タイプを条件として組み込む機能があります。ただし、前述の通り AI 生成メッセージを Chat DLP がスキャンするかどうかが現時点で不確かなため、この条件設定だけでは @Gemini 回答経由のリスクをカバーできない可能性があります。

設計上のリスクパターン3選

リスク 1: ユーザーが機密ファイルの内容を @Gemini に問い合わせ、回答が外部参加者に流れる

典型的な場面として、「@Gemini このプロジェクトの契約書を要約して」といったプロンプトが外部スペースで投げられるケースがあります。Gemini が Drive 内の機密ファイルを参照して要約を返答すると、その内容が外部参加者にも見えてしまいます。仮に Chat DLP がユーザーの入力（プロンプト）をスキャンしたとしても、AI が生成した回答メッセージをスキャンしない場合、このルートでの情報漏洩を防げません。

対策の軸は IRM（情報権限管理）です。機密ファイルに印刷・コピー・ダウンロード制限を設定すると、Gemini はそのファイルを参照できなくなります（Google Workspace 公式セキュリティページより）。DLP に頼る前に、データソース側で Gemini のアクセス範囲を絞ることが先決です。

リスク 2: ユーザーが Gemini で生成した文章を外部スペースで送信する

ユーザー自身がメッセージを送信するため、Chat DLP のスキャン対象になります。外部会話条件を含む DLP ポリシーを設定することで、この経路の機密情報送信を制限・警告できます。3つのリスクの中では最もコントロールしやすいパターンです。

たとえば「顧客の個人情報（氏名・電話番号・メールアドレス）が含まれるメッセージを外部スペースに送信しようとした場合に警告表示する」という DLP ルールは、ユーザー経由の送信をきちんと捕捉できます。Chat DLP はこのユーザー送信経路を守る層として機能します。

リスク 3: 社内情報を含むプロンプトを @Gemini に投げ、AI 回答サマリーが外部参加者に共有される

最もコントロールの難しいシナリオです。たとえば「@Gemini 先月の売上データをもとに取引先向けのレポートを作って」という指示を外部スペースで投げた場合、Gemini が社内の売上情報を参照・要約した回答を外部参加者が閲覧できる状態になる可能性があります。

@Gemini 応答が DLP のスキャン対象である保証がない現状では、外部スペース自体での @Gemini の利用制限を検討する必要があります。管理コンソールの AI 管理設定から Gemini 機能の有効範囲を組織単位（OU 単位）で調整することが、現実的な対策の一つです。

Google Workspace AI セキュリティ設計：3レイヤーの統合防御

単一の設定でリスク全体をカバーしようとせず、3つの防御レイヤーを組み合わせる設計が現実的です。

防御レイヤー	主な手段	担う役割
L1: データソース保護	Drive IRM / CSE（Client-side Encryption）	Gemini が参照できるファイル自体を制限する
L2: 送信時スキャン	Chat DLP（外部会話条件つき）	ユーザー送信メッセージの機密情報を検出・ブロック
L3: 外部共有制御	Chat 共有設定 / AI 管理設定	外部スペース作成・@Gemini 利用の有効範囲を組織単位で制御

L1 を先行整備すべき理由

IRM は Gemini の「情報アクセスの天井」を決める設定です。Gemini は Drive にアクセスできる情報を参照材料として使います。IRM でコピー・印刷・ダウンロード制限を設定したファイルは、Gemini が参照できる候補から除外されます（Google Workspace 公式セキュリティドキュメントより）。

整備が遅れがちなのがこの L1 層です。「Gemini を使い始めたら、これまで気にしていなかったファイルも AI に読まれるかもしれない」という視点への意識転換が必要です。特に人事データ・財務資料・顧客情報を含むファイルについては、Gemini 導入と並行して IRM ポリシーの見直しを行うことを推奨します。「どのファイルを Gemini に参照させてよいか」の整理を先に行わずに AI 活用を広げると、後から IRM を設定しても「すでに外部スペースで共有されていた」というケースが生じます。

L2 でカバーできる範囲と限界

Chat DLP のルールでは、会話タイプ（外部所有スペース・ゲストアクセスあり）を条件に加えることで、外部ユーザーが絡む会話に特化したスキャンが可能です。個人番号・クレジットカード番号といった定義済みパターンから、会社独自の機密マーカー（特定のキーワード、社内文書番号など）を検出するカスタムルールまで設定できます。

ただし、L2 が確実に機能するのは「ユーザーが送信するメッセージ」経路だけです。@Gemini 応答がスキャン対象かどうかは確認できていないため、L2 単体でシステム全体を守ろうとする設計は現時点では推奨できません。「Chat DLP を設定したから Gemini もカバーできている」と誤解しないことが、設計上のリスクを避ける最初の一歩です。

L3 で判断すること：外部スペースで Gemini を許可するか

L3 の判断は二択ではなく、以下のような段階的な制御が可能です。

• 全社禁止: 外部スペースでの @Gemini メンションを管理コンソールの AI 管理設定から無効化する
• OU 単位での制限: 営業部門など外部コミュニケーションが多い部署は制限し、社内専用チームは利用可能とする OU 単位の運用
• 外部スペース作成自体を制限: そもそも外部ユーザーを含むスペースの作成を制限し、外部共有はメールや専用ツールに集約する

この3択の判断は、組織のリスク許容度と業務上の必要性のバランスで決まります。「外部コミュニケーションに Gemini を使いたい部署」と「リスクを取りたくない情シス」の双方の要件を整理したうえで、OU 単位での段階適用が落とし所になるケースが多いです。重要なのは「デフォルトで使えるが、ポリシーがない」という状態を避けることです。

設計判断フロー：外部スペースで Gemini を使うか？

外部ユーザーとの Chat スペースで Gemini を利用する場合、以下の順序で確認してください。

ステップ 1 — L1 から先に設計する

機密ファイルへの IRM 設定が整っているかを確認します。IRM が未整備な状態で AI を活用すると、全社データが @Gemini の参照候補になりかねません。「Gemini に渡してよい情報の天井」をデータソース側で決めることが、統合設計の出発点です。

ステップ 2 — L2 でユーザー送信経路をカバーする

Chat DLP のルールに外部会話条件（外部所有スペース・ゲストアクセスあり）を追加します。ユーザーが機密情報を誤送信するリスクを、この層で制御します。

ステップ 3 — L3 で @Gemini の利用範囲を明示的に決める

外部スペースでの @Gemini 利用を組織として「許可する」「制限する」「禁止する」のいずれかを決め、ポリシー化します。「とりあえず使える状態」のまま外部共有を始めるのが最もリスクの高い状態です。

「L2 の Chat DLP があれば大丈夫」という判断は、@Gemini の AI 応答がスキャン対象かどうかが確定していない現状では根拠が弱いと言えます。L1・L3 を先に固めることで、L2 の「限界」に依存しない設計になります。

DLP 違反の検知と運用継続フェーズの注意点

設計が固まった後に見落とされやすいのが、運用継続フェーズのモニタリングです。

Chat DLP でブロック・警告・監査ログのアクションを設定した場合、違反イベントは管理コンソールの「監査と調査」から確認できます。DLP のアクションログとして記録されるため、「どのルールが、どのユーザーによって、いつ発動したか」を事後的に追うことが可能です。

アラートセンターを使うと、DLP ルールのトリガー発生をリアルタイムで管理者に通知する設定もできます。特に外部スペースへの機密情報送信ブロックが頻発している場合、ポリシーの周知が不十分か、業務フローに無理があるかのシグナルになります。定期的なアラートレビューを運用サイクルに組み込むことで、ポリシーの形骸化を防げます。

また、Gemini for Workspace のセキュリティ適用範囲は Google の機能アップデートとともに変化する可能性があります。「@Gemini の AI 応答に Chat DLP が適用されるかどうか」という現状の未明示事項も、今後の Workspace Updates Blog で方針が明確化される可能性があります。設計を固めた後も、月 1 回程度の公式アップデート確認を担当者の定常業務に含めることを推奨します。

設計確認チェックリスト（導入前・運用見直し時）

対象エディションは Enterprise Standard / Enterprise Plus・Frontline Standard / Frontline Plus・Education 各エディションです（Chat DLP の対応エディション、公式ヘルプより）。

• [ ] Chat DLP ポリシーが有効化されており、メッセージと添付ファイルの両方をカバーするルールが存在するか
• [ ] Chat DLP のルール条件に「外部所有スペース」または「ゲストアクセスあり」の会話タイプを含めているか
• [ ] 機密情報を含む Drive ファイルに IRM が設定されており、Gemini の参照対象から除外できているか
• [ ] 外部スペースでの @Gemini 利用を組織としてどう扱うか方針が決まっているか（許可・制限・禁止のいずれかを明示）
• [ ] @Gemini の AI 応答が Chat DLP のスキャン対象かどうかを、公式アップデート情報で定期的に確認しているか
• [ ] AI 管理設定で Gemini の社内データ参照範囲を把握・制御しているか
• [ ] 上記ポリシーの見直し頻度と担当者が定められているか

まとめ：「DLP があるから安全」を前提にしない

この記事で繰り返し触れた「@Gemini の AI 応答に Chat DLP が適用されるか」という問いに対する現時点の答えは、「公式文書上では明示されていない」です。

裏を返せば、「Gemini の AI 回答は DLP が守っているから安全」と前提を置くことはできません。設計として取るべきスタンスは一つで、Gemini 回答経由のリスクを DLP 単体に依存させない多層防御です。IRM でデータソースを制限し、外部スペースポリシーで @Gemini の利用範囲をコントロールし、Chat DLP をユーザー送信経路に集中させる。3レイヤーを意識的に設計することが、Gemini for Workspace を外部ユーザーとの会話でも安全に活用するための実務的な出発点です。

Gemini for Workspace の機能拡張は今後も続きます。Chat DLP との統合範囲も変わる可能性があるため、設計を固めたら終わりではなく、Google の公式 Workspace Updates を定期的に確認することを習慣にしてください。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。