Google WorkspaceのGemini監査ログ運用ルール|プライバシーを守りながらAI利用を可視化する方法

Google WorkspaceのGemini監査ログで重要なのは「どこまで見るか」

Google WorkspaceにGeminiを導入すると、Gmailでの文章作成、Docsの要約、Sheetsでの分析、Meet、Drive、Geminiアプリなど、生成AIが日常業務のさまざまな場面に入り込むようになります。

そこで企業に求められるのが「AIがどのように利用されているのか」を把握する仕組みです。

しかし、監査を強化すれば安全になるとは限りません。

従業員が入力したプロンプトや利用履歴を必要以上に保存・閲覧する仕組みを作れば、今度はプライバシーや従業員監視という別の問題が発生します。

Google Workspace環境でのAIガバナンスでは、

「すべてを見る」のではなく、「必要な情報を、必要な期間だけ、必要な人が確認する」

という考え方が重要です。

添付資料でも、Geminiの監査を「可視性」と「プライバシー」のバランスとして捉え、メタデータによる利用状況の把握と、必要時だけコンテンツを保全・調査する多層的な設計が提案されています。

Geminiの監査では「利用状況」と「会話内容」を分けて考える

Gemini監査を設計する際、最初に理解しておきたいのがログの種類です。

1. Geminiの利用状況を確認する監査ログ

GoogleはAdmin SDK Reports APIで、Google Workspaceアプリ内におけるGeminiの利用イベントを取得できる仕組みを提供しています。

gemini_in_workspace_appsを利用することで、Workspaceアプリで発生したGemini関連のアクティビティを取得できます。

Google公式ドキュメントでは、Gemini in Workspace Appsのログは2025年6月20日以降を対象とし、最大180日のローリング履歴が維持されるとされています。

記録される情報には、例えば、

  • Geminiが利用されたアプリ
  • 利用者
  • 発生日時
  • AIによる生成・要約などのイベント区分
  • Gemini機能が呼び出された場所
  • 一部の端末・アクセス関連情報

などがあります。

つまり、「誰が、どのアプリで、どのようなAI機能を利用したか」を把握するためのメタデータです。

企業が通常の利用状況を把握するのであれば、まずこのレベルから始めるのが現実的です。

2. Geminiアプリの会話内容を保全するGoogle Vault

一方、法務調査や内部不正調査などでは、メタデータだけでは判断できない場合があります。

そこで利用されるのがGoogle Vaultです。

2026年6月には、VaultでGeminiアプリの会話について保持ルールや記録保持を設定できるようになりました。現在は、対象となるGeminiアプリについてユーザーが入力したプロンプトとGeminiの回答を保持、検索、記録保持、書き出しできます。

ただし、ここで重要な注意点があります。

Google Vaultが保全できる「Geminiアプリの会話」と、「Gemini in Google WorkspaceのすべてのAI利用」は同じではありません。

Google公式情報では、VaultによるGeminiアプリの保全対象にはプロンプトと回答が含まれる一方、Gemini for Google WorkspaceのデータはVaultのGeminiアプリ向け保全対象には含まれないとされています。

したがって、

監査ログ=すべてのプロンプト全文を管理者が読める

という理解は正確ではありません。

「利用量の把握」と「監査」を混同しない

Google WorkspaceにはGeminiの利用状況を確認するレポートもあります。

管理者は組織単位やユーザー単位で、過去28日間のGemini利用状況やアプリ別の活用状況などを確認できます。

これは非常に便利ですが、本来の目的は主に導入状況や利用傾向の把握です。

例えば、

「Geminiを使っている社員は何人いるのか」

「Docsでは使われているがSheetsでは使われていない」

「導入したものの利用率が上がっていない」

といった課題の把握には有効です。

しかし、この利用データをそのまま個人の人事評価へ結び付ける設計は慎重に考える必要があります。

利用回数が多いことと、業務成果が高いことは同義ではないからです。

監査ログはまず、

セキュリティ、コンプライアンス、事故調査、AI利用状況の把握

を目的として設計し、人事評価とは切り離して考えるのが基本です。

プロンプト全文を常時保存する運用は避ける

Gemini監査で陥りやすいのが、

「事故が起きたときに困らないよう、すべてのプロンプトを保存しておこう」

という考え方です。

一見すると安全に見えますが、ログそのものが新しい機密情報データベースになってしまいます。

プロンプトには、

  • 顧客名
  • メール本文
  • 契約内容
  • 社員情報
  • 採用情報
  • 営業案件
  • 未公開の商品情報
  • 社内の相談内容

などが含まれる可能性があります。

つまり、AIへの入力情報を無条件に保存すると、「AIから情報を守るための監査ログ」が逆に情報漏えい時の高価値データになる可能性があります。

個人情報保護委員会も、個人情報を生成AIに入力する場合は利用目的に必要な範囲であることを確認し、入力データが応答生成以外の目的で利用される場合の取扱いにも注意するよう示しています。

Google Workspaceだからこそ利用できるデータ保護機能

Google Workspace with Geminiには、既存のWorkspace環境のセキュリティ管理をAI利用にも組み合わせられるという特徴があります。

Googleは、対象となるWorkspace環境では、組織のコンテンツを許可なくドメイン外の生成AIモデルの学習に使用せず、既存のWorkspaceのデータ保護策が適用されると説明しています。

ただし、「Google側で学習されない」ことだけで企業のAIガバナンスが完成するわけではありません。

企業側でもアクセス制御や情報分類を設計する必要があります。

DLPで機密情報の流れを管理する

Data Loss Prevention(DLP)を利用すれば、個人情報や機密情報などについて、組織のルールに沿ったデータ保護を設計できます。

Google Workspace with Geminiには既存のWorkspaceのデータ保護管理が適用され、DLPもその一つとして位置付けられています。

「AIを禁止する」のではなく、

重要情報そのものを適切に分類・制御する

という設計へ移行することがポイントです。

Context-Aware Accessで利用環境を限定する

より高いセキュリティが必要な組織ではContext-Aware Accessも選択肢になります。

ユーザーIDだけでなく、端末のセキュリティ状態、場所、IPアドレスなどのコンテキストを利用してWorkspaceへのアクセスを制御できます。

例えば、

「管理端末からのみ利用可能」

「特定のネットワーク条件を満たした場合のみアクセス」

といったゼロトラスト型の運用が考えられます。

Google Vaultの閲覧権限こそ厳しく管理する

監査機能を導入するときに見落とされやすいのが、監査する側の権限です。

Geminiアプリのプロンプトや回答をVaultから検索・書き出せるようになれば、その権限自体が非常に強力になります。

したがって、

  • 日常運用担当者
  • セキュリティ担当者
  • Vault管理者
  • 法務・コンプライアンス担当者

の権限を分離する必要があります。

さらにGoogle Vaultでは、設定によってエクスポート時にMulti-Party Approvalを要求できます。Vault UIからのエクスポートについて、別の管理者による承認を必要とする仕組みです。

これは、

「管理者だから自由に社員のAI会話を持ち出せる」状態を作らない

ための重要な統制になります。

ログの保持期間は「長いほど安全」ではない

監査ログやAI会話の保存期間も重要です。

「念のため永久保存」は推奨できません。

保存期間が長くなれば、

  • 漏えいした場合の影響
  • 開示対象となるデータ量
  • 管理コスト
  • 従業員のプライバシーへの影響

も大きくなります。

Google Vaultでは、Geminiアプリについて組織部門単位でカスタム保持ルールを設定でき、1日から36,500日、または無期限を選択できます。保持期間は、その会話で最後のプロンプトまたは回答が送受信された時点を基準に計算されます。

重要なのはGoogleが何日保存できるかではありません。

自社が何のために何日必要なのかを先に決めることです。

企業が策定すべきGemini監査ログ運用ルール

実務では、次の4段階で整理すると運用しやすくなります。

ステップ1:監査目的を明文化する

まずログを取得する目的を決めます。

例えば、

  • セキュリティ事故調査
  • 情報漏えい調査
  • コンプライアンス確認
  • Gemini利用状況の分析
  • AI導入効果の把握

などです。

「将来使うかもしれないから」という理由だけでログを集めないことが重要です。

ステップ2:ログごとに保持期間を設定する

すべてのログを同じ期間保存する必要はありません。

利用状況を見るメタデータと、Geminiアプリの会話内容では情報のセンシティブさが異なります。

業務目的、法令、契約、社内規程、インシデント対応期間などから必要な保存期間を設定します。

ステップ3:閲覧権限と承認フローを分離する

通常の利用状況確認ではメタデータだけを見る。

プロンプトや回答の内容確認は、

「重大なインシデントなど合理的な理由がある場合だけ」

とします。

さらに閲覧やエクスポートには複数人承認を組み合わせることで、管理者による目的外閲覧を防ぎます。

ステップ4:従業員へ監査内容を説明する

技術設定だけでは十分ではありません。

従業員に、

  • 何が記録されるのか
  • なぜ記録するのか
  • 誰が確認できるのか
  • どのくらい保存するのか
  • どんな場合に内容を調査するのか

を明示します。

個人情報保護委員会のガイドラインでも、安全管理措置としてアクセス制御、利用状況の記録、取扱状況の確認、従業者教育などが示されています。

監査の存在を隠すのではなく、透明性を高めることがAI利用への心理的安全性にもつながります。

中小企業では「全部入り」から始める必要はない

Google Workspaceの高度な管理機能を見ると、

「DLPもVaultもCAAもSIEMも導入しなければならない」

と感じるかもしれません。

しかし、中小企業の場合は段階的な導入で十分です。

まずは、

① Geminiの利用範囲を決める
② 入力禁止情報を定義する
③ 管理者権限を限定する
④ 利用状況を定期確認する
⑤ インシデント発生時の調査手順を決める

ところから始めます。

そのうえで、取り扱うデータの重要度に応じてVault、DLP、Context-Aware Access、Multi-Party Approvalなどを追加していく方が現実的です。

大切なのは、監査機能の多さではありません。

「誰が、何を見ることができ、どのような条件なら詳しく調査できるのか」が明確になっていることです。

まとめ

Google Workspace環境でGeminiを導入すると、AI活用を可視化できる監査機能も充実してきます。

一方で、監査能力が高まるほど、管理者による過剰な閲覧やログ自体への機密情報集中といった新しいリスクも生まれます。

そのためGemini監査では、

メタデータによる通常監視と、必要時だけ行うコンテンツ調査を分離すること

が重要です。

Admin SDK Reports APIによる利用状況の把握、Google Vaultによる必要なデータの保全、DLPやContext-Aware Accessによる予防的統制、Multi-Party Approvalによる管理者権限の統制を組み合わせることで、「見える化」と「プライバシー」の両立が可能になります。

生成AIガバナンスの目的は、従業員を監視することではありません。

安心してAIを業務利用できる境界線を組織として明確にすること。

これこそが、Google WorkspaceとGeminiを継続的に活用するための運用設計といえるでしょう。

コメント

この記事へのコメントはありません。

関連記事