【クラウド法務】「当時の判断」が、いま説明できなくなる理由― “そのときは正しかった”が、数年後に“統制不備”に見える構造 ―

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

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

はじめに

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

クラウド運用（Azure / M365 / Entra ID 等）で、よく聞く言い回しがあります。

「当時はそれが最適だったんです」

「当時の事情があって…」

「そのときは急いでいて…」

現場の感覚としては、本当にその通りです。

移行期、障害対応、要件変更、取引先の都合、海外拠点、委託先作業――。

“当時の判断”は、現場を止めずに前へ進めるために必要な判断だったことが多い。

ところが数ヶ月〜数年後、監査・親会社統制・取引先審査・事故対応の場面で、突然こう問われます。

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

「期限は？解除条件は？」

「なぜそのリスクを受けたのですか？根拠は？」

「委託先にどこまで任せる判断は、契約上どう担保されていますか？」

この瞬間、“当時の判断”が説明できなくなります。

本記事では、なぜ「当時の判断」が時間の経過とともに説明不能になるのかを、技術→法務→運用の順で解きほぐし、説明不能を防ぐためのフレーム（成果物）まで落とし込みます。

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

技術構成の“事実整理”：当時の判断が発生する場所は、だいたい「例外」と「暫定」

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

「当時の判断」が後から説明できなくなるのは、ふつう“設定の本流”ではありません。

ほとんどが「例外」か「暫定」です。

よくある例（Azure / M365 / Entra ID）

・条件付きアクセス

　原則：MFA必須 → 当時：特定ユーザーを除外（暫定）

・NSG / Firewall / WAF

　原則：閉じる → 当時：切り分けのため暫定開放

・特権アクセス（RBAC / PIM）

　原則：期限付き → 当時：委託先に常設権限（移行完了まで）

・ログ

　原則：監査要件に合わせ保持 → 当時：コストのため短期保持（後で延長するつもり）

・BCP

　原則：RTO/RPO定義 → 当時：バックアップだけ先に設定（手順・テストは後回し）

“当時の判断”は、多くの場合「例外を出す」「暫定で逃がす」ことで成立します。

そして例外・暫定は、時間が経つほど危険になります。

ここまでは技術の話。

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

例外・暫定は、単なる技術対応ではなく、実務上は リスク受容（そのリスクを会社として受けた意思決定） です。

リスク受容は、後から問われます。

そして問われるときには、「当時の事情」は証拠になりません。証跡が必要になります。

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

2. 「当時の判断」が、いま説明できなくなる理由（7つ）

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

再現性が高い理由を7つに絞ります。

どれも「判断が悪かった」ではなく、「判断が“証跡化されていない”」ことが根本原因です。

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

理由①：判断が“口頭・チャット”に残り、後から検索できない

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

当時の判断は、多くの場合こう残ります。

・会議で「とりあえず」

・Teams/Slackで「一旦OK」

・電話で「やっといて」

その場では正しい。

でも1年後、証拠にならない。

監査・取引先・経営が欲しいのは「当時そう言っていた」ではなく、

誰が承認し、何を条件に、いつまで例外を許したかです。

検索できない判断は、存在しないのと同じ扱いになります。

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

理由②：期限がなく、暫定が恒久化して「当時」が終わらない

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

“当時の判断”が説明できなくなる最大要因は、期限がないことです。

・暫定の終了予定日がない

・解除条件がない

・解除担当者がいない

これで何が起きるか。

当時の判断が“いまの判断”になってしまいます。

数年放置された暫定は、もはや「当時の事情」では言い訳できません。

“暫定のまま放置した意思決定”として見られます。

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

理由③：判断の主語が「個人」だったため、担当者交代で消える

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

当時の判断が“担当者の裁量”で行われると、担当が変わった瞬間にこうなります。

・新担当：「なぜこうなっているか分からない」

・周囲：「当時の担当が決めた」

・監査：「会社として誰が承認した？」

→ 主語が消える

必要なのは個人名ではなく、役割としての承認者です。

役割に落ちていない判断は、時間が経つほど説明不能になります。

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

理由④：代替案検討が残らず、「なぜそれしかなかったか」が言えない

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

例外や暫定を出すとき、本当は代替案があったはずです。

・MFAを免除せずに済む方法は？

・IP制限で補えないか？

・PIMで期限付きにできないか？

・ログの保持を延ばす代替は？

当時は検討していても、残っていないと“検討していない”扱いになります。

結果、「楽をした」「統制を軽視した」と見られやすい。

短くていいので、

「検討したが不可だった理由」

が残っているだけで、説明可能性は段違いに上がります。

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

理由⑤：例外中の補償統制がなく、事故時に説明が崩壊する

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

例外を出すなら、代わりに守りを足す（補償統制）が必要です。

しかし当時は急いでいて、補償統制が抜けがちです。

・監視強化していない

・時間帯制限していない

・送信元限定していない

・期間限定にしていない

・レビュー日がない

事故が起きると、必ず聞かれます。

「例外中は何で補っていたのか？」

ここが答えられないと、“当時の事情”が通りません。

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

理由⑥：委託先が絡むのに、契約（SOW）に「義務」が落ちていない

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

当時は「お願いすればやってくれた」かもしれません。

でも時間が経つと、委託先も担当者も変わります。

事故や監査で必要になるのは、お願いではなく義務です。

・一次通知の期限

・ログ提出の期限と形式

・保全（削除停止）協力

・例外台帳更新や棚卸し

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

当時の判断が“関係性”で回っていると、時間が経った瞬間に消えます。

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

理由⑦：「一覧はある」ことで“管理できている前提”に切り替わり、要求が跳ね上がる

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

数年経つと、一覧（設定のエクスポート）は増えます。

すると外部はこう受け取ります。

「一覧がある＝統制されているはず」

→ 承認者は？期限は？是正は？証跡は？

ここで、“当時の判断”が台帳化されていないと一気に詰まります。

一覧（状態）と管理（主語・期限・是正・証跡）は別物だからです。

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

3. 対策のフレーム：「当時の判断」を“説明できる形”に変換する

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

当時の判断を、今も説明できる会社は何をしているか。

それは、判断を「思い出」ではなく「成果物」にしているだけです。

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

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

フレーム①：例外・暫定の台帳（レジスター）

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

例外はゼロにできません。だから台帳で勝ちます。

最低限の項目

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

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

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

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

・代替案検討（検討したが不可だった理由：一文でOK）

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

・期限（必須）

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

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

・次回レビュー日

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

これだけで「当時の判断」が“台帳上の判断”になり、説明できます。

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

フレーム②：タスク別RACI（誰が決め、誰がやるか）

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

担当者が変わっても説明が消えないよう、主語を役割に固定します。

最低限入れるタスク

・一次通知（検知から何分以内）

・封じ込め（止める判断と実行）

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

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

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

・例外承認・延長・解除

・委託先管理（再委託含む）

「当時、誰がOKしたか」を、今の役割に繋げます。

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

フレーム③：証跡パック（提出・保全の能力）

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

当時の判断が問われる場面は、だいたい「証跡を出せるか」です。

ログが“ある”だけでは足りません。

・対象ログ一覧

・保持期間

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

・提出形式

・承認者

・抽出者記録

・保全手順（削除停止・隔離）

これがあると、「当時の判断」だけでなく「現在の体制」も説明できます。

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

4. ケーススタディ（匿名化）：当時の暫定開放が、今“統制不備”に見えたA社

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

背景

・Azure移行期に、切り分けのためNSGを暫定開放

・条件付きアクセスも一部除外（業務継続のため）

・担当者は当時の事情を理解していた

数年後に起きたこと

・担当者が交代

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

・監査で「暫定はいつまで？解除計画は？」を質問

・台帳がなく、期限も解除条件も追えない

・“当時の判断”が説明不能となり、統制不備として扱われた

立て直し（方向性）

・例外台帳を整備し、既存例外に期限・承認（役割）・解除条件を後付け

・補償統制（監視強化、送信元限定、時間帯制限）をセット化

・タスク別RACIを作成し、例外承認・解除の主語を固定

・委託先が絡む部分はSOWに台帳更新・棚卸し・解除を義務として追記

結果

・「当時の事情」ではなく「台帳と証跡」で説明できる状態に戻り、審査・監査が安定した

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

5. いまの組織で「当時の判断」が消え始めている兆候チェックリスト

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

以下のYESが増えるほど、“当時の判断”が説明不能になりやすい状態です。

□ 例外（除外・暫定開放・常設特権）が増えているが、台帳がない

□ 「暫定」「とりあえず」が口癖だが、期限と解除条件がない

□ 承認がチャットや口頭で、役割として残っていない

□ 代替案を検討した形跡が残っていない

□ 例外中の補償統制（監視強化等）がセットになっていない

□ 担当者が変わると、例外の背景が分からなくなる

□ 委託先に頼っているが、SOWに通知・提出・保全・台帳更新が義務として落ちていない

□ ログはあるが、提出期限・形式・承認者が決まっていない

□ 監査・取引先の質問が“技術”ではなく“体制”に寄ってきた

YESが多い場合、いまからでも台帳化とRACI化で巻き戻せます。

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

6. まとめ：「当時の判断」は、台帳と期限と主語がないと必ず消える

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

「当時の判断」がいま説明できなくなる理由は、当時の判断が間違っていたからではありません。

当時の判断が、次の形に変換されていないからです。

・台帳（検索できる）

・期限（終わる）

・主語（役割として残る）

・補償統制（例外中の守りがある）

・証跡（提出・保全ができる）

・契約（委託先の義務として担保）

これを整えると、時間が経っても「当時の判断」を説明できる会社になります。

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

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

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

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

「当時の判断」が時間の経過で説明不能にならないよう、例外台帳・タスク別RACI・証跡パック・SOW整備まで落とし込むクラウド法務支援を行っています。

・例外（暫定開放、CA除外、常設特権）の背景が追えず不安

・監査や取引先に、承認者・期限・補償統制を説明できる形にしたい

・委託先を含めた責任分界と、提出・保全の期限を契約で固めたい

・担当者交代があっても説明が崩れない状態にしたい

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

お問い合わせの際に「当時の判断の記事を見た」と書いていただけるとスムーズです。