その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