【クラウド法務】情シスが“調整役”から“責任者”にすり替わる瞬間― Azure / M365 / Entra ID の導入・運用で「決めてないのに背負わされる」を構造で止める ―

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

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

はじめに

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

クラウド導入や運用委託の現場で、情シスが一番しんどいのは「仕事が多い」ことよりも、立場が勝手に変わっていくことです。

最初は調整役のつもりだった。

ベンダーと社内の間に立って、会議を回して、情報を揃えて、意思決定の材料を出す。

それなのに、いつの間にかこう扱われる瞬間があります。

「つまり、情シスが決めたってことですね？」

「情シス責任で運用していると理解しています」

「情シスが承認した例外ですよね？」

「提出期限も情シスがコミットしたと聞いています」

そして一番怖いのは、その“すり替わり”が事故が起きる前に完了していることです。

事故や監査、取引先照会のタイミングで、初めて「責任者の役」を演じさせられる。

本記事では、情シスが「調整役」から「責任者」にすり替わる瞬間を構造として分解し、

すり替わりを止めるための“説明の部品（主語・期限・証跡）”の作り方まで落とし込みます。

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

技術構成の“事実整理”：クラウドは「設定＝意思決定」が多く、窓口が責任者に見えやすい

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

Azure / M365 / Entra ID を中心にした運用は、関係者が増えます。

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

【クラウド事業者】Microsoft

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

　↓

【構築】SIer / 導入ベンダー

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

　↓

【運用】MSP（運用代行）

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

　↓

【監視】SOC

・監視、一次分析、報告（再委託で海外SOCが入る場合も）

　↓

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

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

この体制の中で、情シスが担う“調整役”は非常に重要です。

ただし、クラウド運用には次の性質があります。

設定変更が頻繁（例外・暫定・緊急が日常的に起きる）

影響が広い（ID、ネットワーク、データ、ログ、BCPが連動する）

外部から問われる（監査、親会社、取引先、規制、事故後説明）

“主語”が重要（誰が決め、誰が責任を持つか）

つまり、社内外が本当に聞きたいのは「技術が正しいか」だけではなく、こういう問いです。

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

いつまでにできるのか（期限）

何を根拠に言い切るのか（証跡）

ここまでは技術の話。

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

情シスが“調整役”から“責任者”にすり替わるのは、能力不足ではありません。

「窓口＝責任者に見える」構造と、主語・期限・証跡が成果物として未整備な状態が重なると、自然に起きます。

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

2. 情シスが“責任者”にすり替わる瞬間：現場で起きやすい5つのパターン

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

「すり替わり」は、突然の宣言ではなく、日々の会話・資料・メールの積み重ねで起きます。

特に多いパターンを5つに分解します。

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

瞬間①：「窓口＝責任者」に誤解される文言が残ったとき

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

導入・運用の会議で、よくある一言があります。

「情シスが窓口になります」

「情シスで取りまとめます」

「情シスで回答します」

「情シスで対応します」

これ自体は調整役として正しい。

しかし、監査・取引先照会・事故後説明の文脈では、こう読まれます。

情シスが責任者である

情シスが期限をコミットした

情シスが承認した

情シスが保証した

窓口宣言は便利ですが、主語が曖昧なまま文書に残ると、すり替わりの起点になります。

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

瞬間②：ベンダー推奨が、そのまま“社内決定”として引用されたとき

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

ベンダーの言葉は前に進みます。

「推奨です」

「標準です」

「ベストプラクティスです」

導入フェーズでは十分有用です。

しかし社内では、資料が回った瞬間に“決定事項の前提”になります。

後から聞かれるのはこれです。

「誰が承認した？」「なぜそれにした？」「いつ見直す？」

推奨が意思決定に変換されていないと、最後に刺さるのは情シスです。

（推奨を社内に回したのが情シスだからです）

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

瞬間③：例外（暫定・除外・緊急）が「戻す前提」のまま積み上がったとき

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

クラウド運用では例外が増えます。

条件付きアクセスの除外

NSG/Firewallの暫定開放

PIM前提なのに常設に近い権限

break-glassの運用逸脱

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

ただし、例外に次が付いていないと、説明責任が崩れます。

期限

解除条件

承認者（役割）

例外中の補償統制

解除完了証跡

これが無い状態で監査が来ると、質問はこう変わります。

「原則は分かった。例外は誰が承認している？」

この問いに対し、台帳がないと「情シスが許可した」扱いになります。

ここが、すり替わりの決定打です。

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

瞬間④：「対応可能」「24/7可能」が“約束（義務）”として社内外で固定されたとき

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

ベンダーや運用委託の説明で多い言葉です。

対応可能

24/7可能

復旧可能

ログ提出可能

保全可能

技術的には「手段はある」でも、社内外が欲しいのは「約束」です。

何分以内に一次通知？

何営業日以内にログ提出？

保全（削除停止・隔離）は誰が実行？

提出形式は？承認は？抽出者記録は？

“可能”が“義務”に誤変換された瞬間、情シスが責任者として扱われます。

なぜなら、社内でその言葉を通した（ように見える）のが情シスだからです。

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

瞬間⑤：事故・照会・監査で「止める／残す／出す」の主語が割れたとき

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

本当にすり替わるのは、緊張が上がるタイミングです。

止める：権限剥奪、通信遮断、アクセス停止

残す：ログ保全（削除停止・隔離）、証拠保全

出す：ログ提出、対外説明、報告

このとき主語が割れると、こうなります。

「窓口の情シスが決めてください」

つまり、主語が未定義の状態で緊急度が上がると、窓口が責任者にすり替わる。

これが構造です。

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

3. 法務・説明責任の地雷：すり替わった後に起きる“詰み方”

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

すり替わりが怖いのは、「やることが増える」だけではありません。

説明が通らなくなることです。典型的には次の3つで詰みます。

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

地雷①：監査・取引先照会で「誰が承認した？」に答えられない

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

推奨・標準・その場対応は、承認が残っていないと説明になりません。

「情シスが決めた」扱いになり、火消し会議が増えます。

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

地雷②：ログはあるのに「何営業日以内に出せる？」で詰む

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

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

提出形式、時刻基準、マスキング、承認、抽出者記録、保全手順まで揃って初めて「出せる」です。

この整備がないと、情シスが材料集め役に固定されます。

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

地雷③：例外が説明できず、原則設計が否定される

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

例外が台帳化されていないと、監査はこう言います。

「原則が守られていない」

ここからの立て直しは技術より、体制と記録の問題になります。

結果として、情シスが“責任者”として矢面に立ち続けます。

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

4. 対策のフレーム：情シスを“調整役”に戻すための6点セット

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

すり替わりを止める方法はシンプルです。

「窓口（調整）」と「責任（承認・約束）」を、成果物として分離すること。

おすすめの6点セットを提示します。

大改修ではなく、“薄く”入れるだけで効きます。

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

① スコープシート（1枚）：何の話をしているか固定する

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

対象：テナント／サブスク／サービス範囲

本番／開発／子会社／海外拠点を含むか

委託範囲：SOC/MSP/SIerの関与範囲

説明先：監査／取引先／親会社／経営

スコープが固定されると、窓口の発言が“全社の約束”に誤変換されにくくなります。

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

② タスク別RACI（責任分界表）1枚：レイヤーではなく“やること”で主語固定

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

最低限、次の主語を役割名で固定します。

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

封じ込め（判断者と実行者）

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

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

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

対外説明（文面承認者）

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

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

情シスは「R（実行）やC（相談）」に寄せ、Aを経営・責任部署に置く設計が重要です（会社ごとに最適は変わります）。

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

③ Decision Log（判断ログ）：推奨を“社内決定”に変換して残す

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

“誰が決めた？”を無くす最短手です。短くてOKです。

決定内容（設定・運用方針）

理由（代替案も一言）

承認者（役割）

期限／見直し条件

影響範囲

根拠（ベンダー資料名、規程名、要件名など。リンク不要）

「推奨」→「採用決定」に変換し、主語を固定します。

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

④ 例外台帳（Exception Register）：暫定を恒久化させない

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

例外ID（チケット）

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

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

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

承認者（役割）

期限（必須）

解除条件

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

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

これがあると「情シスが勝手に許した」扱いを止められます。

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

⑤ ログ提出・保全パック： “ログがある”を“期限内に出せる”に変換する

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

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

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

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

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

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

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

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

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

「窓口の情シスが出す」ではなく、「会社としてこの手順で出す」に変換します。

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

⑥ SOW整合：お願いを“義務・期限・成果物”にする

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

委託が絡む部分は、契約が弱いと最後に情シスが埋めます。

最低限、次を明確化（確約できないなら“できない”を明確化）します。

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

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

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

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

特権アクセス統制（期限・承認・剥奪証跡）

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

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

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

ここまで揃うと、調整役の情シスに“責任者の役”が落ちてきにくくなります。

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

5. ケーススタディ（匿名化）：調整役だった情シスが、照会で“責任者”にされかけたA社

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

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

業種：製造業

拠点：日本＋海外

環境：Azure＋M365＋Entra ID

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

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

取引先照会で「ログ提出は何営業日以内？」が来た

社内では過去の会議資料に「提出可能」「対応可能」があり、約束扱いになっていた

例外（CA除外、暫定開放）が増えていたが台帳がなく、承認者・期限が説明できない

事故時の保全（削除停止）を誰がやるかが曖昧で、窓口の情シスに判断が寄った

結果として、情シスが“調整役”ではなく“責任者”として扱われ始めた

立て直しの方向性（実務で効くやり方）

RACIで「承認（A）」を役割として固定し、窓口と責任者を分離

Decision Logで、推奨を採用した意思決定に“承認者・期限・根拠”を付け直した

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

ログ提出・保全パックで、提出期限・形式・承認・抽出者記録を決めた

SOW要点を整理し、提出協力・保全協力・記録提供を義務として明確化する方向へ寄せた

結果として

「情シスが決めた」扱いになりかけた状態から、

「会社としてこう決めている（主語がある）」状態へ戻せた、という流れです。

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

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

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

“調整役→責任者”のすり替わりが進んでいるか、次で点検できます。

YESが多いほど要注意です（ただし、今なら止められます）。

【窓口の誤変換】

□ 「情シスが回答します」「情シスで対応します」が文書に残っている

□ 回答や対外文書の承認者（役割）が曖昧

□ 窓口と承認者の区別が資料上できていない

【意思決定の不在】

□ ベンダー推奨が“社内決定”として引用されている

□ 重要設定（ログ保持、例外、権限、復旧）にDecision Logがない

□ “当時の判断”が特定個人の記憶に依存している

【例外の恒久化】

□ CA除外、暫定開放、常設権限が増えている

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

□ 例外台帳がない／更新されていない

【ログ提出・保全】

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

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

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

□ 委託先が絡む提出ルートが曖昧

【責任分界】

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

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

□ 事故時に「窓口の情シスが決める」空気になりそう

YESが3つ以上ある場合、次の照会・監査・インシデントで「責任者の役」が情シスに落ちる可能性が高いです。

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

7. まとめ：すり替わりの本質は「窓口の言葉が、約束として固定される」こと

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

情シスが“調整役”から“責任者”にすり替わるのは、能力の問題ではありません。

次の条件が揃うと、構造的に起きます。

窓口（調整）が会社の主語に見える

推奨・可能が約束（義務）として固定される

例外が台帳化されず、承認者と期限が消える

ログが存在しても提出能力が未設計

タスク別の主語（RACI）がない

契約（SOW）が説明材料の成果物になっていない

止め方は「窓口と責任を分離し、主語・期限・証跡を成果物化する」こと。

それができれば、情シスは“責任者の代役”から抜けられます。

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

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

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

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

情シスが「調整役のまま」運用を回せるように、責任分界（タスク別RACI）・Decision Log・例外台帳・ログ提出/保全パック・SOW整合まで含めた「クラウド法務支援」を行っています。

窓口の情シスが、いつの間にか責任者扱いされ始めた

「誰が承認した？」に答えられる形で決定を残したい

例外（除外・暫定）が増え、期限と解除条件が消えている

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

委託先を含めて、説明できる体制に整えたい

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

お問い合わせの際に「調整役から責任者にすり替わる記事を見た」とお伝えいただけると、論点整理がスムーズです。