【クラウド法務】担当者が変わった瞬間に、責任の所在が消える構造― “引き継いだのは環境であって、責任ではない”状態が起きる会社の共通点 ―

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

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

はじめに

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

クラウド運用（Azure / M365 / Entra ID 等）で、事故や監査より先に組織を詰ませる出来事があります。

それが「担当者交代」です。

担当者が異動・退職した翌月から、会議の空気が変わる。

技術的には動いているのに、質問が来た瞬間に説明が止まる。

「この例外は誰が承認したんだっけ？」

「委託先が触る範囲、契約上どうなってる？」

「ログ提出って、何営業日以内に出せる？」

「事故のとき、誰が止める判断をする？」

新担当は、環境を引き継いだだけで、意思決定の“主語”を引き継いでいない。

そして周囲（監査・親会社・取引先・経営）は、“会社として説明できるはず”という前提で質問してくる。

このギャップが、責任の所在が消える瞬間です。

本記事では、担当者交代で責任の所在が消える構造を、

「技術的な整理 → 法務の地雷 → 対策フレーム → 事例 → チェックリスト」

の順で整理します。

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

技術構成の“事実整理”：責任が消えるのは「設定」ではなく「意思決定」が引き継がれないから

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

担当者交代で起きるのは「知識の欠落」だけではありません。

本質は、クラウド運用の“意思決定”が、設定や設計書ではなく「人の頭の中」に残っていることです。

典型的な構成（テキスト図）

【ID/IAM】Entra ID

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

・PIM（特権の一時付与）

・Break-glass（緊急アカウント）

　↓

【Azure】

・Subscription / RG

・VNet / Subnet / NSG / Firewall / WAF

・VM / PaaS / Storage / Key Vault

・Backup / Site Recovery（BCP）

　↓

【ログ・証跡】

・Sign-in / Audit / Activity / Resource logs

・Log Analytics / Sentinel / SIEM

　↓

【運用体制】

・自社 情シス／CSIRT／法務／経営

・SIer（構築）

・MSP（運用代行）

・SOC（監視）＋再委託（海外SOCが入ることも）

ここで“責任が消える”場所は、だいたい決まっています。

設定項目そのものではなく、その裏にある「なぜこうしたのか」「誰が決めたのか」です。

責任が消えやすい領域（例）

・条件付きアクセスの例外（除外ユーザー／除外条件）

　→ 例外を出した理由と、期限と、戻し方が消える

・NSG/Firewallの暫定開放

　→ “暫定”の終了条件と承認者が消える

・特権アクセス（常設権限の残存、委託先権限）

　→ 誰が「常設を許した」のかが消える

・ログ設定（保持期間、提出形式、保全手順）

　→ “ある”は言えるが、“出せる”と“保全できる”が消える

・委託（MSP/SOC）の作業範囲

　→ 「やってくれるはず」が、契約上の義務かどうかが消える

つまり、担当者交代で失われるのは「Azureの操作方法」ではなく、

**運用の意思決定（責任の主語・期限・証跡）**です。

ここまでは技術の話。

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

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

2. よくある“法務・説明責任”の地雷：担当者が変わると一気に露出する3つの穴

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

担当者交代そのものは、どの会社でも起きます。

問題は、交代によって“説明責任の穴”が可視化されることです。特に地雷になりやすいのは次の3つです。

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

地雷①：リスク受容（承認）の証跡がない

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

監査・取引先・経営が本当に聞いているのは、「設定の正しさ」ではなく

**“会社としてそのリスクを誰が受けたのか”**です。

ところが多くの現場では、例外や暫定がこう処理されます。

・チャットで「一旦除外してOK？」→「OK」

・会議で「とりあえず開けよう」

・チケットはあるが、承認者・期限・補償統制が残らない

担当者が居るうちは「当時こういう事情で…」で説明が通ります。

担当者が変わった瞬間、説明が消えます。

この時点で、例外は“技術的対応”ではなく“統制不備”として扱われやすくなります。

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

地雷②：委託先の動きが「空気」に依存していて、契約（SOW）に落ちていない

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

担当者が変わると、委託運用が一番揺れます。

なぜなら、旧担当は委託先と“阿吽の呼吸”で回していたことが多いからです。

よくあるズレ

・旧担当：お願いすればやってくれる（関係がある）

・新担当：契約上の義務は何か？期限は？成果物は？が分からない

・委託先：契約外はできない／優先対応は別料金／提出形式は要相談

結果、事故対応・監査対応の場面で

「できると思っていたことが、義務として担保されていない」

が露呈します。

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

地雷③：「ログはある」けど、「提出・保全の責任者」がいない

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

担当者交代で詰む典型質問がこれです。

「そのログ、何営業日以内に提出できますか？」

「事故時に削除停止（保全）できますか？誰がやりますか？」

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

ログがSIEMに集約されていても、

・提出期限

・提出形式

・承認者

・保全手順

・抽出者記録

が設計されていないと、説明できません。

そして“説明できない”は、技術課題ではなくガバナンス課題として評価されます。

担当者交代は、その評価が一気に露出するタイミングです。

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

3. 対策のフレーム：責任の所在を「人」から「役割＋成果物」に移す

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

担当者が変わっても責任が消えない組織は、何をしているのか。

答えはシンプルで、責任を“人”に持たせず、役割（Role）と成果物（Artifact）に持たせています。

ここでは、最短で効く3つの整理軸を提示します。

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

整理軸①：責任分界は「レイヤー」ではなく「タスク別RACI」で固定する

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

担当者交代で消えるのは、「誰が何をするか」です。

だから、タスク別にRACI（R=実行 / A=最終責任 / C=相談 / I=共有）を作ります。

最低限入れるタスク（事故対応まで）

・一次通知（検知から何分以内に誰へ）

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

・ログ保全（削除停止、隔離、抽出者記録：着手条件と担当）

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

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

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

・委託先管理（再委託・国外関与、特権アクセス統制）

ポイント

「A（最終責任者）」を“個人名”ではなく“役割名”で置く。

担当者が変わっても、役割は残ります。

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

整理軸②：例外・暫定を「台帳＋期限＋解除条件」で制度化する

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

担当者交代で一番爆発するのが例外です。

例外はゼロにできません。だから“管理できる例外”にします。

例外台帳（最小項目）

・例外ID（チケット番号）

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

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

・理由（業務要件／障害対応／移行措置／ベンダー作業）

・申請者／承認者（役割でOK）

・期限（必須）

・解除条件（何が終われば戻すか）

・補償統制（例外中の守り：監視強化、送信元限定、時間帯制限等）

・次回レビュー日（棚卸し日）

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

ポイント

「暫定」は設定ではなく“終了計画つきのタスク”として扱う。

終了予定日がない暫定は、必ず恒久化します。

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

整理軸③：「証跡パック」を作って“提出・保全ができる会社”にする

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

担当者が変わっても説明が通る会社は、ログを「ある」ではなく「出せる」にしています。

そのための最小セットが証跡パックです。

証跡パック（最小セット）

・対象ログ一覧（何を：Sign-in/Audit/Activity/Resource等）

・保持期間（どれだけ：標準・延長・例外）

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

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

・承認者（誰の承認で外部提出できるか）

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

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

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

ポイント

証跡パックは「監査用の説明」ではなく「事故時に動くための資料」に寄せる。

監査資料と事故資料は分け、橋渡しだけ作ると運用が崩れにくいです。

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

4. さらに効く：担当者交代で崩れない「引き継ぎパック」

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

担当者交代が避けられないなら、“交代前提の成果物”を最初から用意します。

おすすめは「引き継ぎパック」を定義してしまうことです。

引き継ぎパック（最小セット）

システム概要1枚（対象範囲、重要度、委託関係）

タスク別RACI 1枚（事故対応まで）

例外台帳（現時点の例外一覧と期限）

証跡パック（提出・保全の型）

委託契約の要点（SOWの対応範囲、期限、成果物、再委託）

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

変更管理のルール（承認、緊急変更の事後追認）

これがあると、担当者が変わっても責任の所在が消えにくくなります。

「頭の中にある暗黙知」を、役割と成果物に移すからです。

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

5. ケーススタディ（匿名化）：担当者交代で“例外の承認者”が消えたA社

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

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

背景

・製造業A社（国内＋海外拠点）

・M365/Entra IDでゼロトラスト運用を推進

・監視はSOC、運用はMSP、構築はSIer

・条件付きアクセスでMFAを強制し、例外は「移行期間だけ」の想定

担当者交代で起きたこと

・旧担当が異動し、新担当へ引き継ぎ

・数ヶ月後、取引先審査で「CA例外の管理方法」を要求

・例外（除外ユーザー、除外条件）が増えていたが、期限・承認者・解除条件が追えない

・MSP/SOCに聞いても「契約上はベストエフォート」「形式は要相談」で、提出物が固まらない

・社内会議で「誰が承認したのか」が割れ、説明が崩れた

立て直しでやったこと（方向性）

・タスク別RACIを作成（一次通知、封じ込め、保全、提出、対外説明まで）

・例外台帳を整備し、既存例外に期限と解除条件を後付け（延長は再承認へ）

・例外中の補償統制（監視強化、送信元限定、時間帯制限）をセット化

・証跡パックを整備し、ログ提出の期限・形式・承認者を固定

・委託契約（SOW）に、一次通知・提出期限・保全協力・台帳更新を義務として落とす

結果

・担当者が変わっても「誰が決めたか」「誰がやるか」「いつまでに出せるか」を説明できる状態に戻り、取引先審査の質疑が収束

・“技術は動くが説明できない”状態から脱却できた

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

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

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

担当者が変わった瞬間に責任の所在が消える組織かどうかは、次で判定できます。

【主語（責任）】

□ 事故対応まで含めたタスク別RACIが1枚である（個人名ではなく役割名）

□ 「止める判断」「保全」「提出」「対外説明」のA（最終責任者）が明確

□ SOC/MSP/SIerが絡んでも、主語が割れない

【例外・暫定】

□ 条件付きアクセスの例外（除外）が台帳で管理され、期限がある

□ NSG/Firewallの暫定開放が台帳化され、解除条件がある

□ 例外延長は再承認（理由更新＋補償統制の再確認）

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

【提出・保全】

□ ログは「ある」ではなく「何営業日以内に出せる」が言える

□ 提出形式（項目・時刻基準・マスキング）が固定されている

□ 抽出者記録（いつ誰がどう取得したか）を残せる

□ 事故時のログ保全（削除停止・隔離）の手順と責任者がある

【委託契約（SOW）】

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

□ 台帳更新・棚卸し・解除までが委託範囲に含まれている

□ 再委託（国外・海外SOC）がある場合、範囲と監督責任が説明できる

【引き継ぎ】

□ 引き継ぎパック（RACI、例外台帳、証跡パック、SOW要点）が定義されている

□ 担当者が変わっても、1週間で説明できる状態に戻せる

YESが少ない場合、責任は“人に張り付いたまま”で、担当者交代のたびに説明が崩れる可能性が高いです。

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

7. まとめ：責任の所在が消えるのは、責任が「人の記憶」に置かれているから

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

担当者交代で責任の所在が消えるのは、引き継ぎが雑だからではありません。

責任が「役割と成果物」ではなく「個人の記憶と関係性」に置かれている構造だからです。

崩れないための最短ルートは、次の3つです。

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

・例外台帳（期限・解除条件・補償統制で恒久化を止める）

・証跡パック（提出・保全の能力を固定）

＋ 委託契約（SOW）で義務化

＋ 引き継ぎパックで交代前提にする

これが揃うと、クラウド運用は「動いている」だけでなく「説明できる」運用になります。

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

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

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

山崎行政書士事務所では、Azure / M365 / Entra ID 等の技術構成と、契約・規程・監査対応をセットで整理し、担当者交代があっても責任の所在が消えない形（RACI・例外台帳・証跡パック・SOW整備）に落とし込む「クラウド法務支援」を行っています。

・担当者が変わるたびに、例外や暫定の説明が崩れる

・SOC/MSP/再委託が絡むと主語が割れてしまう

・ログはあるのに提出期限・形式・承認者が固まっていない

・委託契約（SOW）に、通知・提出・保全協力・台帳更新を落としたい

・監査・取引先に“一貫したストーリー”で説明できる状態にしたい

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

お問い合わせの際に「担当者交代で責任が消える記事を見た」と書いていただけるとスムーズです。