【クラウド法務】「そこはベンダーがやると思っていた」が起きる瞬間― Azure / M365 / Entra ID の“責任分界”が、事故・監査・照会で突然ズレる理由 ―

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

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

はじめに

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

クラウド導入や運用で、情シスが一番しんどい瞬間は「設定が分からない」ではありません。

設定は調べれば何とかなる。でも、事故・監査・取引先照会の場で突然出てくる、この一言が厳しい。

「そこ、ベンダーがやると思っていました」

しかもこの一言が出るのは、誰かがサボったからではなく、プロジェクトが順調だったときほど起きます。

構成図もあり、運用委託もあり、会議も回っていた。なのに、いざ必要な場面で“主語”が消える。

本記事では、「そこはベンダーがやると思っていた」が起きる瞬間を、技術構造と契約・統制のズレとして整理し、二度と起きないようにするための実務フレーム（RACI／SOW／証跡パック／例外台帳）まで落とし込みます。

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

技術構成の“事実整理”：クラウド運用は「関係者が多いほど主語が消える」

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

Azure / M365 / Entra ID を使った運用は、構成そのものより「関係者の多層構造」が特徴です。

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

【クラウド事業者】Microsoft

・基盤提供（サービス稼働、プラットフォーム）

　↓

【構築】SIer / ベンダー

・設計、構築、移行、初期設定、運用設計書の納品

　↓

【運用】MSP（運用代行）

・監視、パッチ、運用手順、問い合わせ一次対応

　↓

【監視】SOC（監視）

・アラート監視、インシデント一次切り分け、報告

（再委託で海外SOCが入ることも）

　↓

【自社】情シス／CSIRT／法務／経営

・最終責任、対外説明、承認、意思決定、リスク受容

この構造でややこしいのは、責任分界が「レイヤー（誰の領域）」で語られがちなのに、実際に揉めるのは「タスク（誰がやる作業）」だからです。

・ログを保全する（削除停止・隔離）

・ログを提出する（期限・形式・承認）

・特権を剥奪する（PIM、緊急権限）

・例外を期限付きで管理して解除する（CA除外、NSG暫定開放）

・一次報告を出す（何分以内、誰に、何を）

・対外説明文を承認する（誰が責任者か）

ここまでは技術の話。

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

「ベンダーがやると思っていた」が起きるのは、

“レイヤー分界は分かった気になれる”一方で、“タスク分界（義務・期限・成果物）が未確定”のまま本番に出るときです。

そして、その未確定が露呈するのは、だいたい決まった瞬間です。

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

2. 「そこはベンダーがやると思っていた」が起きる瞬間（典型7パターン）

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

この言葉が出るタイミングは偶然ではありません。

現場で特に多い“瞬間”を7つに絞ります。

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

瞬間①：監査・取引先照会で「提出期限」を聞かれたとき

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

質問はだいたいこうです。

「ログは何営業日以内に提出できますか？」

「証跡（承認記録・棚卸し記録）はすぐ出せますか？」

このとき、情シスはこう思う。

「ログはSIEMに入ってるし、ベンダーが運用してるから出せるはず」

しかしベンダー側はこう返しがちです。

「提出用の形式は別途作業です」

「抽出は可能ですが期限は確約できません（ベストエフォート）」

「外部提出は契約範囲外です」

ここで初めて、

“ログがある”と“期限内に提出できる義務がある”は別物

だと気づきます。

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

瞬間②：事故対応で「ログ保全（削除停止）」が必要になったとき

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

事故が起きると、最初に必要なのは「止める／残す／出す」です。

このうち“残す”＝保全で詰まりやすい。

・誰が削除停止を実行するのか

・誰が隔離を判断するのか

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

情シスは「SOCがやってくれる」「MSPがやってくれる」と思っている。

SOC/MSPは「判断はお客様」「保全は契約にない」と言う。

この瞬間に、説明責任が宙に浮きます。

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

瞬間③：本番直前に“暫定”が増えて、戻し作業が必要になったとき

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

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

・条件付きアクセスの除外（業務都合・端末都合）

・NSG/Firewallの暫定開放（切り分け・納期）

・PIMを使わない常設権限（作業効率）

この例外を「戻す」フェーズで、こうなります。

情シス：「暫定を戻してください（閉じてください）」

ベンダー：「戻しは追加作業です。チケットと工数が必要です」

“暫定は暫定だから自然に戻る”は、実務では成立しません。

戻す作業は、誰かの責任とコストが必要です。

そこが契約にないと、「思っていた」が起きます。

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

瞬間④：ベンダーの“推奨設定”が、社内では“決裁済み”として扱われ始めたとき

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

導入が順調なほど、こういう空気が生まれます。

「ベンダー推奨だし、それで進めていいよね」

ところが後で聞かれます。

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

「例外のリスクを受けた判断者は誰？」

「なぜその保持期間なの？」

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

推奨を“決裁”に変換するプロセス（承認・判断ログ）がないと、後で詰みます。

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

瞬間⑤：委託先が変わった／担当者が変わったとき

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

“関係性”で回っていた運用ほど危険です。

前担当：「いつもやってくれてた」

新担当：「契約に書いてないので、やりません／別料金です」

この瞬間、運用の前提が壊れます。

ここで初めて「義務として担保していない」ことが露出します。

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

瞬間⑥：PoCが終わって、ベンダー同席がなくなったとき

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

PoC中は“その場で直せる”し、ベンダーが横にいます。

本番は、契約と体制だけが残ります。

PoCで成立していたこと（例）

・例外をその場で許す

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

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

これが本番で「誰が義務としてやる？」に変換されると、宙に浮きます。

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

瞬間⑦：「SLAがあるから大丈夫」と言った直後に、復旧の約束（RTO/RPO）を聞かれたとき

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

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

でも提案・会議では混ざりやすい。

経営・取引先：「何時間で戻るの？根拠は？」

情シス：「SLAが…」

相手：「それは稼働率ですよね。復旧は？」

ここで“誰が復旧判断し、誰が切替を実行し、テスト記録があるか”が問われます。

ベンダーにやってもらう前提なら、なおさら「義務」「手順」「記録」が必要です。

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

3. 法務・説明責任の地雷：「思っていた」は、実務では“未定義”の別名

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

「そこはベンダーがやると思っていた」は、感情ではなく構造です。

地雷はだいたいこの3つに集約されます。

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

地雷①：責任分界がレイヤー説明で止まり、タスクの主語が決まっていない

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

Microsoft／ベンダー／自社、という説明は入口には便利。

でも事故・照会はタスクを聞いてきます。

・誰が通知する

・誰が保全する

・誰が提出する

・誰が承認する

ここが決まっていないと、会議で主語が割れます。

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

地雷②：SOW（作業範囲）に「やってほしいこと」が成果物として落ちていない

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

“いつもやってくれる”は義務ではありません。

SOWに落ちていないものは、現場ではこうなります。

・ベストエフォート

・別料金

・別途見積

・対応可否確認

これが照会期限や事故初動と衝突して、詰みます。

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

地雷③：例外と証跡が“運用で何とかする”扱いで、戻しと提出が設計されていない

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

例外は必ず出る。ログ提出も必ず求められる。

なのに、台帳・期限・解除条件・提出形式・承認が無い。

この状態で本番に出ると、「思っていた」が必ず起きます。

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

4. 対策のフレーム：「思っていた」をゼロにする3本柱

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

解決策は、関係者を減らすことではありません。

関係者が多い前提で、“主語・期限・証跡”を先に固定することです。

おすすめは次の3本柱です。

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

柱①：タスク別RACIを1枚にする（レイヤーではなく“やること”で分ける）

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

最低限、次のタスクの主語を固定します。

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

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

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

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

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

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

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

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

担当交代しても壊れません。

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

柱②：SOWに“義務・期限・成果物”として落とす（お願いを契約に変換する）

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

RACIで主語が決まっても、契約に落ちていなければ動きません。

SOWに最低限入れるべき項目は次です。

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

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

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

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

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

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

・再委託（国外）：範囲と監督責任、情報移転の条件

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

“そこはベンダーがやる”を本当に成立させるには、ここが必要です。

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

柱③：証跡パック＋例外台帳＋判断ログで「言い切り」を支える

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

照会・監査・事故後説明で必要なのは「言い切り」です。

言い切りは証跡がないと成立しません。

最低限の3点セット

・証跡目録（Evidence Index）：どこに何があるか

・ログ提出・保全パック：提出期限・形式・承認・抽出者記録・保全手順

・例外台帳：期限・解除条件・補償統制・解除完了証跡

（＋できればDecision Log：当時の判断を短文で残す）

これがあると、質問が来た瞬間に「想定済みです」と言えます。

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

5. ケーススタディ（匿名化）：“ログ提出”で「思っていた」が噴き出した製造業A社

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

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

背景

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

・Azure＋M365＋Entra ID、監視はSOC、運用はMSP

・SIEMにログ集約済みで、導入は順調

きっかけ

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

社内の想定

情シス：「SIEM運用は委託してるし、提出も委託先がやるはず」

実際

MSP：「ログ抽出は可能ですが“外部提出用の整形”は範囲外です」

SOC：「提出期限の確約は契約上できません」

法務：「誰の承認で外部提出するんですか？個人情報の扱いは？」

結果

・回答が遅れ、追加照会が増え、社内会議が増えた

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

立て直し

・タスク別RACIで「提出」「承認」「抽出者記録」「保全」の主語を固定

・ログ提出・保全パックを作成（提出期限・形式・マスキング・承認）

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

・例外台帳も整備し、“暫定”を期限付きに

結果として

「ベンダーがやると思っていた」を、契約と証跡で“やる義務”に変換でき、照会対応が安定した

という流れです。

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

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

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

次のYESが多いほど、「思っていた」が起きやすい状態です。

【主語】

□ レイヤー（Microsoft/ベンダー/自社）では説明できるが、タスク別に主語が言えない

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

□ 事故対応で「誰が判断し誰が実行するか」が会議で割れる

【契約（SOW）】

□ ログ提出（期限・形式）がSOWの成果物になっていない

□ ログ保全（削除停止・隔離）協力がSOWにない

□ 委託先の作業記録（実施者・時刻・内容）が成果物として出ない

□ 例外台帳更新（登録・期限管理・解除）が作業範囲に含まれていない

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

【証跡・例外】

□ 「ログはある」が「何営業日以内に出せる」に変換されていない

□ 抽出者記録（いつ誰がどう取得）が残る設計になっていない

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

□ “忙しいから後で”が恒久化している

YESが3つ以上ある場合、次の監査・照会・事故で「思っていた」が起きる確率は高いです。

逆に言えば、RACI／SOW／証跡パックを揃えるだけで劇的に減らせます。

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

7. まとめ：「思っていた」を潰すのは、構成ではなく“主語・期限・証跡”

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

「そこはベンダーがやると思っていた」が起きる瞬間は、

監査・照会・事故対応で“タスクの主語”を聞かれたときです。

構成が正しいかどうかより先に、次が問われます。

・誰がやる（RACI）

・いつまでにやる（期限）

・何を出す（成果物・証跡）

・例外はどう戻す（台帳・解除）

これを、

RACIで固定し、SOWで義務化し、証跡パックで言い切れる

状態にすると、「思っていた」は構造的に起きなくなります。

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

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

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

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

「そこはベンダーがやると思っていた」が起きないように、責任分界（タスク別RACI）・SOW整合・証跡パック・例外台帳まで含めて整える「クラウド法務支援」を行っています。

・SOC/MSP/SIerが絡むと主語が割れて説明が崩れる

・ログ提出期限や保全の責任が曖昧で不安

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

・SOWを見直し、お願い運用を義務に変換したい

・監査・取引先照会で「想定済みです」と言える状態にしたい

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

お問い合わせの際に「ベンダーがやると思っていたの記事を見た」と書いていただけるとスムーズです。