この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。
Google Vaultは、Google Workspaceの対象データを「決めた期間残す」「法務案件のため削除させない」「検索して書き出す」ための情報ガバナンス・電子情報開示（eDiscovery）サービスです。バックアップとは目的が異なるため、保持ルール・ホールド・Matterの関係から整理します。
情報確認基準日：2026-09-19
まず一言でいうと
Vaultは、日常のファイル置き場ではなく、組織が法務・監査・保持方針に沿ってWorkspaceデータを管理するための管理者向け機能です。
| 機能 | 平易にいうと | 実務での用途 |
|---|---|---|
| Retention（保持） | データを何日・何年残すか決める | 社内規程や法令に沿う |
| Hold（ホールド） | 特定対象を削除させず残す | 訴訟・調査対象の保全 |
| Matter | 調査案件をまとめる箱 | 検索・Hold・Exportを案件単位で管理 |
| Search | 条件を指定して探す | 対象メールやファイルを絞る |
| Export | 検索結果を書き出す | レビューや外部提出の準備 |
Google全体での位置づけ
VaultはGoogle Workspaceの情報ガバナンス／eDiscovery層です。GmailやDriveを利用者が日常業務で使う一方、Vaultは管理・法務側から対象データの保持と調査を扱います。Google Workspaceの契約エディションや対象サービスによって利用条件・対象データが変わるため、導入時は公式ヘルプで確認します。
flowchart LR U[利用者] -->|作成・送受信| W[Workspaceデータ] R[Retention rule] -->|保持期間を適用| W H[Hold] -->|案件対象を保全| W W --> S[Vault Search] M[Matter] --> H M --> S S --> E[Export] A[Vault権限を持つ担当者] --> M
重要なのは、Vaultを契約しただけで全データが永続保存されるわけではないことです。保持ルールとHoldは目的が違い、削除ポリシーも含めて設計します。
何ができる？
保持ルールでは対象データを一定期間保持し、期間後の扱いをポリシーとして設計します。Holdは法務・調査など特定案件で対象となるユーザーやデータを保全する仕組みです。Matterは検索、Hold、Exportなどを案件単位で整理する入れ物と考えると分かりやすくなります。
Vaultの検索は「バックアップから復元する」操作ではありません。対象サービスの保持されたデータを条件検索し、必要に応じてExportするためのものです。そのため、一般的なバックアップ製品の世代管理・システム復旧と同じものとして設計しないことが重要です。
誰に関係する？
一般利用者・事務職
通常はVault画面を直接操作しません。ただし、自分が削除したメールやファイルでも、組織の保持ルールやHoldによってVault上では保持される場合があります。「画面から消した＝組織から完全消去」とは限りません。
IT管理者
契約エディション、Vault権限、対象サービス、保持ルール、監査、退職者データの扱いを法務・情報管理部門と整理します。保持期間を長くすれば安全という単純な話ではなく、不要データを過剰保持するリスクも考えます。
法務・監査担当
Matterを案件単位に作り、必要なHold・検索・Exportを行います。検索条件やExportの受け渡し方法も証跡として残せる運用にします。
開発者
Vaultは日常アプリの自動化APIとして考えるより、まず管理・法務プロセスを理解するサービスです。APIを使う必要がある場合も、公式API資料で利用可能な操作、認証、OAuth scope、管理権限を個別確認し、最小権限にします。
Microsoft Purviewと比べる
| 観点 | Google Vault | Microsoft側で近い考え方 |
|---|---|---|
| 主目的 | Workspaceデータの保持・eDiscovery | Microsoft PurviewのData Lifecycle / eDiscovery等 |
| 日常データ | Gmail、Drive等のWorkspace側に存在 | Exchange、SharePoint、OneDrive等 |
| 案件管理 | Matter | eDiscovery Case等 |
| 法的保全 | Hold | Hold / preservationに相当する領域 |
| 注意 | バックアップではない | Purviewもバックアップ製品そのものではない |
Microsoft経験者は「Vault = Purview全部」と覚えるより、Purviewのうち保持とeDiscoveryに近い役割を、Workspaceデータに対して担うと理解すると混同しにくくなります。
料金・アカウント・Cloud Project
VaultはGoogle Workspace組織向けの機能で、利用可否は契約エディション等に依存します。一般の個人Googleアカウント向けの単独バックアップサービスではありません。通常のVault管理操作のために利用者自身がGoogle Cloud Projectを作るものではありません。API開発を行う場合は別途Cloud Project、API有効化、認証設計が必要になる場合があります。
安全に確認する
本番の保持ルールをいきなり変更せず、まず現在の設定を読み取りで棚卸しします。
Vaultの利用可能な契約と管理権限を確認する。
対象サービスと既存Retention ruleを一覧化する。
Matter / Holdの責任者と目的を確認する。
テスト用データで検索条件を確認する。
Exportする場合は保存先・アクセス権・削除時期まで決める。
成功条件： 「どのデータを、何の根拠で、いつまで保持するか」を説明でき、Holdと通常保持を区別できることです。変更するなら、まずテスト組織・限定対象で影響を確認します。
セキュリティで気をつけること
Vaultには組織のメールやファイルなど機微な情報へ到達できる可能性があります。Vault権限は必要最小限にし、管理者権限と法務担当の役割を分け、Export後のファイルもアクセス制御します。検索結果やExportをGitHubへ置かず、token、client secret、private keyなどの認証情報も保存しません。
よくある勘違い
Vault = バックアップではありません。保持・eDiscoveryが中心です。
削除したら必ず消えるとは限りません。保持ルールやHoldの影響を受けます。
Hold = 全社の保持期間延長ではありません。案件等に必要な対象を保全する考え方です。
長く保持するほど安全とも限りません。法務・プライバシー・社内規程を合わせて判断します。
Google公式情報
次に何をすればよい？
最初に「保持」「Hold」「バックアップ」を社内で同じ意味にしていないか確認します。その後、対象サービス・契約・既存ルールを棚卸しし、法務・IT・情報管理の責任分界を決めます。
Papanda TRY：保持とHoldの判断表を作る
破壊的な設定変更はせず、Sheetsなどに データ種別 / 保持要件 / Hold有無 / 根拠 / 承認者 / 見直し日 を並べるだけでも設計の抜けを発見できます。実データや案件名は公開リポジトリへ保存せず、ダミー値で試します。
結局どういうサービス？
Google Vaultは、Google Workspaceの対象データを組織のルールや法務案件に沿って保持・保全・検索・書き出しするための情報ガバナンス／eDiscoveryサービスです。
まず「バックアップではない」「RetentionとHoldは別目的」と理解し、自組織の契約・対象データ・保持方針をGoogle公式情報と照合するのが次の一歩です。
