まず初めに、運営・スタッフのみなさんなど、開催のために尽力いただいた方々に深い感謝を。本当にありがとうございます。また、当日登壇された方々、参加された方々、スポンサーのみなさんもありがとうございました。最高の二日間でした。
今回私は、SREについて特に事前知識のないAndroidアプリのエンジニアと共同登壇をする形で登壇させていただきました。
https://sre-next.dev/2026/schedule/#slot105
資料はこちらです:
今回スマホアプリのエンジニアの方を半ば無理やり(?)誘わせていただいて、セッションを回ったり、色々な人と会話をしたり、共同登壇といいつつ9割以上のトークをお任せしたりしました。こんな私の無茶振りに付き合ってくださった森さんに本当に感謝します！今回のSRE NEXTのテーマがInclusiveだったのも、ちょうどタイミングが良かったです。
まず、今回そういうSRE界隈に馴染みがない方に、その人の立場からの信頼性を語ってもらうという挑戦をしたモチベーションについて説明させてください。
私は以前から、SREに関する議論に少し違和感を持っていました。
SREは、特定のロールだけが行うものではなく、サービス開発に関わる人たちが取り入れるべきプラクティスであるはずです。
一方で、SREコミュニティでは、SREというロールの人たちが「SREは何をするべきか」「SREの責務をどこまでにするべきか」と議論している場面が多いように感じます。(もちろんカンファレンスの招待セッションや毎回のテーマなどをみると、それの解決のための尽力をずっと続けているのが感じられます)
もちろん、SREという専門ロールが存在すること自体には問題ありません。専門性を持つ人たちが集まり、知見を共有することにも大きな価値があります。
ただ、SREのプラクティスまでSREというロールの中に閉じてしまうと、信頼性は「SREチームが担当するもの」「SREへ依頼するもの」になってしまいます。
そこで今回は、あえてSREを知らないAndroidエンジニアと一緒に参加することで、SREの議論に含まれている暗黙的な前提を見つけられるのではないかと考えました。
実際に参加してみると、セッションの内容だけでなく、その後に二人で話したことや、登壇者へ質問したことも含めて、SREについていくつか新しい発見がありました。
この記事では、それらを整理してみます。
なお、各セッションの内容をそのまま要約するものではありません。セッションで提示された論点を起点として、私が考えたことを書いた参加レポートです。(取り止めもなく書き連ねた結果、長文になってしまいました)
SREの定義では、役割と技術レイヤーが混ざっていないか
色々なセッションを回ったり会話したあとに、「なんでSREがインフラやるってセッションが多いんですか？」という疑問を持たれていました。
SREについて説明するときに、よく「運用をソフトウェアエンジニアに任せた結果がSREである」という話があります。
これは、運用上の問題を人手で処理し続けるのではなく、ソフトウェアエンジニアリングによって解決する、という意味だと理解しています。
ただ、実際の議論を聞いていると、いつの間にか次のような話になっていることがあります。
インフラストラクチャを担当するソフトウェアエンジニアがSREである。
ここでは、開発の時系列上の役割と、技術レイヤーの話が混ざっているのではないかと思いました。
少なくとも、次の三つは別の軸です。
開発や運用の時系列上の役割設計
実装、リリース、運用、障害対応、改善
技術レイヤー
フロントエンド、バックエンド、データベース、クラウド
組織上のロール
SWE、SRE、Platform Engineer
「運用をソフトウェアエンジニアに任せる」という説明は、主に一つ目の軸の話です。
一方、「SREはインフラを担当する」という説明は、技術レイヤーと組織上のロールの話です。
この二つを混ぜてしまうと、SREは「運用の問題をソフトウェアエンジニアリングで解決するプラクティス」ではなく、「インフラレイヤーを担当する職種」になってしまいます。
しかし、信頼性を高める取り組みはインフラだけに存在するものではありません。
Androidアプリであっても、クラッシュ率を計測し、変更のリスクを抑え、障害時の挙動を設計することはできます。これらも、サービスの信頼性をソフトウェアエンジニアリングによって改善する取り組みです。
SREという専門ロールは存在していてもよいと思います。
ただし、SREのプラクティスまで、そのロールだけのものにするような、例えばSREはSRE領域に集中するといった説明は誤解を生む可能性もあるかなと思いました。
「何でも屋にならない」は、技術領域を限定する話ではないのかもしれない
SREの議論では、「SREが何でも屋になってはいけない」という話もよく出てきます。
この言葉だけを聞くと、SREが担当する技術領域を限定する話のようにも見えます。
しかし、セッションを聞きながら考えてみると、これは技術的な守備範囲よりも、組織内でどのような関係を作るかという話に近いのではないかと思いました。
開発チームが問題を見つけ、SREへ依頼します。SREが解決し、結果を返します。同じような問題が起きれば、再びSREへ依頼します。
この関係が固定化すると、SREは社内の受託チームになります。
問題を解決しても、依頼元のチームに知識や改善能力が残らず、依頼だけが増えていきます。
重要なのは、SREがどの技術レイヤーに関わったかではありません。
問題を引き取って代行したのか、共同で改善し、その問題を扱う能力をチーム側に残したのか、という違いです。
つまり、「何でも屋にならない」というのは、
SREが関わる技術レイヤーを限定する
という話ではなく、
依頼された作業を代行し続ける関係を作らない
という話として捉えた方が、SREの考え方と整合するように思いました。
必要であれば、SREはどのレイヤーにも関与できます。
ただし、一時的な介入を恒久的な受託関係にしないことが重要そうです。
SREの境界は、技術スタックではなく、介入の目的や関係性によって引くものなのかもしれません。
関連するセッション: (他にもあったらすいません)
Blamelessによって、人間がアンタッチャブルになっていないか
もう一つ印象に残ったのが、Blameless、つまり非難なきポストモーテムに関する議論です。(これはどのセッションについて廊下で議論していたか忘れてしまいました....)
障害が発生したとき、操作をした個人や、バグを入れた個人を責めないことは重要です。
誰かを責める文化では、参加者は自分を守るために情報を隠します。失敗が共有されなくなり、組織として学習できなくなります。
一方で、個人を責めないことを強く意識するあまり、人間に関する要因そのものがアンタッチャブルになっていないか、という問題提起がありました。
たとえば、担当者が疲労していた、体調が悪かった、十分に集中できないスケジュールだった、といったことです。
これらは、個人を非難するための情報ではありません。
しかし、人間に関する情報を分析対象から外してしまうと、なぜその判断や操作が行われたのかを十分に理解できません。
個人の行動や判断を分析しないのではなく、その行動を個人の能力や性格だけで説明しないことが重要なのだと思います。
人間の行動や状態も含めて確認しながら、それを個人への攻撃ではなく、システムや組織を改善するための情報として扱う必要があります。
Blamelessを「誰にも何も聞かないこと」にしないための視点として、興味深いと思いました。
Human Observabilityという発想
この会話の延長として、Human Observabilityという話もありました。
私たちは、システムのCPU使用率、メモリ、レイテンシ、エラー率などを細かく観測しています。
一方で、そのシステムを操作している人間がどのような状態だったかは、ほとんど観測していません。
そこで、オペレーション中の心拍数などを取得し、人間側の負荷も観測できないか、という話がありました。
発想としては面白いですよね。ただし、会社が個人の生体情報を取得するのは現実的には難しいので、ただの思考実験になりそうです。
また、心拍数だけで認知負荷や判断能力を直接判断することもできません。
Human Observabilityを考える場合、最初に観測するべきなのは、生体情報よりも仕事の構造かもしれません。
会議やオンコールの時間、休憩の有無、同時に抱えていた作業、交代要員の有無、本人が申告した疲労度などです。
これらであれば、会議を減らす、交代要員を用意する、中断や延期の権限を明示するといった改善につなげられます。
「とりあえず1%」ではなく、説明できる1%にする
技術的なテーマとして印象に残ったのが、分散トレーシングのサンプリング率に関する議論です。山口さんのセッションです。
https://sre-next.dev/2026/schedule/#slot090
分散トレーシングには、保存容量や通信量などのコストがかかります。そのため、1%や数%だけを保存するサンプリングが行われます。
ただ、なぜ1%なのかと聞かれたとき、「コストが高いから」「よくある設定だから」としか説明できないことも多いのではないでしょうか。
セッションで提示されていたのは、
とりあえず1%ではなく、説明できる1%である必要がある
という考え方でした。
サンプリングされた観測データと、実際の母集団の間には誤差があります。
そのため、どこまでの誤差を許容できるかを決め、そこから必要なサンプル数を考える必要があります。
さらに、許容できる誤差は、SLOやエラーバジェットに関する意思決定から考えられる、という話でした。
整理すると、次のような流れです。
SLOとエラーバジェット → 意思決定の境界 → 許容できる観測誤差 → 必要なサンプル数 → サンプリング率
この考え方を使えば、「1%で十分なのか」という問いを、経験や感覚ではなく、観測品質の仕様として議論できます。
エラーバジェットはメトリクスから計算するのではないか
この話を聞いたとき、一瞬納得したあとで、しばらくして「ん？？？」となったんです。私の周りの多くのケースでは、エラーバジェットの元になるSLIは、トレーシングデータではなく、サーバーサイドの数値メトリクスから計算することが多いです。メトリクスであれば全量保存して集計できます。
一方、トレーシングはコストの都合でサンプリングされていることが多いです。
それなら、サンプリング誤差を考慮しながらトレースからエラーバジェットを計算するよりも、全量のメトリクスから計算した方が自然なのではないかと思いました。
この点をお昼ごはんを食べていた登壇者の山口さんに直撃したところ、その説明を聞いて腹落ちしました。
サービス単位のメトリクスでは、ユーザーが受け取った品質を表現できない
各マイクロサービスで、成功数や失敗数をメトリクスとして取得することはできます。
ただし、それは基本的には、そのサービスから見た成功と失敗です。
実際のユーザー体験は、複数のサービス・機能をまたいで構成されています。
最終的に成功レスポンスを返していても、内部ではリトライやフォールバック、部分的な失敗が発生していることがあります。
ユーザーに一番近い場所、例えばフロントエンドの成功率だけを見れば成功が返っていたとしても、リトライやフォールバックの結果、最後のレスポンスの品質が100%じゃないことがありえます。例えば、個人へ最適化したレスポンスを返すサービスがエラーだったので、汎用的なレスポンスを返すなどです。
そこで、フロントエンドから始まり、複数のサービスをまたぐトレースを使います。
トレースを使うことで、ユーザーの操作を、たとえば次のように分類できます。
Full success
本来期待された品質で完了した
Degraded success
操作は完了したが、フォールバックや部分欠落を含む
Failure
ユーザーの目的を達成できなかった
単純なAPIの成功率だけでなく、「ユーザーが本来期待していた品質を提供できたか」をSLIとして扱う考え方です。これは分散トレーシングをベースにしたエラーバジェットにしか扱うことはできません。
トレースそのものではなく、トレースからSLIを作る
最初は、サンプリングされたトレースを直接エラーバジェットにする構成を想像していました。
ただ、より正確には、トレースを使ってユーザージャーニー全体の品質を判定し、その結果からSLI用のメトリクスを生成する、と考えた方がよさそうです。
流れとしては、次のようになります。
ユーザー操作のトレースを取得します
トレース全体から、リトライやフォールバックなどを判定します
操作をFull、Degraded、Failedに分類します
分類結果をメトリクスとして集計します
そのメトリクスからSLIとエラーバジェットを計算します
つまり、トレースはユーザージャーニーを再構成し、品質を判定するための入力です。
最終的にSLIとして扱うのは、その判定結果を集計した値です。
サービス単位のメトリクスだけでは評価しにくいユーザー体験を、トレースの文脈を使って分類し、その結果をメトリクスとして集計する、という構成が発展的だなと感じました。
理想的なサンプリング率を設定できない場合、どう精度を補うか
(ここからの話は山口さんのセッションを受けて、廊下で他のSREと議論した内容です)
この発表の、エラーバジェットから許容できる誤差を計算し、必要なサンプル数を求め、そこからサンプリング率を決める、という考え方は理想的です。
ただし、現実にはトレーシング基盤へ使える予算や保存容量が先に決まっていることもあります。
必要な精度が得られないことが分かっていても、サンプリング率をそれ以上引き上げられないケースです。
しかし、観測基盤の精度が足りないからといって、それに合わせてSLOを緩めるという判断には通常なりません。SLOは、観測基盤の都合ではなく、ユーザーへ提供したい信頼性から決めるものだからです。
そこで、サンプリングされたトレーシングデータだけでSLIを推定するのではなく、全量取得しているサーバーサイドメトリクスを組み合わせることで、誤差を補完できないか、という議論をしました。
トレーシングとサーバーサイドメトリクスには異なる強みと弱みがあります。
トレーシング
ユーザージャーニー全体の品質を評価できる
サンプリングによる誤差がある
サーバーサイドメトリクス
全量を比較的低コストで集計できる
ユーザーが受け取った最終的な品質を直接表せない
ここで、全量メトリクスを単なる参考情報として並べるのではなく、トレースから得た推定を統計的に補正するために使うことを考えます。
たとえば、サンプリングされたトレースから、ある内部エラーやリトライが最終的な品質劣化につながる確率を推定します。
一方、その内部イベントが母集団全体で何回発生したかは、全量のメトリクスから取得します。
両者を組み合わせることで、トレースを全量取得しなくても、ユーザー体験の劣化数をより高い精度で推定できる可能性があります。
概念的には、次のような構成です。
サンプリングされたトレース → 内部イベントがユーザー体験へ与える影響を推定する
全量のサーバーサイドメトリクス → 内部イベントの母集団全体での発生数を計測する
両者を統計的に合成する → ユーザー体験全体での品質劣化を推定する
目指しているのは、コストの都合に合わせてSLOを緩めることではなく、異なる性質を持つ観測データを組み合わせ、固定されたコストの中でSLIの推定精度を高めることです。
ただし、トレースとメトリクスでイベントの定義が一致している必要があります。同じユーザー操作内で複数の内部エラーが発生した場合の重複も考慮する必要があります。
また、サービス、エンドポイント、リージョン、アプリバージョンなどによって、内部エラーがユーザー体験へ与える影響が異なる可能性もあります。
サンプリング方法に偏りがあれば、トレースから推定した関係自体が偏ることもあります。
実際に成立させるためには、さまざまな課題がありそうです。
ここまで考えると、単なるオブザーバビリティの設定ではなく、統計的な推定の問題になります。
どのような条件で精度が改善するのか、テイルサンプリングのように抽出自体に偏りがある場合でも成立するのか、実際のユーザー体験とどのように照合するのか。
これらを実データで評価できれば、研究論文にもなり得るテーマではないか、という話をしました。
フォールバックやリトライをどう評価するか
さらに難しいのは、フォールバックやリトライが発生した場合に、それをどう評価するかです。
内部でリトライが発生しても、ユーザーが知覚しない時間内に完了していれば、問題がない場合もあります。
フォールバックについても、それがプロダクトとして正式に保証している品質であれば、必ずしも劣化とは限りません。
つまり、技術的なイベントだけでは、good eventかbad eventかを決められません。
最終的には、
ユーザーに約束している体験を提供できたか
というプロダクト上の基準が必要になります。
劣化した成功をエラーバジェットへどう反映するか
Full success、Degraded success、Failureを分類できたとしても、それをどうエラーバジェットに反映するかは簡単ではありません。
Degraded successをすべてbad eventとして扱うと、軽微な劣化と完全な失敗が同じ一件になります。
一方、劣化へ重みを付ける方法では、その重みをどのように決めるかという問題があります。
そのため、無理に一つのSLIへまとめず、複数のSLIに分ける方法も考えられます。
たとえば、最低限の目的を達成できた割合と、本来の品質を提供できた割合を分けて計測します。
これによって、
サービスは利用できていますが、本来の品質を提供できていません
という状態を表現できます。
単純な可用性だけでは見えない品質低下を捉えられる可能性があります。
SREを知らない人を連れていったことで、SREについて考え直せた
今回、SREをほとんど知らないAndroidエンジニアと一緒にSRE NEXTへ参加しました。一番の目的は、この取り組みが他の会社にも波及して、他社のクライアントエンジニアなどSRE以外の方が登壇するスタイルが増やしたいと思ったものでした。
ただ、実際には、SREを知らない人の視点が入ったことで、私自身がSREについて改めて考えることになりました。SREコミュニティの中だけで話していると、暗黙の前提として見えにくくなるものなのかもしれません。
今回の参加で得られた一番大きな発見は、そこだったのかもしれません。ぜひ、みなさんも他職種の方を誘ってみませんか。