【クラウド法務】チェックリストがあるのに事故が起きる理由― “守るべき項目”は揃っているのに、なぜ事故は起きるのか。原因はチェック不足ではなく「運用と責任の設計不足」 ―

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

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

はじめに

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

セキュリティやクラウド運用で、よくある現場の空気があります。

「チェックリストはちゃんとある」

「監査にも通っている」

「設計書もあるし、手順書もある」

なのに、事故は起きます。

しかも、事故が起きた後に振り返ると、チェックリストには“その項目”がちゃんと書いてある。

この現象は、Azure/M365のようなクラウド運用で特に起きやすいです。

結論から言うと、チェックリストがあるのに事故が起きる理由は、チェックリストが悪いからではありません。

多くの場合、チェックリストが 「統制を成立させる最後の条件」 を満たしていないからです。

本記事では、チェックリストがあるのに事故が起きる典型パターンを、技術→法務→運用の視点で整理し、「事故りにくいチェックリスト」に変えるための考え方も示します。

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

技術構成の“事実整理”：チェックリストが得意な領域／苦手な領域

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

チェックリストが得意なのは、静的（固定）な状態の確認です。

得意な例

・NSGで不要ポートを閉じている

・条件付きアクセスでMFAを強制している

・Key Vaultを使っている

・ログをSIEMに送っている

・バックアップを設定している

・権限を最小化している（つもり）

一方、クラウド事故の多くは“動的（変化）”なところで起きます。

苦手な例

・例外が増えて恒久化する（NSG暫定開放、CA除外、常設特権）

・委託先が関与し、誰が何をするかが割れる

・障害対応・緊急変更で統制がすり抜ける

・ログはあるが保全（削除停止）できず証跡が欠ける

・夜間休日に承認が取れず、現場判断で動く

・契約（SOW）上の義務が薄く、材料が集まらない

つまり、チェックリストがあるのに事故が起きるのは、

チェックリストが「変化」「例外」「人・組織」「期限」を扱えていないときです。

（ここまでは技術の話。ここからが法務・説明責任の話です。）

事故後に問われるのは、設定の是非より

「誰が決めたのか」

「いつまでに何をしたのか」

「証跡を出せるのか」

です。チェックリストがそこまで設計していないと、事故は起きます。

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

2. チェックリストがあるのに事故が起きる“7つの理由”

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

再現性が高い原因を7つにまとめます。どれか一つでも当てはまると、チェックリストは機能していない可能性が高いです。

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

理由①：チェック項目が「存在確認」止まりで、“期限”がない

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

例

□ ログを取得している

□ バックアップを設定している

□ 監視している

これらは存在確認です。

事故で問われるのは、期限です。

・ログ提出：何営業日以内に出せる？

・一次通知：検知から何分以内？

・保全：要請から何分で削除停止？

・復旧：RTO/RPOは？

期限がないチェックリストは、事故時に役に立ちません。

「ある」ことと「間に合う」ことは別物です。

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

理由②：チェックリストが「誰の責任で実施するか（主語）」を持っていない

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

チェックリストが一番壊れるのは、委託・分業の環境です。

・SOCが見ている

・MSPが運用している

・SIerが構築した

・Microsoftが基盤を提供している

このとき、チェックリストに

「誰が実行（R）し、誰が最終責任（A）か」

がないと、事故時に止まります。

チェック項目が“やるべきこと”でも、

「誰がやるの？」で止まる。

これが、チェックリストがあるのに事故が起きる最大原因の一つです。

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

理由③：例外（暫定・除外・抜け道）がチェックの外側で増える

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

クラウド運用では例外は必ず出ます。

例外が悪いのではなく、例外が台帳＋期限＋解除条件で管理されないのが悪い。

よくある例外

・NSG暫定開放が残る

・条件付きアクセス除外が増える

・PIMの一時権限が常設化する

・移行の暫定ルートが残る

・運用端末のIPが絞れず「とりあえず許可」が増える

チェックリストが例外管理（例外台帳）を持っていないと、例外が“静かに”事故に繋がります。

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

理由④：チェックが「監査のための儀式」になり、実態と分離する

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

チェックリストが、監査や形式対応のために運用されると、こうなります。

・監査に通る書き方が優先される

・実態の運用（夜間対応、緊急変更、委託先作業）が反映されない

・チェック結果が“YES前提”で回り、異常が上がらない

・チェックしても是正が起きない（誰も責任を持たない）

チェックが“実態”から離れた瞬間、事故は起きます。

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

理由⑤：チェックの結果が「是正（直す）」に繋がらない（直す責任者がいない）

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

チェックリストは、確認するだけでは意味がありません。

「NOだったときに、誰が、いつまでに、どう直すか」が無いと、事故は起きます。

必要なのは、チェック項目の裏にある運用です。

・NOの場合の対応フロー

・是正期限

・是正責任者

・例外として残す場合の承認と期限

・再確認（閉じたか、戻したか）

チェックリストが“点検”で止まると、事故に繋がります。

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

理由⑥：チェック頻度が実態の変化速度に追いついていない

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

クラウドは変化が速いです。

設定変更、権限付与、例外追加、委託先作業…

月次チェックでは間に合わないことがあります。

・「週で変わる」環境を「月で見る」

・「日で変わる」環境を「四半期で見る」

このズレがあると、チェックリストがあっても事故は起きます。

ポイントは頻度ではなく、

**変化を検知する仕組み（アラート、変更監視、台帳更新）**があるかどうかです。

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

理由⑦：チェックリストに「事故時の動き方（初動30分）」が含まれていない

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

チェックリストは平常時の話になりがちです。

事故は非常時です。

事故で必要なのは

・指揮官（Incident Commander）

・承認者（封じ込め、対外説明）

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

・一次通知（何分以内）

・委託先への依頼（期限付き）

・タイムライン記録

です。

ここが準備されていないと、平常時のチェックが完璧でも、事故時に崩れます。

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

3. 「事故が起きにくいチェックリスト」に変える3つのコツ

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

チェックリストを捨てる必要はありません。

事故が起きにくい形に“変換”します。

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

コツ①：「存在」ではなく「期限付きの成果」に変える

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

例

× □ ログを取得している

○ □ 主要ログを〇年保持し、要請から〇営業日以内に指定形式で提出できる（抽出者記録含む）

× □ バックアップを設定している

○ □ RTO〇時間／RPO〇時間を満たす復旧手順とテスト記録がある

“出せる”“戻せる”に変えると、チェックが実務になります。

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

コツ②：各項目に「RACI」を紐づける（誰がやるのか）

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

チェック項目の横に、最低限これを付けます。

・R（実行者）

・A（最終責任者）

・期限（いつまで）

・NO時のアクション（是正／例外申請）

委託があるなら、特にここが効きます。

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

コツ③：例外台帳をチェックリストの中核にする

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

チェックリストの中心に、例外台帳の棚卸しを置きます。

・例外が増えていないか

・期限切れがないか

・延長は再承認されているか

・補償統制が実施されているか

・解除証跡が残っているか

例外は事故の芽です。芽を刈るチェックが最優先です。

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

4. ケーススタディ（匿名化）：チェックリストは完璧なのに事故が起きたA社

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

背景

・Azure＋M365運用

・監査対応のチェックリストが整備され、月次で実施

・SOCとMSPを利用し、構成図も完璧

事故

・委託先作業のための条件付きアクセス例外が増え、期限管理されず残存

・夜間に不正サインインが発生し、例外経路で侵入疑い

・ログはあったが、保全（削除停止）と提出ルートが未整備で初動が遅れた

なぜチェックリストが効かなかったか

・例外台帳がなく、例外がチェック外で増えていた（理由③）

・チェック項目が存在確認止まりで、提出期限・保全が含まれていなかった（理由①）

・委託先を含むRACIがなく、誰が止める・誰が出すが割れた（理由②）

・NOが出ても是正の責任者と期限が固定されていなかった（理由⑤）

立て直し

・例外台帳を整備（期限・承認・解除条件・補償統制）

・ログ提出と保全を「期限付き成果物」として定義

・事故対応RACI（初動30分含む）を作成し、委託契約SOWに落とし込んだ

・チェックリストを「是正が起きる形」に改修

結果

・“チェックしているのに事故る”状態から、“チェックが事故を減らす”状態へ寄せられた

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

5. いまのチェックリストが危ないか分かるチェックリスト（逆チェック）

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

あなたの組織のチェックリストが「事故を防ぐ」側にあるか、簡易に見分ける質問です。

□ 各項目に期限がある（提出・通知・保全・復旧）

□ 各項目にRACIがある（誰が実行し、誰が責任か）

□ 例外台帳の棚卸しが中心にある

□ NOが出たときの是正責任者と是正期限が決まっている

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

□ 委託先（SOC/MSP）を含めた動き方がSOWで義務化されている

□ 事故時の初動30分の動き（指揮官、保全、通知）がチェック項目に含まれている

□ チェック結果が「是正計画」に繋がり、次回レビューで閉じられる

YESが少ないほど、チェックリストは“監査の儀式”になっている可能性があります。

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

6. まとめ：チェックリストがあるのに事故が起きるのは、チェックリストが“統制”になっていないから

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

チェックリストがあるのに事故が起きる理由は、チェック不足ではなく、次が欠けていることが多いです。

・期限（間に合う形）

・主語（RACI）

・例外管理（台帳＋期限＋解除）

・是正の責任と期限

・委託契約（SOW）の裏付け

・事故時初動の型

チェックリストは、“やるべきこと”の一覧ではなく、

やったことを証明し、NOを是正し、例外を期限で潰すための仕組み

として設計されて初めて事故を減らします。

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

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

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

山崎行政書士事務所では、Azure / M365 / Entra ID 等のクラウド運用において、

チェックリストを「監査対応の書類」ではなく「事故を減らし、説明責任が通る運用」に変えるために、

責任分界（RACI）・例外台帳・ログ提出/保全・委託契約（SOW）まで含めて整理するクラウド法務支援を行っています。

・チェックリストはあるが、例外が増えて不安

・SOC/MSPが絡むと主語が割れ、事故時に止まる

・ログはあるのに提出や保全の説明ができない

・チェック結果が是正に繋がらない

・取引先・監査の質問が“体制”に寄ってきた

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

お問い合わせの際に「チェックリストがあるのに事故が起きる記事を見た」と書いていただけるとスムーズです。