【クラウド法務】Azure Site Recovery × SLAでトラブルになりやすい3つのポイント― 「Site Recovery SLA」を導入する前に絶対に整理しておきたい責任範囲とBCP要件 ―

導入：Site Recovery は入れた。でも「SLAとして大丈夫か」は誰も答えられない

Azure 環境の BCP／DR 対策については、ドキュメントや技術ブログが充実しており、Azure Site Recovery（ASR）の構成方法やレプリケーション設定、フェイルオーバー手順など、“技術的な情報” は探せば一通り見つかります。

しかし、全国の情シス・IT部門の方から相談を受けていると、次のような声を非常によく耳にします。

「Site Recovery 自体は構築できたが、RTO/RPO や SLA としてどう説明すべきか整理できていない」「ベンダー任せで ASR を入れた結果、障害時にどこまで保証できるのかが社内で共有されていない」「営業資料では ‘高可用性・DR対応’ と書いているが、Azure Site Recovery の構成と自社の SLA が本当に噛み合っているか不安」

本記事では、「Site Recovery SLA × クラウド法務」 という視点から、全国の製造業・IT企業の案件で実際に見えてきたよくある落とし穴と、実務で使える整理方法をご紹介します。

1. Site Recovery 導入時に、現場で実際に組まれている構成イメージ

まずは「技術構成の事実」をざっくりと言語化しておきます。多くの企業での Azure Site Recovery を用いた DR 構成 は、次のような全体像になっています。

• 保護対象（プライマリ側）

  • オンプレミスの Hyper‑V / VMware / 物理サーバ

  • もしくは Azure 上の本番 VM（例：Japan East）

• レプリカ先（セカンダリ側）

  • Azure の別リージョン（Japan West / Southeast Asia 等）

  • オンプレ → Azure、Azure → Azure のパターン

• ASR 設定

  • Recovery Services コンテナー

  • レプリケーションポリシー（目標 RPO・コピー頻度・アプリ整合性の有無）

  • 計画／非計画フェイルオーバーの手順

  • テストフェイルオーバー用ネットワーク・テスト計画

• 運用まわり

  • レプリケーション状態を Azure Monitor / Log Analytics で監視

  • 一部は運用ベンダーがアラート一次対応を担当

ここまでは“技術構成図” として整理されていることが多い一方で、

• この構成で達成できる現実的な RTO/RPO はいくつなのか

• それを前提にした Site Recovery SLA（社内／取引先向け）をどう定義するか

• 障害時に「誰が・どこまで・どの時間内に」対応するのか

といった “SLA・責任” の図が存在しないケースがほとんどです。

ここまでは技術構成。ここからが「クラウド法務」の話になります。

2. 全国の案件で見えてきた「Site Recovery SLA上の落とし穴」3選

代表的なものを3つだけ挙げると、次のようなパターンです。

① 「ASRがある＝このRTOで保証できる」と思い込んでいる

技術的にはOK

• ASR で本番 VM を別リージョンにレプリケーション

• テストフェイルオーバーも導入時に一度だけ実施済み

SLA・法務的にはNGになりうる点

• 実際の復旧時間は

  • 障害検知

  • 判断・社内調整

  • ベンダー作業着手

  • フェイルオーバー実行

  • アプリ／業務確認まで含めると 設計値より大幅に長くなる ことが多い

• にもかかわらず、営業資料や取引先SLAでは「4時間以内に復旧」などと謳ってしまい、ASR 単体の性能と “サービスとしての復旧時間” を混同 している

② Microsoft の SLA と自社の Site Recovery SLA を同一視している

技術的にはOK

• Azure の SLA ドキュメントを参照し、「ゾーン冗長／リージョン冗長ならこれくらいの可用性」と理解している

契約的にはNGになりうる点

• Microsoft の SLA は「Azure プラットフォームとしてのサービス可用性」 を対象にしたもの

• 自社アプリ・ネットワーク・運用ミス・設定誤りなど、自社側の要因は一切カバーしない

• それにもかかわらず、「Azure が 99.9％ だから、うちも 99.9％ と約束できる」と考えてしまうと、現実以上の責任 を負う Site Recovery SLA を組んでしまうリスクがある

③ ベンダー責任分界と Site Recovery SLA の関係が曖昧

技術的にはOK

• ベンダーが DR 設計・構築・運用を担当しており、技術的な資料は揃っている

法務・運用的にはNGになりうる点

• 運用委託契約において、

  • DR 切替判断を誰が行うのか

  • フェイルオーバー作業を誰が実行するのか

  • 復旧時間に対してベンダーがどこまで責任を持つのかが 明文化されていない

• 結果として、障害時に「Site Recovery 自体は動いていたのに、そもそも誰がスイッチを押すのか決まっておらず復旧が遅れた」という状況になり、SLA 違反とも免責とも言い難いグレーなトラブル が起こりうる

3. Site Recovery × クラウド法務で、まず押さえるべき3つの整理軸

技術構成をいじる前に、最低限、次の3つを紙に落としておくとその後のベンダー調整・社内説明が格段に楽になります。

① 「クラウドSLA／ベンダーSLA／自社Site Recovery SLA」を切り分ける

1枚の表の中で、次の3層を分けて整理します。

• クラウド事業者（Microsoft）のSLA

  • 対象：Azure プラットフォーム（コンピュート／ストレージ等）の可用性

  • 内容：月間稼働率・サービスクレジットの条件 など

• ベンダー（運用・構築）の SLA／責任範囲

  • 監視・一次対応・DR 設計・テストフェイルオーバーの頻度 など

• 自社として対外的に約束する Site Recovery SLA

  • RTO／RPO

  • 復旧不能時の対応（代替手段・サービスクレジット・賠償上限）

  • 障害情報の開示・報告期限

この3つを “ごちゃ混ぜにしない” ことが、SLAトラブルを避ける第一歩です。

② RTO/RPO・ASR 設定値・業務影響をひとつの軸にまとめる

• 技術側の前提

  • レプリケーション頻度（RPO）

  • フェイルオーバーに要する作業時間

  • テストで実測した復旧時間（RTO）

• 業務・契約側の前提

  • そのシステムが止まると、どの業務・どの取引先にどれだけ影響するか

  • 取引先との契約・社内 BCP で要求されている復旧時間

これらを合わせて、「この ASR 構成なら、このレベルまでなら Site Recovery SLA として約束できる」というラインを決めていきます。

③ フェーズ別の責任分界（設計／平常時／障害時／訓練）

Site Recovery SLA を設計するうえでは、フェーズごとに「誰が・どこまで・いつまでに」を切り分けることが重要です。

• 設計フェーズ

  • どのシステムを ASR 対象にするか

  • RTO/RPO のターゲット値を誰が決めるか

• 平常運用フェーズ

  • レプリケーションエラーへの対応

  • テストフェイルオーバーの頻度と実施者

• 障害・災害フェーズ

  • DR 切替の判断を誰が行うか（経営／情シス／ベンダー）

  • フェイルオーバー作業を誰が実行するか

  • 復旧後の動作確認・業務確認を誰が担当するか

• 訓練・改善フェーズ

  • 年何回・どの範囲で訓練を行うか

  • 結果を Site Recovery SLA／BCP にどう反映させるか

このフェーズ別責任分界を、契約書・運用設計書・BCP計画に落とし込む ことで、「ASR はあるのに役割が決まっていない」状態を避けられます。

4. ケーススタディ：製造業A社（売上1,000億円、拠点10カ国）の場合

実際に当事務所でご相談を受けた事例の一つをご紹介します（業種等は匿名化しています）。

• 業種：製造業（BtoB）

• 売上規模：約1,000億円

• 拠点：日本本社＋欧州・アジア計10カ国

• テーマ：Azure Site Recovery 導入済み環境における Site Recovery SLA の再設計

課題の整理

• 数年前に ベンダー主導で ASR を導入し、技術構成自体は稼働している

• BCP計画書には「基幹システムは4時間以内に復旧」と記載があるが、

  • 実際の ASR 設定

  • ベンダーの運用体制（夜間・休日）を踏まえると 達成可能か誰も説明できない

• 取引先向け SLA でも「4時間以内」を前提としており、障害発生時の責任・賠償リスクに経営層が不安を抱いていた

当事務所の支援内容（抜粋）

• ASR 構成と実測復旧時間の棚卸し

  • テストフェイルオーバーを実施し、実際の復旧時間・手順・ボトルネックを整理

• クラウドSLA／ベンダーSLA／自社SLAの三層整理

  • Microsoft の SLA

  • ベンダーの運用委託契約

  • 自社が取引先に提示している SLAを 1 枚のマトリクスにまとめて可視化

• 現実的な Site Recovery SLA 案の策定

  • 実測値と業務影響を踏まえ、サービスランク別（標準／プレミア）に分けて RTO を再設計

  • それに応じた賠償・免責条項案も作成

• 契約・BCP文書・社内説明資料のアップデート

  • 取引先向け約款・個別契約の改定案（Site Recovery SLA 部分）

  • 監査・親会社向けの説明スライド

  • 営業・情シス向けの QA 集 を作成

結果として

• Site Recovery SLA に関する “技術と契約のギャップ” が解消され、「この構成ならこのレベルまでは責任をもてる」というライン を経営層と共有できるようになった

• 取引先への説明も整理され、「ASR があるから大丈夫」ではなく、前提条件と限界を含めた透明性の高いSLA説明 に切り替えられた……といった声をいただいています。

5. Site Recovery 導入済み企業が、今すぐ確認しておきたいチェックポイント

自社で検討を進める際のチェックリストとして、次の項目を挙げておきます。

• □ Azure Site Recovery の構成（対象システム・リージョン・レプリケーション設定）が　 1枚の図で説明できる

• □ 各システムの RTO/RPO・ASR設定値・実測復旧時間 が整理されている

• □ Microsoft の SLA／ベンダーの運用SLA と、　 自社が外部に約束している Site Recovery SLA を明確に分けて説明できる

• □ 障害・災害時の　 フェイルオーバー判断者・実行者・業務確認者 が文書化されている

• □ BCP計画書・取引先との契約・営業資料のあいだで、　 「約束している復旧レベル」と「実際にできる復旧レベル」が一致している

「すべて自信を持って YES と言える企業」は、全国的に見てもまだ多くありません。

6. 全国からのご相談について

山崎行政書士事務所では、Microsoft Azure / Site Recovery / Backup 等の技術構成と、SLA・契約・BCP/DR・監査対応をセットで整理する「クラウド法務支援」 を行っています。

• Site Recovery を導入しているが、SLA・責任分界・賠償条件があいまいで不安が残っている

• BCP計画書や取引先SLAと、ASR の実際の構成・ベンダー契約の内容が噛み合っているか確認したい

• 監査・親会社・大口取引先からの質問に、技術と契約をセットにしたストーリーで答えられるようにしたい

といったお悩みがあれば、オンライン（全国対応） にて初回のご相談を承っております。

👉 ご相談フォームはこちら

👉 お問い合わせの際に、「Site Recovery SLA の記事を見た」 と書いていただけるとスムーズです。