【クラウド法務】監査や取引先からの質問が“技術”ではなく“体制”に寄ってきたら要注意― それは「設定は見た。次は“信用できる運用か”を確認する段階に入った」というサイン ―

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

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

はじめに

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

クラウド導入（Azure / M365 など）が進むと、最初は「どのサービスを使うか」「どう構成するか」「設定は正しいか」といった“技術の質問”が中心になります。ところが、あるタイミングから監査や取引先の質問が、急に“体制”寄りになります。

「誰が承認しているのですか？」「24/7の一次対応は誰が、どの範囲まで？」「ログは何年保持し、いつまでに提出できますか？」「委託先が特権操作する場合の統制は？」「例外運用は台帳管理していますか？」

この変化を「面倒な質問が増えた」と捉えると危険です。体制質問が増えてきたのは、相手があなたの環境を “技術の良し悪し”ではなく、“信用できる運用か（説明責任が成立するか）”で評価し始めたサインだからです。

本記事では、監査や取引先の質問が“技術”から“体制”に寄ってきたときに、社内で何が起きているのか／どこが弱点になりやすいか／どう整理すれば「説明できる会社」になるかを、実務の型としてまとめます。

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

1. 技術の質問が減って「体制の質問」が増えるのはなぜか────────────────────────────

結論から言うと、相手は「設定値」を知りたいのではなく、次を確認しています。

・事故が起きたとき、誰が責任者として判断し、動くのか・必要な証跡（ログ・変更記録・テスト記録）を期限内に出せるのか・委託先や再委託先を含め、統制が効いているのか・継続的に運用が回る仕組みがあるのか（属人化していないか）

つまり、体制の質問は「セキュリティ成熟度」「ガバナンス」「説明責任」を測るための質問です。そしてクラウドは、オンプレ以上に“体制差”が出ます。

なぜクラウドほど体制差が出るのか・責任が共有（Microsoft／利用者）になり、主語が増える・運用委託（MSP／SOC／SIEM運用等）でさらに主語が増える・設定変更が速い（＝例外や暫定対応が積み上がりやすい）・ログは豊富だが、「提出できる形」にしないと意味がない

監査や取引先が「体制」を聞き始めたら、相手はすでに “技術は前提条件” として扱い、次のステージに進んでいます。

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

2. 体制質問に寄ってきたときに起きがちな「法務・運用のズレ」3選────────────────────────────

ここからが本題です。体制質問が増えてきたとき、多くの企業で「技術は動くのに説明が通らない」状態が発生します。典型パターンを3つに絞ります。

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

ズレ①：責任分界が“頭の中”にしかなく、対外説明の主語が割れる────────────────────────────

体制の質問で最初に崩れるのはここです。

・「Microsoftの範囲」「委託先の範囲」「自社の範囲」の整理が、会話ベース・部門によって主語が変わる（情シス／法務／監査対応／営業）・委託先の作業範囲が曖昧で「監視だけのはずが設定変更もしていた」などのズレが起きる

結果として、取引先や監査の場でこうなります。「誰が最終責任者ですか？」→ 返答が止まる「障害時の復旧判断は誰が？」→ その場で相談が始まる「ログ提出は誰が？」→ “委託先に確認します”の連発

これは技術の問題ではなく、統制の設計図がないことが原因です。

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

ズレ②：ログは“取れる”が、証跡として“提出できる”状態になっていない────────────────────────────

体制質問のど真ん中は、実はログです。ただし聞かれるのは「ログ取ってますか？」ではありません。

・どのログを対象とするか（認証／管理操作／ネットワーク変更／Key操作 等）・保持期間は何年か・誰が何営業日以内に提出できるか・事故時に保全（削除停止・隔離）ができるか・抽出したログの真正性を説明できるか（いつ誰が取得したか）

この設計がないと、監査・取引先照会で詰まります。「ログはあるはず」なのに提出できないと、統制不備として評価されやすいです。

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

ズレ③：例外運用が積み上がり、体制質問が“弱点の照射”になってしまう────────────────────────────

体制質問が増える局面では、例外運用が必ず掘られます。

・NSGで一時的に開けたルールが残っている・条件付きアクセスの除外が恒久化している・Break-glassの運用が属人化している・PIMの承認フローが形骸化している・Key VaultのSecrets/Keys/Certificatesが棚卸しされていない（期限切れが怖い）

例外は現場の現実として必要になることがあります。でも説明責任の世界では、例外は「統制の穴」です。だからこそ、理由・承認・期限・補償統制・解除計画がない例外は、体制質問に耐えません。

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

3. 監査や取引先が“体制”を聞くときの質問例（ここが出たら本当に要注意）────────────────────────────

次の質問が出始めたら、相手は「技術」より「統制」を見ています。社内で“答えが割れる”なら危険信号です。

【責任者・承認系】・設定変更の承認者は誰ですか（役割と権限は？）・緊急変更の事後追認はありますか（期限は？）・BCP発動の判断者は誰ですか

【委託・再委託系】・委託先の作業範囲はどこまでですか（監視だけ／復旧支援まで等）・委託先の特権アクセスはどう統制していますか（個人アカウント、期限、操作ログ）・再委託（下請け／海外SOC）の有無と範囲は説明できますか

【証跡・提出能力系】・ログの保持期間は？（何年、どの種類）・ログの提出期限は？（何営業日）・事故時の保全（削除停止・隔離）手順はありますか・復旧テストの実施記録はありますか

【例外・恒久化系】・例外運用は台帳で管理していますか（期限と解除計画は？）・例外中の補償統制は何ですか（監視強化、送信元限定など）

これらは「難しい質問」ではなく、相手にとっては“信用の最低条件”になりつつある質問です。

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

4. どう整えるべきか：体制質問に耐える「整理のフレーム」3つ────────────────────────────

体制の整備は「規程を増やす」ことではありません。説明責任が成立するように、最小限の成果物を揃えることです。以下の3つを先に作ると、質問が来てもブレません。

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

整理軸①：タスク別RACIで「主語」を固定する────────────────────────────

レイヤー（OS層／NW層）で責任分界を議論すると揉めます。クラウドは“やること（タスク）”で切ってRACIにするのが実務的です。

最低限入れるタスク例・ID/特権：MFA、条件付きアクセス、PIM、Break-glass、権限棚卸し・ネットワーク：公開範囲、NSG/Firewall/WAF、例外運用・秘密情報：Key Vault（棚卸し、期限、ローテ、権限）・ログ：収集範囲、保持期間、提出、保全・BCP：RTO/RPO、復旧手順、復旧テスト、証跡・インシデント：一次通知、封じ込め、保全、報告書、再発防止・委託管理：特権アクセス統制、再委託条件、契約終了時の出口

ポイント委託先が実行（R）でも、最終責任（A）や対外説明の主体は自社に残る項目が多いです。ここを“紙で固定”すると、質問への回答が割れなくなります。

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

整理軸②：「証跡パック」を定義して、提出能力を作る────────────────────────────

体制質問は、最終的に「根拠（証跡）」へ収束します。よって“提出できる状態”を先に作ります。

証跡パック（最小セット例）・責任分界（RACI）1枚・ログ一覧（何を、どこに、どれだけ保持）・ログ提出手順（提出期限、形式、担当、承認者）・事故時保全手順（削除停止、隔離、抽出者記録）・特権アクセス台帳（常設/期限付き、付与理由、承認者、剥奪証跡）・例外台帳（理由、承認、期限、補償統制、解除計画）・復旧手順書と復旧テスト記録（いつ誰が何をしたか）

「ログは取っている」ではなく、「何営業日以内に、これをこの形式で提出できます」が言える状態がゴールです。

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

整理軸③：委託契約（SOW）と規程に、事故対応の義務を落とす────────────────────────────

体制質問で崩れる最大要因は、委託契約に“必要な義務”が入っていないことです。監視や運用を委託しているなら、次は最低ラインとして契約・別紙（SOW）に入れると安定します。

・一次通知：検知から何分以内、どのチャネルで・ログ提出義務：提出期限・形式・対象範囲・保全協力：削除停止・隔離・抽出者記録への協力・調査協力：原因分析、再発防止に必要な情報提供・特権アクセス統制：個人アカウント、期限付き、承認、操作ログ、剥奪証明・再委託（国外含む）：条件、範囲特定、同等義務の貫通、監督責任・契約終了（出口）：引継ぎ、アクセス剥奪証明、設定・記録・ログの引渡し

これが入っていないと、体制質問に対して“委託先に確認します”が増え、説明が遅れます。

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

5. ケーススタディ（匿名化）：技術は整っているのに体制質問で止まった製造業A社────────────────────────────

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

背景・Azure＋M365運用、監視はSOC委託、運用はMSP委託・技術資料（構成図、運用設計書）は揃っている・取引先（大手）からセキュリティ審査・BCP確認が入った

詰まった質問・「ログは何年保持？提出は何営業日？」・「委託先が特権操作する場合の統制は？操作ログは？」・「例外運用の管理（期限、解除計画）は？」・「復旧テスト記録は？RTO/RPOの根拠は？」

社内で起きたこと・情シスは「ログは見える」「SLAはある」と説明・法務は「委託先が協力してくれる前提」で回答・委託先は「提出は別メニュー」「保全は契約外」になり、回答が遅延・例外運用は台帳がなく、説明が曖昧に

立て直しでやったこと・タスク別RACIで主語を固定（提出・保全・復旧の責任者を明確化）・証跡パックを定義（提出物と提出期限を可視化）・委託契約別紙に、通知・提出・保全協力・特権アクセス統制を追記・例外台帳を作り、期限と棚卸しを運用として回し始めた

結果・「技術は動いている」状態から、「説明が通る」状態へ寄せられ、取引先審査でも回答が安定した

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

6. チェックリスト：体制質問に寄ってきたときの自己診断────────────────────────────

□ 監査・取引先の質問に、部門間で同じ主語で答えられる

□ Microsoft／自社／委託先の責任分界がタスク別RACIで1枚になっている

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

□ 事故時のログ保全（削除停止・隔離・抽出者記録）手順がある

□ 復旧手順書と復旧テスト記録があり、RTO/RPOを根拠付きで言える

□ 特権アクセスは台帳化され、期限・承認・剥奪証跡がある

□ 例外運用は台帳で管理され、期限と解除計画、補償統制がある

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

□ 再委託（下請け／海外SOC等）の範囲特定と同等義務の貫通が説明できる

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

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

7. まとめ：「体制」を聞かれたら、相手は“信用”を測っている────────────────────────────

監査や取引先の質問が“技術”ではなく“体制”に寄ってきたら要注意です。それは「設定を見たい」段階を超えて、「説明責任が成立する運用か」を見られているサインです。

対処は、技術を追加することより先に、・タスク別RACIで主語を固定する・証跡パックで提出能力を作る・委託契約（SOW）と規程に義務と手順を落とすこの3点を揃えることです。

クラウドは、動いているだけでは“信用”になりません。説明できて初めて、信用になります。

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

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

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

山崎行政書士事務所では、Azure／M365等のクラウド導入・運用について、技術構成（ID、ログ、BCP、委託運用）と、契約・規程・監査対応をセットで整理する「クラウド法務支援」を行っています。

・監査や取引先の質問が体制寄りになり、社内回答が割れてきた・委託先が絡み、ログ提出や保全協力が“契約空白”になっている・RACI（責任分界）と証跡パックを作って、説明できる形にしたい・例外運用を台帳化して恒久化を止めたい

といったお悩みがあれば、オンライン（全国対応）でご相談を承っております。お問い合わせの際に「体制質問の記事を見た」と書いていただけるとスムーズです。