【クラウド法務】IDaaS導入時に法務が後回しになると、なぜ説明できなくなるのか― SSO/MFAは動くのに、“監査・取引先・上司”に答えられなくなる本当の理由 ―

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

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

目次

1. はじめに：動いているのに「説明できない」状態が起きる

2. IDaaS導入の“技術”は説明できるのに、“責任”は説明できない

3. 法務が後回しになると説明不能になる理由（5つ）

4. 事故・監査で実際に聞かれる質問（これに詰まる）

5. 後回しにしないための整理フレーム（最小3枚）

6. ケーススタディ（匿名化）：導入後に説明できなくなった企業の典型

7. 今すぐ確認できるチェックリスト

8. 相談導線（自社に合うか整理したい場合）────────────────────────────

9. はじめに：動いているのに「説明できない」状態が起きる

IDaaS（SSO/MFA/条件付きアクセス/アカウント連携など）は、技術的には導入が進めやすい領域です。PoCも通るし、ログインもできる。画面も分かりやすい。なので導入プロジェクトは「まず動かす」に寄りがちです。

しかし、いざ上司・監査・親会社・取引先から質問が来た瞬間に、急に言葉が詰まります。

・「障害が起きたら、誰がどこまで責任を負うの？」・「ログは何年残る？ 監査で提出できる？」・「委託先や海外拠点はアクセスできる？ 再委託は？」・「例外運用（VIP、海外、緊急対応）は誰が承認して、いつ戻すの？」

この“説明できない”状態は、担当者の能力の問題ではなく、ほぼ構造の問題です。理由はシンプルで、IDaaSの比較・導入が「技術の話」で走り、契約・責任の話が後回しになるからです。

2. IDaaS導入の“技術”は説明できるのに、“責任”は説明できない

技術は、構成図で説明できます。

（技術の説明例）・IDaaSでSSOをする・MFAを必須にする・条件付きアクセスで端末準拠と場所を制御する・SCIMで入退社を自動化する・ログをSIEMに送る

でも、事故や監査で問われるのは「技術ができるか」ではなく、

・誰が何を約束しているか（契約）・誰が実務で担うか（運用）・証跡を提出できるか（ログ/手順/保全）

です。つまり、技術の説明資料だけでは、“責任の説明”は成立しません。

3. 法務が後回しになると説明不能になる理由（5つ）

ここが本題です。IDaaS導入で法務（契約・責任整理）が後回しになると、説明できなくなる理由は主に5つあります。

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

理由1：責任は「設計」ではなく「契約」で決まるから────────────────────────────

IDaaSの障害や侵害時に、ベンダーが何をしてくれるかは、基本的に契約（利用規約/SLA/サポート条件）で決まります。ところが法務が後回しだと、導入後にこうなります。

・稼働率（数字）は書いてあるが、通知・復旧支援・調査協力は“努力義務”・補償は返金（サービスクレジット）中心・「設定はお客様責任」で切られる範囲が広い・委託先運用の範囲が契約に落ちていない

結果として、事故時に「誰がやるの？」が契約上も運用上も曖昧になり、説明ができません。

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

理由2：データの流れ（国外/再委託/アクセス）が後からでは“固定”されるから────────────────────────────

IDaaSは「ユーザー属性」「端末情報」「認証ログ」「管理操作ログ」など、想像以上に広いデータを扱います。導入後に、データの所在やアクセス範囲が判明しても、

・すでに業務が回ってしまっており、止められない・連携先SaaSが増えていて、巻き戻せない・海外拠点/委託先の運用が既定路線になっている

という状態になります。この時点で法務が入っても、「やめたい」ではなく「どう説明するか」に追い込まれます。

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

理由3：ログの保持・提出・保全は“後付け”が難しいから────────────────────────────

ログは「見られる」だけでは意味がありません。事故・監査で必要なのは、

・必要な種類のログが揃う・必要な期間が残る・必要な形式で提出できる・必要なときに保全（削除停止・隔離）できる

です。法務が後回しだと、導入段階で「監査要件」「取引先要件」を踏まえた保持期間や提出期限が決まらず、次のようになります。

・標準保持期間が短く、後から「残っていない」・提出形式が揃っておらず「監査向けに出せない」・SIEM運用委託にしたら「ログが委託先にあり、すぐ出ない」・保全の手順がなく「事故後に上書き・削除が止まらない」

これが“説明不能”の最大原因のひとつです。

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

理由4：例外運用は増え続け、後から“整理”がほぼ不可能になるから────────────────────────────

条件付きアクセスは、例外をゼロにできません。海外、役員、委託先、夜間復旧、レガシーアプリ…例外は必ず出ます。

法務が後回しだと、例外は「止めないための暫定対応」として積み上がり、

・期限なし・承認根拠なし・台帳なし・解除計画なし

になりがちです。この状態で監査に聞かれると、説明できません。

「誰の承認で、いつまで例外にしているのか」「例外中の補償統制（監視強化など）は何か」「例外を解除する計画はあるのか」

に答えられないからです。

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

理由5：契約終了（出口）を決めないまま依存が進み、説明が“詰む”から────────────────────────────

IDaaSは“入口”なので、一度依存が進むと乗り換えが難しくなります。法務が後回しになると、契約終了時に

・設定（ポリシー、条件付きアクセス、例外）をどう引き継ぐか・ログやインシデント記録をどう移管するか・削除と削除証明をどう取るか・移行支援の範囲と費用

が決まっていません。すると、上司や監査から「万一のときに切り替えられる？」と聞かれても、答えられなくなります。

4. 事故・監査で実際に聞かれる質問（これに詰まる）

ここは“現場で本当に飛んでくる質問”です。導入時に法務が後回しだと、次が答えられません。

【障害時】・重大障害の一次通知は誰が、どれくらいで、どのチャネルで行う？・復旧の判断は誰がする？（例外解除、ポリシー変更、回避策の適用）・取引先への説明資料は誰が作り、いつ出す？

【侵害時】・不正の疑い段階で誰に通知する？・ログ保全は誰が指示する？ どこに隔離する？・委託先・再委託先が触れる場合、どこまで追える？

【ログ・監査】・管理操作ログ（ポリシー変更、権限付与、特権昇格）を何年保持している？・提出形式は？（CSV/JSON、タイムゾーン、項目）・提出期限（何営業日以内）は約束できる？

【例外運用】・例外は何件ある？ 誰が承認している？ 期限は？・例外中の補償統制は？（監視強化、対象限定、強い認証など）・恒久例外はある？ なぜ残っている？

【委託・再委託】・海外SOC/再委託の有無は？ 国・法人・範囲は？・再委託先にも同等義務（守秘、ログ提出、保全）が及んでいる？

この質問に「確認します」「ベンダーに聞きます」が続くと、説明責任が崩れます。つまり、“説明できない”とは「根拠がない」状態です。

5. 後回しにしないための整理フレーム（最小3枚）

技術設計を深掘りする前に、まず最低限この3枚を作ると、説明できる状態が作れます。

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

（1）事故別RACI（誰が実行し、誰が最終判断するか）────────────────────────────

事故タイプごとに、実行責任（R）／最終責任（A）／相談（C）／共有（I）を決めます。

最低限の事故タイプ・IDaaS障害（全社ログイン不可）・侵害疑い（乗っ取り、MFA回避）・設定事故（条件付きアクセス誤設定、SSO切断）・ログ提出（監査・取引先照会）・委託先事故（再委託含む）

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

（2）データフロー図（どこに行き、誰が触れ、どれだけ残るか）────────────────────────────

IDaaSが扱うデータを「項目」と「流れ」で見える化します。

・ユーザー属性（氏名、メール、所属など）・端末・場所・リスク情報・サインインログ・管理操作ログ・例外運用情報（例外ポリシー、対象者）

そして、保管場所（国内/国外）アクセス可能者（委託先/再委託先/海外拠点）保持期間（標準/延長）を一枚にします。

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

（3）証跡パック定義（監査で“これを出す”を決める）────────────────────────────

最低限の“出せる証跡”を先に定義します。

・管理者一覧（常設/期限付き、付与理由、承認者）・管理操作ログ（ポリシー変更、権限付与、特権昇格）・重要アカウントのサインインログ・例外台帳（理由、承認、期限、補償統制、解除計画）・インシデント時の保全手順（削除停止・隔離）

この「証跡パック」があれば、監査・取引先への説明が一気に楽になります。

6. ケーススタディ（匿名化）：導入後に説明できなくなった企業の典型

（よくある構図）・SSO/MFAは導入できた・条件付きアクセスも入れた・委託先も混ざって運用が回り始めた・海外拠点の例外も入れて動かした

その半年後、監査・取引先照会・インシデント疑いが来ると、

・例外が何件あるか誰も即答できない・誰の承認か追えない・ログが保持されておらず必要期間が出ない・委託先の操作記録が揃っていない・ベンダー契約の協力範囲が弱く、報告が遅い

結果、「ゼロトラストを入れたのに統制が弱い」と見られ、是正プロジェクトが追加で発生します。この“二重コスト”こそ、法務後回しの最大の損失です。

7. 今すぐ確認できるチェックリスト

□ 事故別RACI（誰が実行し、誰が最終判断するか）がある

□ 重大障害時の通知・復旧・社内周知の手順がある

□ ログの保持期間が、監査・取引先要件と整合している

□ ログを提出できる形式と期限が決まっている

□ 保全（削除停止・隔離）の手順がある

□ 条件付きアクセスの例外運用が台帳化され、期限・承認・解除計画がある

□ 委託先・再委託（国外含む）の範囲と監督責任が説明できる

□ 契約終了時の出口（移行・削除・削除証明）が決まっている

「全部YES」と言える企業は、正直まだ多くありません。

8. 相談導線（自社に合うか整理したい場合）

IDaaSは“入口”なので、説明責任（監査・取引先・親会社）と事故対応（通知・調査・証跡）が揃って初めて「安全」と言えます。もし次のどれかに心当たりがあれば、導入前または導入初期に整理しておくと後工程が大幅に楽になります。

・IDaaS障害時のBCP（ロックアウト対策、緊急手順）・条件付きアクセスの例外運用を台帳と規程で回したい・ログ保持・提出・保全（監査証跡）を固めたい・委託先・再委託（国外含む）の監督責任・提出義務を整理したい・比較表では見えない“事故時の責任の所在”を社内説明できる資料にしたい