SLAとは？SaaSの稼働率保証の読み方と社内システムでの決め方

SLA（Service Level Agreement、サービスレベル合意）とは、サービスの提供者と利用者が「どの水準で提供するか」と「下回ったらどう扱うか」を、測り方まで含めて取り決めた文書です。止まらないことの保証ではありません。執筆時点（2026年10月18日）でMicrosoft 365、Google Workspace、AWSのSLA文書を読むと、3社とも水準を下回ったときの救済をサービスクレジット（料金の減額や利用期間の延長）に限っています（AWSは契約に別の定めがない場合）。

この記事は、SaaSの稟議でSLAを読む側と、保守・運用の委託契約や社内システムでSLAを書く側を兼ねる情シス担当者に向けたものです。読み終えたとき、稼働率を停止時間に直す計算を自分のPCで再現でき、3社のSLAの違いを1枚の表で比べられ、委託契約の別紙に入れるSLAのひな形とチェックリストが手元に残ります。

SLAとは何を約束する文書か

SLAに書かれる要素は、対象のサービス、測る指標（稼働率、障害時の復旧時間、問い合わせへの回答時間など）、その測り方、約束する水準、未達時の扱い、対象外とする条件です。読み手が見落としやすいのは「測り方」と「対象外」で、同じ99.9%でも、何を停止と数えるかによって約束の重さが大きく変わります。後半の計算で、その差を数字で示します。

SLAは営業資料ではなく契約の一部です。MicrosoftのSLA文書は自らをボリュームライセンス契約の一部と位置づけ、AWSのSLAはAWSカスタマーアグリーメントと食い違う部分ではSLAの条件が優先すると書いています（いずれも執筆時点の版）。クレジットを請求するときに根拠になるのは、製品ページの「99.9%」ではなく、この文書に書かれた停止の定義と計算式です。

周辺の略語も整理しておきます。SLI（Service Level Indicator）は実際に測る指標、SLO（Service Level Objective）は提供側が内部で置く目標値、SLAは利用者と合意し、未達時の扱いまで決めたものです。SLOの決め方とエラーバジェットの計算はSREの記事で扱っているので、ここでは契約としてのSLAに絞ります。SLAを合意し、測り、報告し、見直す一連の活動はSLM（サービスレベル管理）と呼ばれ、ITILでもプラクティスの一つとして扱われています。

なお、言語学や英語教育の文脈で出てくるSLAは第二言語習得（Second Language Acquisition）の略で、IT契約のSLAとは無関係です。

SLAの稼働率を停止時間に換算する

「稼働率99.9%」が何分の停止を許すかは、測定期間の長さで決まります。早見表を手で作ると桁を取り違えやすいので、標準ライブラリだけで動くPythonスクリプトを書き、使い捨てのコンテナ（python:3.12-slim イメージ）で実行しました。この節以降の表と数値は、すべてこのスクリプトの実行結果から取っています。

$ python3 --version
Python 3.12.15

#!/usr/bin/env python3
"""SLAの稼働率を停止時間・クレジット・合成稼働率に換算する（標準ライブラリのみ）。
使い方: python3 sla_calc.py [downtime|window|partial|credit|chain]"""
import sys

DAY = 24 * 60  # 1日の分数
WINDOWS = {  # 測定期間の名前: 分
    "28日の月": 28 * DAY,
    "30日の月": 30 * DAY,
    "31日の月": 31 * DAY,
    "1年(365日)": 365 * DAY,
    "営業時間のみ(月20日x9時間)": 20 * 9 * 60,
}
# クレジット表: (この稼働率を下回ったら, クレジット) を緩い順に並べる（執筆時点の各社SLA文書から）
M365_TIERS = [(99.9, "25%"), (99.0, "50%"), (95.0, "100%")]   # Exchange/SharePoint/Teams: 月額料金に対する割合
GWS_TIERS = [(99.9, "3日分"), (99.0, "7日分"), (95.0, "15日分")]  # Google Workspace: サービス日数（オフライン請求は期間延長、オンライン請求は今後の請求で相当額）


def hms(minutes):
    s = round(minutes * 60)
    h, s = divmod(s, 3600)
    m, s = divmod(s, 60)
    return f"{h}時間{m:02d}分{s:02d}秒" if h else f"{m}分{s:02d}秒"


def uptime(down_min, window_min):
    return 100 * (1 - down_min / window_min)


def credit(pct, tiers):
    result = "なし"
    for below, value in tiers:
        if pct < below:
            result = value
    return result


def downtime():
    print("稼働率 | " + " | ".join(WINDOWS))
    for pct in (99.0, 99.5, 99.9, 99.95, 99.99):
        cells = [hms(w * (100 - pct) / 100) for w in WINDOWS.values()]
        print(f"{pct}% | " + " | ".join(cells))


def window():
    names = ("30日の月", "1年(365日)", "営業時間のみ(月20日x9時間)")
    for down in (60, 480):  # 業務時間中に起きた1回の停止（分）
        cells = [f"{n}={uptime(down, WINDOWS[n]):.3f}%" for n in names]
        print(f"停止{hms(down)}: " + ", ".join(cells))


def partial(users=300, minutes=240):
    w = WINDOWS["30日の月"]
    for hit in (30, 9):  # 使えなくなった利用者数
        by_user = uptime(hit * minutes, users * w)              # 利用者分で按分
        threshold = uptime(minutes, w) if hit / users > 0.05 else 100.0  # 5%超なら全体を停止扱い
        all_down = uptime(minutes, w) if hit == users else 100.0         # 全員が使えない時間だけ数える
        print(f"{users}人中{hit}人({hit / users:.0%})が{hms(minutes)}使えない: "
              f"利用者分={by_user:.3f}% 閾値5%={threshold:.3f}% 全断のみ={all_down:.3f}%")


def credit_vs_loss(users=300, fee=1500, down=480, hourly=3000, impact=0.5):
    pct = uptime(down, WINDOWS["30日の月"])
    rate = credit(pct, M365_TIERS)
    credit_yen = users * fee * int(rate.rstrip("%")) / 100 if rate != "なし" else 0
    loss_yen = users * down / 60 * hourly * impact
    print(f"入力(仮の値): {users}人, 月額{fee:,}円/人, 停止{hms(down)}, 時間単価{hourly:,}円, 業務影響{impact:.0%}")
    print(f"月間稼働率 {pct:.3f}% -> M365の表: {rate} / Workspaceの表: {credit(pct, GWS_TIERS)}")
    ratio = f"{loss_yen / credit_yen:.1f}倍" if credit_yen else "クレジットなし"
    print(f"クレジット {credit_yen:,.0f}円 / 業務損失の見積もり {loss_yen:,.0f}円 ({ratio})")


def chain():
    w = WINDOWS["30日の月"]
    parts = [("インターネット回線", 99.9), ("認証基盤(IdP)", 99.99), ("SaaS本体", 99.9)]
    total = 1.0  # 各要素の故障は互いに独立、という仮定で掛け合わせる
    for name, pct in parts:  # 直列: すべてが動いて初めて使える
        total *= pct / 100
    print(" x ".join(f"{n} {p}%" for n, p in parts) + f" = {total * 100:.3f}% (30日で{hms(w * (1 - total))}停止)")
    line = 1 - (1 - 0.995) ** 2  # 並列: 99.5%の回線2本のどちらかが生きていればよい
    total2 = line * 0.9999 * 0.999
    print(f"回線を99.5%x2本の冗長にすると 回線部分={line * 100:.4f}% 全体={total2 * 100:.3f}% (30日で{hms(w * (1 - total2))}停止)")


SECTIONS = {"downtime": downtime, "window": window, "partial": partial,
            "credit": credit_vs_loss, "chain": chain}
for name in sys.argv[1:] or SECTIONS:
    print(f"== {name}")
    SECTIONS[name]()

引数で計算する節を選びます。downtimeは稼働率ごとの許容停止時間、windowは測定期間の違い、partialは部分障害の数え方、creditはクレジットと損失の比較、chainは合成稼働率で、引数を付けなければ全部を順に出力します。クレジット表の値は、次の節で示す各社のSLA文書（執筆時点）から写したものです。

$ python3 sla_calc.py downtime
== downtime
稼働率 | 28日の月 | 30日の月 | 31日の月 | 1年(365日) | 営業時間のみ(月20日x9時間)
99.0% | 6時間43分12秒 | 7時間12分00秒 | 7時間26分24秒 | 87時間36分00秒 | 1時間48分00秒
99.5% | 3時間21分36秒 | 3時間36分00秒 | 3時間43分12秒 | 43時間48分00秒 | 54分00秒
99.9% | 40分19秒 | 43分12秒 | 44分38秒 | 8時間45分36秒 | 10分48秒
99.95% | 20分10秒 | 21分36秒 | 22分19秒 | 4時間22分48秒 | 5分24秒
99.99% | 4分02秒 | 4分19秒 | 4分28秒 | 52分34秒 | 1分05秒

99.9%なら、30日の月で43分12秒、1年で8時間45分36秒です。月の日数でも変わり、28日の月は40分19秒、31日の月は44分38秒まで許されます。Google WorkspaceのSLAは暦月の総分数から停止の分数を引いて割る定義なので（執筆時点）、同じ99.9%でも2月と3月では許容される分数が違います。

測定期間を変えると、同じ停止の評価が変わる

$ python3 sla_calc.py window
== window
停止1時間00分00秒: 30日の月=99.861%, 1年(365日)=99.989%, 営業時間のみ(月20日x9時間)=99.444%
停止8時間00分00秒: 30日の月=98.889%, 1年(365日)=99.909%, 営業時間のみ(月20日x9時間)=95.556%

業務時間中に8時間止まった場合、30日の月で測ると98.889%で99.9%を大きく割りますが、1年で測ると99.909%で99.9%を満たします。年単位のSLAは、1回の長い停止を残りの期間で薄めてしまいます。委託契約や社内システムのSLAを書くなら、測定期間は月にすることをすすめます。月次の定例報告と周期がそろい、大きな停止が「年間では達成」として埋もれません。

営業時間だけを母数にする方式は性質が逆です。平日20日×9時間で測ると、同じ1時間の停止が99.444%になり、24時間で測る30日の月（99.861%）より厳しく出ます。その代わり、夜間と休日の停止は1分も数えません。利用が業務時間に集中する社内システムには営業時間方式が実態に合いますが、夜間バッチや時差のある拠点の利用があるなら、夜間は別の指標（バッチの完了時刻など）で押さえておく必要があります。

一部の利用者だけが使えない障害の数え方

SaaSの障害は、全員が同時に使えなくなるとは限りません。例として、利用者300人の会社で、30人（10%）または9人（3%）が4時間使えなかったケースを、3つの数え方で計算しました。

$ python3 sla_calc.py partial
== partial
300人中30人(10%)が4時間00分00秒使えない: 利用者分=99.944% 閾値5%=99.444% 全断のみ=100.000%
300人中9人(3%)が4時間00分00秒使えない: 利用者分=99.983% 閾値5%=100.000% 全断のみ=100.000%

「利用者分」は、Microsoft 365（Exchange Online、SharePoint Online、Microsoft Teams）のSLAにある式に沿った数え方で、停止の分数に影響を受けた利用者数を掛け、全利用者の分数で割ります。30人が4時間使えなくても99.944%で、99.9%を下回りません。「閾値5%」はGoogle Workspaceの定義を単純化したもので、ドメインのユーザーエラー率が5%を超えている時間をまるごと停止と数えます。影響を受けた利用者の割合をエラー率とみなした近似で、実際の判定はGoogleがサーバー側のエラー率で行います。10%なら4時間がすべて停止になって99.444%、3%なら停止はゼロです。

「全断のみ」は、Amazon EC2のリージョン単位のSLAのように、2つ以上のアベイラビリティゾーン（AZ）に置いた稼働中のインスタンスがすべて同時に外部と通信できなくなった時間だけを数える方式に当たります。一部のAZだけの障害は、この数え方では稼働率に出ません。どの方式が有利かは障害の形で入れ替わるので、製品を比べるときは稼働率の数字より先に、停止の定義を読み比べてください。

部分障害は、どの数え方でもSLAの数字に出にくくなります。上の3%のケースでは、9人が4時間仕事を止めても、3つの方式すべてで稼働率は99.9%以上です（利用者分で99.983%）。自社の業務への影響は、SLAの稼働率ではなく、ヘルプデスクの受付記録と自社の監視ログで残してください。クレジットを請求するときにも、この記録が証拠になります。

Microsoft 365・Google Workspace・AWSのSLAを並べて読む

2026年10月18日に、次の文書を開いて確認しました。Microsoftは「Service Level Agreement for Microsoft Online Services」（2026年10月1日版）、Googleは「Google Workspace Service Level Agreement」（2026年8月31日更新）、AWSは「Amazon Compute Service Level Agreement」（2022年5月25日更新）、「Amazon S3 Service Level Agreement」（2023年11月28日更新）、「Amazon RDS Service Level Agreement」（2024年1月22日更新）です。いずれも改定されるので、契約や更新の前に最新版と日付を確かめてください。表は執筆時点の内容で、AWSはEC2、S3、RDSの3サービスに絞っています。

未達のときに何が返ってくるかは、次の表のとおりです（執筆時点）。

2つの表から読み取れる実務上の違いは3点です。まず、どの社も「停止」を自社で定義しており、利用者が感じる「社内から使えない」より範囲が狭いことです。例えば、拠点とデータセンターの間のネットワーク障害はMicrosoftの、責任分界点より先のインターネット接続の問題はAWSの対象外です。次に、クレジットの形が違います。料金に対する割合で返すのがMicrosoft 365とAWS、サービスの日数で返すのがGoogle Workspaceです。最後に、請求の期限と方法がばらばらで、どれも利用者が自分で請求しなければクレジットは受け取れません。

障害情報が公表されても、クレジットが自動で付くわけではありません。障害の告知はSLA未達やクレジットの対象であることの確認ではない、とMicrosoftの文書は明記しており、Googleは30日以内に請求しなければ権利を失うと定めています。AWSは請求にリクエストログを求めます。大きな障害の後は、請求期限を予定表に入れ、影響を受けた利用者数と時間帯を自社の記録から抜き出しておいてください。

Salesforceについては、Main Services Agreement（2026年9月1日版）の2.1条を確認しました。計画停止（事前に電子的に通知）と、Salesforceの合理的な支配が及ばない事情（インターネット接続事業者の障害や遅延、サービス妨害攻撃など）を除いて、購入したオンラインのサービスを24時間・週7日利用できるよう商業的に合理的な努力をする、という書き方で、この契約書には稼働率の数値もサービスクレジットの規定もありませんでした。数値の約束が導入の条件なら、見積もりの段階で書面での提示を求め、出てこなければ「数値の保証なし」と稟議書に書いておくのが確実です。

稟議の前にSLA文書から書き写しておく項目は次のとおりです。

• 文書名、版の日付、確認した日
• 対象になるサービスとプラン（無償版やプレビュー、特定のエディションを除外している文書がある）
• 停止の定義と計算の単位（利用者×分か、エラー率か、全断のみか）
• 計画停止と対象外の条件。特に、自社側のネットワーク障害がどう扱われるか
• クレジットの率、上限、受け取り方
• 請求期限、必要な証拠、請求の窓口（再販業者経由の契約かどうか）

サービスクレジットでは業務の損失は埋まらない

SLAの水準を比べてSaaSを選びたくなりますが、クレジットの額と業務の損失は桁が違います。利用者300人のSaaSが業務時間中に8時間全面停止したケースを計算しました。月額1,500円/人、時間単価3,000円、業務影響50%は計算のための仮の値で、実在のプランの価格や実際の人件費ではありません。

$ python3 sla_calc.py credit
== credit
入力(仮の値): 300人, 月額1,500円/人, 停止8時間00分00秒, 時間単価3,000円, 業務影響50%
月間稼働率 98.889% -> M365の表: 50% / Workspaceの表: 7日分
クレジット 225,000円 / 業務損失の見積もり 3,600,000円 (16.0倍)

30日の月で98.889%となり、Microsoft 365の表では月額の50%、Google Workspaceの表では7日分のサービス期間が対象です。金額に直すと、Microsoft 365型のクレジットは225,000円、業務損失の見積もりは3,600,000円で、16.0倍の開きがあります。加えてMicrosoftの文書は、クレジットを売上の損失や運用コスト、間接的な損失の補償には充てないと明記しています（執筆時点）。

判断のルールとして、SaaSのクレジットは稟議の費用対効果に入れないことをすすめます。代わりに「停止1時間あたりの損失×許容できない停止時間」を見積もり、それが代替手段（別系統の連絡手段、オフラインで回せる業務手順、データの手元への定期エクスポート）の年間コストを上回るなら、その代替手段を用意します。どこまで備えるかは、IT-BCPの記事の手順で業務ごとの目標復旧時間から決めてください。逆に、止まっても翌日にまとめて処理すれば済む業務なら、SLAの水準の差で製品を選び分ける意味は小さくなります。

直列につながるサービスの合成稼働率

利用者からSaaSまでの経路には、インターネット回線、認証基盤（IdP）、SaaS本体が直列に並び、どれか1つが止まれば使えません。各要素の稼働率を仮に置いて掛け合わせました。

$ python3 sla_calc.py chain
== chain
インターネット回線 99.9% x 認証基盤(IdP) 99.99% x SaaS本体 99.9% = 99.790% (30日で1時間30分40秒停止)
回線を99.5%x2本の冗長にすると 回線部分=99.9975% 全体=99.888% (30日で48分36秒停止)

回線99.9%、認証基盤99.99%、SaaS本体99.9%の直列は99.790%で、30日の月に1時間30分40秒の停止に相当します。どの要素も99.9%以上なのに、全体は99.9%を下回ります。回線を99.5%の2本で冗長にすると、回線部分は99.9975%まで上がりますが、全体は99.888%で、まだ99.9%に届きません。直列の稼働率は最も低い要素を超えないので、回線への投資で取り戻せるのは回線の分だけです。

この掛け算は2つの仮定に立っています。故障が互いに独立していること、そして全要素がそろって初めて使える直列の構成であることです。同じ通信事業者の2回線や、同じビルの電源につながる機器のように原因を共有する要素は一緒に止まるので、実際の稼働率は計算より低くなります。また、各社のSLAの数字は「下回ったらクレジットを出す」境界であって、稼働の実績ではありません。SLA値どうしの掛け算は、どのベンダーもクレジットを払わずに済むぎりぎりの水準の目安として使ってください。

シングルサインオンで認証を1つのIdPに集めると、IdPはすべてのSaaSに共通する直列要素になります。IdPが止まれば、SaaS側が動いていても誰もログインできません。IdPのSLAを確認するのに加えて、IdPを経由せずに管理者がサインインできる緊急用アカウントと、その使用手順を用意しておくと、復旧作業そのものに入れなくなる事態は避けられます。

委託契約や社内システムにSLAを書く

SaaSのSLAは読むだけですが、社内システムの保守・運用を外部に委託するときや、情シスが社内向けにサービスを提供するときは、SLAを書く側に回ります。項目は受託側のひな形に合わせるのではなく、こちらの業務の都合から決めます。次のひな形は、保守・運用の委託契約の別紙を想定して私たちが作ったSLAの具体例で、数値はすべて例です。業務に合わせて置き換えてください。

1. 対象システム: 販売管理システム（本番環境のみ。検証環境は対象外）
2. サービス時間: 平日 8:00〜20:00（年末年始と計画停止を除く）
3. 可用性
   測定方法: 社内ネットワークの監視サーバーから1分間隔でログイン画面にアクセスし、
             2回連続で応答がない、またはHTTP 5xxを返した時点から停止とみなす
   測定期間: 暦月
   目標値: サービス時間に対して99.5%
   除外: 委託範囲外の回線障害（回線事業者の障害記録を月次報告に添付）
4. 障害対応
   重大度1（全利用者が業務を続けられない）: 受付から30分以内に初報、4時間以内に暫定復旧
   重大度2（一部の業務・利用者に影響）: 受付から2時間以内に初報、翌営業日中に暫定復旧
5. 計画停止: 5営業日前までに書面で通知。サービス時間外に実施し、月4時間まで
6. バックアップ: 日次取得の成否を月次報告に記載。リストア試験を半期に1回行い結果を報告
7. 報告: 翌月10営業日以内に月次報告書を提出（稼働率、障害一覧と原因、問い合わせ件数、改善策の進捗）
8. 未達時の扱い: 目標値を下回った月は、原因分析と改善計画を翌月の定例会で提出する。
   3か月連続で下回った場合は、体制と費用を含む契約条件の見直しを協議する
9. 見直し: 年1回、契約更新の3か月前に指標と目標値を見直す

測定方法をここまで具体的に書くのは、受託側の死活監視（サーバーが起動しているか）と利用者の体感（画面が開くか）が一致しないからです。一方で、測定点を社内ネットワークに置くと、社内LANやインターネット回線の障害まで停止に数えられます。回線が委託範囲に入っていないなら、ひな形の「除外」のように回線側の記録で切り分けられる書き方にしておくと、月次の報告会で数字の読み方が割れません。

保証値か目標値か、未達時に何を求めるか

ひな形では可用性を「目標値」とし、下回ったら改善計画を求める形にしました。減額（いわゆるペナルティ）付きの「保証値」は、受託側にとって未達時の損失になるので、見積もりへのリスク分の上乗せや、停止の定義を狭める交渉を招く要因になります。保守・運用を1〜2社に任せている少人数の情シスなら、目標値と改善計画、連続未達での契約見直しの組み合わせのほうが、費用を上げずに改善を引き出しやすいと考えています。減額を入れるなら、測り方に争いの余地がない少数の項目（例えば可用性だけ）に絞り、上限を月額の何割までと書くのが現実的です。複数の受託者がいて切り替えも難しくない場合は、保証値で競わせる選択も成り立ちます。

減額条項と損害賠償の条項の関係や、契約の種類によって書き方がどう変わるかは、契約全体の構成にかかわります。ここで挙げたのは運用面からの提案なので、条文にする前に法務担当か顧問弁護士の確認を通してください。

稟議と監査で残すもの

SaaSの導入稟議には、SLA文書の名前と版の日付、約束する水準と測り方、クレジットの率・上限・請求期限を書き写し、自社が許容できる停止時間との差と、その差を何で埋めるかを添えます。例えば「月99.9%（30日の月で43分12秒）を約束。ただし部分障害は数字に出にくい。メールが止まったときは社内チャットで連絡する」という書き方です。ベンダー選定の段階なら、SLAの要件を最初から提案依頼書に入れておくと、各社の回答を同じ物差しで比べられます（RFPの書き方）。

監査に備えて残すのは、契約時点のSLA文書の写し（PDFにして取得日を記録）、月次報告書、自社の監視ログ、クレジット請求の記録と結果です。初回のサブスクリプション期間中はSLAを変えず、更新時にはその時点の版を適用する、とMicrosoftの文書は定めています（執筆時点）。更新の稟議に、前回保存した版と最新版の差分を確認する手順を入れておけば、条件が変わったことを見落としません。

契約を結ぶ前に、委託契約の別紙や社内向けのSLAを次の項目で点検します。

• 停止の定義が「利用者から見て使えない」状態を指しているか。測定点はどこか
• 測定期間は月か。年や四半期で平均していないか
• 計画停止の通知期限、実施する時間帯、月あたりの上限が書かれているか
• 一部の拠点や利用者だけの障害をどう数えるかが決まっているか
• 未達時の扱い（クレジット、減額、改善計画）とその上限、報告や請求の期限
• 月次報告の期日と項目、自社側で保管する記録
• 指標と目標値を見直す時期（契約更新の何か月前か）
• 業務の損失をSLA以外の何で補うか（代替手段、BCP）

よくある質問

SLAとはIT用語で何ですか？

ITサービスの提供者と利用者が、稼働率や障害時の対応時間といった品質の水準と、その測り方、下回ったときの扱いを取り決めた合意文書です。執筆時点で確認したMicrosoft 365、Google Workspace、AWSのSLAでは、下回ったときの救済はサービスクレジット（料金の減額や利用期間の延長）でした。

SalesforceにはSLAはありませんか？

執筆時点で確認したSalesforceのMain Services Agreement（2026年9月1日版）には、稼働率の数値やサービスクレジットの規定がありません。2.1条で、計画停止と支配の及ばない事情を除き、24時間・週7日利用できるよう商業的に合理的な努力をすると定めているだけです。数値の約束が必要なら、契約前に書面での提示を求めてください。

AWSのSLAの稼働率は？

サービスごとに別の文書で決まっています。執筆時点では、EC2は複数AZ構成のリージョン単位で99.99%、単一インスタンスで99.5%、S3 Standardは99.9%（Standard-IAやIntelligent-Tieringなど一部のストレージクラスは99.0%）、RDSはマルチAZ構成で99.95%、シングル構成で99.5%です。使う構成に当たるSLAのページで確認してください。

SLAとDLPの違いは何ですか？

略語が似ているだけで、別のものです。SLAはサービスの品質水準と未達時の扱いを決める合意文書、DLP（Data Loss Prevention）は機密データの外部送信や持ち出しを検知して止める情報漏えい対策の仕組みです。製品選定では、SLAは契約条件として、DLPはセキュリティ機能として別々に比べます。

まとめ

SaaSのSLAは、製品を選ぶ決め手ではなく、障害のあとに請求期限と証拠をそろえるための文書として読みます。業務の損失はクレジットでは戻らないので、停止時の代替手段とBCPで備えます。委託契約や社内システムのSLAは、月単位の測定期間、利用者側の測定点、未達時の改善計画の3つから書き始めると、運用で揉めにくくなります。最初の作業として、いま使っている主要なSaaSのSLA文書を開き、版の日付・停止の定義・請求期限の3項目を契約台帳に書き写してください。

次に読む

• SREとは？DevOps・プラットフォームエンジニアリングとの違いと始め方（SLOとエラーバジェット）
• BCPとは？IT部門が作るシステム継続計画（IT-BCP）の手順
• 情シスのためのRFP（提案依頼書）の書き方：テンプレートと評価表の作り方