Google Vault で Gemini と DLP ログを突合する方法

2025年2月、Google Vault が Gemini アプリの会話ログ（ユーザーのプロンプトと Gemini の応答）の検索・エクスポートに対応しました。この記事では、Vault の Gemini 対応を起点に、DLP 違反と Gemini 利用の突合を組み込んだ情シス向けの監査設計を整理します。

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

• Gemini for Workspace を導入済みか導入検討中で、AI 利用の監査体制を構築したい情シス担当者
• DLP ルールを設定しているが、違反ユーザーの AI 利用状況を確認できていない担当者
• Vault を保持・削除ツールとしてのみ使っており、監査・証跡管理への活用を模索している方
• 100 名規模の企業で Gemini 導入後のガバナンスを設計したい情シス担当者

Google Vault Gemini 監査の前提：データの所在と対象範囲

突合の設計を始める前に「どの Gemini データ」が Vault の対象になるかを正確に把握しておく必要があります。ここを混同すると、監査設計が根本から狂います。

Vault が対応しているのは Gemini アプリ（standalone）の会話のみです。gemini.google.com で行った会話—ユーザーが入力したプロンプトと Gemini が返した応答—を検索・エクスポートできます（Google Vault ヘルプより）。ただし保持（Retention）やリーガルホールド（Hold）には対応しておらず、検索とエクスポートに限定されます。

対象外は Workspace アプリ組み込みの Gemini 機能です。Docs の「Help me write」、Gmail の文章補助、Sheets の AI 分析など、各アプリに組み込まれた Gemini 機能のプロンプトや応答は Vault では捕捉できません。これらの利用状況は、管理コンソールの「Gemini for Workspace ログイベント」で確認します。

DLP 違反の記録は Vault ではなく管理コンソールのルールログイベントに蓄積されます。違反ユーザーのメールアドレス、発生日時、トリガーされたルール名と重大度、対象リソースの種別・名称・オーナーが記録されます（Google Workspace 管理コンソールヘルプより）。

DLP と Gemini プロンプトの関係を整理する

重要な前提を補足します。管理コンソールのルールログイベントに記録されるのは、Drive・Gmail・Chat といった各サービス上での DLP 違反です。ユーザーが Gemini アプリに入力したプロンプトは、このルールログイベントの対象にはなりません。

つまり「ユーザーが機密情報を Gemini のプロンプトとして入力した」という行為は、DLP 違反として自動的に記録されるわけではないのです。これが、この記事で取り上げる「突合アプローチ」が必要になる背景です。

DLP が検知するのはあくまでも Drive・Gmail・Chat での違反であり、同じユーザーが同時期に Gemini を使って何をしていたかは別途確認しなければわかりません。DLP 違反と Gemini 利用の時間的な重なりを手動で確認することで、「機密情報に触れていたユーザーが AI ツールも積極的に活用していた」という状況を把握できます。

突合に使う主なデータを整理すると次の 3 種になります。

データ種別	確認場所	主な記録内容
Gemini アプリ会話ログ	Google Vault	プロンプト・応答（検索・エクスポートのみ）
Gemini in Workspace 利用ログ	管理コンソール「監査と調査」	利用サービス・操作種別・タイムスタンプ
DLP 違反ログ	管理コンソール「監査と調査」	違反ユーザー・日時・ルール名・リソース情報

これらは別々の場所に存在しており、管理コンソール単体でも Vault 単体でも横断的な把握はできません。突合は情シスが意識的に設計する必要があります。

監査開始前に確認すべき：Gemini アクティビティの設定状態

Vault に Gemini アプリの会話データが蓄積されるには、対象ユーザーの「Gemini アプリのアクティビティ」が有効になっている必要があります。管理コンソールで Gemini アクティビティの設定が無効になっていると、Vault でいくら検索しても会話は取得できません。監査設計を始める前に、組織内の Gemini アクティビティの状態を確認することが先決です。

また、Vault 自体が利用できるエディションであることも前提条件です。エディション要件は管理者ヘルプの Vault 対応エディションのセクションで確認してください。

DLP 違反ログと Gemini ログを突合する方法

3 種のデータを使った突合フローを 3 ステップで説明します。

Step 1：DLP 違反の一覧化と優先度分類

管理コンソールの「監査と調査」からルールログイベントを開き、対象期間（例：前月分）を抽出します。最低限取得しておく項目は次のとおりです。

• 違反ユーザーのメールアドレス
• 発生日時
• ルール名と重大度（Low / Medium / High）
• 対象リソースの種別（Drive / Gmail / Chat）
• リソースのオーナー

調査の優先度は重大度で絞ります。まず重大度 High のみを対象にし、月次で対応しきれる件数に収まるようにします。100 名規模の組織で適切に DLP ルールを設定していれば、High アラートが月に数十件を超えるケースは多くなく、Vault 調査が実際に必要になる対象はさらに絞り込まれます。High を消化した余裕があれば Medium を追加対象にします。Low は原則として集計・モニタリングのみで個別調査はしない、という方針が月次サイクルを継続させる現実解です。

Step 2：Gemini for Workspace ログイベントとの照合

違反ユーザーと同じ期間について、Gemini for Workspace ログイベントを確認します。DLP 違反の発生日時を基準に前後 2 時間以内に Gemini の利用が記録されているかを確認します。

Gemini for Workspace ログイベントには、どのアプリで Gemini を使ったか（Gmail・Docs・Chat・standalone アプリ等）と操作種別が記録されています。「DLP 違反の直前に Drive 上の機密ファイルを閲覧し、その直後に Gemini アプリで会話していた」というパターンが確認できれば、調査優先度を上げる判断材料になります。

時間的な重なりがある場合でも、即座に問題を意味するわけではありません。ただし「AI 経由で機密情報が処理されていた可能性がある」事案として重点調査対象に繰り上げる判断材料になります。

Step 3：Vault での Gemini アプリ会話確認と内容評価

Step 2 で Gemini 利用が確認でき、かつそのユーザーが Gemini アプリ（standalone）を使っていた場合に有効なステップです。Vault の Gemini アプリ検索では以下のパラメータを設定します。

パラメータ	設定内容の例
ユーザー	DLP 違反が発生したユーザーのメールアドレス
日時範囲	DLP 違反の発生日を中心に前後 3 日程度
検索キーワード	DLP ルールが検知した情報種別に対応するワード（例：「個人情報」「機密」「クレジット」等）

検索結果にはマッチした会話に加え、その会話の前後 12 時間以内のやり取りも表示されます（Google Vault ヘルプより）。この「前後 12 時間コンテキスト」は、一つの会話だけでは判断が難しい場合でも前後の文脈から意図を読み取るために役立ちます。

会話内容を確認する際は、次の観点で評価します。

• プロンプトに機密情報の実体（個人情報・顧客データ・社外秘の具体的な内容）が含まれているか
• 社外へのデータ出力を示唆する指示（「〜をメールの文章にして」「〜を英語に翻訳して」等）がないか
• 会話のコンテキストを踏まえて、情報漏えいの意図が認められるか

これらは情シス単独で判断を完結させず、「要対応」と判断した事案は HR・法務と共有したうえで対処する手順を事前に定めておくことが重要です。判断基準そのものをポリシーとして文書化しておくことで、担当者が変わっても運用のばらつきを防げます。

BigQuery Export を使ったスケーラブルな突合

件数が増えてきた場合に備えて、スケーラブルな突合の構成も用意しておきます。Google Workspace には BigQuery Export 機能があり、管理コンソールの監査ログ（DLP 違反ログ・Gemini 利用ログを含む）を BigQuery データセットに継続書き出しすることができます。

両ログを同一データセットへ書き出すことで、ユーザーアドレスとタイムスタンプをキーに相関分析ができます。「DLP 違反が発生したユーザーのうち、前後 N 時間以内に Gemini アプリを利用していた件数」を定期的に集計する作業を自動化できるため、月次の手動突合件数が増え始めたら BigQuery への移行を検討します。BigQuery Export の有効化には対応エディションと初期設定が必要です。管理者ヘルプの BigQuery Export セクションで要件を確認してください。

月次監査サイクルの設計

この突合を定期業務として回す場合、月次サイクルとして組み込む構成が現実的です。

月初 1 週目：データ収集と一次分類

前月分の DLP 違反を抽出し、重大度 High を優先対象にリストアップします。スプレッドシートに「ユーザー / 違反日時 / ルール名 / 重大度 / Gemini 利用フラグ / Vault 調査要否 / ステータス / 担当者コメント」の列を用意し、違反ユーザーごとに Gemini ログイベントを突合して「Gemini 利用あり」「利用なし」のフラグを立てます。

このフラグ付け作業は、High アラートが月 10 件以内であれば 1〜2 時間程度で完了します。件数が大幅に増えてきたら、BigQuery Export による自動集計への移行を検討するタイミングです。

月初 2 週目：Vault 調査（Gemini アプリ利用者のみ）

「Gemini 利用あり」フラグのついたユーザーを対象に Vault 検索を実施します。調査結果を「要対応」「誤検知」「観察継続」の 3 段階に分類し、要対応ケースは HR・法務と連携して対処します。

「要対応」の判断基準は、事前にポリシーとして文書化しておきます。たとえば「プロンプトに顧客の個人情報が実体として含まれている」「外部サービスへの転送を示唆する会話がある」「同一ユーザーが 3 か月以内に 2 回以上 High 違反を起こしている」などの条件を定めておくと、担当者による判断のばらつきを防げます。

月末：集計・レポート・改善

月次の DLP 違反件数・Gemini 共起率・要対応件数を集計します。DLP ルールの精度（誤検知率）を評価し、ルール調整が必要であれば管理コンソールの DLP 設定に反映します。

月次で回し続けると、特定のユーザーや部門での Gemini 利用パターンと DLP 違反の相関が見えてきます。「営業部門で月末に DLP 違反が集中している」「同一ユーザーが繰り返し Medium 違反を起こしている」といったパターンは、DLP ルールの精度改善よりも利用者教育が先に必要なサインである場合があります。月次レポートはルール改善の根拠としてだけでなく、研修・啓発施策の優先度判断にも使えます。

注意点と制約：設計前に知っておくべき 4 つの壁

1. Vault の Gemini 対応はアプリのみ

Vault が捕捉するのは Gemini アプリ（standalone）の会話に限定されます。「Help me write」をはじめとする Workspace アプリ組み込みの Gemini 機能のプロンプトは Vault で確認できません。Workspace アプリ内での Gemini 利用が中心の組織では、Vault での会話確認ができないケースが大多数になります。その場合は管理コンソールの Gemini for Workspace ログイベントで利用傾向を確認するアプローチに切り替えます。

2. 保持・リーガルホールド非対応

Vault の Gemini サポートは検索とエクスポートのみです。保持ポリシーを設定しても Gemini アプリの会話には適用されず、リーガルホールドの設定もできません（Google Vault ヘルプより）。訴訟対応や調査を見越した長期的なデータ保全を想定している場合は、この制約を前提に計画を立てる必要があります。要調査と判定した時点で速やかに Vault からエクスポートして保管する運用が現実的な対応策です。

3. エクスポートにメタデータファイルなし

Gmail や Drive の Vault エクスポートにはメタデータファイルが付きますが、Gemini アプリのエクスポートにはメタデータファイルが含まれません（Google Vault ヘルプより）。証跡として保全する際は、Vault のアクティビティログ（エクスポート実施記録）を補完情報として合わせて保管する運用が必要です。エクスポート実施日時・対象ユーザー・検索条件をスプレッドシートや社内ドキュメントに別途記録しておくことを推奨します。

4. 突合は現状手動

DLP 違反ログと Gemini ログを自動で突合するネイティブ機能は、執筆時点では管理コンソールに提供されていません。BigQuery Export を活用すると相関クエリの自動化が可能になります。まずは手動の月次サイクルで運用を始め、件数が増えてきた段階で BigQuery への移行を検討するのが段階的に無理のないアプローチです。ツール整備より先にサイクルを回す習慣を作ることの方が、実際の監査成熟度向上には貢献します。

Vault を AI 監査の証跡基盤として位置づける

Vault はこれまで「保持・削除・eDiscovery」のツールとして語られてきました。しかし Gemini アプリの会話ログ対応が加わったことで、「AI 利用の監査証跡を取り出せる基盤」という役割も担えます。

DLP 違反との突合は自動化されていない分、月次レビューに組み込んで「誰が・いつ・どんな Gemini 利用をしていたか」を継続的に確認するサイクルを作ることが出発点です。100 名規模の組織であれば DLP 違反は月に数十件程度に収まるケースが多く、Vault 調査が必要になる件数はさらに絞り込まれます。

まず DLP ルールを整備し、違反が上がってきたときに Gemini ログと突合できる体制を整える—このシンプルな仕組みが、Gemini 導入後のガバナンスの現実的な第一歩です。次のアクションとして、管理コンソールのルールログイベントを一度手動でエクスポートして、自組織の DLP 違反の実態を把握することから始めてください。DLP 違反がほぼゼロなら突合サイクルの優先度は低く、違反が継続的に発生しているなら今すぐ始める価値があります。

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

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