【クラウド法務】セキュリティ部門と情シスの合意が、運用段階で崩れる理由― “設計では握れていたはず”が、半年後に説明不能になる。崩れる前に固定すべき主語・期限・証跡 ―

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

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

はじめに

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

セキュリティ部門と情シスが、導入時点では確かに合意していた。ゼロトラストの方針、条件付きアクセスの原則、特権はPIM、ログはSIEM集約、例外は最小限――。ところが運用が始まって数か月すると、現場ではこういう会話が増えます。

「その例外、誰が承認したんでしたっけ」

「原則は分かるけど、工場（現場）は止められない」

「監査で“体制”を聞かれたけど、どこが責任者なの？」

設計では握れていたはずなのに、運用では合意が崩れる。しかも崩れた瞬間、矢面に立つのはだいたい情シスです。

本記事では、合意が崩れる構造を技術・運用・契約（クラウド法務）の順に整理し、崩れないための“合意の固定方法”を提示します。

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

技術構成の“事実整理”：合意が「方針」止まりだと、運用で必ず主語が割れる

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

多くの企業で、セキュリティ部門と情シスが合意する対象は、だいたい次のような構成の上にあります。

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

【ID/IAM】Entra ID

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

・PIM（一時権限）／break-glass

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

　↓

【業務基盤】M365／各種SaaS／Azure

・メール／Teams／SharePoint

・業務SaaS（SSO連携）

・Azureリソース（VM/Storage/Key Vault など）

　↓

【監視・ログ】

・SIEM（Sentinel等）／Log Analytics

・SOC（監視・一次分析）

・MSP（運用代行）

　↓

【自社体制】

・セキュリティ部門（方針・統制・監査対応）

・情シス（運用・変更・窓口・対外説明の実務）

・法務／購買（契約・委託管理）

・経営（最終責任・対外説明の最終承認）

このとき、導入時の合意は“方針”としては成立します。

例：

・「原則MFA」

・「特権は常設しない」

・「ログは保存する」

・「例外は最小限」

しかし運用で実際に問われるのは、方針ではなく次の3点です。

誰が承認するのか（主語）

いつまで・どの条件で許すのか（期限・解除条件）

何を証跡として出せるのか（証跡＝ログ提出能力）

ここまでは技術の話。

ここからが運用と法務（説明責任）の話です。

合意が崩れるのは「仲が悪いから」ではなく、合意が“方針”止まりで、運用に必要な主語・期限・証跡が成果物として固定されていないからです。

その不足分を、日々の緊急対応と例外で埋め始めると、合意は自然に崩れます。

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

2. 合意が運用で崩れる「よくある理由」5選

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

ここが本題です。導入時に握れていた合意が、運用で崩れる典型パターンを5つに分解します。

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

理由①：合意の単位が「原則」だけで、例外の運用設計が無い

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

設計時は原則の合意で進みます。

しかし運用では必ず例外が発生します。

工場・現場端末は準拠判定が難しい

海外拠点の回線事情で条件付きアクセスが不安定

レガシー連携・特殊アプリでMFAが噛み合わない

緊急復旧で一時的に権限・通信を緩める必要がある

例外は悪ではありません。

崩れる原因は、例外に「期限・解除条件・承認者・補償統制」が付いていないことです。

これが無いと、例外が増えた瞬間にセキュリティ部門は「統制が崩れた」と感じ、情シスは「業務を止められない」と感じ、合意が割れます。

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

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

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

導入時は、だいたいこういう合意になります。

「Microsoftはここまで」「MSPはここまで」「情シスがここ」「セキュリティは方針」

でも運用で問われるのはタスクです。

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

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

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

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

例外延長：誰が期限を延長できるか

この“タスク主語”が決まっていないと、緊急度が上がった瞬間に窓口（情シス）へ判断が寄ります。

結果として、セキュリティ部門は「情シスが勝手に例外を作った」と見え、情シスは「決めてないのに背負わされた」と感じ、合意が崩れます。

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

理由③：PIM・条件付きアクセス・break-glassが「理念」として導入され、運用の現実（忙しさ）で逸脱する

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

導入時は理想形に合意しやすいです。

特権はPIMで一時付与

緊急用にbreak-glassを用意

条件付きアクセスで原則ブロック

ところが運用では、次の現実が来ます。

承認が遅いと復旧が遅れる

夜間休日の承認者が不在

例外対応が積もってレビューが回らない

緊急時にbreak-glassが“便利すぎる”

この状態で、運用側が「実務のために逸脱」し始めると、セキュリティ側は「統制が壊れた」と感じます。

そして運用側は「統制が現実を見ていない」と感じます。

合意が崩れるのは、この相互不信が生まれる瞬間です。

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

理由④：「ログはある」合意が、「期限内に提出できる」合意に変換されていない

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

導入時はこう合意します。

「ログはSIEMに集約」「監査ログを有効化」

しかし監査・取引先照会はこう聞きます。

何営業日以内に提出できますか？

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

外部提出の承認者は？

事故時の保全（削除停止・隔離）は誰が？

抽出者記録（いつ誰がどう取得）は残りますか？

ここが未整備だと、照会が来るたびに材料集めと承認調整が発生し、情シスが疲弊します。

疲弊すると、例外レビューや統制作業が後回しになり、さらに合意が崩れます。

これは“技術”ではなく“提出能力（Evidence Production）”の問題です。

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

理由⑤：委託（MSP/SOC）が入った瞬間、合意が「契約範囲」に引き戻される

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

導入時は「監視はSOC」「運用はMSP」「セキュリティ部門が統制」と整理できます。

しかし運用に入ると、委託先は契約モードになります。

「それは契約範囲外」

「別作業（別見積）」

「ベストエフォート」

「その形式でのログ提出は想定外」

社内は「委託している＝できるはず」と思いがちです。

この“期待”と“契約”のズレの調整役が情シスになり、疲弊→例外の恒久化→合意崩壊へ繋がります。

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

3. 法務・説明責任の地雷：合意が崩れたときに「揉め方」が重くなる3点

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

合意崩壊が厄介なのは、社内の温度差だけではありません。

外部（監査・取引先・親会社）からの質問が、崩壊を“確定”させるからです。

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

地雷①：承認の主語が曖昧で、「誰が決めたか」が説明できない

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

方針合意はあっても、例外や運用判断の承認者が残っていない。

すると事故時・監査時に、窓口（情シス）が責任者扱いされます。

この時点で、セキュリティ部門と情シスの関係は「合意」から「責任の押し付け合い」に寄りやすくなります。

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

地雷②：ログ提出・保全が“義務”として社内外に見えているのに、委託契約（SOW）で支えられていない

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

「出せるはず」「保全できるはず」が社内で約束扱いになる一方で、

委託先には提出協力・保全協力・記録提供の義務が無い（または曖昧）。

このズレは、期限付き照会が来た瞬間に露呈し、現場だけが燃えます。

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

地雷③：例外が増えたときに、統制側が“監督責任”を問われ、運用側が“現場責任”を問われる

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

例外の恒久化は、どちらの視点からも正当化が難しいです。

統制側：管理できていない（監督責任）

運用側：例外を戻せていない（現場責任）

外部の質問は、どちらにも刺さります。

ここで“証跡（例外台帳・解除証跡・判断ログ）”が無いと、議論は感情戦になりやすく、合意が戻りません。

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

4. 対策のフレーム：合意を「方針」から「運転できる成果物」に変換する3つの整理軸

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

ここから解決策です。

合意を壊さないために必要なのは、“仲良くすること”ではありません。

合意を運用に耐える成果物へ変換することです。

最低限、次の3つの整理軸を用意すると、合意は崩れにくくなります。

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

整理軸① 合意の単位を「レイヤー」ではなく「タスク」に落とす（タスク別RACI）

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

事故・監査・照会が聞くのはタスクです。

次の主語を、役割名で固定します（個人名ではなく“役割”）。

一次通知：重大度基準／何分以内／誰へ

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

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

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

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

対外説明：文面承認者

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

ポイント：

「情シスが窓口」を残しつつ、「最終承認（A）」を役割で固定すること。

これで“すり替わり”が減り、合意が戻ります。

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

整理軸② 例外を“現場の工夫”から“期限付きの管理対象”へ変える（例外台帳＋補償統制）

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

例外はゼロにできません。

だから最初から“例外は出る前提”で、管理の型を決めます。

例外台帳（最低限）

例外ID（チケット番号）

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

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

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

承認者（役割）

期限（必須）

解除条件

補償統制（例外中の守り：監視強化、範囲限定等）

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

ポイント：

例外を認める代わりに、期限と解除条件を“義務”にする。

これが、統制と運用の合意を維持する現実解です。

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

整理軸③ 「ログがある」を「期限内に提出できる」へ変換する（ログ提出・保全パック＋SOW整合）

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

合意が崩れる最大の引き金は、照会・監査での提出要求です。

だから提出能力を、最初に成果物として固定します。

ログ提出・保全パック（最低限）

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

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

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

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

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

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

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

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

さらに重要なのが、委託契約（SOW）整合です。

提出協力・保全協力・作業記録提供が“別作業”にならないよう、義務・期限・成果物に落とします。

ここが揃うと、合意は「理念」ではなく「運用で守れる約束」になります。

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

5. ケーススタディ（匿名化）：合意が崩れた会社が、崩れない形に戻した流れ

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

（実務で多い構図を匿名化しています）

業種：製造業

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

環境：M365＋Entra ID＋Azure、一部運用委託（MSP）＋監視（SOC）

導入時の合意：

原則MFA、条件付きアクセスで統制

特権はPIMで一時付与

ログはSIEM集約

例外は最小限

運用で起きたこと（半年〜1年で顕在化）

工場・現場端末向けにCA例外が増える（期限なし）

緊急対応でbreak-glassの利用が増え、説明が苦しくなる

監査で「例外の承認者」「解除証跡」「ログ提出期限」を聞かれ、回答が割れる

セキュリティ部門：統制が崩れたと感じる

情シス：業務を止めずに回すためにやっただけ、と感じる

結果、合意が“感情戦”になりかける

立て直し（方向性）

タスク別RACIで、通知・保全・提出・例外の主語を役割で固定

例外台帳を作り、既存例外に期限・解除条件・補償統制を後付け

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

重要判断はDecision Logで「採用決定」として残し、見直し条件を明記

委託SOWの要点（提出協力・保全協力・記録提供）を整理し、期待と契約のズレを減らす

結果として

「例外は悪」ではなく「例外は期限付きで管理する」合意に戻る

照会対応が“会議”から“資料と手順”へ寄る

合意が“人”ではなく“成果物”に乗り、担当交代でも崩れにくくなる

という流れになります。

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

6. 自社で確認できるチェックリスト：合意が崩れ始めているサイン

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

次のYESが増えていたら、合意は崩れ始めています（ただし今なら止められます）。

【合意の単位】

□ 合意が「原則」だけで、例外運用（期限・解除条件・補償統制）が決まっていない

□ レイヤー分界はあるが、タスク別RACIがない

□ “止める／残す／出す”の主語が割れる

【例外】

□ 条件付きアクセスの除外が増えている

□ PIMを回避した常設に近い特権が増えている

□ break-glassの利用が増えている（理由が説明しづらい）

□ 例外台帳がない／期限が付いていない／解除証跡がない

【ログ提出・保全】

□ ログはあるが、提出期限（何営業日以内）を言い切れない

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

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

【委託】

□ MSP/SOCがいるのに、提出協力・保全協力・作業記録提供が成果物になっていない

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

□ 再委託（国外/海外SOC）が絡む場合の説明材料が揃っていない

YESが3つ以上ある場合、次の監査・照会・インシデントで合意崩壊が表面化しやすいです。

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

7. まとめ：合意が崩れるのは“仲の問題”ではなく「成果物不足」の問題

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

セキュリティ部門と情シスの合意が運用で崩れるのは、よくあることです。

原因は、どちらかが正しくないからではなく、合意が“運用できる成果物”になっていないからです。

合意が原則止まりで、例外の期限・解除条件が無い

レイヤー分界はあるが、タスク主語が固定されていない

ログがあっても、提出能力（期限・形式・承認・保全）が未設計

委託の契約範囲が、社内の約束と一致していない

結果、緊急度が上がった瞬間に窓口（情シス）へ判断が寄る

合意を崩さない鍵は、3つです。

タスク別RACI、例外台帳、ログ提出・保全パック（＋SOW整合）。

合意を“人間関係”ではなく“仕組みと成果物”に載せることが、運用で崩れない最短ルートです。

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

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

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

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

セキュリティ部門と情シスの合意が運用で崩れないように、責任分界（タスク別RACI）・例外台帳・ログ提出/保全パック・委託契約（SOW）整合まで含めて整える「クラウド法務支援」を行っています。

合意したはずなのに、例外が増えて統制が崩れ始めた

“誰が承認した？”が増え、雰囲気が悪くなってきた

ログ提出期限・形式・承認が言い切れず、照会が怖い

委託（MSP/SOC）を入れたのに、説明負荷が減らない

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

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

お問い合わせの際に「合意が運用で崩れる記事を見た」と添えていただけると、論点整理がスムーズです。