【クラウド法務】サービス導入時に、情シスだけが“決めた覚えのない決定”を背負う構図― 技術は動いているのに、監査・取引先・経営の前で「誰が決めた？」が情シスに刺さる理由 ―

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

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

はじめに

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

サービス導入は順調。PoCも成功。移行も予定通り。運用委託もついている。

なのに、いざ監査・取引先照会・経営説明の場でこう聞かれて、情シスだけが黙ってしまう瞬間があります。

「その運用方針、誰が決めたの？」

「例外（除外・暫定開放）を許したのは誰？」

「ログは何営業日以内に出せると約束しているの？」

「委託先に任せている範囲は、契約上どこまで？」

情シスとしては正直こう思う。

“決めた覚えはない。必要だから、進めるために、そうなっただけ”

でも外から見ると、導入された以上「誰かが決めた決定」が存在し、その説明責任が会社に発生します。

そして多くの組織では、その矢面に立たされるのが情シスです。

本記事では、サービス導入時に情シスだけが“決めた覚えのない決定”を背負う構図を、技術→法務→運用の順で分解し、二度と同じ構図を作らないための整理フレームを提示します。

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

技術構成の“事実整理”：決定は「会議」ではなく“導入の流れ”の中で勝手に確定していく

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

サービス導入（クラウド・SaaS・IDaaS・SIEM・EDR等）で、意思決定が明確に行われるのは「稟議のとき」だと思われがちです。

しかし現実は違います。決定の多くは、導入の流れの中で“静かに確定”します。

（典型的な導入の流れ：テキスト図）

要件整理（ざっくり）

　↓

ベンダー提案（構成と見積が中心）

　↓

PoC（動けば勝ち／例外OK／その場で直す）

　↓

本番設計（構成は固まるが、主語は未固定になりがち）

　↓

移行（暫定・例外が増える）

　↓

運用開始（契約と体制だけが残る）

　↓

監査・取引先照会・事故対応（“誰が決めた？”が発生）

この流れの中で、会議で明示的に決めた覚えがないのに、実務上は決まってしまう“決定”がたくさんあります。たとえばこうです。

・ログ保持期間（90日でいい？ 1年？ 7年？）

・ログ提出能力（何営業日以内／形式／承認）

・例外運用（条件付きアクセス除外、NSG暫定開放、常設特権など）

・委託先がやる範囲（一次通知、保全、提出、記録提供）

・復旧の約束（SLAとRTO/RPOの混同）

・データの扱い（越境、再委託、目的外利用、削除・返却）

そして問題は、こうした決定が「構成図」や「手順書」には残っても、

“誰が・なぜ・どんな前提で決めたか（主語と根拠）”が残りにくいことです。

ここまでは技術の話。

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

情シスだけが背負う構図は、技術が悪いのではなく、

決定が「意思決定」として管理されず、“設定”として固定されてしまうことで生まれます。

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

2. 情シスが“決めた覚えのない決定”を背負う原因（よくある地雷5選）

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

「決めた覚えがない」のに背負う。

この矛盾は、だいたい次の5つで説明できます。

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

地雷①：ベンダーの“推奨”が、社内では“決裁済み”として扱われる

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

導入中、よく出る言葉があります。

「推奨です」「標準です」「ベストプラクティスです」

導入フェーズでは便利な言葉です。

しかし後で必ずこう問われます。

・なぜその設定を採用した？

・代替案は検討した？

・どのリスクを受容した？

・いつ見直す？（期限と条件は？）

推奨は“材料”であって、意思決定ではありません。

意思決定が残っていないと、最終的に「情シスが決めたこと」になってしまいます。

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

地雷②：PoCの“その場対応”が、本番の“約束”に誤変換される

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

PoCは「動けば勝ち」です。例外も許されます。

でも本番は「義務として回る」が前提です。

PoCで成立してしまうこと

・例外設定（除外・暫定開放）

・広めの権限付与（作業優先）

・ログ抽出の即対応（その場でお願い）

・緊急対応の同席（関係性で回る）

本番で問われること

・誰の承認で例外にした？期限は？解除条件は？

・権限付与の承認フローは？棚卸しは？

・ログ提出は何営業日以内に義務としてできる？

・保全（削除停止・隔離）は誰がやる？

PoCの空気を本番に持ち込むと、決定が宙に浮き、最終的に情シスが背負います。

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

地雷③：「できる」と「義務としてやる」が混ざり、言葉が約束に変わる

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

導入中の資料や会議で、よく出る言葉があります。

・対応可能

・24/7対応可能

・ログ提出可能

・復旧可能

・監査に耐える

これらは“前向きな表現”ですが、取引先照会や監査では「約束」として扱われます。

そして約束の主語が曖昧だと、最後に情シスが抱える形になります。

重要なのは、言い切りには必ず「前提条件・期限・成果物」が必要だということです。

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

地雷④：責任分界がレイヤー（Microsoft／ベンダー／自社）で止まり、タスクの主語が決まっていない

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

レイヤー分界は分かった気になれます。

しかし揉めるのはタスク分界です。

・一次通知（何分以内、誰が誰へ）

・封じ込め（権限剥奪、通信遮断：誰が判断し誰が実行）

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

・ログ提出（期限・形式・承認・提出者）

・対外説明（文面承認者）

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

タスクの主語が決まっていないと、後で「情シスが全部決めた（ことになる）」が起きます。

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

地雷⑤：SOW（作業範囲）に“必要な成果物”が落ちていない

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

導入後に説明責任が問題になる場面で必要なのは、構成図よりも「説明の部品」です。

しかしSOWが構成物中心だと、必要な部品が成果物になりません。

成果物にしないと消えるもの（例）

・ログ提出の形式・期限を満たす提出物

・保全操作の実施記録（いつ誰が何をしたか）

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

・例外台帳（期限・解除条件・解除完了証跡）

・判断ログ（なぜそうしたか、誰が承認したか）

成果物にない＝義務ではない、になりやすい。

義務でなければ、いざという時に材料が集まらず、情シスが背負います。

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

3. 整理のフレーム：“決めた覚えのない決定”を作らない3つの整理軸

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

ここからが解決の話です。

ポイントは、「決定を増やす」ことではありません。

決定を“見える化”し、主語と期限と根拠を固定することです。

最低限、次の3つを揃えると、情シスだけが背負う構図が崩れます。

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

整理軸① 決定の棚卸し（Decision Inventory）を作る

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

導入の途中で、決定がどんどん増えます。

増えること自体は悪ではありません。悪いのは「決定が決定として管理されない」ことです。

棚卸しの対象（例）

・ログ保持期間（標準・例外）

・ログ提出（期限・形式・承認）

・例外運用（どの例外を許すか）

・権限運用（PIM、break-glass、委託先特権）

・BCP（RTO/RPO目標、テストの頻度）

・委託範囲（SOC/MSP/SIerがどこまで義務か）

・越境・再委託・データ削除（説明が必要な論点）

「決定項目一覧」があるだけで、後から“決めた覚えがない”が激減します。

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

整理軸② 判断ログ（Decision Log）で「主語」と「前提」を固定する

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

決定項目があっても、主語が残らないと結局情シスが背負います。

そこで必要なのが判断ログです。短くて構いません。

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

・何を決めたか（決定内容）

・なぜそうしたか（理由／代替案を一言）

・承認者（役割名で）

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

・影響範囲（どのシステム・拠点・データが対象か）

・根拠（参照した資料・ログ・規程・契約など）

「当時の判断」が思い出だと、担当交代・監査・事故後説明で必ず詰みます。

判断ログがあると、「情シスが勝手に決めた」になりにくいです。

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

整理軸③ タスク別RACI＋SOWで“義務”として固定する

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

主語は「会議」で決めても、契約に落ちないと実務で動きません。

そこで、タスク別RACI（責任分界）を作り、SOWに落とします。

最低限固定したいタスク

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

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

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

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

・対外説明（文面承認者）

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

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

ここをSOWの成果物・義務・期限に落とすと、

「そこはベンダーがやると思っていた／契約外です」が減ります。

そして情シスが“背負わされる”構図も減ります。

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

4. ケーススタディ（匿名化）：製造業A社で「決めた覚えがない」が監査で顕在化した例

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

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

背景

・業種：製造業

・拠点：日本＋海外

・環境：Azure＋M365＋Entra ID

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

・導入：PoC成功→段階展開で順調

監査で刺さった質問

・ログ提出は何営業日以内に可能か（形式と承認は？）

・例外（条件付きアクセス除外、暫定開放）は期限管理されているか

・委託先の特権アクセスはどう統制しているか（剥奪証跡は？）

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

当時の状況

・ログは集約していたが「提出期限・形式・承認」が決まっていない

・例外は増えていたが、台帳がなく期限が追えない

・PoC中にベンダー推奨で決めた設定が多く、判断の主語が残っていない

・委託先の作業記録が成果物になっておらず、材料がすぐ集まらない

結果

・技術は動いているのに、説明が通らず会議が増え、回答が遅れた

・最終的に「情シスが決めたこと」として扱われそうになった

立て直し（方向性）

・決定棚卸し（Decision Inventory）を作成し、決定事項を一覧化

・判断ログ（Decision Log）で、承認者（役割）・前提・見直し条件を残す

・例外台帳を整備し、期限と解除条件、補償統制を明確化

・ログ提出・保全パックを作成（期限・形式・承認・抽出者記録・保全手順）

・SOWを見直し、通知・提出協力・保全協力・記録提供を義務化する方向へ

結果として

・「誰が決めた？」に対して、主語と根拠で説明できるようになり

・“決めた覚えがない決定”を情シスが背負う構図から脱却できた

という流れです。

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

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

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

次の項目で、YESが多いほど“決めた覚えのない決定”が情シスに集まりやすい状態です。

【決定の管理】

□ 導入中に決めたことの一覧（Decision Inventory）がない

□ 「推奨」「標準」で進んだ設定が多く、判断の主語が残っていない

□ 重要な決定に、期限（見直し時期）と見直し条件が付いていない

【主語（責任分界）】

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

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

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

【ログ（提出・保全）】

□ 「ログはある」が「何営業日以内に提出できる」に変換されていない

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

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

【例外（暫定・除外）】

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

□ 例外台帳がない／期限・解除条件・補償統制がない

□ 「忙しいから後で」が恒久化している

【委託・契約（SOW）】

□ 委託先の一次通知・提出協力・保全協力が期限付きで義務化されていない

□ 作業記録（実施者・時刻・内容）の提供が成果物になっていない

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

「YESが3つ以上」ある場合、次の監査・照会・事故で“決めた覚えのない決定”が情シスに刺さる可能性が高いです。

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

6. まとめ：情シスが背負うのは“技術”ではなく「主語のない決定」

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

サービス導入時に、情シスだけが“決めた覚えのない決定”を背負うのは、よくあることです。

それは情シスのせいではありません。

・決定が、会議ではなく導入の流れの中で静かに確定する

・推奨が意思決定にすり替わる

・PoCの空気が本番の約束に誤変換される

・レイヤー分界で止まり、タスクの主語が決まらない

・SOWに成果物が落ちず、証跡が集まらない

この構造を崩すために必要なのは、次の3点です。

決定の棚卸し（Decision Inventory）

判断ログ（Decision Log）で主語・前提・期限を残す

タスク別RACI＋SOWで義務・期限・成果物を固定する

これが揃うと、導入が順調なだけでなく、

監査・取引先・経営の前でも「決めた覚えがない」を言語化・整理した上で説明できる状態になります。

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

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

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

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

サービス導入時に情シスだけが“決めた覚えのない決定”を背負わないよう、責任分界（タスク別RACI）・判断ログ（Decision Log）・例外台帳・ログ提出/保全パック・SOW整合まで含めて整える「クラウド法務支援」を行っています。

・導入は進んでいるが、後から説明できる自信がない

・ベンダー推奨で進んだ決定の主語を整理したい

・例外（暫定・除外）が恒久化しそうで不安

・ログ提出期限や保全操作の主語が曖昧

・委託先の“お願い運用”をSOWで義務化したい

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

お問い合わせの際に「決めた覚えのない決定の記事を見た」と書いていただけるとスムーズです。