【クラウド法務】ベンダーに任せているのに、なぜ情シスの説明負荷が減らないのか― SOC/MSP/SIerがいても「結局うちが説明する」から抜け出せない会社の構造と、抜け方 ―

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

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

はじめに

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

「運用はMSPに任せています」

「監視はSOCが見ています」

「構築はSIerがやりました」

体制としては“任せている”はずなのに、情シスの説明負荷がまったく減らない。

むしろ導入後にこういう場面が増えていませんか。

監査・親会社・取引先からの質問が、情シスに全部集まる

ベンダーに聞くと「契約範囲外」「ベストエフォート」「別作業」の回答が返ってくる

ログはあるのに「何営業日以内に出せる？」で詰まる

例外（暫定開放、CA除外、常設権限）が増え、説明が苦しくなる

ベンダーがいるのに「誰が決めた？」が情シスに刺さる

情シスとしてはこう思います。

「任せているのに、なぜ説明だけは自分たちなのか」

「技術は回っているのに、説明責任だけが重い」

結論から言うと、“運用を任せる”と“説明責任が減る”は別物です。

説明負荷が減らないのは、情シスの努力不足ではなく、運用委託の設計（主語・期限・証跡・契約）が“説明用”に作られていない構造が原因です。

本記事では、なぜ説明負荷が減らないのかを

「共感 → 技術的な整理 → 法務の地雷 → 対策のフレーム → 具体例 → チェックリスト → 相談導線」

の順で分解し、明日から現場で使える形に落とし込みます。

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

技術構成の“事実整理”：関係者が増えるほど、説明の窓口は情シスに固定される

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

Azure / M365 / Entra ID を導入し、運用委託・監視委託まで入れると、多くの企業は次のような体制になります。

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

【クラウド事業者】Microsoft

・サービス提供（基盤稼働、プラットフォーム）

　↓

【構築】SIer / ベンダー

・設計、構築、移行、初期設定、運用設計書の作成

　↓

【運用】MSP（運用代行）

・監視、定常作業、問い合わせ一次対応、変更対応（範囲はSOW次第）

　↓

【監視】SOC

・アラート監視、インシデント一次分析、報告（再委託で海外SOCが入ることも）

　↓

【自社】情シス／CSIRT／法務／購買／経営

・最終責任、承認、対外説明、リスク受容、契約管理

ここで重要な事実があります。

運用は分業できても、社外・社内への説明窓口は“会社”にしか持てないという点です。

監査は「あなたの会社として」説明を求める

取引先は「あなたの会社として」期限付きで回答を求める

事故時は「あなたの会社として」初動と説明を求める

ベンダーは助けてくれます。

でも“会社としての説明”は、最終的に情シス（もしくは社内の説明窓口）に集まる構造です。

ここまでは技術の話。

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

情シスの説明負荷が減らない本質は、

「実作業（オペレーション）は委託できても、説明責任（Accountability）は委託しても消えない」

という点にあります。

そして、消えないなら「説明のための部品」を最初から設計しておかないと、負荷はむしろ増えます。

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

2. ベンダーに任せているのに説明負荷が減らない理由（よくある7つの構造）

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

「任せているのに減らない」は偶然ではありません。

現場で特に多い“減らない構造”を7つに分解します。

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

理由①：委託で減るのは“作業量”で、減らないのは“説明責任”

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

まず、期待値のズレがあります。

MSP/SOCが減らすもの：定常作業、監視、一次分析、運用手順

会社が背負うもの：対外説明、契約上の約束、リスク受容、最終判断

つまり、委託は「手を動かす人」を増やす仕組みであって、

「会社としての約束を背負う人」を減らす仕組みではありません。

ここを混同すると、「任せているのに説明負荷が減らない」が必然になります。

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

理由②：責任分界が“レイヤー説明”で止まり、事故・監査が聞く“タスク主語”が決まっていない

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

説明が割れる典型はこれです。

よくあるレイヤー分界

Microsoft：クラウド基盤

ベンダー：構築・運用

自社：利用者管理・意思決定

しかし、監査・取引先・事故対応が聞きたいのは「タスク」です。

一次通知：誰が・何分以内に・誰へ

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

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

ログ提出：誰が・何営業日以内に・どの形式で・誰の承認で

対外説明：文面承認者は誰

例外：誰が承認し、期限管理し、解除する

タスク主語が決まっていないと、質問が来た瞬間に「誰がやる？」会議が始まり、説明負荷は減りません。

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

理由③：「ログは取っています」が“提出能力”を含まないため、照会が来ると情シスが材料集め役になる

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

委託しているのに一番疲れるのが、ログ提出系です。

ベンダー側の「ログは取っています」

＝収集して保管している（運用上はOK）

社内外が求める「ログを出せますか」

＝期限内に提出できる形で、承認を経て、必要なら保全も含めて出せる（説明責任）

具体的に問われるのはこうです。

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

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

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

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

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

この“提出能力”が委託の成果物として設計されていないと、

情シスが「関係者から材料を集めるPM」になり、説明負荷は増えます。

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

理由④：「対応可能」「24/7可能」が“約束”として社内外で引用され、情シスが言い切りの矢面に立つ

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

委託が入ると、前向きな言葉が増えます。

24/7対応可能

対応可能

復旧可能

監査に耐える

ログ提出可能

しかし運用が始まると、これらは必ずこう問われます。

何分以内？何営業日以内？

義務？ベストエフォート？

誰が責任者？成果物は？

この言葉を“期限と成果物”に翻訳していない会社ほど、情シスが説明を背負います。

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

理由⑤：例外（暫定・除外・緊急）が積み上がり、説明が“原則設計”からズレていく

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

委託していても例外は増えます。むしろ増えやすい。

条件付きアクセスの除外（業務都合）

NSG/Firewallの暫定開放（切り分け・納期）

PIMのはずが常設権限（作業効率）

break-glassの運用逸脱（緊急時の便利さ）

技術的には“業務が回る”。

でも監査・取引先が見るのは「例外が管理されているか」です。

例外台帳（期限・解除条件・補償統制）がないと、説明の負荷は減らず、むしろ増えます。

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

理由⑥：委託（SOW）が“作業”中心で、「説明のための成果物」が義務化されていない

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

情シスの説明負荷を減らすには、委託先が“材料を出してくれる”必要があります。

しかしSOWが作業中心だと、材料が成果物ではありません。

成果物化しておかないと消えるもの

通知記録（いつ、誰が、何を通知したか）

保全記録（削除停止や隔離の実施記録）

ログ抽出の作業記録（抽出者記録）

提出形式に整えた提出物（マスキング含む）

例外台帳の更新履歴

権限付与・剥奪の証跡

再委託（国外/海外SOC）を含む体制の説明材料

「任せているのに説明負荷が減らない」の多くは、ここ（成果物の未定義）で起きています。

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

理由⑦：担当交代・委託先変更で“いつもやっていた”が消え、情シスが穴埋めする

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

平時は関係性で回ります。

しかし次の瞬間に崩れます。

MSP/SOCの担当が変わる

再委託先（海外SOC）が変わる

契約更新で条件が変わる

社内担当が異動する

このとき、

「口頭で分かっていたこと」「その場でやっていたこと」

が消えます。

残るのは契約と記録だけ。

ここが弱い会社ほど、情シスが説明の穴埋め役になり、負荷が減りません。

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

3. 法務・説明責任の地雷：委託していても詰む“3つの質問”

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

委託しているのに説明負荷が減らない会社で、必ず刺さる質問があります。

この3つが出始めたら「説明の設計」が必要です。

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

地雷①：「何営業日以内に出せますか？」（ログ・証跡提出）

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

“ある”では足りません。期限内に“出せる”が必要です。

提出期限・形式・承認・抽出者記録・保全まで、材料が揃っていないと詰みます。

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

地雷②：「誰が決めたんですか？」（意思決定の主語）

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

ベンダー推奨で進んだ設定ほど、後から刺さります。

推奨→意思決定への変換（承認者・理由・見直し条件）がないと、情シスが背負います。

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

地雷③：「その“対応可能”は義務ですか？」（契約と期待値）

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

“可能”は約束ではありません。

SOWに落ちていないことは、事故や照会で「ベストエフォート」「別料金」になります。

結果、期限に間に合わず情シスが詰みます。

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

4. 対策のフレーム：説明負荷を“構造的に減らす”5つの整え方

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

委託しているのに説明負荷が減らないなら、対策は「もっと委託」ではなく、

委託と社内統制を“説明のために再設計”することです。

ここでは、現場で回しやすい5つの整え方を提示します。

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

整え方①：タスク別RACIで“主語”を固定する（レイヤーではなく、やること）

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

最低限、次のタスクは主語を固定します。

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

封じ込め（権限剥奪・通信遮断：判断者と実行者）

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

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

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

対外説明（文面承認者）

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

ポイント

A（最終責任）は個人名ではなく役割名で固定。

担当交代でも壊れません。

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

整え方②：「ログ提出・保全パック」を作り、“出せる”を言い切れる形にする

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

ログを“運用のためのログ”から“説明のための証跡”に変換します。

ログ提出・保全パック（最小項目）

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

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

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

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

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

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

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

委託が絡む場合の提出ルート（SOC/MSP→自社→対外）

これがあると「材料集め」が減り、説明負荷が落ちます。

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

整え方③：例外台帳を“初日から”回し、暫定が恒久化して説明を壊すのを止める

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

例外はゼロにしません。期限付きで管理します。

例外台帳の最小項目

例外ID（チケット）

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

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

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

承認者（役割）

期限（必須）

解除条件

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

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

例外が台帳に乗るだけで、説明の深掘りが止まりやすくなります。

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

整え方④：Decision Log（判断ログ）で「推奨」を「会社の意思決定」に変換して残す

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

“誰が決めた？”に耐えるには、短い判断ログが効きます。

判断ログの最小フォーマット

何を決めたか

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

承認者（役割）

期限と見直し条件

影響範囲

根拠（参照資料・規程・台帳等）

これがあると、情シスが“決めた覚えのない決定”を背負いにくくなります。

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

整え方⑤：SOWを「作業」から「説明材料の納品」へ寄せる

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

説明負荷を本当に減らすには、委託先から材料が“期限付きで”出てくる必要があります。

そのためにSOW（作業範囲）で次を義務化します。

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

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

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

作業記録提供（実施者・時刻・内容）

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

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

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

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

「任せているのに説明負荷が減らない」状態は、SOWをここまで寄せると一気に改善します。

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

5. ケーススタディ（匿名化）：SOC/MSPがいるのに、照会対応で情シスが燃えたA社

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

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

背景

業種：製造業

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

環境：Azure＋M365＋Entra ID

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

状況：障害も少なく“運用は安定”していた

きっかけ

取引先から「インシデント発生時のログ提出は何営業日以内か」「保全（削除停止）は可能か」などの照会が到来。

起きたこと

SOCは「検知・一次分析」は早いが、外部提出用の形式整備や期限確約は難しい

MSPは「抽出は可能だが、外部提出・マスキング・承認支援は範囲外」

社内では「誰の承認で外部提出するか」「例外は期限管理されているか」が決まっていない

結果として、情シスが材料集めと調整の中心になり、回答が遅れ、会議が増えた

立て直し（方向性）

タスク別RACIを作り、提出・保全・承認の主語を固定

ログ提出・保全パックで「提出期限・形式・承認」を確定

例外台帳で「暫定」の期限と解除条件を運用化

Decision Logで「推奨→意思決定」の根拠を残す

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

結果

委託を増やさずに、説明負荷（材料集め・主語割れ・言い切り不安）が大きく減った

照会対応のスピードが上がり、監査の深掘りが止まりやすくなった

ポイントは「任せる」ではなく、任せた結果を“説明できる形”で返してもらう設計です。

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

6. 自社で確認しておきたいチェックリスト

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

次のYESが多いほど、「委託しているのに説明負荷が減らない」状態になっています。

【主語（責任分界）】

□ レイヤー分界（Microsoft/ベンダー/自社）は説明できるが、タスク別主語が言えない

□ 一次通知・封じ込め・保全・提出・対外説明のA（最終責任）が役割で固定されていない

□ 事故対応で「止める／残す／出す」の主語が会議で割れる

【ログ（提出・保全）】

□ ログは集約しているが、提出期限（何営業日以内）が言えない

□ 提出形式（項目・時刻基準・マスキング）と承認者が決まっていない

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

□ SOC/MSPが絡む提出ルートが整理されていない

【例外】

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

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

□ 「暫定」が恒久化している

【契約（SOW）】

□ 通知期限・提出期限・保全協力・記録提供がSOWで義務化されていない

□ 「対応可能」「ベストエフォート」が多く、義務と成果物が曖昧

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

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

【意思決定】

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

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

□ 担当交代した瞬間に説明が崩れそう

YESが3つ以上ある場合、委託していても説明負荷は減りにくいです。

逆に言えば、RACI／証跡パック／例外台帳／SOW整合／判断ログを揃えるだけで、負荷は構造的に落とせます。

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

7. まとめ：委託しても説明負荷が減らないのは“任せ方”ではなく「説明の設計」が抜けているから

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

ベンダーに任せているのに情シスの説明負荷が減らないのは、自然なことです。

委託で減るのは作業量で、説明責任は会社に残るからです。

ただし、説明負荷は「仕組み」で減らせます。

タスク別RACIで主語を固定する

ログ提出・保全パックで“期限内に出せる”を言い切れる形にする

例外台帳で暫定を期限付きにし、説明のズレを止める

Decision Logで推奨を意思決定に変換して残す

SOWで材料（通知・提出・保全・記録提供）を義務化する

委託を増やす前に、「説明の部品」を揃える。

これが、情シスの説明負荷を本当に減らす近道です。

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

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

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

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

「ベンダーに任せているのに説明負荷が減らない」状態を、責任分界（タスク別RACI）・証跡パック（ログ提出/保全）・例外台帳・判断ログ・SOW整合まで含めて整える「クラウド法務支援」を行っています。

SOC/MSPがいるのに、照会・監査が全部情シスに刺さる

ログはあるが、提出期限・形式・承認・保全が言い切れない

「対応可能」が約束になりそうで怖い

例外（暫定開放、CA除外、常設権限）が恒久化して説明が苦しい

委託先の作業を“義務・成果物”として固め直したい

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

お問い合わせの際に「説明負荷が減らない記事を見た」と書いていただけるとスムーズです。