【クラウド法務】ベンダーの説明資料が、社内説明にそのまま使えない理由― Azure / M365 / Entra ID の提案書が“立派”でも、経営・監査・取引先の前で詰まるのはなぜか ―

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

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

はじめに

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

ベンダーから届く提案資料は、構成図もロードマップも綺麗で、読めば「確かに良さそうだ」と思える。

ところが、その資料をそのまま社内に回した途端、質問の方向が変わって詰まる会社があります。

「それ、誰が責任を持つの？」

「事故が起きたら、誰が・いつまでに・何をするの？」

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

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

情シスとしては、技術的な内容は理解できるのに、社内説明（経営・監査・法務・購買・現場）になると、ベンダー資料が“使えない”感覚が残る。

本記事では、その理由を「構成の話」ではなく「説明責任の話」として整理し、ベンダー資料を“社内で通る説明”に変換するためのフレームを提示します。

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

技術構成の“事実整理”：ベンダー資料は「導入するための資料」で、社内説明は「引き受けるための資料」

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

まず前提として、ベンダーの説明資料が社内説明に使えないのは、ベンダーが下手だからではありません。

資料の目的（読者）が違うからです。

ベンダー資料の目的（多い順）

・提案の魅力を伝える（機能、構成、効果、価格、スケジュール）

・比較に勝つ（他社との差別化、標準、推奨）

・プロジェクトを前に進める（体制、進め方、マイルストーン）

一方、社内説明の目的はこうです。

・会社として“引き受ける範囲”を決める（責任、義務、期限）

・引き受けた後に“説明できる状態”を作る（証跡、例外、委託、保全）

・意思決定の主語を固定する（誰が決めたか、誰が承認したか）

ここがズレると、こうなります。

ベンダー資料を読んだ技術担当は「いけそう」と思う。

でも社内の質問は「いけそう」では終わらない。

（よくある社内質問の変化）

・構成の質問：

「Hub-Spoke？NSG？条件付きアクセス？」

→ これはベンダー資料で答えられる

・説明責任の質問：

「誰が設定を承認した？例外は期限管理される？ログ提出は何営業日以内？」

→ これはベンダー資料だけでは答えられない

ここで一度、ベンダー資料の典型的な“目次”を言語化します。

（典型的なベンダー資料の目次例）

現状課題とTo-Be（ゼロトラスト、標準化、可用性）

提案アーキテクチャ（Azure/M365/Entra ID、SIEM、BCP）

方式（ログ統合、認証、ネットワーク、バックアップ）

導入ステップ（PoC→本番、移行計画）

体制（ベンダーのチーム、窓口）

スケジュール、見積

付録（SLA、用語、製品説明）

技術としては十分です。

しかし社内説明で問われるのは、付録にすら入らない領域です。

・誰が（主語）：一次通知、封じ込め、保全、提出、対外説明の責任者は？

・いつまでに（期限）：何分以内、何営業日以内、RTO/RPOは？

・何を根拠に（証跡）：どのログを、どこに、どれだけ、誰の責任で保持？

・例外はどう戻す：暫定開放、除外、緊急権限の期限・解除条件は？

・委託は義務か：SOC/MSP/SIerが何を“義務として”やるのか（SOW）は？

つまり、ベンダー資料が強いのは「作る」側の説明。

社内説明が必要とするのは「引き受ける」側の説明です。

ここまでは技術の話。

ここからが法務・説明責任の話です。

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

2. ベンダー資料が社内説明に使えない“法務・運用の地雷”3選

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

社内説明で詰まる会社は、ほぼ次の3つのどれかで詰まります。

（技術は合っているのに、説明が通らないポイントです）

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

地雷①：「主語」が書かれていない（責任分界がレイヤー止まり）

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

ベンダー資料の責任分界は、こう書かれがちです。

・Microsoft：クラウド基盤

・ベンダー：設計・構築・運用支援

・自社：利用者管理、運用判断

社内が知りたいのは、こういうレイヤーではなくタスクです。

・事故時の一次通知は誰がやる？（何分以内に、誰へ）

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

・ログ保全（削除停止・隔離・抽出者記録）は誰がやる？

・ログ提出（期限・形式・承認・提出者）は誰がやる？

・例外（CA除外、NSG暫定開放）の承認・延長・解除は誰が責任を持つ？

・対外説明文の承認者は誰？

この“主語”が資料にないと、社内説明で必ずこうなります。

「それ、情シスがやるって決めたの？」

→ 決めてないのに、矢面に立つのは情シス

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

地雷②：「期限」が書かれていない（SLAと“約束された復旧”が混ざる）

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

ベンダー資料にはSLAが出てきます。

しかし社内説明で問われるのは、SLAよりも「期限」です。

・ログ提出は何営業日以内に？

・重大インシデントの一次報告は何分以内に？

・復旧は何時間で？（RTO）どこまで戻る？（RPO）

・例外はいつ解除する？（期限と見直し条件）

SLA（稼働率）と、復旧の約束（RTO/RPO）は別物です。

ここが混ざると、経営・監査・取引先の前で説明が崩れます。

ベンダー資料は「こういう構成なら可用性が高い」を語りやすい。

社内は「何時間で戻ると約束できるのか」を決めたい。

このズレで“使えない”が起きます。

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

地雷③：「証跡・例外・委託」が成果物になっていない（“出せる”が言えない）

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

社内説明で詰む代表がこれです。

ベンダー資料ではこう書けます。

「ログはSIEMに集約します」

「監査ログを有効化します」

でも社内説明で必要なのは次です。

・どのログを対象にする？（Sign-in/Audit/Activity/Resource/M365監査 等）

・保持期間は何年？（契約・規制・業界基準と整合？）

・何営業日以内に提出できる？（形式、項目、マスキング）

・外部提出の承認者は？

・事故時の保全（削除停止）と抽出者記録は？

・委託先が絡むなら、提出・保全・記録提供は“義務”として担保されている？（SOW）

「ログはある」のに「提出できない」

「例外はある」のに「期限管理できない」

「委託している」のに「契約上の義務ではない」

この3つが社内説明で噴き出すと、ベンダー資料はそのままでは使えません。

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

3. 対策のフレーム：ベンダー資料を“社内で通る説明”に変換する3枚重ね

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

結論から言うと、ベンダー資料を捨てる必要はありません。

ベンダー資料の上に「足りない3枚」を重ねると、社内説明で通るようになります。

（社内説明で必要な3枚）

スコープ定義（どこまでの話か）

タスク別RACI（誰が何をするか）

証跡・例外・契約のパック（何を根拠に言い切るか）

順に説明します。

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

フレーム①：スコープ定義を1枚で固定する（話が広がる前に止める）

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

社内説明が壊れる大きな原因は「対象範囲が増殖する」ことです。

まず、1枚で固定します。

スコープシートに入れるべき項目（例）

・対象：テナント／サブスク／サービス（Azure, M365, Entra ID等）

・対象環境：本番／開発／子会社／海外拠点を含むか

・対象データ：個人情報、機微情報、設計情報などの扱い

・委託範囲：SOC/MSP/SIerが関与する範囲

・説明先：経営／監査／取引先（何を出す必要があるか）

これがないと、ベンダー資料の「提案範囲」と社内の「想定範囲」がズレます。

ズレた瞬間に「使えない」になります。

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

フレーム②：タスク別RACIで“主語”を固定する（レイヤーではなく、やること）

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

社内説明の核心は主語です。

RACI（Responsible/Accountable/Consulted/Informed）でタスク別に固定します。

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

・一次通知（重大度基準、何分以内、誰へ）

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

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

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

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

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

・例外承認／延長／解除（期限管理）

・委託先作業記録の提供（実施者・時刻・内容）

ポイント：A（最終責任）は個人名ではなく“役割名”で固定する。

担当者が変わっても説明が崩れません。

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

フレーム③：“言い切り”の根拠をパック化する（証跡・例外・契約）

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

社内説明で怖いのは「言い切ってしまうこと」です。

だから言い切りは、根拠のパックとセットにします。

A）ログ提出・保全パック（Evidence Production Pack）

・対象ログ一覧

・保持期間（標準・延長・例外）

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

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

・外部提出の承認者（役割）

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

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

・委託が絡む場合の提出ルート（SOC/MSP→自社→対外 等）

B）例外台帳（Exception Register）

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

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

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

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

・承認者（役割）

・期限（必須）

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

・補償統制（例外中の守り）

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

C）Decision Log（判断ログ）

・何を決めたか

・なぜそうしたか（代替案も一言）

・承認者（役割）

・期限と見直し条件

・影響範囲

・根拠（参照資料・規程・ログ等）

D）SOW要点（委託管理サマリ）

・一次通知（重大度と期限）が義務か

・提出協力（期限・形式・成果物）が義務か

・保全協力（削除停止等＋記録提供）が義務か

・特権アクセス統制（期限・剥奪証跡）が義務か

・例外台帳更新（登録・棚卸し・解除）が作業範囲か

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

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

これらを揃えると、ベンダー資料の「推奨」や「標準」が、社内で“説明できる約束”に変換されます。

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

4. ケーススタディ（匿名化）：ベンダー資料は立派なのに、社内説明が割れた製造業A社

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

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

背景

・業種：製造業

・拠点：日本＋欧州＋アジア

・環境：Azure＋M365＋Entra ID

・体制：運用MSP＋監視SOC（再委託あり）

・ベンダー提案：構成図、移行計画、SIEM統合、BCP案まで揃っていた

社内説明で詰まった質問

・「ログ提出は何営業日以内にできると言い切れる？」

・「事故時の保全（削除停止）を誰が実行する？」

・「条件付きアクセスの例外は増えたらどう管理して戻す？」

・「委託先が触る範囲は契約上どこまで？再委託は？」

・「その設定の判断根拠と承認者は？」

起きていたこと

・ベンダー資料は“導入の説明”としては完璧

・しかし“引き受けの説明”（主語・期限・証跡）が抜けていた

・その結果、情シス・法務・監査・購買で前提が割れ、会議が増えた

整えたこと（方向性）

・スコープを1枚化し、説明範囲を固定

・タスク別RACIを作成し、通知・保全・提出・例外・対外説明の主語を役割で固定

・ログ提出・保全パックで、提出期限・形式・承認を確定

・例外台帳で、暫定の期限・解除条件・補償統制を運用化

・SOW要点を整理し、“お願い”を“義務”として説明できる部分を明確化

・Decision Logで「推奨→意思決定」変換の根拠を残した

結果として

・社内説明が「構成の説明」から「体制と根拠の説明」へ変わり

・監査・取引先照会の想定質問に、ブレずに答えられる状態に近づいた

という流れです。

ポイントは、構成を変えたことではありません。

説明の部品を揃えたことです。

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

5. 自社で検討するときのチェックリスト

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

ベンダー資料が社内でそのまま使えない会社は、次のどれかが不足しています。

YESが多いほど、“社内用への変換”が必要です。

【スコープ】

□ 対象テナント／サブスク／拠点（海外・子会社）を1枚で説明できない

□ PoC範囲と本番範囲の違いが資料に出ていない

【主語（責任分界）】

□ レイヤー分界は説明できるが、タスク別の主語が言えない

□ 一次通知・保全・提出・対外説明の責任者が役割で固定されていない

□ 事故対応で「止める／残す／出す」の主語が割れる

【期限】

□ 「対応可能」「24/7可能」が多いが、期限（何分以内／何営業日以内）がない

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

【ログ・証跡】

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

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

□ 証跡の保管場所と提示責任者（Evidence Index）がない

【例外】

□ 条件付きアクセス除外、暫定開放、常設特権が増えている

□ 例外台帳がなく、期限・解除条件・補償統制が回っていない

□ 「忙しいから後で」が恒久化している

【委託・契約】

□ MSP/SOC/SIerの提出協力・保全協力・記録提供がSOWで義務化されていない

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

□ 委託先の特権アクセス統制（期限・剥奪証跡）が言い切れない

【意思決定】

□ “推奨”で進んだ設定の判断根拠と承認者が残っていない

□ Decision Log（判断ログ）がない

YESが3つ以上ある場合、ベンダー資料をそのまま社内説明に使うのは難しいです。

逆に言えば、スコープ／RACI／証跡パック／例外台帳／SOW要点を揃えるだけで、社内説明の通り方が大きく変わります。

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

6. まとめ：ベンダー資料が使えないのは“資料が悪い”のではなく「説明の目的が違う」から

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

ベンダーの説明資料が社内説明にそのまま使えない理由はシンプルです。

・ベンダー資料は「導入するため」の資料

・社内説明は「引き受けるため」の説明

・社内は主語・期限・証跡・例外・委託（義務）を聞いてくる

・そこが資料に無いと、説明が割れ、情シスが背負う

だから、ベンダー資料の上に次の3枚を重ねるのが最短です。

スコープ定義

タスク別RACI（主語）

証跡・例外・契約（言い切りの根拠）

これが揃うと、社内説明は「構成の紹介」から「説明責任の設計」になり、

監査・取引先・経営の前で詰まりにくくなります。

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

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

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

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

ベンダー資料を社内で通る形に変換するための「クラウド法務支援」（スコープ／RACI／証跡パック／例外台帳／判断ログ／SOW整合）を行っています。

・提案資料はあるが、社内説明の質問に耐えられない

・責任分界（主語）と提出期限（期限）を言い切れる形にしたい

・ログ提出・保全、例外運用が“説明できない”状態になっている

・委託（SOC/MSP）の範囲を契約上の義務として固めたい

・「ベンダー推奨」を「会社の意思決定」として残したい

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

お問い合わせの際に「ベンダー資料が社内で使えない記事を見た」と書いていただけるとスムーズです。