Google Vault で Gemini アプリの会話を保持する設計判断

2025年2月に Google Vault がスタンドアロンの Gemini アプリの会話データに対応し、2026年6月には保持ルールと訴訟ホールドが正式に追加されました。この記事では、Vault の Gemini 対応範囲と、コンプライアンス設計を組む際の判断軸を整理します。

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

• Gemini for Workspace を展開済みで、会話データのコンプライアンス設計に手がついていない情シス担当者
• 「Gemini を導入すれば全会話が保持される」と思い込んでいて、実際の対象範囲を確認したい方
• 訴訟対応・監査対応に備えて Gemini 会話の保全方法を整理したい担当者
• 100名規模企業で OU（組織単位）別の保持ポリシーを設計したい方

Google Vault で保持できる Gemini データと保持できないデータ

Vault がサポートするのは、スタンドアロンの Gemini アプリ（gemini.google.com のウェブ版および iOS/Android のモバイルアプリ）で行われた会話のみです。ユーザーが入力したプロンプトと、Gemini が返した応答が対象になります。

一方、Google Workspace の各アプリに組み込まれた Gemini 機能は対象外です。以下の表で対応状況を整理します。

データの発生源	Vault の対応
Gemini アプリ（gemini.google.com / モバイル）	◎ 対応（検索・エクスポート・保持ルール・訴訟ホールド）
Google Docs「文章作成を手伝う」	✕ 非対応
Gmail の Gemini による文章補助	✕ 非対応
Google Chat・Drive のサイドパネル Gemini	✕ 非対応
Google Meet の Gemini 機能	✕ 非対応

対応外の Gemini 利用データは、Vault ではなく管理コンソールの「監査と調査」から利用ログとして確認します。ただし、どのような内容を入力したかは見えません。利用の有無・操作種別・タイムスタンプの把握にとどまります。

この区分が盲点になりやすい理由

「Gemini for Workspace を契約した＝全 Gemini 会話が保全される」と思い込んでいる組織は少なくありません。実際には、保全対象はスタンドアロンの Gemini アプリだけです。ドキュメント上での AI 補完やメール作成補助は Vault の管轄外になります。

コンプライアンス要件に「AI 会話の保全」が含まれる場合は、この区分を法務・経営層と明示的に確認しておく必要があります。「Gemini を使っているから保全できている」という認識が事実と食い違っていると、監査や訴訟の場で問題になります。

特に注意が必要な状況は、Gemini in Workspace を主に使っている部門です。Docs や Gmail での AI 補助はユーザーにとって日常的な作業に馴染んでいるため、Vault で保全できないデータが毎日大量に生まれていても、情シスがそれを認識していないケースがあります。保全されている Gemini 会話と保全されていない Gemini 補助の両方が存在する状態で、後から「全部保全していた」と説明するのは困難です。

Gemini アクティビティ設定が保持の前提条件になる理由

保持ルールや訴訟ホールドを正しく設定しても、対象ユーザーの Gemini アクティビティがオフになっていると、会話データが Vault に蓄積されません。Gemini アクティビティが無効化されている場合、会話データが Google のシステムに記録されないため、Vault が保持する対象データが存在しません。

Gemini アクティビティの設定はユーザー自身が Google アカウントから変更可能です。組織として保持を確実にしたい場合は、管理者側でこの設定を制御する必要があります。管理コンソールから組織全体や OU 単位で Gemini アクティビティの管理ポリシーを設定できます（詳細は Google Workspace 管理コンソールのヘルプを参照してください）。

保持ルールの設計と並行して、「ユーザーが自分でアクティビティを無効にできる状態になっていないか」を確認することが先決です。アクティビティの管理権限を管理者側に集約したうえで保持ルールを有効にする順番が安全です。逆順にすると、ルールを設定した時点でアクティビティが既にオフだったユーザーの会話は遡って保全されません。この点は設計の入口として必ず押さえてください。

Vault の Gemini 対応が段階的に拡張された経緯

2025年2月の対応開始時点では、Vault の Gemini サポートは検索とエクスポートのみでした。保持ルールと訴訟ホールドは「今後のリリースで提供予定」と記載されていた段階です（Google Workspace Updates Blog より）。

2026年6月、Google Vault の公式リリースノートに保持ルール（デフォルト・OU 別カスタム）と訴訟ホールドの対応が記録されました。2026年6月より Rapid Release および Scheduled Release で順次展開が始まっています（Google Workspace Updates Blog より）。

2025年時点で「保持や訴訟ホールドはまだできない」と認識していた担当者は、2026年6月以降に状況が変わっていることを確認してください。以前に確認した結論が、現時点では正確でなくなっています。

OU 別保持ルールの設計判断フロー

Vault の Gemini アプリ保持ルールには、デフォルト保持ルールとカスタム保持ルールの2種類があります。

デフォルト保持ルールは、ドメイン全体を対象に一定期間または無期限で会話を保持します。カスタムルールが設定されていないユーザーに自動的に適用されます。全員に同じ保持期間を設定するだけなら、デフォルトルール1本で完結します。

カスタム保持ルールは OU 単位で設定します。役員と一般社員で保持期間を変えたい場合や、法務部門のみ長期保持が必要な場合に使います。カスタムルールはデフォルトルールよりも優先されるため、「デフォルト1年・法務 OU は3年」のような組み合わせが成立します。保持期間の起算日は「最後のプロンプトまたは応答が送受信された日」からです（Google Vault ヘルプより）。

100名規模企業での設計例

法務部（10名）・経営層（5名）・一般社員（85名）の構成を例にすると、以下のような設計になります。

• 一般社員 OU: デフォルト保持ルール 1年（内部規定の標準保持期間に合わせる）
• 法務部 OU: カスタム保持ルール 5年（訴訟・コンプライアンス対応に備えた長期保持）
• 経営層 OU: カスタム保持ルール 3年（ガバナンス上のトレーサビリティを確保）

この設計では、法務部・経営層は一般社員より長期間の保持が適用されます。保持期間が異なるデータを後から一律に引き伸ばすことは Vault ではできないため、必要な保持期間は最初の設計時点で決める必要があります。

OU 構成が現在どうなっているかの確認も重要です。既存の OU が部門単位ではなくロール単位で切られていると、保持ルールの適用単位と実際の業務単位がズレます。保持ルール専用の子 OU を切る方法もありますが、OU の変更は他の設定（Gmail 配信、Drive 共有など）にも影響するため、慎重に計画してください。

組織規模や要件に応じた判断軸をまとめると、以下のようになります。

• 全社一律で保持期間が同じ → デフォルトルールのみ。設定・管理コストを最小化できる
• 部門・役職ごとに保持期間が異なる → OU 別カスタムルールを追加。OU 設計が保持ルールにも影響するため、既存の OU 構成との整合性を先に確認する
• 特定の調査・訴訟対応が進行中 → 訴訟ホールドを使用。保持ルールとは別の仕組みとして運用する

Gemini 会話データの訴訟ホールドと通常保持の優先順位

訴訟ホールド（リーガルホールド）は、保持ルールとは独立した仕組みです。Google Vault ヘルプによると、優先順位は次のとおりです。

訴訟ホールド > カスタム保持ルール > デフォルト保持ルール

訴訟ホールドが設定されている期間中は、ユーザーが Gemini アプリのプロンプトを手動で削除したり、Gemini アクティビティ設定をオフにしたりしても、Vault 管理者からはデータが保全された状態で見えます。ホールドは明示的に解除されるまで無期限に継続します。

訴訟ホールドの運用で事前に決めておくべきこと

訴訟や調査が発生してから手順を考えていると、設定完了までの間にデータが消える可能性があります。事前に決めておくべき運用ポイントは以下の4点です。

• ホールドをいつ設定するか: 法務部門から「調査対象者が確定した」連絡が入った時点を起点にする。口頭連絡だけでは抜け落ちるため、連絡チャネルを文書化しておく
• 誰が設定するか: Vault 管理者の役割を持つ担当者を事前に指定しておく。担当者の異動・退職時のバックアップも考慮する
• ホールド対象の範囲: ユーザー単位か OU 単位かを案件の性質に応じて判断する。範囲が広すぎるとエクスポート量が増え後処理が重くなる
• ホールドの解除条件: 調査終了・和解・訴訟確定など、解除のトリガーを定義しておく。解除後は通常の保持ルールに戻るため、残りの保持期間が十分かを確認する

これらを「Vault 運用手順書」として整備しておくと、担当者が交代した際も迷わず対応できます。

設計前に確認すべき前提条件

保持ルールや訴訟ホールドの設計に入る前に、以下の前提条件を確認します。

Vault が利用できるエディションかどうかを最初に確認してください。すべての Google Workspace エディションで Vault が使えるわけではなく、対応エディションは管理者ヘルプに記載されています。Gemini for Workspace のライセンスとは別に、Vault の利用権限を確認する必要があります。

次に、Gemini アクティビティの管理状態です。ユーザーがアクティビティをオフにしていると保持が機能しません。管理コンソールで組織として Gemini アクティビティを制御できる状態になっているかを確認します。

さらに、組織の OU 構成が保持ポリシー設計に適しているかを確認します。部門ごとに保持期間を変える場合は、その部門が独立した OU として切られていることが前提です。OU 構成が整理されていない場合は、保持ルール設計の前に OU の見直しが必要になります。

最後に、法務・コンプライアンス部門との要件合意です。「何年保持するか」「訴訟ホールドの発動条件は何か」は、情シスだけで決められる内容ではありません。設計を始める前に法務と合意形成を済ませておくことで、設定後の変更コストを抑えられます。

設計の優先順位まとめ

Vault の Gemini 保持設計において、情シスが判断すべき順番を整理すると次のようになります。

1. Vault が利用できるエディションかを確認する
2. 法務・コンプライアンス部門と保持要件を合意する
3. Gemini アクティビティの管理状態を確認し、ユーザーが勝手に無効化できない設定にする
4. コンプライアンス要件で求められる保全対象が Vault のスコープ内かを確認する。Gemini in Workspace の非対応部分を含む要件であれば、別途対応を検討する
5. 全社一律か OU 別かで保持ルールを設計し、OU 構成の整合性も確認する
6. 訴訟・調査対応の手順（ホールド設定フロー・担当者・解除条件）を文書化しておく

保持ルールを設定したことよりも、「保持されていないデータのスコープを把握している」状態にあることのほうが、コンプライアンス上は価値があります。Gemini in Workspace の利用ログ管理も含めて設計の全体像を描いておく必要があります。Gemini の普及が進むほど、この設計を後回しにした場合のリカバリコストは大きくなります。

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

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