【クラウド法務】委託先の「ログ提出義務」条項でトラブルになりやすい3つのポイント— Azure / M365 / Entra ID 運用を委託する前に、“いつ・誰が・何のログを・どの形式で出すか”を契約で縛る（委託先 ログ提出義務 条項）—

導入：ログは取ってる“はず”。でも「提出できる」とは誰も約束していない

クラウド運用をMSP（運用委託先）やSIerに委託すると、監視・障害対応・設定変更のスピードは上がります。一方で、全国の情シス・IT部門の方から相談を受けていると、次のような“詰み方”が非常によく起きます。

• 「インシデント後にログが必要になったが、委託先から“それは提供対象外”と言われた」

• 「ログはあると言われたが、保持期間が短く、欲しい期間が残っていなかった」

• 「監査・親会社・取引先から“証跡を出して”と言われても、委託契約に提出義務がなく社内が揉めた」

ログは“取っているか”より、**「必要なときに、証跡として提出できるか」**が本番です。本記事では 「委託先 ログ提出義務 条項 × クラウド法務」 の視点から、よくある落とし穴と、実務で使える整理のフレーム（条項のたたき台）をご紹介します。

1. 委託先運用で「ログ」が実際どこに存在するのか（技術の“事実整理”）

まず、技術の事実を揃えます。ログ提出で揉める企業の多くは、そもそも “ログがどこに溜まっているか” が曖昧です。

1-1. 典型構成（テキスト簡易アーキテクチャ）

• ID / 認証：Entra ID（旧 Azure AD）

  • Sign-in logs / Audit logs / PIM・ロール変更履歴

• IaaS/PaaS：Azure

  • Activity Log / Resource Logs（診断ログ）/ Key Vault / Storage / SQL など各サービスのログ

• セキュリティ：Defender / Sentinel / 外部SIEM

  • アラート、インシデント、ルール発火履歴、調査メモ

• ログの集約先（会社によって分岐）

  • 自社の Log Analytics / Sentinel に集約

  • 委託先が自社環境内で運用（ただし操作は委託先）

  • あるいは 委託先の監視基盤（委託先SIEM） に転送・保管（ここが地雷）

1-2. “ログ提出できない”が起きる典型パターン（現場あるある）

• 委託先が「監視効率」を理由に、ログを委託先側のSIEMに持ち出している

• Azure / M365 側の保持期間は短いのに、長期保管の設計がされていない

• 調査に必要なログ（例：条件付きアクセスの変更履歴、PIM昇格履歴、Key Vaultアクセスログ等）が“対象外”になっている

• そもそも 提出形式（CSV/JSON/タイムゾーン/ハッシュ化等） の合意がなく、出てきても使えない

ここまでは技術の話。

ここからが法務。「委託先が保持している（または触れる）ログを、いつ・何の条件で・どの範囲まで提出させるか」を契約で決めていないと、緊急時ほど揉めます。

2. 全国の案件で見えてきた「ログ提出義務」条項の落とし穴3選

① “協力する”とは書いてあるが、ログ提出の中身がゼロ

• 技術的にはOK：委託先は監視しているし、何かあれば調査もしてくれる

• 法務・実務的にはNG：

  • 契約が「協力」「善処」止まりで、提出対象・期限・形式が未定義

  • インシデント後に「追加費用」「対応範囲外」「社外秘なので不可」が発生し、スピードが死ぬ

  • 監査・親会社・取引先対応で“出せない”が致命傷になる

② 保持期間と提出トリガーが噛み合っておらず、必要なログが消える

• 技術的にはOK：ログは“ある程度”は残る

• 法務・監査的にはNG：

  • 監査・紛争・取引先照会は「数か月〜年単位」で遡るのに、ログ保持は90日/180日で消える

  • 提出を求める頃にはもう残っていない

  • 「誰が保持設計の責任を負うか」も曖昧で、責任が宙に浮く

③ 個人情報・機密・越境・再委託が絡み、出したくても出せない

• 技術的にはOK：委託先はログを持っている

• 契約・統制的にはNG：

  • ログにはIP・端末ID・ユーザー識別子等が含まれ、個人データ/機密が混ざる

  • 再委託先や海外拠点が関与し、提出プロセスが複雑化

  • その結果「提出を禁止/制限する社内ルール」と「提出を求める監査要求」が衝突して揉める

3. 委託先ログ提出義務を“揉めない条項”にする整理フレーム3つ

条項作成の前に、最低限この3軸を紙に落とすと、契約がブレません。

① 何のログを、どの範囲で「提出対象」にするか

提出対象ログのカタログ化が最優先です。例としては：

• Entra ID：Sign-in / Audit / PIM（昇格・ロール変更）/ CA（条件付きアクセス変更）

• Azure：Activity Log / Resource Logs（診断ログ）/ Key Vault / Storage / SQL / Network など

• セキュリティ運用：Defenderアラート、Sentinelインシデント、調査記録（チケット・メモ）

• 変更管理：変更チケット番号、承認者、実施者、実施時刻、ロールバック記録

ポイントは「ログそのもの」だけでなく、調査の“文脈”（チケット・承認・手順）も提出対象に含めることです。

② いつ・どの期限で・どの形式で提出させるか

ログ提出は「気合い」ではなく SLA（納期） です。

• 提出トリガー

  • 発注者の要請（監査・親会社・取引先照会を含む）

  • インシデント（疑い含む）

  • 重大変更（CA/PIM/権限変更など）後の報告

• 期限

  • 一次提出：例「○時間以内に初動ログ」「○営業日以内に詳細ログ」など段階設計

• 形式

  • CSV/JSON、タイムゾーン、項目、マスキング要否、ハッシュ化（改ざん検知）

  • “誰が抽出したか”の記録（チェーン・オブ・カストディ）

③ 出せない理由を潰す（機密・個人情報・再委託・越境）

提出できない理由はだいたい固定です。先回りして条項で潰します。

• 個人データや機密のマスキング／最小化のルール

• 再委託先にも同等義務（提出・保全・協力）を課す

• 国外関与がある場合の提出ルール（保管場所、アクセス制限、提出経路）

• 提出費用（通常範囲／追加作業の線引き）も明文化

3.5 すぐ使える「委託先 ログ提出義務」条項サンプル（たたき台）

※以下は一般的な条項サンプル（骨子＋文例）です。実際は対象環境（Azure/M365）、運用範囲、監査要件、取引先要件に合わせて調整してください。

条項案1：定義（ログ・証跡・インシデント）

• 骨子：用語定義がないと揉めるので最初に固定

• 文例「本契約において『ログ』とは、受託者が本業務の遂行に関連して取得・生成・保管・参照する認証ログ、監査ログ、操作ログ、アラート情報、インシデント記録、変更管理記録その他の証跡をいう。」

条項案2：提出義務（要請ベース）

• 骨子：発注者の要請で提出させる／形式と期限をセットに

• 文例「受託者は、発注者からの要請があった場合、発注者が指定する範囲のログを、指定する形式および期限内に提出する。」

条項案3：提出トリガー（インシデント時）

• 骨子：疑い含む／一次提出と詳細提出の二段階が実務的

• 文例「受託者は、インシデント（疑いを含む）を認知した場合、所定時間以内に一次報告および当該時点で取得可能なログを提出し、追って原因調査に必要なログを所定期限内に追加提出する。」

条項案4：保持義務（保持期間・保全）

• 骨子：保持期間を契約で決める／改ざん防止と保全手順

• 文例「受託者は、ログを発注者が指定する期間保管し、改ざん・消去・不正アクセスを防止するための措置を講ずる。発注者から保全要請があった場合、受託者は当該ログの消去・上書きを停止し保全する。」

条項案5：形式・マスキング・チェーンオブカストディ

• 骨子：提出ログが“監査・法務で使える状態”であること

• 文例「ログ提出にあたり、受託者は、抽出日時、抽出者、対象期間、対象システム、形式、マスキングの有無等を併記し、発注者が監査等に利用できる状態で提出する。」

条項案6：再委託先にも同等義務（重要）

• 骨子：再委託が絡むとログが出ない問題が起きやすい

• 文例「受託者は、発注者の承諾を得て再委託を行う場合、再委託先に対し本条項と同等のログ保管・提出義務を課し、受託者はその履行について責任を負う。」

条項案7：費用（通常範囲／追加の線引き）

• 骨子：「出すのに工数がかかる」問題を事前に処理

• 文例「本業務に通常含まれる範囲のログ提出は委託料に含む。発注者の要請により追加作業が必要となる場合は、事前に協議の上、別途費用を定める。」

条項案8：契約終了時（ログ・証跡の引渡し／削除）

• 骨子：終了時にログが消えるのを防ぐ

• 文例「契約終了時、受託者は発注者の指示に従いログを引き渡し、または消去し、その完了を証跡をもって報告する。」

4. ケーススタディ：SaaS企業A社（売上100億、契約社数300社）の場合

（匿名化した事例）

• 業種：BtoB SaaS

• 体制：Azure / M365 をMSPに運用委託（24/365監視）

• 課題：大口顧客から「インシデント時の証跡提出」を要求された

起きていた問題

• 契約書には「セキュリティに協力する」としか書いておらず、ログ提出の期限・形式が未定義

• MSP側SIEMにログを集約していたが、提出は“有償・要相談”扱い

• 監査要求が来た時点で、必要期間のログが残っていない部分があった

支援内容（抜粋）

• どのログがどこにあるか（Entra/Azure/Sentinel/チケット）を棚卸し

• 「提出対象ログ」「提出トリガー」「提出期限」「形式」「保持期間」を一枚表に整理

• その内容を委託契約条項（ログ提出義務・保全・再委託・費用）に落とし込み

• 顧客向けには「提出できるログ範囲」と「提出手順」を説明資料化

結果

• 監査・大口顧客からの照会に“契約＋運用証跡”で一貫して回答できるようになり、交渉が安定

• MSP側も「どこまでが標準対応か」を明確化でき、緊急時の摩擦が減った

5. 委託先のログ提出義務を見直すチェックリスト

• □ 委託先が取得・保管しているログの一覧（提出対象）が1枚で説明できる

• □ 提出トリガー（要請時／インシデント時／監査時）が契約で定義されている

• □ 一次提出・詳細提出の期限が決まっている

• □ 形式（CSV/JSON/タイムゾーン/マスキング）と、抽出者・抽出条件の記録が決まっている

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

• □ 保全（消去停止・改ざん防止）の義務がある

• □ 再委託先にも同等義務が及ぶ（再委託管理）

• □ 通常範囲と追加費用の線引きが明文化されている

• □ 契約終了時のログ引渡し／削除／完了報告がある

「全部YES」と言える企業は、全国的に見てもまだ多くありません。逆にここが揃うと、監査・親会社・取引先対応が一気に楽になります。

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

山崎行政書士事務所では、Azure / M365 / Entra ID 等の技術構成と、委託契約・規程・監査対応をセットで整理する「クラウド法務支援」 を行っています。

• 委託先運用はしているが、ログ提出義務が契約に落ちていない

• 監査・親会社・取引先からの質問に、技術と契約をセットで説明したい

• 「提出できるログ」「保持期間」「再委託」「費用」を含めて、揉めない条項に作り直したい

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

👉 お問い合わせの際に、「委託先 ログ提出義務 条項の記事を見た」 と書いていただけるとスムーズです。