【クラウド法務】Azure VMware Solution（AVS）は“オンプレ延長”ではない― Lift & Shiftのつもりで進めると、事故・監査・取引先説明で詰まる理由と、責任分界・契約整理の型

────────────────────────────

はじめに

────────────────────────────

Azure VMware Solution（以下AVS）は、VMwareの既存資産を大きく作り替えずにAzureへ持っていけるため、情シスにとって非常に魅力的です。「オンプレのvSphere環境をそのままAzureに伸ばす」「データセンター更改の期限に間に合わせる」「クラウドネイティブ化は後で考える」──そういう“現実的な移行”の選択肢として、AVSは確かに強いです。

ただ、全国の情シス・IT部門の方から相談を受けていると、AVS導入が進んだ後に、次のような“説明の壁”で止まるケースが増えます。

・「VMwareだからオンプレと同じ運用でいけると思ったが、障害時に誰が何をするか説明できない」・「委託先（MSP）が入っているが、vCenter/NSXの“特権操作”が契約に落ちていない」・「バックアップは取っているつもりでも、取引先にRTO/RPOを根拠付きで言えない」・「監査で“権限・変更管理・証跡”を求められ、オンプレ時代の規程がそのまま使えない」

本記事では、AVSは“オンプレ延長”ではないという前提から、「共感 → 技術的な整理 → 法務の地雷 → 対策フレーム → 具体例 → 自社に合うか相談」の順で、実務で崩れない整理方法をまとめます。（※本記事は一般的な情報提供であり、個別案件の法的助言ではありません）

────────────────────────────

1. AVSの技術構成の“事実整理”

   ────────────────────────────

まず、AVSで何が起きるかを、技術として整理します。AVSは一言でいうと、「Azure上に、VMware SDDC（vSphere/vSAN/NSX等）を“マネージドな形”で構築し、顧客がvCenter等を使ってVM運用できる」サービスです。

多くの企業での典型構成（テキスト図）

【オンプレ】・既存vSphere（vCenter、ESXi、vSAN/ストレージ、ネットワーク）・運用手順、バックアップ、監視（既存ツール）　↓（移行、接続）【Azure上のAVS】・VMwareクラスタ（ホスト追加でスケール）・vCenter（AVS環境の管理）・NSX（ネットワークセグメント、FW等）・ストレージ（vSAN等）　↓【接続】・オンプレ↔Azure接続（帯域、冗長、ルーティング設計）　↓【運用】・ID/アクセス（誰がvCenter/NSXを操作できるか）・監視/ログ（Azure側、SIEM、委託SOCなど）・バックアップ/DR（復旧計画・テスト）・運用委託（MSPが入るケースが多い）

ここで重要な“切り替え宣言”をします。

ここまでは技術の話。ここからが法務。

AVSが“オンプレ延長”に見えるのは、管理画面がVMware（vCenter）で、VMの見え方がオンプレと似ているからです。しかし実態は、次の意味でオンプレと違います。

・基盤（ホストやマネージド領域）は、顧客が自由に触れない（＝責任の持ち方が変わる）・運用は「VMwareの運用」だけで完結せず、「Azureの契約・支払い・権限・監査」の枠組みを連れてくる・事故時は「オンプレのベンダー保守」ではなく、「Microsoft／自社／委託先」の三者分界で動く

この違いを整理しないまま進めると、“動くのに説明できない”状態になります。

────────────────────────────

2. AVS導入でトラブルになりやすい「法務・責任」の地雷3選────────────────────────────

技術的には移行が進んでも、事故・監査・取引先説明で詰まりやすいポイントを3つに絞ります。いずれも「技術的にはOK／法務的にはNG」になりやすいギャップです。

────────────────────────────

地雷①：責任分界の主語がズレる（Microsoftが何でも守るわけではない）────────────────────────────

AVS導入直後に社内で起きやすい誤解は、次の2つです。

・誤解A：「Azureに乗せた＝Microsoftが全部面倒を見る」・誤解B：「VMwareだからオンプレと同じ責任分界のまま」

実務上は、どちらも危険です。AVSでは“マネージドな部分”が増える一方で、顧客側に残る責任は消えません。代表例は次です。

・ゲストOS、ミドルウェア、アプリの脆弱性対応・VM内のデータ、認証情報、鍵、バックアップ方針・vCenter/NSXの操作権限の統制（誰が何をできるか）・オンプレとの接続設計（帯域・冗長・経路・障害時の迂回）・監査で求められる証跡（変更管理、操作ログ、復旧テスト記録）

事故が起きたときに問われるのは「どこが原因か」だけではなく、「誰が、何を、事前に決め、何を根拠に説明できるか」です。ここを曖昧にすると、復旧より先に“責任者探し”が始まり、対応が遅れます。

────────────────────────────

地雷②：vCenter/NSXの“特権運用”が増えるのに、規程と委託契約が追いつかない────────────────────────────

AVSは“VMwareっぽい”ので、オンプレ時代の運用の癖がそのまま持ち込まれがちです。しかし、AVSでは「Azure上の統制」「委託先運用」「多拠点」「クラウド横断」などが絡み、特権運用が複雑化します。

よく揉めるポイントはここです。

・誰がvCenter/NSXの管理者権限を持つのか（自社？委託先？）・常設権限なのか、期限付きなのか・変更はチケットと承認で回っているか（変更管理）・緊急対応（夜間休日）の権限付与はどうするか（Break-glass的運用）・担当者交代・契約終了時に剥奪が保証されるか・“いつ誰が何をしたか”の操作証跡を提出できるか

AVSは、オンプレより「見える化」「集中管理」が進む反面、統制が弱いと「強権限がクラウド側に集中する」形になり、監査で刺さりやすいです。

────────────────────────────

地雷③：バックアップ／DRは“オンプレの延長”で設計すると、RTO/RPOの説明が破綻する────────────────────────────

AVS導入時に最も誤解されやすいのが、バックアップとDRです。

・「今のバックアップ製品があるから大丈夫」・「VMwareのスナップショットがあるから大丈夫」・「AzureにあるからBCPも強いはず」

この“はず”が、取引先SLA・BCP・監査の場面で崩れます。問われるのは次です。

・RTO（何時間で復旧できるか）・RPO（どこまで戻せるか）・復旧の順序と依存関係（AD/ID、DNS、ネットワーク、アプリ、DB）・復旧が本当にできる根拠（復旧テスト記録）・災害時のリージョン障害をどう考えるか（同一リージョン内冗長だけで足りるのか、別リージョンをどうするのか）

AVSは“VMware基盤の提供”であって、あなたの業務サービスの復旧を保証するものではありません。ここを契約・規程で整理しないと、「バックアップはあるのに説明できない」になります。

────────────────────────────

3. AVS導入で崩れないための「整理のフレーム」────────────────────────────

ここからは「どう考えればいいか」の軸です。AVSの設計を詰める前に、最低限この3つを紙に落とすと、ベンダー調整・社内説明・監査対応が一気に楽になります。

────────────────────────────

整理軸①：タスク別の責任分界（RACI）を“事故対応まで”作る────────────────────────────

AVSの責任分界は「レイヤー」より「やること」で切るのが実務的です。Microsoft／自社／委託先（MSP）で、次のタスクを並べ、R（実行）／A（最終責任）／C（相談）／I（共有）を決めます。

最低限入れたいタスク例

1）AVS環境の運用（基盤側に寄る領域）・ホストの増減、メンテナンス、基盤更新への対応・メンテ情報の受領、影響評価、社内周知

2）vCenter/NSXの設定変更（統制が必要な領域）・ネットワークセグメント、FWルール、ルーティング・管理者アカウント、権限付与・剥奪・拡張的な運用（自動化、スクリプト等があるなら）

3）VM（ゲスト）側の運用（顧客責任が濃い領域）・OS/ミドルウェア/アプリのパッチ・EDR、アカウント、秘密情報（鍵・証明書）・構成管理と変更管理

4）監視・ログ（証跡）・何を収集し、どこに保管し、どれだけ保持するか・操作ログ（管理操作）とシステムログ（監視）の分担・提出期限（監査・取引先照会）と提出形式

5）バックアップ／DR・RTO/RPOの定義・復旧手順、復旧テスト、証跡・災害時の判断（いつBCP発動するか）

6）インシデント対応・一次通知（誰がどのチャネルで何分以内に）・封じ込め（権限停止、ネットワーク遮断等）・証拠保全（ログ凍結、抽出者記録）・社外説明（誰が文章を出し、誰が承認するか）

ポイント：委託先がR（実行）でも、A（最終責任）や対外説明の主体は自社に残る場面が多いです。だからこそ、委託契約で“協力義務”と“提出能力”を固めます。

────────────────────────────

整理軸②：SLA/BCPの「言葉」を先に揃える（AVSのSLAと自社の約束は別物）────────────────────────────

AVS導入で社内が混乱する典型はこれです。

「Azure（AVS）のSLAがあるから大丈夫」→ 取引先に「何時間で復旧？」と聞かれて詰まる

SLA/BCPは、次の3段階を分けて整理すると崩れません。

（A）Microsoft（AVS）の提供条件としての可用性・サポート範囲（B）自社のシステム要件（冗長化、接続、運用体制、復旧手順）（C）取引先・社内に対する自社の約束（サービスレベル、復旧時間、報告）

法務としては、「（C）の約束」を（A）に丸投げしないことが重要です。（C）を約束するなら、（B）を“設計と運用で実現できる状態”にして、証跡（テスト記録）を持つ必要があります。

最低限、規程や社内資料に落とすべき項目・重要システムごとのRTO/RPO・復旧優先順位・復旧テストの頻度と証跡保管・オンプレ接続断やリージョン障害時の判断基準（BCP発動条件）

────────────────────────────

整理軸③：委託契約（SOW）に「特権アクセス・変更管理・ログ提出」を入れる────────────────────────────

AVSは運用委託（MSP）とセットになりやすい領域です。ここで揉めるのは、契約本文より“別紙SOW”に落ちる部分です。最低限、次を明文化しておくと事故後に崩れません。

（1）作業範囲（やる／やらない）・vCenter/NSXの設定変更は含むか・ネットワーク変更（FW/ルート）は含むか・ゲストOSパッチは含むか・バックアップ・復旧テスト支援は含むか・障害時の復旧作業はどこまで含むか（一次対応だけか、復旧支援までか）

（2）特権アクセス統制・個人アカウント原則（共有アカウント禁止）・期限付き権限、承認付き・操作ログ提出（いつ誰が何をしたか）・担当者交代・契約終了時の剥奪証明・緊急時の例外（事後追認の期限と記録）

（3）変更管理（Change Management）・チケット番号と承認ルート・緊急変更の扱い（事後追認、ロールバック、報告）・影響評価の最低要件（停止、性能影響、接続影響）

（4）ログ提出義務・保全協力・提出期限、提出形式、対象範囲・事故時の保全（削除停止・隔離・抽出者記録）協力・再委託（国外含む）がある場合の条件と同等義務の貫通

（5）契約終了（出口）・設定情報、手順書、作業記録、ログの引渡し・アクセス剥奪と証明・引継ぎ期間と費用

AVSは「オンプレの運用委託」よりも、**クラウド側の統制（証跡・提出・権限）**が問われやすいので、ここを最初から固めると後戻りが減ります。

────────────────────────────

4. ケーススタディ（匿名化）：データセンター更改期限でAVSを採用した製造業A社────────────────────────────

実際に近い形で起きがちな例です（業種等は匿名化しています）。

背景・業種：製造業・課題：DC更改期限が近く、オンプレ刷新よりも早く移行したい・方針：既存VMware資産を大きく作り替えずAVSへ移行（Lift & Shift中心）・体制：日々の運用はMSPに委託

導入後に詰まったこと・障害時の連絡と復旧判断が割れた（自社・MSP・Microsoftの役割が曖昧）・vCenter/NSXの変更が“運用の空気”で進み、変更承認と証跡が揃わない・バックアップは動いているが、復旧テストがなく、取引先にRTO/RPOを根拠付きで言えない・監査で「誰がいつ何を変更したか」「特権運用はどう統制しているか」を問われ、オンプレ時代の規程がそのまま通らない

整理したこと（実務）・タスク別RACIを作り、事故対応の指揮命令系統を固定・MSP契約別紙に「特権アクセス統制」「変更管理」「ログ提出・保全協力」を明記・復旧手順と復旧テストを定義し、証跡として残す運用に切替・監査向け“証跡パック”（操作ログ、変更記録、復旧テスト記録、権限棚卸し）を整備

結果・監査・親会社・取引先からの質問に、技術ではなく「責任分界と証跡」で一貫回答できるようになり、・AVSが“オンプレ延長”ではなく“クラウド運用として統制できる基盤”に近づいた

────────────────────────────

5. AVS導入前に、今すぐ確認しておきたいチェックリスト────────────────────────────

□ 「AVS＝オンプレ延長」ではなく、責任共有の前提で説明資料が作れている

□ Microsoft／自社／委託先の責任分界（タスク別RACI）が1枚で説明できる

□ vCenter/NSXの特権運用（個人アカウント、期限、承認、操作ログ）が統制されている□ 変更管理が回っている（チケット、承認、緊急変更の追認、ロールバック）

□ 監査で出す“証跡パック”（権限、変更、操作ログ、復旧テスト）が定義されている

□ ログの保持期間・提出期限・提出形式が決まっている（委託先にも義務化）

□ RTO/RPOがシステムごとに決まっており、復旧手順と復旧テストの証跡がある

□ オンプレ接続断や大規模障害時の判断（BCP発動条件、周知、報告）が決まっている

□ 委託契約（SOW）に、通知・提出・保全協力・特権アクセス統制が入っている

□ 契約終了時（出口）：設定・手順書・作業記録の引渡し、アクセス剥奪証明、引継ぎが決まっている

「全部YES」と言える企業は、正直まだ多くありません。

────────────────────────────

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

────────────────────────────

山崎行政書士事務所では、Azure VMware Solution（AVS）の技術構成と、契約・規程・監査対応をセットで整理する「クラウド法務支援」を行っています。

・AVS導入で、Microsoft／自社／委託先の責任分界を“事故対応まで”1枚にしたい・委託契約別紙（SOW）に、特権アクセス統制・変更管理・ログ提出義務を入れたい・取引先SLA/BCPに耐えるRTO/RPOと復旧テストの証跡を整えたい・監査で刺さる“権限・変更・証跡”を、VMware運用の言葉で整理したい

といったお悩みがあれば、オンライン（全国対応）にて初回のご相談を承っております。お問い合わせの際に「AVSの記事を見た」と書いていただけるとスムーズです。

────────────────────────────

※本記事は一般的な情報提供です。実際の責任分界・契約論点は、導入範囲（ネットワーク、監視、バックアップ、運用委託）、取引先要件、既存運用の成熟度により変わります。────────────────────────────