Gemini for Workspace × Vault のデータ交差リスクと制御設計

Gemini for Workspace を展開すると、Google Vault（グーグル ボールト）で保持中のメールやファイルへの Gemini のデータアクセスを制御する必要が生じます。この記事では「Vault 保持 = AI から隠れる」という誤解を整理し、情シス担当者が取るべき設計判断の軸を提示します。

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

• Gemini for Workspace を展開済み、または展開を検討中の情シス担当者
• Google Vault を eDiscovery・法的保全目的で運用している担当者
• Gemini 展開前にコンプライアンスリスクを棚卸ししたい方
• Vault と Gemini の設定が自組織で整合しているか確認したい担当者

Vault の本質：保全はアクセス制限ではない

Google Vault は eDiscovery（電子情報開示）と法的保全（リーガルホールド）を目的としたサービスです。訴訟・監査・法規制対応で「このデータを消してはいけない」という要件を満たすための仕組みであり、Gmail・Drive・Chat・グループのデータに保持ルールやホールドを設定することで、ユーザーがデータを削除しても Vault がそのデータを保全し続けます。

ここで押さえておくべき点があります。Vault が行うのはデータの削除防止であり、他のサービスからそのデータへのアクセスを制限するものではありません。ホールドがかかっている Gmail メッセージや Drive ファイルは、ユーザーが通常通りアクセスできる状態のまま残ります。つまり Vault 保持中のデータは Gmail・Drive 上に元通りある—特別な場所に隔離されているわけではありません。

Gemini for Workspace が参照できるデータの範囲

Gemini for Workspace は Workspace Intelligence（ワークスペース インテリジェンス）という仕組みを通じて Gmail・Drive・Calendar・Chat の内容を参照し、文脈に沿った回答を生成します。Google の公式情報によると、Gemini が参照できる範囲は「そのユーザーがアクセス権限を持つデータ」のみで、他ユーザーが所有するファイルにはアクセスできません。

このアクセス制御の仕組みと Vault を組み合わせると、重要な点が浮かび上がります。Vault ホールド対象のメールや Drive ファイルは Gmail/Drive に通常通り残っており、ユーザーはそれらにアクセスできます。Gemini も同じ権限範囲でデータを参照できるのが現実です。法的保全の対象メールや eDiscovery 対象ファイルが Gemini の参照範囲に入り得ます。

「Vault でホールドをかけているから AI には読まれない」という前提で Gemini を展開していると、コンプライアンス上の想定外が起きるリスクがあります。

具体的な場面で考えてみます。労務問題で社員 A のメール・Chat メッセージにリーガルホールドをかけている最中に、その社員 A に Gemini for Workspace が有効な状態だとします。社員 A 自身が Gemini に「先月のやり取りを要約して」とプロンプトを入力した場合、ホールド対象のメール内容が回答のソースになり得ます。Vault のホールドはその状況を変えません。また、管理職が「チームの先月のコミュニケーションをまとめて」と Gemini に依頼した場合、その管理職が閲覧権限を持つ範囲での参照が行われます。アクセス権限の設計が実質的な境界線です。

Vault 保持データへの AI アクセスを制御する設定

Gemini for Workspace のデータアクセスを制限できる手段として何が有効かを整理します。

Vault の保持ルール・ホールド自体はアクセス制限の手段にはなりません。実際に機能する手段は以下の通りです。

手段	Gemini アクセスを制限できるか	補足
Vault 保持ルール / リーガルホールド	できない	削除防止が目的。アクセス権限は変わらない
クライアントサイド暗号化（CSE）	できる	CSE で保護されたデータは Gemini が復号できない
IRM（Information Rights Management）制限	できる	ダウンロード・印刷・コピー不可のファイルは Gemini が参照しない
Workspace Intelligence の無効化	部分的にできる	Gmail/Drive を AI 参照ソースから除外できる。ただしユーザーが明示的に指定したファイルは参照される
DLP ポリシー（IRM 連携）	できる	機密ラベルに応じて IRM を自動付与し Gemini のアクセスをブロック

CSE（クライアントサイド暗号化）が最も確実な手段です。Google の公式情報によると、CSE で保護されたデータは Google のサービスや Gemini を含む AI アシスタントが復号できないため、Gemini から完全に遮断されます。ただし CSE は上位エディションが必要で、既存データへの適用には計画的な導入が必要です。

IRM による制限も実効性があります。ダウンロード・印刷・コピーを禁止する IRM が設定されたファイルについては、Gemini はそのファイルを参照せずに回答を生成します（Google Workspace Enterprise セキュリティ情報より）。

情シスの設計判断フロー

Gemini 展開と Vault 運用を同時に行う場合、以下のステップで設計を組み立てます。

ステップ1：リスクが存在するか確認する

Gemini for Workspace が展開されているユーザーに、Vault ホールドの対象データが含まれているかを確認します。「Gemini を使っている部署」と「Vault ホールドの関係者」が重なっている場合、設計判断が必要なリスクが存在します。

ステップ2：保持データの機密度を評価する

このステップは IT 部門だけでは完結しません。Vault の保全対象・案件の背景を把握しているのは法務・コンプライアンス部門のため、ホールドの台帳（保全対象者・案件名・保全期間）を法務から共有してもらい、Gemini の展開ユーザーリストと突き合わせる作業が実務上の第一歩です。Gemini 展開計画の段階から法務を巻き込んでおくことを推奨します。

Vault で保全しているデータの性質によって対応の優先度が変わります。

• 訴訟・労務問題・M&A 案件に関連するメール・ファイル → 高優先度
• 社内調査中の当事者のデータ → 高優先度
• 法定保存期間のための一般業務記録 → 要判断（機密度次第）

機密性の高い案件で、当事者ユーザーに Gemini が展開されている場合、アクセス制御の設計が必要です。

ステップ3：自組織のエディションで使える手段を確認する

取れる手段は Workspace のエディションに依存します。

• Workspace Intelligence の無効化（Gmail・Drive を Gemini のデータソースから外す）は多くのエディションで対応可能です。管理コンソールの生成 AI 設定から確認できます。
• IRM の手動付与は幅広いエディションで利用できます。機密性の高い Vault 保持ファイルに個別に設定する方法です。
• DLP ポリシーによる IRM の自動付与の対応エディションは、管理コンソールのエディション比較ページで確認してください。ラベルや条件に基づいて自動的に IRM を付与し、Gemini のアクセスをブロックします。
• CSE は Frontline Plus・Enterprise Plus・Education Standard・Education Plus で利用できます（Enterprise Standard は対象外）。

ステップ4：Workspace Intelligence の設定を確認・調整する

管理コンソールの生成 AI 設定から Workspace Intelligence を開き、Gmail や Drive が Gemini のデータ参照ソースとして有効になっているかを確認します。完全に無効化すると AI の利便性は下がりますが、Vault 保持対象データが多い部門に絞って制御することで、リスクを抑えながら AI の利便性を維持できます。

AI コントロールセンターの概念と活用

AI コントロールセンターは、管理コンソールの生成 AI 設定から使える Gemini の安全・コンプライアンス管理の集約ポイントです（Enterprise Standard / Enterprise Plus 限定）。次の 4 つの観点から設定を一元管理できます。

• AI アクセスの監視と制御: 組織内での AI 機能の利用状況を確認し、アクセス範囲を管理する
• AI 製品向けセキュリティの管理: Workspace および外部 AI アプリとのデータ共有設定を制御する
• 基本セキュリティの管理: DLP ルール・信頼ドメイン・外部アプリ制限などの設定に横断的にアクセスする
• プライバシー・不正使用防止・コンプライアンスの確認: 生成 AI がどのようなプライバシー基準・不正使用防止措置を満たしているかを確認する

AI コントロールセンターを通じて、ユーザーが入力したプロンプトや生成された回答が許可なくモデル学習に使われないことの確認も行えます。Vault × Gemini のリスク対応では、このセクションで DLP の現状確認とデータ共有ポリシーの整合を取ることが出発点になります。

管理コンソールのレポート機能からは Gemini の利用状況（アクティブユーザー数・機能別の利用量）を確認できます。どのユーザーが AI 機能を積極的に使っているかを把握することで、Vault ホールド対象者との重複チェックをより正確に行えます。Enterprise Standard / Enterprise Plus 以外のエディションでも、個別機能のオン・オフや Workspace Intelligence の設定は管理コンソールの生成 AI 設定から操作できます。

DLP と IRM を組み合わせた自動制御

DLP（データ損失防止）ポリシーは、機密情報を含むファイルに対して IRM 制限を自動的に付与する設定が可能です。機密ラベルや条件に基づいて IRM が自動適用されると、そのファイルへの Gemini のアクセスも同時にブロックされます。

Vault 保持データ全体に遡及して DLP を適用するには段階的な計画が必要です。現実的なアプローチとして、新規作成・更新されるファイルから順次ポリシーを適用し、機密度の高い案件データから保護を強化していく方法が有効です。既存の Vault 保持データへの遡及は、Drive の一括ラベル付け機能を活用して段階的に進めることになります。

ここで「逆方向の交差」も押さえておく必要があります。2025年2月の Workspace Updates によると、Gemini アプリとのチャット会話が Vault の保持・ホールド対象に追加されました。つまり Gemini との会話記録を eDiscovery や法的保全の対象にすることが可能になっています。AI の利用記録を組織の記録として保全する義務がある場合は、Vault の保持ルールに「Gemini アプリの会話」を含めているかを確認してください。なお、Gmail や Docs に組み込まれた Gemini for Workspace 機能（メール要約・文書生成など）のプロンプト・回答は、この Vault 保持の対象外です。スタンドアロンの Gemini アプリ（gemini.google.com）での会話のみが対象になります。Gemini がデータを読むリスクとは別次元の設定ですが、同じ Vault の設定画面に関わるため、両者を切り離さず一緒に見直すことを推奨します。

なお、DLP および IRM の運用は Vault の保持ルールとは独立した設定系統です。Vault で保全済みのデータに DLP を後から適用しても、既存の保持ルールやホールドには影響しません。両者を補完的に使う設計が基本です。

Vault と Gemini の設定を横断的に見直す

Vault は削除を防ぐ仕組みであり、Gemini からデータを遮断する機能は持っていません。Gemini for Workspace を展開した組織で Vault を運用している場合、Vault の設定だけではデータ保護が完結しないという認識が設計の起点になります。

実際の優先順位は自組織のエディションと保全案件の機密度で変わりますが、まず管理コンソールの生成 AI 設定で Workspace Intelligence の状態を確認し、意図しないデータ参照が起きていないかを把握するところから始めます。機密度の高い Vault 保持データには IRM を手動付与し、DLP でその自動化を検討する。エディションが許せば CSE でより確実な保護を実現する。この順で対応範囲を広げるのが現実的です。

実務上、Vault の担当者（法務・コンプライアンス）と Gemini の展開担当者（情シス）が別々に動いてきたケースが多くあります。この問題は設定の技術的な対応だけでなく、両者が同じ視点で棚卸しをする機会を持つことで初めて解決に向かいます。自組織の Vault 設定と Gemini の展開範囲を一度突き合わせてみることが、次の具体的なアクションです。

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

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