【クラウド法務】クラウドは動いているのに、説明が通らなくなったときに起きている5つの兆候― 技術は正しい。でも社内外の“質問”に答えられない。いま起きているのは「統制の断線」です ―

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

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

はじめに

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

クラウド（Azure / M365 など）を導入すると、構築も運用も“動く”ところまでは到達できます。監視も入れた。ログも取っている。バックアップも設定した。IDもMFAにした。それでも、ある日突然「説明が通らない」瞬間が来ます。

・監査に「証跡は？」と聞かれて、何を出せば良いか分からない・取引先のセキュリティチェックで、回答が部門ごとに割れる・障害や不正アクセス疑いで、復旧より先に“責任者探し”が始まる・顧問もSIerもいるのに、説明が一本化できない

この状態は、技術の失敗ではありません。**“説明責任を成立させる成果物（責任分界・証跡・契約義務）が揃っていない”**ことが原因で、クラウド運用が「統制として」断線している状態です。

本記事では、クラウドは動いているのに説明が通らなくなったときに現れる「5つの兆候」を整理し、いま何を整えるべきかの軸を提示します。

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

1. まず前提：クラウドは“責任が減る”のではなく“責任が増える

   ”────────────────────────────

オンプレは「自社の機械を自社で運用」なので、責任の主語が単純でした。クラウドは違います。主語が増えます。

・クラウド事業者（Microsoft）・利用者（自社：情シス／事業／CSIRT／法務／広報）・委託先（SIer／MSP／SOC／SIEM運用）・サードパーティ（Marketplace、SaaS、監視製品等）・再委託（下請け、海外SOC等が入るケース）

そしてクラウドの失敗は、技術的に「落ちる」より先に、**“説明が割れる／証拠が出ない／約束が言えない”**で表面化します。

（ここからが本題です。）

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

2. クラウドは動いているのに説明が通らなくなったときの「5つの兆候」────────────────────────────

以下の兆候が1つでも出ていたら、クラウドの“統制の断線”が始まっています。放置すると、事故・監査・取引先照会のどこかで確実に詰まります。

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

兆候①：「SLAは説明できる」のに「RTO/RPO（復旧の約束）」が言えない────────────────────────────

現場で起きること・「AzureのSLAがあるので大丈夫です」とは言える・でも「何時間で復旧しますか？」「どこまで戻せますか？」に答えが止まる・BCP資料がオンプレ時代のまま／クラウドの現実と噛み合っていない

説明が通らなくなる理由SLA（稼働率）と、RTO/RPO（復旧の約束）は別物です。取引先・監査・経営が聞きたいのは「あなたのサービスが戻るか」です。クラウドのSLAを説明しても、復旧の筋道がないと“回答になりません”。

放置すると起きること・取引先審査で落ちる（または条件付きになる）・事故時に復旧判断が遅れる（誰がBCP発動するか決まっていない）・「バックアップはあるのに復旧できない／間に合わない」状態が露呈する

最小の対処（今日からできる）・重要システムごとに「RTO/RPO」「復旧優先順位」を決める・復旧手順（誰が・どの順で・どこに復旧）を文章化・復旧テストを計画化し、テスト記録を“監査証跡”として残す

欠けている成果物・RTO/RPO一覧（重要度付き）・復旧手順書・復旧テスト記録（いつ誰が何をしたか）

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

兆候②：「ログは取っているはず」なのに、監査・取引先に“期限内に提出できない”

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

現場で起きること・Azure Monitor / Log Analytics / SIEM などで可視化はできている・でも監査で「この期間の操作ログを提出して」と言われると、抽出が遅い／揃わない・保持期間が短い（例：90日）まま運用していて、必要期間が残っていない・ログは委託先が持っていて「別料金」「時間がかかる」になる

説明が通らなくなる理由説明責任で問われるのは「ログが見えるか」ではなく、**“提出できるか（提出能力）”**です。提出能力には、保持期間・抽出手順・承認者・期限・形式が必要です。

放置すると起きること・監査で統制不備扱い（「証跡が出ない」は致命的）・事故調査で影響範囲が確定できず、対外説明が遅れる・委託先との契約トラブル（「契約外」「有償」）で初動が鈍る

最小の対処・「証跡パック（提出物）」を定義する（対象ログ、保持、提出期限、形式）・ログの保全手順（削除停止・隔離・抽出者記録）を決める・委託があるなら「ログ提出義務・期限・形式・保全協力」を契約別紙に入れる

欠けている成果物・ログ一覧（何をどこに何日/何年保持）・提出手順（誰が何営業日以内に出すか）・事故時保全手順（リーガルホールド相当）

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

兆候③：例外運用が増え、「なぜそれが残っているのか」説明できない────────────────────────────

現場で起きること（典型）・NSGで一時的に広く開けたルールが残っている・条件付きアクセスの除外が増え、期限がない・Break-glassアカウントはあるが、運用が属人化している・PIM（特権）を導入したのに、例外が常設化している・Key Vaultの秘密情報（Secrets/Keys/Certificates）が棚卸しされておらず、期限切れが怖い

説明が通らなくなる理由例外は「技術の現実」ですが、説明責任の世界では例外＝統制の穴として扱われます。例外を許すなら「理由」「承認」「期限」「補償統制」「解除計画」が必要です。これがないと、事故・監査で“意図”が説明できません。

放置すると起きること・事故後に「なぜ開けた」「なぜ除外した」が説明できず二次炎上・委託先や現場判断が積み上がり、いつの間にか設計思想が崩壊・「最小権限」「ゼロトラスト」と言っているのに実態が伴わず信頼が落ちる

最小の対処・例外台帳（レジスター）を作る（NSG/CA/PIM/緊急運用など）・例外は必ず期限を持たせ、期限切れで棚卸し・例外中の補償統制（監視強化、送信元限定、JIT化等）をセット化

欠けている成果物・例外台帳（理由・承認・期限・解除計画・補償統制）・棚卸しルール（毎月/四半期）・緊急運用の規程（事後追認の期限）

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

兆候④：事故が起きたとき「Microsoft？委託先？自社？」で指揮命令が割れる────────────────────────────

現場で起きること・障害や侵害疑いで、まず「誰の責任か」会議が始まる・委託先は「監視はするが復旧は別」・自社は「復旧まで含むと思っていた」・経営は「クラウド事業者が何とかするのでは？」・法務は「ログはすぐ出る前提」で話していた

説明が通らなくなる理由責任共有の環境で、責任分界が“レイヤー議論”のままだと必ず割れます。必要なのは、事故対応を含めた「タスク別の責任分界（RACI）」です。

放置すると起きること・初動が遅れる（封じ込め・保全・一次報告が遅れる）・対外説明が割れる（営業／情シス／法務／委託先で言うことが違う）・委託先の協力が得られず、証跡が揃わない

最小の対処・タスク別RACIを作る（一次通知、封じ込め、保全、ログ提出、復旧、報告書）・委託先の作業範囲をSOWで固定（“やる／やらない”を明文化）・事故時の一次報告テンプレと承認者（誰が文章を出すか）を決める

欠けている成果物・タスク別RACI（事故対応まで）・委託契約別紙（通知・提出・保全協力・復旧支援範囲）・一次報告テンプレ（社内・取引先）

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

兆候⑤：データの所在・越境・再委託を聞かれると、説明が“雰囲気”になる────────────────────────────

現場で起きること・「データは国内ですか？」に、リージョンだけ答えて終わる・ログや監視が委託先SOCに流れているが、海外関与が説明できない・CDN/キャッシュで「どこに何が残るか」が答えられない・SaaSやMarketplace製品が増え、どの契約が支配しているか分からない・目的外利用（学習利用等）の懸念を問われ、判断材料がない

説明が通らなくなる理由クラウドは「データが動く」ことが前提です。そして説明責任で問われるのは、どこに／誰が／どの目的で／どの契約の下でアクセスできるかです。ここが整理されていないと、取引先審査や親会社統制で止まります。

放置すると起きること・海外取引・大手取引先の審査で追加要求（条項・証跡・体制）を受ける・事故時に「誰がアクセスしたか」の範囲特定が遅れる・再委託が見えず、委託管理不備として評価が落ちる

最小の対処・データフロー図（データ種別・保存場所・アクセス主体・委託/再委託）を作る・委託先・再委託先の範囲と義務（守秘、提出、保全、目的外利用禁止等）を契約で貫通させる・CDNやログ基盤など“データが残る場所”の削除・保全手順を決める

欠けている成果物・データフロー図（越境・委託含む）・再委託の範囲特定と同等義務の貫通・削除・保全・提出の運用ルール

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

3. 兆候が出たら、まず作るべき「3枚の紙」────────────────────────────

上の兆候は、個別対処すると永遠に終わりません。最短で“説明が通る状態”に戻すには、まずこの3つを作るのが効きます。

（1）タスク別RACI（事故対応まで含める）・ID／ネットワーク／ログ／BCP／インシデント／委託管理・R（実行）A（最終責任）C（相談）I（共有）

（2）証跡パック（提出物セット）・ログ一覧（保持期間）・ログ提出手順（期限・形式・承認）・復旧テスト記録・特権アクセス台帳・例外台帳

（3）委託契約別紙（SOW）と規程への落とし込み・一次通知・ログ提出義務（期限・形式）・保全協力・特権アクセス統制（個人アカウント、期限、承認、操作ログ、剥奪証明）・再委託（国外含む）の条件

この3枚があると、「説明の主語」が割れなくなり、必要な材料が集まります。

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

4. ケーススタディ（匿名化）：技術は動くのに説明で詰まった企業がやったこと────────────────────────────

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

・Azure移行は完了し、監視もSIEMも導入済み

・運用はMSP/SOCに一部委託・取引先からBCPと証跡提出の照会が来て、回答が割れた　→ SLAは説明できるがRTO/RPOの根拠がない　→ ログはあるが提出期限が決まっておらず遅い　→ 条件付きアクセス例外とNSG暫定開放が台帳なしで残っている

そこで、追加の製品導入より先に

・タスク別RACI

・証跡パック

・委託契約別紙（通知・提出

・保全協力

・特権統制）を整備し、復旧テストと例外棚卸しを“運用として回す”形に変更しました。

結果として

・取引先照会に対して「いつまでに何を出すか」が言える

・事故時も「誰が動くか」が割れず、初動が速くなる

・監査で“統制の証拠”が出せるという状態に近づきました。

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

5. 今すぐ確認できるチェックリスト（兆候の自己診断）────────────────────────────

□ SLAとRTO/RPOを切り分けて説明できる

□ 重要システムの復旧手順書と復旧テスト記録がある

□ ログは「保持期間」「提出期限」「形式」「担当」まで決まっている

□ 事故時の保全手順（削除停止・隔離・抽出者記録）がある

□ 例外運用（NSG/条件付きアクセス/PIM/緊急運用）が台帳化され、期限がある

□ 特権アクセスは個人アカウントで統制され、剥奪証明ができる

□ Microsoft／自社／委託先のタスク別RACIが1枚である

□ 委託先に一次通知・ログ提出・保全協力の義務が契約で入っている

□ 再委託（国外含む）の範囲特定と同等義務の貫通が説明できる

□ データの所在（キャッシュ/ログ含む）をデータフローで説明できる

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

6. まとめ：説明が通らないのは「運用の劣化」ではなく「設計の未完」────────────────────────────

クラウドが動いているのに説明が通らなくなったとき、起きているのは「担当者の頑張り不足」ではありません。説明責任を成立させる設計（責任分界・証跡・契約義務）が未完なだけです。

兆候が出た段階で、RACI／証跡パック／契約別紙（SOW）を整えると、クラウドは「動く」から「説明できる」に変わります。

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

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

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

山崎行政書士事務所では、Azureを含むクラウド導入・運用において、技術構成（ID、ログ、BCP、委託運用）と、契約・規程・監査対応をセットで整理する「クラウド法務支援」を行っています。

・クラウドは動いているが、監査・取引先に説明が通らない

・委託先が絡み、責任分界と証跡が割れている・ログ提出

・保全・特権アクセス統制を契約別紙に落としたい

・例外運用を台帳化して恒久化を止めたい

・RTO/RPOと復旧テスト記録を“根拠”として整えたい

といった課題があれば、オンライン（全国対応）でご相談を承っております。お問い合わせの際に「説明が通らなくなった兆候の記事を見た」と書いていただけるとスムーズです。