【クラウド法務】クラウド導入で“顧問やSIerでは説明しきれない”と感じたときの視点― 技術も契約も揃っているのに、なぜ「説明」が崩れるのか。間にある“責任の設計”を見落とさない ―（キーワード：クラウド導入／説明責任／責任分界／運用委託／監査証跡）

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

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

はじめに

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

クラウド導入が進むと、技術資料は揃ってきます。SIerからは構成図と運用設計、顧問（顧問弁護士や顧問の士業）からは契約レビューやリスクコメントも出る。にもかかわらず、ある日突然こう感じる瞬間があります。

「これ、誰がどう説明するのが正解なんだろう」「顧問もSIerも、どちらも“それぞれ正しい”のに、つながらない」

典型的には、監査・親会社統制・取引先のセキュリティ審査・BCP確認・事故対応の局面で、質問の矢が一気に飛んできます。・「この構成で、どこまでがMicrosoftで、どこからが自社責任？」・「委託先が触る範囲は？特権アクセスは統制できている？」・「ログは“取れる”ではなく“提出できる”？保持期間は？」・「復旧は何時間？RTO/RPOは根拠付きで言える？」・「海外拠点や海外SOCが関与するなら、越境・再委託は説明できる？」

このとき必要なのは「追加の技術」や「追加の契約レビュー」ではなく、**“説明責任の設計”**です。本記事では、顧問やSIerでは説明しきれないと感じたときに見るべき視点を、実務で使える形に整理します。

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

1. 技術構成の“事実整理”：資料が揃っているのに説明が崩れる構造────────────────────────────

まず、クラウド導入プロジェクトで「成果物として揃いやすいもの」と「抜けやすいもの」を分けます。

揃いやすいもの（多くのプロジェクトで出てくる）

・アーキテクチャ図（VNet、NSG、Firewall/WAF、VM/PaaS、接続）

・ID設計（Entra ID、MFA、条件付きアクセス、PIM等の方針）・監視設計（Azure Monitor、Log Analytics、SIEM連携）

・バックアップ/DRの設計（Azure Backup、Site Recovery等）

・運用フロー（定常運用、変更管理、障害対応の流れ）

抜けやすいもの（ここが“説明不能”の原因になりやすい）

・「責任分界図」：Microsoft／自社／委託先／再委託先の“タスク別”分担

・「説明ストーリー」：監査や取引先に、根拠とセットで話せる筋道・「証跡パック」：ログや台帳を“期限内に提出できる状態”にしたセット

・「例外台帳」：NSGの暫定開放、条件付きアクセス除外、Break-glass運用などの期限管理

・「契約別紙（SOW）に落ちた義務」：通知

・ログ提出・保全協力

・特権アクセス統制・再委託条件

つまり、技術資料と契約レビューがあっても、“説明に必要な成果物（責任分界＋証跡＋義務）”が抜けていると、質問に答えられません。

（ここまでは技術の話。ここからが法務・運用の地雷の話です。）

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

2. 「顧問やSIerでは説明しきれない」と感じる理由：よくあるズレ3選────────────────────────────

顧問とSIerが悪い、という話ではありません。役割が違うので、“間（あいだ）”が空白になりやすいのが問題です。典型を3つに絞ります。

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

ズレ①：顧問は契約を見られるが、“クラウド前提の運用証跡”まで設計しない────────────────────────────

顧問側は、契約条項のリスク（免責、損害賠償、秘密保持、個人情報、委託管理など）を見ます。しかしクラウドでは、条項を成立させるために「運用で何を残すか」が必要です。

例：条項は整っているのに詰まるパターン・ログ提出義務があっても、保持期間・抽出手順・提出期限が運用に落ちていない・事故時の通知義務があっても、一次通知の体制（誰が何分以内に）と証跡が決まっていない・越境・再委託の条件があっても、実態（海外SOCや下請けの範囲）が整理されていない

「条項として正しい」だけでは、監査や取引先への説明が成立しない。ここが“顧問だけでは説明しきれない”と感じる一因です。

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

ズレ②：SIerは技術を作れるが、“対外説明の主語”と“義務の貫通”を成果物にしない────────────────────────────

SIerは構成を作り、運用設計も作ります。ただしプロジェクトのスコープに入っていないと、次が空白になりやすいです。

・委託先（MSP/SOC）が関与する場合の「ログ提出義務」「保全協力」「再委託条件」まで契約に落とす・“事故後の説明”を前提とした証跡パック（何を、どこに、何年、誰が出す）を作る・SLA（稼働率）と、取引先が求めるRTO/RPO（復旧の約束）を切り分けて説明資料にする

SIerが作るのは「動く仕組み」で、企業が求められるのは「説明できる仕組み」。この差が、導入後に効いてきます。

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

ズレ③：委託やサービスが増えるほど、責任の主語が割れて事故初動が遅れる────────────────────────────

クラウドは関係者が増えます。Microsoft、SIer、MSP、SOC、サードパーティ、グループ会社…このとき責任の整理がないと、事故や照会でこうなります。

・「それはMicrosoftの範囲」「それは委託先の範囲」「それは自社設定」・しかし“誰が対外的に説明するか”が決まっていない・ログは存在するのに、提出ルートが不明／期限に間に合わない・緊急操作（Purge、権限停止、NSG締め、Key Vaultローテなど）の実行者と承認者が割れる

結局、復旧より先に「責任者探し」が始まり、説明が遅れます。これが“顧問やSIerだけでは埋まらない空白”です。

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

3. 視点の結論：「説明責任」を“設計対象”として扱う────────────────────────────

「説明責任」は、事故が起きたときに頑張って作文するものではありません。クラウドでは、説明責任を 設計対象（deliverable） にしておくと、後で崩れません。

ここで使える整理の軸は、次の3つです。

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

整理軸①：説明先（誰に説明するか）から逆算する────────────────────────────

説明相手によって、必要な粒度が違います。まず対象を固定します。

・社内上層（経営・役員）：リスクの主語、意思決定ポイント、BCPの約束・監査／親会社統制：統制の証跡（権限、変更管理、ログ、テスト記録）・取引先／顧客：影響範囲、SLA/RTO/RPO、事故時の通知、データ取扱い・（該当する場合）当局：保全、報告基準、越境・委託管理

「説明先が違うのに、同じ資料で答えようとして崩れる」ことが非常に多いです。ここを分けるだけで、社内の混乱が減ります。

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

整理軸②：責任分界を“レイヤー”ではなく“タスク”でRACI化する────────────────────────────

レイヤー（NW層、OS層）で揉めると終わりません。クラウドは“やること”で分けた方が説明に強いです。

最低限これだけはタスクとして切って、RACI（R=実行/A=最終責任/C=相談/I=共有）を作ります。

・ID／特権：MFA、条件付きアクセス、PIM、Break-glass、棚卸し・ネットワーク：NSG、Firewall/WAF、公開範囲、例外運用、接続障害時の切替・秘密情報：Key Vault（Secrets/Keys/Certificatesの棚卸し、期限、ローテ、権限）・ログ：収集範囲、保持期間、提出期限、提出形式、保全（削除停止・隔離）・BCP：RTO/RPO、復旧手順、復旧テスト、証跡・インシデント：一次通知、封じ込め、保全、報告書、再発防止・委託管理：特権アクセス統制、再委託（国外含む）、契約終了時の出口

ポイントはここです。委託先がR（実行）でも、A（最終責任）と対外説明の主体は自社に残る項目が多い。だからこそ、委託先に求める義務（通知・提出・保全協力）を契約で固定します。

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

整理軸③：「証跡パック」を作る（“ログがある”ではなく“提出できる”）────────────────────────────

説明責任で一番詰まるのは、原因究明ではなく「材料が出ない」ことです。そのため、最初から“提出できる形”をセットにした「証跡パック」を定義します。

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

これがあると、監査・取引先照会・事故時の“最初の一手”が速くなります。

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

4. ケーススタディ（匿名化）：“顧問もSIerもいるのに説明が割れた”典型────────────────────────────

実務でよくある構図を匿名化して紹介します。

・業種：製造業（国内＋海外拠点）・構成：Azure（IaaS＋PaaS）、Entra ID、ログはSIEMに集約、運用はMSPとSOCを活用・体制：顧問あり、SIerあり

つまずいた場面・取引先から「BCP（RTO/RPO）とログ提出（保持期間・提出期限）」の照会・社内では「AzureのSLA」を説明しようとするが、取引先は「復旧の約束」を求めている・SOCがログを見ているが、提出期限・形式が契約で固定されておらず遅延・条件付きアクセスの例外、NSGの暫定開放が台帳化されておらず、統制説明が弱い・結果として、技術の追加より先に「説明の再設計（RACI＋証跡パック＋契約別紙）」が必要になった

立て直しの方向性・タスク別RACIで“主語”を固定（対外説明の責任者、承認者を明確化）・証跡パックを定義（復旧テスト、特権台帳、例外台帳、ログ提出手順）・委託契約別紙に「一次通知／ログ提出／保全協力／特権アクセス統制／再委託条件」を明記・結果として「説明が割れない」状態に近づき、照会対応の速度が上がった

このケースは、技術の問題ではなく、説明責任を“設計していなかった”問題です。

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

5. チェックリスト：顧問・SIerだけでは足りないと感じたら、ここを確認────────────────────────────

□ 説明先（経営／監査／取引先／当局）ごとに、必要資料と粒度が分かれている

□ Microsoft／自社／委託先の責任分界が、タスク別RACIで1枚になっている

□ SLA（稼働率）とRTO/RPO（復旧の約束）が切り分けて説明できる

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

□ ログは“取れる”ではなく“提出できる”（保持期間、提出期限、提出形式、担当）

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

□ 特権アクセス（PIM/Break-glass等）が台帳化され、期限・承認・剥奪が統制できる

□ 例外運用（NSG暫定開放、条件付きアクセス除外等）が台帳化され、恒久化しない仕組みがある

□ 委託先に、一次通知・ログ提出・保全協力・特権統制が“義務”として契約に入っている

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

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

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

6. まとめ：足りないのは“専門性”ではなく“つなぎ目の設計”

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

クラウド導入で「顧問やSIerでは説明しきれない」と感じるとき、不足しているのは、技術や法務のどちらか一方ではないことが多いです。

不足しているのは、・責任の主語を固定する設計（RACI）・説明材料を提出可能な形で揃える設計（証跡パック）・委託先の義務を運用レベルまで落とす設計（契約別紙・規程）という“つなぎ目”です。

ここを押さえると、クラウドは「動く」から「説明できる」に変わります。

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

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

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

山崎行政書士事務所では、Azureを含むクラウド導入において、技術構成（ID・ログ・BCP・運用委託）と、契約・規程・監査対応を“説明できる形”に整理する支援を行っています。

・顧問やSIerの資料はあるが、監査・取引先に一貫して説明できる形にしたい・Microsoft／委託先／自社の責任分界を、事故対応まで含めて1枚にしたい・ログ提出・保全・特権アクセス統制を、委託契約別紙と規程に落としたい・RTO/RPOと復旧テストの証跡を、BCP説明に耐える形で整えたい・例外運用（NSG、条件付きアクセス等）を台帳化して恒久化を止めたい

といったお悩みがあれば、オンライン（全国対応）でご相談を承っております。お問い合わせの際に、本記事に近い課題感があれば、その旨を共有いただければ整理がしやすくなります。