【クラウド法務】ベンダーと情シスの“暗黙の前提”が食い違う理由― 同じAzure / M365 / Entra IDの話をしているのに、後から「そんなつもりじゃ」が発生する構造 ―

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

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

はじめに

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

クラウド導入や運用委託のプロジェクトで、技術の議論はスムーズに進むのに、いざ運用や監査・取引先照会の局面で突然噛み合わなくなることがあります。

「そこは運用に含まれると思っていました」

「そこまでの義務は契約上ありません」

「ログは取っています（でも提出用に整形するのは別作業です）」

「例外は暫定のはずでした（でも戻す手順や期限が決まっていない）」

この“食い違い”は、誰かが悪いから起きるのではありません。

多くの場合、ベンダーと情シスが別々の「暗黙の前提」を持ったまま、同じ言葉を使って進めてしまうのが原因です。

本記事では、暗黙の前提が食い違う理由を構造として整理し、

「共感 → 技術的な整理 → 法務の地雷 → 対策フレーム → 具体例 → チェックリスト → 相談導線」

の順で、実務で再現できる形に落とし込みます。

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

技術構成の“事実整理”：構成図は共有できても「責任の地図」は共有されない

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

Azure / M365 / Entra ID を使うプロジェクトでは、最初に“構成図”ができます。

これは良いことです。構成図があるから議論が進みます。

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

【ID/IAM】Entra ID

・条件付きアクセス、MFA、PIM、監査ログ

　↓

【クラウド】Azure / M365

・VNet/NSG/Firewall/WAF

・VM/PaaS/Storage/Key Vault

・Backup/Site Recovery（BCP）

　↓

【ログ】

・Sign-in/Audit/Activity/Resource logs

・Log Analytics / SIEM（Sentinel等）

　↓

【体制】

・自社：情シス/CSIRT/法務/経営

・委託：SIer（構築）/MSP（運用）/SOC（監視）＋再委託（海外SOC等）

しかし、この構成図には“決定的に足りない図”があります。

それが「責任の地図」です。

構成図が答えるのは「何があるか（What）」

責任の地図が答えるのは「誰が・いつまでに・何を出すか（Who/When/Deliverables）」

監査・取引先照会・事故対応で問われるのは、ほぼ後者です。

・誰が一次通知するのか（何分以内に、誰へ）

・誰が封じ込め判断するのか（権限剥奪、通信遮断）

・誰がログ保全するのか（削除停止、隔離、抽出者記録）

・誰がログ提出するのか（期限、形式、承認）

・例外（暫定開放、CA除外）を誰が期限管理して戻すのか

・委託先が絡むなら、どこまでが義務でどこからが別作業か

ここまでは技術の話。

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

暗黙の前提の食い違いは、

「構成は共通理解があるのに、責任の地図が未作成のまま進む」

ときに発生します。

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

2. ベンダーと情シスの“暗黙の前提”が食い違う理由（よくある7つの構造）

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

「なぜズレるのか」を、現場で頻発する構造として7つに分解します。

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

理由①：同じ言葉でも、ベンダーは“契約範囲”、情シスは“期待値”で聞いている

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

たとえば「運用」「監視」「対応」という言葉。

情シスの暗黙前提

・運用＝問題が起きたら必要なことは一通りやってくれる

・監視＝検知したら封じ込めまで一緒にやってくれる

・対応＝期限内に答えられる形でやってくれる

ベンダーの暗黙前提

・運用＝契約に書かれた定常作業

・監視＝検知と一次切り分け（封じ込めは別）

・対応＝ベストエフォート（期限保証は別）

同じ言葉を使っているのに、見ている世界が違います。

このズレが、後で「そんなつもりじゃ」を生みます。

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

理由②：RFP/提案は“構成（What）”中心で、“義務（Who/When）”が後回しになりやすい

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

RFPや提案は、比較しやすい項目（構成、機能、価格、工期）が中心になりがちです。

しかし後で問われるのは、比較しにくい項目です。

・ログ提出は何営業日以内に“義務として”できるのか

・保全（削除停止）は誰が実施し、記録は誰が残すのか

・例外の期限管理と解除は、誰のタスクなのか

構成が固まった後でここを詰めようとすると、

「それは別作業」「別料金」「契約外」が出て、食い違いが顕在化します。

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

理由③：PoC/導入フェーズでは“その場でできる”が、本番では“義務としてできる”に変わる

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

PoCや導入フェーズは、ベンダー同席でその場対応が成立します。

・例外を一旦許す

・ログ抽出をその場で頼む

・緊急対応をその場でやる

しかし本番では、同じことが「義務・期限・成果物」の話になります。

PoCの成功が、“本番での約束”に誤変換されるとズレます。

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

理由④：「SLA」と「約束された復旧（RTO/RPO）」が混ざり、責任の前提が壊れる

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

情シス側は「止まったら復旧できるのか」を気にします。

ベンダー側は「SLA（稼働率）」を説明しがちです。

しかし事故や経営説明で問われるのは、SLAよりも

・何時間で戻るか（RTO）

・どこまで戻るか（RPO）

・根拠は何か（手順、テスト記録、体制）

です。

SLA＝稼働率（クラウド側の要素が大きい）

RTO/RPO＝復旧の約束（利用者の設計・運用・判断が大きい）

ここを混ぜたまま進むと、説明の前提が割れます。

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

理由⑤：「ログは取っています」が、情シスの期待する“提出能力”を含んでいない

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

ベンダーの「ログは取っています」は、だいたい“収集と保管”を指します。

情シスが照会で必要なのは“提出能力”です。

照会や監査で必ず出る追加質問

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

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

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

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

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

「ログがある」だけでは、説明できません。

ここが暗黙にズレやすい代表格です。

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

理由⑥：例外（暫定・除外・緊急）が“戻す前提”で語られるが、戻す責任と期限が決まっていない

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

移行終盤ほど例外は増えます。

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

・NSGの暫定開放

・PIMを使わない常設特権

・break-glassの運用逸脱

情シスの暗黙前提

「暫定は暫定。落ち着いたら戻る」

ベンダーの暗黙前提

「戻すには作業が必要。契約範囲か、別作業かはSOW次第」

例外台帳（期限・解除条件・補償統制）がないと、暫定は恒久化します。

恒久化した瞬間に、前提が壊れます。

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

理由⑦：意思決定の“主語”が成果物として残らず、あとから誰も説明できなくなる

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

導入中は「ベンダー推奨」で進みがちです。

しかし後で問われます。

・誰が承認した？

・なぜその設定？代替案は？

・どのリスクを受容した？

・期限と見直し条件は？

推奨＝意思決定ではありません。

意思決定が成果物（判断ログ）として残らないと、暗黙前提が崩れて食い違いになります。

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

3. 法務・説明責任の地雷：暗黙のズレが“致命傷”になるのはこの3局面

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

暗黙の前提がズレていても、平時は回ります。

致命傷になる局面は、だいたい次の3つです。

取引先照会・親会社統制

・提出期限（何営業日以内）が要求され、材料が集まらない

・「できる」と「義務」が混ざり、言い切れない

監査

・例外の期限管理と解除証跡を求められ、台帳がない

・委託範囲の説明で、SOWと実態がズレる

インシデント（事故）

・止める／残す／出すの主語が割れ、初動が遅れる

・保全（削除停止）と抽出者記録が弱く、説明が通らない

この3局面に耐えるには、暗黙を“明示”に変える必要があります。

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

4. 対策のフレーム：暗黙の前提を「主語・期限・成果物」に翻訳して固定する

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

ズレをなくす方法は、気合いではありません。

暗黙の前提を、次の順で翻訳・固定します。

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

フレーム①：用語の“定義表”を作る（運用・監視・対応・保全・提出）

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

最初に、同じ言葉を同じ意味で使うための定義表を作ります。

1ページで十分です。

例（定義のイメージ）

・監視＝検知・一次切り分けまで（封じ込めは別）

・運用＝定常作業＋契約で定義された随時作業

・対応＝対応可否ではなく「期限・成果物・責任」を含む

・保全＝削除停止＋隔離＋抽出者記録まで

・提出＝期限内に、指定形式で、承認を経て提供すること

これだけで会議の食い違いが減ります。

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

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

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

暗黙前提がズレるのは、レイヤー分界で会話しているからです。

タスクで固定します。

最低限固定したいタスク

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

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

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

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

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

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

・例外承認／延長／解除（期限必須）

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

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

フレーム③：「ログ提出・保全パック」を作る（“ある”→“出せる”へ）

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

ログに関する暗黙前提のズレは、提出能力を明示すれば止まります。

ログ提出・保全パックの最小項目

・対象ログ一覧

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

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

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

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

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

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

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

これがあると「ログは取ってます」の解釈が揃います。

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

フレーム④：例外台帳を“初日から”回す（暫定を恒久化させない）

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

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

例外台帳の最小項目

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

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

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

・理由（当時の事情）

・承認者（役割）

・期限（必須）

・解除条件

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

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

「暫定は台帳に載る」「期限が切れる前に再承認or解除」

これを仕組みにすると、暗黙前提が崩れません。

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

フレーム⑤：Decision Log（判断ログ）で「当時の判断」を成果物にする

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

暗黙前提が食い違う最大原因は、判断が記録されないことです。

短くていいので残します。

・何を決めたか

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

・承認者（役割）

・期限と見直し条件

・影響範囲

・根拠（参照資料・ログ・台帳）

担当交代・監査・事故後説明で効きます。

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

フレーム⑥：SOW（委託別紙）に“義務・期限・成果物”として落とす

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

暗黙前提をなくす最終手段は、契約に落とすことです。

SOWに最低限入れたい項目は次です。

・一次通知：重大度基準＋通知期限

・ログ提出：期限（何営業日以内）＋形式＋成果物

・ログ保全：削除停止等の協力＋実施記録提供

・作業記録：実施者・時刻・内容を成果物化

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

・例外台帳：登録・棚卸し・解除まで作業範囲化

・再委託（国外）：範囲と監督責任

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

これで「思っていた」は構造的に減ります。

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

5. ケーススタディ（匿名化）：暗黙前提のズレが“ログ提出”で噴き出したA社

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

背景

・製造業A社（国内＋海外拠点）

・Azure＋M365＋Entra ID

・監視：SOC、運用：MSP（委託）

・SIEM統合も進み、導入は順調

きっかけ

海外取引先から「インシデント時、ログは何営業日以内に提出可能か」と照会。

情シスの前提

「SIEMにログは入っているし、委託しているから提出できるはず」

ベンダー側の前提

「抽出は可能だが、外部提出用の整形・マスキング・承認支援は契約外。期限確約は難しい」

結果

・社内の法務承認、委託先の可否確認、形式調整で時間が溶け、追加照会が増えた

・技術はできているのに“説明が遅い”状態になった

立て直し

・ログ提出・保全パックを作成（期限・形式・承認・抽出者記録）

・タスク別RACIで提出と承認の主語を固定

・SOWに提出協力（期限・成果物）と保全協力、記録提供を義務化

・例外台帳も整備し、例外の説明も同時に安定化

結果として

暗黙の前提が“明示の約束”に変換され、照会対応が安定した

という流れです。

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

6. 自社で確認できるチェックリスト

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

次のYESが多いほど、暗黙前提の食い違いが起きやすい状態です。

□ 「運用」「監視」「対応」の定義が社内とベンダーで一致していない

□ レイヤー分界（Microsoft/ベンダー/自社）で止まり、タスク別RACIがない

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

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

□ 例外（CA除外、暫定開放、常設特権）に期限・解除条件がない

□ PoCで成立していた“その場対応”が、本番の義務として整理されていない

□ 委託先の一次通知・提出協力・保全協力がSOWで義務化されていない

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

□ 「対応可能」という言葉が資料に多く、前提条件・期限・成果物が書けていない

□ 当時の意思決定（なぜその設定）が判断ログとして残っていない

YESが3つ以上ある場合、次の監査・照会・事故でズレが顕在化しやすいです。

逆に言えば、定義表／RACI／証跡パック／例外台帳／SOW整合を揃えるだけで、ズレは大きく減ります。

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

7. まとめ：暗黙の前提は、放置すると“説明不能”として返ってくる

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

ベンダーと情シスの暗黙の前提が食い違うのは、

能力の問題ではなく、構造の問題です。

・同じ言葉でも、片方は契約範囲、片方は期待値で聞いている

・構成（What）は固まるが、主語・期限・成果物（Who/When/Deliverables）が固まらない

・PoCの“その場対応”が、本番の義務に変換されない

・ログは“ある”が、“出せる”になっていない

・例外が暫定のまま恒久化し、前提が崩れる

・意思決定が記録されず、後で誰も説明できない

だから、暗黙を明示に変えるために必要なのは次です。

・用語定義表

・タスク別RACI

・ログ提出・保全パック

・例外台帳

・Decision Log

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

これが揃うと、構成が立派なだけでなく、説明できるクラウド運用になります。

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

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

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

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

ベンダーと情シスの暗黙前提が食い違わないように、責任分界（タスク別RACI）・証跡パック・例外台帳・判断ログ・SOW整合まで落とし込む「クラウド法務支援」を行っています。

・運用委託しているのに、照会期限に答えられる自信がない

・ログはあるが、提出・保全・承認の型がない

・例外（暫定開放、CA除外、常設特権）が増えて説明が怖い

・「対応可能」が約束になりそうで言葉が怖い

・委託先との役割分担を“義務”として固めたい

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

お問い合わせの際に「暗黙の前提の記事を見た」と書いていただけるとスムーズです。