【クラウド法務】責任分界は“レイヤー”で考えると失敗する理由― 「ネットワーク層はベンダー」「OS層はMicrosoft」…で整理した瞬間、事故・監査・取引先説明が崩れる ―

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

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

はじめに

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

クラウド導入で必ず出てくる言葉が「責任分界」です。

そして多くの現場では、責任分界を“レイヤー”で整理し始めます。

・物理層：クラウド事業者

・ネットワーク層：クラウド＋ベンダー？

・OS層：IaaSは自社、PaaSはクラウド？

・アプリ層：自社（or 開発ベンダー）

・データ層：自社

この整理、最初は「それっぽく」見えます。

資料としても綺麗にまとまります。上司にも説明しやすい。

ところが、全国の情シス・IT部門の方から相談を受けていると、**責任分界をレイヤーで固めた企業ほど、事故・監査・取引先照会の場面で“説明が割れて詰まる”**ケースが目立ちます。

なぜか。

結論から言うと、クラウドの現場で問われる責任は「層」ではなく、**“やること（タスク）”と“出せる証跡（成果物）”**だからです。

本記事では、責任分界をレイヤーで考えると失敗する理由と、崩れない整理のフレームを解説します。

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

技術構成の“事実整理”：クラウドの責任は「層」ではなく「行為」で発生する

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

まず前提として、クラウドの運用は「層を守る」仕事ではありません。

実際に現場で発生するのは、次のような“行為”です。

・アカウントに特権権限を付与する／剥奪する

・NSGやWAFのルールを変更する

・条件付きアクセスの例外を追加する

・Key VaultのSecrets/Keys/Certificatesを更新する

・ログの保持期間を決める／抽出して提出する

・バックアップから復旧する／復旧テストを残す

・インシデントを検知し、封じ込め、保全し、一次報告を出す

・委託先の再委託（下請け・海外SOC等）を管理する

（ここまでは技術の話。ここからが法務・説明の話です。）

監査や取引先が聞いてくるのは、レイヤーではなくこの手の質問です。

「誰が承認したのですか？」

「いつまでにログを提出できますか？」

「事故時の一次通知は誰が、何分以内に？」

「例外は期限管理されていますか？」

つまり、“責任分界”の正体は、**タスクに対する責任（誰が決め、誰が動き、誰が説明するか）**です。

レイヤー図だけでは、ここに答えられません。

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

2. 責任分界を“レイヤー”で考えると失敗する5つの理由

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

ここから本題です。

「レイヤーで責任分界」をやると、なぜ失敗するのか。典型を5つに絞って整理します。

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

理由①：レイヤーは“サービス種別”で変わり、混在すると境界が破綻する

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

クラウドはIaaS / PaaS / SaaSが混在します。

同じ「OS層」でも、IaaSは自社が触るが、PaaSは触らない。

同じ「ネットワーク層」でも、CDN・WAF・Private Endpoint・ExpressRouteが絡むと、層の定義が崩れます。

レイヤー整理の典型的な崩れ方

・「OSはPaaSだからMicrosoft責任」と言いつつ、アプリのTLS設定や認証方式は自社責任

・「ネットワークはベンダー」と言いつつ、NSG例外承認は誰？が決まっていない

・「ログはSIEMがあるから大丈夫」と言いつつ、保持期間・提出期限が決まっていない

混在環境では、レイヤーは“図として綺麗”でも、運用の境界になりません。

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

理由②：レイヤーは“フェーズ”を表せない（設計・構築・運用・事故対応で責任が変わる）

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

クラウドの責任は、時間軸で変わります。

・設計：誰が要件（公開範囲、例外条件、監査要件）を決めるか

・構築：誰が設定を入れるか

・運用：誰が日々の変更と棚卸しを回すか

・事故対応：誰が一次通知・封じ込め・保全・対外説明をするか

レイヤー図は“静止画”です。

しかし現場で燃えるのは“動き”です。

「誰が決めたのか」「誰がいつまでに動くのか」が決まっていないと、事故の初動が遅れます。

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

理由③：レイヤーは“作業責任”と“説明責任”を混ぜてしまう

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

レイヤー分界でよく起きるのが、これです。

・委託先が設定を変更した（作業責任は委託先）

・でも取引先と契約しているのは自社（説明責任は自社）

・Microsoftの範囲が絡む（原因に関与する可能性はある）

→ それぞれの責任が“同時に存在”する

レイヤーで「ここはベンダー」と書いた瞬間に、社内でこういう誤解が生まれます。

「じゃあそこはベンダーが説明するんだよね？」

現実は逆で、社外への説明の主語は原則として自社に残ります。

ここを取り違えると、監査・取引先照会で説明が割れます。

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

理由④：レイヤーでは“提出能力（証跡）”が設計されず、監査で詰む

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

監査や取引先は、最後は証跡（ログ・記録）で判断します。

しかしレイヤー分界は、次の設計につながりません。

・どのログを対象にするか

・どこに保管するか

・何年保持するか

・誰が何営業日以内に提出できるか

・事故時に保全（削除停止・隔離・抽出者記録）ができるか

たとえば「ログ層はSOC」とレイヤーで書いても、

“提出期限”や“保全手順”が決まっていなければ、説明責任は成立しません。

レイヤーは、証跡という“成果物”を生みません。

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

理由⑤：レイヤー分界は“例外運用”の恒久化を止められない

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

クラウド運用で本当に危ないのは、例外が積み上がって恒久化することです。

・NSGの暫定開放

・条件付きアクセスの除外

・PIMの例外（常設化）

・Break-glassの属人化

・Key Vaultの期限切れ放置

これらはレイヤーで整理しても、止まりません。

止めるのは「台帳」と「期限」と「承認」です。

つまり必要なのは、レイヤーではなく“運用の制度設計”です。

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

3. じゃあどう考えるべきか：責任分界は“タスク”で切る（RACI）

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

レイヤー分界がダメなのではなく、レイヤー“だけ”で止めるのがダメです。

実務で崩れないのは、責任分界を「やること」で切るやり方です。

おすすめは、タスク別のRACI（R=実行、A=最終責任、C=相談、I=共有）です。

ポイントは「事故対応まで含める」「提出能力まで含める」ことです。

最低限押さえたいタスク（例）

① 変更管理（Change）

・設定変更の承認者は誰か

・緊急変更の事後追認期限はあるか

・ロールバック方針は誰が持つか

② 特権アクセス（Privileged Access）

・特権付与・剥奪の責任者

・期限付きにするか（常設化をどう止めるか）

・操作ログを誰がどこまで保管するか

③ 例外運用（Exception）

・例外を出せる条件

・例外台帳（理由・承認・期限・解除計画）

・例外中の補償統制（監視強化、送信元限定等）

④ ログ提出（Evidence）

・対象ログ（認証、管理操作、NW変更、Key操作等）

・保持期間

・提出期限・形式

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

⑤ BCP/復旧（BCP）

・RTO/RPOを誰が決めるか

・復旧手順（誰が、どの順番で）

・復旧テストを誰が実施し、記録を残すか

⑥ インシデント対応（IR）

・一次通知（誰が、何分以内に、どのチャネル）

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

・対外説明（誰が文章を出すか、承認は誰か）

⑦ 委託管理（Vendor Control）

・委託先の作業範囲（やる／やらない）

・ログ提出義務・保全協力

・再委託（国外含む）の条件と同等義務の貫通

・契約終了時の出口（アクセス剥奪証明、引継ぎ）

これを「タスク別」に固定すると、レイヤーの曖昧さが消えます。

そして何より、監査・取引先の質問に“主語が割れずに答えられる”ようになります。

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

4. レイヤー分界を“使うなら”こう使う（正しい役割）

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

レイヤーの図自体が無意味ではありません。

役割は「説明の入口」と「抜け漏れ検知」です。

レイヤー分界の正しい使い方

・入口：クラウドの責任共有をざっくり理解する

・抜け漏れ：IaaS/PaaS/SaaSの違いで“自社責任が増える箇所”を発見する

・ただし結論はタスク別RACIへ落とす（ここがゴール）

つまり、

レイヤー＝目次

タスク＝本文（責任分界の本体）

という位置づけです。

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

5. ケーススタディ（匿名化）：レイヤー分界で整理したのに事故で割れた会社

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

実務でよくある構図を匿名化して紹介します。

背景

・Azure運用。構築はSIer、運用はMSP、監視はSOC。

・責任分界はレイヤー図で整理済み（NW層はベンダー、ログ層はSOC等）

起きたこと

・条件付きアクセスの例外が増えていた（期限管理なし）

・NSGの暫定開放が残っていた（台帳なし）

・外部からの不正アクセス疑いが出て、取引先照会が発生

・照会内容は「いつ誰が決めた」「ログ提出はいつ」「一次報告は誰が」の“体制質問”

レイヤー分界が役に立たなかった理由

・「NW層はベンダー」と書いても、例外の承認者が決まっていない

・「ログ層はSOC」と書いても、提出期限と形式が契約にない

・事故時の封じ込め（権限停止、NSG締め）の実行者と承認者が割れる

立て直しで効いたこと

・タスク別RACIで「一次通知・封じ込め・保全・提出・対外説明」を固定

・例外台帳を作り、期限と補償統制をセット化

・委託契約別紙（SOW）に「通知・ログ提出・保全協力・特権統制」を明記

・証跡パック（提出物セット）を定義し、提出能力を作った

結果

・技術構成を大きく変えずに、「説明できる状態」に寄せられた

という流れです。

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

6. チェックリスト：レイヤー分界で止まっていないか？

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

□ 責任分界がレイヤー図で終わっており、タスク別RACIがない

□ 事故対応（一次通知・封じ込め・保全・対外説明）の主語が決まっていない

□ ログは“取れる”が、保持期間・提出期限・提出形式・承認が決まっていない

□ 例外運用（NSG暫定開放、CA除外、PIM例外）が台帳化されていない

□ 委託先の作業範囲（やる／やらない）がSOWに落ちていない

□ 委託先にログ提出義務・保全協力・一次通知義務が明記されていない

□ 特権アクセスが常設化し、剥奪証明ができない

□ BCPとしてRTO/RPOが決まっておらず、復旧テスト記録がない

□ 再委託（下請け／海外SOC等）の範囲特定と同等義務の貫通が説明できない

一つでも当てはまると、レイヤー分界だけでは説明責任が成立しにくい状態です。

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

7. まとめ：責任分界のゴールは「層の整理」ではなく「説明が通る状態」

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

責任分界を“レイヤー”で考えると失敗する理由は、

クラウドで問われる責任が「層」ではなく「タスク」と「証跡」だからです。

・レイヤーは入口として使う（目次）

・本体はタスク別RACIに落とす（誰が決め、誰が動き、誰が説明するか）

・証跡パック（提出能力）と例外台帳（恒久化防止）で運用に落とす

・委託契約別紙（SOW）に義務を入れて“実務として保証”する

これができると、クラウドは「動いている」だけでなく「説明が通る」状態になります。

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

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

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

山崎行政書士事務所では、Azure/M365等のクラウド運用について、技術構成と契約・規程・監査対応をセットで整理し、責任分界を“レイヤー止まり”にせず「タスク別RACI＋証跡＋委託管理」まで落とし込むクラウド法務支援を行っています。

・レイヤー分界の資料はあるが、監査・取引先に説明が通らない

・委託先（MSP/SOC）を含めたRACIを事故対応まで作りたい

・ログ提出義務・保全協力・特権アクセス統制をSOWに落としたい

・例外運用を台帳化して恒久化を止めたい

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

お問い合わせの際に「レイヤー分界の記事を見た」と書いていただけるとスムーズです。