【クラウド法務】Azure CDNは誰が“配信の責任”を負うのか？― Microsoft／利用者（自社）／委託先（MSP/SOC）で割れやすい「配信の責任」を、事故対応まで含めて整理 ―

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

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

はじめに

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

Azure CDNは「速くなる」「落ちにくくなる」「オリジン負荷が減る」という分かりやすいメリットがあり、導入も比較的スムーズです。ただ、いざトラブルが起きた瞬間に、情シス・法務・事業側で必ず出るのがこの質問です。

「CDNの“配信”って、結局誰の責任？」「Microsoft？ それとも自社？ 監視を委託しているベンダー？」

ここでいう“配信の責任”は、実は1種類ではありません。「回線が落ちた」「キャッシュが古い」「誤って会員ページが外部に配信された」「ログが出せず説明できない」など、トラブルの種類によって責任の論点が変わります。

結論から言うと、Azure CDNの配信は 責任共有（Shared Responsibility）です。ただし、社外（顧客・取引先）への説明の主語は、原則として 利用者（自社）に残ります。そのため、CDN導入時に「責任分界の設計図」を作らないと、事故の初動より先に“責任の押し付け合い”が始まり、復旧と説明が遅れます。

この記事では、Azure CDN利用時の「配信責任」を、技術の事実整理→ズレの地雷→整理フレーム→事例→チェックリストの順でまとめます。

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

1. まず定義：CDNの“配信の責任”は3つに分けて考える────────────────────────────

「配信の責任」を1つの言葉で扱うと必ず揉めます。最初に、次の3つに分解してください。

（1）可用性の責任（Availability）・CDNサービスとして応答できるか・特定地域で落ちていないか・大規模障害時の復旧情報がどう出るか→ これは主にクラウド提供者（Microsoft／CDN基盤側）の領域が大きい

（2）内容の責任（Correctness / Freshness / Access Control）・“正しいコンテンツ”を配っているか・キャッシュが古くないか（更新が反映されるか）・配ってはいけないもの（会員ページ、個人情報、機密ファイル）を配っていないか→ これは主に利用者（自社）の設計・設定・運用の領域が大きい

（3）説明責任（Accountability / Evidence）・事故の影響範囲を説明できるか・ログ（証跡）を提示できるか・取引先への一次報告を期限内に出せるか・再発防止の筋の通った説明ができるか→ 主語は原則「自社」。委託先やMicrosoftは“協力者”になりやすい

この3つを混ぜないことが、Azure CDN導入の法務・運用で一番重要です。

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

2. 技術構成の“事実整理”：CDNは「オリジン以外にデータを作る」────────────────────────────

責任分界を議論する前に、CDNで何が起きるかを、最低限の構造として押さえます。

典型構成（テキスト図）

【ユーザー（ブラウザ／アプリ）】　↓ HTTPS【CDNエッジ（世界各地の配信拠点）】・キャッシュ（コンテンツのコピーが一時保存され得る）・ルール（キャッシュ制御、リダイレクト、ヘッダ付与など）・（構成次第で）WAF／アクセス制御／TLS終端　↓（キャッシュミス時など）【オリジン（Storage／Webアプリ／オンプレ等）】・本体コンテンツ／アプリ処理

CDNを使うと、次の“データ”が増えます。

A）キャッシュされるコンテンツ（コンテンツのコピー）B）ログ（アクセスログ、配信ログ、セキュリティ関連ログ）C）設定（ルール、TTL、オリジン、証明書、WAF等）

つまり、CDN導入は「配信経路を増やす」だけではなく、“データの所在”と“操作できる範囲”を増やす行為です。この増えた分だけ、責任分界と証跡設計が必要になります。

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

3. 結論：Azure CDNの“配信責任”は誰にあるのか（境界の整理）────────────────────────────

ここが一番聞かれる部分なので、先に結論を整理します。

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

3-1. Microsoft（CDN基盤側）が主に負う領域────────────────────────────

・CDN基盤（エッジネットワークや配信基盤）の提供・サービスとしての稼働（一般的にはSLA等の枠で示される領域）・基盤側の物理・プラットフォームセキュリティ（施設・基盤運用等）

ただしここで重要な注意点があります。「稼働率」や「基盤の提供」はあっても、あなたのサイトが“正しい内容で配信されること”や“あなたの取引先要件を満たすこと”までを保証するとは限りません。可用性と内容の責任を混ぜると、事故時に説明が崩れます。

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

3-2. 利用者（自社）が主に負う領域（ここが“オンプレ延長”と誤解されやすい）────────────────────────────

Azure CDNで多くの企業が見落とすのは、「配信内容」や「配信制御」は自社の責任が濃い点です。

・オリジンの正しさ（何を公開するか）・キャッシュ方針（TTL、Cache-Control、キャッシュ禁止対象）・誤配信リスクの設計（会員ページ、個人情報、トークン付きURL等）・Purge（キャッシュ削除）や無効化の運用（誰が、いつ、どの範囲で）・設定変更の統制（変更管理、承認、ロールバック）・ログの保持・提出・保全（監査・取引先照会に耐える状態）・インシデント時の社外説明（一次報告、影響範囲、再発防止）

要するに、「Azure CDNを使っている」こと自体は理由になっても、免責にはなりにくいというのが実務です。

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

3-3. 委託先（MSP/SOC/保守ベンダー）が負う領域────────────────────────────

委託先は、Microsoftの責任を肩代わりする存在ではなく、基本的には 自社が負う領域の“作業”を契約で代行する存在です。

だからこそ、事故時に揉めるのはここです。

・委託範囲が「監視だけ」なのか「一次対応まで」なのか「設定変更も含む」のか・Purgeや緊急遮断を委託先ができるのか（権限設計）・ログ提出の義務があるのか（期限・形式）・保全（削除停止・隔離）の協力義務があるのか・再委託（国外SOC等）があるのか、あるなら条件は何か

委託先の責任は、最終的には「契約で決めた義務」の範囲に落ちます。契約にないものは、事故後に“別メニュー／別料金／努力義務”になりやすく、説明が遅れます。

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

4. よくある“法務・運用のズレ”3選（技術はOK／説明はNG）────────────────────────────

ここからが実務上の地雷です。Azure CDN導入で特に多いズレを3つに絞ります。

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

ズレ①：SLA（稼働率）を「配信の責任」と誤解する────────────────────────────

技術的にはOK・CDNは動いている・稼働率の話はできる

でも実務では、社内外はこう聞いてきます。・「なぜ古いコンテンツが配られた？」・「なぜ会員向けが外に出た？」・「なぜ今すぐ消せない？」

これらは可用性より「内容の責任」の話です。SLAを持ち出しても説明にならず、むしろ「話が噛み合わない会社」に見えます。

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

ズレ②：キャッシュが“データ保管”になるのに、データ管理がオリジン止まり────────────────────────────

CDN導入後、社内の説明資料が「データはオリジン（Storage等）にある」前提のままだと危険です。CDNは、設定次第で「本来キャッシュしてはいけないもの」もキャッシュします。

典型的に事故につながるパターン・認証が必要なページをキャッシュ対象にしてしまう・URLにトークンや識別子が入り、ログやキャッシュに残る・会員向けPDF／請求書／契約書などを静的配信の延長で載せる・Purge運用が属人化しており、緊急時に誰も動けない

このズレは、情報漏えいの原因として非常に多いです。

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

ズレ③：委託先が絡むと「ログ提出」と「保全」が契約空白になりやすい────────────────────────────

CDNの事故では、原因確定より先に「いま出せる事実」が求められます。つまりログです。ところが委託運用が入ると、

・ログは委託先が見ているが、提出義務が契約にない・提出期限が決まっておらず、取引先照会に間に合わない・事故時に保全（削除停止・隔離）する手順がない・緊急時のPurgeを誰が実行するのか決まっていない

となり、説明の材料が集まらず詰みます。

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

5. “配信責任”で詰まらないための整理フレーム（3つの軸）────────────────────────────

Azure CDNの責任分界は、機能一覧を追うより、先に次の3軸で整理すると崩れません。

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

整理軸①：「配信の責任」をタスクに分解してRACIで固定する────────────────────────────

レイヤー議論（ネットワーク層など）ではなく、やること（タスク）で切ります。最低限、次のタスクを並べてRACI（R=実行、A=最終責任、C=相談、I=共有）を決めます。

CDNの最低タスクリスト（例）1）キャッシュ方針の決定（キャッシュ許可／禁止、TTL、ヘッダ方針）2）CDN設定変更（ルール、ルーティング、オリジン、ヘッダ、セキュリティ設定）3）Purge（キャッシュ削除）／緊急遮断4）証明書（TLS）更新・失効対応（誰がいつ更新するか）5）ログ収集・保持（何を、どこに、どれだけ）6）ログ提出（監査／取引先照会／事故調査：期限と形式）7）ログ保全（削除停止、隔離、抽出者記録）8）インシデント一次通知（社内・取引先・顧客）9）原因分析と再発防止（誰がまとめ、誰が承認するか）

ポイント委託先がRでも、A（最終責任）と社外説明の主語は自社に残る項目が多い。だからこそ、委託先に「協力義務」と「提出能力」を契約で固定します。

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

整理軸②：「キャッシュしてはいけないもの」を先にルール化する────────────────────────────

CDN設計で最も効果が高いのは、“キャッシュ禁止”の先出しです。

最低限の禁止ルール例・認証が必要なページ、個別ユーザー情報を含むページはキャッシュ禁止・URLにトークン／識別子／個人情報が入る設計は原則禁止（やるなら短命化・署名付き・限定配信）・会員向けPDF（請求書、見積書、契約書、設計図等）は原則キャッシュ禁止・管理画面、API応答、動的ページは原則キャッシュ禁止（例外は厳格に台帳管理）

加えて、事故時の運用として・Purgeの手順（誰が、どの範囲を、何分以内に）・誤配信発覚時の一次報告テンプレ（社内・取引先）を決めておくと、二次炎上を防げます。

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

整理軸③：契約と規程で「提出能力」と「緊急操作」を固定する────────────────────────────

CDNの事故は「説明が遅い」だけで信用を落とします。そのため契約・規程で固定したいのは、次の“能力”です。

（A）ログ提出能力・保持期間（短期運用／監査要件で分けるのか）・提出期限（何営業日以内に出すか）・提出形式（必要項目、時刻基準、マスキングの要否）・提出担当と承認（誰が出し、誰が承認するか）

（B）保全能力（リーガルホールド相当）・事故時にログや設定証跡を「消さずに凍結」できるか・抽出者記録（いつ誰が取ったか）を残せるか・委託先が関与する場合、保全協力が“義務”かどうか

（C）緊急操作能力（Purge・遮断・切替）・Purgeを誰が実行できるか（権限設計）・緊急遮断（CDN無効化、オリジン切替等）の承認ルート・緊急変更の事後追認（期限・記録）

これを契約別紙（SOW）や運用規程に落とすと、事故時に「動ける会社」に変わります。

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

6. ケーススタディ（匿名化）：B2Bポータルで「配信責任」が割れて初動が遅れた例────────────────────────────

背景・B2Bポータルの高速化でCDNを導入・運用は一部MSPに委託・CDNの設定変更も委託先が手を入れることがあった

起きたこと（典型）・一部コンテンツが意図せずキャッシュされ、古い情報が配信された疑い・取引先から「どの期間、どのユーザーに影響？」と照会が来た・社内では「CDNのせい」「オリジンのせい」「委託先の設定」など原因の議論が先に進む・しかしログ提出の担当と期限が決まっておらず、回答が遅れた・Purgeも誰がいつやるかが曖昧で、対応が後手に回った

改善で効いたこと・キャッシュ禁止ルール（認証系、個別データ、トークンURL等）を明文化・Purge手順と承認ルートを規程化・ログの保持・提出・保全を「証跡パック」として定義・委託契約別紙に、通知・提出・保全協力・緊急対応の範囲を明記

結果として「CDNは速い」だけでなく、「事故時に説明できる配信基盤」として位置づけ直せたというケースです。

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

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

□ “配信責任”を可用性／内容／説明責任に分けて社内説明できる

□ CDNでキャッシュしてはいけない対象（認証ページ、個別データ等）がルール化されている

□ URLトークンや識別子の扱いが決まっている（禁止／短命化／限定配信）

□ Purge（キャッシュ削除）の手順・担当・承認が決まっている

□ CDN設定変更が変更管理（チケット・承認・ロールバック）で回っている

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

□ ログ提出の期限・形式・担当が決まっている（委託先が絡むなら契約化）

□ 事故時のログ保全（凍結・隔離・抽出者記録）ができる

□ 委託先の責任範囲（監視／一次対応／設定変更／提出協力）が明確

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

□ 契約終了時の出口（設定・ログ・手順引渡し、アクセス剥奪証明）が決まっている

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

8. まとめ：配信の責任は「サービス」ではなく「仕組み」で決まる────────────────────────────

Azure CDNの“配信の責任”は、Microsoft／自社／委託先の責任共有です。ただし、社外（取引先・顧客）への説明の主語は、原則として自社に残ります。

だからこそ、CDN導入前に・タスク別RACI・キャッシュ禁止ルールとPurge手順・ログの保持・提出・保全（証跡パック）・委託契約の提出義務・緊急対応範囲を固めることが、最終的に一番安い「事故対策」になります。

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

お問い合わせ

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

山崎行政書士事務所では、Azure CDNを含む配信基盤について、技術構成と契約・規程・監査対応をセットで整理する「クラウド法務支援」を行っています。

・CDN導入で“配信責任”を1枚の責任分界（RACI）にしたい・委託先（MSP/SOC）にログ提出・保全協力・緊急対応を契約で入れたい・キャッシュ起因の誤配信リスクを、ルールと運用手順で潰したい・取引先照会に耐える“証跡パック”を作りたい

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