Managed Services

SLAはもう古い？SLO・XLAで読み解く、これからのサービスレベル管理

目次

SLA（サービスレベル合意）を結んだはずなのに、現場は数値の報告に追われるばかりで品質は一向に上がらない。あるいは契約書の片隅に眠ったまま、誰も見返さない。システム運用の現場では、こうした“形だけのSLA”をしばしば見かけます。本来SLAは、サービス提供者と利用者の認識をそろえ、運用品質を継続的に高めていくための強力な道具です。それが形骸化してしまうのは、SLAを「契約書を作ること」だと捉え、それを支える指標や目標、運用の仕組みとセットで考えていないからにほかなりません。
結論から言えば、価値を生むSLAには三つの条件があります。測れる指標（SLI）に裏打ちされていること、現実的で意味のある目標（SLO）が定められていること、そして定期的に見直されながら運用に組み込まれていることです。逆にこのいずれかが欠けると、SLAは数字だけが独り歩きする“報告のための書類”になりかねません。本記事では、SLAの基本を押さえたうえで、混同されがちなSLO・SLIとの違い、運用にもたらす効果、形骸化させないための設計のポイント、そして「SLAはもう古いのか」という問いへの答えとして、SLOやXLAをめぐる最新の動向までを、順を追って解説していきます。

SLAとは何か

SLAとは「Service Level Agreement」の略で、日本語では「サービスレベル合意」と訳されます。サービス提供者と利用者の間で、提供するサービスの品質や性能の基準をあらかじめ取り決めておく合意のことです。稼働率や障害発生時の対応時間といった項目を数値で約束することで、サービスの信頼性を担保し、利用者の安心と満足につなげることを目的としています。
提供者側にとってもメリットがあります。明確な基準があることで品質管理の拠りどころができ、過剰でも過少でもない、適切な水準のサービス提供が可能になるのです。システム運用において、SLAは契約と品質をつなぐ土台といえる存在です。

SLA・SLO・SLIはどう違うのか

システム運用の世界では近年、SLAと並んで「SLO」「SLI」という言葉がよく使われるようになりました。混同されがちですが、三つは役割の異なる別物です。運用の現場に長く携わってきた立場からいえば、この違いを理解しているかどうかが、SLAを“生きた道具”にできるかどうかの分かれ目になります。
出発点となるのがSLI（Service Level Indicator＝サービスレベル指標）です。これは、サービスの状態を測るための定量的なものさしで、可用性、応答時間、エラー率などが代表例です。測れなければ管理できない、というのが運用の鉄則であり、SLIはすべての土台になります。
次にSLO（Service Level Objective＝サービスレベル目標）は、そのSLIに対して自分たちで定める目標値です。「月間の可用性を99.9％以上に保つ」といったように、社内で達成を目指す基準を指します。
そしてSLAは、このSLOを土台に、利用者や顧客と交わす“約束”です。未達のときの対応や補償といった責任を伴う点が、あくまで社内目標であるSLOとの大きな違いです。実務では、対外的に約束するSLAよりも社内のSLOをやや厳しめに設定しておくのが定石です。こうしておけば、SLOを下回ってもSLAに抵触する前に手を打つ余裕が生まれます。
SLI・SLO・SLAは、測る・目指す・約束するという一本の線でつながっているのです。
可用性の目標を考えるときによく使われるのが、「ナイン（9の数）」という表現です。たとえば可用性99.9％は「スリーナイン」と呼ばれ、ひと月あたりに換算すると約43分の停止までが許容範囲になります。これが99.99％の「フォーナイン」になると、許容される停止はわずか月4分ほどです。数字の上では0.09％の差にすぎませんが、それを満たすために必要な冗長化や監視、体制の負担は大きく跳ね上がります。だからこそ、「とにかく高ければよい」と考えるのではなく、そのサービスにとって本当に必要な水準はどこかを見極めることが、現実的なSLO設計の出発点になります。

SLAを導入すると運用はどう変わるのか

SLAをきちんと設計し、運用に乗せると、現場にはいくつもの目に見える変化が生まれます。
まず、提供するサービスの範囲と水準が明文化されることで、提供者と利用者の認識のズレがなくなります。「どこまでが対応範囲なのか」をめぐる不毛なやり取りが減り、問い合わせやクレームにも一貫した基準で応じられるようになります。提供者側にとっても、範囲が定まることでリソースを適切に配分でき、結果として効率化やコストの最適化につながります。
次に、トラブルへの備えが強くなります。SLAには、障害時の対応時間やエスカレーションの手順があらかじめ盛り込まれます。誰が、どのタイミングで上位の担当者へ引き継ぐのかが決まっているため、いざというときの初動が速くなり、復旧までの時間（MTTR）の短縮が期待できます。対応の基準が文書として共有されていれば、特定の担当者しか動けないという属人化も避けられ、チームのどのメンバーが受けても一定の品質で対応できるようになります。
そして何より、信頼が積み上がっていきます。約束した水準を継続的に満たすという事実こそが、利用者の安心を生み、長期的な関係の土台になります。数値で語れる信頼は、感覚的な「がんばっています」よりも、ずっと説得力があるのです。さらに、SLAの達成状況を定期的にレポートとして共有すれば、運用チームの貢献が目に見える形になり、社内での評価や次の投資判断にもつながっていきます。

SLAに盛り込む主要な項目

では、実際のSLAにはどのような項目を盛り込むのでしょうか。システム運用では、おおむね次の五つが中心になります。

  • 前提条件：対象範囲、提供時間、双方の役割といった土台の取り決め
  • サービス範囲と内容：稼働時間、メンテナンス予定、サポート時間、障害対応などの具体化
  • サービスレベル：可用性や応答時間など、保証する水準の数値
  • 役割と責任：提供者・利用者それぞれが担う義務の明確化
  • 提供未達時の対応と保証：水準を満たせなかった場合の手順と補償

出発点は前提条件です。どのシステムやアプリケーションを対象とするのか、サービスを提供する時間帯や休日の扱いはどうするのか、そして提供者と利用者がそれぞれ何を担うのかといった、土台となる取り決めを最初に固めます。ここが曖昧なままだと、後から必ず認識のズレが表面化します。
そのうえで、サービスの範囲と内容を具体的に記します。稼働時間、メンテナンスの予定、サポートの対応時間、障害時の対応方法などを明示し、解釈の余地をできるだけ残さないようにします。
中心となるのがサービスレベルです。可用性や応答時間をどの水準で保証するのかを、現実的かつ達成可能な数値で定めます。高すぎれば未達で信頼を損ない、低すぎれば利用者の不満を招くため、双方が納得できるバランスが求められます。ここで定める数値は、後述するSLO・SLIと地続きであることを意識すると、より運用に根ざしたものになります。加えて、提供者と利用者それぞれの役割と責任を明確にし、最後に、約束した水準を満たせなかったときの対応と保証を定めておきます。未達時の手順や補償まで決めておくことが、かえって提供者自身の品質改善への動機づけにもなります。

形骸化させないSLA設計のポイント

冒頭で触れたとおり、SLAは作ること自体が目的ではありません。形だけで終わらせないために、いくつか押さえておきたい勘所があります。
ひとつは、項目を欲張らないことです。あらゆる可能性を網羅しようとすると契約は複雑になり、誰も全体を把握できなくなります。自社にとって本当に重要な指標を絞り込み、優先順位をつけて取り決めるほうが、合意形成も運用もずっとスムーズになります。
もうひとつは、達成できる現実的な目標を置くことです。ここで役立つのが、SRE（サイトリライアビリティエンジニアリング）で広く使われる「エラーバジェット」という考え方です。たとえば可用性の目標を99.9％と定めるなら、裏返せば0.1％ぶんの“許容される不具合”が存在します。この余白を、機能改修やリリースといった攻めの活動にあてる予算として捉えるのです。100％の完璧を目指して現場を疲弊させるのではなく、許容できる範囲をあらかじめ決めて賢く使う。これが、持続可能な運用の鍵になります。予算がまだ残っているうちは新しいリリースに積極的に挑み、使い切ってしまったら、いったん変更を止めて安定化に注力する。こうして開発と運用の判断を同じ物差しで下せるようになる点も、この考え方の大きな利点です。
そして、SLAは一度決めたら終わりではありません。ビジネス環境も技術も変わり続ける以上、定期的に実績を振り返り、目標や項目を見直していく必要があります。測定（SLI）にもとづいて目標（SLO）と合意（SLA）を更新し続けるサイクルこそが、SLAを生きた道具に保つのです。

変わったのは、SLAの“立ち位置”

ここまで読んで、「最新の現場では、SLAはもう時代遅れなのではないか」と感じた方もいるかもしれません。結論からいえば、SLAが廃れたわけではなく、その役割が再定義され、上下に新しい層が加わった、というのが実情です。
まず、SLAは契約や法務の層として、むしろ重みを増しています。クラウドやSaaSの事業者は今もSLAを公開していますし、欧州では2025年に全面適用された金融規制（DORA）が、金融機関と外部の技術提供者との契約に、具体的な可用性・性能のSLAを盛り込むよう求めるなど、規制の側から要求される場面さえ広がっています。ダウンタイムが一時間あたり数十万ドル規模の損失につながる事業も珍しくない以上、約束に責任を伴わせるSLAの価値は、むしろ高まっているのです。ITサービスマネジメントの標準であるITILでも、「サービスレベル管理」は主要な実践として位置づけられ、SLAの締結と継続的な見直しが品質を保つ活動とされています。
その一方で、日々の運用の主役は、前述したSLOとエラーバジェットへと移ってきました。対外的な約束であるSLAを守るために、内部ではより厳しいSLOを掲げて測定と改善を回す。この分業が、いまの現場のスタンダードになっています。

XLA（体験レベル合意）とは──どう測り、数値化するのか

そして近年、もうひとつの観点として「XLA（Experience Level Agreement＝体験レベル合意）」が注目を集めています。これは、稼働率や応答時間といった技術指標ではなく、利用者がサービスを実際にどう感じているか、つまり体験そのものを測ろうとする考え方です。背景にあるのが「ウォーターメロン問題」です。ダッシュボードの上ではすべて緑（SLA達成）なのに、割ってみれば中身は赤（利用者は不満だらけ）。スイカのようなその状態を指す言葉で、XLAは、こうした“数字は満たしているのに満足されていない”というSLAの盲点を埋めるために生まれました。
とはいえ、「体験」という主観をどう測り、数値化するのかが、最初に浮かぶ疑問でしょう。XLAでは、性質の異なる三種類のデータを組み合わせてスコア化するのが基本です。ひとつは、利用者の主観をとらえる体験データです。操作や問い合わせの直後に「今の対応はいかがでしたか」と尋ねる短いアンケート（パルスサーベイ）で満足度を点数化したり、問い合わせの文章やチャットの内容をAIで感情分析したりして、感じ方を数値へと変換します。
二つ目は、SLAやKPIといった従来の運用データで、応答時間や解決時間などの客観的な事実を、体験の背景情報として添えます。三つ目は技術データです。DEX（デジタル従業員体験）と呼ばれるツールが、利用者の端末側からアプリの起動時間やクラッシュ、体感のレスポンスといったテレメトリを集めます。
これらを突き合わせると、「稼働率は99.9％を満たしているのに、ログイン画面の体感が遅く、満足度スコアが低い」といった、SLAだけでは見えなかった実態が浮かび上がります。さらに、利用者が体感した“奪われた時間”や、やりたい作業を滞りなく完了できたか、同じトラブルが繰り返し起きた回数といった指標を加えれば、体験はより具体的に可視化できます。あとは、この体験スコアに目標値を定め、SLAやSLOと同じように定期的に振り返って改善を回していくわけです。客観的なテレメトリと主観的な手ごたえを併せて見ることで、ある技術的な不具合が本当に人の仕事を妨げたのかどうかまで判断できる点が、XLAの大きな強みです。
ただし、XLAはSLAを置き換えるものではありません。多くの現場では、既存のSLAに体験の指標を足すという形で両者を併用しています。日本でもITサービスマネジメントの領域を中心に紹介が進んでいますが、普及そのものは欧米が先行している段階です。
整理すると、SLAは契約という土台の層として今も健在で、その上にSLO・エラーバジェットという運用の操縦層、そしてXLAという体験の評価層が積み重なりつつある、というのが現在の姿です。完璧な代替物が現れてSLAが消えた、という事実はありません。だからこそ、SLAを古い枠組みとして手放すのではなく、測れる指標に裏打ちされた土台として整え、その上に新しい層をどう乗せていくかを考えることが、これからの運用設計の勘所になります。

まとめ

SLAとは、サービスの品質や性能の基準を提供者と利用者の間で取り決める、システム運用の土台となる合意です。ただし、その価値は契約書を作った瞬間に生まれるわけではありません。測れる指標であるSLIを土台に、現実的な目標であるSLOを定め、それを約束としてのSLAへとつなげ、運用のなかで測り、見直し続ける。この一連のサイクルがあってはじめて、SLAは信頼を生む道具になります。
項目を欲張らず、達成できる目標を置き、エラーバジェットのように許容範囲を賢く使い、そして定期的に見直す。これらを押さえれば、SLAは「守らされるノルマ」ではなく、サービスを継続的に良くしていくための羅針盤になります。SLOやXLAといった新しい層が広がるなかでも、その土台となるのは、測れる指標に裏打ちされたSLAであることに変わりはありません。システム運用の信頼性を一段引き上げる第一歩として、まずは手元のSLAが、本当に測れる指標に裏打ちされているか、改めて見直してみてはいかがでしょうか。