【クラウド法務】「部門間合意」が書類だけで終わると起きること― Azure / M365 / Entra ID / 各種SaaS運用で、“合意したはず”が半年後に説明不能になる理由と、崩れない合意の作り方 ―

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

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

はじめに

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

「部門間で合意しました」

ゼロトラスト方針、例外の扱い、ログの取り方、委託範囲…。書類も作った。会議もした。承認も通った。

それなのに運用が始まると、現場でこういう言葉が増えていきます。

「それ、誰が承認したんでしたっけ」

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

「ログはあるけど、期限内に出せるの？」

「契約上はベストエフォートなので…」

「合意書には書いてあるけど、手順がない」

“合意した”のに、運用で詰まる。

この現象は、仲が悪いから起きるのではありません。合意が「書類」で止まり、運用に変換されていないとき、構造として起きます。

本記事では、部門間合意が書類だけで終わると何が起きるのかを、技術・運用・クラウド法務（契約／説明責任）の順に整理し、崩れない合意の作り方まで落とし込みます。

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

技術構成の“事実整理”：クラウド運用は「設定＝意思決定」が多く、合意が“手順化”されないと必ずズレる

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

部門間合意が問題になりやすいのは、Azure / M365 / Entra ID のように「設定変更が日常」「影響が広い」「外部から問われる」領域です。典型的な構造は次の通りです。

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

【ID/IAM】Entra ID

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

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

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

　↓

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

・メール／Teams／SharePoint

・業務SaaS（SSO連携）

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

　↓

【ログ・監視】

・Activity / Resource Logs / M365監査ログ

・Log Analytics / SIEM（Sentinel等）

・SOC（監視）／MSP（運用代行）

　↓

【社内体制】

・情シス（運用・変更・窓口）

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

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

・事業部（業務継続・例外要求）

・経営（最終責任・最終承認）

この世界で運用が詰むのは、技術の“正しさ”そのものよりも、次の3点が揃っていないときです。

主語：誰が承認し、誰が実行し、誰が最終責任を持つのか

期限：いつまでに、何営業日以内に、何分以内に、どの条件で

証跡：何を根拠として出せるのか（ログ提出、保全、例外、作業記録）

ここまでは技術の話。

ここからがクラウド法務（説明責任）の話です。

部門間合意が「書類」だけで終わると、運用で必要な主語・期限・証跡が固定されず、日々の例外対応と緊急対応で“空白を埋める”ことになります。

その空白埋めが続くと、合意は自然に崩れます。

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

2. 「書類だけの部門間合意」で起きること：現場が詰む典型パターン5選

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

ここが本題です。合意書があるのに運用で詰むとき、起きている現象はだいたい次の5つです。

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

起きること①：「原則だけ合意」になり、例外が増えた瞬間に合意が無効化される

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

合意書にはこう書かれます。

「原則MFA」「原則PIM」「例外は最小限」「原則ログ取得」

運用では必ずこうなります。

工場端末や特殊端末で条件付きアクセスが通らない

海外拠点の回線事情でMFAが不安定

レガシー連携で例外除外が必要

緊急復旧で一時的に権限強化が必要

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

問題は、例外に「期限・解除条件・承認者・補償統制（例外中の守り）」が付いていないことです。

例外が台帳化されていないと、半年後にこうなります。

セキュリティ部門：「統制が崩れた」

情シス：「業務を止められないから仕方ない」

事業部：「いつまで例外？誰が許可？」

合意は“書類上の原則”として残り、現場では別ルールが走り出します。

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

起きること②：責任分界が「レイヤー」止まりで、事故時に“止める／残す／出す”の主語が割れる

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

よくある合意はこうです。

「Microsoftはここまで」「ベンダーはここまで」「自社はここから」

しかし運用・監査で問われるのはタスクです。

止める：権限剥奪、通信遮断、アクセス停止（誰が判断し、誰が実行？）

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

出す：ログ提出、対外報告（誰の承認で、誰が提出？期限は？）

タスクの主語が決まっていないと、緊急度が上がった瞬間に「窓口＝情シス」に判断が寄ります。

結果として、合意していたはずの“統制の責任”も“対外説明”も情シスが抱え込み、部門間合意は実質的に崩れます。

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

起きること③：「ログは取る」合意のまま、提出能力（期限・形式・承認・保全）が未整備で照会に耐えない

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

導入時はこう握れます。

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

でも取引先や監査が聞くのはこうです。

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

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

外部提出の承認者は？

事故時に削除停止・隔離できますか？誰がやりますか？

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

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

ここが未設計だと、照会のたびに材料集めと承認調整が発生し、情シスが疲弊→例外レビューが後回し→統制が崩れる、という悪循環に入ります。

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

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

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

部門間で合意していても、外部委託が絡むと現実はこうなります。

「それは契約範囲外です」

「別作業（別見積）です」

「ベストエフォートです」

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

社内は「委託している＝できるはず」と期待します。

しかし契約が支えていないと、運用の穴埋めは自社側（ほぼ情シス）でやるしかありません。

この瞬間、合意は「紙の上では正しいが、実務では回らない」状態になります。

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

起きること⑤：合意の“更新サイクル”がなく、担当交代・構成変更で合意が自然死する

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

合意書は作った直後が一番新しい。

でも運用は変化します。

組織改編、担当交代

追加SaaS導入、拠点追加、海外展開

セキュリティ強化（CAポリシー増、PIM導入拡大）

監査要求の増加、取引先の質問票の高度化

事故対応の経験値が増える

更新ルール（いつ見直す／誰が改訂する／どこに保管する）がないと、合意は“存在しているのに参照されない文書”になります。

そして参照されない合意は、実質的に無いのと同じです。

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

3. 法務・説明責任の地雷：書類合意が「対外説明」に変換されないと、最後に揉めるポイント

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

書類だけの合意が危険なのは、社内調整で止まらないからです。

監査・親会社・取引先照会が入ると、次の3点で一気に揉めます。

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

地雷①：「誰が承認した？」が答えられず、責任が窓口に集まる

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

合意書があっても、例外や緊急対応の承認記録がないと、外部はこう判断します。

「統制が個人依存」「統制が曖昧」

そして窓口の情シスが“実質責任者”扱いになります。

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

地雷②：「何営業日以内に出せる？」が言えず、ログが“あるのに使えない”扱いになる

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

提出期限・形式・承認・保全手順が未確定だと、ログの存在価値が対外的に減ります。

照会対応が遅れ、説明の信頼が落ち、合意そのものが疑われます。

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

地雷③：「例外が管理されていない」と見なされ、原則設計が否定される

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

例外が増えるのは自然です。

しかし期限管理・解除証跡がないと、監査では「原則が守られていない」と見なされやすい。

この時点で、技術の正しさでは評価されず、体制と記録の問題になります。

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

4. 対策のフレーム：部門間合意を“書類”から“運転できる成果物”に変換する3つの整理軸

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

ここからが解決策です。

必要なのは、合意書を増やすことではありません。合意を運用に耐える成果物へ変換することです。

最低限、次の3軸を揃えると、合意は崩れにくくなります。

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

整理軸① 合意を「タスク別RACI」に落とす（レイヤーではなく“やること”で主語を固定）

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

事故・監査・照会が聞くのはタスクです。主語を役割名で固定します（個人名ではなく役割）。

最低限固定したいタスク

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

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

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

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

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

対外説明：文面承認者（経営承認ライン含む）

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

ポイント：

「情シスが窓口」でも良い。ただし「最終承認（A）」を役割で固定し、窓口＝責任者へのすり替わりを止めます。

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

整理軸② 例外を“期限付きの管理対象”にする（例外台帳＋補償統制）

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

例外は出ます。だから最初から管理の型を決めます。

例外台帳（最低限）

例外ID（チケット番号）

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

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

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

承認者（役割）

期限（必須）

解除条件

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

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

「例外を許す＝統制崩壊」ではありません。

「例外を期限付きで管理する＝運用に耐える統制」です。

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

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

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

照会で詰まらないための“提出能力”を成果物化します。

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

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

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

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

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

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

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

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

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

さらに、重要な判断（例外承認、運用方針、提出期限の確定など）はDecision Log（判断ログ）で残します。

決定内容

理由（代替案も一言）

承認者（役割）

見直し期限／条件

根拠（資料名でOK）

これで「合意したはず」が、実務で再現できる状態に寄ります。

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

5. ケーススタディ（匿名化）：書類合意はあるのに、運用で合意が崩れた製造業A社

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

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

業種：製造業

拠点：日本＋海外

環境：Azure＋M365＋Entra ID

体制：構築SIer→フェーズアウト、運用MSP＋監視SOC（再委託あり）

導入時合意（書類あり）：

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

特権はPIMで一時付与

ログはSIEM集約

例外は最小限

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

工場向け例外が増え、期限なしで残った

緊急時にbreak-glass利用が増えたが、理由と承認が追えない

取引先照会で「ログ提出は何営業日以内？」に答えが割れた

ベンダーは「その提出形式は別作業」「保全操作は契約外」と回答

セキュリティ部門は「統制が崩れた」、情シスは「業務を止められない」で対立

立て直し（方向性）

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

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

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

重要判断をDecision Log化し、見直し条件を明記

必要に応じて委託範囲（SOW）と“提出協力・保全協力・作業記録提供”の整合を検討

結果として

合意が「紙」ではなく「運用で回る手順」として復活

照会対応が会議ではなく資料と手順で回る

例外が増えても説明が崩れにくい

という状態に寄せられます。

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

6. 自社で確認できるチェックリスト：「書類合意」で終わっていないか

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

次のYESが増えているほど、部門間合意は“書類だけ”になっている可能性が高いです。

【主語】

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

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

□ 窓口（情シス）が責任者扱いされ始めている

【例外】

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

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

□ break-glassの利用が増えている

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

【ログ提出・保全】

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

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

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

【委託】

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

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

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

【更新】

□ 合意文書の改訂責任者と改訂タイミングが決まっていない

□ 担当交代後、合意文書が参照されなくなっている

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

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

7. まとめ：「部門間合意」は書類で終わると、運用で必ず“空白”が埋められて崩れる

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

部門間合意が書類だけで終わると、次が起きます。

原則合意のまま例外が増え、統制と業務継続が衝突する

タスク主語が未定義で、緊急時に窓口へ責任が寄る

ログはあるのに提出できず、照会対応で疲弊する

委託が契約範囲に戻り、社内の約束とのズレを情シスが埋める

更新サイクルがなく、合意が自然死する

止め方はシンプルです。

合意を「運転できる成果物」に変換すること。

タスク別RACI（主語を役割で固定）

例外台帳（期限付きで管理）

ログ提出・保全パック＋Decision Log（証跡と判断を固定）

この3点を置くだけで、「合意したのに詰まる」確率は大きく下がります。

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

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

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

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

部門間合意が“書類だけ”で終わらないように、責任分界（タスク別RACI）・例外台帳・ログ提出/保全パック・Decision Log・委託範囲（SOW）整合まで含めて整える「クラウド法務支援」を行っています。

合意文書はあるのに、運用で説明が崩れ始めた

例外（暫定・除外）が増え、期限と承認が追えない

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

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

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

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

お問い合わせの際に「部門間合意が書類だけで終わる記事を見た」と添えていただけると、論点整理がスムーズです。