3行まとめ
Gemini appの会話に対して、Default retention rules、Custom retention rules、Litigation holdsを扱えるようになった。
standaloneのGemini app on web/mobileが中心で、Gemini in Workspace apps全体を一括で扱う話ではない。
対象データ、対象エディション、Vaultライセンス、検索・エクスポート結果を順番に確認する。
速報として読むより、自社の情報管理ルールに落とし込むための確認項目として読むと整理しやすくなります。
- Google Vaultは、Gemini appの会話について、検索・エクスポートに加えて保持ルールと訴訟ホールドを扱えるようになった。2026年6月11日のGoogle Workspace Updates発表では、Rapid Release domainsとScheduled Release domainsのどちらもAvailable nowとされている。
- ただし対象はstandaloneのGemini app on web/mobileだ。GmailやDocsなどに組み込まれたGemini in Google Workspace機能、media files、Gems、Gemini for Google Workspace dataまで一括でVault対象になったと読まないほうがよい。
- 管理者は、対象エディションだけでなく、Vaultライセンス、Gemini conversation history、OU設計、保持期間、hold運用、検索・エクスポート権限を確認したい。Vault API対応は公式発表上「coming weeks」で、2026年6月15日JST時点では今後確認する項目として扱う。
Google Workspace Updatesは2026年6月11日、Google VaultがGemini appの保持ルールと訴訟ホールドに対応したと発表した。6月12日のWeekly Recapにも再掲されており、Workspace管理者にとっては「AI利用ログをどこまでeDiscoveryと情報ガバナンスの対象に入れられるのか」を確認するきっかけになる。
この更新は便利な一方で、読み違えると危ない。Geminiという名前が同じでも、standaloneのGemini app、GmailやDocs内のGemini機能、添付メディア、Gems、Google Workspace側のデータは同じ扱いではない。保持ルールやholdは、削除やpurgeにも関わるため、機能を見つけたらすぐ全社適用するより、対象範囲を分けて小さい単位で検証するほうが現実的だ。
この記事では、2026年6月15日JSTに確認したGoogle Workspace UpdatesとGoogle Vault Helpの一次情報をもとに、管理者、法務・コンプライアンス担当、情報システム担当が見るべき順番を整理する。2026年6月のAlphabet関連アップデートを時系列で追う場合は、<a href="https://googl-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月 重要トピックまとめ</a>も合わせて確認してほしい。
Alphabet Watch JapanはAlphabetおよびGoogleとは非提携のメディアだ。本記事はGoogle Workspaceの製品・管理者向け確認メモであり、法務助言、投資助言、売買推奨ではない。
Google VaultでGemini appに何が追加されたのか
検索・エクスポートの延長ではなく、保持期間と保存義務を管理する領域が追加された点が中心です。
今回のポイントは、VaultがGemini app conversationsを「探して取り出す」段階から、「どれだけ残すか」「法的・保存義務の対象として固定するか」まで広げたことだ。
公式発表では、管理者がGemini appに対して次の操作を作成、更新、削除できるようになったと説明されている。
- Default retention rules: Gemini appに対する有限または無期限の基本保持ルール。
- Custom retention rules: OUまたはドメイン全体を対象にしたカスタム保持ルール。
- Litigation holds: 特定OUまたはユーザーリストを対象にしたGemini appデータのhold。
2026年6月11日の発表で増えた操作
根拠
Google Workspace Updatesの2026年6月11日記事は、Gemini app on web/mobileについて、従来はVaultで検索とエクスポートが可能だったが、今回の更新で保持ルールと訴訟ホールドも扱えるようになったと説明している。Vault HelpのWhat's newでは、2026年6月10日の項目として、Gemini app conversationsに対するretention rules and holdsのサポートが記載されている。
このため、記事の中心は「Gemini appの会話をVaultの情報ガバナンスに入れるには、どの範囲で、どの順番で確認するか」になる。単なる新機能紹介より、既存のVault運用へどう接続するかが大事だ。
注意点
検索とエクスポートは今回初めて出た機能ではない。Vault HelpのWhat's newでは、Gemini app conversationsのsearch/export対応は2025年2月4日の更新として記録されている。今回の追加は、保持ルールとholdを通じて、データの保存期間や保存義務を制御できるようにする部分だ。
また、公式発表はVault API supportについて「coming weeks」としている。2026年6月15日JST時点で、保持ルールやholdのAPI自動化がすでに使えると断定するのは避けたい。管理コンソールやVault UIでの確認と、API対応待ちの確認項目を分けておくのが安全だ。
Weekly RecapとVault変更履歴で見る直近性
確認項目
直近性は3点で確認できる。
- Google Workspace Updatesの発表日: 2026年6月11日。
- Google Workspace Updates Weekly Recapの掲載日: 2026年6月12日。
- Vault HelpのWhat's new: 2026年6月10日にGemini app conversationsの保持ルールとhold対応を記載。
発表記事のRollout paceは、Rapid Release domainsとScheduled Release domainsのどちらもAvailable nowだ。したがって、対象エディションとVaultライセンスがそろっている組織では、管理画面側で確認に入る段階と読める。
評価基準
管理者が最初に確認すべきなのは、機能が見えるかどうかだけではない。自社のGemini app利用者、対象OU、Vaultライセンス、既存の保持ポリシー、法務・監査部門の要件がそろっているかを見たい。保持ルールは、短い期間を指定すると過去データのpurgeに影響する可能性があるため、表示されたからすぐ全社へ入れる運用は避けたい。
最初に切り分ける対象範囲
対象範囲を先に分けることで、保持できるデータと保持できるように見えてしまうデータの混同を避けられます。
この更新で最も重要なのは、対象範囲の切り分けだ。Geminiという名前だけでまとめず、Vault HelpのSupported services & data typesに沿って、何が対象で何が対象外かを先に見る。
Vault対象はGemini app on web/mobile
根拠
公式発表は、今回の更新がGemini app on web/mobileに適用されると明記している。Vault HelpのSupported services & data typesでは、Gemini appについて、retention rules、holds、search、exportの対象として扱えることが示されている。
Vaultが保持、hold、検索、エクスポートできるGemini appデータは、ユーザーが入力したpromptと、Gemini appが生成したresponseだ。管理者はこの2つを中心に、検索結果、エクスポート、保持期間を設計することになる。
確認項目
自社で最初に見る項目は次の通りだ。
- Gemini appが組織で有効か。
- どのOU、グループ、利用者区分でGemini appを使っているか。
- 利用者が企業アカウントでGemini appを使っているか。
- Vaultを使う管理者と法務担当者の権限が分離されているか。
- Gemini app会話を業務記録として扱う社内ルールがあるか。
ここで対象が曖昧なまま保持ルールへ進むと、後で「残したつもりのものが残っていない」「消えると思っていたものがVaultには残る」という説明のねじれが起きる。
Gemini in Workspace appsは別扱い
条件
公式発表のApplication scopeでは、今回の更新はGemini appに特化しており、GmailやDocsなどに組み込まれたGemini in Google Workspaceの機能には適用されないと説明されている。たとえばGmailやDocsのHelp me writeのような統合機能を、今回のGemini app保持・hold対応と同じ範囲で扱わないほうがよい。
この切り分けは、導入企業ほど重要になる。利用者から見ると「Geminiに聞いた」「Geminiで書いた」という体験は似ているが、管理者が証跡、保持、検索、エクスポートを設計するときは、サービスごとの対象データを分ける必要がある。
注意点
「Gemini in Workspace appsは何もVaultで扱えない」と広げすぎるのも危険だ。この記事で言えるのは、今回の発表がGemini app on web/mobileの保持ルールとhold対応であり、Workspaceアプリ内のGemini機能を同じ更新範囲として扱ってはいけない、ということだ。
Gmail、Drive、Meet、Chatなどは、それぞれVaultの対象サービスとして別のルールを持つ。Gemini関連のAI操作がどのサービスのデータとして残るのかは、個別のヘルプや管理設定で確認したい。
media files、Gems、Gemini for Google Workspace dataの扱い
対象外
Vault HelpのSupported services & data typesでは、Gemini appについて対象外のデータも明示されている。Vaultは、Gemini appのpromptに添付されたmedia files、Gemini appのresponseとして生成されたmedia files、Gems、Gemini for Google Workspace dataをretain、hold、search、exportしない。
これは、画像やファイルを使ったAI相談、Gemsを使ったカスタム体験、Workspaceアプリ内のAI機能まで、VaultのGemini app対応だけで証跡がそろうわけではないという意味だ。
確認項目
画像、音声、動画、Driveファイル、社内文書を含む利用が多い組織では、VaultのGemini app対応だけで監査要件を満たせるかを慎重に見る必要がある。Google Drive、DLP、Admin console、監査ログ、利用規程、エクスポート後の保管ルールを合わせて棚卸ししたい。
WorkspaceのAI機能や権限設計を横断して確認する場合は、<a href="https://googl-watch.blog.mo-gmo.com/googl-42-gemini-in-chrome-rollout-permissions-check/">Gemini in Chromeの地域拡大と管理者権限の記事</a>も参考になる。Gemini機能は提供条件、管理者設定、ユーザーの見え方がサービスごとに違うためだ。
保持ルールと訴訟ホールドの優先順位
- 1Default retention rules
Gemini app messagesをどのくらい保持するかという全体方針を決める。
- 2Custom retention rules
組織部門などの単位で、全体方針とは異なる保持期間や対象範囲を設定する。
- 3Litigation holds
法的・監査上残す必要があるデータを、通常の削除ルールから守る。
- 4削除影響の確認
保持ルールの変更や期限切れが、期待しないpurgeにつながらないかを事前に確認する。
保持ルールは運用方針、holdは保存義務の保護として読み分けると判断しやすくなります。
VaultでGemini appを扱うときは、保持ルールとholdを同じ強さで考えないほうがよい。保持ルールは保存期間を決める運用ルールで、holdは法的・保存義務に関わるデータを通常の削除ルールから守る仕組みとして読む。
Default retention rulesで全体方針を決める
条件
Default retention rulesは、Gemini app messagesをどのくらい保持するかという基本方針にあたる。公式発表では、有限または無期限の保持期間を設定できるとされている。Vault Helpのretainページでは、Gemini appの保持期間は、会話内の最後のpromptまたはresponseが送受信された時点から始まり、期限が過ぎると会話全体がpurgeされると説明されている。
この考え方は、メールの1通単位の感覚とは少し違う。Gemini appではpromptとresponseを含む会話が単位になりやすく、最後のやり取りから何日残すかを決めることになる。
注意点
Vault Helpのcustom retention rule手順では、保持期間を指定する場合、1日から36,500日まで入力できるとされている。同時に、新しいルールを送信すると、保持期間を超えたGemini app messagesがすぐpurgeされる可能性があるという警告もある。purgeされたデータは、利用者が残しておきたいと思っていたものを含む可能性がある。
Default ruleを決めるときは、まずテスト用OUや限定ユーザーで、保持期間、検索結果、エクスポート、削除後の見え方を確認したい。全社へ短い保持期間を一気に適用するのは、運用上の失敗が大きくなりやすい。
Custom retention rulesでOU単位の例外を作る
条件
Custom retention rulesは、OUまたはドメイン全体に対して例外的な保持方針を作るときに使う。法務、監査、教育機関、営業、開発、サポートなど、Gemini appの使い方と保存要件が違う部門を分ける場合に候補になる。
たとえば、一般部門では短めに保持し、規制対象業務や監査対象部門では長く保持する、といった設計が考えられる。逆に、保存義務より削除義務が強いデータを扱う部門では、法務・プライバシー担当と保持期間を慎重に決める必要がある。
確認項目
Custom ruleを作る前に、次を確認したい。
- Gemini appの利用者がどのOUにいるか。
- OUが業務上の保存要件と合っているか。
- Vault add-onを一部ユーザーだけに付与していないか。
- 既存のVault保持ルールと競合しないか。
- ルール変更時の承認者、記録方法、レビュー日が決まっているか。
OU設計が古いままだと、保持対象と実際の業務リスクがずれる。Vaultで細かく制御できるようになった分、管理ディレクトリ側の整理も必要になる。
Litigation holdsは保存義務の対象を固定する
根拠
Vault Helpのholdページでは、Gemini app messagesにholdを設定して、法的または保存義務を満たすために無期限で保持できると説明されている。holdは個別アカウント、またはOU全体に適用できる。さらに、holdは通常の保持ルールを上書きし、通常ルールでpurgeされるはずのGemini messagesを保護する。
このため、holdは「念のため全部残す」ための軽いスイッチではない。対象者、対象OU、matter、承認者、解除条件を決めて使うべき機能だ。
注意点
Vault Helpは、最上位OUにholdを設定することを強く推奨していない。最上位OUを選ぶと、組織内のGoogle Workspaceアカウントを削除できなくなる可能性があるためだ。また、Vault対応ライセンスをユーザーから外すと、holdがGemini messagesを削除から保護しなくなり、削除対象のデータがすぐpurgeされて復元できない可能性もある。
訴訟ホールドは法務領域に近い。情報システム部門だけで判断せず、matterの作成、対象者、解除条件、ライセンス保持、退職者対応を法務・コンプライアンス担当と合わせて決めたい。
ユーザー設定よりVaultが優先される場面
- 1会話履歴の設定
Admin consoleのGemini conversation historyで、会話を保存するか、どのくらいで自動削除するかを決める。
- 2ユーザー側の削除
ユーザーが画面上で会話を消しても、Vaultの保持ルールやholdの対象なら管理上残る場合がある。
- 3Vaultのretainとhold
保持ルールやholdが有効なデータは、ユーザー設定とは別に検索・エクスポートの対象になり得る。
- 4説明責任
利用者には、画面上の表示と企業側の保存義務が一致しない場合があることを明確に伝える。
ここは優劣ではなく、利用者向け表示と企業の保存義務が別レイヤーで動く場面として整理します。
今回の更新で利用者への説明が難しくなるのは、「ユーザー画面から消えること」と「Vault上で保持されること」が一致しない場合だ。
Admin consoleのGemini conversation historyとの関係
条件
Vault Helpは、Admin consoleのGemini conversation history設定で、Gemini app conversationsを保存するか、どのくらいで自動削除するかを決められると説明している。そのうえで、会話がどう保存されているかにかかわらず、管理者はVaultでGemini app conversationsをretain、hold、search、exportできるとしている。
つまり、Admin console側の会話履歴設定とVault側の保持・holdは、同じ意味ではない。利用者に見える履歴の扱いと、組織がeDiscoveryや情報ガバナンスとして保持する扱いを分けて説明する必要がある。
確認項目
管理者は、次の一覧を並べて見ると判断しやすい。
- Gemini conversation historyの組織設定。
- Gemini appを使えるOUと利用者。
- Vault retention rulesの対象OU。
- active holdの対象者またはOU。
- ユーザー削除、退職者、ライセンス解除の運用。
- 利用者向けの社内通知と利用規程。
ユーザーが「履歴を消したから組織にも残らない」と理解していると、後で信頼を損ねる。社内ルールでは、ユーザー画面、管理者画面、Vault、エクスポート後の保存先を分けて説明したい。
ユーザー削除やGemini Apps activityとの関係
注意点
公式発表では、ユーザーが会話を削除したりactivity settingをオフにしたりしても、active Vault holdが保持を求める場合、そのデータはユーザーからは隠れるが、Vault管理者には完全に保持され見える例が示されている。Vault Helpでも、ユーザーの行動や設定がGemini app conversationsの削除につながる場合でも、管理者はVaultでretain、hold、search、exportできると説明されている。
ここは、監視を煽るように書くべきところではない。重要なのは、組織がAI利用ログを情報資産として扱うなら、ユーザーへの通知、管理者権限の分離、検索・エクスポートの承認、監査ログの確認が必要になるという点だ。
評価基準
最低限、次の状態になってから運用に入るのがよい。
- 利用者向けに、Gemini app会話が組織の保持・検索対象になり得ることを説明している。
- Vault管理者と通常のWorkspace管理者の権限を分けている。
- exportできる人、export後に見られる人、保管場所が決まっている。
- 法務・監査目的以外の検索を制限する内部ルールがある。
- hold解除やライセンス解除時のpurgeリスクを確認している。
対象エディションとライセンスを確認する
エディションの対象範囲と、Vaultを実際に操作できる条件は分けて確認する必要があります。
「Availabilityに載っている」と「自社のユーザーと管理者がVaultで扱える」は同じではない。公式発表の対象エディションと、Vault Helpのライセンス要件を分けて見る。
公式発表のAvailabilityを確認する
根拠
2026年6月11日のGoogle Workspace Updates発表では、Availabilityとして次が記載されている。
- Business: Business Plus。
- Other Editions: Frontline Standard and Plus、Enterprise Essentials Plus。
- Enterprise: Enterprise Standard and Plus。
- Education: Education Fundamentals、Standard and Plus。
- Other Add-ons: Vault。
この一覧は、今回のGemini app保持・hold対応がどのエディションやadd-onに出るかを見るための出発点になる。
注意点
実際の運用では、契約、ユーザーへのライセンス付与、管理者ライセンス、管理権限、Gemini appの有効化状態を合わせて確認する必要がある。特にVault add-onを一部のユーザーだけに付けている組織では、Gemini app利用者全員が保持・検索対象になっているとは限らない。
Vaultライセンスはユーザーと管理者の両方を見る
根拠
Vault HelpのVaultページでは、ユーザーのデータを検索・保持するには、対象ユーザーがGoogle Vaultを含むGoogle Workspaceライセンスを持ち、管理者側もGoogle Vaultを含むライセンスを持つ必要があると説明されている。Vaultがeditionに含まれる場合は組織内のユーザーと管理者に自動でVaultライセンスが割り当てられるが、add-onの場合は割り当て対象の確認が必要だ。
確認項目
管理者は次を確認したい。
- Gemini app利用者にVault対応ライセンスがあるか。
- Vaultを操作する管理者にVault対応ライセンスがあるか。
- 法務担当アカウントや監査担当アカウントに必要な権限があるか。
- 退職者や休職者のライセンスを外す運用が、holdや保持要件と矛盾していないか。
- 教育機関では、教職員、生徒、管理者でライセンスと利用条件が分かれていないか。
管理者が優先して確認するチェックリスト
- 今日見る項目
対象エディション、Vaultライセンス、Gemini app on web/mobileの利用状況、既存の会話履歴設定を確認する。
- 今週決める項目
Default retention rulesとCustom retention rulesの方針、組織部門ごとの例外、保存期間を決める。
- 法務・監査と合わせる項目
Litigation holdsの対象、検索・エクスポートの手順、取得後データのアクセス範囲を確認する。
- 更新を追う項目
Vault API supportや公式ヘルプの追記を確認し、自動化の判断を急ぎすぎない。
AI利用ログの扱いは、情報システムだけでなく法務・監査の判断も含めて順番に固めます。
今回の更新は、すぐ使う機能というより、AI利用ログをどの責任範囲で扱うかを決める管理者向けの更新だ。確認の順番を「今日見る」「今週決める」「法務と合わせる」「API待ちで追う」に分けると、議論が進めやすい。
今日見る項目
確認項目
まず確認するのは、次の項目だ。
- Gemini appが有効なOU。
- Gemini appの実利用者。
- Vault対応エディションまたはVault add-on。
- 対象ユーザーとVault管理者のライセンス。
- Gemini conversation history設定。
- 既存のVault保持ルールとhold。
- Gemini appでmedia filesやGemsを使う業務があるか。
- 検索・エクスポート権限を持つ管理者。
評価基準
「対象範囲を説明できる」「保持期間を決める責任者がいる」「テスト用OUがある」「export後の保存場所が決まっている」状態が最低ラインだ。ここが曖昧なら、保持ルールの作成より先に運用設計を進めたい。
今週決める項目
確認項目
次に、ルール設計へ進む。
- Default retention ruleを置くか。
- Custom retention ruleを置くOU。
- 保持期間を有限にするか無期限にするか。
- holdを設定できる担当者と承認フロー。
- matterの命名規則。
- 検索条件の保存方法。
- exportファイルの保存先、アクセス権、削除期限。
- 利用者向けの通知文。
Workspace内の承認や監査文脈も合わせて見たい場合は、<a href="https://googl-watch.blog.mo-gmo.com/googl-53-google-drive-alignment-approvals-workspace-checklist/">Google Driveのalignment approvals記事</a>で、共同編集と承認記録の切り分けも確認できる。
注意点
保持ルールの変更は、過去データのpurgeに影響する可能性がある。短い保持期間を設定してしまうと、対象期間を過ぎたGemini app conversationsが削除対象になる。テスト用OUで検索、export、削除後の見え方を確認し、承認フローを通してから広げるほうが安全だ。
法務・監査と合わせる項目
条件
訴訟ホールド、保存期間、削除義務、教育機関の生徒データ、規制対象業務の会話データは、情報システム部門だけで判断しないほうがよい。Gemini appは日常的な相談にも使われるため、個人情報、機密情報、顧客情報、研究開発情報が含まれる可能性がある。
確認項目
法務・監査担当とは、次を合わせたい。
- どの種類のGemini app conversationsを保存義務の対象にするか。
- holdの対象者、対象OU、解除条件。
- ユーザー通知と社内規程。
- export後の保管場所とアクセス権。
- 監査ログと操作記録。
- 削除不能データについての説明責任。
- 地域、業界、教育機関ごとの規制要件。
AIガバナンスを広く見る場合は、<a href="https://googl-watch.blog.mo-gmo.com/googl-37-ai-content-verification-synthid-c2pa/">GoogleのAIコンテンツ識別拡大の記事</a>も合わせて読むと、AI利用ログの保持だけでなく、生成物の識別や検証の論点へつなげやすい。
検索・エクスポートで確認しておくこと
Message、Topic、Owner、Date and timeなどが、監査や法務確認で必要な粒度になっているかを見る。
ユーザーのpromptだけでなく、Gemini app responseと前後の文脈を合わせて確認する。
取り出したデータを誰が見られるか、どこに保管するか、再共有をどう制限するかを決める。
検索条件、対象期間、対象ユーザー、エクスポート形式を記録し、同じ確認を再現できるようにする。
設定できることと、監査時に説明できることは別です。検索とエクスポートの実地確認まで含めて運用を見ます。
保持ルールとholdを設定するだけでは、運用できているとは言い切れない。実際にVaultで検索し、期待通りの会話が出るか、exportの形式が監査・法務の期待と合うかを確認したい。
Searchではpromptとresponseのペアを確認する
根拠
Vault HelpのUse Vault to search Gemini appでは、検索結果の各行に、Message、Topic、Owner、Date and timeが含まれると説明されている。MessageはユーザーpromptとGemini app responseで構成され、一覧では一部が省略されることがあるが、exportすると完全なpromptとresponseが表示される。
検索対象は、specific accountsなら最大5,000個のメールアドレスを入力でき、OUを指定する場合はそのOUと子OUのアカウントが検索される。日付範囲を指定すると、その範囲に送信されたpromptとresponseが返る。
確認項目
テスト検索では、次を確認したい。
- 特定アカウントで検索できるか。
- OU検索で子OUが含まれるか。
- 日付範囲が期待通りに効くか。
- ユーザー画面から削除された会話がVault上でどう見えるか。
- hold対象の会話が保持されているか。
- 検索結果のTopic、Owner、Date and timeを法務担当が使える形で説明できるか。
Exportでは前後文脈と保存先を確認する
条件
Vault export contentsのGemini app exportsでは、conversation contentがzipファイルとして出力され、conversation ownerごとにXMLファイルが含まれると説明されている。各XMLには、検索条件に一致したpromptとresponseが入る。さらに文脈を示すため、同じ会話で一致したpromptまたはresponseの前後12時間に送信されたpromptとresponseも含まれる。
これは便利だが、検索条件に一致した部分だけが切り出されると思っていると、export量や取り扱う情報の範囲を見誤る。前後文脈が含まれることを、法務・監査・プライバシー担当と共有しておきたい。
注意点
Gemini app exportsには、accounts and conversations countのCSV、file checksums、error reportも含まれる。一方で、Google HelpはGemini app exportsにはmetadata fileが含まれないと説明している。既存のGmailやDrive exportと同じ前提で監査手順書を作っている場合は、Gemini app用に確認手順を分ける必要がある。
exportは証跡の取り出しであり、取り出した後の保存、アクセス制御、削除、暗号化、監査ログ確認は別の責任になる。Vaultで出せることと、社内で安全に扱えることは分けて確認したい。
API対応と今後の更新をどう追うか
- 2026年6月15日JST時点
記事では、Vault APIでGemini appの保持ルールやholdを自動化できるとは書かない。
- coming weeks
Google Workspace Updatesで示されたAPI supportの予定を、今後数週間の確認事項として扱う。
- 公式ドキュメント確認
Vault APIのリファレンス、Google Workspace Updates、Vault Helpの更新を同じ導線で追う。
- 自動化判断
API対応が確認できてから、保持ルールやholdの棚卸し、監査レポート、運用手順の自動化を検討する。
未対応の可能性がある段階では、UIでの確認手順と公式更新の追跡を先に決めておくほうが安全です。
公式発表でAPI supportがcoming weeksとされている点は、急いで自動化したい管理者ほど注意が必要だ。
Vault API supportはcoming weeksとして扱う
注意点
2026年6月15日JST時点では、この記事ではVault APIでGemini appの保持ルールやholdを自動化できるとは書かない。公式発表が示しているのは、Vault API users向けのsupportが今後数週間で利用可能になるという見通しだ。
自動化前提で設計している組織は、UIで小さく検証し、API対応が公式ドキュメントに反映された時点で、作成、更新、削除、監査ログ、エラー処理、ロールバック不可の扱いを確認したい。
更新条件
記事公開後に確認する公式資料は次の通りだ。
- Google Workspace Updates。
- Vault HelpのWhat's new。
- Supported services & data types。
- Vault API documentation。
- Google Cloud CommunityやWorkspace Admin Communityの公式案内。
API対応が確認できた場合は、この記事の更新履歴に追記し、手動運用から自動化運用へ進む前のチェックを追加する。逆にHelp Centerの対象外データやライセンス条件が変わった場合は、対象範囲表を優先して差し替える。
追記確認の導線を決める
確認項目
定期確認では、次の5つを見ておきたい。
- API対応が実装済みになったか。
- Gemini app supported dataの対象外項目が変わっていないか。
- AvailabilityやVault add-onの説明が変わっていないか。
- retain、hold、search、exportの手順が変わっていないか。
- 社内手順書と利用者通知が古くなっていないか。
上振れと下振れ
上振れは、API対応が早く公開され、保持ルールやholdの管理を既存のWorkspace管理フローへ組み込める場合だ。下振れは、Help Centerの記述が更新され、media files、Gems、Gemini for Google Workspace dataの扱いやライセンス条件の説明を差し替える必要が出る場合だ。
今回の変更をどう位置づけるか
どのGemini app conversationsを、どの期間、どの組織部門で保持するかを決める。
対象外データや保持期間を超えたデータを、期待通りに削除できるか確認する。
Vaultで検索、hold、エクスポートを扱える管理者と承認経路を明確にする。
エクスポート後のデータ閲覧、保管、再共有、削除のルールまで含めて運用を決める。
Gemini app対応は機能追加であると同時に、AI会話ログの責任範囲を定義するきっかけになります。
Google VaultのGemini app対応は、Geminiを企業の情報管理の外に置かないための更新として読むと分かりやすい。AIチャットの会話は、メールやDriveファイルほど定型化されていない。だからこそ、残す範囲、残さない範囲、検索できる人、export後に見られる人を、最初に決めておく価値がある。
一方で、VaultがGemini appのすべてを保存する万能ログになるわけではない。対象はpromptとresponseを中心としたGemini app messagesであり、media files、Gems、Gemini for Google Workspace dataは対象外として示されている。Workspaceアプリ内のGemini機能も、今回のGemini app更新とは分ける必要がある。
管理者にとっての優先順位は明確だ。まず対象範囲とライセンスを確認する。次に、Default ruleとCustom ruleを小さいOUで検証する。holdは法務・監査の承認フローに入れる。最後に、検索・exportとAPI対応の追記確認を運用へ組み込む。この順番なら、AI利用ログを急に全社監視の話にせず、情報ガバナンスとして説明しやすい。
AlphabetやGoogleの発表を製品・サービス目線で追う場合は、<a href="https://googl-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>や<a href="https://googl-watch.blog.mo-gmo.com/category/products-services-solutions/">製品・サービス・ソリューション</a>のカテゴリも活用してほしい。
次に読むなら
更新履歴と読者向けメモ
- 2026年6月15日JST
Google Workspace Updates、Weekly Recap、Google Vault Helpを確認し、保持ルール、訴訟ホールド、検索・エクスポートを整理した。
- 一次情報の扱い
Google公式資料を事実根拠とし、専門メディアやコミュニティ上の反応は需要シグナルとして扱う。
- 対象外データの明記
media files、Gems、Gemini for Google Workspace dataを、Gemini app conversationsと混同しない。
- API supportの注記
Vault API supportはcoming weeksとされているため、対応済みとは書かない。
仕様変更が続く領域では、確認日と断定しない範囲を明示して読むことが重要です。
- 2026年6月15日JST: Google Workspace Updates、Weekly Recap、Google Vault Helpの各ページを確認し、Gemini appの保持ルール、訴訟ホールド、検索・エクスポート、対象外データ、ライセンス要件を整理した。
- 本記事はGoogle公式資料を一次情報として扱い、専門メディアやコミュニティ上の反応は需要シグナルとしてのみ参照している。
- Vault API supportは公式発表上coming weeksとされているため、対応済みとは書いていない。公式ドキュメントで確認できた場合は追記する。
- Alphabet Watch JapanはAlphabetおよびGoogleとは非提携だ。Google、Google Workspace、Google Vault、Geminiなどの名称は各社の商標または登録商標である。
Alphabetの公式発表、Workspace更新、Gemini関連の提供条件、噂と公式確認の切り分けを継続して追いたい場合は、<a href="https://googl-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>で更新通知を受け取れる。
参照した主な情報源
- Google Workspace Updates: Google Vault now supports retention rules and litigation holds for Gemini app
https://workspaceupdates.googleblog.com/2026/06/google-vault-now-supports-retention-rules-and-litigation-holds-for-Gemini-app.html
- Google Workspace Updates Weekly Recap – June 12, 2026
https://workspaceupdates.googleblog.com/2026/06/weekly-recap-06-12-2026.html
- Google Workspace: Google Vault
https://workspace.google.com/products/vault/
- Google for Developers: Google Vault
https://developers.google.com/workspace/vault
- Google for Developers: Google Vault API
https://developers.google.com/workspace/vault/reference/rest
補足確認: Google Vault HelpのWhat's new、Supported services & data types、Retain Gemini app messages、Place Gemini app messages on hold、Use Vault to search Gemini app、Vault export contents、Vaultの各ページは、2026年6月15日JSTに本文確認用の一次情報としてGETで確認した。Google SupportはHEAD確認で404を返す場合があるため、参照URL欄ではHEAD/GETともに200を確認できる公式ページを優先している。