はじめに
SaaSは、業務システムを素早く導入できる便利な選択肢です。一方で、契約内容を十分に確認しないまま利用を始めると、障害発生時の補償、情報漏えい時の責任、設定ミスによる事故対応で認識のズレが生じる可能性があります。
特に重要なのが、SLAとセキュリティ責任分界です。SLAは単なる「稼働率の約束」ではなく、どの状態を障害とみなし、どこまでを補償対象とするかを決める契約上の基準です。経済産業省のSaaS向けSLAガイドラインでも、SaaS型取引の紛争を未然に防ぐため、利用者と提供者が事前に合意すべき事項を示しています。
本記事では、元資料で整理されているSLA、サービスクレジット、クラウド設定ミス、情報開示、AI搭載SaaSの契約論点をもとに、企業がSaaS導入前に確認すべきポイントを実務目線で解説します。
SaaS契約でSLAが重要になる理由
SLAとは、Service Level Agreementの略で、サービス提供者と利用者の間で合意するサービス品質の基準です。代表的な項目には、稼働率、応答時間、障害通知、復旧目標、サポート対応時間、バックアップ、メンテナンス時の扱いなどがあります。
SaaSでは、システムの物理基盤やアプリケーション運用の多くを提供者側が管理します。そのため利用者は、自社でサーバを管理する場合よりも運用負荷を下げられます。しかしその分、「止まったときに何を請求できるのか」「データが失われた場合に誰が責任を負うのか」「利用者側の設定ミスは補償されるのか」を契約前に確認する必要があります。
ここで注意したいのは、SLAが高い稼働率を掲げていても、それだけで安心とはいえない点です。たとえば「月間稼働率99.9%」と書かれていても、計算対象の時間、計画メンテナンスの扱い、外部ネットワーク障害の除外、利用者端末や回線に起因する不具合の除外などによって、実際に補償される範囲は大きく変わります。
SLAとSLOは分けて考える
SLAと混同されやすい言葉にSLOがあります。SLOはService Level Objectiveの略で、提供者が内部的または外部的に設定するサービス品質目標です。一方、SLAは契約上の合意であり、未達時の補償や対応条件と結びつきます。
つまり、SLOは運用上の目標、SLAは契約上の約束です。提供者が内部ではSLAより高いSLOを設定し、運用上の余裕を持たせることはありますが、利用者が実際に主張できるのは契約上明記されたSLAです。
SaaSを選定する際は、営業資料に書かれた品質目標だけでなく、契約書、利用規約、SLA別紙、サポート条件に同じ内容が明記されているかを確認する必要があります。
稼働率だけでなく「ダウンタイムの定義」を見る
SLA確認で最も見落とされやすいのが、ダウンタイムの定義です。単に「サービスが使えない時間」と考えるのは危険です。契約上は、提供者が管理する本番環境の障害のみを対象とし、計画メンテナンス、不可抗力、第三者回線、利用者側の端末や設定に起因する不具合は除外されることが一般的です。
確認すべき項目は次の通りです。
- 稼働率の計算対象期間は月間か年間か
- 計画メンテナンスはダウンタイムに含まれるか
- 障害の開始時刻は誰がどのように判定するか
- 一部機能停止も障害に含まれるか
- 外部サービスやAPI連携障害は対象か
- 利用者側のネットワーク、端末、ID管理ミスは除外されるか
SaaSは複数のクラウド基盤、認証サービス、外部API、ネットワークに依存することがあります。そのため、単体のアプリケーションが優れていても、外部依存部分の扱いが曖昧なままだと、障害時に責任の所在が不明確になります。
サービスクレジットは「損害賠償」ではない
SLA未達時の補償として、サービスクレジットが設定されることがあります。これは、一定の稼働率を下回った場合に、月額利用料の一部を減額したり、翌月以降の利用料に充当したりする仕組みです。
ただし、サービスクレジットは実損害を補填する制度ではないことが多い点に注意が必要です。業務停止による売上損失、顧客対応費用、代替システム利用費、調査費、信用毀損などは、利用規約上、間接損害として免責される場合があります。
そのため、重要業務でSaaSを利用する場合は、SLAの数値だけでなく、責任限定条項、免責条項、損害賠償上限、サービスクレジットが唯一の救済手段とされていないかを確認する必要があります。
特に基幹業務、顧客情報管理、決済、予約、医療・介護、行政関連業務などでは、SaaS停止が業務継続に直結します。重要度が高い場合は、マルチクラウド、代替運用、データエクスポート、BCP、サイバー保険など、利用者側でも防衛策を持つべきです。
セキュリティ責任分界は「SaaSなら全部お任せ」ではない
SaaSでは、サーバ、ストレージ、アプリケーション基盤、パッチ適用、脆弱性管理などの多くを提供者が担います。しかし、利用者側の責任が消えるわけではありません。
利用者側に残る主な責任は、ID・パスワード管理、多要素認証、退職者アカウントの削除、権限設定、端末管理、データ分類、入力禁止情報の管理、利用部門への教育などです。
つまり、提供者が守る領域と、利用者が守る領域は分けて考える必要があります。総務省の情報開示指針は、クラウドサービスを比較・評価・選択する利用者の支援を目的としており、ASP・SaaS、IaaS・PaaS、データセンター、AIを用いたクラウドサービスなど、サービス類型ごとに情報開示の枠組みを設けています。
SaaS契約では、少なくとも次の責任分界を確認しておきたいところです。
- データの所有権は誰にあるか
- データのバックアップ責任は誰が負うか
- 復旧作業の範囲はどこまでか
- 利用者の設定ミスによる漏えいは補償対象か
- 管理者権限の誤付与は誰の責任か
- 退職者アカウント削除漏れは誰が管理するか
- ログの取得・保存・開示は可能か
- 契約終了時のデータ返却・削除方法は明確か
クラウド設定ミスは契約と運用の両面で防ぐ
近年、SaaSやクラウドの事故では、高度なサイバー攻撃だけでなく、設定ミスが原因となるケースも問題視されています。総務省は、クラウドサービス利用・提供における適切な設定のためのガイドラインを策定しており、設定不備を防ぐための体制や点検の重要性が示されています。
設定ミス対策は、導入時の一度きりの確認では足りません。SaaSは機能追加や仕様変更が継続的に行われるため、当初は安全だった設定が、後の変更によってリスクを持つこともあります。
実務では、次のような運用が必要です。
- 管理者権限を最小限にする
- MFAを標準化する
- 共有リンクや外部公開設定を定期点検する
- 退職者・異動者のアカウントを棚卸しする
- ログを取得し、不審な操作を確認する
- 重要SaaSは外部診断やSSPMの活用を検討する
- 仕様変更通知を確認する担当者を決める
契約書では、設定変更の通知、ログ提供、セキュリティレポート、監査対応、設定支援の有無を確認しておくと、運用時のトラブルを減らせます。
情報開示と第三者認証を調達条件に組み込む
SaaS選定では、営業資料や機能一覧だけで判断すると危険です。セキュリティ体制、財務安定性、委託先管理、バックアップ、障害通知、脆弱性対応、物理設備、サポート体制などを客観的に確認する必要があります。
そこで有効なのが、情報開示指針や第三者認証の活用です。ASPICのクラウドサービス情報開示認定制度では、ASP・SaaS、AIクラウドサービス、医療情報ASP・SaaS、特定個人情報ASP・SaaS、IaaS・PaaS、データセンターなどの区分で認定サービスを確認できます。
調達時には、以下をRFPやチェックシートに入れると実務的です。
- 情報開示指針への対応状況
- ASPIC認定の有無
- ISMS、SOC2、プライバシーマーク等の認証状況
- 第三者監査レポートの提出可否
- 委託先・再委託先の管理方法
- 障害・インシデント発生時の通知条件
- 契約終了時のデータ返却・削除証明
- AI機能がある場合の学習利用・出力責任・権利関係
第三者認証があるから絶対安全というわけではありません。しかし、提供者の内部統制や情報開示の水準を比較する材料にはなります。特に中小企業では、すべてを自社で監査することは現実的ではないため、認証制度を調達判断に組み込むことは有効です。
AI搭載SaaSでは契約確認項目が増える
生成AIや機械学習を組み込んだSaaSでは、従来のSLAやセキュリティだけでは確認が足りません。AI機能を付加または活用したASP・SaaSについて、ASPICは総務省のAIを用いたクラウドサービスの情報開示指針に基づく認定制度を運用しています。
AI搭載SaaSでは、次の項目を追加で確認する必要があります。
- 入力データがAI学習に使われるか
- 学習利用を拒否できるか
- 出力結果の正確性を誰が検証するか
- 誤出力による損害責任はどう扱われるか
- 著作権や知的財産権の帰属はどうなるか
- 外部AI APIを利用しているか
- データが国外に送信されるか
- 説明可能性や判断根拠の開示はどこまで可能か
特に営業秘密、顧客情報、個人情報、設計情報、契約書、社内ノウハウを入力する可能性がある場合は、AI学習への利用可否を明確にしておく必要があります。利用者側でも、入力禁止情報リスト、利用ルール、承認フロー、出力確認ルールを整備することが重要です。
インシデント通知と個人情報漏えい対応を契約に入れる
SaaSで個人情報を扱う場合、情報漏えい等が発生した際の通知プロセスは契約上の重要項目です。個人情報保護委員会は、漏えい等報告について、速報は発覚日から3〜5日以内、確報は原則30日以内、不正な目的で行われたおそれがある場合は60日以内と示しています。
利用者が個人情報取扱事業者として報告義務を負う場合でも、実際の事故発生箇所がSaaS提供者側であれば、提供者からの迅速な通知がなければ対応が遅れます。
契約では、次の点を明確にするべきです。
- インシデント発生時に何時間以内に通知するか
- 通知内容に何を含めるか
- 原因調査報告書を提供するか
- ログや証跡を提供するか
- 被害拡大防止策を誰が実施するか
- 顧客・本人通知の支援範囲
- 監督官庁への報告支援
- フォレンジック調査費用の扱い
ここが曖昧だと、事故発生時に「提供者から情報が来ない」「利用者は報告期限に追われる」「補償範囲は限定される」という厳しい状況になりかねません。
SaaS契約で確認すべき実務チェックリスト
SaaS導入前には、以下の観点で契約・規約・SLA・セキュリティ資料を確認します。
- SLA
稼働率、計算方法、ダウンタイム定義、除外事項、メンテナンス、障害通知、復旧目標を確認する。 - 補償
サービスクレジット、損害賠償上限、間接損害の扱い、唯一の救済手段条項を確認する。 - 責任分界
提供者が守る範囲、利用者が管理する範囲、設定ミス時の責任、外部API障害時の扱いを確認する。 - セキュリティ
認証、暗号化、脆弱性管理、ログ、監査、委託先管理、データセンター、バックアップを確認する。 - データ管理
データ所有権、学習利用、保存場所、返却方法、削除証明、契約終了後の扱いを確認する。 - インシデント対応
通知期限、報告内容、調査協力、証跡提供、顧客対応支援、再発防止策を確認する。 - AI機能
入力データの利用、出力責任、説明可能性、著作権、外部AI連携、オプトアウトを確認する。
まとめ
SaaS契約では、便利さや導入スピードだけで判断してはいけません。SLAはサービス品質の目安であると同時に、障害時の責任と補償の境界線です。セキュリティ責任分界は、提供者任せにする領域と、利用者が自ら管理すべき領域を切り分けるための重要な基準です。
特に確認すべきなのは、ダウンタイムの定義、サービスクレジットの限界、設定ミス時の責任、インシデント通知、データ返却・削除、AI学習利用の有無です。
SaaS導入は、IT資産を外部に預けるだけではなく、外部サービスを前提にした業務継続体制を設計することでもあります。契約、技術、運用、法務を分けずに確認し、導入前から責任分界を明確にすることが、安全で持続的なSaaS活用の第一歩です。
コメント