はじめに ― SLOが“わかりにくい”理由
言葉は知っている、でも作れない
SLO（Service Level Objective）とエラーバジェットという言葉は、SREまわりの文脈に触れている人なら一度は見たことがあるはずです。けれど、「自分たちのプロダクトのSLOを、ゼロから設計してください」と言われると、一気にハードルが上がります。
・どの指標をSLOにすべきか
・どれくらいの数値を目標にすべきか
・ビジネス側とどう合意を取ればいいのか
・エラーバジェットをどう運用に反映させるのか
こうした問いに、すぐに答えられるチームは多くありません。結果として、どこかの事例から「99.9％くらいかな」と数字だけを借りてきて、誰も使わないSLOがドキュメントの片隅に眠る――そんな状況が起きがちです。
信頼性の議論が噛み合わない背景
もうひとつのよくある悩みは、「信頼性の話になると、いつも議論が噛み合わない」というものです。開発側は機能を早く届けたい。運用側は安定を守りたい。プロダクトマネージャーはユーザー体験とビジネスインパクトを気にしている。それぞれの“正義”は理解できるものの、同じテーブルで話すとどうしてもぶつかってしまう。
このとき、SLOとエラーバジェットは「誰の意見が正しいか」ではなく、「何をどこまで許容するか」を決めるための共通言語として機能します。逆に言えば、共通言語がない状態では、信頼性の議論は感情論や印象論に流れやすくなります。
本記事では、Google公式『Site Reliability Engineering』『SRE Workbook』の思想を土台にしながら、「信頼性は関係性である」という0章の視点を重ねて、SLOとエラーバジェットを実務で使える“信頼性の軸”としてどうデザインするかを整理していきます。
ステップ1 ― ユーザー価値から“守るべき体験”を観測する
「何を守りたいか」を数値化する前に
SLO設計で最初にやるべきことは、いきなりパーセンテージを決めることではありません。まずは「誰の、どんな体験を守りたいのか」を言葉で描き出すところから始まります。
たとえば、あるSaaSプロダクトであれば、守るべき体験は次のようなものかもしれません。
- 平日日中、業務時間にログインできない状態が続かないこと
- ダッシュボードの主要画面は、いつ開いても数秒以内に表示されること
- 決済処理は、ユーザーが諦めて離脱しない程度の成功率を維持すること
ここで重要なのは、「サーバーのCPUを守る」ことではなく、「ユーザーの期待している体験を守る」ことを出発点にすることです。信頼性はシステムの属性ではなく、ユーザーとの関係性から生まれます。だからこそ、SLOはユーザー価値から逆算して設計されるべきです。
ユーザージャーニーと失敗モードを洗い出す
守るべき体験をもう少し構造的に理解するために、ユーザージャーニーと失敗モードを洗い出してみます。ユーザーはどんな流れでサービスに触れ、どこで価値を感じ、どこで離脱しそうになるのか。
たとえば、次のような問いをチームで投げかけてみると、議論が前に進みやすくなります。
- ユーザーが「これは使えない」と感じる瞬間はどこか？
- 障害が起きたとき、もっとも信頼を失いやすいのはどのパスか？
- 軽微な遅延なら許容されるが、致命的になる境界線はどこか？
こうして出てきた観測結果は、そのままSLI（Service Level Indicator）候補のリストになります。つまり、SLOづくりの第一歩は「ユーザーとの関係性を観測し、どこに痛みがあるかを知ること」だと言えます。
ステップ2 ― SLIを最小構成で決める
Google公式が示す「4つの典型SLI」
SLOを設計する前に、まずはSLI（サービス水準を表す指標）を決める必要があります。GoogleのSRE本では、典型的なSLIとして次の4つが挙げられています。
- 可用性（Availability）
- レイテンシ（Latency）
- スループットまたはトラフィック（Throughput / Traffic）
- 品質（Quality：エラー率や正答率など）
すべてのサービスでこれらを網羅する必要はありませんが、多くのプロダクトはこのうち1〜2個をベースにSLOを定義できます。大事なのは、SLIは「システム側の都合」ではなく、「ユーザーの体験」を代表する指標であるべきという点です。
たとえばAPIサービスであれば、「2xxで返せたリクエストの割合」は品質SLIになり得ますし、「p95レイテンシ」はレイテンシSLIになります。フロントエンド中心のサービスであれば、「ファーストビューの描画時間」や「エラー画面の表示率」がSLI候補になります。
“全部は要らない”という重要な前提
ここで多くのチームが陥る落とし穴は、「せっかくだから全部測ろう」としてSLIを増やし過ぎてしまうことです。メトリクスは増やそうと思えばいくらでも増やせますが、それらを本気でSLOとして運用するのは現実的ではありません。
Google SREの考え方に沿うなら、最初はサービスごとに1〜2個の主要SLIから始めるのが現実的です。「これが崩れるとユーザーの信頼が一気に下がる」という指標を絞り込むことが重要です。
SLIは少ないほど、チームのフォーカスは明確になります。逆に、10個以上のSLOを一度に運用し始めると、「何が本当に重要なのか」が誰にも分からなくなります。信頼性の軸をつくるためには、まず「何を見ないか」を決める勇気も必要です。
ステップ3 ― SLOを設定する ―「どれくらい守るか」を決める
SLOは願望ではなく“合意”である
SLIが決まったら、次は「どれくらい守るか」をSLOとして定義します。ここで重要なのは、SLOはSREチームが勝手に決める“理想値”ではなく、ステークホルダー間の合意値だということです。
たとえば、「このAPIは可用性99.9％を目指します」という目標は、一見すると良さそうに聞こえます。しかし、その数字を達成するためにインフラコストが3倍になり、開発のスピードが半減するとしたら、それは本当にビジネスにとって最適な選択でしょうか。
SLOは、「ビジネスが許容できるリスク」と「プロダクトが提供すべき信頼性」のバランスから決まります。つまり、SLOを議論する場には、開発、運用だけでなく、プロダクトオーナーやビジネス側のステークホルダーも巻き込む必要があります。
SLOは1つの値ではなく“帯”として扱う
もうひとつのポイントは、SLOを単なる1つの数字としてではなく、「このレンジに収まっていればOK」という“帯”として扱うことです。たとえば、「可用性99.0〜99.5％を目標とする」といったイメージです。
現実の運用では、トラフィックの季節変動やリリース計画、依存システムの状態などによって値は揺れ動きます。常にぴったり99.5％を維持することに意味はありません。それよりも、「この帯から外れたときにどう判断するか」を決めておくことのほうが重要です。
この“帯”の発想は、のちほど紹介するエラーバジェットとも相性が良い考え方です。SLOは、現場にプレッシャーをかけるためのムチではなく、健全な判断を支えるための枠組みであることを忘れてはいけません。
ステップ4 ― エラーバジェットで信頼性の“判断軸”をつくる
なぜエラーバジェットは強力なのか
SLOの話題とセットで語られるのが、エラーバジェットです。たとえば可用性SLOが「99.5％」なら、残りの「0.5％」がその期間に許容されるエラー（ダウンタイムなど）の“予算”になります。これがエラーバジェットです。
エラーバジェットの本質は、「どこまで壊れてもよいか」をあらかじめ合意しておくことで、開発スピードと信頼性のトレードオフを明示的に扱えるようにする点にあります。SLOを守りながらも、バグをゼロにしようとはしない。あえて“壊れてよい範囲”を定義することで、チームは安心してリリースできるようになります。
具体的には、次のような運用ルールが考えられます。
- エラーバジェットが十分に残っているときは、新機能リリースを積極的に行う
- エラーバジェットを使い切った場合は、新規開発を一時停止し、信頼性改善に集中する
これにより、「なんとなく不安だからリリースはやめよう」「上から怒られそうだから止めておこう」といった曖昧な判断ではなく、データにもとづいた議論ができるようになります。
変化（開発）と安定（信頼性）のトレードオフを調停する
エラーバジェットが調停しているのは、「変化」と「安定」のトレードオフです。プロダクトは変化し続けなければ価値を失いますが、変化には常にリスクが伴います。SREが担う役割のひとつは、このトレードオフを技術とデータの両面から支えることです。
ここで忘れてはいけないのは、エラーバジェットもまた関係性の道具だということです。数字そのものが魔法を起こすわけではありません。むしろ、「このSLOとエラーバジェットを前提に、私たちはこういう約束をする」という対話のプロセスこそが、信頼性文化の土台になります。
だからこそ、エラーバジェットを単なるレポートの一項目として眺めるのではなく、意思決定のトリガーとして運用に組み込むことが重要です。
ステップ5 ― 運用と対話に組み込む（ここで文化になる）
SLOレビュー会の設計
SLOとエラーバジェットを定義しただけでは、現場は変わりません。大事なのは、それらを日常の運用と対話にどう組み込むかです。そのひとつの方法が、定期的なSLOレビューです。
たとえば、月次で次のような問いをチームで確認していきます。
- この期間、SLOはどの程度守れたか？
- エラーバジェットの消費は、想定どおりだったか？
- どのリリースやイベントが、信頼性に大きな影響を与えたか？
- ユーザーからの声やサポートへの問い合わせと、SLOの数字は整合しているか？
ここで大切なのは、「SLOを守れなかったから誰かを責める」のではなく、何が起きていたのかを丁寧に観測し、次の一歩を合意する場にすることです。ポストモーテム文化と同様、SLOレビューもまた“仕組み化された対話”として設計する必要があります。
データより“認識のズレ”を扱うことが重要
SLOレビューを続けていくと、数字そのものよりも、むしろ「認識のズレ」が浮かび上がってきます。「このくらいのダウンタイムなら問題ないと思っていた」「いや、あの時間帯はビジネス的に致命的だ」といったズレです。
こうしたズレを表に出し、言葉にしていくことこそが、SLO運用の価値です。信頼性は、結局のところ人と人の合意によって定義されます。だからこそ、SLOとエラーバジェットは、技術指標であると同時に、関係性を調整するための装置なのです。
運用と対話にSLOを組み込めたとき、ようやくSLOは「ドキュメントの数字」から「文化を支える軸」に変わっていきます。
実務でよくあるSLOの間違い ― 組織はどこでつまずくか
「高すぎるSLO」の罠
実務でよくある失敗のひとつが、「高すぎるSLOを設定してしまう」ことです。競合の数字や他社の事例に影響されて、「可用性99.99％くらいは欲しいよね」と雰囲気で決めてしまうケースです。
高いSLOを掲げること自体は悪くありません。しかし、その裏には必ずコストとトレードオフがあります。冗長構成の強化、テスト体制の拡充、リリースプロセスの慎重化など、高いSLOを支えるための投資が必要になります。それをきちんと議論しないまま、数字だけが独り歩きすると、現場は疲弊し、SLOは形骸化していきます。
大切なのは、「このSLOを維持するために、私たちは何を諦めるのか、何に投資するのか」をチームで言語化することです。SLOは、欲張るほど良いものではありません。むしろ、現実的に守れるラインを合意することに意味があるのです。
SLOが“数字の飾り”になってしまう構造
もうひとつの典型的な失敗は、SLOが“レポートの1ページ”になってしまうパターンです。月次レポートの最後にSLO達成状況のグラフが並ぶものの、誰もその数字を意思決定に使っていない、という状態です。
この構造が生まれる背景には、次のような要因があります。
- エラーバジェット消費時の「具体的なアクション」が決まっていない
- ビジネス側がSLOの意味を理解しておらず、関心も持てていない
- 現場の開発プロセス（リリースフローなど）とSLOが紐づいていない
言い換えると、SLOが日々の判断と接続していないのです。この状態から抜け出すには、「SLOを守れなかったとき、何を止めるか」「エラーバジェットが十分に残っているとき、どこまで攻めてよいか」といった具体的なルールを決める必要があります。
数字が意思決定を動かし始めたとき、初めてSLOは「飾り」から「軸」に変わります。
まとめ ― SLOづくりは、技術ではなく“関係性の設計”
合意形成のプロセスそのものが文化になる
ここまで見てきたように、SLOとエラーバジェットは、単なる技術的なフレームではありません。ユーザーの体験を出発点に、関係者同士で「どこまでを守り、どこまでを許容するか」を丁寧に合意していくプロセスそのものが、信頼性文化のコアを形づくります。
信頼性は、数字だけでは完結しません。数字の裏側には、ユーザーとの約束があり、チーム内の合意があり、組織としての価値判断があります。だからこそ、SLOづくりは技術指標の設計であると同時に、関係性の設計でもあります。
次の一歩：SLOレビューと改善サイクルへ
もし今、あなたのチームにSLOがない、あるいは形骸化していると感じているなら、完璧なSLOを目指す必要はありません。まずは「このサービスにとって、本当に守るべき体験は何か」を言葉にするところから始めてみてください。
そこから1〜2個のSLIを選び、現実的なSLOを合意し、エラーバジェットを運用に組み込んでいく。その小さな一歩が、やがて文化としての信頼性を育てていきます。
次の記事では、実際の運用の中でSLOをどうレビューし、どう改善サイクルに落とし込んでいくか――「SLOレビューとエラーバジェット運用の実践」について掘り下げていく予定です。