【クラウド法務】“この設定、誰が決めたんだっけ”が増え始めたら要注意― Azure / M365 / Entra ID の運用で「技術は正しいのに説明が崩れる」最初のサインと、崩れる前に打てる手 ―

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

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

はじめに

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

クラウド運用が回り始めると、現場でよく聞くセリフがあります。

「この設定、誰が決めたんだっけ？」

「当時の判断、理由わかる人いる？」

「ベンダー推奨だった気がするけど、承認って取ってた？」

最初は軽い確認のつもりでも、これが増え始めたら要注意です。

なぜなら、このセリフが増えるタイミングは、技術的な失敗より先に、説明責任の崩壊（＝“後から説明できない状態”）が始まっていることが多いからです。

監査・親会社・取引先の質問が「設定の妥当性」ではなく「決め方（体制）」に寄ってくる

事故が起きたとき、技術の正しさより「誰が判断したか」を問われる

担当者が変わると、意思決定の主語が消えて“情シスが全部決めた”ことにされそうになる

本記事では、

「“誰が決めた？”が増える理由 → どの設定で起きやすいか → 法務・監査での地雷 → 崩れないための整理フレーム」

を、実務で再現できる形でまとめます。

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

技術構成の“事実整理”：クラウドは「設定＝意思決定」が多すぎて、放置すると“判断負債”になる

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

Azure / M365 / Entra ID を中心とした運用では、システムの安全性・可用性・利便性が、ほぼ「設定」によって決まります。

そしてこの“設定”は、実態として「意思決定」です。

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

【ID/IAM】Entra ID

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

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

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

　↓

【クラウド】Azure / M365

・ネットワーク（VNet/NSG/Firewall/WAF）

・権限（RBAC/管理者ロール/委託先アクセス）

・データ（Storage/Key Vault/暗号化/共有）

・BCP（Backup/Site Recovery）

　↓

【ログ・監視】

・Activity / Resource Logs / M365監査ログ

・Log Analytics / SIEM（Sentinel等）

・SOC/MSP（委託）

　↓

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

この環境で、日々増える「設定上の意思決定」を例にすると、こんなものがあります。

条件付きアクセス：例外（除外）を入れる／外す

NSG/Firewall：暫定開放する／戻す

RBAC：誰にどのロールを付与する／期限をつける

PIM：承認フローをどうする／緊急時の運用はどうする

Key Vault：誰が所有者か／期限切れをどう防ぐか

ログ：何を取るか／どこに集約するか／保持期間は何年か

バックアップ：RPO/RTO目標はどう置くか／復旧テスト頻度はどうするか

ここで重要なのは、これらの多くが「正解が一つ」ではないことです。

つまり、後から問われるのは「設定の正しさ」だけではなく、次の3点になります。

なぜその設定にしたのか（理由）

誰が承認したのか（主語）

いつ見直すのか（期限・条件）

ここまでは技術の話。

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

“この設定、誰が決めた？”が増えるのは、技術が壊れているからではなく、

設定（意思決定）が増えたのに、意思決定として管理されていない＝判断負債が積み上がっている状態だからです。

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

2. よくある“法務・責任”の落とし穴：「誰が決めた？」が増える組織で起きている3つのギャップ

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

“誰が決めた？”が増える組織では、だいたい次の3つのギャップが同時に起きています。

（技術的には成立しているのに、説明として破綻するポイントです）

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

落とし穴①：ベンダー推奨・PoCの判断が「会社の意思決定」として残っていない

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

技術的にはOK：

推奨（ベストプラクティス）で実装した

PoCで動いたから本番採用した

急ぎで暫定対応した

法務・説明としてNG：

“推奨”は材料であって、意思決定ではない

PoCの「その場対応」は、本番の「義務・体制」とは別

承認者・リスク受容・見直し条件が記録に残っていない

この状態だと、監査・取引先照会で必ずこう聞かれます。

「推奨は分かった。御社として、誰が承認し、どのリスクを受けたのか？」

ここで“決めた人が消えている”と、情シスが矢面に立ちます。

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

落とし穴②：例外（暫定・除外・緊急）が“戻す前提”のまま恒久化し、説明が壊れる

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

技術的にはOK：

暫定開放・除外で業務を止めない

影響が出たら戻すつもり

便利だから運用で吸収している

法務・説明としてNG：

期限がない

解除条件がない

承認者が曖昧

例外中の補償統制（監視強化など）が言えない

“いつ戻すか”が誰も答えられない

この状態だと、説明の焦点が「原則」から「例外」へ移った瞬間に詰みます。

そして例外は、半年・1年で必ず積もります。

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

落とし穴③：「ログはある」のに「期限内に提出できる」が言い切れず、材料集めが発生する

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

技術的にはOK：

SIEMにログを集約している

監査ログも取っている

調べれば分かる

法務・説明としてNG：

何営業日以内に提出できるかが言えない

提出形式（項目、時刻基準、マスキング）が決まっていない

外部提出の承認者（役割）が決まっていない

事故時の保全（削除停止・隔離）と抽出者記録が弱い

委託先（SOC/MSP）が絡むと「契約外」「別作業」「ベストエフォート」になる

結果、情シスが「材料集め担当」に固定され、仕事が増え続けます。

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

3. クラウド法務としての「整理のフレーム」：“誰が決めた？”を減らすのは、設定を減らすことではない

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

ここからが解決パートです。

“誰が決めた？”を減らすために必要なのは、設定を減らすことではありません。

設定（意思決定）に「主語・期限・根拠」を付けて、会社として説明できる状態にすることです。

最低限、次の3つを紙に落とすだけで、運用と説明が一気に安定します。

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

整理軸① Decision Log（判断ログ）で「意思決定」を成果物にする

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

“誰が決めた？”が増える最大の原因は、意思決定が人の頭にしかないことです。

短くていいので、必ず残します。

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

決定内容：何を決めたか（設定・運用方針）

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

承認者：役割名（個人名でなくてOK）

期限：いつ見直すか／見直し条件は何か

影響範囲：対象システム・拠点・データ

根拠：参照資料（提案、監査要件、規程、台帳など）

ポイント：

「設定変更チケットのコメント」では弱いです。

“説明できる形”で一枚に集約することが重要です。

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

整理軸② タスク別RACIで、事故・監査が聞く「主語」を固定する

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

レイヤー分界（Microsoft／ベンダー／自社）だけだと、事故や監査で必ず主語が割れます。

“やること”で主語を固定します。

最低限固定したいタスク

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

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

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

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

対外説明：文面承認者

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

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

ポイント：

A（最終責任）は“個人名”ではなく“役割名”で固定します。

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

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

整理軸③ 例外台帳＋証跡パックで「例外」と「出せるログ」をセットで管理する

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

“誰が決めた？”が増える現場は、例外と証跡の管理が弱いことが多いです。

だから、ここは型で揃えます。

A）例外台帳（Exception Register）

例外ID（チケット番号）

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

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

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

承認者（役割）

期限（必須）

解除条件

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

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

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

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

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

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

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

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

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

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

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

この2つが揃うと、

「例外は増えるが、説明は崩れない」状態に近づきます。

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

4. ケーススタディ（匿名化）：製造業A社で“誰が決めた？”が増え始めたときに起きていたこと

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

実際にご相談が多い構図を、匿名化して紹介します。

業種：製造業

売上規模：数百億規模

拠点：日本＋海外

環境：Azure＋M365＋Entra ID

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

現象（半年〜1年で顕在化）

条件付きアクセスの除外が増えた（当時の理由は分かるが、承認者と期限が曖昧）

NSGの暫定開放が残っている（戻す担当が不明）

委託先の特権アクセスが増えてきた（棚卸しと剥奪の証跡が弱い）

監査・親会社から「誰が承認した？」「いつ見直す？」が増えた

社内会議で“誰が決めた？”が頻発し、決め直しの会議が増えた

当事務所でよく行う整理（抜粋）

構成図と運用実態を前提に、タスク別RACIを1枚にする（通知・保全・提出・例外）

例外台帳を起点に、既存例外へ期限・解除条件・補償統制を後付けする

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

“推奨で進んだ設定”をDecision Logに変換し、主語と根拠を残す

必要に応じて、委託契約（SOW）の「提出協力・保全協力・作業記録提供」等の明確化を検討する

結果として多い変化

会議で“誰が決めた？”が出ても、判断ログを見れば終わる

例外はゼロにならないが、「期限付き」で回るため説明が崩れにくい

照会や監査で、同じストーリーで答えられるようになる

情シスが“材料集め役”から“統制の運転手”に戻れる

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

5. 自社で検討するときのチェックリスト

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

“誰が決めた？”が増え始めたら、次の項目を点検してください。

YESが多いほど、説明崩壊が始まっています（ただし今なら止められます）。

【意思決定】

□ ベンダー推奨で進んだ設定の「承認者（役割）」が言えない

□ 設定変更の理由がチケットやチャットに散らばっている

□ “当時の判断”を説明できる人が特定の個人に偏っている

□ 見直し期限（いつ再評価するか）が付いていない決定が多い

【例外】

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

□ NSG/Firewallの暫定開放が残っている

□ PIM前提なのに、常設に近い特権が増えている

□ 例外に「期限・解除条件・承認者・補償統制」が付いていない

□ “暫定”が台帳に載っていない

【ログ・証跡】

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

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

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

□ 委託先（SOC/MSP）が絡む提出ルートが整理されていない

【主語（責任分界）】

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

□ 一次通知・封じ込め・保全・提出・対外説明の主語が割れる

□ “止める／残す／出す”が事故時に会議になりそう

YESが3つ以上ある場合、

“この設定、誰が決めた？”はこの先も増え、監査・照会・事故時に一気に負荷になります。

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

6. まとめ：“誰が決めた？”は、技術トラブルより先に出る「説明崩壊のアラート」

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

“この設定、誰が決めたんだっけ”が増え始めたら、要注意です。

それは「技術の問題」というより、次の状態を示すアラートだからです。

設定＝意思決定が増え、判断負債が積み上がっている

例外が増え、原則と実態がズレ始めている

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

主語（責任分界）が曖昧で、説明が情シスに寄っていく

止め方はシンプルです。

設定を減らすのではなく、意思決定に「主語・期限・根拠」を付けて成果物にする。

Decision Log（判断ログ）

タスク別RACI（責任分界）

例外台帳＋ログ提出・保全パック（証跡の型）

これだけで、“誰が決めた？”が会議にならず、説明が安定しやすくなります。

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

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

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

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

「“誰が決めた？”が増えて説明が崩れそう」な状態を、責任分界（タスク別RACI）・例外台帳・ログ提出/保全パック・判断ログまで含めて整える「クラウド法務支援」を行っています。

例外（除外・暫定）が増えてきて、戻し方と期限が決まっていない

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

ベンダーはフェーズアウトしたが、当時の判断が残っていない

監査や取引先照会に、同じストーリーで答えられる状態にしたい

委託先を含めて、説明できる運用体制にしたい

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

お問い合わせの際に「“誰が決めた？”の記事を見た」とお伝えいただけると、論点整理がスムーズです。