【クラウド法務】「原則」「例外」「暫定」という言葉が放置される組織の末路― 技術は動いているのに、監査・取引先・事故対応で“説明”が壊れるのは、だいたいこの3語が原因 ―

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

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

はじめに

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

クラウド運用（Azure / M365 / Entra ID など）に慣れてくると、会話の中に必ず出てくる言葉があります。

「原則」「例外」「暫定」です。

・原則：外部公開は禁止です（ただし…）

・例外：この部門だけは除外します（とりあえず…）

・暫定：移行が終わるまで開けておきます（いったん…）

この3語は、現場の作業を進めるための“便利な合意”として使われます。

問題は、便利すぎて、そのまま放置されることです。

放置されると、数ヶ月後に必ずこうなります。

「その“原則”って、どこに書いてありますか？」

「その“例外”は誰が承認しましたか？期限は？」

「“暫定”っていつまでですか？解除条件は？」

そして、技術は動いているのに、説明が通らなくなります。

監査、親会社統制、取引先審査、事故対応――“技術の質”ではなく、“統制の言葉”が問われる局面で詰むのです。

本記事では、この「原則・例外・暫定」が放置される組織が、なぜ詰むのか。どこで末路を迎えるのか。どうすれば“説明が壊れない運用”にできるのかを、実務の型で整理します。

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

技術構成の“事実整理”：この3語が出現する場所

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

まず、どの企業でも起きる「原則・例外・暫定」の出現ポイントを、技術構成の視点で整理します。

よくある全体像（テキスト図）

【ID/IAM】Entra ID

・条件付きアクセス（MFA、端末準拠、場所制限）

・PIM（特権の一時付与）

・Break-glass（緊急用アカウント）

　↓

【Azure】

・VNet / Subnet / NSG / Firewall / WAF

・VM / PaaS / Storage / Key Vault

・Backup / Site Recovery（BCP）

　↓

【ログ・証跡】

・Sign-in / Audit / Activity / Resource logs

・Log Analytics / Sentinel / SIEM

　↓

【運用体制】

・自社 情シス／CSIRT／法務／経営

・SIer（構築）

・MSP（運用代行）

・SOC（監視）＋再委託（海外SOCが入ることも）

この構成で「原則・例外・暫定」が出やすい具体例は次の通りです。

・NSG：原則閉じる → 例外として暫定開放

・条件付きアクセス：原則MFA → 例外として除外ユーザー／除外場所

・特権アクセス：原則PIMで期限付き → 例外として常設権限（暫定のはずが残る）

・ログ：原則保持（監査要件）→ 例外として短期保持（コスト理由）

・BCP：原則RTO/RPOを定義 → 暫定として「バックアップは取ってる」で進む

・委託：原則は自社責任 → 例外として委託先任せ（契約の裏付けが薄い）

ここまでは技術の話。

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

この3語が放置されると、何が起きるか。

一言で言うと、**“統制の言葉が、証跡と責任に変換されない”**まま運用が進み、外部から問われた瞬間に説明が壊れます。

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

2. 「原則」「例外」「暫定」が放置される組織の末路（5段階）

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

末路は一気に来ません。段階的に悪化します。

そして、気づいたときには戻しづらい状態になります。

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

末路①：「原則」が“スローガン化”し、実態とズレる

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

原則は言える。

でも、どこにも落ちていない。

・原則：外部公開禁止

　→ 実態：暫定開放が積み上がる

・原則：特権は最小限

　→ 実態：委託先の常設権限が残る

・原則：ログは保持

　→ 実態：保持期間がサービスごとにバラバラ

この時点では“まだ事故っていない”ので、放置されます。

しかし、原則が「守るルール」ではなく「言うだけの言葉」になります。

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

末路②：「例外」が“通常運用”に吸収され、誰も閉じられない

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

例外が残る理由は、だいたいシンプルです。

「閉じると困る」から。

・例外の背景が担当者の頭の中にしかない

・閉じると業務影響が出そうで怖い

・委託先が関与しており、誰が閉じる責任者か曖昧

・そもそも期限がない

例外が増えるほど、触るのが怖くなり、放置が最適解になります。

結果、「例外＝通常」になります。

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

末路③：「暫定」が“永続化”し、説明責任が破綻する

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

暫定は本来、

・期限

・解除条件

・解除担当者

がセットのはずです。

でも放置組織ではこうなります。

・暫定だが期限がない

・暫定だが解除条件がない

・暫定だが解除担当者がいない

・暫定だが承認者が残っていない

そして、監査や取引先照会でこう問われます。

「暫定の根拠は？いつまで？誰がリスクを受けた？」

ここで答えられません。

“暫定”という言葉は、時間が経つほど自社に不利になります。

なぜなら、暫定を続けたのは自社の意思決定だからです。

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

末路④：事故対応で「誰が決めるのか」が割れ、初動が遅れる

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

原則・例外・暫定が放置されている組織は、事故対応で詰みます。

理由は「判断のルール」が存在しないからです。

・権限剥奪（止める）：原則止める？例外で様子を見る？誰が決める？

・ログ保全（残す）：原則保全？暫定で様子見る？誰がやる？

・外部連絡（出す）：原則報告？例外で社内だけ？誰が承認？

この“主語の割れ”は、復旧そのものよりも、説明責任を壊します。

「誰が決めたのか」が説明できないからです。

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

末路⑤：監査・取引先が「技術」ではなく「体制」を見に来て詰む

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

成熟した監査・取引先審査は、技術仕様より先にこう聞きます。

・例外はどう管理しているか（台帳は？期限は？棚卸しは？）

・暫定はいつまでか（解除計画は？）

・責任者は誰か（承認者は？）

・証跡は出せるか（何営業日以内に？）

・委託先や再委託（海外SOC含む）が絡む場合、統制できているか

ここに答えられないと、「技術がすごい」より「説明できない」が勝ちます。

取引が止まる、追加要求が増える、内部統制が重くなる――これが末路です。

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

3. 放置される組織の特徴（“技術が弱い”ではない）

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

この問題は、技術力の有無とはあまり関係がありません。

むしろ、技術が強いほど例外が増えやすいことさえあります（解決が速い＝暫定が作りやすい）。

放置組織に共通する特徴は、次の通りです。

「原則」が“定義”ではなく“願望”になっている

「例外」が“申請”ではなく“現場の空気”で決まる

「暫定」が“期限”ではなく“落ち着いたら”で運用される

例外の台帳がない（検索できない）

延長が“自動”になっている（再承認がない）

例外中の補償統制がない（監視強化、送信元限定などがセットになっていない）

委託契約（SOW）に「例外管理」「棚卸し」「解除」が義務として落ちていない

事故対応のRACIがない（誰が決めて誰が実行するかが固定されていない）

ここまでが「なぜ末路に向かうか」。

次は「どう止めるか」です。

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

4. クラウド法務としての「整理のフレーム」

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

解き方はシンプルです。

「原則」「例外」「暫定」を“言葉”ではなく“成果物”に変換します。

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

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

整理軸①：「原則」を“測定可能なルール”として1枚にする（原則台帳）

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

原則は、抽象のままだと守れません。

最低限、原則を「何がOKで何がNGか」に落とします。

原則台帳（最小項目）

・原則ID

・対象（どのシステム／どの環境）

・原則（例：インターネットからの管理ポート禁止、MFA必須、特権は期限付き等）

・例外が許容される条件（例：障害対応、移行期間、ベンダー作業 等）

・例外時に必須の補償統制（例：送信元固定、時間帯限定、監視強化、承認必須）

・最終責任者（A：誰が原則を持つか）

・見直し頻度（年1回など）

ポイント

原則は“禁止”ではなく、“例外を運用できる前提条件”も含めて書くと回ります。

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

整理軸②：「例外」を“台帳＋期限＋補償統制”で制度化する（例外台帳）

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

例外はゼロにできません。

だから、例外は「出してよい」ではなく「統制している」に変換します。

例外台帳（最小項目）

・例外ID（チケット番号）

・原則ID（どの原則の例外か）

・対象（NSG名、CAポリシー名、ロール名など特定できる形）

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

・理由（業務要件／切り分け／移行／障害対応／ベンダー作業）

・申請者／承認者（役割でOK）

・期限（必須）

・解除条件（何が終われば戻すか）

・補償統制（例外中に追加する守り）

・次回レビュー日（棚卸し日）

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

ポイント

例外は「期限がないと必ず恒久化」します。

期限が長いなら、途中でレビュー日を必ず入れます。

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

整理軸③：「暫定」を“終了計画つきのプロジェクト”として扱う（暫定台帳）

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

暫定は、例外よりも危険です。

なぜなら暫定は「今だけ」の顔をして、最長で残るからです。

暫定台帳（最小項目）

・暫定ID

・対象（どの設定／どの機能／どの体制）

・開始日（いつ始めたか）

・終了予定日（必須）

・終了条件（どうなったら終わるか）

・恒久対応案（暫定を終わらせる“正規ルート”）

・依存関係（誰の作業が必要か：SIer/MSP/社内）

・責任者（A：暫定を終わらせる人）

・進捗ステータス（停滞が見えるようにする）

ポイント

暫定は“設定”ではなく“タスク”として管理します。

誰かが終わらせる責任を持つ必要があります。

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

5. さらに効く「仕上げ」：事故・監査で詰まらないためのRACIと証跡パック

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

台帳があっても、事故と監査で詰む組織があります。

それは「誰がやるか」と「何を出すか」が最後まで固定されていないからです。

そこで、次の2つをセットにします。

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

（A）タスク別RACI（事故対応まで）

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

最低限入れるタスク

・一次通知（何分以内、誰が）

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

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

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

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

・例外／暫定の承認・期限管理・解除

・委託先管理（再委託・国外関与の範囲確認）

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

（B）証跡パック（提出できる材料）

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

最小セット

・原則台帳／例外台帳／暫定台帳

・責任分界（RACI）

・ログ一覧（何をどこにどれだけ保持）

・提出手順（期限・形式・承認者）

・保全手順（削除停止、抽出者記録）

・特権アクセス台帳（付与理由、期限、剥奪証跡）

・例外解除の証跡（いつ解除したか）

これがあると、監査・取引先が「体制」を聞いてきたときに、技術者が詰まりにくくなります。

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

6. ケーススタディ（匿名化）：3語が放置され、監査で止まったA社

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

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

背景

・Azure移行中。運用はMSP、監視はSOC

・NSGの暫定開放、条件付きアクセスの例外、特権の暫定常設が積み上がる

・会議では「原則は守ってます」と言える状態

起きたこと

・取引先審査で「例外管理の仕組み」「期限」「承認者」「補償統制」を要求

・監査で「暫定はいつまでか」「解除計画はあるか」を質問される

・現場は“設定はある”が、“台帳がない”ため説明できない

・委託先も関与しており「誰が閉じる責任者か」が割れる

立て直し（方向性）

・原則を1枚化（原則台帳）し、例外の条件と必須補償統制を定義

・例外台帳を作り、既存の例外に期限と承認者を後付けで付与

・暫定台帳を作り、終了予定日と恒久対応案を計画化

・委託契約（SOW）に「台帳更新」「期限管理」「棚卸し」「解除」まで義務として落とす

・事故対応RACIと証跡パックを整え、提出能力（何営業日以内に何を出すか）を固定

結果として

・「原則です」ではなく「原則・例外・暫定を統制しています」と説明できるようになり、審査と監査の質疑が収束した

という流れです。

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

7. 自社で確認するときのチェックリスト

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

以下がYESで揃わない場合、この3語は放置されている可能性が高いです。

【原則】

□ 原則が1枚で定義され、対象範囲と責任者が明確

□ 原則に「例外が許される条件」と「例外時の必須補償統制」が書かれている

□ 原則は年1回など定期レビューされている

【例外】

□ 例外は例外台帳に必ず登録され、検索できる

□ 例外には期限が必ずある（期限なし例外は原則作らない）

□ 延長は再承認（理由更新＋補償統制の再確認）

□ 例外中の補償統制が具体的（監視強化、送信元限定、時間帯制限等）

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

【暫定】

□ 暫定は暫定台帳で管理され、終了予定日がある

□ 暫定には恒久対応案（正規ルート）があり、責任者がいる

□ 暫定が停滞しているものが見える（一覧で詰まりが分かる）

【委託・体制】

□ 委託先が関与しても、例外管理・棚卸し・解除がSOWで義務化されている

□ 事故対応のRACIがあり、主語が割れない

□ 証跡パック（提出手順・保全手順）が整っている

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

8. まとめ：3語が放置される組織は、“いつか誰かに説明する”局面で必ず詰む

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

「原則」「例外」「暫定」は、現場を前に進めるための便利な言葉です。

しかし、放置されると、技術的には動いていても、説明責任が破綻します。

末路を止めるポイントは、言葉を成果物に変換することです。

・原則：原則台帳（測定可能なルール）

・例外：例外台帳（期限＋補償統制＋解除証跡）

・暫定：暫定台帳（終了計画つき）

＋ RACI（主語固定）

＋ 証跡パック（提出できる材料）

これが揃うと、クラウド運用は「動いている」だけでなく「説明できる」運用になります。

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

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

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

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

「原則・例外・暫定」が放置されない形に落とし込むクラウド法務支援を行っています。

・例外（NSG暫定開放、条件付きアクセス除外、特権常設）が増え、説明が危ない

・例外台帳／暫定台帳を整備し、期限と解除で恒久化を止めたい

・委託先（MSP/SOC/再委託含む）の責任分界を、タスク別RACIで1枚にしたい

・監査・取引先に出せる証跡パック（提出・保全・承認）を整えたい

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

お問い合わせの際に「原則・例外・暫定の記事を見た」と書いていただけるとスムーズです。