【クラウド法務】ログがあるのに説明できない組織で、必ず抜けている3つのもの― 「見えている」のに「出せない」「語れない」。監査・取引先照会で詰まる原因はログ不足ではない ―

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

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

はじめに

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

「ログは取っている。SIEMにも入っている。監視もSOCに任せている。なのに“説明”になると急に詰まる」

クラウド（Azure / M365）を運用している情シス・IT部門の方から、こうした声を非常によく聞きます。

監査や取引先の審査で聞かれるのは、もはや「ログを取っていますか？」ではありません。

「何を、どれだけ保持し、いつまでに、どの形式で提出できますか？」

「事故時にログを保全（削除停止）できますか？証跡の真正性は？」

「誰が最終責任者として判断し、誰が対外説明を承認する体制ですか？」

ログがあるのに説明できないとき、問題は“ログがない”ことではなく、ログを証跡として成立させるための3つの要素が抜けていることがほとんどです。

本記事では、その「必ず抜けている3つのもの」を、技術と法務のつなぎ目として整理します。

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

技術構成の“事実整理”：ログは「ある」だけでは説明にならない

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

まず技術の話として、現場のログ環境は大抵こうなっています。

よくある全体像（テキスト図）

【Azure / M365 / Endpoint】

・Entra ID（サインインログ／監査ログ）

・Azure（Activity Log／リソースログ／NSG・Firewall・WAF等）

・M365（監査ログ、メール、SharePoint等）

・EDR（端末イベント）

　↓（転送）

【ログ基盤】

・Log Analytics / データレイク / ストレージ

・SIEM（Sentinel 等）

　↓（運用）

【SOC / 委託先】

・検知、トリアージ、調査、エスカレーション

　↓

【自社（情シス／CSIRT／法務／監査対応）】

・封じ込め、復旧、対外説明、再発防止

この状態で「ログは見える」ようになります。

しかし監査や取引先が求めているのは「見えること」ではなく、次の3点です。

提出できること（期限内に、一定形式で、揃えて出せる）

保全できること（事故時に削除停止や隔離を行い、真正性を示せる）

主語が割れないこと（誰が判断し、誰が承認し、誰が出すかが固定されている）

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

ログがあるのに説明できない組織は、この3点の“どれか”ではなく、だいたい“全部”が薄いです。

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

2. ログがあるのに説明できない組織で、必ず抜けている3つのもの

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

ここから本題です。

「ログはあるのに説明できない」組織で、ほぼ必ず抜けている3つのものを挙げます。

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

抜けているもの①：ログの「提出設計」（提出期限・形式・承認）がない

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

ログがある企業ほど、ここを見落としがちです。

ログは“取れている”ので安心してしまいます。

しかし、説明責任で問われるのは次です。

・誰が（提出担当）

・いつまでに（提出期限：何営業日以内）

・どの形式で（項目、時刻基準、マスキング要否、関連メタデータ）

・何を含めて（対象ログの範囲：認証、管理操作、ネットワーク変更等）

・誰の承認で（対外提出の承認者）

この「提出設計」がないと、監査や取引先照会のたびに

「SOCに確認します」「委託先に抽出依頼します」「形式は相手に合わせて…」

となり、提出が遅れ、回答が割れます。

技術的にはログがある。

でも運用として“提出できる状態”になっていない。

これが最初の抜けです。

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

抜けているもの②：ログの「保全設計」（リーガルホールド相当・真正性）がない

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

事故や紛争、監査の局面では、ログは単なる運用データではなく「証拠（証跡）」として扱われます。

このとき問われるのは、ログの内容以前に次です。

・事故時に削除停止（Retention固定・削除抑止）ができるか

・抽出したログが“後から改ざんされていない”と説明できるか

・いつ、誰が、何の手順で抽出したか（抽出者記録）があるか

・抽出データの保管場所、アクセス制限、保管期限が決まっているか

保全設計がない組織は、事故後にこうなります。

「ログはあるけど、今見ているログが当時の原本なのか説明できない」

「削除や上書きが起きていないと言い切れない」

「関係者が多すぎて、誰が何を触ったか追えない」

ログがあるのに説明できない理由は、ログの“量”ではなく、証拠としての“形”がないことにあります。

これが2つ目の抜けです。

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

抜けているもの③：ログ運用の「主語を固定する設計」（責任分界＋契約）がない

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

ログは、集めるより「誰が責任を持つか」が難しい領域です。

特に次の条件があると、一気に主語が割れます。

・SOC / SIEM運用を委託している

・再委託（下請け、海外SOC等）が絡む

・クラウド（Microsoft）＋委託先＋自社の関係者が多い

このとき、社内外の質問は“技術”から“体制”へ寄ります。

・誰が最終責任者ですか

・誰が提出しますか

・誰が保全しますか

・誰が対外説明を承認しますか

ここに答えるには、レイヤー図ではなく タスク別の責任分界（RACI） と、委託先に義務として担保させる 契約（特にSOW） が必要です。

よくある崩れ方

・社内：「SOCが持っている」

・SOC：「提出は契約外／別料金」

・法務：「提出できる前提で説明していた」

→ 誰も“提出できる責任主体”にならない

ログがあるのに説明できない組織では、ここが必ず抜けています。

これが3つ目の抜けです。

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

3. どう整えるべきか：説明責任を成立させる「整理のフレーム」

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

上の3つを埋めるには、完璧な統制より先に、最低限これだけを揃えるのが効きます。

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

フレーム①：「証跡パック」を定義して、提出設計を作る

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

証跡パックの最低構成（例）

・対象ログ一覧（認証／管理操作／NW変更／Key Vault操作／メール監査等）

・保持期間（標準と延長、取引先要件との整合）

・提出期限（例：〇営業日以内）

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

・提出ルート（誰が抽出し、誰が承認し、誰が提出するか）

・提出時のチェック（抜け漏れ、改ざん疑義対応）

「ログはあります」から

「この形式で、〇営業日以内に提出できます」

へ変える設計です。

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

フレーム②：保全プロトコルを作り、真正性を説明できるようにする

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

最低限決めるべきこと

・保全トリガー（何が起きたら保全するか）

・削除停止の手順（誰が、どこで、何を止めるか）

・抽出者記録（日時、実施者、対象、手順、保管場所）

・保管（アクセス制限、保管期限、暗号化、持ち出し禁止）

・委託先が関与する場合の協力義務（保全協力、提出協力）

事故のときに「ログを取る」では遅いです。

「先に保全してから動く」体制が、説明責任の前提になります。

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

フレーム③：タスク別RACIと、委託契約（SOW）で“主語”を固定する

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

レイヤー（NW層、OS層）ではなく、タスクで切ります。

ログ領域で最低限入れるタスク（例）

・ログ収集範囲の決定（Aは誰か）

・ログ保持期間の決定（Aは誰か）

・ログ提出（Rは誰か、Aは誰か、期限は何か）

・事故時保全（R/A、保全トリガー）

・委託先の特権アクセス統制（個人特定、期限、操作ログ、剥奪証明）

・再委託（国外SOC含む）の範囲特定と同等義務の貫通

・契約終了時の出口（ログ返還、削除証明、引継ぎ）

そして、委託があるならSOWに「義務」として落とします。

最低ライン（例）

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

・ログ提出義務（期限・形式・対象範囲）

・保全協力（削除停止、隔離、抽出者記録への協力）

・目的外利用（学習利用等）禁止

・再委託条件（国外関与含む）と監督責任

・契約終了時の返還・削除・削除証明

これが揃うと、ログが“説明の根拠”として使えるようになります。

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

4. ケーススタディ（匿名化）：ログはSIEMにあるのに取引先照会で止まった例

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

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

背景

・Azure＋M365運用

・ログはSIEMに集約、SOCで24/7監視

・体感として「ログは揃っている」状態

取引先からの質問

・「当該期間の管理操作ログを〇営業日以内に提出可能ですか」

・「事故時にログを保全（削除停止）できますか。手順と責任者は？」

・「海外SOCや再委託の関与はありますか」

詰まったポイント

・ログはあるが、提出期限・形式・承認が決まっていない（抜け①）

・保全手順がなく、抽出者記録もない（抜け②）

・SOCは協力するが、提出や保全は契約外になり得る状態（抜け③）

立て直し

・証跡パックを定義（提出期限・形式・対象ログの固定）

・保全プロトコルを作成（削除停止・抽出者記録）

・RACIで主語を固定し、SOWに提出義務・保全協力・再委託条件を追記

結果

・技術構成を大きく変えずに「提出できる」「説明できる」状態に近づき、照会対応が安定した

という流れです。

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

5. 今すぐ確認できるチェックリスト

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

□ ログの“対象範囲”を説明できる（認証／管理操作／NW変更等）

□ 保持期間が、監査・取引先要件と整合している

□ 提出期限（何営業日以内）と提出形式が決まっている

□ 提出担当者と承認者が決まっている（主語が割れない）

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

□ 抽出したログの真正性を説明できる（いつ誰がどう取得したか）

□ SOC/委託先が絡む場合、提出・保全協力がSOWで義務化されている

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

□ 契約終了時の出口（ログ返還・削除・削除証明・引継ぎ）が決まっている

「ログがある」のにYESが揃わないなら、説明責任は成立しにくい状態です。

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

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

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

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

ログ・証跡を「見える」だけでなく「提出できる」「保全できる」「主語が割れない」形に整えるクラウド法務支援を行っています。

・ログはあるが、監査・取引先に“期限内に提出できる”状態にしたい

・SOC／SIEM運用委託を含め、提出義務・保全協力・再委託条件をSOWで固めたい

・リーガルホールド相当の保全手順と抽出者記録を整備したい

・責任分界をレイヤーではなくタスク別RACIで1枚にしたい

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

お問い合わせの際に「ログがあるのに説明できない記事を見た」と書いていただけるとスムーズです。