【クラウド法務】構成図が立派でも、説明できないシステムの共通点― “絵はある”のに“主語がない”。監査・取引先・経営説明で詰まるのは、技術ではなく「説明の部品」が欠けているから ―

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

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

はじめに

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

構成図が立派なほど、現場は安心します。

Azureのネットワーク分離、WAF、EDR、SIEM、SOC、バックアップ、冗長化――。

「ここまで描けていれば、説明も通るはず」と思いたくなります。

ところが実務では、逆の現象が起きます。

構成図は綺麗なのに、監査・親会社統制・取引先審査・事故対応の場面で、質問が来た瞬間に止まる。

・「その設定は誰が決めたんですか？」

・「事故のとき、誰が何分以内に何をしますか？」

・「ログは何年保持で、何営業日以内に提出できますか？」

・「ベンダーやSOCが関与するなら、誰が責任主体ですか？」

・「復旧は何時間で戻る約束ですか？（SLAではなく）」

このとき詰まるのは、“技術が弱い”からではありません。

構成図に載らない“説明の部品”が欠けているからです。

本記事では、構成図が立派でも説明できないシステムの共通点を、

「技術的な整理 → 法務の地雷 → 整理のフレーム → 事例 → チェックリスト」

の順で整理します。

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

技術構成の“事実整理”：構成図が示しているもの／示していないもの

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

まず、現場でよく見る“立派な構成図”が何を示しているかを整理します。

よくある構成図（ざっくりの要素）

・ID：Entra ID（MFA、条件付きアクセス、PIM）

・ネットワーク：VNet、サブネット、NSG、Firewall、WAF

・ワークロード：VM、PaaS、Storage、Key Vault

・監視：Log Analytics、Sentinel（SIEM）、EDR

・BCP：Azure Backup、Site Recovery、冗長化

・運用体制：SOC／MSP／SIer（※図の外に書かれることも多い）

構成図が強いのは、次の2つです。

“何がどこにあるか”（部品と接続）

“どう流れるか”（データフロー・通信経路）

一方で、構成図が弱い（ほぼ載らない）のは次の3つです。

誰が決めるか（主語）

いつまでにやるか（期限）

何を出せるか（証跡・成果物）

そして監査・取引先・経営が聞いてくるのは、ほぼ例外なくこの3つです。

つまり、構成図は立派でも「説明の質問」に答える部品が不足しやすい構造になっています。

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

説明が必要な局面では、構成図の“機能”より、

責任分界・証跡・約束（復旧・通知・提出）の形が問われます。

ここがないと、どれだけ綺麗な絵でも説明できません。

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

2. 構成図が立派でも説明できないシステムの共通点（6つ）

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

ここから本題です。現場で非常に再現性が高い共通点を6つ挙げます。

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

共通点①：構成図はあるのに「責任分界図（RACI）」がない

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

構成図は「部品の配置」。

説明責任が問われるのは「タスクの責任者」です。

例えば事故対応で実際に聞かれるのはこういう話です。

・不正アクセス疑いが出たとき、アカウント停止を“決める”のは誰？

・停止を“実行”するのは誰？（自社／MSP／どの権限？）

・ログ保全（削除停止）は誰がやる？

・取引先への第一報は誰が承認する？

・SOCは何をし、何をしない？（監視・分析・実行の境界）

構成図が立派でも、**タスク別のRACI（R=実行/A=最終責任/C=相談/I=共有）**がないと、

事故時に主語が割れます。主語が割れると、説明は破綻します。

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

共通点②：「ログはある」けど「提出できる」設計になっていない

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

SIEMもある、ログも集約している。

それでも説明できない会社は多いです。理由は簡単で、問われるのは“保管”ではなく“提出能力”だからです。

説明の質問はこうです。

・何のログを（対象ログの一覧）

・どこから（保管場所・抽出経路）

・どの期間（保持期間と延長）

・何営業日以内に（提出期限）

・どの形式で（項目・時刻基準・マスキング）

・誰の承認で（外部提出の承認者）

・真正性は（抽出者記録：いつ誰がどう取得したか）

「ログはあります」は、技術的な事実でしかありません。

“期限内にこの形で出せます” という状態になっていないと、説明になりません。

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

共通点③：例外・暫定・抜け道が、構成図に出ていない（＝説明の爆弾）

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

構成図は“あるべき姿”を描きます。

一方で、説明を壊すのは“現実の抜け道”です。

典型例

・NSGの暫定開放が残っている（期限不明）

・条件付きアクセスの除外ユーザーが増えている（承認不明）

・Break-glassが多すぎる／運用が曖昧

・委託先の常設特権が残っている（PIM未適用）

・「移行が終わるまで暫定」のまま半年経過

構成図が綺麗でも、例外は増えます。

例外が増えるのは悪ではありません。悪いのは、例外が“台帳＋期限＋解除条件”で管理されていないことです。

これがあると、監査や取引先照会で一撃で詰みます。

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

共通点④：「SLA」と「復旧の約束（RTO/RPO）」が混ざっている

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

構成図には冗長化やバックアップが描かれます。

そして言いがちな説明が「SLAがあるので大丈夫」です。

でも、取引先・監査・経営が欲しいのは、稼働率（SLA）ではなく、

**止まったときに何時間で戻るのか（RTO）、どこまで戻るのか（RPO）**です。

これはクラウド事業者のSLAだけでは決まりません。

自社の設計・手順・テスト・委託体制で決まります。

構成図が立派でも、

・復旧手順書がない

・復旧テスト記録がない

・誰が復旧判断するかが曖昧

だと、復旧の約束は説明できません。

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

共通点⑤：委託・再委託（海外SOC含む）が“図と契約”に乗っていない

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

クラウド運用は、ほぼ確実に複数社が関わります。

SIer、MSP、SOC、下請け、海外SOC。

この“関係者の多さ”が、説明を壊す最大要因の一つです。

よくある破綻

・自社：「SOCが見てます」

・SOC：「実行はしません（契約外）」

・MSP：「承認がないと止められません」

・取引先：「じゃあ誰が責任主体？」

・監査：「再委託（国外）やアクセス主体は説明できる？」

構成図が立派でも、

契約（特にSOW）で“通知・提出・保全・特権アクセス統制”が義務化されていないと、

事故の現場で材料が集まりません。説明ができません。

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

共通点⑥：「変更の意思決定」と「記録」が設計されていない

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

事故や監査で最後に効くのは、設定そのものより、

「誰が決めて、いつ変えて、なぜ変えたか」です。

構成図が立派でも、次が弱いと説明できません。

・変更承認（誰がOKしたか）

・変更理由（何のリスク・要件で）

・変更の記録（チケット、タイムライン）

・緊急変更（事後追認のルール）

・委託先作業の証跡（作業報告、実施者）

「設定は正しい」ではなく、

“意思決定として正しい形で残っている” が問われます。

ここが弱いと、説明の主語が割れます。

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

3. クラウド法務としての「整理のフレーム」

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

では、何を整えれば「構成図が立派＝説明も強い」状態になるのか。

答えは、構成図を増やすことではありません。

**説明のための“追加の3枚”**を作ることです。

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

フレーム①：タスク別RACI（責任分界）1枚

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

レイヤー（ネットワーク層など）ではなく、タスクで切ります。

最低限これだけは入れます（事故対応まで含める）。

・一次通知（検知から何分以内、誰が誰へ）

・封じ込め（アカウント停止、通信遮断、例外解除）

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

・ログ提出（何営業日以内、形式、承認者）

・復旧判断（BCP発動、切替）

・対外説明（文面承認者）

・委託先管理（再委託、国外関与、特権アクセス）

これがあると「誰がやるのか問題」で止まらなくなります。

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

フレーム②：証跡パック（提出できる材料）1枚

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

“ログはある”ではなく、“この形で出せる”を固定します。

証跡パックの最小項目

・対象ログ一覧（Sign-in/Audit/Activity/Resource 等）

・保持期間（標準・延長・例外）

・提出期限（例：〇営業日以内）

・提出形式（項目、時刻基準、マスキング要否）

・抽出手順（担当、承認、抽出者記録）

・保全手順（削除停止、隔離、アクセス制限）

・委託先からの提出ルート（SOC→MSP→自社等）

これがあると、監査・取引先照会の質問が“怖くなく”なります。

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

フレーム③：例外・暫定台帳（期限つき）1枚

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

例外は必ず出ます。だから台帳で勝ちます。

最低限の台帳項目

・例外ID（チケット番号）

・対象（NSG名／CAポリシー名／ロール名など特定できる形）

・理由（業務要件／障害対応／移行措置等）

・承認者（役割）

・期限（必須）

・解除条件（何が終われば戻すか）

・補償統制（例外中の守り：監視強化、送信元限定、時間帯制限など）

・解除完了の証跡（いつ誰が戻したか）

例外が説明できると、構成図が“統制の図”に変わります。

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

4. ケーススタディ（匿名化）：構成図は完璧なのに取引先審査で止まったA社

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

（実務でよくある構図を匿名化しています）

背景

・製造業A社：Azure＋M365を全社展開

・構成図：ネットワーク分離、WAF、EDR、SIEM、バックアップ、冗長化まで完備

・体制：監視はSOC、運用はMSP、構築はSIer

取引先審査で聞かれたこと

・事故時の一次通知は何分以内？誰が責任者？

・当該期間の証跡ログを何営業日以内に提出できる？

・ログの保全（削除停止）は誰がやる？手順は？

・委託先・再委託（海外SOC含む）の関与範囲は？誰がアクセスできる？

・例外（条件付きアクセス除外、暫定ルール）は期限付きで管理している？

詰まった理由

・構成図はあるが、RACIがなく主語が割れる

・ログはあるが、提出期限・形式・承認がない

・例外が台帳化されておらず、期限も承認も追えない

・SOWに提出・保全協力が義務として落ちておらず、材料が集まらない

立て直し（方向性）

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

・証跡パックを定義（提出期限・形式・抽出者記録）

・例外台帳を作成し、既存例外に期限と解除条件を付与

・委託契約（SOW）に一次通知・提出義務・保全協力・特権アクセス統制を追記

結果

・技術構成を大きく変えずに「説明できる」状態へ寄せられ、審査が前に進んだ

という流れです。

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

5. 構成図が立派でも説明できない“兆候”チェックリスト

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

以下にYESが少ないほど、「立派な絵」なのに説明が止まる可能性が高いです。

□ タスク別RACIが1枚である（通知・封じ込め・保全・提出・復旧・対外説明まで）

□ SOC/MSP/SIer/Microsoftの役割がタスクで説明できる

□ ログ提出について「何営業日以内に・どの形式で・誰の承認で」が決まっている

□ 抽出者記録（いつ誰がどう取得したか）を残せる

□ 事故時のログ保全（削除停止・隔離）の手順と責任者が決まっている

□ 例外（NSG暫定開放、CA除外、特権常設等）が台帳で管理され期限がある

□ 例外延長は再承認になっている（理由更新＋補償統制の再確認）

□ 復旧目標（RTO/RPO）をシステム別に言える（SLAと混ぜていない）

□ 復旧手順書と復旧テスト記録がある（根拠がある）

□ 委託契約（SOW）に、一次通知・提出義務・保全協力が期限付きで書かれている

□ 再委託（国外）や海外SOCの関与範囲・アクセス主体を説明できる

□ 変更承認と記録（誰が決めたか）が残る運用になっている

「構成図はあるのにYESが揃わない」場合、

問題は技術の不足ではなく、説明の設計（主語・期限・証跡）の不足です。

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

6. まとめ：立派な構成図があるほど、“説明の部品不足”が目立つ

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

構成図が立派でも説明できないシステムの共通点は、ほぼこれです。

・責任分界（主語）がない

・提出能力（期限・形式・承認）がない

・例外が台帳化されず恒久化している

・SLAと復旧の約束が混ざっている

・委託・再委託の義務が契約に落ちていない

・意思決定と記録が残らない

つまり、構成図は“技術の完成度”を示しても、

説明に必要な“統制の完成度”までは示さない、ということです。

だからこそ、構成図に加えて

RACI／証跡パック／例外台帳

この3枚を揃えると、システムは「動いている」だけでなく「説明できる」状態に近づきます。

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

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

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

山崎行政書士事務所では、Azure / M365 / Entra ID 等の技術構成と、契約・規程・監査対応をセットで整理し、

「構成図は立派なのに説明が通らない」状態から、

「責任分界（RACI）・証跡（提出/保全）・例外管理（期限付き）」で説明できる状態へ整えるクラウド法務支援を行っています。

・監査や取引先の質問が“技術”ではなく“体制”に寄ってきた

・ログはあるのに、期限内に出せる説明ができない

・SOC/MSP/再委託を含めると、主語が割れてしまう

・例外（NSG/条件付きアクセス/特権）が恒久化している

・SOWに「通知・提出・保全協力」を落とし込みたい

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

お問い合わせの際に「構成図は立派でも説明できない記事を見た」と書いていただけるとスムーズです。