【クラウド法務】クラウド導入から3年目で“説明が崩れ始める”理由― 技術は安定しているのに、監査・取引先・経営説明だけが急に通らなくなる「3年目の壁」 ―

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

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

はじめに

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

クラウド導入の1年目は、正直“勢い”で進みます。

移行計画、構築、切替、障害対応、運用立ち上げ。現場は忙しいですが、説明は通りやすい時期でもあります。なぜなら「いま作っている最中」という前提が社内外にあるからです。

ところが、導入から2年、3年と経って、技術的には落ち着いてきたはずなのに、突然「説明だけが崩れ始める」瞬間が来ます。

「この例外、誰が承認したんだっけ？」

「この運用、契約上“誰がやる”ことになってる？」

「ログはあるけど、取引先に何営業日で出せる？」

「復旧は何時間で戻る約束？SLAの話じゃなくて」

「ベンダーが変わっても、責任はこっちに残るの？」

こういう質問が増え始めたら、3年目の壁に入っています。

本記事では、なぜクラウド導入3年目で説明が崩れやすいのかを、技術・法務・運用の視点で整理し、「崩れない状態」に戻すための具体的なフレームをご紹介します。

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

技術構成の“事実整理”：3年目のクラウドは「構成が増える」のではなく「関係が増える」

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

3年目に説明が崩れる企業は、技術が弱いわけではありません。

むしろ、ある程度クラウドが回っている企業ほど起きます。

典型的に、導入から3年でこう変化します。

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

（1年目）作る・移す：構成はシンプル、責任も見えやすい

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

・主要ワークロードを移行

・構成図は最新（作ったばかり）

・担当者も覚えている

・ベンダーも「構築の文脈」で語れる

・例外はまだ少ない（あるが覚えている）

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

（2年目）増やす・最適化する：例外と委託が増える

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

・アプリが増える、環境が増える（検証/本番、子会社、海外拠点）

・SOCやMSPの利用範囲が広がる

・コスト最適化でログ保持や冗長の方針が揺れる

・運用の“抜け道”が増える（暫定開放、除外、常設権限）

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

（3年目）回っているように見える：でも「説明の部品」が腐り始める

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

・担当者の異動・退職、運用担当の分業化

・ベンダーの契約更新、SOWの内容が変わる（または変わっていない）

・監査・取引先の要求が“体制”に寄ってくる

・構成図はあるが、現実の例外・暫定が図に出ていない

・「誰が決めたか」「誰がやるか」が曖昧になる

ここで重要なのは、3年目に増えているのはサービス数だけではなく、

関係者（自社・委託先・再委託）と、例外（暫定・除外・常設）の数です。

構成（部品）は説明できても、

関係（主語）と例外（期限）と証跡（提出能力）が説明できない。

このズレが、3年目に一気に表面化します。

（ここまでは技術の話。ここからが法務・説明責任の話です。）

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

2. クラウド導入3年目で説明が崩れ始める「よくある理由」6選

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

“説明が崩れる”とは、要するに次の質問に答えられなくなる状態です。

・誰が決めたか（承認・責任）

・誰がやるか（実行・委託範囲）

・いつまでにできるか（期限・提出）

・何を出せるか（証跡・成果物）

3年目にこれが崩れる理由を、再現性の高い順に並べます。

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

理由①：例外（暫定・除外・抜け道）が“積み上がって恒久化”する

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

3年目で一番多いのはこれです。

・NSGの暫定開放が残る

・条件付きアクセスの除外ユーザー/除外条件が増える

・PIMのはずが、常設特権が残る

・移行の暫定ルートが残る（結局それが正規ルートになる）

・「このままで問題出てないから」の放置

例外は必要なことがあります。

問題は、例外が 台帳＋期限＋解除条件＋補償統制 になっていないことです。

3年目は例外が増え、当時の背景を覚えている人が減り、急に説明不能になります。

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

理由②：契約更新（SOW更新）で「やること」が曖昧になる／またはズレる

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

3年目は、ちょうど更新が来やすいタイミングです。

・構築SIer → 運用MSPへ主役が移る

・SOC導入後に再委託（海外SOC等）が入る

・運用範囲が増えたのに、SOWが1年目のまま

・逆に、費用見直しでSOWが薄くなる（提出・保全・是正が“ベストエフォート化”）

ここで起きる悲劇がこれです。

「できると思っていたこと」が、契約上の義務になっていない。

結果、事故・監査・取引先照会の局面で、

「何営業日以内にログ提出できますか？」

「保全（削除停止）は誰がやる？」

に答えられなくなります。

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

理由③：「責任分界」をレイヤーで語ってしまい、タスクの主語が消える

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

3年目になると、関係者が増え、レイヤーで分けた説明が崩れます。

・Microsoftはここまで

・ベンダーはここまで

・自社はここから

この説明、図としては綺麗です。

でも事故・監査が聞きたいのはレイヤーではなくタスクです。

・封じ込め（権限剥奪）を決めるのは誰？実行するのは誰？

・ログ保全（削除停止）を誰がいつやる？

・ログ提出は誰がいつまでに、どの形式で出す？

・対外説明は誰が承認する？

3年目に「主語が割れる」会議が増えたら、ここが崩れています。

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

理由④：「一覧はある」が「管理できている」に変換され、要求水準が上がる

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

導入3年目になると、社内外から言われやすい言葉があります。

「運用は回っていますよね？」

「例外管理は当然されていますよね？」

「ログは提出できますよね？」

この瞬間に、

“設定がある” → “統制できている前提”

に切り替わります。

しかし実務では、一覧（エクスポート）と管理（期限・責任・是正・証跡）は別物です。

このギャップが、3年目に「説明の崩れ」として露出します。

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

理由⑤：ログはあるのに「提出能力」と「保全能力」が設計されていない

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

3年目は取引先・監査の要求が具体化します。

・対象ログは何か

・保持期間は何年か

・要請から何営業日以内に出すか

・誰の承認で外に出すか

・事故時に削除停止（保全）できるか

・抽出者記録（いつ誰がどう取得したか）は残るか

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

**期限内に“提出できる形”で、必要なら“保全できる形”**である必要があります。

ここが3年目に問われ始め、崩れます。

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

理由⑥：BCPが「バックアップは取っている」止まりで、約束（RTO/RPO）が言えない

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

3年目は経営・取引先から、SLAではなく「復旧の約束」が問われます。

・止まったら何時間で戻る？（RTO）

・どこまで戻る？（RPO）

・根拠は？（復旧手順書、復旧テスト記録）

ここが言えないと、技術は動いていても説明は通りません。

クラウドのSLAは“稼働率の話”で、復旧の約束とは別物です。

3年目はその違いが問われ、崩れます。

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

3. 3年目の壁を越える「整理のフレーム」

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

ここからが実務の解決策です。

3年目に必要なのは、新しいサービスの導入よりも、説明の再設計です。

おすすめは次の「3枚＋契約見直し」です。

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

フレーム①：タスク別RACI（誰が決めて誰がやるか）を1枚で固定する

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

レイヤーではなくタスクで切ります。最低限これだけは入れます。

・一次通知（検知から何分以内、誰が誰へ）

・封じ込め（権限剥奪・通信遮断：判断者と実行者）

・ログ保全（削除停止・隔離・抽出者記録：開始条件と担当）

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

・復旧判断（BCP発動、切替の決裁者）

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

・委託先管理（再委託・国外関与、特権アクセス統制）

「会議で主語が割れる」状態を、紙で止めます。

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

フレーム②：例外・暫定台帳（期限つき）で“恒久化”を止める

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

3年目の説明崩れの主犯は例外の恒久化です。

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

例外台帳の最小項目

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

・対象（NSG名、CAポリシー名、ロール名、Key Vault等）

・理由

・承認者（役割でOK）

・期限（必須）

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

・補償統制（例外中の守り：監視強化、送信元限定、時間帯制限等）

・次回レビュー日

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

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

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

フレーム③：証跡パック（提出・保全の能力）を1枚で定義する

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

ログはある、は通用しません。

“出せる”と“保全できる”を固定します。

証跡パックの最小項目

・対象ログ一覧（何を）

・保持期間（どれだけ）

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

・提出形式（どの形式で）

・承認者（誰の承認で外に出すか）

・抽出者記録（いつ誰がどう取得したか）

・保全手順（削除停止、隔離、アクセス制限）

・委託先が絡む場合の提出ルート（SOC/MSP→自社等）

これがあると、取引先・監査の質問に“ブレずに”答えられます。

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

フレーム④：SOW（委託契約別紙）を“3年目仕様”に更新する

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

3年目は委託と運用が実態に合っていないことが多いです。

SOWで最低限固めたいのは以下です。

・一次通知：重大度基準と通知期限

・ログ提出：対象、形式、提出期限（何営業日以内）

・保全：削除停止・隔離への協力、実施記録の提供

・特権アクセス統制：PIM相当、付与理由、期限、剥奪証跡

・例外台帳：台帳更新、棚卸し、解除までを作業範囲に含める

・再委託（国外・海外SOC）の範囲と監督責任

・契約終了時の出口：アクセス剥奪証明、ログ引継ぎ、削除証明

「できるはず」を「義務」に落とさないと、3年目以降の説明は必ず崩れます。

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

4. ケーススタディ（匿名化）：3年目で“監査質問が体制に寄って”崩れたA社

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

（実際のご相談で多い構図を匿名化しています）

背景

・製造業A社（国内＋海外拠点）

・Azure＋M365を導入し、運用はMSP、監視はSOC

・導入後は安定稼働。構成図も整っている

3年目に起きた変化

・担当者が異動

・委託範囲が広がった（新システム追加、海外対応）

・取引先からセキュリティ審査が厳格化（証跡提出期限が明確化）

詰まりポイント

・条件付きアクセスの除外が増えていたが、期限と承認が追えない

・NSGの暫定開放が残っていたが、解除条件が不明

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

・SOWは1年目のままで、提出・保全協力がベストエフォート止まり

・事故時に「誰が止めるか」「誰が保全するか」が割れる

立て直し（方向性）

・タスク別RACIの作成（事故対応まで）

・例外台帳の棚卸しと期限付与（延長は再承認へ）

・証跡パック（提出・保全の型）を定義

・SOWを更新し、通知・提出・保全・特権統制・例外管理を義務化

結果として

・「技術は動いているのに説明できない」状態から

・「体制として説明できる」状態に戻り、取引先審査・監査対応が安定

という流れです。

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

5. 3年目の壁に入っているか分かるチェックリスト（兆候）

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

以下のうちYESが増えてきたら、説明が崩れ始めるサインです。

□ 例外（NSG暫定開放、CA除外、常設特権）が増え、背景を覚えている人が減っている

□ 「これは暫定です」が口癖になっているが、期限と解除条件が無い

□ 構成図はあるが、運用の抜け道（例外）が図に出ていない

□ 監査や取引先の質問が“技術”より“体制（誰が何をいつまでに）”に寄ってきた

□ SOC/MSP/SIerが絡むと「誰がやるのか」が会議で割れる

□ ログはあるのに、提出期限（何営業日以内）を言えない

□ ログ保全（削除停止・抽出者記録）の手順が薄い／責任者が決まっていない

□ “SLAがある”と言ってしまいがちで、RTO/RPOを根拠付きで言えない

□ 委託契約（SOW）が更新されておらず、実態とズレている

□ ベンダー変更・更新のたびに「どこまでが契約内か」が曖昧になる

YESが多い場合、技術を増やす前に「説明の再設計」が必要です。

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

6. まとめ：3年目で崩れるのは技術ではなく「主語・期限・証跡」

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

クラウド導入3年目で説明が崩れ始める理由は、だいたい次の3つに集約できます。

・主語が増える（委託・分業・再委託で責任が割れる）

・例外が増える（暫定が恒久化し、承認と期限が消える）

・要求が上がる（監査・取引先が“提出期限・体制”を求める）

これに対して、効く対策はシンプルです。

・タスク別RACI（主語）

・例外/暫定台帳（期限）

・証跡パック（提出・保全）

＋ SOW更新（義務化）

この4点を整えると、クラウドは「動いている」だけでなく「説明できる」運用に戻ります。

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

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

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

山崎行政書士事務所では、Azure / M365 / Entra ID 等の技術構成と、契約・規程・監査対応をセットで整理し、導入3年目以降に起きやすい「説明の崩れ」を止めるクラウド法務支援を行っています。

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

・SOC/MSP/再委託を含めた責任分界（RACI）を事故対応まで1枚にしたい

・ログ提出（期限・形式）と保全（削除停止・抽出者記録）を整備したい

・SOWを3年目仕様に更新し、通知・提出・保全・特権統制を義務化したい

・監査や取引先の質問に、一貫したストーリーで答えられるようにしたい

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

お問い合わせの際に「クラウド導入3年目の記事を見た」と書いていただけるとスムーズです。