そのSLO 99.9%、本当に必要ですか？〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs

そのSLO 99.9%、本当に必要ですか？ ~ 優先度付きSLOによる責任共有の設計思想 ~ Topotal, Inc - SRE
as a Service / VTRyo クラウドネイティブ会議2026 | VTRyo （ @VTRyo ） 1

自己紹介 VTRyo／ 2015年インフラエンジニアとしてキャリアスタート 2018年頃から本格的にSREとして活動スタートアップ・メガベンチャーで SRE を経験 └ ㈱マツリカ／㈱マネーフォワードなど
2025年9月より株式会社Topotalにて SRE as a Serviceに従事。 Cross-Company Embedded SREとしてお客様を支援中クラウドネイティブ会議2026 | VTRyo 2

登壇歴 SRE NEXT 2022 ONLINE 「一人から始めるプロダクトSRE」 SRE NEXT 2025 「60以上のプロダクトを持つ組織における
　開発者体験向上への取り組み」 − チームAPIとBackstageで構築する組織の可視化基盤 − SRE Kaigi 2025 「一人から始めたSREチーム3年の歩み」 − 求められるスキルの変化とチームのあり方 − 資料一覧: speakerdeck.com/vtryo クラウドネイティブ会議2026 | VTRyo 3

もう一つの顔カレー屋 SRE業務の傍ら、間借りでカレー屋を展開中スリランカ現地のシェフから学ぶ。今年も訪問予定間借り界隈に特化したオーダーシステムを個人開発中
ビアジャッジビール審査資格を保有書籍出版『ITエンジニアのための偶然から始めるキャリアプラン』クラウドネイティブ会議2026 | VTRyo 4

そういえば…… 本スライドはClaudeによるHTMLで出力されていますこれまでは Markdown （Marp）でスライド作成していたが廃止トークンをドカ食いしたリッチなスライドをお楽しみくださいこのスライドはこのあとインターネットにアップロードします。写真は撮らなくても心配なし！ Xでの実況大歓迎!!
あとで登壇者は全部読みます → ※ HTML出力指示はわざわざSkill化しなくていいってばっちゃが言ってたクラウドネイティブ会議2026 | VTRyo 5

今日持ち帰れること SREのリソース問題にどう立ち向かうか SRE と Dev がどう責任共有するか？「精度の高いSLO」 ──
End-to-end SLO が何をもたらすか Enabling 特化による「本番離れ」を防ぐ考え方 → SLOの使い方を再考するきっかけを持ち帰っていただきたいクラウドネイティブ会議2026 | VTRyo 6

前提 SREのリソース問題 SREは何に時間を使うのか 7

本セッションが想定する組織 SRE のリソース問題が顕在化しやすい組織像条件詳細規模中規模以上、複数サービスを抱えている。 SRE チーム
< サービス数構造独立した SRE チームと Devチームが存在する文化 Dev と SRE が、必要に応じて目標について対話できる関係性成熟度 SLI / SLO の概念が運用できる土壌 ※ シングルプロダクト・小規模・SRE 未導入組織は、別のパターンが適する。クラウドネイティブ会議2026 | VTRyo 8

リソースが足りない状態では、「Dev が自律的に信頼性を高められる状態」を目指す Devチームが、自分たちのサービスの信頼性の向上に責任を持つ。ある程度の規模になると、個人的にはこれが合理的だと思っています。この理想に向かうなら、
SRE は支援（Enabling）に回るでしょう。 → ※ Google SRE Workbook の Team Lifecycles でも、 Horizontal SRE という名前で「少人数の SRE チームが複数のチームに助言を提供する」モデルが書かれている。「自分たちを支援者（Enabler）と捉える」とある参考: Google SRE Workbook — Team Lifecycles クラウドネイティブ会議2026 | VTRyo 9

リソース不足を補うために、これまで何をしてきたか？自律運用への橋渡し可能な限りToilを潰す。非効率な部分や、いち早く対応すべきことは実施体系化したら、 SRE がDevへ委譲する業務内容をドキュメント化ペアワークを通じて委譲する
チケット方式にして、 Dev にどうしてもできないタスクのみ受け取るクラウドネイティブ会議2026 | VTRyo 10

これを突き詰めていくと…… SRE の仕事は何が増え、何が変わるのか SRE は支援業務が増える。例: ドキュメント作成、情報ポータルの整備 Dev
からの依頼で時間がいっぱいになってくる Dev への委譲が進みSREチームが独立タスクを実行するにつれて、サービスで何が起きているか分からなくなってくる可能性大（SREは複数のサービスを見ている前提） Horizontal SRE のリスクである「実際には何の業務も行わず、新たなゲート組織として認識されている」に似ている個人的に「自分はサービスに直接価値を生んだだろうか？」と葛藤が生まれたクラウドネイティブ会議2026 | VTRyo 11

「Devチーム自身が信頼性を高める活動ができる」を目指しつつ、これからのSREにできることは？クラウドネイティブ会議2026 | VTRyo 12

SREはサービスから離れすぎない。しかしDevも本番環境について責任を持つ方法を考えるすべてのタスクをDevに委譲できることが理想だが、現実は難しい → 現代のDevは機能開発だけではなく、 QAといった周辺ロールも持っているケースがある。急激に実施すると認知負荷が高すぎる。言われた側が、
「丸投げしてないか？」と感じるリスクもあるので慎重に。クラウドネイティブ会議2026 | VTRyo 13

そこで参考したいこと Google が提唱する Product-Focused Reliability for SRE 個々のサービスではなく、プロダクトの重要機能とユーザーの成果を信頼性の単位に据える考え方。出典:
Google SRE — Product-Focused Reliability for SRE クラウドネイティブ会議2026 | VTRyo 14

D E E P D I V E Product-Focused Reliability
for SRE なぜこの考え方なのか、どう使うか 15

PFR の中核 — 信頼性の「単位」を捉え直す PFR は、信頼性の対象を「サービス」
から「プロダクトの重要機能」へ移すアプローチ。 SLO・計測・改善の基準が、すべてユーザー成果に紐づいて定義される。観点従来のSLO （サービス中心） PFRのSLO （プロダクト中心）信頼性の単位個々のサービス（API / DB / cluster）ユーザーが実行する重要機能 SLO の基準サービス可用性・レイテンシプロダクト KPI とユーザー成果 → PFR を一言でいえば、信頼性を測る単位そのものを「サービス」から「プロダクト」へ移す考え方。クラウドネイティブ会議2026 | VTRyo 16

「サービス中心」と「プロダクト中心」サービス中心 SLO 焦点: 個々のサービス・インフラの安定稼働ステークホルダー: SRE ＋
Devチームメトリクス: 技術指標（可用性・レイテンシ） SLO: サービス単位 (例: API 応答時間 99.9%) 評価: システム安定性・開発速度プロダクト中心 SLO 焦点: プロダクト全体の重要機能・ユーザー体験ステークホルダー: PdM・UX デザイナー・Eng・サポート等メトリクス: ビジネス指標（機能成功率・KPI） SLO: ユーザー目標の文脈 (例: メール検索成功率 99%) 評価: ユーザー満足度・ビジネス成果クラウドネイティブ会議2026 | VTRyo 17

提案: プロダクト中心 SLO のフロー「プロダクト中心で考えた時、私たちの議論の起点はシステム（サービス）ではなく、プロダクトそのものになるはず」 ←
Service SLO にはない領域（プロダクト中心固有） PdM ・ Designer ・ Dev ・ CS Product Requirements Business Goals R E L I A B I L I TY CO N T R O L Define Metrics SLO Error Budget Monitoring Change Management Improvement Activities Feedback → ビジネス観点からメトリクスを定義し、それがSLOになるイメージクラウドネイティブ会議2026 | VTRyo 18

提案: SLOを問い直すサービス中心の問い「決済 API はどれくらい信頼性が高く、高速であるべきか？」プロダクト中心の問い「ユーザーが商品を購入する際に、
どれくらいのエラーを許容できるか、どれくらいの速さで購入完了すべきか？」議論の起点が、システムからユーザー体験へ。 → この問いはPdMやビジネスメンバーとも議論するとよいクラウドネイティブ会議2026 | VTRyo 19

SLO はいくつかの種類にわけられる SERVICE SLO サーバー側の技術メトリクスコスト: 低 / カバレッジ: 狭い
用途: 日常監視 CLIENT-SIDE SLO ブラウザ・アプリ側の計装でユーザー実体験を計測コスト: 中 / カバレッジ: 広い用途: 全体俯瞰 END-TO-END SLO CUJ 全体をエンドツーエンドで測るコスト: 非常に高い / カバレッジ: 深い用途: 重要 CUJ 全部を同じ精度である必要はない。重要な所に End-to-end SLOを採用する。 → Service SLOが悪いのではなく、 SLO実装コストや目的が異なると考える参考: Google SRE — Product-Focused Reliability for SRE クラウドネイティブ会議2026 | VTRyo 20

提案 SRE が優先度をつけるために、さらに本番から離れないために、重要な SLO に責任を持つ "SREは本番環境にとってもっとも重要な機能を優先する" 21

提案：責任を SLO で分ける得意領域で責務を分けたり、 Devチームに無理にタスクを委譲すると、 SREは本番から離れ、分断の歴史を繰り返してしまう。ならば、 SLOで分けることで、本番に責任を持ち続けつつお互いの目的
（本番環境の信頼性）を達成するという発想よくある分け方（層）アプリケーション ← Dev インフラ ← SRE 境界が技術スタックになりがち。 ── かつての Dev/Ops 分業と同じ構図に近寄る。提案する分け方（機能 = SLO）この機能の SLO ← Devチームこの機能の SLO ← SRE 境界がユーザー価値にある。 → End-to-end SLO （高コスト・深いカバレッジ）を SRE が引き受ける。クラウドネイティブ会議2026 | VTRyo 22

SLOを協働の境界線として使う頭で分かっていても、気づいたら層（インフラ/アプリ）で責務が分かれはじめてることはないか？従来: 横の境界（層） Devが得意な領域 Dev
の責任境界 SREが得意な領域 SRE の責任技術スタックで分ける → 境界を 90°回転提案: 縦の境界（機能 = SLO）機能 A SLO SRE 機能 B SLO Dev 機能 C SLO SRE ユーザー価値（機能）で分ける → SREもDevも、同じように本番環境について考えられるクラウドネイティブ会議2026 | VTRyo 23

SLOを協働の境界線として使うまた、 Dev が SRE の業務を無理して取り込むと、運用に対する知見が足りないこともあり得えるだからこそSLOを協働の境界線にする健全な分担（SLO 境界）
SRE End-to-end SLO Dev Service SLO Client-side SLO SREは重要な機能のみに集中 / DevはシンプルなSLOにのみ注力 ⚠ 無理に吸収すると DevがOps作業を吸収 SRE 本番環境から乖離 Dev 機能開発＋ Service / Client-side SLO ＋ End-to-end SLO ⚠ 運用知見不足 / 機能優先 Dev に過負荷、運用品質が下がる可能性 → 双方向にバランスが取れるクラウドネイティブ会議2026 | VTRyo 24

End-to-end SLO は SRE が引き受ける SLO 種別 × 責任主体のマッピングの例 SERVICE
SLO 技術メトリクス・低コスト・狭い Devチーム CLIENT-SIDE SLO ユーザー実体験・中コスト・広い Devチーム END-TO-END SLO CUJ起点・高コスト・深いカバレッジ ★ SRE 最も重要な機能の信頼性を、 SRE が引き受ける。 → Devは比較的シンプルで負荷が少ないSLOを担当できるクラウドネイティブ会議2026 | VTRyo 25

SLO で責務範囲を分けると、何が変わるか SRE が本番に責任を持ち続けながら、 Dev と共通目的で動ける SRE が本番から離れずに済む
（End-to-end SLO を引き受けるため）互いの成長機会を奪わない（技術スタックに依存しないため）相互理解の機会が生まれる同じ目的を目指せる（ユーザー価値という共有指標） → Dev が Service SLO を押し付けられる／SRE が Enabling 専任に固定される、といった関係を回避できるクラウドネイティブ会議2026 | VTRyo 26

実装では、 SRE が担う End-to-end SLO はどう作るか？ 27

End-to-end SLO の作り方 CUJ 起点で、ユーザー目的をメトリクスに落とすユーザー目的を言語化する（Critical User Journey）
目的を達成するためのステップに分解する各ステップを測定可能なメトリクス（SLI）に落とす └ サービス計測に加え、 Synthetic / RUM も SLI に含めてサービス間ギャップを埋める SLI を集約して End-to-end SLO として定義する → Google 公式も End-to-end SLO は high cost と明言。最重要な CUJ にだけ限定することが前提。参考: Google SRE — Product-Focused Reliability for SRE クラウドネイティブ会議2026 | VTRyo 28

自販機で考える CUJ 機能ごとに「ユーザーの期待」を分解し、 SLI に落とすユーザーの期待押したボタンの商品が出てくる／
正しいお釣りが返る ① ボタンを押す商品選択 UI ② お金を入れる投入口・受付 ③ 品物が出る商品排出機構 ④ お釣りが返る釣銭返却例として ② を掘り下げてみましょう「お金を入れる」が成立するための要件自販機の場合 ▸ 投入口が機能している ▸ 投入口が塞がっていない ▸ 位置が高すぎず低すぎない Web サービスに置き換えると ▸ 該当ページにアクセスできる ▸ レスポンスタイムが許容範囲 ▸ 入力 UI が正しく動作する → これらが SLI の候補になる → 機能ステップを順に分解し、「成立要件」を SLI に落としていく。クラウドネイティブ会議2026 | VTRyo 29

CUJ の探し方 — 3 つの問い順に明確にしていくと、 SLI / SLO の対象が見えてくる
# 問い意図自販機での回答 ① このユーザーは誰かペルソナを明確にする商品を買いたい購買者 ② そのユーザーにとって何が重要か「成功」の定義を言語化する押したボタンの商品が出る／正しいお釣りが返る ③ 目的を果たすのにどの手続きが必要か機能ステップに分解し SLI を当てるボタン押下 → 入金 → 排出 → 釣銭返却 → ① 〜 ③ をテンプレ化すれば、新規 CUJ も同じ手順で立ち上げられる。クラウドネイティブ会議2026 | VTRyo 30

自販機の CUJ を Web サービスに当てはめる各エンドポイントの SLI を集約し、 End-to-end SLO
として束ねる自販機の機能 Web サービスでの相当 SLI （エンドポイント単位） ① ボタンを押す商品検索・選択 UI 表示成功率 / P95 応答時間 ② お金を入れるカート → 決済入力入力 API 成功率 / レイテンシ ③ 商品が排出される注文確定・配送開始確定 API 成功率 / 通知到達率 ④ お釣りが返る注文完了通知 / 完了画面通知到達率 / 表示成功率 End-to-end SLO ＝「ユーザーが商品を買って受け取る」一連の流れが成功する率（各 SLI を集約した値） → 個別 SLI の積み上げで終わらせず、 End-to-end SLO 一本に束ねるのが PFR の核。クラウドネイティブ会議2026 | VTRyo 31

もし「サービス SLO」で運用したら各サービスに個別の SLO を割り当てた場合、 End-to-end ではどう見えるかサービス
（Web 相当）個別 SLO （典型例）狙い商品検索・選択 UI 99.5% / P95 800ms UI 表示性能を維持カート → 決済入力 99.9% / P95 500ms 決済 API の可用性注文確定・配送開始 99.95% / P99 1s 確定処理の堅牢性注文完了通知 / 完了画面 99.0% / P95 2s UI フィードバックの確実性 End-to-end SLO で測ると　0.995 × 0.999 × 0.9995 × 0.990 ≈ 約 98.36% に劣化。 Service SLO は個別ごとに緑のため検知できない ── End-to-end SLO を持って初めて見える。 → サービス SLO の積み上げだけでは、ユーザーの「商品を買って受け取る」目的は守れない。これが PFR が End-to-end SLO を別途持つ理由。クラウドネイティブ会議2026 | VTRyo 32

回収 End-to-end SLO は、何をもたらすか責任共有の答え 33

結論：Service SLO と End-to-end SLO で責任を共有・分担する SLO で責任を切り分ければ、 SRE
も Dev も重要なことに時間を集中できる層 SLO 目標評価軸責任主体 End-to-end SLO 「商品を買って受け取る」 E2E 99% / 30日ユーザー目的の達成 PdM × SRE Service SLO ① 商品検索・選択 UI 99.5% / P95 800ms API 可用性・性能 Dev Service SLO ② カート → 決済入力 99.9% / P95 500ms API 可用性・性能 Dev Service SLO ③ 注文確定 99.95% / P99 1s API 可用性・性能 Dev → 同じ計測値でも、 Service SLO は 30日窓のチーム視点、 End-to-end SLO は E2E 集約のプロダクト視点で別の意味を持つ。クラウドネイティブ会議2026 | VTRyo 34

問いそのSLO 99.9% は、本当に必要か SLO の目標値は、本当にそれで合っているか 35

CS チームへのヒアリング SLO を再考する過程で、ある問いを投げかけた私（SRE）最近 SRE はよくサービスの障害を検知している。
それによって、ユーザーから何か意見があったり、解約はあった？ CS 実は、機能不足による失注や解約のほうが数は多いです。 → 私は SLO を、機能開発と運用のバランスを取るための意思決定に使えていなかった。クラウドネイティブ会議2026 | VTRyo 36

「99.9% は本当に必要か」 ── きっかけの問い ① 私の直感もしかしたら、 99.9% はこんなに高くなくていいかもしれない。 ②
現実でも、下げて本当に影響がないかは分からない。技術側だけでは判断しきれない。 ③ 打ち手だからこそ、ビジネスチームと話して SLO の精度を上げる。 → この問いは「答えるため」じゃない。対話を起動するためのきっかけとして効く。クラウドネイティブ会議2026 | VTRyo 37

End-to-end SLO と 99.9% の再考は、リソース最適化に寄与する 99.9% を再考すれば、戦略と時間の使い方が変わる過剰運用から離れられる
→ 信頼性維持に消費していた時間が浮く浮いた時間で機能開発・ユーザー価値の創出に投資できる → あなたの組織なら、浮いた時間を何に投資するか？クラウドネイティブ会議2026 | VTRyo 38

今日のまとめ 4 つの持ち帰りリソース問題への答え：SLO で責任を分担する責任共有の具体形：Service SLO （Dev）
+ End-to-end SLO （SRE） End-to-end SLO は CUJ 単位で最重要なものに限定する「99.9% は本当に必要か」はビジネスとの対話を起動するきっかけ → SLO は、リソース最適化と責任共有の道具クラウドネイティブ会議2026 | VTRyo 39

We are hiring!! CEO 兼 SRE といつでもカジュアル面談 ← 左の
QR コードで SRE スタイル診断してみてね！クラウドネイティブ会議2026 | VTRyo 40

ご清聴ありがとうございましたそのSLO 99.9%、本当に必要ですか？ ~ 優先度付きSLOによる責任共有の設計思想 ~ Topotal, Inc -
SRE as a Service / VTRyo 41

そのSLO 99.9%、本当に必要ですか？ 〜優先度付きSLOによる責任共有の設計思想〜 / ...

そのSLO 99.9%、本当に必要ですか？ 〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs

More Decks by VTRyo

Other Decks in Technology

Featured

Transcript

そのSLO 99.9%、本当に必要ですか？〜優先度付きSLOによる責任共有の設計思想〜 / ...

そのSLO 99.9%、本当に必要ですか？〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs