【クラウド法務】「プロに任せたはず」が、責任だけ残す構造― SOC/MSP/SIerに任せても、監査・取引先・事故後説明で“最後に立つ人”が消えない理由 ―

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

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

はじめに

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

「構築はSIerに任せた」

「監視はSOCが見ている」

「運用はMSPに任せている」

体制としては“プロに任せた”はずなのに、いざ社内説明や監査、取引先照会、事故後説明になると、なぜか情シスだけが前に出て、こう言われます。

「つまり、御社としてはどう約束しているんですか？」

「その設定や例外は、誰が決めたんですか？」

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

情シスとしては心の中でこう思うはずです。

“プロに任せたのに、責任だけ残ってるじゃないか”

結論から言うと、これは珍しい現象ではありません。むしろ“自然に起きる構造”です。

プロに任せるほど「作業」は減りますが、設計しない限り「説明責任（誰が・いつまでに・何を根拠に）」は減りません。

そして説明責任が減らないまま運用が進むと、最終的に“責任だけ”が情シスに集まります。

本記事では、なぜ「プロに任せたはず」が責任だけ残すのかを、

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

の順で分解します。

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

技術構成の“事実整理”：プロが増えるほど「作業は分散」するが「説明の主語」は固定される

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

まず、現場でよくある全体像を整理します。クラウド運用は、関係者が増えやすい構造です。

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

【クラウド事業者】Microsoft

・Azure / M365 / Entra ID のサービス提供（基盤）

　↓

【構築】SIer（設計・構築・移行）

・構成図、設定、初期チューニング、運用設計書

　↓

【運用】MSP（運用代行）

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

　↓

【監視】SOC（監視・一次分析）

・アラート監視、一次切り分け、報告（再委託で海外SOCが入ることも）

　↓

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

・承認、意思決定、対外説明、契約管理、最終責任

この構造のポイントは、次の2つです。

作業（オペレーション）は分業できる

説明（会社としての回答・約束）は分業しにくい

なぜなら、監査も取引先も経営も、聞きたいのは「ベンダーが何をしたか」より、結局こうだからです。

「御社は、どう管理しているのか」

「御社は、どこまで約束しているのか」

「御社は、事故時にどう動けるのか」

つまり、プロに任せるほど現場は回りやすくなる一方で、“会社としての主語”が誰なのかが曖昧なまま進むと、後から「責任だけ残る」状態になります。

ここまでは技術の話。

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

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

2. 「責任だけ残る」が起きる法務・運用の落とし穴3選

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

「プロに任せたのに、情シスだけが背負う」状態は、だいたい次の3つで発火します。

それぞれ「技術的にはOK／法務・説明としてNG」のギャップで起きます。

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

落とし穴①：「対応します」が“義務”ではなく、“可能”のまま残っている

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

導入・運用の会話でよく出る言葉があります。

24/7対応可能です

ログは提出可能です

保全できます

復旧できます

監査に耐えます

技術的にはOK：

プロが言う「可能」は、多くの場合“対応手段がある”という意味で、嘘ではありません。

法務・説明としてNG：

監査や取引先照会は「可能か」ではなく「約束（義務）か」を聞きます。

何分以内に一次通知しますか？（確約？）

何営業日以内にログを提出しますか？（確約？）

事故時の保全（削除停止・隔離）は誰がやりますか？（義務？）

その作業記録は成果物として出ますか？（証跡？）

“可能”のままだと、結局こうなります。

「じゃあ、御社としては何を約束するんですか？」

ここで会社側（情シス）が主語になり、責任だけ残ります。

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

落とし穴②：「ログは取っている」が「期限内に提出できる」に変換されていない

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

ログ周りは、最も“責任だけ残る”を起こしやすい領域です。

技術的にはOK：

SIEMに入っている

監査ログを有効化している

何かあれば調べられる

法務・説明としてNG：

監査・取引先・事故後説明で必要なのは、ログの存在ではなく“提出能力”です。

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

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

外部提出の承認者は？

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

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

この「期限・形式・承認・保全・抽出者記録」が未定義だと、

プロがいても、情シスが材料集めと社内調整の中心になり、説明負荷も責任も残ります。

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

落とし穴③：例外（暫定・除外・緊急）が“運用の空気”で増え続け、説明が壊れる

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

プロに任せていても、例外は増えます。むしろ、プロがいるから増えることもあります（進捗優先になりやすい）。

よくある例外

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

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

PIMのはずが常設に近い特権付与（作業効率）

break-glassが便利すぎて逸脱（緊急対応の常態化）

技術的にはOK：

業務は回る。障害も減る。プロジェクトは前に進む。

法務・説明としてNG：

例外は“説明の弱点”です。監査・取引先は必ずこう聞きます。

「原則は分かった。例外はどう管理している？」

誰が承認した？

期限は？解除条件は？

例外中の補償統制（監視強化など）は？

解除完了の証跡は？

ここが揃っていないと、最後に「御社として説明できない」になり、情シスに責任だけ残ります。

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

3. 「プロに任せた」を“責任だけ残さない”形に変換する整理のフレーム

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

ここからが解決策です。

ポイントは、プロに任せるのをやめることではありません。

任せた結果を“説明できる成果物”として戻ってくる構造に作り替えることです。

最低限、次の3つの軸で整理すると「責任だけ残る」を止められます。

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

整理軸①：レイヤーではなくタスクで責任分界を固定する（タスク別RACI）

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

「Microsoft／ベンダー／自社」という説明は入口には便利です。

でも事故・監査・照会で聞かれるのはタスクです。

最低限固定したいタスク（これで大半の揉め事が止まります）

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

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

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

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

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

対外説明：文面承認者

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

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

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

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

整理軸②：「言い切り」のためのパックを作る（ログ提出・保全／例外台帳／判断ログ）

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

説明責任で詰むのは、「言い切れない」からです。

言い切るための根拠をパック化します。

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

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

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

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

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

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

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

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

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

B）例外台帳（Exception Register）

例外ID（チケット番号）

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

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

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

承認者（役割）

期限（必須）

解除条件

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

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

C）判断ログ（Decision Log）

何を決めたか

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

承認者（役割）

期限と見直し条件

影響範囲

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

この3点セットがあると、

「プロに任せたから大丈夫」ではなく

「こういう体制と証跡で説明できます」

に変換できます。

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

整理軸③：委託契約（SOW）を“作業”から“説明材料の納品”へ寄せる

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

プロがいても責任だけ残る最大原因は、委託契約が「作業」中心で、説明に必要な材料が“成果物”になっていないことです。

SOWで最低限押さえたい項目

一次通知：重大度基準＋通知期限（確約の可否も明確化）

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

ログ保全協力：削除停止等＋実施記録提供（抽出者記録含む）

作業記録：実施者・時刻・内容の提供を成果物化

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

例外台帳：登録・棚卸し・解除まで作業範囲化

再委託（国外/海外SOC）：範囲と監督責任、情報移転の条件

契約終了時の出口：アクセス剥奪証明、ログ引継ぎ、削除証明など

これがあると、「任せたのに材料がない」状態が減り、情シスの説明負荷は構造的に落ちます。

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

4. ケーススタディ（匿名化）：“プロに任せた”のに照会で詰まった製造業A社

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

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

背景

業種：製造業

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

環境：Azure＋M365＋Entra ID

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

状況：障害も少なく、運用は一見安定

きっかけ

海外取引先から質問票。内容は技術ではなく“体制”でした。

インシデント時の一次通知は何分以内か

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

事故時のログ保全（削除停止）はできるか、誰がやるか

例外（暫定開放、除外）の期限管理はあるか

再委託（国外）がある場合の監督責任はどうなっているか

起きたこと

SOCは監視・一次分析は早いが、外部提出用の整形や期限確約は難しい

MSPは抽出は可能でも、外部提出・マスキング・承認支援は契約外扱い

社内では外部提出の承認者や提出形式が固まっておらず、会議が増える

例外が増えていたが台帳がなく、期限も解除条件も説明できない

最終的に「御社としての回答」を作る役が情シスに集中し、責任だけが残った

立て直し（方向性）

タスク別RACIで主語を固定（通知・保全・提出・承認）

ログ提出・保全パックを作り、提出期限・形式・承認を明確化

例外台帳で、暫定を期限付きにし、解除条件と補償統制をセット化

SOW要点を整理し、提出協力・保全協力・記録提供を義務として位置付け直す方向へ

判断ログで“推奨→会社の意思決定”の根拠を残した

結果として

「プロに任せたのに責任だけ残る」から、

「プロと分業しつつ、会社として説明できる」へ寄せられた

という流れです。

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

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

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

次のYESが多いほど、「プロに任せたはず」が責任だけ残りやすい状態です。

【主語】

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

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

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

【ログ】

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

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

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

□ 委託先が絡む提出ルートが整理されていない

【例外】

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

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

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

【契約（SOW）】

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

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

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

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

【意思決定】

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

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

□ 担当交代した瞬間に「当時の判断」が消えそう

YESが3つ以上ある場合、次の監査・照会・事故後説明で「責任だけ残る」確率は高いです。

逆に言えば、RACI／ログ提出・保全パック／例外台帳／SOW整合／判断ログの5点を揃えるだけで、構造的に改善します。

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

6. まとめ：「プロに任せた」は正しい。ただし“任せ方”を説明責任に合わせて設計しないと責任だけ残る

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

プロに任せること自体は、間違いではありません。

問題は、任せた結果が次の形で返ってきていないことです。

主語（誰がやるか）が固定されている

期限（いつまでに出せるか）が言い切れる

証跡（何を根拠に説明するか）が揃っている

例外（暫定）が期限付きで管理され、解除できる

委託が“お願い”ではなく“義務・成果物”として契約に落ちている

ここが揃わないと、プロは作業をしてくれても、説明責任（会社としての回答）は情シスに残ります。

だからこそ、任せる前提で「説明の部品」を揃えることが、情シスの負荷を本当に減らします。

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

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

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

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

「プロに任せたのに責任だけ残る」状態を、責任分界（タスク別RACI）・ログ提出/保全パック・例外台帳・判断ログ・SOW整合まで含めて整えるクラウド法務支援を行っています。

SOC/MSP/SIerがいるのに、照会・監査の回答が情シスに集中する

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

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

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

委託契約（SOW）を“説明できる成果物”中心に作り直したい

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

お問い合わせの際に「プロに任せたはずの記事を見た」と書いていただけるとスムーズです。