「SREは信頼性、PEは生産性」に引っかかったので、"信頼性"を考え直してみる
はじめに
3-shakeでSREをやっている @hymaaa_k と申します。
最近、SREとPlatform Engineering（PE）の違いとして、「SREの主目的は信頼性」「PEの主目的は認知負荷の削減と開発生産性の向上」と切り分ける説明をよく見かけます。
特に引っかかったのは、この切り分けの中で「信頼性」という言葉が、いつの間にか「稼働率（Uptime）」とほぼ同義で扱われがちなことです。例えば「99.99%や99.999%の信頼性を確保するために〜」という話をよく目にします。
果たして私たちSREが行っている「Site Reliability」とは、一体どういったものなのでしょうか。
「信頼性」と「可用性」をまず分ける
可用性は重要ですが、可用性は信頼性そのものではありません。
- 可用性（Availability）： アクセスできる／稼働している度合い。いわゆる「稼働率（Uptime）」はその代表的な指標（例：リクエストの99.99%が正常応答を返す、など）
- サイト信頼性（Site Reliability）： その事業にとっての価値が、期待どおり継続して提供されている状態。実務上は、それを測る指標群を通じて扱われる。
つまり、稼働率は可用性の一指標に過ぎず、その可用性もまた「サイト信頼性」を構成する要素のひとつに過ぎません。もちろん、可用性が信頼性の最重要構成要素となるドメインが多いのは確かです。
極端な話、可用性が高くても「価値」が毀損されていれば信頼性は低い。逆に、夜間バッチ基盤が日中止まっていても締め処理さえ確実に完了すれば誰も困らないように、部分的な停止があっても価値提供が守られていれば「信頼できる」と言えるケースもあります。
この切り分けをしないまま無意識に「SREの主目的は信頼性である。だから可用性のために行動していきます」と発信して、SLO＝稼働率、SRE＝障害対応と運用改善、という理解が昨今のSREとPEを分ける要素になってしまっているのではないかと思っています。
ビジネスによっては「可用性」が最優先ではない
「SREの主目的は信頼性である」——言葉としては間違っていません。
SREはGoogleで生まれました。ダウンタイムが秒単位で巨額の損失に直結する彼らのビジネスでは、可用性がそのまま価値に直結しやすかったのだと思います。だからSLOを定め、エラーバジェットで稼働率を厳格に管理することが強い解になります。
しかし、これはあくまで「Googleの事業ドメインに最適化された実装」であって、普遍的な信頼性ではありません。
ビジネスドメインが違えば、価値の形も、価値を測る指標も、信頼性の意味も変わります。
会計・給与・人事SaaSにおいて顧客が真に求めているのは「サーバーの稼働率」ではなく、「月次締めや給与計算日に処理が確実に完了すること（締め日の信頼性）」かもしれません。システムエラーで25日に給与が振り込まれないなんてことがあれば、次の契約更新してくれませんよね？
パスワードマネージャーのような機密情報を扱うサービスであれば、顧客が求めているのは秘密が守られることであり、可用性はその次です。最悪パスワードは再設定できますから、知らず知らずのうちに流出してたなんてことがあれば即解約待ったなしです。
このように考えると、SRE本の文脈が「可用性こそが信頼性の核」と受け取られがちですが、その前提がそこまでクリティカルではないビジネスは少なくありません。
実際、最近のSREコミュニティでも、こうした方向の議論が増えてきています。
SRE NEXT 2025では、プレイド社の土谷さんがKARTE Message（月間10億通超の配信基盤）のSLO実践を発表していました。そこでは「エンドユーザーにメッセージが届いたか」「配信が遅延していないか」をビジネス向けSLOに据えています。稼働率ではなく、事業にとっての価値を直接測りに行っているのがよくわかります。
SREは「可用性」だけの役割ではない
ここでSREの実務に目を向けてみます。SREの仕事の多くは、価値提供が壊れにくい状態を作ることです。そのためにトイルを削減し、自動化・システム化によって仕組みに置き換えていくことです。
わかりやすいのはCI/CDです。デプロイを自動化すれば、手作業によるミスが減る。同時に、細かい単位での高速なリリースが可能になる。信頼性と生産性が同じ施策から同時に出てくるわけです。IaCもo11yも構造は同じで、Git管理やエラー検知といった信頼性の取り組みが、そのまま開発者の速度や判断精度を底上げする。
SREの実務において、信頼性と生産性はそもそも分離できるものではありません。
開発速度もまた「信頼性」である
信頼性と生産性が不可分なら、開発速度（変更を小さく、安全に、素早く出せること）そのものを信頼性の構成要素として捉えられるビジネスもあるはずです。
もちろん、なんでも「信頼性」と呼んでしまえば言葉は無意味になります。境界線は、その欠如が「価値の毀損」としてユーザから観測されるかどうかです。
たとえば、法改正や外部API仕様変更への追従が遅れると、サービスは「落ちていないのに使えない」状態になります。あるいは、不正対策や脆弱性対応を迅速に適用できないことが、長期的な信頼の毀損につながります。
この基準で見れば、デリバリのリードタイム短縮やリリース頻度の向上は「生産性の話」に見えて、価値の継続提供（＝信頼性）を守るための投資でもあります。
クラウドネイティブ会議2026では、TopotalのVTRyoさんが「そのSLO 99.9%、本当に必要ですか？」と題して登壇していました。印象的なのは、CSチームへのヒアリングで「障害よりも機能不足による失注・解約のほうが数は多い」と返ってきたエピソードです。価値毀損の最大要因が機能不足なら、過剰な稼働率の維持をやめて機能開発に投資するのは、信頼性を捨てる判断ではなくその事業にとっての信頼性を構成する要素の優先度を組み替える判断であると言えますよね。
SREとは、結局なにをする人たちなのか
結局のところSREがやっているのは、「自分たちの事業にとって"信頼できる状態"ってなんだっけ？」を定義して、それを仕組みで維持し続けることだと考えています。
Googleにとっての価値は、いつでも検索を通じて広告を配信できることでした。だからこそ、o11yやエラーバジェットを整備して可用性を磨き込むことが、強い解になりました。
ただ、私たちの事業はGoogleではありません。可用性を磨き込むことが最優先の事業もあれば、認知負荷を下げることや開発速度を上げることのほうが信頼性に効く事業もあります。
ここまで見てきたように、認知負荷の削減や開発生産性の向上は、事業ドメインによっては信頼性の構成要素になりえます。だとすれば、それを実現する手段がプラットフォームというプロダクトであっても、SLOや自動化といった運用プラクティスであっても、目指すものは「事業の価値を届け続ける」ことで変わりません。
自分の考えでは、SREとPEの違いは目的ではなくアプローチにあります。SREは運用のプラクティスでサービスの価値を守る。PEはプラットフォームというプロダクトを通してサービスの価値を守る。
だから、SREかPEかという二択で語ること自体があまり意味を持ちません。問うべきは「この事業の価値を守るには、どの道が一番効くか」だと思っています。