【クラウド法務】ベンダー提案が「構成の話」から始まると、あとで苦しくなる理由― Azure / M365 / Entra ID の“立派な構成図”があるのに、監査・取引先・経営説明で詰む会社の共通点 ―

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

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

はじめに

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

クラウド導入の相談で、最初に出てくるのは大体「構成図」です。

ベンダーから提示される提案資料も、だいたいこう始まります。

「Azure Landing Zoneはこう設計します」

「ゼロトラストはこう実装します」

「SIEMはSentinelで統合します」

「バックアップ／DRはこの構成です」

技術寄りの担当者としては、正直ありがたい。議論が進むし、社内もイメージしやすい。

ところが導入が進み、運用が回り始めた数ヶ月〜数年後、監査・取引先・親会社・経営の質問が来た瞬間に、急に苦しくなる会社があります。

「その設定は誰が承認した？」

「障害や事故のとき、誰が・どこまで・いつまでに対応する？」

「ログは何営業日以内に提出できる？保全（削除停止）は？」

「“できる”と言っているが、それは義務？ベストエフォート？」

構成図は立派なのに、説明が通らない。

原因は、技術が弱いからではありません。

“構成の話”から始めたせいで、体制・契約・証跡の設計が後回しになり、後から回収不能になるからです。

本記事では、なぜ「構成から始まる提案」が後で効いてくるのかを、技術→法務→運用の順で整理し、苦しくならないためのフレームまで落とし込みます。

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

技術構成の“事実整理”：ベンダー提案が「構成から始まる」典型パターン

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

多くの企業で、ベンダー提案の初手はこうです。

（典型提案：テキスト構成図）

・ID基盤：Entra ID（条件付きアクセス、MFA、PIM、break-glass）

・ネットワーク：Hub-Spoke、VNet、NSG、Firewall、WAF

・基盤標準：Azure Policy、タグ、RBAC、監査設定

・ログ統合：Log Analytics＋SIEM（Sentinel等）、アラート、インシデント

・BCP：Azure Backup、Site Recovery（必要ならマルチリージョン）

・運用：MSPが監視・運用、SOCが一次検知、重大時はエスカレーション

ここまでが「構成の話」です。

この話はもちろん必要ですし、導入初期の合意形成には効きます。

ただ、構成図には“書かれていないこと”があります。

それは、後で必ず問われる次の3点です。

その構成を前提に、誰が何をする義務なのか（責任分界）

事故・監査・取引先照会のとき、何をどの期限で出せるのか（証跡提出能力）

例外（暫定・除外・緊急対応）が増えたとき、どう管理して戻すのか（統制）

構成図は“部品の地図”であって、

「説明責任の地図」ではありません。

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

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

2. ベンダー提案が「構成の話」から始まると、あとで苦しくなる理由（よくある地雷5選）

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

「構成から始める」こと自体が悪いのではありません。

悪いのは、構成が先に固まり、あとから“主語・期限・証跡”を当てはめようとして破綻することです。

実務で特に多い地雷を5つに絞ります。

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

地雷①：「要件」が“言葉”のまま進み、契約に落ちない（＝後で約束が割れる）

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

構成提案の序盤は、要件がふわっとしがちです。

・高可用性にします

・セキュリティを強化します

・監査に耐えられるようにします

・ログは取ります

・24/7対応可能です

構成図としては成立します。

しかし、この言葉は事故や監査でこう問われます。

「高可用性って、RTO/RPOは何時間？」

「監査に耐えるって、保持期間は何年？提出は何営業日以内？」

「24/7対応“可能”って、義務？ベストエフォート？」

ここで“約束の定義”がないと、社内外の期待値がバラバラになります。

特に危険なのが「SLA」と「約束された復旧」を混ぜることです。

・SLA（稼働率）＝クラウド提供側の約束の要素

・RTO/RPO（復旧時間／復旧地点）＝利用者側の設計・運用・判断が大きい

構成から始めると、SLAの話が先に出て、RTO/RPOと運用手順（テスト記録）が後回しになりがちです。

その結果、後で「説明できない」になります。

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

地雷②：責任分界が“レイヤー説明”のままで、事故対応タスクの主語が消える

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

構成提案では、責任分界がこう説明されがちです。

・Microsoft：クラウド基盤

・ベンダー：構築・運用

・自社：アカウント管理、業務アプリ

一見わかりやすいですが、事故・監査が聞きたいのは“レイヤー”ではありません。

聞きたいのは“タスクの主語”です。

・一次通知（検知から何分以内に誰が誰へ）

・封じ込め（権限剥奪、通信遮断：誰が判断し誰が実行する）

・ログ保全（削除停止、隔離、抽出者記録：誰がいつやる）

・ログ提出（何営業日以内、形式、承認者：誰が出す）

・対外説明（文面承認：誰が責任を持つ）

構成から入ると、ここが後回しになり、いざという時に「SOCがやるはず」「MSPの範囲外」「情シスがやるべき」など主語が割れます。

その瞬間に“説明責任が崩れる”ので、技術の正しさは評価されません。

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

地雷③：ログは集めたのに「提出能力」と「保全能力」が設計されていない

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

構成提案でよくあるのが「ログはSIEMに集約します」です。

しかし、照会や監査で問われるのは次です。

・どのログを対象にするか（Sign-in／Audit／Activity／Resource等）

・保持期間は何年か（規制・業界要求・契約要求に整合するか）

・何営業日以内に提出できるか

・提出形式は何か（項目、時刻基準、マスキング）

・誰の承認で外部提出するか

・事故時に削除停止（保全）できるか

・抽出者記録（いつ誰がどう取得したか）は残るか

「ログはある」では足りません。

**“期限内に、提出できる形で、必要なら保全できる形”**であることが求められます。

構成から始めると、ログの“収集”までで満足し、提出・保全・承認（プロセス）が置き去りになります。

後から整えようとすると、委託先の作業範囲や追加費用、権限設計の変更が絡み、苦しくなります。

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

地雷④：例外（暫定・除外・緊急）が積み上がり、構成図が現実を表さなくなる

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

構成図は“理想の原則”で描かれます。

でも運用では例外が必ず発生します。

・条件付きアクセスの除外

・NSGの暫定開放

・PIMのはずが常設特権

・break-glassの運用逸脱

・Key Vaultの期限管理の抜け

構成から始めると、例外を「運用で回すもの」として制度化せず、

「忙しいから後で」「いったん暫定で」が恒久化しやすくなります。

監査や取引先が見ているのは、“原則の構成図”ではありません。

“例外が管理されているか”です。

例外台帳（期限・解除条件・補償統制）がないと、後から深掘りが止まりません。

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

地雷⑤：委託（SOC/MSP/SIer）が増えるほど、契約（SOW）が薄いと材料が集まらない

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

構成提案は「運用も含めて支援します」で終わりがちです。

しかし後で問われるのは「何が義務か」です。

・一次通知は何分以内が義務？

・ログ提出は何営業日以内が義務？

・保全（削除停止）協力は義務？

・作業記録（実施者・時刻・内容）は成果物？

・再委託（国外・海外SOC）の範囲と監督責任は？

・契約終了時にアクセス剥奪証明は出る？

SOW（委託契約別紙）に落ちていないことは、事故や照会の時に「やれない／確約できない／別料金」で返ってきます。

結果、期限内に説明材料が揃わず、苦しくなります。

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

3. 苦しくならないための「整理のフレーム」：構成の前に“説明の設計”を置く

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

ここが本題です。

構成の話は必要です。ただし順番が違います。

おすすめは、構成の前に次の「説明の設計」を置くことです。

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

整理軸①：まず「説明先」を固定する（誰に、何を、どの期限で説明するのか）

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

構成を決める前に、先にこれを決めます。

・監査（社内／親会社／外部）に何を出す必要があるか

・取引先に何営業日以内に何を出す必要があるか

・事故時の第一報（何分以内／何時間以内）で何を言う必要があるか

・海外拠点や越境が絡むなら、誰がどの根拠で説明するか

“説明先”が固定されると、ログ保持や提出形式、承認体制が逆算できます。

構成はその結果として決まるべきです。

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

整理軸②：タスク別RACI（主語）を先に作る（構成ではなく“やること”で分ける）

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

構成図より先に、事故・照会・監査で必ず聞かれるタスクの主語を固定します。

最低限のタスク（これで8割は止まります）

・一次通知（検知から何分以内、誰が誰へ）

・封じ込め（権限剥奪・通信遮断：判断者と実行者）

・ログ保全（削除停止・隔離・抽出者記録）

・ログ提出（期限・形式・承認・提出者）

・復旧判断（BCP発動、切替の決裁）

・対外説明（文面承認者）

・例外承認／延長／解除

・委託先管理（再委託含む）

ポイント

A（最終責任）を個人名ではなく役割名で置く。

担当者交代で崩れません。

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

整理軸③：「証跡パック」を先に定義する（ログ収集より、提出・保全の設計）

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

ログ設計の順番を逆にします。

・提出期限（何営業日以内）

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

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

・抽出者記録（いつ誰がどう取得）

・保全手順（削除停止・隔離・アクセス制限）

・保持期間（契約・規制・監査要件と整合）

これを決めてから、SIEM／Log Analytics／監査ログの設定に落とします。

順番が逆だと、後から必ず苦しくなります。

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

整理軸④：例外台帳を“初日から”回す（暫定を暫定で終わらせる）

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

例外は必ず発生します。だから台帳が最初から必要です。

例外台帳の最小項目

・例外ID（チケット番号）

・対象（CAポリシー名、NSG名、ロール名等）

・例外内容（何を緩めたか）

・理由（当時の事情：一文でOK）

・承認者（役割）

・期限（必須）

・解除条件（何が終われば戻すか）

・補償統制（監視強化、送信元限定、時間帯制限等）

・次回レビュー日

・解除完了証跡（いつ誰が戻したか）

“構成が正しい”は、例外が管理されている前提で初めて通用します。

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

整理軸⑤：SOW（委託別紙）で「お願い」を「義務」に変換する

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

運用委託やSOCを使うなら、後で詰まらないためにSOWで最低限ここを固めます。

・一次通知（重大度基準と通知期限）

・ログ提出（期限・形式・成果物）

・ログ保全協力（削除停止等、実施記録の提供）

・特権アクセス統制（期限、付与理由、剥奪証跡）

・例外台帳の更新・棚卸し・解除（作業範囲に入れる）

・再委託（国外・海外SOC）の範囲と監督責任

・契約終了時の出口（アクセス剥奪証明、ログ引継ぎ、削除証明）

構成から始める提案は、ここが薄いまま進みやすいので要注意です。

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

4. ケーススタディ（匿名化）：構成から始めて、後で“説明だけ”詰まったA社

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

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

背景

・製造業A社（日本＋海外拠点）

・Azure上に基幹周辺、M365/Entra IDで統合

・ベンダー提案はLanding Zone＋SIEM＋運用委託からスタート

・構成図は非常に綺麗で、導入自体は予定通りに進んだ

数ヶ月後〜1年後に起きたこと

・取引先から「ログ提出は何営業日以内？」の照会

・親会社監査で「例外（CA除外・暫定開放）の期限管理は？」の質問

・事故想定訓練で「保全（削除停止）は誰がやる？」で主語が割れた

詰まったポイント

・ログはSIEMに集約していたが、提出形式・期限・承認者が決まっていない

・例外台帳がなく、“当時の判断”が説明できない

・MSP/SOCの作業範囲がSOWに落ちておらず、提出・保全がベストエフォート扱い

・レイヤー分界で説明していたため、タスク別主語が割れて会議が増えた

立て直し（方向性）

・タスク別RACIを作成し、事故・照会の主語を固定

・証跡パック（提出期限・形式・承認・保全）を定義

・例外台帳を整備し、期限・解除条件・補償統制を後付け（延長は再承認）

・SOWを更新し、通知・提出・保全協力・記録提供を義務化

結果

・構成は変えずに、「説明が通る」状態へ戻せた

・照会対応が早くなり、監査の深掘りが減った

という流れです。

ポイントは、構成を否定したのではありません。

構成の前提になる“説明の設計”が抜けていたのが原因です。

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

5. 自社で確認できるチェックリスト（構成の話から始めて苦しくなりそうな兆候）

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

次のYESが増えているほど、「構成から始めたツケ」が後から来やすい状態です。

□ ベンダー提案の議論が、最初から構成図・サービス選定中心で進んでいる

□ 「対応可能」「監査に耐える」など抽象語が多く、期限や成果物が決まっていない

□ SLAとRTO/RPOの話が混ざっている（復旧の約束が言えない）

□ 事故対応で「止める/残す/出す」の主語が割れる（RACIがない）

□ ログは集約しているが、提出期限・形式・承認者が決まっていない

□ ログ保全（削除停止・隔離）と抽出者記録の手順が弱い

□ 条件付きアクセスの例外や暫定開放が増えているが、例外台帳がない

□ “忙しいから後で”が恒久化している（期限・解除条件がない暫定がある）

□ 委託（SOC/MSP）を使っているが、SOWで提出・保全・記録提供が義務化されていない

□ 再委託（国外・海外SOC）の関与範囲と監督責任が説明できない

YESが多い場合、構成を追加する前に「説明の設計」を入れた方が、結果的に早く・安く・荒れずに進みます。

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

6. まとめ：構成は“手段”。先に決めるべきは「主語・期限・証跡」

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

ベンダー提案が構成の話から始まると、あとで苦しくなる理由は明確です。

・構成図は立派でも、事故・監査・照会で問われるのは主語・期限・証跡

・構成が固まった後に主語・期限・証跡を当てはめると、委託・権限・費用が絡み回収不能

・「できる」と「義務」を混ぜると、言葉が約束になって自社を縛る

・例外が制度化されていないと、原則設計の正しさが相殺される

だから、構成の前に次を置くのが正解です。

・説明先の固定（誰に何をどの期限で）

・タスク別RACI（主語）

・証跡パック（提出・保全・承認）

・例外台帳（期限・解除・補償統制）

・SOW整合（お願い→義務）

これが揃うと、構成の議論が“技術の話”で終わらず、

「説明できるクラウド」になります。

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

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

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

山崎行政書士事務所では、Azure / M365 / Entra ID 等の技術構成と、契約・規程・監査対応をセットで整理し、

ベンダー提案が「構成の話」から始まっても、後で苦しくならないように、責任分界（RACI）・証跡パック・例外台帳・SOW整合まで落とし込む「クラウド法務支援」を行っています。

・構成図はあるが、監査・取引先照会で詰まり始めた

・ログ提出や保全、一次通知など“期限付きの約束”が固まっていない

・SOC/MSP/再委託が絡むと主語が割れ、説明がブレる

・「対応可能」「ベストエフォート」が混ざって怖い

・例外（暫定開放、CA除外、常設特権）の恒久化を止めたい

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

お問い合わせの際に「構成の話から始まると苦しい記事を見た」と書いていただけるとスムーズです。