Azure Site RecoveryでRTO/RPO/SLAを説明できるか

BCP文書とAzure構成を突合し、「復旧できるはず」から「証跡で説明できるDR」へ

確認日：2026年7月9日対象読者：経営層、情シス担当者、クラウド運用担当者、監査対応担当者、BCP/DR担当者対象領域：Azure Site Recovery、BCP、DR、RTO、RPO、SLA、復旧計画、テストフェールオーバー、監査証跡

結論

Azure Site RecoveryでRTO/RPO/SLAは説明できます。ただし、Azure Site Recoveryを有効化しているだけでは説明できません。

説明できる状態とは、次の3つが一致している状態です。

観点	必要な状態
BCP文書	業務ごとのRTO、RPO、復旧優先順位、責任者が明記されている
Azure構成	Azure Site Recovery、復旧計画、ネットワーク、DNS、認証、監視がBCPと一致している
証跡	テストフェールオーバー結果、ASRジョブ時間、RPO、承認記録、改善履歴が残っている

RTO/RPOは経営・業務側の要求です。SLAはMicrosoftが提供するサービス上の約束です。そして、実際に会社が監査や事故対応で説明すべきなのは、**「当社の業務は、どの条件なら、何分で、どの時点まで復旧できるのか」**です。

Microsoft公式では、RPOは災害時に許容できるデータ損失量を時間で測定した最大許容範囲、RTOは障害後に業務を復元できる最大許容時間と定義されています。Azure Site Recoveryについては、Azure VM、オンプレミスVM、物理サーバーなどのレプリケーション、フェールオーバー、フェールバックを管理できるサービスとして説明されています。

理由

BCP文書とAzure構成が一致していない場合、災害時に次のような問題が起きます。

BCP上の記載	実際のAzure構成	起きる問題
RTO 1時間	復旧計画未作成、手順は口頭	1時間以内に復旧できる根拠がない
RPO 15分	ASRのRPO監視なし	データ損失見込みを説明できない
自動切替	Azure Site Recoveryのフェールオーバーは手動起動	災害時に誰が押すのか不明
全システムDR対象	一部VMだけASR保護	依存サービスが復旧せずアプリが起動しない
四半期訓練	テストフェールオーバー履歴なし	監査で実効性を示せない
顧客向けSLA 99.9%	アプリ全体の復旧試験なし	Microsoft側SLAと自社サービスSLAを混同

Microsoft公式では、Azure Site Recoveryのテストフェールオーバーは、データ損失やダウンタイムを発生させず、実行中のレプリケーションや運用環境に影響を与えずにDR戦略を検証できるものと説明されています。つまり、BCP文書に書いた復旧目標は、机上ではなくテストフェールオーバーで確認する必要があります。

数字で見る：BCP/DR計画とAzure設計の突合で確認すべき15項目

No.	確認項目	確認内容
1	業務重要度	どの業務を最優先で復旧するか
2	RTO	業務として何分・何時間以内に復旧する必要があるか
3	RPO	何分・何時間分のデータ損失を許容するか
4	ASR保護対象	BCP対象サーバーがすべて保護されているか
5	復旧計画	VM起動順序、依存関係、手動作業が定義されているか
6	復旧ポイント	最新、最新処理済み、アプリ整合性などの選択基準があるか
7	ネットワーク	フェールオーバー後のVNet、Subnet、NSG、UDR、Firewall
8	DNS	利用者が復旧先へ接続できる名前解決設計
9	認証	Entra ID、AD、証明書、Key Vault、Managed Identity
10	データ整合性	DB、ファイル、アプリ整合性、マルチVM整合性
11	容量	復旧先リージョンのVM SKU・ディスク・IP・クォータ
12	監視	ASRアラート、RPO監視、Replication Health、ジョブ失敗
13	訓練	テストフェールオーバーの頻度、結果、改善履歴
14	承認	災害宣言、フェールオーバー、フェールバック、切戻し承認
15	証跡	BCP、Azure構成、ASRジョブ、KQL、承認記録の保管

1. まずRTO/RPO/SLAを分けて説明する

RTO、RPO、SLAは混同されやすい言葉です。経営層向け資料では、最初に分けて説明する必要があります。

表1：RTO/RPO/SLAの違い

用語	意味	誰が決めるか	Azureで確認するもの	注意点
RTO	何時間以内に業務を復旧するか	経営・業務部門	ASRジョブ時間、復旧計画、起動確認時間	ASRジョブ時間だけでは業務RTOにならない
RPO	どの時点までのデータ損失を許容するか	経営・業務部門	最新復旧ポイント、RPO、復旧ポイント履歴	RPOに定義済みSLAはない
SLA	サービス提供者の約束	Microsoftまたは自社	Microsoft SLA、自社顧客向けSLA	MicrosoftのSLAと自社アプリSLAは別

Azure Site RecoveryのRTOについて、Microsoft公式FAQでは、仮想マシンフェールオーバーのRTO SLAは1時間であり、多くの場合は数分でフェールオーバーすると説明されています。一方で、RPOについては、ゾーン間DRの公式FAQで「RPOには定義されたSLAがない」と説明されています。

2. 図で見る：BCP文書とAzure構成の関係

図1：BCPからAzure Site Recoveryまでの突合フロー

BCP / BIA
業務影響分析
    │
    ▼
業務ごとのRTO / RPO
    │
    ▼
システム重要度分類
Tier 1 / Tier 2 / Tier 3
    │
    ▼
Azure設計
ASR / Backup / PaaS DR / DNS / Network
    │
    ▼
復旧計画
起動順序・手動作業・Runbook
    │
    ▼
テストフェールオーバー
実測RTO / 実測RPO / 課題
    │
    ▼
BCP文書へ反映
承認・証跡・改善履歴

重要なのは、BCP文書からAzure構成へ落とすことです。逆に、「Azure Site Recoveryを設定したのでBCPは大丈夫」という順番では、経営判断や監査説明に耐えません。

3. Azure Site Recoveryで保護できる範囲

Azure Site Recoveryは、主に仮想マシンや物理サーバーのDRを管理するサービスです。

Microsoft公式では、Site RecoveryはAzure VMのリージョン間レプリケーション、Azure Extended Zonesからリージョンへのレプリケーション、オンプレミスVM、Azure Stack VM、物理サーバーのレプリケーションを管理できると説明されています。

表2：Azure Site Recoveryで整理すべき対象

対象	ASRでの扱い	BCP突合ポイント
Azure VM	Azure VM間DR対象	保護対象VM一覧とBCP対象システムが一致するか
VMware VM	AzureへのDR対象	アプライアンス、帯域、認証、依存関係
Hyper-V VM	AzureへのDR対象	レプリケーション頻度、ネットワーク
物理サーバー	AzureへのDR対象	OS、エージェント、復旧後の運用
SQL Server on VM	VMとして保護可能	DB整合性、Always On等との役割分担
Azure SQL Database	ASR対象ではなくPaaS側DR	Geo-replication、Failover Group等を別途設計
Storage Account	ASR対象ではない	冗長化、Backup、Immutable、復元手順
Key Vault	ASR対象ではない	バックアップ、Soft Delete、Purge Protection
DNS / Front Door / Firewall	ASR対象ではない	復旧先切替・ルール・証跡を別途設計

MicrosoftのWell-Architected Frameworkでは、IaaSではAzure Site Recoveryを使ってフェールオーバーと復旧を自動化し、PaaS製品については各サービスのDR機能を理解して復旧手順に含める考え方が示されています。

4. RTOは「ASRジョブ時間」だけではない

Azure Site Recoveryのジョブ時間は重要です。しかし、会社が説明すべき業務RTOは、ASRジョブ時間だけではありません。

図2：業務RTOの内訳

障害発生
  │
  ├─ 検知時間
  ├─ 影響確認
  ├─ 災害宣言・承認
  ├─ ASRフェールオーバー実行
  ├─ VM起動
  ├─ ネットワーク / DNS切替
  ├─ アプリ起動確認
  ├─ DB整合性確認
  ├─ 利用者向け案内
  ▼
業務再開

表3：RTO構成要素

RTO構成要素	Azureで確認するもの	証跡
障害検知	Azure Monitor、Service Health、Sentinel	アラート履歴
災害宣言	BCP手順、承認者	チケット、会議記録
ASR起動	Failover Job	ASRJobs
VM起動	VM状態、Boot diagnostics	Azure Activity Log
ネットワーク復旧	VNet、NSG、Firewall、Public/Private IP	構成図、疎通試験
DNS切替	DNS Zone、Traffic Manager、Front Door	DNS変更履歴
アプリ確認	URL、API、DB接続	動作確認記録
業務再開判断	業務責任者の承認	完了報告

Microsoft公式では、ASRの復旧計画はVMのフェールオーバーと復旧をオーケストレーションし、依存関係を定義し、手動アクションも含めて自動化できるものとして説明されています。また、復旧計画のRTOを確認するにはテストフェールオーバーを行い、Site Recoveryジョブで所要時間を確認するとされています。

5. RPOは「最新を選べばよい」ではない

RPOを最小化したい場合、Azure Site Recoveryでは復旧ポイントの選択が重要です。

Microsoft公式では、Latest、つまり最低RPOの復旧ポイントを選ぶと、Site Recoveryサービスに送信済みのすべてのデータを処理してから復旧ポイントを作成するため、RPOは低くできます。一方で、未処理データの処理が入るため、RTOは高くなると説明されています。Latest processedは、処理済みの最新復旧ポイントを使うためRTOを低くできます。

図3：RPOとRTOのトレードオフ

Latest processed
  │
  ├─ RTO：短い
  └─ RPO：処理済み最新時点


Latest / Lowest RPO
  │
  ├─ RTO：長くなる可能性
  └─ RPO：より低くできる可能性

表4：復旧ポイント選択の判断表

復旧ポイント	優先するもの	向いている場面	注意点
Latest processed	RTO短縮	業務再開を急ぐ	直近未処理データは含まれない可能性
Latest / Lowest RPO	RPO最小化	データ損失を抑えたい	処理待ちがあるとRTOが伸びる
Latest app-consistent	アプリ整合性	DB、業務アプリ	アプリ整合性スナップショット設定が前提
Custom	特定時点復旧	障害前時点へ戻したい	単一VMでの利用に限定される場合あり
Multi-VM processed	複数VM整合性	多層アプリ	マルチVM整合性設計が前提

6. 復旧ポイントの間隔と保持期間をBCPと突合する

Azure Site Recoveryの一般FAQでは、クラッシュ整合性復旧ポイントは5分ごとに作成され、アプリケーション整合性復旧ポイントは最短1時間ごとに作成できると説明されています。また、既定のレプリケーションポリシーでは復旧ポイント保持が1日、アプリ整合性スナップショットなしで作成されるとされています。

表5：BCP要求とASR設定の突合

BCP要求	ASR設定で見るもの	判定例
RPO 5分以内	クラッシュ整合性復旧ポイント、RPO監視	DB整合性が必要なら別検討
RPO 1時間以内	アプリ整合性復旧ポイント頻度	SQL等はアプリ整合性を確認
3日前へ戻したい	復旧ポイント保持期間	Managed Diskなら最長15日が目安
ランサムウェア前へ戻したい	ASRだけでなくBackup/Immutable	ASRは長期バックアップではない
データ損失ゼロ	計画フェールオーバー、同期技術	ASRの非同期DRだけで満たせるか要検証

ASRの一般FAQでは、Managed Diskで使用できる最古の復旧ポイントは15日、Unmanaged Diskでは3日と説明されています。復旧ポイント保持を増やすと追加のストレージコストが発生する点も示されています。

7. ASRのSLAと自社SLAを混同しない

Azure Site RecoveryのSLAは、Microsoftが提供するSite Recoveryサービス上の約束です。しかし、自社が顧客や経営層へ説明するSLAは、アプリ全体の可用性・復旧性です。

MicrosoftのSLAページでは、Microsoft Online ServicesのSLAはMicrosoftの稼働時間や接続性に関するコミットメントを説明するものとされ、最新版・過去版のSLAがダウンロード可能とされています。

図4：SLAの範囲を分ける

Microsoft側SLA
  ├─ Azure Site Recoveryサービス
  ├─ Azure VM
  ├─ Storage
  ├─ Network
  └─ Microsoft Online Services SLA


自社側SLA
  ├─ アプリケーション復旧
  ├─ DB整合性
  ├─ DNS切替
  ├─ 利用者接続
  ├─ 業務再開判断
  └─ 顧客・取引先への説明

表6：説明で避けるべき表現

避けるべき表現	理由	正しい表現
ASRがあるので1時間で業務復旧できます	業務復旧にはDNS、DB、認証、確認作業が含まれる	ASRのVMフェールオーバーRTOと、業務RTOを分けて管理します
RPOは保証されています	RPOに定義されたSLAはありません	RPOは復旧ポイント実績とテスト結果で説明します
DRは自動です	ASRのフェールオーバーは既定で自動ではありません	災害宣言後、承認手順に従い手動または自動化で起動します
VMが起動すれば復旧完了です	アプリ・DB・DNS・認証確認が必要	業務再開判定までをRTOに含めます

Azure Site Recoveryの一般FAQでは、フェールオーバーは自動ではなく、ポータルのクリックやPowerShellで開始すると説明されています。自動化する場合は、検知・判断・起動の設計が必要です。

8. BCP文書とAzure構成の突合マトリクス

表7：BCP/DR突合マトリクス

BCP文書の項目	Azureで確認する項目	証跡	判定
対象業務	対象VM、PaaS、依存サービス	システム台帳	一致 / 不一致
復旧優先順位	Recovery Planのグループ順序	復旧計画画面	一致 / 不一致
RTO	Test Failover Job Duration	ASRJobs	達成 / 未達
RPO	Last RPO、復旧ポイント時刻	ASRReplicatedItems、Recovery Points	達成 / 未達
復旧先	Target region、Target VNet	ASR設定、構成図	一致 / 不一致
ネットワーク	VNet mapping、NSG、Firewall	IaC、Activity Log	一致 / 不一致
DNS	Traffic Manager、Front Door、Private DNS	DNS変更履歴	一致 / 不一致
認証	AD、Entra ID、Key Vault	権限設計書	一致 / 不一致
DB整合性	アプリ整合性、DB側DR	テスト結果	一致 / 不一致
承認者	災害宣言、フェールオーバー承認	チケット、会議ログ	明確 / 不明
訓練頻度	Test Failover履歴	ASRJobs、訓練報告書	達成 / 未達
改善管理	課題、期限、担当	DR改善台帳	管理 / 未管理

9. 復旧計画は「起動順序」を説明するために使う

多層アプリケーションでは、VMを一斉に起動すればよいわけではありません。DB、認証、バックエンド、フロントエンド、バッチ、監視の順序が必要です。

Microsoft公式では、Azure Site Recoveryの復旧計画は、マシンを復旧グループにまとめ、フェールオーバー後の起動順序を定義でき、最大100個の保護インスタンスを1つの復旧計画に追加できると説明されています。また、依存関係をモデル化し、RTO削減のため復旧タスクを自動化する用途が示されています。

図5：三層アプリの復旧順序

Group 1
  └─ Domain Controller / DNS / 基盤サービス

Group 2
  └─ Database / File Server / Queue

Group 3
  └─ API / Middleware

Group 4
  └─ Web Frontend / Load Balancer設定

Group 5
  └─ 監視確認 / 業務確認 / 公開切替

表8：復旧計画設計表

グループ	対象	確認内容	手動/自動
Group 1	AD/DNS/基盤	名前解決、認証	手動確認
Group 2	DB	DB起動、整合性確認	手動＋スクリプト
Group 3	API	DB接続、環境変数	Runbook
Group 4	Web	URL応答、証明書	Runbook
Group 5	切替	DNS/Traffic切替、業務確認	承認後実行

復旧計画では、異なるグループは順番に実行され、同一グループ内のマシンは並列にフェールオーバーされます。

10. Runbookで「手作業の抜け」を減らす

DRで失敗しやすいのは、VM起動後の作業です。

VM起動後に必要になりやすい作業	例
IP/DNS切替	Public IP、Private DNS、Traffic Manager
証明書確認	Key Vault、TLS証明書
アプリ設定	Connection String、環境変数
監視設定	Alert、Action Group
Firewall/NSG	復旧先通信許可
利用者案内	公開URL、運用連絡
業務確認	ログイン、検索、登録、帳票、API

Microsoft公式では、Azure Automation RunbookをRecovery Planに追加でき、手動介入が必要な基本タスクを自動化し、複数ステップの復旧を単一操作に近づけることができると説明されています。Runbookはフェールオーバー時やフェールバック時に実行できます。

11. 復旧先の容量は「ベストエフォート」として説明する

RTOを経営層に説明するとき、復旧先リージョンの容量も重要です。

Microsoft公式FAQでは、Site RecoveryチームとAzure容量管理チームは十分なインフラ容量をベストエフォートで計画すると説明されています。一方で、Site Recoveryは復旧リージョンの容量を保証するものではなく、さらに確実なコンピュート容量が必要な場合はCapacity Reservationが推奨されています。

表9：容量設計レビュー

項目	確認内容
VM SKU	復旧先リージョンで同一SKUが使えるか
vCPUクォータ	フェールオーバー時に必要なコア数があるか
ディスク	Target diskの種類、性能、暗号化
IP	Private IP、Public IP、Load Balancer
Capacity Reservation	重要VMで必要か
Reserved Instance	DR側の費用最適化に使うか
テストフェールオーバー	実際にVM作成できるか

12. テストフェールオーバーは四半期単位で見直す

DR計画は、1回作って終わりではありません。

Microsoft公式の復旧計画ページでは、フルフェールオーバー前にアプリのテストフェールオーバーを完了すること、アプリがスムーズに復旧するまで複数回テストすること、アプリと依存関係は頻繁に変わるため各アプリのテストフェールオーバーを四半期ごとに実行することが推奨されています。

表10：DR訓練で確認する項目

項目	確認内容
実測RTO	Test Failover開始から業務確認完了まで
実測RPO	使用した復旧ポイント時刻
起動順序	Recovery Planどおりに起動したか
DNS	利用者が復旧先へ接続できるか
認証	ログイン、権限、証明書が正常か
DB	整合性、トランザクション、アプリ接続
運用	監視、バックアップ、ログ、通知
例外	手動対応、未自動化、未保護リソース
改善	次回までの担当・期限

13. 監視と証跡はAzure Monitor Logsで残す

Azure Site Recoveryは、監視・証跡を残せるように設計すべきです。監査で重要なのは、「訓練しました」ではなく、いつ、誰が、どのRecovery Planで、何分かかり、どのRPOだったかを示すことです。

Microsoft公式では、Azure Monitor LogsとLog Analyticsを使い、Site Recoveryの正常性、レプリケーション状態、テストフェールオーバー状態、イベント、RPO、データ変更率を監視できると説明されています。

表11：保存すべきログ

ログ	用途
ASRJobs	フェールオーバー、テストフェールオーバー、再保護などのジョブ履歴
ASRReplicatedItems	レプリケーション正常性、フェールオーバー準備状況、RPO計算時刻
AzureActivity	Recovery Services Vault、ASR設定変更
AzureDiagnostics	旧形式・診断ログ
Service Health	Azure側障害の確認
チケット	災害宣言、承認、作業履歴
DR訓練報告書	業務確認、課題、改善計画

ASRJobsテーブルには、Failover、Test failover、Reprotectionなどのジョブ、DurationMs、Status、OperationNameなどが含まれます。ASRReplicatedItemsには、ReplicationStatus、FailoverReadiness、LastRpoCalculatedTime、LastSuccessfulTestFailoverTimeなどが含まれます。

KQL例：テストフェールオーバーの所要時間確認

ASRJobs
| where TimeGenerated > ago(180d)
| where OperationName has "Test"
| project TimeGenerated, VaultName, OperationName, SourceFriendlyName,
          Status, DurationMinutes = round(DurationMs / 60000.0, 2),
          ResultDescription
| order by TimeGenerated desc

KQL例：保護対象のレプリケーション状態確認

ASRReplicatedItems
| summarize arg_max(TimeGenerated, *) by ReplicatedItemUniqueId
| project TimeGenerated, VaultName, ReplicatedItemFriendlyName,
          ReplicationStatus, FailoverReadiness,
          PrimaryFabricName, RecoveryRegion,
          LastRpoCalculatedTime, LastSuccessfulTestFailoverTime
| order by ReplicatedItemFriendlyName asc

14. ASRの費用もBCPに入れる

DR設計では、費用も経営判断の材料です。

Microsoft公式の価格ページでは、Azure Site Recoveryは保護インスタンス数に基づいて課金され、保護された各インスタンスは最初の31日間無料と説明されています。また、最初の31日間無料であっても、Azure Storage、ストレージトランザクション、データ転送、復旧VMのコンピュートなどの料金が発生する可能性があると説明されています。

表12：DR費用の説明項目

費用項目	内容
ASRライセンス	保護インスタンス単位
レプリカディスク	復旧先に保持するディスク
復旧ポイント	スナップショット相当の保持コスト
データ転送	リージョン間レプリケーション
Cache Storage	レプリケーション用
テストフェールオーバー	起動したVMのコンピュート費
実フェールオーバー	復旧先VM、ディスク、ネットワーク費
監視	Log Analytics、アラート
運用	訓練、Runbook、手順書、監査対応

15. BCP/DR突合台帳テンプレート

表13：BCP/DR計画とAzure設計の突合台帳

項目	記入例
管理番号	DR-2026-001
対象業務	受注管理システム
重要度	Tier 1
業務RTO	60分
業務RPO	15分
復旧優先順位	1
対象Azureリソース	VM3台、SQL VM、Key Vault、Private DNS
ASR保護対象	VM3台
ASR対象外依存	Key Vault、DNS、Firewall、Storage
復旧先リージョン	Japan West
Recovery Plan	rp-order-prod
起動順序	AD/DNS → DB → API → Web
復旧ポイント方針	最新処理済み。DBはアプリ整合性確認
災害宣言者	情報システム部長
フェールオーバー承認者	経営層、業務責任者
テスト頻度	四半期
最終テスト日	2026-06-30
実測RTO	42分
実測RPO	7分
未解決課題	DNS切替手順をRunbook化
次回改善期限	2026-09-30

16. RACI：誰が何を決めるのか

表14：BCP/DR運用RACI

作業	経営層	情シス責任者	Azure基盤	アプリ担当	セキュリティ	業務部門	監査/規程
業務重要度決定	A	C	I	C	C	R	C
RTO/RPO決定	A	R	C	C	C	R	C
ASR設計	I	A	R	C	C	I	C
復旧計画作成	I	A	R	R	C	C	C
DNS/ネットワーク切替	I	A	R	C	C	I	I
テストフェールオーバー	I	A	R	R	C	C	C
災害宣言	A	R	C	C	C	C	I
フェールオーバー実行	I	A	R	C	C	I	I
業務再開判定	A	C	C	C	I	R	I
証跡保存	I	A	R	C	C	C	R
BCP改訂	A	R	C	C	C	C	R

R：実行責任、A：説明責任、C：相談先、I：共有先

17. BCP/DR突合で見つかる典型的なギャップ

表15：ギャップと是正策

ギャップ	影響	是正策
BCP対象サーバーがASR未保護	復旧できない	保護対象台帳を作成しASR設定
復旧計画がない	起動順序が属人化	Recovery Plan作成
RTOが実測されていない	経営説明不能	テストフェールオーバーで測定
RPO監視なし	データ損失説明不能	Azure Monitor Logsで可視化
DNS切替が手作業	RTO超過	Runbook化・手順化
DB整合性未確認	起動後に業務不可	アプリ整合性・DB側DRを確認
復旧先容量未確認	フェールオーバー失敗	クォータ・Capacity Reservation検討
PaaSがASR対象外	アプリ全体が復旧しない	PaaSごとのDR手順を追加
訓練記録なし	監査で弱い	四半期テストと報告書
フェールバック手順なし	元に戻せない	Reprotect/Failback手順整備

18. BCP文書に入れるべきAzure項目

表16：BCP文書への追記項目

項目	記載内容
対象システム	Azureリソース名、業務名、所有者
復旧目標	RTO、RPO、優先順位
復旧先	リージョン、VNet、Subnet、DNS
ASR構成	Vault、Replication Policy、Recovery Plan
復旧ポイント	選択基準、アプリ整合性、マルチVM整合性
起動順序	グループ、依存関係、手動アクション
切替	DNS、Front Door、Traffic Manager、Firewall
監視	Azure Monitor、ASRアラート、Log Analytics
承認	災害宣言、実行者、承認者
訓練	頻度、方法、証跡、改善
フェールバック	再保護、切戻し、業務確認
例外	未保護リソース、代替策、期限

19. 規程文サンプル

第○条（Azure Site Recoveryを利用したBCP/DR管理）

1. 当社は、Azure上またはオンプレミス上の重要システムについて、
   業務影響分析に基づきRTOおよびRPOを定義し、BCP/DR台帳に記録する。

2. Azure Site Recoveryを利用するシステムについては、
   対象VM、復旧先リージョン、復旧計画、復旧ポイント方針、
   ネットワーク、DNS、認証、監視をBCP文書と突合する。

3. Azure Site RecoveryのRTO SLAは、当社業務全体のRTOを保証するものではない。
   当社業務RTOは、障害検知、災害宣言、フェールオーバー、VM起動、
   DNS切替、アプリ確認、業務再開判断までを含めて管理する。

4. RPOについては、定義済みSLAに依存せず、
   Azure Site Recoveryの復旧ポイント、RPO監視、テストフェールオーバー結果により確認する。

5. 重要システムについては、少なくとも四半期ごとにテストフェールオーバーを実施し、
   実測RTO、実測RPO、課題、改善期限、承認者を記録する。

6. 復旧計画、フェールオーバー、フェールバック、例外対応、手順変更は、
   変更管理手続に基づき、承認および証跡を残す。

20. 経営層向け説明資料の1枚テンプレート

表17：経営向けDR比較資料

項目	現状	目標	差分	対応方針
対象業務	受注管理	Tier 1	重要	最優先復旧
RTO	不明	60分	未測定	テストフェールオーバーで測定
RPO	不明	15分	未監視	RPO監視を有効化
DR方式	VM単位ASR	アプリ単位復旧	復旧計画なし	Recovery Plan作成
DNS切替	手動	15分以内	手順未整備	Runbook化
DB整合性	未確認	アプリ整合性	検証不足	テスト時確認
訓練	年1回未満	四半期	不足	訓練計画作成
証跡	バラバラ	監査提示可能	不足	台帳・KQL・報告書

21. 山崎行政書士事務所としての支援領域

Azure Site Recoveryの導入は、単なるクラウド設定ではありません。BCP、DR、監査、経営判断、契約、委託先責任、証跡管理と直結します。

山崎行政書士事務所では、Azure技術支援とクラウド法務・ガバナンス支援を一体で行います。

領域	支援内容
Azure技術支援	Azure Site Recovery設計、Recovery Plan、テストフェールオーバー支援
BCP/DR突合	BCP文書とAzure構成の差分整理
RTO/RPO整理	業務RTO/RPO、ASR実測値、復旧ポイントの説明資料
監査対応	ASRJobs、ASRReplicatedItems、訓練報告書、承認証跡整理
規程整備	BCP規程、DR運用規程、クラウド変更管理規程
経営説明	費用対効果、復旧優先順位、投資判断資料
契約・委託管理	運用委託、SLA、責任分界、報告様式整理

行政書士業務の範囲を踏まえ、個別紛争対応や訴訟代理など弁護士領域に属する事項は切り分けたうえで、企業がクラウドを安全に利用するための規程整備、契約関連資料、監査説明資料、運用ルール整備を支援します。

まとめ

Azure Site RecoveryでRTO/RPO/SLAを説明することは可能です。ただし、説明できるのは、Azure Site Recoveryの設定がBCP文書と一致し、テストフェールオーバーで実測され、証跡として残っている場合です。

重要なのは、次の5点です。

重要ポイント	内容
RTO/RPO/SLAを分ける	MicrosoftのSLAと自社業務RTOは別
BCPとAzure構成を突合する	文書・構成・手順・証跡を一致させる
復旧計画を作る	起動順序、依存関係、Runbookを定義する
テストフェールオーバーで測る	机上ではなく実測RTO/RPOで説明する
証跡を残す	ASRジョブ、KQL、承認、改善履歴を保管する

BCP文書とAzure構成が一致していなければ、災害時に「復旧できるはず」は通用しません。必要なのは、復旧できる設計、実測された訓練結果、監査で説明できる証跡です。

Azure Site Recovery設計、RTO/RPO/SLA整理、BCP/DR計画とAzure構成の突合、監査対応資料の整備は、山崎行政書士事務所へご相談ください。

出典・確認日

確認日：2026年7月9日

出典	確認した主な内容	表示日・公開日
Microsoft Learn：ディザスターリカバリーのためのアーキテクチャ戦略	RTO/RPOの定義、IaaSではASRでフェールオーバーと復旧を自動化する考え方	2025年11月20日
Microsoft Learn：About Azure Site Recovery	ASRの保護対象、Azure VM・オンプレVM・物理サーバー等のレプリケーション	2026年6月4日
Microsoft Learn：Azure VM disaster recovery FAQ	ASRのRTO SLA、復旧計画、復旧ポイント、容量、Capacity Reservation	2025年7月25日
Microsoft Learn：Site Recovery general FAQ	フェールオーバーは自動ではないこと、復旧ポイント、クラッシュ整合性、アプリ整合性、保持期間	2025年6月13日
Microsoft Learn：Zone-to-zone disaster recovery	RTO SLAはSite Recovery全体と同じ、RPOに定義済みSLAはないこと	2025年2月12日
Microsoft Learn：テストフェールオーバー	本番に影響せず、データ損失やダウンタイムなしでDR訓練を検証できること	2025年10月31日
Microsoft Learn：Recovery Plans	復旧計画、起動順序、最大100保護インスタンス、四半期ごとのテスト推奨	2025年1月22日
Microsoft Learn：Runbooks in Recovery Plans	Azure Automation Runbookによる復旧手順自動化	2025年8月19日
Microsoft Learn：Monitor Site Recovery with Azure Monitor Logs	Site Recoveryの正常性、RPO、テストフェールオーバー、ジョブ状態の監視	2026年2月13日
Microsoft Learn：ASRJobs / ASRReplicatedItems	ASRジョブ履歴、DurationMs、Status、RPO計算時刻、フェールオーバー準備状況	2026年3月11日
Microsoft Azure：Site Recovery Pricing	保護インスタンス単位の課金、31日間無料、Storage・転送・Compute等の追加費用	確認日：2026年7月9日
Microsoft Licensing：SLA for Online Services	Microsoft Online Services SLAの位置付け、最新版SLAの提供	2026年7月版
NIST SP 800-34 Rev.1	情報システムのコンティンジェンシープラン、テスト・訓練・演習の重要性	2010年11月11日