【クラウド法務】Azureを使う企業が必ず一度は考えるべき「説明責任」という問題― 技術は動くのに、監査・取引先・親会社で詰まる。本当のボトルネックは“説明できない”こと ―

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

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

はじめに

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

Azureを触っている情シス・IT部門の方なら、一度はこう感じたことがあるはずです。

「技術的には構築できた。動いている。なのに、社内外の“質問”に答えられない」

・「この構成って、セキュリティは誰が責任持つの？」・「委託先が運用してるけど、事故が起きたら誰が説明するの？」・「ログはある？監査で提出できる？保持期間は？」・「BCP的に、何時間で復旧できる？その根拠は？」・「海外拠点や海外SOCが絡むけど、越境の説明できる？」

Azureは、機能を増やすほど強くできます。しかし現実には、クラウドの失敗は“技術不足”ではなく“説明不能”から起きることが多いです。そしてこの“説明不能”は、事故だけでなく、監査・取引先照会・親会社の統制・M&A・海外展開など、必ずどこかのタイミングで踏みます。

本記事では、Azureを使う企業が避けて通れない「説明責任」について、「共感 → 技術的な整理 → 法務の地雷 → 対策フレーム → 具体例 → 自社に合うか相談」の順で、実務で崩れない整理方法をまとめます。

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

1. 技術構成の“事実整理”：Azureは「責任が消える」のではなく「責任が分割される」────────────────────────────

まず、Azureの責任を語る前に、現場で起きている“構造”を整理します。Azure導入で増えるのは、機能だけではありません。関係者と境界が増えます。

典型的な全体像（ざっくり）

【利用者（ユーザー／社員／取引先）】　

↓

【ID・アクセス】・Entra ID（MFA、条件付きアクセス、PIM等）　

↓

【ネットワーク境界】・VNet／NSG／Firewall／WAF／Private化 等　

↓

【ワークロード】・VM／PaaS／DB／Storage／AVS／Arc 等（組み合わせ多数）　

↓

【ログ・監視・運用】・Azure Monitor／Log Analytics／SIEM（委託SOC含む）　

↓

【バックアップ・DR】・Azure Backup／Site Recovery／設計・テスト・証跡　

↓

【契約・委託】・Microsoft（クラウド提供）・MSP（運用委託）・SOC（監視・調査委託）・サードパーティ（Marketplace含む）

ここで“説明責任”が難しくなる理由は単純です。オンプレは「自社の機械を自社が運用」なので、責任の主語が単純でした。クラウドは、責任が共有（Shared Responsibility）になり、しかも委託やサードパーティでさらに分割されます。

つまりAzureは、「安全になる」＝「責任が減る」ではなく、**“責任の設計図が必要になる”**環境です。

そして、説明責任で詰まる企業の多くは、技術構成図はあるのに「契約上・運用上、誰がどこまで責任を負うか」の図がありません。

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

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

2. まず定義：Azureの「説明責任」は、原因責任や賠償責任とは別物────────────────────────────

事故や監査の場面で混ざりやすい「責任」を、最初に分解します。ここを分けるだけで社内会議が短くなります。

（1）原因責任（技術的に何が原因か）・設定ミス、権限ミス、パッチ未適用、委託先操作、基盤障害など

（2）契約責任（誰が何を“義務として”負うか）・通知義務、調査協力、ログ提出、補償（賠償・免責）、SLA、再委託条件など

（3）説明責任（社内外に“説明できる状態”を作る責任）・取引先／顧客／親会社／監査／当局（該当する場合）に　「影響範囲」「対応状況」「再発防止」を、根拠付きで説明できること

結論：Azureを使う企業で最もボトルネックになるのは（3）です。そして（3）の主語は、原則として 利用者＝自社に残ります。

Microsoftが原因に関与していても、委託先が作業していても、取引先と契約しているのは自社であり、サービス提供主体も自社だからです。委託先やMicrosoftは協力者にはなれても、対外説明の主語にはなりにくい。これがクラウドの“現実”です。

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

3. 説明責任が突然「問題化」するタイミング（事故だけではない）────────────────────────────

多くの企業は、セキュリティ事故が起きて初めて「説明責任」を意識します。ただ実際は、事故がなくても、次のタイミングで必ず問われます。

・取引先の審査（セキュリティチェックシート、BCP確認、ログ提出要求）・親会社・グループの統制（共通基準、監査、権限棚卸し）・外部監査（ISO、SOC相当、内部監査、規制対応）・委託先管理の見直し（再委託・国外SOC・目的外利用の確認）・海外取引や越境（データ所在地、アクセス主体の説明）・M&A／子会社統合（テナント統合、ログ統合、権限統合）

つまり、説明責任は「いつか来る」ではなく、**Azureを使い始めた時点で“必ず来る”**と考える方が現実的です。

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

4. 法務・運用の“地雷”：説明責任が崩れる典型3パターン────────────────────────────

ここでは、全国の案件で特に多い「技術はOK／説明はNG」のズレを3つに絞ります。

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

地雷①：SLAの数字を語れるのに、RTO/RPO（復旧の約束）を説明できない────────────────────────────

よくある会話・社内：「AzureのSLAがあるので大丈夫です」・取引先：「で、あなたのサービスは何時間で復旧しますか？」・情シス：「……（SLAの話と違う）」

SLAは“クラウドサービス提供”の話であり、取引先が求めるのは“あなたのサービスが戻るか”です。つまりRTO/RPO、復旧手順、復旧テストの証跡が必要です。

「バックアップは取っている」「DR構成はある」だけでは足りません。事故や審査で問われるのは、・誰が復旧判断するか・どの順番で戻すか（依存関係：ID、DNS、ネットワーク、アプリ、DB）・復旧が成功する根拠（テスト記録）です。

ここが未整備だと、説明責任が一気に破綻します。

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

地雷②：ログは“取れる”のに、監査や取引先に“期限内に提出できない”────────────────────────────

クラウドはログが豊富です。しかし、説明責任で問われるのは「見えるか」ではなく、

・どのログを対象にするか（認証、管理操作、ネットワーク変更、キー操作等）・保持期間はどれだけか（90日なのか、1年なのか、数年なのか）・提出期限は守れるか（何営業日以内か）・事故時に保全できるか（削除停止、隔離、抽出者記録）

です。

さらに委託運用（SOC、SIEM運用委託）が入ると、ログの所在が複雑化し「ログはあるはずだが出ない／遅い／別料金」になりがちです。ここは“契約の空白”が原因であることが多いです。

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

地雷③：委託先が入るほど“誰が何をするか”が曖昧になり、事故初動が遅れる────────────────────────────

クラウドは委託を入れやすいです。しかし委託を入れるほど、責任分界が曖昧だと説明が割れます。

典型的な崩れ方・委託先は「監視はするが復旧は別」・自社は「復旧までやってくれると思っていた」・経営は「Microsoftが何とかするのでは？」・法務は「ログは出せる前提で話をしていた」

この状態で事故が起きると、“復旧”より先に“責任者探し”が始まります。説明責任は、事故対応の速度そのものに直結します。

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

5. どう整理すればいいか：説明責任を崩さない「3つの整理フレーム」────────────────────────────

Azureの説明責任は、全部を完璧にするより「最低限これだけ揃える」方が現実的です。おすすめの整理軸は次の3つです。

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

整理軸①：タスク別RACIで「誰が何を担うか」を固定する────────────────────────────

レイヤー（OS層、NW層）で議論すると揉めるので、“やること（タスク）”で切ってRACI（R=実行、A=最終責任、C=相談、I=共有）にします。

最低限入れるべきタスク例・ID／特権運用：MFA、条件付きアクセス、PIM、Break-glass・ネットワーク：NSG、Firewall、WAF、公開範囲、例外運用・秘密情報：Key Vault、証明書、鍵、ローテーション・ログ：収集範囲、保持期間、提出、保全・バックアップ／DR：RTO/RPO、復旧手順、復旧テスト、証跡・インシデント：一次通知、封じ込め、保全、報告書、再発防止・委託管理：特権アクセス統制、再委託（国外含む）、契約終了時の出口

ポイント委託先がR（実行）でも、A（最終責任）と対外説明主体は自社に残る項目が多い。この前提で設計すると、社内説明が割れません。

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

整理軸②：「説明に必要な成果物（証跡パック）」を先に定義する────────────────────────────

説明責任を果たすために必要なのは、技術資料だけではありません。“証跡として出せる形”が重要です。最低限、次を「証跡パック」として定義します。

証跡パックの最低ライン（例）・責任分界（RACI）1枚・重要システムのRTO/RPOと復旧優先順位・復旧手順書（誰が、どの順番で、どこに復旧するか）・復旧テスト記録（いつ、誰が、何を、結果どうだったか）・特権アクセス台帳（常設／期限付き、付与理由、承認者）・例外運用台帳（NSG例外、条件付きアクセス例外等：理由・期限・解除計画）・ログ一覧（何を、どこに、どれだけ保持）・ログ提出手順（提出期限・形式・承認）・事故時保全手順（削除停止、隔離、抽出者記録）・委託先の作業証跡（変更管理：チケット・承認・実施者・ロールバック）

“ログがある”ではなく、**“提出できる”**状態にすることがゴールです。

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

整理軸③：委託契約・規程に「事故対応の義務」を落とす────────────────────────────

説明責任が崩れる最大要因は、委託契約に「事故対応の義務」が入っていないことです。運用委託（MSP/SOC/SIEM）を入れるなら、最低限ここを契約（条項または別紙SOW）に落とします。

契約で固めたい最低ライン（例）・一次通知：検知から何分以内、どのチャネルで・ログ提出義務：提出期限・形式・対象範囲・保全協力：削除停止・隔離・抽出者記録への協力・調査協力：原因分析、再発防止情報の提供・特権アクセス統制：個人アカウント、期限付き、承認、操作ログ・再委託（国外含む）：条件、範囲特定、監督責任、同等義務の貫通・契約終了（出口）：アクセス剥奪証明、設定・記録・ログの引渡し、削除証明

ここまで入ると、事故時に「材料が集まらない」問題が一気に減ります。

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

6. ケーススタディ（匿名化）：技術は整ったのに“説明できず”に後戻りした例────────────────────────────

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

背景・Azure移行（IaaS＋PaaS混在）を短期間で実施・IDはEntra ID、監視は委託SOC、ログはSIEMへ集約・バックアップもAzure Backupで取得し、運用も委託先を活用

起きたこと・取引先から「BCP（復旧時間）と証跡（ログ提出）」の照会・社内では「SLAの説明」と「RTO/RPOの説明」が混ざって回答が割れる・委託先がログを持っているが、提出期限と形式が契約に明記されておらず遅延・例外運用（条件付きアクセスの除外、NSGの暫定開放）が台帳化されておらず、統制説明が弱い・結果として、技術を作り直す前に「規程」「台帳」「契約別紙」「証跡パック」を後追いで整備することになり、二重コストが発生

改善で効いたこと・タスク別RACIを作り、対外説明の主語と承認者を固定・証跡パックを定義（復旧テスト記録、特権台帳、例外台帳、ログ提出手順）・委託契約別紙にログ提出・保全協力・特権アクセス統制を明記

結果・「技術は動く」から「説明できる」へ移行でき、取引先照会の回答が安定したという流れです。

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

7. 今すぐ確認できるチェックリスト（説明責任の自己診断）────────────────────────────

□ Azureの責任を「原因責任／契約責任／説明責任」に分けて社内説明できる

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

□ 重要システムごとのRTO/RPOと復旧優先順位が決まっている

□ 復旧手順書があり、復旧テストの記録（証跡）が残っている

□ ログの保持期間・提出期限・提出形式が決まっている

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

□ 特権アクセス（管理者権限）は台帳化され、期限・承認・剥奪が統制できる

□ 例外運用（NSG開放、条件付きアクセス除外等）が台帳化され、期限・解除計画がある□ 委託先に「一次通知／ログ提出／保全協力／特権統制」の義務が契約で入っている

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

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

「すべてYES」と言える企業は、全国的に見てもまだ多くありません。逆に言えば、ここを整えた企業は“強い”です。説明ができるからです。

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

8. まとめ：Azureの説明責任は「事故対策」ではなく「経営の基礎体力」────────────────────────────

Azureは、技術の自由度が高い反面、責任の主語が増えます。だからこそ、Azureを使う企業が必ず一度は向き合うべきなのが「説明責任」です。

・誰が何を担うのか（RACI）・何を根拠として出せるのか（証跡パック）・委託先に何を義務として求めるのか（契約・規程）

この3点が揃うと、事故が起きても、監査が来ても、取引先に聞かれても、「説明できる会社」になります。

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

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

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

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

・Microsoft／委託先／自社の責任分界を“事故対応まで”1枚にしたい・ログ提出・保全・特権アクセス統制を、委託契約別紙に落としたい・RTO/RPOと復旧テストの証跡を、取引先説明に耐える形にしたい・例外運用（条件付きアクセス、NSG等）を台帳と規程で回したい

といったお悩みがあれば、オンライン（全国対応）で初回のご相談を承っています。お問い合わせの際に「説明責任の記事を見た」と書いていただけるとスムーズです。

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

※本記事は一般的な情報提供です。実際の整理ポイントは、利用サービス、委託範囲、取引先要件、データ種別により変わります。────────────────────────────