Google Drive ファイル復元 BCP 設計：Vault 保持期間と RTO/RPO の整合確認

2026年3月30日、Google Drive のランサムウェア検出・ファイル復元機能が一般提供（GA）になりました。この記事では、GA 後の次のステップとして、Drive 復元機能と Google Vault（コンプライアンスアーカイブサービス）を BCP（Business Continuity Plan：事業継続計画）文書にどう記載するか、RTO/RPO と Vault 保持期間の整合設計を中心に整理します。

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

• 100名規模で GWS（Google Workspace）を管理しており、BCP 文書の定期見直しに対応中の情シス担当者
• Drive 復元機能を導入済み（または導入予定）だが、BCP 文書への具体的な記載方法が定まっていない方
• ISMS（情報セキュリティマネジメントシステム）の更新や内部監査で、ランサムウェア対策の説明責任を持っている方
• Vault 保持期間と RTO/RPO 目標値の整合を確認したい方

Drive 復元機能と Vault の役割分担（BCP 設計の前提）

BCP を設計するとき、Drive 復元機能と Google Vault を混同したまま RTO/RPO を設定すると、目標値が実際の機能仕様からずれます。両者はそもそも設計思想が異なるため、まず役割を整理します。

Drive ランサムウェア復元機能（事業継続レイヤー）

Google Workspace 公式ヘルプによると、Drive のリビジョンは最大25日間保持されます。ランサムウェア感染が検出されると、Drive for Desktop の同期が自動停止し、管理コンソールのアラートセンターと管理者宛てメールに通知が届く仕組みです。管理者は Web インターフェースから複数ファイルを以前の正常な状態に一括復元できます。

ただし、復元対象は Microsoft Office 形式（.docx / .xlsx / .pptx など）を含む外部アプリ形式ファイルに限られます。Google ドキュメント・スライド・スプレッドシートはランサムウェアの影響を受けない構造のため、復元ツールの対象外です。また、個々のファイルを個別に選択することもできず、一括復元のみの設計である点も押さえておく必要があります。さらに、ランサムウェアの自動検出通知は Business Standard 以上など一部のプランに限定されているため、自組織のプランがどちらに該当するかも BCP 設計の前提確認事項になります。

Google Vault（コンプライアンス・eDiscovery レイヤー）

Google Vault は法的証拠開示（eDiscovery）やコンプライアンスアーカイブを主目的とするサービスです。公式ヘルプによると、Drive ファイルの保持期間は1〜36,500日の範囲で設定でき、永続保持も選択できます。設計思想は「ランサムウェア復旧」ではなく「削除や改ざんを防ぎながら長期保存する」点にあり、ファイル復元より証跡保全に重点があります。

Vault は Google Workspace Business Plus 以上のプランに含まれます（Business Starter・Business Standard では別途検討が必要です）が、利用するには管理コンソールでサービスを有効化する必要があります。保持ルール（Retention Rule）の設定がなければ、ユーザーがファイルを削除すると Vault からも消えてしまうため、導入後すぐに保持ルールを設定する手順をオンボーディング手順書に含めておくことが重要です。

ISMS 審査でよくある誤答パターン

この2層の違いは BCP 文書の記載でも直接影響します。ISMS 審査の場で「Drive 復元機能の保持期間は？」と問われたとき、Vault と混同したまま「最長36,500日まで対応しています」と回答すると事実誤認になります。Drive 復元は最大25日、Vault はコンプライアンス目的の長期保存——この役割の分離を文書上でも明記しておくと、審査員への説明が正確になります。

BCP 内で「事業継続レイヤー（Drive 復元機能: 最大25日）」と「コンプライアンスレイヤー（Google Vault: 最長36,500日）」という区分けを設けて2行で説明するだけでも、読み手の誤解を防げます。また、この区分けを明示することは、ISMS の情報バックアップや情報セキュリティの継続に関する管理策に対応した文書整備としても有効です（ただし適用する ISMS 規格・バージョンとの照合は各担当者で確認してください）。

RTO/RPO 目標値の設定方針と Drive 復元の制約

BCP 文書に記載する RTO（Recovery Time Objective：目標復旧時間）と RPO（Recovery Point Objective：目標復旧時点）は、Drive 復元機能の仕様制約を起点に考えます。

RPO 設計（どの時点のデータに戻れるか）

Drive リビジョンの保持期間は最大25日間（公式ヘルプより）です。Drive 復元機能だけで対応する場合、「25日以内」が RPO の上限になります。

RPO を設定するときは「感染が何日間気付かれなかった場合を想定するか」が出発点になります。感染翌日に検知できる体制があれば RPO = 24時間が現実的ですが、週次の確認体制しかない場合は「1週間（7日）以内」を目標に設定したうえで、週次の検知手順を BCP に組み込む必要があります。25日を超えた遡りが必要な場面では Drive 復元機能ではカバーできないため、Vault の保持ルールが対象データを確保しているかを別途確認してください。

設定例として「RPO = 前日バックアップ時点（24時間以内）」「RPO = 72時間以内」といった水準が考えられますが、数値は組織が許容できる最大データ損失量から逆算して決める必要があります。

RTO 設計（どのくらいの時間で復旧するか）

復元操作自体は管理コンソールから実行できますが、RTO には「検出通知の受信」→「管理者による状況確認・判断」→「復元範囲の決定」→「復元操作の実行」→「業務再開の確認」という一連のプロセスが含まれます。インシデントの発生時間帯によって対応速度は大きく変わります。次の表を参考にシナリオ別の RTO を設定してください。

インシデント発生パターン	RTO 設定例	補足
営業時間内・管理者在席	4時間以内	検出通知受信から復元完了まで
夜間・休日・管理者不在	翌営業日午前中	バックアップ対応者への連絡フロー含む
自動検出通知なし（プラン要因）	翌営業日中（確認完了後）	定期確認頻度が RTO を左右する

「夜間・休日」シナリオを BCP 文書に明記しておくと、インシデント発生時の初動判断が曖昧になりにくくなります。特に管理者が1名体制の組織では、バックアップ対応者と連絡フローをセットで記載することが現実的な備えです。

なお、ランサムウェア検出機能は Business Standard 以上などの特定プランでのみ提供されます（2026年3月時点の公式情報より）。ファイル復元機能は全 Workspace プランで利用できますが、ランサムウェアの自動検出通知を受け取れないプランでは、RTO 設計に「外部の検知手段」や「定期的な状態確認」を組み込む必要があります。

RTO の妥当性を判断する最も確実な方法は、実際に管理コンソールから復元操作を行い、所要時間を計測することです。後述の「年1回の定期復元テスト」でこの計測を実施すると、目標値と実績のギャップが数値として把握できます。

※ 表内の数値はあくまで設計例です。自組織のリスク許容度と体制に合わせて設定してください。

Vault 保持期間との整合チェック表（Vault 保持期間 BCP 設計）

Drive 復元（短期・事業継続）と Vault（長期・コンプライアンス）の整合を確認するための比較表です。BCP 更新時の確認材料として活用してください。

設計観点	Drive 復元機能	Google Vault
主目的	事業継続・ランサムウェア復旧	コンプライアンス・eDiscovery
復元可能な時点	最大25日前（公式ヘルプより）	保持ルール設定次第（最長36,500日）
BCP における役割	RPO・RTO の主役	長期証跡保全・法的記録
対象ファイル	外部アプリ形式（.docx 等）のみ	ドライブ内ほぼ全ファイル
操作の単位	一括復元（個別選択不可）	eDiscovery 検索・エクスポート

Vault 保持期間の設計方針

Vault の保持期間は、社内規程で定めたデータ保持年数を起点に設定します。一般的には「社内一般文書: 5年」「財務関連: 7年」「契約書: 10年」といった区分を設けることが多いですが、自組織の文書管理規程や法的要件と照合して決める必要があります。Drive 復元機能の25日制限とは独立した設計です。

保持ルール設計時の注意点として、Vault の保持ルールは組織部門（OU）単位またはグループ単位で適用範囲を絞ることができます。全社一律の保持期間にするか、部門別に設定するかは、コンプライアンス要件と管理運用コストのバランスで判断してください。また、保持ルールが設定されていない期間のデータは保護されないため、Vault を新規導入する場合は「導入前のデータ」をどう扱うかを BCP 文書に明記しておくことが重要です。

「RTO/RPO は Drive 復元機能で設計」「コンプライアンス保持は Vault で設計」と役割を明確に分けると、BCP 文書の整合が取りやすくなります。

Vault の保持ルール設計（退職者対応との連携も含む）については、DRASENASの関連記事でも関連する観点を整理しています（Google Workspace退職者データ保持ポリシー最適化）。

BCP 文書記載項目チェックリスト（Google Drive ファイル復元 BCP 対応版）

BCP 文書（または付属の IT-BCP 手順書）に追記・更新すべき項目を整理します。ISMS の更新や内部監査対応の際に活用してください。

基本情報の確認

• [ ] 対象機能の正式名称: Google Drive ランサムウェア検出・ファイル復元機能（2026年3月30日 GA）
• [ ] 自組織の Workspace プランがランサムウェア検出に対応しているか確認済みか
• [ ] 管理コンソールで復元機能が有効化されているか（OU 単位の設定確認）
• [ ] Vault の保持ルールが BCP 対象データに対して有効化されているか確認済みか

RTO/RPO 目標値の記載

• [ ] RPO 目標値（例: 24時間以内）と、Drive リビジョン最大25日制限との整合を確認済みか
• [ ] RTO 目標値（例: 4時間以内）と、検出→確認→復元→確認のフロー所要時間が整合しているか
• [ ] 25日を超える遡りが必要な場面における Vault の対応方針を記載済みか
• [ ] 夜間・休日インシデント発生時の RTO を別シナリオとして記載済みか
• [ ] ランサムウェア検出通知が届かないプランの場合、代替の検知手段と検知頻度を記載済みか

担当者・権限・連絡体制

• [ ] 管理コンソールで復元操作を実行できる管理者ロールの担当者名と連絡先を記載済みか
• [ ] 担当者不在時のバックアップ対応者と連絡手順を明記済みか
• [ ] アラートセンターの通知先メールアドレスが現在有効な担当者のものに設定されているか
• [ ] 外部ベンダー（MSP・IT 管理代行）が対応する場合、連絡先と対応範囲を明記済みか

インシデント後の対応（事後レビュー）

• [ ] 復元完了後に関係者・上位管理者へ状況報告を行う連絡フローを記載済みか
• [ ] 事後報告書のテンプレート（発生日時・検出経緯・復元範囲・再発防止策）を準備済みか
• [ ] 事後レビューで判明した課題を翌年の BCP テストに反映する仕組みがあるか

テスト・見直しのスケジュール

• [ ] 年1回の定期復元テスト実施日程（ISMS 訓練との連動が望ましい）
• [ ] Vault 保持期間設定の次回見直し予定日
• [ ] Workspace プランを変更した場合に BCP を再確認する手順があるか

定期復元テスト（年1回）の設計例

BCP は文書を整備するだけでは機能しません。年1回以上のテストで手順と担当者の練度を確認する必要があります。実際のランサムウェア感染を再現することは難しいため、以下の形式が現実的です。

テストの基本要素

• 実施タイミング: ISMS 内部監査または年次 BCP 訓練と合わせて設定する（例: 毎年第2四半期）
• テスト範囲: テスト用の共有ドライブ（本番データを使わない）に .docx / .xlsx / .pptx ファイルを配置し、意図的に上書きしたあとバージョン履歴から復元できるかを確認する
• 所要時間の目安: 準備（テスト用ファイルの配置・上書き）30分、復元操作・確認1〜2時間、記録・報告書作成30分——計2〜3時間を作業枠として確保しておくと ISMS 訓練の時間枠に組み込みやすい

テスト当日の確認項目

• 担当者が復元操作手順を把握しているか
• RTO 目標時間内に復元を完了できるか（タイマーで実測する）
• 管理コンソールのアラート通知設定が現在も有効か（担当者メールアドレスの更新確認を含む）
• Vault の保持ルールが対象 OU / グループに正しく適用されているか

テスト結果に問題があった場合の対応

テストで RTO 目標に間に合わなかった場合は、原因によって対処が変わります。

• 手順の把握不足が原因のとき: 復元操作の手順書を改訂し、次回テスト前に担当者が手順を通読して確認するプロセスを追加する
• 担当者の人数が足りないとき: バックアップ対応者を追加指定し、BCP 文書の連絡体制を更新する
• 通知が届いていなかったとき: 管理コンソールのアラート通知先設定を確認し、有効な担当者のアドレスに更新する

記録・報告

テスト実施記録（日時・担当者・結果・課題・改善アクション）を BCP 文書の付属資料として保管し、ISMS 審査の証跡として活用します。課題を翌年のテストで再確認するサイクルが、BCP を機能させ続けるうえで重要です。

BCP 文書への記載サンプル（参考テンプレート）

「どう書けばいいか分からない」という状況を減らすため、BCP 文書（IT-BCP 付属手順書）に追記できる参考テンプレートを示します。組織名・数値・担当者名は各組織に合わせて書き換えてください。

対象サービス: Google Workspace — Drive ランサムウェア検出・ファイル復元機能（2026年3月30日 GA）

目標値（本記載時点）

• RPO: ランサムウェア感染検出時点の最大24時間前までのデータを復元できる状態を目標とする（Drive リビジョン最大保持期間: 25日）
• RTO（営業時間内）: 検出通知受信から4時間以内に復元完了を目標とする
• RTO（夜間・休日）: 翌営業日午前中（翌日12:00まで）に復元完了を目標とする

対応担当者

• 主担当: [担当者名] / [連絡先]
• バックアップ担当: [担当者名] / [連絡先]

制約事項

• 復元対象は Microsoft Office 形式ファイル（.docx / .xlsx / .pptx 等）に限定される。Google ドキュメント・スプレッドシート・スライドは復元ツール対象外
• 復元は一括操作のみ対応（個別ファイル選択不可）
• Drive 復元機能の保持期間を超えた遡り（25日超）は Google Vault の保持ルールに従う

コンプライアンスレイヤー（Google Vault）

• Google Vault の保持ルールで Drive ファイルを最長 [X年/日数] 保持。eDiscovery および法的記録の証跡として機能する

このテンプレートに数値と担当者名を入れるだけで、IT-BCP セクションに貼り付けられる状態になります。RTO の数値は定期復元テストで実績を計測したうえで調整してください。

まとめ：BCP 文書に Drive 対応パートを追加する3ステップ

Drive 復元機能の GA をきっかけに BCP を更新するなら、進める順序は次の通りです。

まず、Drive 復元機能の仕様制約（RPO 上限25日・復元対象は Office 形式ファイルのみ・一括復元のみ）を BCP 文書に明記します。次に、Vault の保持期間をコンプライアンス要件から逆算して設定し、Drive 復元との役割分担を明確に分けて記載します。最後のステップは、年1回の復元テスト計画を ISMS 訓練と連動させてスケジュールへ落とし込み、テストで判明した課題を翌年に反映するサイクルを回すことです。この3ステップで、Drive 対応パートを持つ BCP 文書の骨格が整います。

ISMS 審査対応の観点では、「Drive 復元機能は最大25日・Vault は長期コンプライアンス保持」という2層構造を文書に明記し、年1回のテスト記録を証跡として保管することが最低ラインです。文書化と訓練のサイクルが機能している状態を目指してください。

BCP 文書は「書いたら終わり」ではなく、機能の GA・仕様変更に合わせて継続的に更新するものです。Drive 復元機能のGAは、既存の BCP 文書を棚卸しする良い機会として活用してください。

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

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