【情シス向け】IDaaS比較で見落とされがちな「法務・契約」チェックポイント― “できる機能”より先に、“約束される責任”を揃える ―

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

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

■ なぜIDaaS比較で「契約」が抜け落ちやすいのか────────────────────────────

IDaaS（SSO/MFA/条件付きアクセス/アカウント連携など）は、どうしても比較が「機能一覧」「画面」「対応プロトコル（SAML/OIDC/SCIM）」に寄ります。でも、情シスが本当に詰むのはその後です。

・障害で全社ログイン不可になったとき、誰が何をする？・監査や取引先照会で、ログ・証跡を“期限内に”出せる？・委託先/海外拠点/再委託が絡むとき、データと責任の整合は取れてる？

つまり、比較すべきは「できるか」だけでなく、「契約上“やる義務があるか／出す義務があるか／責任を負うか”」です。

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

■ まず押さえるべき「落とし穴」3つ（比較で漏れやすい）────────────────────────────

1）SLAはあるのに、復旧・連絡・エスカレーションの責任が曖昧・稼働率の数字だけ見て終わり・実際は“返金（サービスクレジット）”だけで、復旧支援や説明責任が契約上弱い

2）ログは“見られる”が、監査に“提出できる”とは限らない・保持期間が短い・重要な管理操作ログが揃っていない・エクスポート形式や提出期限が決まっていない

3）例外運用（委託先・海外・Break-glass）が増殖し、統制不備になる・緊急用アカウントが“作っただけ”・管理者権限が常設化・委託先の担当交代や契約終了で剥奪漏れが起きる

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

■ IDaaS比較の「法務・契約」チェックポイント（カテゴリ別）────────────────────────────

以下を、そのまま比較表（A社/B社/C社）にして埋めるのがおすすめです。（YES/NO/要交渉/提供不可 を入れていくと、危ない製品が一発で見えます）

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

A. 契約スコープと定義（最初にズレると全部ズレる）────────────────────────────

□ 「ユーザー」の定義は？（社員/派遣/委託先/ゲスト/B2Bパートナー/顧客）□ 「管理者」の定義は？（どのロールが“特権”扱いか）□ テナント/環境（本番・検証・DR）の扱いと範囲は？□ サポート対象範囲は？（SSO設定、MFA、ログ、API/SCIM、連携SaaS）□ 連携先SaaSが増えた場合の費用・責任は変わるか？

落とし穴：「標準サポート外」「設定は自己責任」「連携先は対象外」で、事故時に詰む。

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

B. SLA（可用性）と“実務の責任分界”（数字だけ見ない）────────────────────────────

□ 稼働率の定義は？（計測単位、対象範囲、除外条件、メンテ時間の扱い）□ 障害時の初動連絡は誰が／何分以内？（通知チャネル・窓口）□ 復旧対応の責任者は誰？（ベンダー／運用委託先／自社）□ エスカレーションの手順と優先度（P1/P2等）は契約化されているか？□ 補償は“返金だけ”か／復旧支援・調査協力まで含むか？

落とし穴：「SLAは高いが、実態はサービスクレジットだけ」。取引先説明に使えない。

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

C. BCP/DR（IDaaS停止＝全社停止）をどう扱うか────────────────────────────

□ IDaaS障害時の代替手段は何か？（手順として定義されているか）□ Break-glass（緊急用）運用の条件・記録・復旧後手順は定義されているか？□ 重大障害時に、ベンダー側が提供する復旧計画や復旧目標（RTO/RPO）は説明可能か？□ 計画停止（メンテ）時の通知期限・影響範囲・回避策はあるか？

落とし穴：「緊急用アカウントはある」と言いながら、規程も監査証跡もなく“統制不備”になる。

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

D. インシデント対応（通知・協力・フォレンジック）────────────────────────────

□ インシデントの定義（疑い含む）は明確か？□ 通知期限（一次通知・詳細報告）は契約に入っているか？□ 調査協力の範囲は？（ログ提出、原因分析、再発防止提案）□ 証拠保全（削除停止・上書き停止）に協力する義務があるか？□ 取引先照会（顧客監査/親会社監査）の対応に協力する義務があるか？

落とし穴：「善処」レベルだと、事故後に“出せない／遅い／追加費用”で炎上する。

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

E. ログ・証跡（保持・提出・保全＝リーガルホールド相当）────────────────────────────

□ 取得できるログの種類は？（サインイン、監査、管理操作、ポリシー変更、PIM等）□ 保持期間は？（標準／延長／長期保管のオプション）□ ログのエクスポートは可能か？（形式、タイムゾーン、項目、API）□ 監査・取引先照会で「〇営業日以内に提出」など期限を約束できるか？□ 保全（リーガルホールド相当）：削除停止・上書き停止・隔離ができるか？□ ログ改ざん防止やチェーン・オブ・カストディ（誰が抽出したか）の扱いは？

落とし穴：「見られる」＝「監査に出せる」ではない。提出期限と形式が決まっていないと詰む。

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

F. セキュリティ要件（“ベンダー任せ”の範囲を明確に）────────────────────────────

□ 暗号化（保存・通信）の範囲と責任は？□ 脆弱性対応（修正期限の目安、通知、重大度分類）は？□ セキュリティ更新・機能変更の通知義務はあるか？□ 侵害テスト、第三者評価、認証（有無と範囲）を提示できるか？□ 管理者アクセスの制御（MFA必須、端末制限、操作ログ）は契約要件になるか？

落とし穴：「セキュアです」と言うが、具体の義務・通知・是正が契約にない。

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

G. 特権アクセス（管理者権限・委託先運用・サポートアクセス）────────────────────────────

□ ベンダー／運用委託先が“顧客テナントに入る”ことはあるか？□ ある場合、アクセス条件（目的限定、最小権限、期限付き、承認、操作ログ）は？□ 個人アカウント運用か？共有アカウントは禁止されているか？□ 委託先の担当交代・契約終了時の剥奪（期限、証明、棚卸し頻度）は？□ 特権操作の報告（チケット番号、作業内容、実施者、結果）は義務化できるか？

落とし穴：緊急対応を理由に“強権限常設”になり、監査で説明不能になる。

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

H. 個人情報・越境・データ取扱い（DPA/委託の整合）────────────────────────────

□ IDaaSが扱うデータ項目（属性、端末情報、IP、位置、ログ）は定義されているか？□ データの保管場所（国・リージョン）の方針は？□ 国外拠点／海外SOC／再委託先がアクセスする可能性は？□ 政府機関等からの開示要請が来た場合の通知・対応方針は？□ 契約終了時のデータ返却／削除／削除証明は取れるか？

落とし穴：「海外アクセスはあるが契約に書いてない」「どこの国か特定できない」で監査に刺さる。

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

I. 再委託（国外含む）と監督責任（フロー・ダウンできているか）────────────────────────────

□ 再委託は事前承諾制か？それとも包括許可か？□ 再委託先（国・法人・業務範囲）を別紙で特定できるか？□ 再委託先にも同等義務（守秘、セキュリティ、ログ提出、保全、目的外利用禁止）が貫通するか？□ 一次請けが最終責任を負う条文があるか？

落とし穴：一次請けは良いが、再委託先が穴になる。事故後に“下請けのせい”が始まる。

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

J. 目的外利用（学習利用／サービス改善利用）と派生データ────────────────────────────

□ ログ・属性情報・インシデント情報を「サービス改善」「学習」に使う条項はあるか？□ ある場合、オプトアウトできるか？条件（匿名化、再識別禁止、第三者提供禁止）は？□ 派生データ（相関結果、判断メモ、レポート）の提出・移管は可能か？□ “自社事例が教材化される”リスクをどう潰すか？

落とし穴：約款にさらっと入っている。「匿名化だからOK」で済まないケースがある。

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

K. 料金・ライセンス（法務というより“後から揉める契約”）────────────────────────────

□ 課金単位は何か？（登録ユーザー／MAU／認証回数／機能別）□ B2Bゲスト・委託先・一時アカウントは課金対象か？□ ログ長期保管・サポート優先度・監査対応は追加費用か？□ 価格改定の通知・改定拒否・解約条件は？

落とし穴：「監査対応は有償」「ログ延長は高額」で、後から運用が崩れる。

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

L. 変更管理（サービス変更・機能廃止・約款更新）────────────────────────────

□ 約款変更の通知期間は？（事前通知の義務）□ 重要機能の廃止・仕様変更時の代替策・猶予期間は？□ セキュリティ上重要な変更（MFA要件、ログ仕様）の変更は通知されるか？

落とし穴：いつの間にか仕様が変わり、監査・運用設計が破綻する。

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

M. 契約終了（出口設計：ロックイン回避）────────────────────────────

□ 契約終了時に返却されるものは何か？（設定、ポリシー、ログ、レポート）□ データ削除の証明（削除証明書など）を出せるか？□ 移行支援（切替期間、並行運用、費用、期限）は契約化できるか？□ 退職者・委託先のアクセス剥奪を含む“終了手順”が定義されるか？

落とし穴：出口がない＝乗り換え不能。いざというときに詰む。

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

N. 損害賠償・補償（事故後に揉める条項）────────────────────────────

□ 賠償上限はいくらか？（年額の何倍、固定額、無制限例外の有無）□ 免責が広すぎないか？（間接損害、逸失利益など）□ セキュリティ侵害・漏えいの場合の扱い（通知・協力・補償）は？□ IP侵害などの補償（インデムニティ）は？

落とし穴：“重大なID事故”ほど間接損害が大きいが、免責で全部落ちると社内説明が地獄。

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

■ 比較のやり方（情シスが決裁を取りやすくなる整理）────────────────────────────

おすすめは、論点に優先順位を付けて「比較表」を作ることです。

P0（これがNOなら採用しない／要エスカレーション）・障害時の連絡・責任分界が合意できる・ログ（管理操作・サインイン等）の保持期間と提出が担保できる・委託先/再委託（国外含む）と監督責任が説明できる・特権アクセス（常設禁止、期限付き、操作ログ）が担保できる・契約終了時の削除・削除証明・移行支援がある

P1（交渉してでも固めたい）・リーガルホールド相当の保全協力・目的外利用（学習利用）の制御・価格改定・約款変更の通知と猶予・監査協力（証跡パックの定義）

P2（運用で吸収できるが、あると強い）・説明資料テンプレ（監査回答用）・定例レビュー、改善提案、アクセスレビューの支援

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

■ ベンダーに最初に要求すべき「成果物パック」（比較が一気に楽になる）────────────────────────────

契約書だけ見ても読み切れないので、次の“出力物”を要求すると比較が早くなります。

1）責任分界表（障害・インシデント・特権操作・ログ提出）2）取得できるログ一覧（種類、保持期間、エクスポート形式）3）再委託・海外SOCの有無と一覧（国・法人・業務範囲）4）特権アクセス運用ポリシー（誰が、いつ、どう入るか／操作ログ）5）契約終了時の返却・削除・削除証明の手順6）目的外利用（学習利用）条項の扱い（オプトアウト可否、条件）

これが揃うと、情シスは「技術＋統制＋契約」を同じ資料で上司に説明できます。

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

■ 相談（社内で詰まりやすいところだけ整理したい場合）────────────────────────────

IDaaS比較は、最後に必ず「契約・責任分界・監査証跡」で詰まります。特に、委託先運用（MSP/MSSP）や海外拠点が絡むと、再委託・越境・ログ提出が一気に難しくなります。

もし、以下のどれかに心当たりがあれば、比較表の作成段階で一度整理しておくと後工程が楽になります。

・IDaaS障害時のBCP（ロックアウト対策、Break-glass）を決めたい

・ログ保持期間、提出期限、保全（リーガルホールド相当）を決めたい

・委託先/再委託（国外）と監督責任を契約で固めたい

・目的外利用（学習利用）を禁止または制限したい・取引先監査に耐える「証跡パック」を定義したい