Drive ラベル × Vault 保持ポリシー設計

2023年6月、Google Vault のカスタム保持ルールで Drive ラベルを条件として指定できる機能が一般提供されました（Google Workspace Updates Blog より）。この記事では、Google Drive ラベルと Vault 保持ポリシーを連動させる命名規則設計・ポリシーマッピング・設計フロー・運用チェックリストを整理します。

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

• Google Workspace で Drive ラベルと Vault 保持ポリシーを両方運用している 100 名規模企業の情シス担当者
• Drive のラベル管理と Vault の保持設定が別々に存在し、コンプライアンス証跡の整備に毎月工数がかかっている担当者
• ラベル運用が「ファイルに色をつけるだけ」で止まっており、保持ポリシーとの連携まで踏み込めていない担当者
• 情報ライフサイクル管理を体系化したいと考えている情シス担当者

Google Drive ラベルと Vault 保持ポリシーの連携が解決すること

Drive ラベルとは、Google Drive 上のファイルに付与できる構造化メタデータです。テキスト・選択・日付・ユーザーなどのフィールドを持ち、ファイルの性質を機械可読な形式で記述できます。

Google Vault（GWS の電子的証拠開示（eDiscovery）・保持管理ツール）のカスタム保持ルールでは、Drive ラベルを条件として指定できます。「このラベルが付いているファイルを 7 年保持する」「このラベルの日付フィールドの値を保持開始日として使う」という設定が可能です（Google Vault ヘルプより）。

この連携によって運用の構造が変わります。従来は「Drive の運用ルール」と「Vault の保持ポリシー」は独立して管理されていました。ラベルを起点にすると、ファイルに付与されたメタデータが保持ルールを自動的に呼び出す設計になります。コンプライアンス報告のたびに「対象ファイルを特定して保持期間を確認する」という人手作業を大幅に削減できます。

利用可能なエディションは Business Plus、Enterprise Essentials / Essentials Plus、Enterprise Standard / Plus、Education Standard / Plus です（Google Workspace Updates Blog, 2023年6月より）。Business Starter と Business Standard はこの連携機能の対象外です。Drive ラベル自体は Business Standard から使えますが、Vault 保持ルールとの連携には Business Plus 以上が必要な点に注意してください。

ラベル命名規則の設計例

ラベルをポリシー連携の起点にするなら、命名規則を先に決めることが設計の基本です。「誰でも直感的に付与でき、かつ保持期間が一意に決まる」ラベル体系を目指します。

設計のポイント

• 文書の性質（契約・財務・個人情報・社内一般）と保持期間のカテゴリ（法定・業務・短期）を組み合わせた体系にする
• ラベル名に保持期間の数字を直接埋め込まない。「7年-契約書」のような命名にすると、法改正などで保持期間が変わるたびにラベル自体の変更が必要になる
• 選択フィールドに値を設けて 1 ラベルで複数の文書カテゴリをカバーする設計のほうが、管理コストが低い

以下は 1 つのラベルに複数フィールドを持たせる設計例です。

ラベル名	フィールド名	フィールド種別	値の例
文書種別	カテゴリ	選択	契約 / 財務 / 個人情報 / 社内一般
文書種別	文書日付	日付	契約締結日・退会日など業務固有の日付
文書種別	担当部署	選択	法務 / 人事 / 財務 / 全社

「文書種別」という 1 つのラベルに複数フィールドを持たせる設計が運用しやすいです。ラベルは組織全体で最大 150 個まで作成できますが、ファイル 1 件に手動付与できるのは最大 5 個です。自動ルール付与も含めた合計上限は 1 ファイルあたり最大 20 個です（公式ドキュメントより）。DLP 連携や自動付与を組み合わせる設計では合計上限も念頭に置いてください。ラベル数を増やしすぎると付与漏れが増えるため、最初は 2〜3 ラベルから始めることをお勧めします。

フィールド種別の使い分け

フィールド種別の選択は、後工程の精度を左右します。「選択フィールド」は値の揺れを防ぎ、DLP ルールのトリガーとしても直接使えます（例：カテゴリ値が「個人情報」のファイルの組織外共有をブロックするなど）。「日付フィールド」は業務上の意味のある日付（締結日・退職日など）を機械可読な形で記録でき、Vault の保持開始日として直接参照できます。「テキストフィールド」は柔軟性が高い反面、値が揺れやすく検索・フィルタリングに向かないため、Vault 保持との連携の条件としては適していません。Vault 保持との連携を目的とするなら、選択フィールドまたは日付フィールドを中心に設計するのが実務的です。

ユーザーの入力負荷も考慮が必要です。1 ファイルに複数フィールドの入力を求めると付与率が下がります。「担当部署」フィールドのように、所属 OU から自動推定できる項目は入力必須にしない設計も検討してください。ラベルの付与率が低いまま運用が始まると、対象ファイルがカスタムルールの条件を満たさず、コンプライアンス上の穴になります。

Vault 保持ポリシーとのマッピング設計

ラベルの体系が決まったら、各ラベル値と Vault のカスタム保持ルールを対応させます。以下は文書カテゴリごとの保持ポリシー設計の例です。

ラベル値（カテゴリ）	保持期間	保持開始日の条件	根拠
契約	7 年	文書日付フィールド（契約締結日）	商法・民法の書面保存義務
財務	10 年	文書日付フィールド（計上日）	法人税法・会社法の帳簿保存
個人情報	3 年	文書日付フィールド（退会・退職日）	社内個人情報保護規程
社内一般	3 年	ファイル作成日	社内文書管理規程

Vault のカスタム保持ルールでは、「ラベル条件（label is〜）」と「保持開始日のロジック」を組み合わせます。保持開始日として選択できる条件は次の 4 種類です（Vault ヘルプより）。

• ファイルの作成日
• ファイルの最終更新日
• ゴミ箱への移動日
• ラベルの日付フィールドの値

4 番目の「ラベルの日付フィールドの値」が今回の設計で中核になります。「退会日」「契約締結日」など業務固有の日付をラベルフィールドに持たせることで、ファイルの作成・更新タイミングに左右されない保持期間計算が実現します。

Vault の保持ルールには「デフォルトルール」と「カスタムルール」があります。デフォルトルールはサービス全体に広く適用され、カスタムルールはデフォルトより優先されます。ラベル条件でカスタムルールを作る場合、デフォルトルールとの優先関係を必ず確認してください。意図しないデータが削除される事態を防ぐために重要な確認です。

訴訟ホールド（Legal Hold）との関係

Vault には保持ルールとは別に「訴訟ホールド」機能があります。ホールドは保持ルールとは独立して機能し、ホールドが設定されているコンテンツは保持ルールの期間が過ぎても削除されません（Vault ヘルプより）。コンプライアンス対応や訴訟リスクが生じた場合にホールドを設定することで、保持ルールの設計とは別軸でデータを保全できます。保持ルール設計が未整備の段階でも、リスクが発生した文書に対してはホールドを先行して設定するという運用が実務上は有効です。

情報ライフサイクル管理の設計フロー（GWS 運用）

ラベル × 保持ポリシーの連携を実装する場合、設計の順序が結果を大きく左右します。以下に概念レベルのフローを整理します。

1. 文書分類の棚卸し：組織内で管理が必要な文書カテゴリと、それぞれの法定・業務上の保持期間要件を整理する。法務・コンプライアンス担当との確認が必須。ここが曖昧なままだとラベル設計が途中で迷走する
2. ラベル体系の設計：上記の分類に基づき、Drive ラベルの構成（ラベル名・フィールド種別・値の選択肢）を設計する。将来の DLP ルールやアクセス制御との兼ね合いも考慮する
3. 保持ルールのマッピング設計：ラベル値ごとの保持期間・保持開始日・削除ポリシーを定義し、マッピング表として文書化する
4. テスト適用：少数のテストファイルにラベルを付与し、保持ルールが意図通りに機能するか確認する。不適切な保持ルールはデータの即時・不可逆的な削除を引き起こす可能性があります（Vault ヘルプより）。5〜10 件のテストファイルで「ラベルを付与したときの保持期間」「ラベルを外したときの挙動」を事前確認してから本番に移行する
5. 全社展開と運用開始：展開範囲（OU 単位またはグループ単位）を定め、ユーザー向けのラベル付与ガイドを整備する
6. 定期見直し：法改正・組織変更・新しい文書カテゴリの発生に合わせて、ラベル設計とマッピング表を年 1 回以上見直す

このフローで省略してはいけないのが「1. 文書分類の棚卸し」です。Drive ラベルと Vault の設定は技術的な作業ですが、「どの文書を何年保持するか」は法務・コンプライアンス担当との確認が必要な業務判断です。情シスだけで完結させようとすると、後から保持期間の再設定が発生します。

Vault 保持 自動化と DLP 連携に向けた拡張ポイント

ラベル × 保持ポリシーの基本設計が固まったら、次に視野に入るのが DLP（データ損失防止）との統合と自動化です。

DLP × ラベル連携の設計

Drive ラベルは DLP ルールのトリガーとしても機能します。「カテゴリ = 個人情報のラベルが付いているファイルを組織外に共有しようとしたらブロックする」という DLP ルールを組み合わせると、1 つのラベルが複数のガバナンス機能の起点として機能します。

具体的には、1 つの「文書種別」ラベルが次の 3 つの軸を同時に制御する構造が実務上まとまりやすいです。

• 保持（Vault）：カテゴリ値に応じた保持期間を自動設定
• 制御（DLP）：機密レベルに応じた外部共有・ダウンロードのブロック
• 可視性（Drive レポート・管理コンソール）：ラベル付きファイルの定期棚卸しと付与率の確認

この構造を実現するには、ラベル設計の段階から「Vault 連携」と「DLP 連携」の両方を意識したフィールド定義が必要です。後から DLP 連携を追加しようとすると、フィールド値の粒度や命名が合わず、ラベル体系を作り直すケースがあります。三つの軸を最初から意識した設計が、後からの手戻りを最小化します。

ラベル自動付与の方向性

Drive Labels API を利用すると、プログラムからファイルにラベルを付与・更新・削除できます。GAS（Google Apps Script）や外部のワークフローツールと組み合わせて、「特定のフォルダに作成されたファイルに自動でラベルを付与する」仕組みを実装することで、手動付与の漏れを大幅に減らせます。

ただし、自動化は手動運用が安定してから導入するのが安全です。ラベル付与ルールが組織内で合意されていない段階で自動化を先行させると、不正なラベルが大量に付与されて保持ポリシーが誤動作するリスクがあります。手動付与のフローと品質確認の体制を先に整え、「どのフォルダのファイルに何のラベルを付けるか」が明確になってから自動化に移行するのが実務的な順序です。自動化の実装手順は別記事で解説します。

導入前に確認すべき制約と注意点

設計を進める前に、以下を押さえておく必要があります。

• 保持ルールの即時適用リスク：不適切な保持ルールを設定すると、データが即時・不可逆的に削除される可能性があります（Vault ヘルプ原文：「an improperly configured retention rule can cause the immediate and irreversible purging of data」）。テストファイルで動作確認してから本番適用する
• ラベルを外したファイルの扱い：ユーザーがラベルを外してからゴミ箱に移動した場合、カスタムルールのラベル条件に引っかかりません。ゴミ箱移動日ベースのデフォルトルールとの組み合わせを設計に組み込む
• ラベル付与の漏れ：ラベルが付与されていないファイルはカスタムルールの対象外です。デフォルトルールでカバーするか、ラベル付与プロセスを整備する。この「漏れ」が監査上の穴になりやすい
• エディション制約：Drive ラベル × Vault 保持連携は Business Plus 以上が必要。Business Starter / Standard は対象外です（Google Workspace Updates Blog, 2023年6月）
• 共有ドライブとマイドライブの違い：マイドライブと共有ドライブのいずれも Vault 保持の対象になりますが、共有ドライブは特定の OU に属さないため、OU 単位で保持ポリシーを分ける設計では挙動が異なる場合があります。共有ドライブへの適用範囲は管理コンソールの設定を事前に確認してください
• ラベル操作の監査ログ：Drive の監査ログでは、ユーザーがラベルを付与・変更・削除した操作を確認できます。ラベルの不正な取り外しはカスタムルールの対象外を作り出すリスクになるため、定期的なログ確認をコンプライアンス証跡の一部として組み込んでください

運用チェックリスト

設計・導入後の定期点検として使えるチェックリストです。フェーズ別に確認漏れがないかを参照してください。

初期設計フェーズ

• [ ] 文書カテゴリと保持期間要件を法務・コンプライアンス担当と合意済みか
• [ ] ラベル命名規則の設計ドキュメントが存在するか
• [ ] Vault 保持ポリシーとのマッピング表が文書化されているか
• [ ] テスト環境または少数ファイルで保持ルールを事前検証したか
• [ ] エディション要件（Business Plus 以上）を満たしていることを確認したか
• [ ] 将来の DLP 連携を前提としたフィールド設計になっているか

展開・運用フェーズ

• [ ] ユーザー向けのラベル付与ガイドが配布されているか
• [ ] ラベル付与漏れを検知する仕組み（Drive レポートや監査ログの定期確認）があるか
• [ ] デフォルト保持ルールとカスタムルールの優先関係を確認済みか
• [ ] ラベルを外したファイルに対するポリシーが定義されているか
• [ ] 訴訟ホールドの発動フローと担当者が定義されているか

定期見直しフェーズ

• [ ] 年 1 回以上、法改正・組織変更に合わせてマッピング表を見直しているか
• [ ] 新規文書カテゴリが発生したときの追加手順が定められているか
• [ ] Vault の保持ルール一覧と現行の設計ドキュメントが乖離していないか
• [ ] Drive の監査ログでラベル変更の不審な操作を確認しているか

技術設定より設計合意が先

Drive ラベル × Vault 保持ポリシーの連携は「設定すれば自動で管理される」という仕組みではありません。正確には、「設計した通りに動く」仕組みです。設計が正しければ工数が下がり、設計が誤っていればデータを失うリスクがあります。

重要なのは、情シスが技術設定より先に「組織間の合意づくり」を進めることです。保持期間の根拠（法定か業務規程か）は法務との確認が必要で、ラベル付与の運用ルールはファイルを扱う各部門との合意が必要です。この合意プロセスに最も工数がかかりますが、ここを省略すると後から設定を大幅に変更することになります。

逆に言えば、設計が固まれば維持は楽です。ラベルが付いたファイルが自動的に正しい保持期間に入る状態になれば、毎月のコンプライアンス証跡確認がルールの確認と例外処理だけに絞られます。情シスの工数削減は「設定のうまさ」より「設計の丁寧さ」から生まれます。

Google Workspace 情報管理の設計支援については DRASENAS でも継続的に情報発信しています。

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

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