【クラウド法務】Microsoftの責任分界モデルを“そのまま説明”してはいけない3つの理由Azure / M365導入で必ず問われる「責任分界」と「説明責任」― 参考図を“社内外の回答”に転用すると詰む（キーワード：Microsoft 責任分界モデル／Azure 責任分界／M365 責任分界／説明責任／監査ログ）

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

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

はじめに

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

クラウド導入の議論が進むと、誰かが必ず「Microsoftの責任分界モデル（Shared Responsibility Model）」を持ち出します。図として分かりやすく、説明資料にも載せやすいからです。

ただ、全国の情シス・IT部門の方から相談を受けていると、その“分かりやすさ”が逆に事故・監査・取引先対応で地雷になる場面を何度も見ます。

「それ、Microsoftの責任でしょ？」

「じゃあ自社は何をやらなくていいの？」

「委託先が運用しているなら、誰が説明するの？」

結論から言うと、Microsoftの責任分界モデルは“参考図”としては有用ですが、そのまま社内外への回答として使うと、説明責任が破綻しやすいです。

本記事では、なぜ「そのまま説明」してはいけないのか、そしてどう整理すれば“説明できる責任分界”になるのかを、実務の型でまとめます。

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

技術構成の“事実整理”：Microsoftの責任分界モデルが示すもの／示さないもの

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

まず、責任分界モデルが「何を言っているか」を技術的に整理します。

● Microsoftの責任分界モデルが言っていること（ざっくり）

クラウドの責任はゼロサムで移転するのではなく、**共有（Shared）**である。

大枠としては次の二つの考え方です。

（A）「クラウド基盤側のセキュリティ」＝ Microsoftが担う領域がある

（B）「クラウド上の設定・運用」＝ 利用者（顧客）が担う領域がある

そしてIaaS / PaaS / SaaS のどれを使うかで、Microsoftが担う範囲が増減します。

簡易イメージ（ざっくり）

・IaaS（VM中心）

　Microsoft：物理・ホスト・基盤

　顧客：OSパッチ、アカウント、ネットワーク設定、アプリ、データ、ログ、バックアップ設計

・PaaS（DB、App、Storage等）

　Microsoft：基盤＋OS/ミドル相当まで広がることが多い

　顧客：認証/権限、設定、データ、公開範囲、監査証跡、運用設計

・SaaS（M365等）

　Microsoft：提供基盤やサービス運用が中心

　顧客：ID、アクセス制御、データの取り扱い、端末、運用ルール、監査対応

ここまでは技術の話です。

ここからが法務・監査対応の話です。

● Microsoftの責任分界モデルが“示さない”こと

このモデルが、現場で一番必要になる次の情報を“直接は”示しません。

・あなたの契約で「誰が」「どこまで」「いつまでに」やる義務があるか

・あなたの委託先（SIer/MSP/SOC）が「何をやる義務を負うか」

・事故時に「ログを何営業日以内に提出できるか」

・BCPとして「何時間で復旧できるか（RTO/RPO）」

・例外運用（暫定開放・除外）をどう管理し、どう証跡化するか

つまり、モデルは“入口”にはなるが、社内外の説明のゴールにはならない、というのが落とし穴です。

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

2. Microsoftの責任分界モデルを“そのまま説明”してはいけない落とし穴3選

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

ここでは「技術的には正しい／でも説明としては破綻する」典型パターンを3つに絞ります。

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

落とし穴①：モデルは“参考図”であって、あなたの「契約（義務）」ではない

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

技術的にはOK

・「Microsoftがここまでやる／顧客がここをやる」という一般整理としては正しい

・社内の理解を揃える資料としては便利

法務・実務としてNGになりやすい

監査・取引先・親会社が聞いているのは、モデルではなく あなたの会社としての義務と実行能力 です。

よく聞かれる質問は、たとえばこうです。

・事故時の一次通知は誰が、何分以内に、どのチャネルで？

・ログ提出は誰が、何営業日以内に、どの形式で？

・復旧は何時間で？ その根拠（復旧テスト記録）は？

・委託先が関与するなら、再委託や国外関与の条件は？

・例外運用は台帳で管理している？ 期限は？ 承認は？

ここに対して「Microsoftの責任分界モデルでは…」と返しても、回答になりません。

むしろ相手からすると、「質問の主語がズレている」＝「説明できない会社」に見えます。

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

落とし穴②：サービス・構成・オプション・委託の組み合わせで“実態の責任分界”は変わる

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

技術的にはOK

・モデルは一般論として整っている

・IaaS/PaaS/SaaSの違いは説明できる

でも現場ではこうなります。

・同じAzureでも、VM中心か、PaaS中心かで顧客責任は大きく変わる

・同じM365でも、条件付きアクセス・PIM・監査ログ・DLP等の設計次第で統制の強さが変わる

・Marketplace製品やサードパーティを挟むと、契約の支配関係が増える

・運用委託（MSP/SOC）が入ると、「誰が動くか」がさらに変わる

つまり、モデルの“型”だけで説明すると、あなたの実態（構成＋運用＋委託）とズレます。

このズレが、事故時に「それは誰がやるはずだったのか」を曖昧にします。

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

落とし穴③：最終的な“説明責任”は、モデル上Microsoftが担う領域があっても、自社に残りやすい

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

これは一番誤解されやすい点です。

技術的にMicrosoft領域がある

・基盤障害、サービス提供側の問題など、Microsoftが原因に関与する可能性はある

しかし対外説明の主語は誰か？

多くのケースで、取引先と契約しているのはあなたの会社です。

つまり「顧客への説明」「監査への説明」「親会社への説明」の主語は、原則として自社に残ります。

そして説明に必要なのは「原因の完全確定」より先に、次の“材料”です。

・影響範囲を示す証跡（ログ）

・いつ誰が何をしたか（変更記録、操作記録）

・封じ込めや復旧の手順と実施記録（BCP）

・再発防止策（承認・期限・例外管理の仕組み）

モデルをそのまま貼るだけでは、この材料が揃いません。

結果として「Microsoftの責任分界モデルでは…」と言っても、説明責任が成立しないのです。

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

3. クラウド法務としての「整理のフレーム」：モデルを“そのまま”ではなく“翻訳して使う”

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

ここからが実務の解決策です。

Microsoftの責任分界モデルは捨てる必要はありません。使い方を変えるのがポイントです。

おすすめは次の3ステップです。

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

整理軸①：責任分界は“レイヤー”ではなく“タスク”でRACI化する

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

レイヤー（NW層、OS層）で整理すると、事故対応や提出能力の話が抜けます。

よって“やること（タスク）”で切り、RACI（R=実行、A=最終責任、C=相談、I=共有）に落とします。

最低限入れるべきタスク例（事故対応まで含める）

・一次通知（検知→社内連絡）

・封じ込め（権限停止、通信遮断、Purge等）

・ログ提出（監査・取引先照会：何営業日以内）

・ログ保全（削除停止・隔離・抽出者記録）

・変更管理（承認、緊急変更の事後追認）

・特権アクセス（PIM、Break-glass、棚卸し、剥奪証明）

・BCP（RTO/RPO、復旧手順、復旧テストと記録）

・委託管理（再委託、国外SOC、同等義務の貫通）

このRACIが1枚あるだけで、監査・取引先の“体制質問”に回答が安定します。

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

整理軸②：「契約条項」→「運用タスク」へ翻訳し、SOW（別紙）で義務を固定する

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

契約レビューが終わっていても、運用説明ができない原因の多くはここです。

条項が抽象のまま運用に落ちていない。

例：条項→運用への翻訳（イメージ）

・条項：事故時に通知

　→ 運用：通知の条件、期限（何分以内）、チャネル、承認者、テンプレ

・条項：ログ提出

　→ 運用：対象ログ、保持期間、抽出手順、提出期限（何営業日以内）、形式

・条項：協力

　→ 運用：保全協力（削除停止、隔離）、原因分析情報の提供期限

・条項：再委託

　→ 運用：再委託先の範囲特定、国外関与の有無、同等義務の貫通

委託（MSP/SOC/SIEM運用）が入るなら、これをSOW（作業範囲・品質の定義）に落とします。

「できる」ではなく「義務としてやる」が重要です。

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

整理軸③：「証跡パック」を作り、“提出できる状態”にする

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

説明責任は最後、証跡で決まります。

だから先に「これを出す」を定義します。

証跡パック（最小セット例）

・責任分界（タスク別RACI）

・ログ一覧（何を／どこに／どれだけ保持）

・ログ提出手順（期限、形式、担当、承認者）

・事故時保全手順（削除停止、隔離、抽出者記録）

・特権アクセス台帳（付与理由、期限、承認、剥奪証跡）

・例外台帳（理由、承認、期限、補償統制、解除計画と解除証跡）

・BCP：RTO/RPO、復旧手順、復旧テスト記録

“ログは取れます”ではなく、

“何営業日以内に、どの形式で提出できます”

まで言える状態がゴールです。

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

4. ケーススタディ（匿名化）：責任分界モデルを貼っただけで監査に刺さったA社

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

（実務で起きがちな構図を匿名化して紹介します）

背景

・Azure＋M365運用（IaaS/PaaS混在）

・運用はMSP、監視はSOCへ委託

・社内説明資料にMicrosoftの責任分界モデルを掲載し、「大枠はこれ」として運用開始

監査・取引先で詰まった質問

・ログ提出は誰が、何営業日以内に？（SOCが持つのか、自社が出すのか）

・例外運用（NSG暫定開放、条件付きアクセス除外）の承認者と期限は？

・事故時の一次通知は誰が、何分以内に、どのチャネルで？

・復旧は何時間？ テスト記録は？

起きていた問題

・モデルはあるが、タスク別の責任分界（RACI）がない

・SOWに提出義務・保全協力・一次通知が落ちていない

・例外台帳がなく、決裁者と期限が残らない

・証跡パックが定義されておらず、提出能力が見えない

立て直し

・タスク別RACIを作成（事故対応まで）

・SOWに「一次通知／ログ提出義務（期限・形式）／保全協力／特権統制」を追記

・例外台帳を作り、期限と解除計画で恒久化を止めた

・証跡パックを定義し、提出期限に耐える運用へ移行

結果として

・「モデルの説明」ではなく「自社の説明」ができるようになり、監査・取引先照会で回答が安定した

という流れです。

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

5. 自社で検討するときのチェックリスト

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

□ Microsoftの責任分界モデルを「参考図」と「自社の回答」に分けている

□ IaaS/PaaS/SaaS混在の実態に合わせて、自社責任を言語化できる

□ Microsoft／自社／委託先の責任分界が“タスク別RACI”で1枚になっている

□ 事故対応（一次通知・封じ込め・保全・報告）の主語が割れない

□ ログは「保持期間／提出期限／提出形式／担当／承認者」まで決まっている

□ 事故時のログ保全（削除停止・隔離・抽出者記録）の手順がある

□ 委託先が関与する場合、SOWに「通知・提出・保全協力」が義務として入っている

□ 特権アクセス（PIM/Break-glass等）の台帳があり、期限と剥奪証跡が残る

□ 例外運用（NSG暫定開放、CA除外等）が台帳化され、期限で棚卸しできる

□ BCPとしてRTO/RPOが定義され、復旧テスト記録が残っている

「すべてYES」と言える企業は、まだ多くありません。

逆に言えば、ここを整えるだけで“説明できる会社”に一気に近づきます。

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

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

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

山崎行政書士事務所では、Azure / M365等の技術構成と、契約・規程・監査対応をセットで整理し、Microsoftの責任分界モデルを「自社の説明」に翻訳するクラウド法務支援を行っています。

・Microsoft／委託先／自社の責任分界を、事故対応まで含めてRACIで1枚にしたい

・SOW（別紙）に一次通知、ログ提出、保全協力、特権アクセス統制を落としたい

・監査・取引先に提出できる“証跡パック”を定義したい

・例外運用（暫定開放・除外）の恒久化を台帳と規程で止めたい

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

お問い合わせの際に「責任分界モデルの記事を見た」と書いていただけるとスムーズです。