保守を委託しているベンダーから、契約更新の資料として「稼働率99.9%を保証します」という一文が出てきたとします。この数字は高いのでしょうか、低いのでしょうか。自社の業務にとって十分なのでしょうか。多くの発注担当者が、この問いに自分の言葉で答えられないまま、提示された数値のまま契約を更新しています。
判断できない理由は、知識が足りないからではありません。「何を測って、その数字をどう数えるか」という測定の定義が、契約書のどこにも書かれていないからです。定義がなければ、99.9%という数値は比較も検証もできない記号にすぎません。障害が起きたときに「監視上はサーバが応答していたので、SLA 違反には当たりません」と説明され、現場では半日業務が止まっていたのに反論できない——この状況は、測定の定義を自社側で持っていないことから生まれます。
一方で、SLO・SLI について調べると出てくる解説の多くは、自社サービスを自社のエンジニアで運用している企業を前提に書かれています。SRE チームがダッシュボードを見ながら指標を設計する話は、保守を外部に委託していて社内に専任者がいない立場からは、そのまま自社に置き換えるのが難しいものです。
しかし、SLI（何を測るか）と SLO（どの水準を目指すか）は、本来は発注者側が主導して決められる領域です。この2つを自社で先に定義しておけば、ベンダーが提示する SLA の数値は「検証できる対象」に変わります。打ち合わせの場で「その99.9%は、どの操作を、誰の視点で、どう数えた数字ですか」と問い返せるようになります。
本記事では、SLO・SLI とは何かという定義から始めて、保守を外部委託している発注者が自社で SLI・SLO を決める4つのステップ、システムの性格別の SLO 設定例、そして決めた数値を保守契約の SLA 条項へ落とし込む手順までを順に解説します。社内にインフラの専任者がいない前提で実行できる粒度に絞って整理します。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
SLA・SLO・SLIの3層構造｜ベンダー提示の稼働率を評価できない理由
まず、「稼働率99.9%」という数字だけが契約書に存在している状態が、構造的に何を欠いているのかを整理します。
発注者が「99.9%」の妥当性を判断できない構造的な原因
保守契約に書かれた稼働率の数値を評価するには、その下に2つの土台が必要です。ひとつは「何を、どこで、どう数えた値なのか」という測定の定義。もうひとつは「自社の業務にとって、どの水準を維持できていれば許容できるのか」という目標の設定です。
契約書に数値だけがある状態は、この2つの土台が空白のまま、いちばん上の結論だけが置かれている状態です。土台がないので、次のような問いに誰も答えられません。
- 「稼働している」とは、サーバのプロセスが生きていることでしょうか、それとも社員がログインして受注登録を完了できることでしょうか
- 分母の「全体時間」には、計画メンテナンスの時間や夜間の非稼働時間が含まれているのでしょうか
- そもそも自社の業務は、月に何分止まったら実害が出るのでしょうか
こうした問いに答える枠組みが、SLI・SLO・SLA という3層の構造です。順に見ていきます。
SLI・SLO・SLAの役割分担を一枚の表で整理する
3つの用語は「実測値」「目標値」「契約上の約束」という関係で並んでいます。SLI SLO 違いを整理するうえで重要なのは、それぞれ誰が決め、誰が測り、どこに書かれるものなのかという役割分担です。
層 | 日本語名 | 何を表すか | 発注者が決めること | ベンダーが測ること | 契約に書くこと |
|---|---|---|---|---|---|
SLI | サービスレベル指標 | サービスが正常に提供できているかを表す実測値（例: ログイン成功率、応答時間3秒以内の割合） | どの操作を測るか、成功をどう定義するか | 定義に沿った実測値の収集とレポート提出 | 測定対象・計測点・計算式（定義として） |
SLO | サービスレベル目標 | SLI に対して維持したい水準（例: ログイン成功率99.5%以上） | 業務影響と過去実績から自社の目標水準 | SLO を維持するための運用設計 | 原則として書かない（自社の内部目標） |
SLA | サービスレベル合意 | 契約として合意する最低ラインと未達時の扱い | 譲れない最低ラインと報告要求 | 達成状況の報告 | 保証水準・除外条件・報告頻度・未達時の対応 |
この表で押さえたいのは、SLI と SLO は本来「発注者が決められる（決めるべき）領域」だという点です。ベンダーが決めて提示してくるのが当然だと考えていると、測定の定義は自動的にベンダーの監視ツールの都合で決まります。それが「監視上は正常だった」という説明が成立してしまう仕組みの正体です。
SLI→SLO→SLAの順に決めるのが原則である理由
この3つは、SLI から順に下から積み上げるのが原則です。理由は3つあります。
第一に、測れないものは目標にできません。「ユーザーが快適に使えること」は目標として立派ですが、数値化の定義がなければ達成したかどうかを誰も判定できません。先に SLI を決めることで、目標が検証可能な形になります。
第二に、目標がなければ契約水準を決められません。SLA に書く数値は「未達なら契約上の問題として扱う最低ライン」です。自社の目標水準を持たないままこの最低ラインを決めると、ベンダー側が達成しやすい数値がそのまま最低ラインになります。
第三に、外部サービスへの依存を織り込む必要があります。自社システムがクラウドや外部 API に依存している場合、依存先の SLA を上回る水準を自社の SLO に置いても実現できません。依存先の保証水準を確認したうえで自社の SLO を置き、そこからさらに余裕を見て SLA の数値を決める、という順序になります。
なお、この積み上げ方は Google の SRE 本でも基本的な考え方として整理されています（Google SRE Book "Service Level Objectives"）。
SLIとは？サービス品質を数値で測るための指標
SLI（Service Level Indicator / サービスレベル指標）とは、サービスが正常に提供できているかどうかを表す実測値です。Google の SRE Workbook では、SLI を「良かったイベント数 ÷ 全イベント数」という比率として定義することが推奨されています（Google SRE Workbook "Implementing SLOs"）。
この「比率として表す」という考え方が重要です。障害の件数や復旧までの時間を並べるだけでは、品質が良い状態なのか悪い状態なのかを一定の物差しで比較できません。分子と分母を定義して割合にすることで、月をまたいでも、システムをまたいでも比較できる数値になります。
サービスレベル指標として何を測るか——4つの代表的なSLIタイプ
実務でよく使われる SLI は、大きく次の4タイプに整理できます。
SLIタイプ | 測るもの | 定義の例 | 向いているシステム |
|---|---|---|---|
可用性 | 使える状態だったか | 正常応答したリクエスト数 ÷ 全リクエスト数 | ほぼすべてのシステム |
レイテンシ | 十分に速かったか | 3秒以内に応答したリクエスト数 ÷ 全リクエスト数 | 顧客向け Web サービス、検索・照会が多い業務システム |
エラー率 | 正しく処理できたか | エラーを返さなかったリクエスト数 ÷ 全リクエスト数 | 決済・登録など更新系処理を持つシステム |
鮮度・完了性 | データが期待どおり揃っているか | 定刻までに完了したバッチ回数 ÷ 全実行回数 | 夜間バッチ、データ連携、BI・分析基盤 |
多くの保守契約は、このうち可用性だけを対象にしています。しかし業務が止まる原因は「使えない」だけではありません。画面は開くが検索に1分かかる、登録ボタンを押すと一定確率でエラーになる、朝の会議で見る数字が前日分に更新されていない——これらはいずれも可用性の指標では検知されず、レイテンシ・エラー率・鮮度の指標を持って初めて数値として現れます。
「動いている」を誰の視点で判定するか——サーバ視点とユーザー視点のずれ
同じ「稼働している」という判定でも、どこから見るかによって結果が変わります。ここが「監視上は正常だったが業務は止まっていた」という食い違いの発生源です。
視点 | 測定の例 | 検知できること | 検知できないこと |
|---|---|---|---|
サーバ視点 | Ping 応答、プロセスの死活監視、CPU・メモリ使用率 | サーバダウン、リソース枯渇 | 認証基盤の障害、DB のロック、アプリ内部のエラー、ネットワーク経路の問題 |
ユーザー視点 | ログイン成功率、主要画面の表示成功率、業務処理の完了率 | 利用者が業務を完了できたかどうか | サーバ個別の異常（ただし結果として現れる） |
サーバ視点の監視は運用に必要ですが、SLI としては不十分です。サーバが応答していても、認証サーバが落ちていればログインできず、DB がロックしていれば受注登録は完了しません。利用者から見れば、業務は完全に止まっています。
SRE Workbook でも、SLI は利用者が感じる信頼性に近い形で定義すべきであり、インフラのメトリクスをそのまま指標にしないことが推奨されています。発注者としては「サーバが動いていたかどうか」ではなく「社員・顧客がやりたい操作を完了できたかどうか」を測る定義を求める、という立場をとるのが出発点になります。
時間ベースとイベントベース——数え方が変わると同じ障害でも数値が変わる
もうひとつ、契約前に確認しておきたいのが「何を分母にするか」です。同じ障害でも、数え方によって稼働率の数字は変わります。
- 時間ベース: 「稼働していた分数 ÷ 全体の分数」。1分単位などで正常・異常を判定し、時間の割合で算出します。分かりやすい反面、「1分間のうち何件のエラーが出ていたか」は表現できません
- イベント（リクエスト）ベース: 「成功したリクエスト数 ÷ 全リクエスト数」。利用者が受けた影響の規模を反映しやすく、部分的な障害も数値に現れます
たとえば、平日の日中に30分間だけ「10回に1回エラーになる」状態が続いた障害を考えます。時間ベースで「サーバは応答していた」と判定すれば、この30分は稼働時間に算入され、稼働率はほぼ100%のままです。イベントベースでエラー率を測っていれば、その30分間に発生したエラーが分子に反映され、数値として異常が可視化されます。
どちらが正解というものではなく、対象システムの性格に合わせて選ぶものです。重要なのは、契約前に「どちらの数え方で、どの粒度で判定するのか」を文書で合意しておくことです。これが曖昧なままだと、障害後の解釈が必ず食い違います。
SLOとは？SLIに置く目標値と、SLAとの決定的な違い
SLO（Service Level Objective / サービスレベル目標）とは、決めた SLI に対して「どの水準を維持するか」を定める目標値です。「ログイン成功率を99.5%以上に保つ」「応答3秒以内の割合を99%以上に保つ」といった形で表現します。
SLA との決定的な違いは、SLO が自社の内部目標であるのに対し、SLA は契約上の約束であり未達時の扱いが伴う点です。この2つを混同して同じ数値にしてしまうと、後述するように交渉の余地も運用の余裕も失われます。
サービスレベル目標は理想値ではなく実績値から置く
SLO を決めるとき、最初にやりがちなのが「高いほど良い」という発想で99.99%のような数値を置いてしまうことです。これは費用の高騰を招くだけでなく、達成できない目標が形骸化する原因にもなります。
現実的な出発点は、直近6〜12か月の実績値を確認することです。ベンダーに月次の障害報告や監視ログの提出を依頼すれば、おおよその実績は把握できます。そのうえで、次の3点を突き合わせて目標水準を決めます。
- 過去実績: 直近1年間でどの程度の水準だったか
- 業務影響: どの程度止まると実害（受注機会の損失、締め処理の遅延、顧客からの申し出）が出るか
- 費用の許容範囲: 水準を上げるために追加できる保守費用の上限
ただし、実績値をそのまま目標にすればよいという話でもありません。Google の SRE 本では、現状の数値を無反省に目標として採用すると、達成のために過大な努力を要し続けるシステムを抱え込むことになると注意が促されています。実績値は「実現可能性の確認材料」として使い、目標水準そのものは「利用者が何を重視しているか」から決めるのが本筋です。
実務的には、実績値と業務影響の両方を確認したうえで「実績と同等か、わずかに上」を初回の SLO として置き、四半期ごとに見直していく進め方が現実的です。
稼働率だけをSLOにすると取りこぼす品質
SLO 稼働率という組み合わせで語られることが多いため、SLO は稼働率のことだと理解されがちですが、稼働率は SLO のひとつの形にすぎません。稼働率だけを目標に置くと、次のような品質低下が目標の網から漏れます。
- 遅い: 画面は開くが、月末の集計処理に10分かかる。稼働率上は100%
- エラーが混ざる: 一定確率で登録に失敗するが、再実行すれば通る。サーバは応答しているため稼働率上は正常
- データが古い: 連携バッチが失敗し、参照系のデータが前日のまま。システムは動作しているため稼働率上は正常
- 一部の機能だけ止まる: 帳票出力だけが失敗する。全体としては稼働している扱い
これらを目標に含めたい場合は、稼働率とは別に「レイテンシの SLO」「エラー率の SLO」「バッチ完了時刻の SLO」を立てます。すべてを網羅する必要はなく、業務影響が大きいものから2〜3個を追加する形で十分です。
なお、稼働率の数値と許容できる停止時間の対応関係（99.9%であれば月あたりどの程度か、といった換算）については、エラーバジェットとはで早見表とあわせて整理しています。SLO を決めた後に「あとどれだけ止まってよいか」を管理する考え方も同記事の範囲です。
SLOをそのままSLAの数値にしてはいけない理由
自社で決めた SLO をそのまま SLA の保証水準として契約に書くのは避けたほうがよい判断です。理由は次の3点です。
第一に、余裕がなくなります。SLO は「維持したい水準」であり、多少下回っても改善アクションで戻せばよい性質のものです。これを契約上の最低ラインにしてしまうと、わずかな未達がただちに契約上の問題になり、双方が硬直します。
第二に、費用が跳ね上がります。契約上の保証水準は、ベンダーにとって未達時のリスクを伴う数値です。SLO と同じ厳しい水準を保証させれば、そのリスク分が保守費用に上乗せされます。
第三に、SRE の実務でも内部目標を対外的な約束より厳しく置くことが推奨されています。Google の SRE 本では、公表する SLA より内部の SLO を厳しく設定することで、問題が外部に見える形になる前に対処する余地が生まれると説明されています。
したがって、SLO SLA 違いを実務に落とすと「自社の目標（SLO）＝厳しめ、契約の最低ライン（SLA）＝それより緩め」という2段構えになります。この構造を持っていると、ベンダーとの打ち合わせで「当社の運用目標はこの水準ですが、契約上の保証はこの水準で結構です」と説明でき、要求の意図と譲歩の範囲が伝わりやすくなります。
SLIの決め方｜ユーザーの重要操作から測定対象を絞る4ステップ
ここからは、社内に専任者がいない前提で実行できる SLI 決め方の手順を4ステップに分けて説明します。会議室でホワイトボードに書き出せる範囲の作業です。
ステップ1｜業務が止まると困る操作を洗い出す
最初に決めるのは「測定対象の操作」です。システム全体を対象にするのではなく、止まると業務が止まる具体的な操作を洗い出します。
洗い出すときは、部門ごとに次の形式で書き出すと精度が上がります。
操作 | 利用部門 | 使う時間帯 | 止まったときの実害 | 実害の大きさ |
|---|---|---|---|---|
受注登録 | 営業部 | 平日9〜19時 | 受注を紙で受けて後追い入力。当日出荷が間に合わない | 大 |
在庫照会 | 営業部・倉庫 | 平日8〜20時 | 電話確認で代替可能だが処理速度が落ちる | 中 |
月次締め処理 | 経理部 | 毎月1〜5営業日 | 締め日が後ろ倒しになり、支払処理に影響 | 大 |
社内ポータル閲覧 | 全社 | 平日終日 | 情報参照が遅れるが業務は継続可能 | 小 |
ここで「実害の大きさ」を付けておくと、後のステップで測定対象を絞る判断が楽になります。実害が小さい操作は、SLI の対象から外して構いません。
なお、対象を洗い出す前提として、どこまでが委託先の保守範囲でどこからが自社の運用範囲かを確認しておく必要があります。この切り分けが曖昧なままだと、測定対象を決めても「その事象は保守の対象範囲外です」という説明になりかねません。範囲の整理については保守と運用の違いを参照してください。
ステップ2｜操作ごとに「成功」の定義を言語化する
洗い出した操作それぞれについて、「どうなったら成功か」を文章で書き出します。曖昧な表現を避け、判定できる形にするのがポイントです。
- 悪い例: 「受注登録が正常に使えること」
- 良い例: 「営業担当がログインした状態で受注登録画面を開き、必要項目を入力して登録ボタンを押してから5秒以内に登録完了画面が表示されること」
この作業で決まるのは、次の3点です。
- 開始点と終了点: どこからどこまでを1回の操作とみなすか
- 成功の条件: エラーが出ないこと、正しい結果が返ること
- 時間の条件: 何秒以内に完了すれば成功とみなすか
時間の条件は、業務の実感から決めて構いません。「営業担当が電話中に照会するので3秒を超えるとつらい」といった現場のヒアリングが根拠になります。
ステップ3｜どこで測れるかを確認する（計測点の特定）
定義した「成功」を、システムのどこで観測すれば数値にできるかを確認します。計測点の選択肢は主に次の3つです。
計測点 | 何を測れるか | 導入の負荷 | 注意点 |
|---|---|---|---|
Web サーバ・ロードバランサのアクセスログ | リクエストごとのステータスコードと応答時間 | 低（多くの場合すでに取得済み） | 認証や外部連携の失敗が正常応答として記録される場合がある |
APM・アプリケーション監視ツール | 画面や処理単位の成功率・処理時間 | 中（導入済みかで大きく変わる） | ツール利用料が発生する。委託先の環境に依存する |
外形監視（外部から定期的にアクセスして確認） | 利用者に近い位置から見た応答可否と応答時間 | 低〜中 | 実際の利用者操作そのものではなく、代表的な操作の疑似実行になる |
社内に専任者がいない場合、まずは既存のアクセスログで測れる範囲から始めるのが現実的です。そのうえで、ログでは判定できない重要操作（ログイン成否、決済完了など）については、外形監視を追加するか、委託先に APM の導入を相談する形になります。
ステップ4｜既存の監視・ログで測れるかを委託先に確認する
計測点の当たりを付けたら、委託先に確認します。ここで聞くべき項目は次のとおりです。
- 現在、どのログ・監視データを、どのくらいの期間保管していますか
- ステップ2で定義した操作の成功・失敗は、既存のデータから判定できますか
- 判定できない場合、何を追加すれば測れるようになりますか（設定変更か、ツール追加か）
- 追加する場合の費用と、対応にかかる期間はどの程度ですか
- 測定結果を月次で提出いただくことは可能ですか。その様式はどうなりますか
この確認を契約交渉より前に済ませておくと、「測れない指標を契約に書いてしまう」という失敗を避けられます。測れないものを条項化しても、達成状況を誰も確認できず、条項が形骸化するだけです。
SLIは絞る——多く測るほど運用が回らなくなる
最後に、数の問題です。SRE Workbook では、顧客にとって最も重要な機能を表す SLI タイプを5つ以下に絞ることが推奨されています。指標を増やしすぎると、本当に重要な指標に注意を向けられなくなるためです。
発注者の立場でも同じことが言えます。10個の指標のレポートを毎月受け取っても、すべてを確認して判断する時間は現実的に確保できません。まずは実害が「大」の操作から3〜5個の SLI を選び、運用が回ることを確認してから必要に応じて追加する進め方が無理のない範囲です。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
SLO設定例｜業務システム・顧客向けWebサービス・バッチの3パターン
同じ「99.9%」という数値でも、システムの性格によって意味も難易度も変わります。ここでは典型的な3パターンについて、SLO 設定 例として考え方を整理します。
社内業務システム｜サービス提供時間を区切って測る
社内の基幹系システムや業務システムは、利用時間帯が限られています。この場合、24時間365日を分母にして稼働率を測ると、実態と乖離した数値になります。
- 測る SLI: 業務時間帯における主要操作の成功率（受注登録、在庫照会、承認処理など）
- 目標水準の置き方: 分母を「平日8〜20時」のように業務時間帯に限定したうえで、成功率の目標を置く
- 見落としやすい点: 深夜帯を分母に含めると、深夜に発生した障害が薄まって数値上は良く見えます。逆に、深夜のメンテナンス時間を分母に含めたまま「24時間365日で99.9%」を要求すると、業務上は不要な水準をベンダーに求めることになり、費用だけが上がります
サービス提供時間を明示的に区切ることは、要求を弱めることではなく、必要な時間帯に確実な水準を求めるための設計です。契約交渉でも「深夜帯は保証対象外でよいので、平日日中の水準を上げてほしい」という形で、費用配分の交渉材料になります。
顧客向けWebサービス｜可用性・レイテンシ・エラー率を組み合わせる
社外の顧客が利用する Web サービスは、24時間アクセスされる前提になり、かつ「遅い」「エラーが出る」が直接的に離脱や問い合わせにつながります。
- 測る SLI: 可用性（正常応答率）、レイテンシ（一定時間以内の応答割合）、エラー率（更新系処理の成功率）の3つを組み合わせる
- 目標水準の置き方: 可用性は全時間帯で、レイテンシとエラー率は特に重要な画面・処理に限定して目標を置く。全画面に一律の応答時間目標を置くと、重い処理（帳票生成、大量検索）が常に未達になり運用が回りません
- 見落としやすい点: 平均応答時間を目標にすると、一部の利用者だけが極端に遅い状態を検知できません。「3秒以内に応答した割合が99%」のように、割合で表現する形にします
夜間バッチ・データ連携｜完了時刻とデータ鮮度で測る
夜間バッチや外部システムとのデータ連携は、「動いているかどうか」よりも「決まった時刻までに終わっているか」「データが最新か」が業務上の関心事です。
- 測る SLI: 定刻までに完了したバッチ実行回数の割合、データの鮮度（参照時点でデータが何時間前のものか）
- 目標水準の置き方: 「毎営業日7時までに前日分の連携が完了している割合を99%以上」のように、業務の開始時刻から逆算して設定する
- 見落としやすい点: 稼働率で測ろうとすると、バッチが「動いた」だけで成功扱いになります。処理件数が0件でも異常終了していなければ成功と判定されてしまうため、完了件数や連携レコード数の妥当性まで含めた定義にしておく必要があります
目標水準を上げると保守費用がどう変わるか
SLO の水準は、そのまま保守体制の要求に跳ね返ります。水準を1段階上げるとき、ベンダー側で必要になるのは主に次の要素です。
上げたい水準 | ベンダー側で必要になること | 費用への影響 |
|---|---|---|
障害検知を早くする | 監視項目の追加、監視ツールの導入 | ツール利用料と設定費用が発生 |
復旧を早くする | 夜間・休日の待機要員配置、一次対応の即応体制 | 人員待機のコストが継続的に発生 |
障害そのものを減らす | 冗長構成の導入、定期的な改善作業 | インフラ費用と作業工数が増加 |
このため、すべてのシステムに一律の高い水準を要求するのは費用効率が悪い選択になります。実害が「大」のシステムには高い水準を、実害が「小」のシステムには標準的な水準を、という形で重要度に応じて水準を分けることで、必要な部分に予算を集中できます。契約交渉の場でも、この配分の考え方を示せると議論が具体的になります。
SLO・SLIを保守契約のSLA条項に落とし込む手順
自社で SLI と SLO を決めたら、次はそれを契約に反映します。ここでの目的は、障害時に「契約上は問題ありません」という説明で終わらせないことです。
SLAに載せる指標は絞る——測れて争えないものだけ
自社で決めた SLI をすべて SLA に載せる必要はありません。契約条項に載せる指標は、次の2つの条件を満たすものだけに絞ります。
- 測れる: 既存の監視・ログ、または合意して追加する仕組みで確実に数値化できる
- 争いにならない: 計算方法が一意に定まり、後から解釈の余地が生じない
たとえば「利用者の体感速度」は重要な関心事ですが、条項化には向きません。一方で「業務時間帯における受注登録処理の、5秒以内の応答完了率」は、計測点と計算式を定義すれば一意に判定できます。
SLA に載せなかった SLI は、契約条項ではなく月次レポートの報告項目として扱えば十分です。「保証対象ではないが、数値は毎月報告してもらう」という位置づけにしておけば、傾向の悪化には気づけます。
SLOとSLAの間にバッファを置く
前述のとおり、自社の SLO をそのまま SLA の保証水準にはしません。SLA には SLO より緩い数値を置き、その差分をバッファとして持ちます。
バッファの幅に決まった正解はありませんが、決め方の考え方は次のとおりです。
- 過去実績のばらつきを見る: 直近12か月の月次実績を並べ、最も悪かった月がどの程度だったかを確認する
- 改善に必要な猶予を織り込む: 目標を下回ってから改善アクションを打ち、効果が出るまでの期間（通常は1〜3か月）に耐えられる幅を確保する
- 費用との釣り合いで調整する: 保証水準を上げるほど費用が増えるため、実害が発生する水準を下回らない範囲で緩める
このバッファがあることで、SLO を下回った段階では「改善を要請する」、SLA を下回った段階では「契約上の対応に入る」という2段階の運用ができるようになります。
計測方法・除外条件・レポート様式を条項化前に合意する
障害後に解釈が食い違う原因は、ほぼこの3点の未合意に集約されます。数値を決める作業と同じ重みで、次の項目を文書化してください。
計測方法
- 誰の計測値を正とするか（ベンダーの監視ツールか、自社の外形監視か、双方の値が食い違った場合の扱い）
- 判定の粒度（1分単位か、リクエスト単位か）
- 集計期間（暦月か、月末締めの30日間か）
除外条件
- 計画メンテナンスの扱い（事前通知から何営業日前までの告知で除外対象とするか）
- 自社起因の事象（自社側のネットワーク障害、自社が管理する端末の問題）
- 不可抗力（災害、大規模なクラウド障害）の範囲
除外条件は、広く書かれるほどベンダー側に有利になります。「事前に合意した計画メンテナンス」のように、事前合意を条件とする書き方にしておくのが実務的です。
レポート様式
- 報告頻度（月次が一般的）
- 報告項目（各 SLI の実測値、目標との差、未達があった場合の原因と対策）
- 提出期限（翌月何営業日以内か）
なお、条項の具体的な文言や、稼働率・RTO・RPO といった項目ごとの数値目安については、保守契約にSLAを盛り込む方法で条項サンプルとあわせて整理しています。本記事で決めた数値を文言に落とす段階で参照してください。
未達時は「ペナルティ」より先に「改善プロセス」を決める
SLA というと減額や違約金といったペナルティ条項が想起されますが、発注者にとっての目的は「金銭的な補填」ではなく「業務が止まらないこと」です。優先順位としては、まず改善プロセスを定義し、金銭ペナルティは補助的に位置づけるのが実務に合います。
改善プロセスとして定義しておきたいのは次の内容です。
- 未達時の報告義務: 未達が判明してから何営業日以内に、原因と対策を報告するか
- 改善計画の提出: 対策の内容、実施時期、効果の確認方法を含む計画を提出する
- 改善状況のレビュー: 翌月以降のレポートで改善効果を確認する場を設ける
- 連続未達時の扱い: 3か月連続で未達が続いた場合の協議条項
金銭ペナルティを設ける場合も、保守費用の一定割合を上限とする減額規定が現実的な範囲です。過大なペナルティを求めると、その分のリスクが保守費用に上乗せされるか、除外条件が広く設定される方向で調整が入ります。
なお、保守運用を含む契約の全体構成については、IPA が公開している情報システム・モデル取引・契約書（第二版）が参考になります。サービスレベル項目の設定例については、経済産業省が公表しているガイドラインにモデルケースが収録されています（出典: 経済産業省「SaaS向けSLAガイドライン」、2008年）。
契約前にベンダーへ確認する質問リスト
ここまでの内容を、打ち合わせで使える質問の形にまとめます。提示された SLA 案に対して、次の順で確認していくと論点が漏れません。
- その稼働率は、どの操作を、どの計測点で測った数値ですか
- 分母には何が含まれますか（深夜帯、計画メンテナンス、自社起因の事象）
- 判定は時間ベースですか、リクエストベースですか
- 過去12か月の実績値を提示いただけますか
- 応答時間・エラー率・バッチ完了時刻について、測定と報告は可能ですか
- 除外条件に該当するかどうかは、誰がどう判定しますか
- 未達が発生した場合、報告と改善計画の提出はどのような流れになりますか
- 目標水準を1段階上げる場合、費用はどの程度変わりますか
- 測定結果のレポートは、どの様式で、いつ提出されますか
- サービスレベルの内容を見直す場合、契約期間中でも協議できますか
すべてに即答が得られなくても構いません。「持ち帰って確認します」という回答が返ってくること自体が、これまで曖昧だった論点を可視化した成果になります。
SLI・SLO運用でつまずくポイントと発注者側の備え
数値を決めて契約に書いた後にも、いくつかの詰まりどころがあります。事前に想定しておくと対処が早くなります。
委託先にSLIを測る仕組みがない
そもそも定義した SLI を測定できる仕組みが、委託先の環境に存在しないケースがあります。特に、サーバ死活監視だけで運用されてきたシステムでは、ユーザー視点の成功率を測る手段がないことが珍しくありません。
この場合の対処は2つです。ひとつは、監視の追加要件そのものを契約に含めること。「本契約の開始から3か月以内に、別紙に定める SLI を測定できる監視体制を整備する」といった形で、準備期間を含めて合意します。もうひとつは、初年度は測定可能な指標だけを SLA に載せ、翌年度の更新時に対象を広げる段階的な進め方です。
レポートの数字を自社で検証できない
ベンダーから提出される月次レポートの数値を、自社側で確認する手段がないと、レポートは「受け取るだけ」のものになります。数値が実態と食い違っていても気づけません。
対処として現実的なのは、自社側で最小限の計測手段を持つことです。主要な画面に対する外形監視は、比較的低いコストで導入でき、利用者に近い位置からの応答可否と応答時間を継続的に記録できます。ベンダーの数値と自社の数値が大きく食い違ったときに、その差分を議論の出発点にできる状態を作っておくことが目的です。
あわせて、社内のヘルプデスクへの問い合わせ記録も突き合わせの材料になります。「レポート上は正常だが、その日に同じ症状の問い合わせが集中していた」という事実は、測定定義の見直しにつながります。
SLOを厳しくしすぎて保守費用が跳ね上がる
前述のとおり、水準を上げれば費用は上がります。すべてのシステムに高い水準を求めると、予算が通らないか、通っても他の投資を圧迫します。
対処は、重要度に応じた水準の階層化です。実害が「大」のシステムには高い水準と手厚い体制を、「中」「小」のシステムには標準的な水準を割り当てます。稟議の場でも「全システムを一律に引き上げる案」ではなく「重要度に応じて配分した案」のほうが、投資対効果の説明がしやすくなります。
決めた数値が実態と乖離したまま放置される
一度決めた SLI・SLO を契約更新まで見直さないと、システムの変更や利用状況の変化に数値が追いつかなくなります。新機能が追加されたのに測定対象が古いまま、利用者数が倍増したのに目標水準はそのまま、といった状態です。
対処は、見直しの場を定例化することです。月次レポートの受領時に数値を確認し、四半期に一度は「測定対象と目標水準が今の業務実態に合っているか」を点検する運用にします。契約書にも「サービスレベルの内容は、双方の合意により契約期間中でも見直すことができる」という趣旨の協議条項を入れておくと、見直しの提案がしやすくなります。
まとめ｜SLI・SLOを持つと保守契約の交渉が「感覚」から「数値」に変わる
SLI（サービスレベル指標）は何を測るかを定義した実測値、SLO（サービスレベル目標）はその実測値に置く目標水準、SLA は契約として合意する最低ラインです。この3層のうち、SLI と SLO は発注者側が主導して決められる領域であり、ここを自社で持つことが、ベンダー提示の数値を検証可能にする起点になります。
明日から着手する場合の順序は次のとおりです。
- 重要操作の洗い出し: 止まると業務が止まる操作を、部門・時間帯・実害の大きさとあわせて書き出す
- 成功の定義: 操作ごとに「何秒以内に、どうなれば成功か」を文章にする
- 実績値の確認: 直近6〜12か月の実績をベンダーに照会し、現在の水準を把握する
- 目標水準の決定: 実績値と業務影響、費用の許容範囲を突き合わせて SLO を置く
- 契約条項への反映: 測れて争いにならない指標を選び、SLO より緩い水準を SLA に置く。計測方法・除外条件・レポート様式をあわせて合意する
この5段階を通ると、「稼働率99.9%は妥当か」という答えの出ない問いは、「当社が測るべき操作は受注登録と月次締め処理で、成功の定義はこれ、過去実績はこの水準、業務影響から見た目標はこの値、したがって契約上の最低ラインはこの値」という説明可能な形に変わります。ベンダーとの打ち合わせでも、稟議の場でも、根拠を添えて話せる状態になります。
指標をすべて完璧に揃える必要はありません。実害の大きい操作を3つ選び、成功の定義を書き出すところから始めれば、次の契約更新の議論は確実に変わります。
関連情報
保守契約の見直しや委託先の変更にあわせて、引き継ぎ時に確認すべき項目を整理したい場合は、失敗しないためのシステム保守の引継ぎチェックリストもご活用ください。監視・ドキュメント・体制など、契約前に確認しておきたい項目をチェックリスト形式でまとめています。無料でダウンロードいただけます。
自社システムのサービスレベル設計や、保守契約の条件見直しについてご相談されたい場合は、お問い合わせフォームからご連絡ください。測定対象の洗い出しや現行契約の整理といった、要件の整理段階からご相談いただけます。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- SLIとSLOはどちらから決めるべきですか？
先にSLI（何を測るか）を定義し、その実測値に対してSLO（維持したい水準）を置きます。測れない対象は目標として検証できず、SLOがなければ契約上の最低ラインであるSLAも決められないため、SLI→SLO→SLAの順で積み上げるのが原則です。
- 社内にSRE専任者がいなくてもSLI・SLOは自社で決められますか？
決められます。業務が止まると困る操作の洗い出し、成功の定義の言語化、計測点の特定、委託先への確認という4ステップは会議室で完結する作業であり、SREの専門知識ではなく自社の業務内容についての理解があれば実行できます。まずは実害の大きい操作から着手するのが現実的です。
- 自社で決めたSLOを、そのままSLAの契約数値にしてよいですか？
避けるべきです。SLOは多少下回っても改善で戻せる内部目標ですが、これをそのままSLAにすると、わずかな未達がただちに契約上の問題になり硬直や費用増につながります。SLAにはSLOより緩い数値を置き、その差分をバッファとして持たせます。
- 稼働率さえSLAに書いておけば十分ですか？
不十分です。稼働率は「使えるか」しか測れず、応答が遅い・一部エラーが出る・データが古いといった品質低下は検知できません。業務影響の大きい操作には、レイテンシやエラー率のSLOも組み合わせて設定します。
- ベンダー提示のSLA案が自社に妥当か判断する最初の一歩は何ですか？
提示された稼働率が、どの操作を、どの計測点で、時間ベースとイベントベースのどちらで数えた数値かをベンダーに確認することです。分母に深夜帯や計画メンテナンスが含まれるかも合わせて聞き、測定の定義が分からなければ数値の妥当性は判断できません。
