【クラウド法務】Azure Site Recovery × ベンダー責任分界でトラブルになりやすい3つのポイント― 「Site Recovery ベンダー責任分界」を導入前に必ず整理しておきたい契約・責任範囲 ―

導入：Site Recoveryは入れた。でも「誰の責任で復旧するか」は曖昧なまま

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

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

「ASR で Azure の DR 構成は組んだが、障害時にベンダーと自社の責任分界が整理できていない」「“BCP対策やりました” と社内で説明したものの、RTO/RPO やフェイルオーバー作業を誰がやるのか契約上あいまい」「監査や親会社のレビューで、“この Site Recovery 構成で本当に大丈夫か” と聞かれても、SLA・契約・実運用との関係を説明しきれない」

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

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

まずは「技術構成としてどうなっているか」を、ざっくり言語化しておきます。多くの企業での Azure Site Recovery（ASR）ベースの DR 構成 は、次のようなイメージです。

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

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

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

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

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

  • オンプレ → Azure、Azure → Azure のいずれか／両方

• ASR の構成要素

  • Recovery Services コンテナー

  • レプリケーションポリシー（RPO 目標・レプリケーション頻度など）

  • フェイルオーバー／フェイルバックのプロセス（計画／非計画）

  • テストフェイルオーバー用のサンドボックス環境

• 運用・監視周り

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

  • 一部は運用ベンダーが 24/365 監視を担当

このあたりまでは、多くの企業で 「ASR を使った技術構成図」 として整理されています。

一方で、次のような 「ベンダー責任分界・契約・BCP計画の図」 が存在しないケースが非常に多いのが実情です。

• 障害・災害発生時に誰が・どのタイミングで・どこまで対応するのか（フェイルオーバー／フェイルバック等）

• RTO/RPO の達成責任が、Microsoft／ベンダー／自社 のどこにあるのか

• DR リージョン・DR 用ネットワーク・アプリ確認などの範囲を、どこまでベンダーが担当し、どこから先を自社・事業部門が担うのか

ここまでは“技術構成”として ASR の図がある一方で、「契約上・BCP上、どこからどこまで誰の責任か」 の図が存在しないケースがほとんどです。

ここから先が、「Site Recovery ベンダー責任分界」＝クラウド法務の領域になります。

2. 全国の案件で見えてきた「クラウド法務上の落とし穴」3選

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

① 「ASR を入れた＝ベンダーが全部やってくれる」と思い込んでいる

• 技術的にはOK

  • ベンダー主導で ASR を導入し、レプリケーション状態も一応 “正常”

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

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

  • ベンダーとの契約（SLA・運用委託契約）に、「障害時のフェイルオーバーを誰が実行するのか」 が明記されていない

  • DR への切替判断（どのタイミングで本番をあきらめるか）が、経営判断なのか、情シスなのか、ベンダー提案を待つのか不明確

  • 結果として、「ASR は入っているのに、誰もスイッチを押さない（押せない）」 状態になるリスク

② RTO/RPO と ASR の設定・契約が噛み合っていない

• 技術的にはOK

  • レプリケーションポリシーを「とりあえずベンダー推奨値」で設定

  • レポート上は RPO 数分〜数十分程度に見える

• BCP・契約的にはNGになりうる点

  • BCP計画書には「重要システムは 2時間以内に復旧（RTO 2h）」と書いてあるが、実際の ASR 構成・復旧手順・ベンダー対応時間では 物理的に不可能

  • 事業部門との SLA（取引先とのサービス提供義務等）と、Microsoft の SLA・ベンダーの運用SLA が整理されていない

  • 障害発生時に「RTO を守れなかった責任は誰にあるのか」でもめる土壌ができてしまう

③ ASR の「設計・運用・テスト」の分担がグレーなまま

• 技術的にはOK

  • ベンダーの設計書に “DR 手順書” が存在し、テストフェイルオーバーの手順も一応書いてある

• 実務・契約的にはNGになりうる点

  • テストフェイルオーバーを「誰が」「どの頻度で」実施するか が契約にない

  • DR 先で立ち上がったサーバ・アプリケーションの動作確認を、ベンダーがどこまでやるのか（OS まで／ミドルまで／アプリは顧客側 等）が曖昧

  • DR 後の業務確認・ユーザー側テストの責任が、事業部門と情シスとベンダーの間でグレーゾーンになっている

「ASR 自体は技術的に動いているが、障害時・災害時の役割分担が契約で固まっていない」——多くの企業で、このギャップが生じています。

3. Site Recovery ベンダー責任分界で、まず押さえるべき3つの整理軸

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

① フェーズ別「誰が・どこまで・いつまでに」責任分界表

ASR まわりは、フェーズごとに登場人物が変わります。最低限、次のフェーズごとに 責任分界表 を作ることをおすすめします。

• 設計フェーズ：

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

  • RTO/RPO の要件を誰が決めるか（事業部門／情シス／ベンダー提案）

• 導入フェーズ：

  • 実装・テスト・ドキュメント作成を誰が担当するか

• 平常時運用：

  • レプリケーションエラーの監視・一次対応

  • テストフェイルオーバーの計画と実施

• 障害・災害時：

  • DR への切替判断（誰が GO を出すか）

  • 実際のフェイルオーバー操作の実行者

  • 復旧後の動作確認・業務確認の担当

クラウド事業者（Microsoft）／構築ベンダー／運用ベンダー／自社（情シス・事業部門） を軸にしたマトリクスにすると、誰が何を見ていないのかが見えやすくなります。

② RTO/RPO・SLA・ASR設定値のひもづけ

• システムごとに

  • 事業側が求める RTO / RPO

  • 取引先や親会社との SLAを整理したうえで、

• ASR 設定側

  • レプリケーション頻度・アプリケーション整合性スナップショットの有無

  • DR 先での起動順序・依存関係

• 契約（ベンダー側）

  • 監視・一次対応にかかる時間

  • 夜間・休日の対応体制

  • RTO/RPO を “保証” しているのか、“ベストエフォート” なのか

これらを 1 枚の表／スライド にまとめておくことで、「ASR があるから大丈夫」ではなく、「この条件であれば、こういう前提でここまで復旧できる」 と説明できるようになります。

③ テストフェイルオーバー・訓練・証跡の整理

• テストフェイルオーバーを

  • 年何回やるのか

  • どのレベルまで（OS 起動まで／アプリ動作確認まで）やるのか

  • そのコストと工数は誰が負担するのか

• テスト結果を

  • どのフォーマットで記録し

  • BCP計画書・監査対応にどう反映させるか

• 訓練時に

  • 情シス・ベンダーだけでなく、事業部門・コールセンター・サプライチェーン などの関係者をどこまで巻き込むか

ここを 契約・運用設計書・BCP計画書のいずれかに明文化 しておくと、「ASR があるのに“ぶっつけ本番”でしか使ったことがない」という状態を避けやすくなります。

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

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

• 業種：製造業（BtoB）

• 売上規模：約900億円

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

• テーマ：Azure Site Recovery 導入済み環境におけるベンダー責任分界と BCP の整理

課題の整理

• 数年前にベンダー主導で ASR を導入し、DR 構成自体は動いているが、役割分担が曖昧

• BCP計画書には「基幹システムは 4時間以内に復旧」とあるが、現行の ASR 設定＋ベンダー体制で本当に達成可能か誰も検証していない

• 障害時のフェイルオーバー操作・DR 後のアプリ確認・業務確認について、ベンダー・情シス・事業部門がそれぞれ「相手がやるだろう」と思っている状態

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

• ASR 構成と BCP計画・契約書のクロスチェック

  • Recovery Services コンテナー／レプリケーション設定／テスト履歴を整理

  • BCP計画書・ベンダーとの運用委託契約・SLAを突き合わせ

• 責任分界マトリクスの作成

  • 設計・導入・平常時運用・障害時対応・訓練の5フェーズに分解し、Microsoft／ベンダー／自社（情シス・事業部門）の役割を定義

• RTO/RPO の現実的な見直し支援

  • ASR の設定とベンダー体制を前提に、現実的に達成可能な RTO/RPO を再計算

  • 必要であれば BCP計画書側の目標値・優先順位の見直しを提案

• 訓練・テストのルール化

  • 年1回以上のテストフェイルオーバー実施ルールを策定

  • 訓練結果を監査・親会社向けに説明できるフォーマットを整備

結果として

• 「ASR 構成」「ベンダー責任分界」「BCP計画」 の整合が取れ、監査・親会社・海外拠点からの質問に一貫して回答できるようになった

• 障害時に「誰もスイッチを押さない」状態から、誰が・どの条件でフェイルオーバーを実行するかが明確化 された

• ベンダー任せだった DR 構成から脱却し、「自社としてどこまでリスクを取るか」を前提にした設計・契約にアップデートできた……といった声をいただいています。

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

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

• □ ASR を使った DR 構成について、　 クラウド事業者・構築ベンダー・運用ベンダー・自社の責任分界図 が1枚で説明できる

• □ 各システムの RTO/RPO・ASRの設定値・BCP計画上の目標・取引先SLA が整合している

• □ 障害・災害時の　 フェイルオーバー／フェイルバックの実行者・判断者・手順 を文書化している

• □ テストフェイルオーバー・DR訓練を、　 誰が・どの頻度で・どこまでの範囲で実施するか が契約・ルールに落ちている

• □ 「ASR を入れたから大丈夫」ではなく、　 「自社としての Azure BCP 方針とリスクテイク」を説明できる 状態になっている

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

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

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

• Site Recovery を導入したものの、ベンダーとの責任分界があいまいで不安が残っている

• BCP計画・RTO/RPO と、ASR の実際の構成・ベンダー契約の内容が合っているか確認したい

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

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

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

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