【クラウド法務】「“その設定は誰が決めたのか”と聞かれて詰まる組織の共通点」― 技術の正しさより、意思決定の“証跡”がないことが問題になる ―

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

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

はじめに

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

監査や取引先の審査、親会社統制、あるいは事故対応の会議で、必ず飛んでくる質問があります。

「その設定は、誰が決めたのですか？」

技術担当としては、設定の理由を説明できます。「セキュリティのためです」「運用上必要でした」「疎通のために一時的に…」しかし問題は、理由が正しいかどうかより先に、次の点です。

・意思決定の主体は誰か（責任者は誰か）・承認は通っているか（統制として成立しているか）・例外なら期限と解除計画があるか・“いつ誰が決めたか”を後から証明できるか（証跡）

クラウド（Azure/M365など）は、設定で結果が変わります。だからこそ、設定値そのものより「決め方」が問われるようになります。本記事では、「“誰が決めたのか”と聞かれて詰まる組織の共通点」を5つに整理し、どう直せば“説明できる組織”になるかの軸を提示します。

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

1. 技術構成の“事実整理”：クラウドでは「設定＝統制の意思決定」────────────────────────────

オンプレ時代も設定はありましたが、クラウドは設定の影響範囲が広いです。

・NSGの1ルールで公開範囲が変わる・条件付きアクセスの1例外で認証強度が落ちる・PIMの承認フローの有無で特権運用の統制が変わる・Key Vaultの権限やローテーションで秘密情報管理が変わる・ログ保持期間の設定で「説明できるか」が決まる・バックアップの保持と復旧テストでBCPの実効性が決まる

つまりクラウドでは、設定は単なる技術作業ではなく、“統制の意思決定”そのものです。

そして「誰が決めたのか」と問われるのは、設定ミスのときだけではありません。監査や取引先審査が成熟すると、問題が起きていなくても“統制が成立しているか”を確認するために聞かれます。

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

2. “誰が決めたのか”と聞かれて詰まる組織の共通点（5つ）────────────────────────────

以下の共通点が複数当てはまると、設定は正しくても説明が崩れます。

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

共通点①：決裁の「単位」がない（設定が“現場判断”の連続になっている）────────────────────────────

起きていること・設定は基本的に担当者判断で進む・承認はあっても「口頭」「チャット」「会議の空気」で済む・リスクが大きい設定（例：0.0.0.0/0許可、CA例外、特権常設）が“普通の変更”として扱われる

なぜ詰まるか相手が聞きたいのは「担当者がやりました」ではなく、「会社としてそのリスクを受容した意思決定があるか」です。“決裁単位（この種類の設定は誰が承認する）”がないと、意思決定の主体が消えます。

典型例・NSGの暫定開放が恒久化している・条件付きアクセスの例外が増えている・PIMの承認を外したままになっている・Key Vaultの権限が広いまま放置されている

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

共通点②：変更管理が「作業記録」で止まっている（意思決定の証跡が残らない）────────────────────────────

起きていること・チケットはあるが、何を根拠に許可したかが書いてない・承認者が不明（“見た”だけ、了承しただけ）・実施後の検証やロールバック方針が記録されていない・設計差分が出たときの扱いが決まっていない

なぜ詰まるか「誰が決めたか」は、厳密には**“誰が承認し、何を根拠に許容したか”**です。作業ログだけでは、意思決定の証拠になりません。

最低限、変更記録に欲しい項目・変更の目的（何を守る／何を実現する）・リスク（何が悪化する可能性があるか）・承認者（役割名でも可）・期限（例外なら必須）・ロールバック（戻し方）・実施者と実施日時

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

共通点③：例外運用が台帳化されていない（“暫定”が恒久化する）────────────────────────────

起きていること・「一旦開ける」「一旦除外する」が積み上がる・期限がない、または期限が管理されていない・例外中の補償統制（監視強化、送信元限定等）がない・解除した証跡がない

なぜ詰まるか例外は説明責任の世界では「統制の穴」です。例外を許すなら、理由・承認・期限・補償統制・解除計画がセットです。これがないと、質問に対して「昔の誰かが…」しか言えません。

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

共通点④：委託先が絡むほど「決めた人」が見えなくなる（契約で縛れていない）────────────────────────────

起きていること

・監視だけ委託のつもりが、実態は設定変更も委託先がやっている

・緊急対応の名目で委託先の特権が常設化・再委託（下請け）が入っていて、誰が触ったか追えない

・ログ提出や保全協力が契約に明記されていない

なぜ詰まるか委託先が実行（R）していても、最終責任（A）や対外説明の主語は自社に残ることが多いです。にもかかわらず、委託契約別紙（SOW）に「どこまでやる」「承認が必要」「証跡を出す」が落ちていないと、意思決定の流れが消えます。

典型的な崩れ方

・社内：「委託先が決めた」・委託先：「お客様の指示で実施した（承認はもらってない）」→ 誰も決めていないことになる

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

共通点⑤：説明のゴールが「設定値の説明」になっている（“統制”の説明になっていない）────────────────────────────

起きていること・「なぜこの設定ですか？」に対して、技術理由だけを返す・しかし相手が確認したいのは「統制として妥当か」・結果、会話が噛み合わず“説明が通らない会社”に見える

なぜ詰まるか監査や取引先が見たいのは、設定の正しさだけではありません。次が揃っているかを見ています。

・誰が承認し、責任を負うか・例外をどう管理し、いつ棚卸しするか・証跡をどの期間保持し、いつ提出できるか・委託先をどう監督するか

設定値の説明は「入口」で、統制の説明が「本題」です。

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

3. ではどう直すか：「決めた人」を消さない最小セット（3つ）────────────────────────────

“誰が決めたのか”に詰まらない組織は、次の3点を最小セットで持っています。完璧なガバナンスより、まず「説明が成立する形」を作るのがポイントです。

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

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

レイヤー議論は揉めるので、“やること”で切ります。

最低限入れるタスク例・NSG/Firewall/WAF：公開範囲、例外開放、棚卸し

・条件付きアクセス：ポリシー変更、例外、解除

・特権（PIM/Break-glass）：付与、承認、棚卸し、緊急運用

・Key Vault：権限、棚卸し、期限、ローテ・ログ：収集、保持、提出、保全

・BCP：RTO/RPO、復旧手順、復旧テスト・委託先管理：特権統制、変更管理、ログ提出義務、再委託条件

RACIがあると、「決める人」「承認する人」「実行する人」が消えません。

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

（2）例外台帳（レジスター）を作り、期限で潰す────────────────────────────

例外台帳の最低項目

・例外内容（どの設定を、どの範囲で）

・理由・承認者・期限・補償統制・解除計画と解除証跡

例外を台帳化し、期限で棚卸しすると、“昔の誰かが決めた”が減ります。

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

（3）変更管理の記録を「意思決定の証跡」に寄せる────────────────────────────

チケットに最低限残すべき項目

・目的／背景

・リスク評価（簡易でよい）

・承認者（役職・役割）

・例外なら期限と解除条件

・実施結果とロールバック可否

・関連ログの保管先（証跡へのリンクではなく“保管場所の明記”）

これで「誰が決めたのか」に答えられる材料が残ります。

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

4. ケーススタディ（匿名化）：技術理由は言えるのに“決裁者”が言えずに詰まった例────────────────────────────

背景

・AzureでIaaS中心に運用、MSPに一部委託・納期優先で例外（暫定開放、条件付きアクセス除外）が積み上がっていた

・監査で「この例外は誰の承認？」と問われた

起きたこと

・担当者は技術理由を説明できる

・しかし承認者・期限・解除計画が記録にない

・委託先は「指示に従った」と言い、社内は「委託先がやった」と言う

・結果、意思決定の主体が消えてしまい、統制不備として指摘

立て直し

・RACIで承認主体を固定・例外台帳で期限管理を開始

・委託契約別紙に「承認必須」「操作ログ提出」「再委託条件」を追記・変更管理のテンプレを見直し、意思決定の証跡を残す運用へ

結果

・「設定の説明」ではなく「統制の説明」ができる状態に近づいた

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

5. チェックリスト：「誰が決めたのか」質問に耐えられるか────────────────────────────

□ 重要な設定（公開範囲、特権、例外）に“承認者の型”がある

□ 変更はチケットに紐付き、承認者と理由が残っている

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

□ 委託先が設定変更する場合、承認必須と操作ログ提出が契約に入っている

□ 再委託（下請け）がある場合、範囲特定と同等義務の貫通がある

□ 監査や取引先に、設定値ではなく“統制の仕組み”として説明できる

□ 事故時の保全（ログ凍結、抽出者記録）ができる

□ 「誰が決めたか」を、役割（A）で答えられる（個人名に依存しない）

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

6. まとめ：「詰まる原因」は設定ではなく“意思決定の見える化”の欠落────────────────────────────

「その設定は誰が決めたのか」と聞かれて詰まる組織の共通点は、設定が悪いことではなく、意思決定の主体と証跡が残っていないことです。

・タスク別RACIで主語を固定する・例外台帳で暫定を恒久化させない・変更管理を“意思決定の証跡”として残す

この3点が揃うと、クラウドは「動く」だけでなく「説明できる」になります。

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

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

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

山崎行政書士事務所では、Azure/M365等のクラウド運用について、技術構成と契約・規程・監査対応をセットで整理し、「誰が決めたのか」に詰まらない形に整える支援を行っています。

・責任分界（RACI）を事故対応まで含めて1枚にしたい・例外運用を台帳化し、期限管理で恒久化を止めたい・委託契約別紙（SOW）に、承認・操作ログ・提出義務・保全協力を入れたい・監査・取引先への説明を、設定値ではなく統制の仕組みとして整えたい

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