【クラウド法務】導入説明が「運用が始まってから」必要になる会社の共通点― “動いている”のに、監査・取引先・親会社・経営説明で詰まるのは、導入ではなく「説明の設計」が未着手だから ―

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

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

はじめに

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

導入は順調で、スケジュールも守れている。技術的にも動いている。運用委託も入っている。

それなのに「導入説明が必要になるタイミング」が、なぜか“運用が始まってから”やってくる会社があります。

本番稼働後に突然こう聞かれるからです。

「その設定の判断根拠は？」

「事故時に誰が・どこまで・いつまでに対応する？」

「ログは何営業日以内に提出できる？保全（削除停止）は？」

「例外（暫定・除外）は期限管理している？」

「委託先の範囲は契約上どこまで？」

情シス側はこう感じます。

「稼働はしているのに、説明する材料が揃っていない」

「決めた覚えのない決定が、いつの間にか“会社の約束”になっている」

「ベンダーと社内で前提がズレていて、話が割れる」

本記事では、導入説明が「運用が始まってから」必要になる会社の共通点を構造として整理し、

運用前に“説明できる状態”を作るためのフレームと成果物（スコープ／RACI／証跡パック／例外台帳／SOW）を提示します。

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

技術構成の“事実整理”：導入資料はあるのに、説明資料が存在しない

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

Azure / M365 / Entra ID などの導入で、ベンダーや情シスがまず揃える資料は概ね次の2つです。

構成図（アーキテクチャ）

運用設計書／手順書（Runbook）

（典型構成：テキスト図）

【ID/IAM】Entra ID

・条件付きアクセス（MFA/端末準拠/場所制限/例外除外）

・PIM（特権の一時付与）

・監査ログ（Sign-in / Audit）

　↓

【クラウド基盤】Azure / M365

・VNet / NSG / Firewall / WAF

・VM / PaaS / Storage / Key Vault

・Backup / Site Recovery（BCP）

　↓

【ログ】

・Activity / Resource Logs / M365監査ログ

・Log Analytics / SIEM（Sentinel等）

　↓

【体制】

・自社：情シス／CSIRT／法務／経営

・委託：SIer（構築）／MSP（運用）／SOC（監視）

（再委託で海外SOCが入ることも）

ここまでの資料は、導入の成功（＝動くこと）に必要です。

しかし、運用が始まってから必要になる「導入説明」は、構成図や手順書だけでは成立しません。

運用開始後に問われるのは、ほぼ次の4点です。

どこまでが対象か（スコープ）

誰が責任者か（主語：責任分界）

いつまでに出せるか（期限：提出・通知・復旧）

何を根拠に言い切るか（証跡：ログ・台帳・承認記録）

構成図は「何があるか（What）」

導入説明は「誰が・いつまでに・何を根拠に言えるか（Who/When/Proof）」

ここまでは技術の話。

ここからが法務・説明責任の話です。

導入説明が運用開始後に必要になる会社は、導入資料（構成・手順）を“納品物”として揃えた一方で、

説明資料（スコープ・責任分界・証跡・例外・契約整合）を“成果物”として揃えていない、という共通点があります。

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

2. 導入説明が「運用が始まってから」必要になる会社の共通点5選

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

ここからが本題です。

「なぜ後から必要になるのか」は偶然ではなく、典型パターンがあります。

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

共通点①：プロジェクトの完了定義が「構成完了」になっている

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

導入プロジェクトの完了条件が、こうなっている会社ほど後で説明が必要になります。

移行が終わった

テストが通った

運用設計書が納品された

運用引継ぎ会が終わった

これらは“導入完了”であって、“説明完了”ではありません。

説明完了の最低条件は、次が言い切れる状態です。

照会（取引先・親会社）に期限内に回答できる

監査で例外管理・証跡・責任分界を提示できる

事故時に「止める／残す／出す」の主語と手順が回る

完了定義に「説明できる」が入っていないと、運用開始後に説明が必要になります。

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

共通点②：ベンダー推奨が“社内の決裁”にすり替わっている

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

導入中によく聞く言葉があります。

推奨です

標準です

ベストプラクティスです

導入フェーズでは便利です。

しかし運用開始後には、こう問われます。

なぜその設定にした？

代替案は？

どのリスクを受容した？

いつ見直す？（期限と条件は？）

推奨は“材料”で、意思決定ではありません。

意思決定（主語・理由・見直し条件）が成果物として残っていないと、運用が始まった瞬間に「導入説明」が必要になります。

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

共通点③：責任分界がレイヤー説明で止まり、タスクの主語が決まっていない

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

「Microsoft／ベンダー／自社」というレイヤー分界は分かった気になります。

でも運用開始後に問われるのは“タスク”です。

一次通知（何分以内に、誰が、誰へ）

封じ込め（権限剥奪・通信遮断：誰が判断し誰が実行）

ログ保全（削除停止・隔離・抽出者記録：誰がやる）

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

対外説明（文面承認者）

例外承認／延長／解除（期限管理）

これが決まっていないと、運用開始後に「それは誰がやる話？」が噴き出し、導入説明（＝主語の整理）が後追いになります。

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

共通点④：ログは集めたが「提出能力」と「保全能力」が設計されていない

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

運用開始後に突然来る質問の代表がログです。

ログは何営業日以内に提出できる？

提出形式は？（項目、時刻基準、マスキング）

誰の承認で外部提出する？

事故時に保全（削除停止・隔離）できる？

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

「ログがある」ことと「期限内に提出できる」ことは別です。

この差が埋まっていない会社ほど、運用開始後に導入説明が必要になります。

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

共通点⑤：例外（暫定・除外・緊急）が台帳化されず、現実が“原則設計”からズレる

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

運用が始まると例外は必ず増えます。

条件付きアクセスの除外

NSGの暫定開放

PIMを使わない常設特権

break-glassの運用逸脱

Key Vaultの期限切れ（Secrets/Certificates）等

例外が悪いのではありません。

悪いのは、例外に「期限・解除条件・承認者・補償統制」が無いことです。

この状態だと、監査や照会で「原則は分かったが、例外は？」となり、運用開始後に導入説明（＝例外の説明）が必要になります。

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

3. 法務・説明責任の地雷：なぜ“運用開始後”に一気に噴き出すのか

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

導入中は、ベンダー同席・関係性・プロジェクト予算で“その場対応”が成立します。

しかし運用開始後は、残るのは「契約」と「体制」と「記録」だけです。

運用開始後に噴き出しやすい地雷は次の3つです。

「できる」と「義務としてやる」が混ざり、言葉が約束として引用される

委託（SOC/MSP/SIer）のSOWが薄く、提出・保全・記録提供がベストエフォート扱いになる

担当交代・委託先変更で“いつもやっていた”が消え、資料が残っていないことが露呈する

つまり、運用開始後に導入説明が必要になる会社は、

「導入中に回っていたものが、運用では回らない」状態になっているだけです。

回らない理由は、主語・期限・証跡が成果物になっていないからです。

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

4. 対策のフレーム：導入説明を“運用前に終わらせる”ための6点セット

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

ここからは実務の答えです。

運用開始後に慌てないために、導入フェーズで最低限揃えるべき成果物を「6点セット」として提示します。

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

① スコープシート（1枚）

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

導入説明の前提を固定します。

対象：テナント／サブスクリプション／サービス範囲

対象期間：いつ時点の運用を説明するか

含む／含まない：海外拠点・子会社・開発環境

委託範囲：SOC/MSP/SIerの関与範囲

説明先：監査／取引先／親会社／経営（どこに出すか）

これがあると「どこまで答えるか」で荒れません。

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

② タスク別RACI（責任分界表）1枚

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

レイヤーではなくタスクで主語を固定します。

最低限入れるタスク

一次通知（重大度基準、何分以内、誰へ）

封じ込め（判断者と実行者）

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

ログ提出（期限・形式・承認・提出者）

復旧判断（BCP発動、切替の決裁）

対外説明（文面承認者）

例外承認／延長／解除（期限必須）

ポイント：A（最終責任）は個人名ではなく役割名で固定する。

担当交代しても壊れません。

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

③ ログ提出・保全パック（Evidence Production Pack）

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

「ログがある」から「提出できる」へ変換します。

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

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

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

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

外部提出の承認者（役割）

抽出者記録（いつ誰がどう取得したか）

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

委託が絡む場合の提出ルート

運用開始後に最も効く成果物の一つです。

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

④ 例外台帳（Exception Register）

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

暫定を恒久化させない仕組みです。

必須項目

例外ID（チケット番号）

対象（CAポリシー名、NSG名、ロール名等）

例外内容（何を緩めたか）

理由（当時の事情：一文でOK）

承認者（役割）

期限（必須）

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

補償統制（例外中の守り）

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

例外が説明できれば、監査・照会の深掘りが止まりやすくなります。

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

⑤ Decision Log（判断ログ）

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

“決めた覚えがない決定”をなくすための必須部品です。

最小フォーマット

何を決めたか

なぜそうしたか（代替案も一言）

承認者（役割）

期限と見直し条件

影響範囲

根拠（参照資料・規程・ログ等）

運用開始後に「誰が決めた？」が来たとき、情シスが一人で背負わなくて済みます。

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

⑥ SOW整合（お願いを義務に変換）

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

委託が絡むなら、ここが最後の砦です。

SOWに次を落とし込みます。

一次通知（重大度基準＋通知期限）

ログ提出協力（期限・形式・成果物）

ログ保全協力（削除停止等＋実施記録提供）

特権アクセス統制（期限付き、付与理由、剥奪証跡）

例外台帳更新（登録・棚卸し・解除まで）

再委託（国外）の範囲と監督責任

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

「運用が始まってから必要になる導入説明」は、だいたいここ（SOWの薄さ）で詰まります。

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

5. ケーススタディ（匿名化）：運用開始後に“説明作り直し”になったA社

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

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

業種：製造業

拠点：日本＋欧州＋アジア

環境：Azure＋M365＋Entra ID

体制：運用MSP＋監視SOC（再委託あり）

導入：構成・移行・テストは順調で予定通り本番稼働

運用開始後に起きたこと

親会社監査で「例外管理」「ログ提出期限」「保全手順」「委託範囲」の質問が集中

取引先照会で「ログ提出は何営業日以内？」の回答を求められた

ログはあるが、提出形式・承認者・抽出者記録が未整備

例外（CA除外、暫定開放）が増えていたが台帳がなく説明できない

MSP/SOCの作業範囲がSOW上あいまいで、材料集めに時間がかかる

結果

技術的には動いているのに「説明が通らない」

会議が増え、回答が遅れ、運用開始後に“導入説明の作り直し”が発生

立て直し（方向性）

スコープシートとタスク別RACIで主語を固定

例外台帳を整備し、期限・解除条件・補償統制を付与

ログ提出・保全パックを作成し、提出期限・形式・承認を固定

Decision Logで重要判断を残し、担当交代でも説明できる状態に

SOWを見直し、提出協力・保全協力・記録提供を義務化する方向へ

結果として

「運用開始後に必要になる導入説明」を、運用前に終わらせる型へ移行できた

という流れです。

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

6. 自社で確認できるチェックリスト

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

次のYESが多いほど、導入説明が運用開始後に必要になります。

【完了定義】

□ 完了が「構成・移行・テスト」で定義され、「説明できる」が定義されていない

【主語】

□ レイヤー分界は説明できるが、タスク別RACIがない

□ 一次通知・保全・提出・対外説明の主語が役割で固定されていない

□ 事故時に「止める／残す／出す」の主語が割れる

【ログ】

□ ログは集約しているが、提出期限・形式・承認者が決まっていない

□ 保全（削除停止・隔離）と抽出者記録の手順が弱い

【例外】

□ 条件付きアクセス除外、NSG暫定開放、常設特権が増えている

□ 例外台帳がない／期限・解除条件・補償統制がない

□ 「忙しいから後で」が恒久化している

【委託・契約】

□ MSP/SOC/SIerの通知・提出・保全協力がSOWで義務化されていない

□ 作業記録（実施者・時刻・内容）の提供が成果物になっていない

□ 再委託（国外・海外SOC）の範囲と監督責任が説明できない

【意思決定】

□ ベンダー推奨で進んだ設定の判断根拠が残っていない

□ Decision Log（判断ログ）がない

YESが3つ以上ある場合、運用開始後に導入説明が必要になるのは“ほぼ必然”です。

逆に、スコープ／RACI／証跡パック／例外台帳／SOW／判断ログを揃えるだけで、後追い説明は大幅に減ります。

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

7. まとめ：運用開始後に必要になるのは「導入説明」ではなく“説明責任の未完”

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

運用開始後に導入説明が必要になる会社の共通点は、

導入が遅れていることではなく、説明責任（主語・期限・証跡）の設計が未完であることです。

構成が正しくても、運用が回っていても、

説明の部品が揃っていないと、監査・取引先・親会社・経営の前で詰みます。

だから導入フェーズで、次を「成果物」として揃えることが重要です。

スコープシート

タスク別RACI

ログ提出・保全パック

例外台帳

Decision Log

SOW整合（お願い→義務）

これが揃うと、導入説明は“運用開始後に慌てて作るもの”ではなく、

運用前に完成している状態になります。

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

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

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

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

導入説明が運用開始後に必要にならないように、責任分界（タスク別RACI）・証跡パック・例外台帳・判断ログ・SOW整合まで含めて整える「クラウド法務支援」を行っています。

導入は順調だが、監査・照会で説明できる自信がない

ログはあるが、提出期限・形式・承認・保全が固まっていない

例外（暫定・除外）が恒久化しそうで不安

委託先に頼る部分を義務として言い切れるようにしたい

ベンダー推奨で進んだ決定の主語と根拠を整理したい

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

お問い合わせの際に「導入説明が運用後に必要になる記事を見た」と書いていただけるとスムーズです。