はじめに
ここまでの記事では、次のような流れで設計を整理してきました。
- Google Workspaceを業務基盤として残す
- Windows端末管理は Microsoft Entra / Intune / Defender に寄せる
- 会社メール、Google ID、Microsoft ID を分離して設計する
- 必要に応じて EXTIC を「依存しない自動化層」として使う
これまでの記事は以下になります。
- Google Workspaceを使い続けながらWindows端末管理をIntuneへ移行する設計パターン
- IDをベンダに依存させないためのGoogle / Microsoft分離設計
- オンプレADを廃止する前に確認すべきWindows端末移行パターン
- Google WorkspaceとMicrosoft Entraを併用する構成
- EXTICを使ったID連携の設計
この流れの中で、メールについては別に考える必要があります。
今回は Google Vault と メール配送経路 について考えます。
Vault は便利な製品ですが、単にライセンスを買って有効化すれば終わりではありません。
メールがどこを通り、どこに保存され、どこが検索・保全の対象になるのかを整理しないと、「Vault を入れたつもりだが、実は一部メールが対象外だった」 という状態が起きます。
この記事では、Google Workspace を使っている企業が、Vault 導入時に考えるべき メール配送経路 と 保持ルール の設計を整理します。
この記事は公開用に抽象化した設計パターンです。
実ドメイン、実メールサーバ、実アカウント、実保持期間は記載しません。
結論
結論から書きます。
Vault を導入するなら、メールの正本を Gmail 側へ寄せる前提で考えるべきです。
設計の要点は次です。
1. 会社メールアドレスは独自ドメインを正本にする
2. そのドメインの受信メールは最終的に Gmail が直接受ける構成にする
3. 転送元メールサーバにメールが残る構成は、保全対象の分散を生みやすい
4. Vault は保持・検索・書き出しの仕組みであり、保持ルールを決めないと意味が薄い
5. 退職者メール、削除データ、管理者権限、保持期間は別途設計が必要
つまり、**Vault 導入は「ライセンス購入」ではなく、「メール配送経路と保持方針の再設計」**です。
Vault は何をする製品か
Google Vault は、Google Workspace の 情報ガバナンス と 電子情報開示 のためのツールです。
Google 公式でも、Vault はユーザーの Google Workspace データに対して、保持、リティゲーションホールド、検索、書き出しを行うツールと説明されています。対応データとしては、Gmail、Google Drive、Google Calendar、Google Chat、Google Meet の録画とログ、Google Groups、Google Sites などが挙がっています。(Google Vault ヘルプ: Vault)
ここで重要なのは、Vault が次の用途の製品だということです。
・法務・監査・調査のための検索
・保持期間の制御
・特定データの保全
・書き出しによる証跡確保
逆に、次の用途と完全に同義ではありません。
・一般的なエンドユーザー向けバックアップ
・何もしなくても全データを永久保存してくれる仕組み
Google 公式でも、Vault はデータアーカイブではなく、保持ルールを設定するまでデータは保持されないと説明されています。(Google Vault ヘルプ: Vault)
なぜメール配送経路の整理が必要なのか
企業によっては、Google Workspace を使っていても、メール配送経路が次のように複雑になっています。
インターネット
↓
旧メール基盤 / ホスティングメール
↓ 転送
Gmail
↓
Vault
この構成は移行期にはよくあります。
ただし、Vault 導入の観点では問題があります。
問題1: 正本が分かりにくい
メールが旧メール基盤にも Gmail にも存在する場合、
どちらを正本として扱うのか が曖昧になります。
問題2: 保全対象が分散する
Vault は Google Workspace データに対する保持・検索・書き出しの仕組みです。
そのため、旧メール基盤側にだけ残っているメールは、当然ながら Vault の検索対象にはなりません。
問題3: 退職者や削除データの扱いが複雑になる
転送元と転送先の双方にデータがあると、
- どちらを停止するか
- どちらを保持するか
- どちらを削除するか
が別々に発生します。
推奨するメール配送の考え方
長期的には、次の構成を目指すべきです。
要するに、独自ドメイン宛のメールを Gmail が直接受ける構成です。
Google Workspace で Gmail を使う場合、Google 公式も、メールが Google のメールサーバー経由で受信トレイへ配信されるように MX レコードを更新し、管理コンソールで Gmail を有効化するよう案内しています。現在の Google 公式手順では、MX レコード値として smtp.google.com が案内されています。(Google Workspace 管理者ヘルプ: Google Workspace の MX レコードを設定する)
この構成にすると、受信メールの正本が Gmail に揃うため、Vault の対象範囲も分かりやすくなります。
旧メール基盤から Gmail への転送を残すと何が起きるか
転送構成そのものが即NGというわけではありません。
ただし、少なくとも次の論点が残ります。
・転送元にメールを残すか
・転送失敗時の再送をどうするか
・転送元の保存メールは誰が管理するか
・監査や法務対応でどちらを検索するか
・退職者メールの正本はどちらか
特に、「転送元にも保存する」 構成は、保全の責任範囲を二重化します。
この状態で Vault を導入しても、組織としてのメール保全設計は単純になりません。
また、Google は Gmail への転送について、転送がメール認証や配送品質に影響する可能性があるため、管理者向けのベストプラクティスを別途案内しています。(Google ヘルプ: メールを Gmail に転送するおすすめの方法)
したがって、移行期間を除けば、旧基盤から Gmail への転送運用は長期固定にしない方がよいです。
Vault 導入時に決めるべきこと
Vault 導入で本当に重要なのは、保持ルールです。
Google 公式でも、Vault の保持ルールは、データを必要期間保持したり、不要になったデータを一定期間後に削除したりするための仕組みとされています。(Google Vault ヘルプ: データ保持の仕組み)
決めるべきことは、最低でも次です。
1. どのユーザーを Vault 対象にするか
・全社員を対象にするか
・役員・管理部門・管理者だけにするか
・退職者はどの期間まで対象にするか
Vault は、ライセンスが割り当てられたユーザーと管理者に対して利用できます。Google 公式でも、Vault アドオンライセンスの場合は、ライセンスが割り当てられたユーザーのみが Vault を利用できると説明されています。(Google Vault ヘルプ: Vault)
2. デフォルト保持ルールをどうするか
Google 公式では、デフォルトの保持ルールは「そのサービスのすべてのデータ」を対象にするルールで、サービスごとに1つだけ設定できます。(Google Vault ヘルプ: データ保持の仕組み)
ここで考えるべきことは次です。
・Gmail を何年保持するか
・Drive を何年保持するか
・Chat や Calendar を対象にするか
・無期限保持にするか
・保持終了後に削除するか
3. リティゲーションホールドをどう使うか
通常の保持ルールとは別に、調査や法的要請に備えて個別データを保持するための ホールド を使うことがあります。
Vault の公式説明でも、記録保持（リティゲーションホールド）は通常の保持ルールより優先されます。(Google Vault ヘルプ: データ保持の仕組み)
4. 退職者メールをどう扱うか
ここは実務上かなり重要です。
・退職当日にアカウント停止するか
・どの時点でライセンスを外すか
・退職者メールを何年保持するか
・誰が検索権限を持つか
Vault を導入しても、退職者アカウントの運用ルールが曖昧だと、後で困ります。
保持ルールで注意すべきこと
Google 公式は、保持ルールについて次の点を明示しています。
・デフォルトでは、Google Workspace データはユーザーまたは管理者が削除するまでアカウントに残る
・保持ルールを設定すると、必要期間保持したり、一定期間後に削除したりできる
・保持ルール設定を誤ると、データが直ちにパージされて元に戻せなくなることがある
・新しい保持ルールは、少人数のユーザーグループでテストすることが推奨される
これは非常に重要です。(Google Vault ヘルプ: データ保持の仕組み)
つまり、Vault 導入時は次の順番が安全です。
1. いきなり全社一括で長期保持ルールを入れない
2. まず対象サービスを決める
3. 小さな対象で保持ルールをテストする
4. 監査・法務・経営の要件を確認する
5. その後に全社へ広げる
Vault は「検索・保持の仕組み」であって、運用そのものではない
ここで誤解しやすいのが、Vault を入れれば退職者運用も削除運用も自動的に正しくなるわけではないという点です。
Vault が提供するのは、あくまで次です。
・保持する
・検索する
・ホールドする
・書き出す
その前段で、組織として決めるべきことがあります。
・会社メールはどこで受けるか
・保持対象者は誰か
・保持期間は何年か
・退職者をどう扱うか
・誰が検索できるか
・誰が書き出しできるか
この設計が曖昧だと、Vault は「あるだけ」の状態になります。
会社メール・Google ID・Vaultの関係
このシリーズでは、会社メールと Google ID を分ける設計も扱ってきました。
会社メール: user@example.co.jp
Google ID: user@g.example.co.jp
Microsoft ID: user@ms.example.co.jp
この構成でも、会社メールドメインの MX を Google Workspace 側へ向けることはできます。
つまり、Google の primary email が user@g.example.co.jp であっても、user@example.co.jp 宛のメールを Gmail で受け、Vault の対象にする設計は可能です。
ただし、ここでも重要なのは、どのドメインが受信正本なのか を明確にすることです。
Google Workspace ではユーザーエイリアスドメインや追加ドメインを使えますが、ログインIDとメールアドレスの使い分けは別問題です。運用上は、
・会社メールドメイン = 対外アドレスの正本
・Google primary = ログイン識別子
・Vault 対象 = Gmail に実際に届いたメール
という整理が分かりやすいです。
実務上の推奨フロー
Vault を導入するなら、実務上の順番は次がよいです。
フェーズ1: 現在のメール配送経路を棚卸しする
確認すべきことは次です。
・どのドメイン宛メールをどこが受信しているか
・転送元メールサーバが存在するか
・転送元にメールを保存しているか
・Gmail 側に届かない経路が残っていないか
・退職者メールがどこに残るか
フェーズ2: Vault 対象と保持方針を決める
・全社員か、一部ユーザーか
・Gmail / Drive / Chat / Calendar のどこまで対象にするか
・保持期間
・ホールド運用
・検索権限
フェーズ3: Gmail を直接受信できるようにする
・独自ドメインの MX を Google Workspace へ向ける
・Gmail を有効化する
・旧メール基盤からの転送を段階的に廃止する
Google 公式でも、Google Workspace でメールを受信するためには MX レコード更新と Gmail 有効化が必要です。(Google Workspace 管理者ヘルプ: Google Workspace の MX レコードを設定する)
フェーズ4: 保持ルールを小さくテストする
Google 公式も、保持ルールは少人数グループでのテストを推奨しています。(Google Vault ヘルプ: データ保持の仕組み)
フェーズ5: 退職者・削除運用を決める
・停止時点
・ライセンス剥奪時点
・保持期間
・完全削除までの猶予
この構成のメリット
・メールの正本が Gmail に揃う
・ Vault の検索対象が明確になる
・ 監査や調査時に参照先が分散しにくい
・ 退職者運用の方針を整理しやすい
・ Google Workspace を中心にメール保全設計を組める
この構成の注意点
・ 旧メール基盤からの転送を長期固定にしない方がよい
・ Vault は保持ルールを入れないと意味が薄い
・ 保持ルールは誤設定すると危険
・ 退職者運用を先に決めないと混乱する
・ Vault だけで全てが解決するわけではない
まとめ
Google Vault 導入で本当に重要なのは、ライセンスの有無よりも メール配送経路と保持設計 です。
整理すると、次の順番がよいです。
1. メールの受信正本をどこに置くか決める
2. 長期的には Gmail が直接受信する構成に寄せる
3. Vault 対象ユーザーと対象データを決める
4. 保持ルールを設計する
5. 退職者・削除・検索権限のルールを決める
重要なのは、Vault を導入することではなく、Vault を前提にメールとデータの正本を整理することです。
次回は、このシリーズ全体を踏まえて、Qiita 連載をもとにした 体系的な設計ガイド化 を考えます。