【クラウド法務】「顧問とSIer、どちらも正しいのに説明が割れる理由」― 技術と契約の“つなぎ目”が空白だと、監査・取引先・事故対応で主語が割れる ―

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

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

はじめに

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

クラウド導入（Azure / M365 等）を進めていると、次のような“もどかしさ”を感じる瞬間があります。

・SIerの説明は技術的に筋が通っている

・顧問（顧問弁護士や士業）の説明も、契約・法務として筋が通っている

・なのに、社内外に向けた説明が一本化できない

・監査や取引先の質問に、部門ごとに答えが割れる

この状態は「どちらが間違っている」わけではありません。

どちらも正しいのに、説明が割れるのは、クラウド導入で最も起きやすい構造的な問題です。

結論から言うと、原因は“専門性”の不足ではなく、

技術（SIer）と契約（顧問）の間にある「責任の設計」と「証跡の設計」が空白になっていることです。

本記事では、なぜ説明が割れるのかを、現場でそのまま使える形で整理します。

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

技術構成の“事実整理”：クラウドは「境界」が増える。だから主語が増える

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

オンプレの世界は単純でした。

自社設備を自社が運用し、外部が入っても「保守」や「構築支援」程度で、責任の主語が比較的単純でした。

クラウドは違います。主語が増えます。

・クラウド事業者（Microsoft）

・利用者（自社：情シス、CSIRT、法務、監査、広報、事業）

・SIer（構築・移行・保守）

・MSP（運用代行）

・SOC（監視・調査）

・サードパーティ（Marketplace、SaaS、監視製品等）

・再委託（下請け、海外SOC等が入るケース）

そしてクラウドは、設定で結果が変わります。

NSG、条件付きアクセス、PIM、Key Vault、ログ保持、バックアップ、CDN…

設定が増えるほど、意思決定の数も増えます。

（ここまでは技術の話。ここからが“説明が割れる”本題です。）

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

2. まず結論：「顧問」と「SIer」が見ている“正しさ”は、そもそも種類が違う

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

顧問とSIerは、同じ「正しさ」を見ていません。

それぞれの正しさを分解すると、説明が割れる理由が見えます。

SIerが正しい（ことが多い）領域

・技術的に成立するか（動くか、要件を満たすか）

・構成として妥当か（冗長化、性能、運用性）

・運用手順が回るか（監視、障害対応のフロー）

顧問が正しい（ことが多い）領域

・契約条項として妥当か（免責、損害賠償、秘密保持、委託管理）

・法令・ガイドライン上の論点が抜けていないか

・対外説明で危ない表現になっていないか

つまり、

SIerは「仕組みが成立する」正しさ、

顧問は「約束とリスクが成立する」正しさ。

どちらも正しい。

しかし、両者を接続する“運用上の証拠”がないと、説明は割れます。

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

3. 説明が割れる本当の原因：技術と契約の間にある「5つの空白」

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

“顧問とSIerが正しいのに説明が割れる”組織では、ほぼ例外なく次の空白が存在します。

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

空白①：責任分界が「レイヤー議論」で止まり、タスク別に固定されていない

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

SIerの説明

・「ここはクラウド事業者の範囲」「ここはお客様の設定です」

顧問の説明

・「最終的な説明責任は御社に残ります」

この2つは両立します。

しかし“タスク別”に落ちていないと、現場ではこう崩れます。

・障害時の一次通知は誰がやる？

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

・Purge（CDNキャッシュ削除）やNSG締めは誰が実行する？

・復旧判断（BCP発動）は誰がする？

・委託先が触る範囲はどこまで？

レイヤー（NW層、OS層）ではなく、

やること（タスク）単位でRACIにしないと主語が割れます。

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

空白②：SLA（稼働率）と、取引先が求めるRTO/RPO（復旧の約束）が混ざる

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

SIerの説明

・「この冗長構成なら落ちにくい」「SLA相当は高い」

顧問の視点

・「取引先に約束するなら、その根拠が必要」

取引先や監査が聞きたいのは「あなたのサービスが何時間で戻るか」です。

SLAを説明しても、RTO/RPOが根拠付きで言えないと説明になりません。

だから説明が割れます。

・情シスはSLAを語る

・法務は「約束できない」と止める

・営業は「大丈夫です」と言ってしまう

この状態が典型です。

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

空白③：ログは“取れる”が、提出期限・形式・保全手順が決まっていない

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

SIerの説明

・「ログは取れます」「SIEMに集約できます」

顧問の視点

・「事故時や監査で、期限内に出せますか？」

ログが存在することと、提出できることは別です。

提出には、保持期間、抽出手順、提出期限、形式、承認、保全（削除停止・隔離）が必要です。

ここが空白だと、顧問は安全側に寄せ、SIerは技術的可能性を語り、説明が割れます。

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

空白④：委託契約（SOW）に「通知・提出・保全協力・特権アクセス統制」が落ちていない

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

SIer／MSP／SOCが関与すると、実務は契約の別紙（SOW）で決まります。

しかしここが薄いと、事故や照会で一気に崩れます。

典型

・社内：「委託先がやってくれるはず」

・委託先：「契約外です（有償です）」

・顧問：「それでは説明が成立しません」

・SIer：「技術的には可能ですが…」

つまり、技術と契約の“つなぎ目”は、SOWに落ちていないと成立しません。

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

空白⑤：例外運用が台帳化されておらず、「誰が決めたか」が消える

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

クラウドは例外運用が増えます。

NSG暫定開放、条件付きアクセス除外、PIM例外、Break-glass運用…

これが台帳化されていないと、監査や取引先にこう聞かれます。

「その例外は誰が承認したのですか？期限は？補償統制は？」

SIerは「当時の要件で必要でした」と言う

顧問は「承認と期限がないのは危険」と言う

→ どちらも正しいが、説明は割れる

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

4. どうすれば一本化できるか：「説明を成立させる最小セット」

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

顧問とSIerの説明を一本化するには、間にある“空白”を成果物で埋めるしかありません。

効果が高い最小セットは次の3つです。

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

（1）タスク別RACI（責任分界）を1枚で作る

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

事故対応まで含めて、R（実行）／A（最終責任）／C（相談）／I（共有）を固定します。

最低限入れるタスク例

・一次通知、封じ込め、保全、ログ提出、復旧判断、報告書

・ID/特権（PIM、Break-glass、棚卸し）

・ネットワーク（NSG/WAF/Firewall、例外）

・ログ（保持、提出期限、形式、承認）

・BCP（RTO/RPO、復旧手順、復旧テスト）

この1枚があると、顧問もSIerも同じ主語で話せるようになります。

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

（2）証跡パック（提出物セット）を定義する

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

「何を」「どの期間」「誰が」「何営業日以内に」出せるかを定義します。

最小セット例

・ログ一覧（保持期間）＋提出手順（期限・形式・承認）

・復旧手順書＋復旧テスト記録

・特権アクセス台帳

・例外台帳（理由・承認・期限・解除計画・補償統制）

・変更管理の証跡（チケット、承認、実施者、ロールバック）

“ログは取れます”を、“期限内に提出できます”へ変えるのがポイントです。

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

（3）委託契約別紙（SOW）に「事故対応の義務」を落とす

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

委託が絡むなら、ここが最後の決め手です。最低ラインとして

・一次通知

・ログ提出義務（期限・形式）

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

・特権アクセス統制（個人アカウント、期限、承認、操作ログ、剥奪証明）

・再委託（国外含む）の条件と同等義務の貫通

・契約終了（出口：引継ぎ、ログ引渡し、アクセス剥奪証明）

を明記します。

これで「委託先が協力してくれる前提」の説明が、契約上の根拠を持ちます。

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

5. ケーススタディ（匿名化）：「どちらも正しい」状態から抜け出した例

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

背景

・Azure導入、運用はMSP＋SOC、顧問あり、SIerあり

・取引先照会（BCP、ログ提出、委託管理）で回答が割れた

起きたこと

・SIer：技術的には可能、構成は妥当

・顧問：契約と説明責任の観点では根拠が薄い

・委託先：提出や保全は契約外になり、回答が遅い

・社内：SLAとRTO/RPOが混ざり、説明が噛み合わない

立て直し

・タスク別RACIで主語を固定

・証跡パックを定義（提出期限、形式、保全手順を含む）

・委託契約別紙に通知・提出・保全協力・特権統制を追記

・例外台帳で暫定運用の恒久化を止める

結果

・顧問もSIerも同じ“成果物”を根拠に話せるようになり、説明が一本化された

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

6. チェックリスト：説明が割れそうな組織の自己診断

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

□ レイヤーではなくタスク別RACI（事故対応まで）が1枚である

□ SLAとRTO/RPOを切り分けて説明できる

□ ログは保持期間・提出期限・形式・担当まで決まっている

□ 事故時の保全（削除停止・隔離・抽出者記録）ができる

□ 委託先に一次通知・ログ提出・保全協力の義務が契約で入っている

□ 委託先の特権アクセスが統制されている（個人アカウント、期限、剥奪証明）

□ 例外運用が台帳化され、期限と解除計画がある

□ 契約終了時の出口（引継ぎ、ログ引渡し、アクセス剥奪証明）が決まっている

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

7. まとめ：割れているのは“意見”ではなく、“つなぎ目”

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

顧問とSIer、どちらも正しいのに説明が割れる理由は、

誰かが間違っているからではありません。

割れているのは、

・責任分界（タスク別RACI）

・証跡（提出能力）

・委託契約別紙（義務の貫通）

という“つなぎ目”が未設計だからです。

この3点を整えると、クラウドは「動く」から「説明できる」に変わり、

顧問とSIerの説明も一本化できます。

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

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

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

山崎行政書士事務所では、Azure/M365等のクラウド導入・運用において、

技術構成と契約・規程・監査対応をセットで整理し、「説明が割れない」形に整える支援を行っています。

・顧問とSIerの説明が割れ、取引先や監査への回答が安定しない

・責任分界（RACI）と証跡パックを作り、提出能力を整えたい

・委託契約別紙（SOW）に通知・提出・保全協力・特権統制を落としたい

・例外運用を台帳化して恒久化を止めたい

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