【クラウド法務】事故後説明で“技術の正しさ”が評価されない理由― 「設定は正しかった」は免罪符にならない。評価されるのは“統制・証跡・意思決定” ―

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

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

はじめに

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

事故が起きたあと、情シスやセキュリティ担当が最初に言いたくなる言葉があります。

「設計はベストプラクティスに沿っていた」

「設定は正しかった（つもり）」

「SLAもあるし、クラウド側は問題ない」

技術者としては当然の感覚です。

“正しい”ことが重要で、正しく作ってきた自負があるからです。

ところが事故後の説明の場（取引先、親会社、監査、経営、場合によっては当局・弁護士対応）では、空気が変わります。

技術的に正しい話をしているのに、評価されない。むしろ質問がこう寄ってきます。

「誰が、いつ、何を決めたのか」

「どの証跡で、影響範囲を言い切れるのか」

「ログは保全できているのか（改ざん・欠落はないか）」

「通知や提出は、契約どおり期限内にできるのか」

「再発防止は“運用として”回るのか」

ここで詰まると、技術が正しくても「説明が通らない」状態になります。

本記事では、なぜ事故後説明で“技術の正しさ”が評価されにくいのかを、構造として整理します。

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

技術構成の“事実整理”：事故後に問われるのは「構成」ではなく「行動の記録」

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

クラウド（Azure / M365 / Entra ID）環境の典型構成は、多くの企業で似ています。

（ざっくり全体像：テキスト図）

【ID/IAM】Entra ID

・条件付きアクセス、MFA、PIM、監査ログ

　↓

【Azure/M365】

・VNet / 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含む）

事故前の会話は、ここ（構成）を中心に進みます。

「WAFを入れている」「ゼロトラスト」「ログはSIEMに集約」「バックアップもある」など。

しかし事故後の会話は、構成よりも次の3つに集中します。

いつ何が起き、誰が何をしたか（タイムライン）

その主張を支える証跡は何か（ログ・記録・真正性）

その判断は誰が責任を持って決めたか（主語・承認）

つまり、事故後は「正しい構成だったか」より、

**“正しく動けたか”と“それを証明できるか”**が問われます。

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

事故後説明は、技術レビュー会ではありません。

「技術の評価」よりも、「説明責任（責任の所在・約束・証拠）」の評価に寄ります。

だから“技術の正しさ”は、そのままでは評価されません。

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

2. 事故後説明で“技術の正しさ”が評価されない理由（8つ）

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

ここから本題です。技術的に正しくても評価されにくい理由は、ほぼ次の8つに集約できます。

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

理由①：相手の目的が「技術の優劣」ではなく「責任と再発可能性の確認」だから

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

事故後に説明を求める側（取引先・親会社・監査・経営）が知りたいのは、ざっくり言うと次の3点です。

・被害（影響範囲）はどこまでか

・同じことが再発しないと言える根拠は何か

・今後、安心して取引・運用を続けられる体制か

これは技術の点数ではなく、統制の点数です。

技術が正しくても、体制・証跡・意思決定が弱いと「再発しそう」と見えます。

その時点で評価は厳しくなります。

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

理由②：「正しい」と言っても、証跡（ログ・記録）がなければ“主張”でしかない

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

事故後は、言い切りが重要になります。

そして言い切りには根拠が必要です。

・侵害はなかった → 何のログで確認したのか

・データ流出はない → どの証跡で判断したのか

・影響は限定的 → どこまでを“影響”と定義したのか

技術者の感覚では「この設定なら大丈夫」でも、事故後説明では通用しません。

証跡がなければ、相手から見ると「信じてください」に見えます。

“技術の正しさ”が評価されない最大理由がここです。

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

理由③：事故時は“正しい運用”より“正しい初動”が評価される

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

事故後の評価で効くのは、設計の美しさより 初動の正確さ です。

特に最初の30分で、次が決まっているか。

・止める（封じ込め）：何を止める／誰が判断する

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

・出す（説明）：第一報、更新時刻、証跡提出の段取り

事故後説明の場では、

「当初30分で何を決め、何を実行し、何を残したか」

が強い評価軸になります。

構成が正しくても、初動が遅い・記録がないと評価されません。

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

理由④：「SLAがある」は復旧の約束（RTO/RPO）の説明にならない

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

技術者が言いがちな説明が「SLAがあるので大丈夫」です。

しかし事故後は、稼働率の話（SLA）より、次が問われます。

・いつ復旧するのか（RTO）

・どこまで戻るのか（RPO）

・根拠は何か（手順、テスト記録、体制）

SLAはクラウド側の約束でも、復旧は自社の設計・運用・判断に左右されます。

ここを混ぜると、説明は信用されにくくなります。

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

理由⑤：委託・再委託が絡むと「技術の正しさ」より「義務の所在」が問われる

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

SOC、MSP、SIer、再委託（国外・海外SOC含む）。

関係者が増えるほど、事故後説明の質問はこうなります。

「誰が何をする義務なのか」

「ログ提出は何営業日以内に“義務として”できるのか」

「保全操作は誰がやるのか」

ここで「お願いすればやってくれる」「いつもやっている」は弱いです。

求められるのは、契約（特にSOW）で担保された義務・期限・成果物です。

技術が正しくても、義務の線引きが曖昧だと評価されません。

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

理由⑥：例外・暫定・抜け道があると、設計の正しさは相殺される

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

事故後に強く問われるのは、設計図より“現実の運用”です。

・条件付きアクセスの除外が増えていた

・NSGの暫定開放が戻っていない

・常設特権が残っていた

・break-glassが日常運用に混ざっていた

これらがあると、たとえ原則設計が正しくても、評価は落ちます。

相手はこう見るからです。

「正しい設計があっても、例外が管理されていない＝統制が崩れている」

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

理由⑦：説明に必要なのは“正しさ”ではなく“意思決定の主語”

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

事故後は、必ず「誰が決めたのか」を聞かれます。

・封じ込め判断（止める/止めない）は誰が決めた

・対外説明の文面は誰が承認した

・例外を延長したのは誰が承認した

・ログ提出の範囲は誰が決めた

“技術的に正しい”より、

意思決定が適切な権限者によって行われたかが問われます。

ここが弱いと、技術の話は評価されません。

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

理由⑧：「再発防止」が技術対策だけだと、運用として回らないと見なされる

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

事故後の再発防止で、技術者は対策を盛りがちです。

WAF強化、ポリシー追加、ログ増量、EDR増設…。

でも相手が見ているのは、

「それを継続的に運用できる体制か」

です。

・例外は期限管理されるか

・権限棚卸しは誰がいつやるか

・委託先の作業は証跡が残るか

・変更は承認と記録が残るか

“運用の型”がない再発防止は、継続しないと見られます。

このとき技術の正しさは評価されにくいです。

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

3. 整理のフレーム：事故後説明で評価される「3つの部品」

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

事故後説明で評価されるのは、技術そのものより、技術を説明可能にする部品です。

最低限、次の3つを揃えると説明が一気に強くなります。

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

フレーム①：タイムライン（事実）＋判断ログ（主語）

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

事故後に最も強い資料は、時系列です。

しかし“出来事の羅列”では足りません。意思決定が乗っている必要があります。

最低限の項目

・時刻（いつ）

・事象（何が起きた）

・判断（何をする/しないを決めた）

・判断者（役割：誰が責任を持って決めたか）

・実行者（誰が手を動かしたか）

・根拠（どのログ・証跡を見たか）

・次回更新時刻（いつ何を報告するか）

これがあると、技術の正しさが「行動として正しかった」に変換されます。

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

フレーム②：証跡パック（言い切りの根拠）

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

事故後の説明は「言い切れるか」が価値です。

言い切りを支える証跡パックを作ります。

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

・対象ログ一覧（何を見るか）

・保持期間（どこまで遡れるか）

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

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

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

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

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

・委託先提出ルート（SOC/MSP→自社など）

「ログはあります」ではなく「この範囲をこの形式でこの期限で提出できます」

に変換できると、事故後説明が通りやすくなります。

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

フレーム③：タスク別RACI（誰がやるか、が割れない）

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

事故後説明が崩れる典型は、主語が割れることです。

「SOCがやる」「MSPがやる」「情シスがやる」「経営が決める」…が噛み合わない。

最低限固定したいタスク

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

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

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

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

・復旧判断（BCP発動、切替）

・対外説明（文面承認）

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

RACIがあると、技術の話が「責任の話」に変換されても破綻しません。

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

4. ケーススタディ（匿名化）：技術は正しいのに“説明が通らなかった”B社

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

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

背景

・B社：Azure上で複数システム運用、M365/Entra IDで統合認証

・WAF、MFA、SIEM、バックアップ等は導入済み

・監視はSOC、運用はMSPに委託

事故後の状況

・技術的な対策は一通り実装されており、担当は「構成は正しい」と説明

・しかし取引先からの質問が以下に集中

初動のタイムライン（誰がいつ何をしたか）

影響範囲の根拠（どのログで“流出なし/限定”を言い切ったか）

ログ保全の記録（削除停止はいつ誰が実施したか）

ログ提出の期限と形式（何営業日以内に出せるか）

委託先の役割と義務（契約上どこまでやるか）

詰まった理由（構造）

・ログは集約していたが「保全」「抽出者記録」「提出期限・形式」が固まっていなかった

・SOC/MSP/自社のタスク別RACIがなく、主語が割れた

・例外（暫定・除外）の台帳がなく、当時の判断が説明できなかった

・SOWに提出・保全協力の義務が明確でなく、材料が期限内に集まらなかった

立て直し（方向性）

・タイムライン＋判断ログのフォーマットを作り、事故ごとに必ず残す

・証跡パック（提出・保全・承認）を定義

・タスク別RACIを整備し、委託先を含めて主語を固定

・SOWに一次通知・提出期限・保全協力・記録提供を期限付きで落とす

結果

・「技術の正しさ」だけの説明から、

・「行動と証跡で説明できる」説明へ移行でき、取引先対応が安定した

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

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

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

事故後説明で“技術の正しさ”が評価されない組織は、だいたい次が抜けています。

YESが少ないほど、事故後に説明が崩れやすいです。

【タイムライン・判断】

□ 事故のタイムラインを分単位で残せる（時刻・事象・判断・実行・根拠）

□ 判断者（役割）が明確で、会議で主語が割れない

□ 「次回更新時刻」を決めて報告できる

【証跡（言い切りの根拠）】

□ 影響範囲を言い切るための対象ログ一覧がある

□ ログ保全（削除停止・隔離・アクセス制限）の手順がある

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

□ ログ提出の期限（何営業日以内）と形式が固定されている

□ 外部提出の承認者が決まっている

【責任分界（RACI）】

□ 一次通知・封じ込め・保全・提出・復旧・対外説明のRACIがある

□ SOC/MSP/SIer/Microsoftの役割がタスクで説明できる

□ 例外の承認・延長・解除が台帳＋期限で回っている

【委託契約（SOW）】

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

□ 記録提供（作業報告、実施者、実施時刻）が成果物になっている

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

YESが揃うほど、事故後説明は「技術の正しさ」だけに依存せず、組織として評価されやすくなります。

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

6. まとめ：事故後に評価されるのは「正しい構成」ではなく「正しく動き、証明できる体制」

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

事故後説明で“技術の正しさ”が評価されない理由は、技術が不要だからではありません。

技術の正しさが、相手の評価軸に直接つながらないからです。

評価されるのは、次の3つです。

・タイムライン＋判断ログ（事実と主語）

・証跡パック（言い切りの根拠）

・タスク別RACI（責任分界）

この3つが揃うと、技術の正しさは「統制として正しい」に変換され、事故後説明が通ります。

逆に、どれかが欠けると、技術が正しくても「説明不能」「再発しそう」と見なされやすくなります。

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

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

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

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

事故後に「技術は正しいのに説明が通らない」状態を、タイムライン・証跡パック・RACI・委託契約（SOW）まで含めて整えるクラウド法務支援を行っています。

・ログはあるが、保全（削除停止）や提出（期限・形式・承認）が固まっていない

・SOC/MSP/再委託が絡むと、主語が割れて説明が崩れる

・例外（暫定開放、CA除外、常設特権）の当時判断が説明できない

・事故後の説明を“技術だけ”から“体制と証跡”に変換したい

・取引先・親会社・監査に一貫したストーリーで答えられる状態にしたい

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

お問い合わせの際に「事故後説明の記事を見た」と書いていただけるとスムーズです。