【クラウド法務】ベンダーが悪いわけではないのに、情シスが矢面に立つ理由― “正しいことをしているのに責められる”の正体は、技術ではなく「説明責任の設計不足」 ―

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

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

はじめに

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

クラウド導入や運用委託の現場で、いちばんモヤっとするのは「ベンダーが悪いわけではない」のに、なぜか情シスが矢面に立つ瞬間です。

構築はSIer、運用はMSP、監視はSOC。体制も予算も取って、技術的には動いている。それでも監査や取引先照会、経営会議の場で刺さるのは情シス側で、質問の矛先がこちらに固定される。

「誰が決めた？」「期限内に出せる？」「事故時に誰がやる？」――この手の問いに対して、ベンダーは誠実に対応しているのに、最終的に“会社として”答える役が情シスに残ってしまう。

本記事では、ベンダーを責める話ではなく、なぜ情シスが矢面に立つのかを構造として分解し、矢面に立たないために必要な“説明の部品”を提示します。

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

技術構成の“事実整理”：作業は分業できても、説明の主語は分業しにくい

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

まず、現場で起きている構造を冷静に整理します。

Azure / M365 / Entra ID を使った運用は、関係者が増えやすいです。

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

【クラウド事業者】Microsoft

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

　↓

【構築】SIer / 導入ベンダー

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

　↓

【運用】MSP（運用代行）

・定常作業、変更作業、一次受付（範囲はSOW次第）

　↓

【監視】SOC

・監視、一次分析、報告（再委託で海外SOCが入る場合も）

　↓

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

・承認、意思決定、対外説明、契約管理、最終責任

この分業は合理的です。

“手を動かす作業”は、プロに寄せた方が早い。品質も上がる。属人化も減る。

ただし、ここに落とし穴があります。

作業は分業できても、「会社としての説明」は分業しにくいのです。

監査は「あなたの会社として」説明を求める

取引先は「あなたの会社として」期限付きで回答を求める

事故時は「あなたの会社として」初動と説明を求める

ここまでは技術の話。

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

情シスが矢面に立つのは、情シスが悪いからではありません。

“説明窓口”が会社側に固定される構造があり、そこに“説明の部品”が揃っていないと、最終的に情シスが前に出ざるを得なくなるからです。

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

2. ベンダーが悪いわけではないのに、情シスが矢面に立つ「決定的な理由」

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

ここから本題です。

ベンダーが不誠実だから情シスが矢面に立つ、という単純な話ではありません。

“良いベンダー”であっても、構造上こうなります。

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

理由①：説明責任（Accountability）は、委託しても会社から消えない

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

委託で減らせるのは、主に「作業量」です。

監視・一次分析

定常運用

変更作業

設定作業

一方で、消えないのが「会社としての説明責任」です。

取引先へ「何を約束するか」

監査へ「統制が回っていること」を示す

事故後に「適切だった」ことを説明する

個人情報・越境・再委託などの説明を引き受ける

ベンダーが悪くないのに情シスが矢面に立つ最大の理由は、

“作業は移るが、説明責任は移らない” という点です。

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

理由②：ベンダーが答えられるのは「自分たちがやったこと」までで、「御社の約束」ではない

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

ベンダーは誠実なほど、こう言います。

「契約範囲でできることはここまでです」

「提出期限は確約ではなくベストエフォートです」

「外部提出用に整形・マスキングするのは別作業です」

「最終判断はお客様です」

これは逃げではなく、むしろ正しい線引きです。

問題は、会社側が「その線引きの上に、御社としての約束をどう置くか」を決めていないときに起きます。

結果として、社内外の問いはこう変わります。

「ベンダーは何をする？」ではなく、

「御社はどう約束する？」になります。

ここで、矢面に立つのは情シスです。

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

理由③：レイヤーの責任分界は説明できても、タスクの主語が決まっていない

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

よくある説明はこうです。

Microsoft：基盤

ベンダー：構築・運用

自社：利用者管理・意思決定

これは入口としては便利です。

しかし、監査・取引先・事故対応が聞きたいのはタスクです。

一次通知：誰が・何分以内に・誰へ

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

ログ保全：誰が削除停止・隔離をする（抽出者記録は誰が残す）

ログ提出：誰が・何営業日以内に・どの形式で・誰の承認で

対外説明：文面の承認者は誰

例外：誰が承認し、期限管理し、解除する

このタスク主語が決まっていないと、質問が来た瞬間に会議が始まります。

会議の中心にいるのは情シスです。

だから矢面に立ちます。

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

理由④：「ログがある」と「期限内に提出できる」が別物で、材料集め役が情シスになる

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

ベンダーは「ログは取っています」と言う。

それ自体は事実で、技術的には正しい。

でも社内外が聞いてくるのは、ほぼこうです。

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

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

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

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

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

この「提出能力」を、事前に“成果物として設計”していないと、

情シスが「SOC→MSP→SIer→社内承認」をつないで期限と戦うことになります。

ベンダーが悪くなくても、情シスが矢面に立ちます。

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

理由⑤：例外（暫定・除外・緊急）が積み上がり、説明が“原則設計”とズレる

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

運用が始まると例外は必ず増えます。

条件付きアクセスの除外

NSG/Firewallの暫定開放

PIM前提なのに常設に近い権限

break-glassの運用逸脱

これも、ベンダーが悪いというより「業務を止めないため」に起きる現象です。

しかし監査や取引先は必ず聞きます。

「原則は分かった。例外はどう管理している？」

例外に「期限・解除条件・承認者・補償統制」が付いていないと、説明が壊れます。

壊れた説明を直す役が、情シスになります。

だから矢面に立ちます。

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

理由⑥：「推奨」が「会社の意思決定」に誤変換され、主語が情シスに寄る

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

導入中、ベンダーは推奨を提示します。これは良いことです。

ただ、推奨は意思決定ではありません。

運用が始まってから聞かれるのはこうです。

なぜその設定にした？

代替案は？

どのリスクを受容した？

いつ見直す？

この「推奨→意思決定」変換の記録が残っていないと、

“決めた覚えのない決定”が情シスに刺さります。

ベンダーが悪くなくても、矢面に立ちます。

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

3. 法務・説明責任の地雷：矢面に立つ瞬間はだいたいこの3つ

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

情シスが矢面に立つのは、平時ではなく次の瞬間です。

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

地雷①：取引先・親会社照会で「期限」を聞かれたとき

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

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

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

“期限”が出た瞬間に、雰囲気運用は崩れます。

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

地雷②：監査で「例外と証跡」を聞かれたとき

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

「例外は期限管理している？」

「解除証跡は？」

「権限の棚卸しは？」

“証跡”が出た瞬間に、口頭は通りません。

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

地雷③：インシデントで「止める／残す／出す」を決める必要が出たとき

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

誰が権限を剥奪する？

誰がログを保全（削除停止）する？

誰が外部提出を承認する？

この初動の主語が割れると、説明が壊れ、情シスが矢面に立ちます。

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

4. 対策のフレーム：ベンダーを責めずに、情シスが矢面に立たない状態を作る「6点セット」

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

結論から言うと、矢面に立たないために必要なのは「人」ではなく「部品」です。

“説明の部品”が揃うと、ベンダーが悪くないのに情シスが矢面に立つ状況は減らせます。

おすすめは次の6点セットです。

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

① スコープシート（1枚）：どこまでの話かを固定する

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

対象：テナント／サブスク／サービス範囲

本番／開発／子会社／海外拠点を含むか

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

説明先：監査／取引先／親会社／経営（出す相手）

スコープが固定されると、説明がブレにくくなります。

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

② タスク別RACI（1枚）：レイヤーではなくタスクで主語固定

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

最低限固定するタスク

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

封じ込め（判断者と実行者）

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

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

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

対外説明（文面承認者）

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

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

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

③ ログ提出・保全パック： “ある”を“出せる”に変換する

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

対象ログ一覧（Sign-in / Audit / Activity / Resource / M365監査 等）

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

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

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

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

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

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

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

これがあると「材料集め役」が減ります。

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

④ 例外台帳（Exception Register）：暫定を恒久化させない

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

例外ID（チケット番号）

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

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

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

承認者（役割）

期限（必須）

解除条件

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

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

例外が管理されると、監査の深掘りが止まりやすいです。

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

⑤ Decision Log（判断ログ）：推奨を「会社の意思決定」に変換して残す

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

何を決めたか

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

承認者（役割）

期限と見直し条件

影響範囲

根拠（参照資料・台帳・規程など）

“決めた覚えがない決定”を減らします。

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

⑥ SOW整合：お願いを「義務・期限・成果物」にする

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

委託しているのに矢面に立つ最大要因は、SOWが「作業」中心で、説明材料が成果物になっていないことです。

最低限、次を義務化（または確約できないなら明確化）します。

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

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

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

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

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

例外台帳更新（登録・棚卸し・解除まで）

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

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

「ベンダーが悪いかどうか」ではなく、「材料が義務として返ってくるかどうか」で矢面は減ります。

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

5. ケーススタディ（匿名化）：ベンダーは誠実なのに、取引先照会で情シスが矢面に立ったA社

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

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

背景

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

Azure＋M365＋Entra ID

構築：SIer、運用：MSP、監視：SOC（再委託あり）

大きな障害もなく運用は安定

きっかけ

海外取引先から質問票。内容は技術ではなく体制と証跡。

一次報告は何分以内か

ログは何営業日以内に提出できるか

保全（削除停止・隔離）は誰がやるか

例外（CA除外、暫定開放）の期限管理はあるか

再委託がある場合の監督責任はどうか

起きたこと

SOC/MSPは誠実に説明したが「確約できる範囲」と「契約外」が混在

社内では提出承認者・提出形式・保全手順が固まっておらず、会議が増える

例外が増えていたが台帳がなく、期限も解除条件も説明できない

結果として「御社として回答してください」が情シスに集中し、矢面に立った

立て直し（方向性）

タスク別RACIで主語を固定（通知・保全・提出・承認）

ログ提出・保全パックを作り、期限・形式・承認を決める

例外台帳で暫定に期限と解除条件を付ける

Decision Logで推奨→意思決定の根拠を残す

SOW要点を整理し、提出協力・保全協力・記録提供を義務として整合する方向へ

結果として

「ベンダーは悪くないのに矢面に立つ」状態から、

「材料が揃うので矢面に立たなくて済む」状態へ寄せられた、という流れです。

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

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

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

次のYESが多いほど、ベンダーが悪くなくても情シスが矢面に立ちやすい状態です。

【主語】

□ レイヤー分界は説明できるが、タスク別RACIがない

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

□ 事故時に「止める／残す／出す」の主語が割れる

【ログ（提出・保全）】

□ ログはあるが、何営業日以内に提出できるか言えない

□ 提出形式（項目・時刻基準・マスキング）と承認者が決まっていない

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

□ 委託が絡む提出ルートが整理されていない

【例外】

□ CA除外、暫定開放、常設権限が増えている

□ 例外台帳がない／期限・解除条件・補償統制が付いていない

□ 「暫定」が恒久化している

【契約（SOW）】

□ 通知・提出・保全・記録提供がSOWで義務化されていない

□ 「対応可能」「ベストエフォート」が多く、義務と成果物が曖昧

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

【意思決定】

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

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

□ 担当交代で「当時の判断」が消えそう

YESが3つ以上ある場合、次の監査・照会・事故後説明で矢面に立つ確率は高いです。

逆に言えば、6点セットを揃えるだけで構造的に減らせます。

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

7. まとめ：矢面に立つのは「ベンダーのせい」ではなく、説明の部品が未完成だから

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

ベンダーが悪いわけではないのに情シスが矢面に立つのは、自然な構造です。

委託で減るのは作業量で、説明責任は会社に残る

ベンダーは自社の契約範囲以上は“約束”できない

レイヤー分界ではなく、タスク主語・期限・証跡が問われる

ログは存在より提出能力が問われる

例外は増える。台帳がないと説明が壊れる

推奨は意思決定ではない。決定の記録がないと主語が情シスに寄る

だから、ベンダーを責めるのではなく、

説明の部品（スコープ／RACI／ログ提出・保全／例外台帳／判断ログ／SOW整合）を先に揃える

これが、矢面に立たない最短ルートです。

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

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

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

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

「ベンダーが悪くないのに情シスが矢面に立つ」状態を、責任分界（タスク別RACI）・ログ提出/保全パック・例外台帳・判断ログ・SOW整合まで含めて整えるクラウド法務支援を行っています。

委託しているのに照会・監査の回答が情シスに集中する

ログ提出期限・形式・承認・保全が言い切れない

例外（暫定・除外）が恒久化して説明が怖い

ベンダー推奨が“会社の決定”として残っておらず、主語が割れる

SOWを“説明材料が返ってくる契約”に寄せたい

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

お問い合わせの際に「矢面に立つ理由の記事を見た」と書いていただけるとスムーズです。