1. SLA（サービスレベル合意：Service Level Agreement）とは？
SLAの定義と役割
SLA（Service Level Agreement：サービスレベル合意）とは、サービス提供者と顧客（ユーザー）の間で締結する「提供するサービスの品質基準」に関する合意です。サービス提供者が維持すべき品質の最低ラインや、その基準に達しなかった場合の救済措置（返金や利用料減額など）などが定められます。
SLAは単なる努力目標ではなく、当事者を法的に拘束する合意事項です。
なぜSLAが必要なのか？
SLAを締結することの主な目的は、提供するサービスの品質水準と責任範囲を明確化し、サービス提供者と顧客の認識のずれを防ぐことです。
ITサービスでは、顧客が機能やサポートなどに対して過度な期待を抱き、不具合などが発生した際にトラブルへと発展することがあります。SLAによって稼働率や障害対応にかかる時間、基準を満たせなかった場合の取り扱いなどを事前に定めておけば、サービス提供者は自社が負うべき責任の範囲を予測できるほか、明確な基準に基づいたスムーズな紛争解決も期待できます。
また、SLAによってITサービスの品質を数値で示すことは、顧客の信頼の獲得や他社サービスとの差別化にも繋がります。
このようにSLAは、ITサービスを提供する事業者にとって、適切なリスク管理と事業運営を行うための重要なツールといえます。
よくある誤解：SLO（サービスレベル目標）との違い
SLAは、SLO（Service Level Objective：サービスレベル目標）との間でしばしば混同されます。両者の主な違いは次のとおりです。
SLA（サービスレベル合意）
位置づけ：法的な「合意（約束）」
未達時の影響：返金、利用料金の減額などの救済措置を伴う
主な対象者：サービス提供者と顧客の双方を法的に拘束する
SLO（サービスレベル目標）
位置づけ：社内的な「目標値」
未達時の影響：救済措置（ペナルティ）は発生しない（改善が推奨されるのみ）
主な対象者：開発チームやSRE（サイト信頼性エンジニア）などの目標となる
SLOはあくまで「開発・運用チームが目指す内部的な基準」ですが、SLAは「サービス提供者と顧客の双方を法的に拘束する合意」です。SLAの不履行による法的責任を回避するため、SLOではSLAよりも高い目標値を定めてバッファを設けることが推奨されます。
なお、SLOが外部に対して公表され、顧客との間の契約の一部となっている場合は、SLOに法的拘束力が生じることもあり得るので注意を要します。
2. SLAにおける4つの主要な評価指標
SLAでは、サービスの品質基準を「客観的かつ測定可能な数値」として定義しなければなりません。代表的な4つの評価指標を紹介します。
① サービス稼働率
SLAで最も一般的に採用される指標が「サービス稼働率（アベイラビリティ）」です。対象期間の総時間（計画されたメンテナンス等による停止時間を除く）に対し、システムが正常にアクセス可能であった時間の割合を示します。 一般的には、以下の算定式を用いて月単位（または年単位）で計算します。
月間稼働率 = （月間総時間 - 計画停止時間 - ダウンタイム） ÷ （月間総時間 - 計画停止時間） × 100
- 月間総時間：対象となる暦月の総時間（例：30日の月であれば 30 × 24時間 = 720時間）。
- 計画停止時間：メンテナンス等のため、事前に顧客に通知した上でシステムを停止した時間。
- ダウンタイム：計画停止時間以外で、システムの主要機能が全面的に利用不能となった時間。
② 応答時間
ユーザーがシステムにリクエストを送信してから、システムが応答（レスポンス）を返却し終えるまでの時間です。インターネット回線や利用者側の通信環境による影響を受けないよう、SLAでは通常、サービス提供者のサーバーがリクエストを受信した時点から、サーバーがレスポンスの送信を完了した時点までを測定対象とします。
③ 障害復旧時間と解決の目標時間
重大なシステム障害（インシデント）が発生した際、障害を検知してからサービスを利用可能な状態に戻すまでの目標時間です。完全な原因解消までを意味するものではなく、一時的な代替案（ワークアラウンド）による暫定復旧を含む場合もあります。障害の重大度（Severity）に応じて「レベル1（致命的）：4時間以内」「レベル2（軽微）：24時間以内」のように段階的な目標値を設定するのが一般的です。なお、根本的な原因の解消までの時間は別途「解決時間」などとして管理されることもあります。
④ カスタマーサポートの応答時間
ユーザーからの問い合わせ（メールやチャット、チケットシステムなど）に対して、一次回答（ファーストレスポンス）を提供するまでの目標時間です。 「営業時間内の問い合わせに対し、4時間以内に一次返答を行う」などと定めます。
3. SLAにおける「救済措置」のルール
SLAの基準を達成できなかった場合に、どのような金銭的・法的な措置をとるべきか（救済措置）の設計は、特に慎重に検討すべき事項です。
返金・減額の基準となるしきい値
BtoB SaaSの実務では、SLAで保証した稼働率を下回った場合に、未達の程度に応じて利用料金の一定割合をサービスクレジットとして付与する例がよく見られます（サービスクレジット制度）。また、状況によっては返金を行うケースもあります。
- 99.9% ≦ 稼働率：返金なし（正常稼働範囲内）
- 99.0% ≦ 稼働率 ＜ 99.9%：翌月利用料金の 10% を減額（または返金）
- 95.0% ≦ 稼働率 ＜ 99.0%：翌月利用料金の 25% を減額（または返金）
- 稼働率 ＜ 95.0%：翌月利用料金の 50% を減額（または返金）
救済措置の上限と不可抗力免責
サービス提供者の責任範囲を限定するため、金銭的ペナルティには「上限」を設けておきましょう。 「救済措置として支払われる返金額（または減額分）の総額は、障害が発生した対象月においてユーザーが実際に支払った月額利用料金を上限とする」という旨を明記する例がよく見られます。
ただし、サービス提供者の故意または重大な過失によってSLA未達となった場合については、顧客に対する損害賠償責任の限定や免除は認められません。消費者契約法の規定を踏まえて、その旨をSLAに書き込んでおく必要があります。
また、天災地変、戦争、電力会社による停電、通信キャリアの広域障害など、自社の合理的なコントロールを超えた事由（不可抗力：Force Majeure）による停止時間は、稼働率の分母から完全に「除外（免責）」されるよう規定します。
「申請主義」によるコストの低減
SLA違反が発生した場合のサービスクレジットや料金減額については、自動的に行うのではなく、ユーザーからの申請を要件とする運用がよく採用されています。具体的には、SLAに以下のような条項を組み込みます。
- 稼働率未達による返金（クレジット）の適用を希望するユーザーは、対象月の翌月末日までに、障害発生時の客観的な証跡（エラーログやスクリーンショット等）を添えて、事業者が指定する方法により申請しなければならない。
- 期限までに適式な申請がない場合、ユーザーは返金を受ける権利を放棄したものとみなす。
このような申請手続を設けることで、事業者はSLA違反の有無を適切に確認できるほか、少額のクレジットを自動計算・自動付与する際に生じるコストを軽減できます。
ただし、申請期間が極端に短い場合や、利用者に過度な証明の負担を課している場合には、公序良俗違反によって当該規定が無効となるリスクもあるので注意が必要です。
4. AIサービスに特有のSLAに関する3つの論点
自社のITサービスにAI機能を組み込む場合に、SLAの内容検討に当たって留意すべき特有の3つの論点を解説します。
外部LLM・API障害に伴う稼働率低下の「除外事項」
自社のシステムやネットワークが正常に稼働していても、裏側で連携している外部のLLMやAPIが停止した場合、自社のAI機能も連動して停止します。
主要な外部LLM・APIの提供元が定めるSLAでは、極めて限定的な返金しか設定されていません。そのため、外部LLM・APIの障害時を含めて高い稼働率にコミットしていると、実務上許容できない大きなリスクを抱えることになってしまいます。
【実務上の対策：除外事項（Carve-outs）への明記】
SLAの「除外事項（ダウンタイムとしてカウントしない事由）」として、以下のような内容を明記する必要があります。
（条項例：ダウンタイムからの除外）
当社が管理するサーバーやネットワーク環境以外の事由に起因する障害（当社サービスが連携する第三者のAPI、外部LLMサービス、クラウドインフラストラクチャサービス等の停止、障害、仕様変更、または制限を含みますがこれらに限りません）によって生じた本サービスの停止または遅延時間は、本SLAにおけるダウンタイムには含まれず、稼働率の低下を理由とした一切の返金・減額の対象外とします。
生成AI特有の「出力品質」をSLAの対象外とする
従来のSaaSにおけるSLAは、主に「システムが動いているか否か（可用性）」を保証していました。しかし、生成AIにおいては、システム自体は動いていても「ハルシネーション（嘘の回答）」や「期待した精度に達していない」といった「出力品質」の問題が頻繁に発生します。
顧客から「AIが誤回答をしたのでSLA未達」といったクレームを受けないよう、出力の正確性や特定目的への適合性については、いかなる契約上も一切保証しないことを利用規約で明文化する必要があります。
- システム稼働（可用性）：SLAの対象とし得る。
- 出力内容の正確性・品質：SLAおよび基本契約の対象から「完全に除外（非保証）」とする。
応答時間を平均値ではなく「パーセンタイル」で設計する
生成AI機能では、プロンプトの長さ、生成トークン数、モデルの混雑状況により、1リクエストあたりの応答時間（レイテンシ）が数ミリ秒から数十秒まで極端に変動します。
ここで「平均応答時間：3秒以内」といった単純な平均値をSLAの保証値にしてしまうと、少数の超ロングレスポンスが発生しただけで平均値が跳ね上がり、容易にSLA違反となってしまいます。もし応答時間を明記せざるを得ない場合は、統計的アプローチである「パーセンタイル（Percentile）」をベースに合意します。
- 避けるべき表現：「平均応答時間を5秒以内とする」
- 実務上推奨される表現：「全リクエストの 90%（90パーセンタイル：P90）において、システム側での処理時間を10秒以内とする（ただし、外部LLMのAPI処理時間およびネットワーク遅延は除く）」
これにより、突発的なロングレスポンスによるペナルティリスクを大幅に緩和できます。
5. SLAを利用規約・契約書に組み込む際のポイント
設計したSLAを実際に適用する際、契約書のどの位置に配置すべきか、実務における重要設計ポイントを整理します。
利用規約の「別紙」として切り離す
SLAの文面を「利用規約本体」の中に埋め込むと、インフラの強化、APIプロバイダの変更、技術的な仕様変更に伴いSLAの数値（稼働率や除外項目）を変更したい場合、利用規約全体の改定手続きが必要になり、機動的な運用が難しくなります。
実務上は以下のように、利用規約本体とSLAを分離するのが一般的です。
- 利用規約本体： 「本サービスのサービスレベル（SLA）については、当社が別途定める『サービスレベル保証規定』の定めに従うものとします」と1行のみ記述。
- 別紙または専用URL： 『サービスレベル保証（SLA）規定』として別個の独立した文書、または専用のWebページ（URL）で詳細な稼働率式、しきい値、除外事項などを定義する。
損害賠償条項・救済措置について、利用規約本体とSLAとの整合性をとる
SLAで「月額の10%を返金する」と合意していても、利用規約本体の損害賠償条項に「債務不履行に基づきユーザーに生じた直接の損害を賠償する」と書かれていると、ユーザーから「SLAの返金とは別に、システム停止による実損害も請求する」と主張される余地が残ります。このような事態を防ぐため、利用規約とSLAの内容が抵触する場合の取り扱いを明記しましょう。具体的には、以下のような文言を定めます。
（条項例：唯一の救済措置）
本SLA規定に基づく利用料金の返金（または減額）は、利用規約本体その他の定めにかかわらず、本サービスの提供停止、遅延、その他サービスの品質基準の未達に関して、当社がユーザーに対して負う唯一かつ排他的な救済措置であり、一切の責任（債務不履行責任、不法行為責任、その他法的根拠を問いません）のすべてとします。ただし、当社の故意または重大な過失による場合はこの限りではありません。
6. 「LegalOn」を活用したSLA契約審査の効率化
SLAの策定では、サービス品質、障害対応、サポート範囲、責任分担など、検討すべき論点が多岐にわたります。「LegalOn」が提供する「LegalOnテンプレート」なら、「クラウドサービス導入契約及び利用規約」「プログラム保守契約」「システム保証書」など、SLAに関連する実務的なひな形をまとめて参照可能です。
自社がサービス提供者か利用者か、SaaS・保守・システム提供のどの場面かに応じて、必要な条項やリスクの考え方を比較しながら確認できます。ゼロから条項を作るのではなく、信頼できるテンプレートを起点に検討できるため、抜け漏れを抑えつつ、自社の運用実態に合ったSLA整備をスムーズに進められます。
7. まとめ：適切なSLA策定でサービス価値と法的安全性を両立させる
サービス内にAI機能を組み込むにあたり、従来のレガシーなSaaS向けテンプレートをそのまま使い使い回すことは、自社で制御不可能な領域の責任（外部LLMのダウンタイム、ハルシネーションによる誤回答など）を法的にすべて引き受けてしまうことになり、ビジネス上極めて危険です。
サービスの価値を適切に顧客へ提供しつつ、企業としての法的安全性を確保するためには、AIの特性に合わせた「除外条項の明文化」と「出力品質の非保証設計」が不可欠です。
＜関連記事＞