【クラウド法務】Azure VMware Solution（AVS）導入で起きやすい「法務・運用のズレ」― VMwareのまま移した“つもり”でも、事故・監査・取引先説明で詰まるポイントを先に潰す ―（キーワード：Azure VMware Solution／AVS／VMware移行／責任分界／運用委託／SLA／BCP）

※本記事は一般的な情報提供です。個別案件の法的助言ではありません。

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

はじめに

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

Azure VMware Solution（AVS）は、既存のVMware資産を大きく作り替えずにAzureへ移せるため、「DC更改期限が迫っている」「まずはLift & Shiftで間に合わせたい」という現実解として選ばれやすいサービスです。そして導入プロジェクトの前半は、だいたい順調に進みます。VMが動く。vCenterも見える。ネットワークも繋がる。関係者が“オンプレと同じ感覚”を持てる。

しかし、全国の情シス・IT部門の方から相談を受けていると、AVS導入後に次のタイミングで急に「説明ができない」状態に陥るケースが増えます。

・障害が起きた／不正アクセス疑いが出た・委託先（MSP）が運用に入り、変更が増えた・監査・親会社・取引先から「責任分界」「証跡」「復旧要件」を問われた・BCPや取引先SLAの見直しで、“根拠”が必要になった

このとき問題になるのは技術そのものより、法務（契約）と運用（実態）のズレです。本記事では「AVS導入で起きやすいズレ」を、技術の整理→ズレのパターン→対策フレーム→事例→チェックリスト、の順でまとめます。

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

1. 技術構成の“事実整理”：AVSはどこまで“VMware”で、どこから“クラウド”か────────────────────────────

まず前提として、AVSは「VMware環境がAzure上にある」ので、見た目はオンプレに近いです。ただし、“責任の持ち方”はオンプレと同じにはなりません。

よくある導入構成（テキスト図）

【オンプレ】・既存VMware（VM、運用手順、監視、バックアップ）　↓（移行／接続）【Azure上】・AVS（VMware SDDC：vSphere／vSAN／NSX など）・vCenter（AVS側の管理）・NSX（ネットワーク／セグメント／FWルールなど）・Azure側の契約・課金・権限（Azure RBAC）　↓【接続・運用】・オンプレ接続（経路、冗長、帯域）・委託運用（MSP）・ログ集約／SIEM／監査対応・バックアップ／DR設計・テスト

ここが重要な切り替えポイントです。

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

AVSは「VMwareの運用っぽく扱える」反面、実態としては“クラウドの契約と統制”を強制的に連れてくるVMware基盤です。

このため、オンプレと同じ感覚で「保守契約」「運用委託」「BCP」「監査」を組むと、ズレが発生しやすくなります。

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

2. AVS導入で起きやすい「法務・運用のズレ」7パターン────────────────────────────

ここでは“導入後に揉める典型”を、ズレとして整理します。どれも「技術的には動いているのに、説明できない」原因になります。

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

ズレ①：SLAの数字と、自社が約束すべき復旧（RTO/RPO）が同一視される────────────────────────────

よくある状況・「AzureのSLAがあるから大丈夫」・「AVSはマネージドだから復旧もMicrosoft側で…」という期待が混ざる

しかし、取引先や親会社が聞きたいのはSLAの数字ではなく、「あなたのサービスは何時間で戻るのか（RTO）」「どこまでデータが戻るのか（RPO）」「復旧の根拠（手順とテスト）はあるか」です。

ズレが起きるとどうなるか・SLAを説明しているのに、RTO/RPOを答えられない・復旧が“できるはず”で進めたが、依存関係（AD/DNS/接続/鍵/監視）で詰まる・結局「バックアップはあるが、復旧の説明ができない」状態になる

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

ズレ②：「Microsoftが面倒を見る範囲」と「自社が守る範囲」が混ざる────────────────────────────

AVSはマネージド要素があるため、社内で責任の主語が混ざりやすいです。特に混ざるのがこの領域です。

・ゲストOS／ミドルウェア／アプリの脆弱性対応・VM内部のアカウント、秘密情報、鍵、証明書・ネットワーク設計（経路、冗長、FWルール）・バックアップ方針と復旧手順・監査で必要な証跡（変更管理、操作ログ、復旧テスト記録）

ズレが起きるとどうなるか・事故時に「それはMicrosoft？MSP？自社？」で初動が遅れる・「設定はお客様側です」と言われて、社内説明が割れる・責任者探しが先に始まり、復旧・封じ込めが後回しになる

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

ズレ③：vCenter／NSXの“特権操作”が、委託契約の範囲外・証跡なしで回り始める────────────────────────────

AVSでは、vCenter／NSXの操作が強い影響力を持ちます。にもかかわらず、運用委託（MSP）が入ると次が起きがちです。

・「監視だけ委託」のつもりが、実際は設定変更もやっている・緊急対応を理由に、管理者権限が常設化する・共有アカウントが残る／個人特定できない・作業はチケットに紐付かず、後から追えない・委託先の担当交代・契約終了で剥奪漏れが起きる

ズレが起きるとどうなるか・監査で「誰がいつ何を変えたか」を出せない・事故時に「直前に何を変えたか」が分からず復旧が遅い・“統制が弱いクラウド運用”として評価が落ちる

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

ズレ④：変更管理（Change Management）の粒度がオンプレ時代のままで、AVSでは足りなくなる────────────────────────────

オンプレのVMware運用でも変更管理はありますが、AVSでは“影響範囲”が広がりがちです。典型はこれです。

・ネットワーク変更（NSXルール、経路、セグメント）・ホスト増減やメンテ情報に伴う影響・接続（オンプレ↔Azure）周りの変更・監視設定やログ転送の変更（証跡の取り方が変わる）

ズレが起きるとどうなるか・「いつもの変更」扱いで進み、影響評価・ロールバックが不足・後から「誰の承認でやった？」が説明できない・緊急変更が“緊急のまま恒久化”して残る

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

ズレ⑤：ログは“取っているつもり”なのに、監査・取引先に“提出できない”────────────────────────────

AVS導入後、ログは増えます。しかし説明責任で問われるのは「ログがあるか」ではなく、

・どのログを・どの期間保持し・誰が（どの権限で）抽出し・何営業日以内に提出できるか・事故時に保全（削除停止・隔離）ができるかです。

ズレが起きるとどうなるか・監査で「必要期間のログがない」・委託先がログ基盤を持っていて「すぐ出ない／別料金」・“証跡が出せない＝統制が弱い”と判断される

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

ズレ⑥：バックアップは“従来製品の延長”で設計し、クラウド側の出口・責任が空白になる────────────────────────────

AVSはVMwareなので、バックアップも「従来の延長」で考えがちです。ただ、クラウドに載ると次の論点が追加されます。

・バックアップデータの所在（どこにあるか）・保持期間（監査・契約要件と整合しているか）・削除権限（誰が消せるか。侵害者が消せないか）・事故時の保全（凍結、隔離、抽出者記録）・契約終了時の出口（データ／設定／証跡をどう引き継ぐか）

ズレが起きるとどうなるか・「取っていたのに、戻せない／間に合わない／証跡がない」・削除や設定変更が統制されず、最後の砦が弱い・出口設計がなく、移行・解約時に大きな摩擦が出る

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

ズレ⑦：オンプレ↔Azure接続（ネットワーク）の“責任分界”が契約と運用で割れる────────────────────────────

AVSは単体で完結しないことが多く、接続（帯域、冗長、経路、迂回）で可用性が決まります。ここが曖昧だと、障害時に次が割れます。

・回線障害は誰が一次切り分けするのか・迂回経路の切替は誰が判断・実行するのか・“AVSは動いているが接続が落ちた”とき、誰が取引先に何を説明するのか・接続設計がSLA/RTOの前提条件になっていることが共有されていない

ズレが起きるとどうなるか・障害時に「うちはAVS側は問題ない」「回線側だ」で止まる・取引先に復旧見込みを説明できない・結局、可用性を決めるのはサービスではなく“接続と運用”だったと後から気づく

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

3. ズレを潰すための整理フレーム（導入前に作るべき3枚）────────────────────────────

AVS導入で揉める企業は、例外なく「責任の設計図」がありません。逆に、ここを3枚作っておくと、導入後の説明と事故対応が崩れにくくなります。

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

整理①：タスク別RACI（Microsoft／自社／委託先）を“事故対応まで”固定────────────────────────────

レイヤー議論（OS層・NW層）ではなく、「やること」で切ります。

最低限入れるタスク例・vCenter/NSXの権限付与・剥奪・ネットワーク変更（FW/経路/セグメント）・ゲストOS/ミドルウェア/アプリのパッチ・監視・ログ収集（範囲、保持、提出）・バックアップ/復旧（手順、テスト）・インシデント対応（一次通知、封じ込め、保全、報告書）・接続障害時の切替判断と実行

ポイント委託先がR（実行）でも、A（最終責任）や対外説明の主語は自社に残る項目が多い。だからこそ「委託先に何を義務として求めるか」を次の整理②③で固めます。

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

整理②：証跡パック（監査・取引先に“これを出す”）を定義────────────────────────────

証跡パックの最低ライン例・管理者（特権）一覧：誰が、いつから、なぜ持つか（期限付きか）・変更管理記録：チケット番号、承認者、実施者、実施日時、ロールバック・重要操作ログ：権限変更、ネットワーク変更、主要設定変更・バックアップ設定と実行結果：保持期間、成功/失敗、復旧テスト記録・インシデント時保全手順：凍結対象、抽出者記録、保全解除条件

“ログがある”ではなく、“提出できる”状態を作るのがゴールです。

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

整理③：委託契約（SOW/別紙）に「特権アクセス・変更管理・提出義務」を明記────────────────────────────

AVSで揉めるのは、契約本文より別紙SOWです。最低限ここを入れるとズレが減ります。

・作業範囲（やる／やらない）：vCenter/NSX変更、復旧作業、バックアップ支援 など・特権アクセス統制：個人アカウント、期限付き、承認、共有禁止、操作ログ提出・変更管理：チケット、承認、緊急変更の事後追認期限、ロールバック、報告・ログ提出義務：提出期限・形式・対象範囲（有償/無償の線引きを先に）・保全協力：事故時の削除停止・隔離・抽出者記録・再委託がある場合：条件、範囲特定、同等義務の貫通・契約終了（出口）：引継ぎ、アクセス剥奪証明、設定・記録・ログの引渡し

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

4. ケーススタディ（匿名化）：AVSで“動くが説明できない”状態になった製造業A社────────────────────────────

背景・業種：製造業（複数拠点）・課題：DC更改期限が近く、AVSで移行を急いだ・体制：運用はMSPを活用、社内は少人数

起きたズレ・障害時の切り分けで「回線？NSX？ゲストOS？」が割れ、初動が遅れた・vCenter/NSXの設定変更がMSP側で進むが、チケットと承認が揃っていない・監査で「特権運用」「変更管理」「証跡提出」を求められ、オンプレ規程がそのままでは足りない・バックアップはあるが、復旧テストの記録がなくRTO/RPOを根拠付きで言えない

整理して改善したこと・タスク別RACIで事故対応の指揮命令系統を固定・MSP契約別紙に、特権アクセス統制・変更管理・提出義務・保全協力を追記・証跡パックを定義し、月次で「提出できる状態」を棚卸し・復旧テストを計画化し、成功/失敗の記録を監査証跡として残す運用に変更

結果・「VMwareだから大丈夫」という空気から脱却し、・AVSを“クラウド運用として説明できる状態”に近づけることができた

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

5. チェックリスト：AVS導入前・導入直後に確認しておきたいこと────────────────────────────

□ AVSを“オンプレ延長”ではなく、責任共有として社内説明できる

□ Microsoft／自社／委託先のタスク別RACIが1枚である（事故対応まで含む）

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

□ 証跡パック（権限・変更・操作ログ・復旧テスト）が定義されている

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

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

□ 接続（オンプレ↔Azure）の障害時切替判断と実行者が決まっている

□ 委託契約（SOW）に、事故対応・提出義務・保全協力が入っている

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

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

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

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

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

・AVS導入で、Microsoft／自社／委託先の責任分界を“事故対応まで”1枚にしたい

・MSP契約別紙（SOW）に、特権アクセス統制・変更管理・ログ提出義務を入れたい

・取引先SLA/BCPに耐えるRTO/RPOと復旧テストの証跡を整えたい

・監査で刺さる“権限・変更・証跡”を、VMware運用の言葉で整理したい

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

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

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