SRE NEXT 2026に参加してきた。SRE NEXTは過去すべての会で登壇していて皆勤賞と言われていたのだけど、今回はじめてプロポーザルがリジェクトされて、聴講のみの参加になった。一般に公開されている、発表資料は [SRE NEXT 2026 発表資料まとめ - SRE NEXT Staff Blog](https://blog.sre-next.dev/entry/2026/07/13/173953) に、参加者による参加レポートは [SRE NEXT 2026 参加レポートまとめ - SRE NEXT Staff Blog](https://blog.sre-next.dev/entry/2026/07/12/205027) にまとめられている。 SRE NEXTを知らない人向けに説明すると、国内初のSREに関するテックカンファレンスである。SRE Kaigiというのがあとでできて、今はSRE系カンファレンスはその２つある。 [https://sre-next.dev/2026](https://sre-next.dev/2026) 今回の自分の参加スタイルは、Keynoteといくつかの知り合いのセッションを聴いて、あとは廊下で知り合いと議論したり、スポンサーブースを回ったり、知り合いに挨拶したりというものだった。今回に限らず、だいたいいつもそんな感じになる。 さくらからの参加者はおそらく他にはfujiwaraさんのみで、 fujiwaraさんは[パネルセッション](https://sre-next.dev/2026/schedule/#slot096)で登壇されていた。パブリッククラウドのユーザーが非常に多く参加しているので、クラウドのユーザーの気持ちを知るという意味でも、もうすこし社内から参加者が増えるといいかもしれない。 ## 全体の傾向と感想 現地参加者数は890人、プロポーザル数はメインセッションが24/101 で採択率23.8%だった。採択率は昨年とおそらく同じくらいで、現地参加者数もたしか同じくらい。初回の2020年から年々増えてきて、そろそろ参加者数も頭打ちかもしれない。 プログラムの傾向は、以前から特定の話題が多いということもなく、AI一色というわけでもなく、様々な話題がある。流行り廃りに強く影響されないのはSREコミュニティの良いところかもしれない。最近言われているテックカンファレンスのスライド資料がAI生成感がでてしまった問題はSRE NEXTではあまり感じなかった。 (See [TSKaigi 2026 の発表資料の体感半数以上が AI 生成感あるものだった - mizdra's blog](https://www.mizdra.net/entry/2026/05/27/161559)) 自分にとっては、Day 1 Keynote "Reliability is a Question"と題した講演から始まり、「問いかけ」や「問い直し」が多く発生した会となった。必ずしも講演内で触れられたものだけでなく、廊下や飲み会での議論も含む。 - ユーザーの解像度がまだまだ低い問題：SREの信頼性は「ユーザーのための信頼性」を意味するが、プロダクトデザインの視点からみるとユーザーへの踏み込みが足りないのではないか？ - SREの定義問題：「運用をソフトウェアエンジニアに任せたら出来上がるもの」というSREbookの定義らしきものは、一般的にWhatでもって定義を与えるところをHowでもって定義を与えているのではないか。 - [SRE NEXT 2026に参加しました｜maru](https://sizu.me/maruloop/posts/kiiwa97nez3u) - SREの定義では、役割と技術レイヤーが混ざっていないか？ - から派生してのDevOpsとは何だったのか？ [DevOpsとは何だったのか - Gosuke Miyashita](https://mizzy.org/blog/2026/07/13/2/) - Blamelessしすぎる問題 - 個人を責めないことを強く意識するあまり、人間に関する要因そのものがアンタッチャブルになっていないか？ - サンプリングレートを統計学に基づいて決められているか？ - しぶい技術：AIとか組織論、マネージドサービスもいいけど、しぶい技術をちゃんとやれる人が必要では？ - クライアントサイドを含めたSRE 以降は個別の講演について書いていく。 ## Keynote ### Keynote 1 Reliability is a Question > [[2026__SRENEXT2026__Reliability is a Question|詳細メモ・Q&A はこちら]]（登壇者: David Blank-Edelman / Seeking SRE 編者・Becoming SRE 著者・SREcon 共同創設者） > 公式ページ: https://sre-next.dev/2026/schedule/#slot050 ／ スライド: 未公開 - 信頼性は答えの集合ではなく、問いの立て方の巧拙で決まる。可用性だけでなく、レイテンシ、正しさ、鮮度なども顧客視点で測るべきだと説く。 - 「root cause」という言葉は単一原因の物語を作り学びを狭めるため、トリガーと寄与要因で語り直すべきだと提案する。トートバッグ会社の障害例では「誰でもあり誰でもない、システムの問題だ」と結論づけた。 - 最も実践的な持ち帰りは、SREを社内で売り込む際に保険や税金の比喩を使わず、実際に起きたダウンタイムの復旧コストを基準にエンジニアリングの数字として語ることである。 感想としては、Ironies of Automationやリチャードクック博士の有名な「[How Complex Systems Fail](https://how.complexsystems.fail/)」 レジリエンス工学の論文の話など、海外のSREconでは定番ネタだが、国内では自分ぐらいしかあまり語らなかった学術的な話を持ち込んでもらえたのはとてもよかった。 ![[Pasted image 20260714174241.png|400]] --- ### Keynote 2 誰のためのリライアビリティ？ > [[2026__SRENEXT2026__誰のためのリライアビリティ？]]（登壇者: 木浦幹雄 / アンカーデザイン株式会社） > 公式ページ: https://sre-next.dev/2026/schedule/#slot089 ／ スライド: https://speakerdeck.com/kur/reliability-for-whom - SREの「Reliability」を支えるべき価値の宛先を問い直す講演であり、SLOの数値やCritical User Journeyについて「誰の、どんな目的達成のためか」を常に問い直す必要があると論じる。 - SREの「ユーザー」概念はデザインの「属性、文脈、目的」に比べて解像度が粗く、SLO「99.9%」も医療画像の0.1mm精度要求と同様、数値の妥当性を利用文脈に照らして検証すべきだと指摘する。 - 「ユーザー」という言葉をやめて具体的な活動として議論すること、SREの観測データとUXリサーチの定性データを組み合わせることを、SREとデザインの協働として提案する。 ![[Pasted image 20260714185547.png|500]] 前述したように、SREみんなが思っているSLI/SLOってユーザー体験を本当に表現できているのか？ ## OSINT for SRE: 学術論文とポストモーテムから探るシステム障害の共通パターン > [[2026__SRENEXT2026__OSINT for SRE 学術論文とポストモーテムから探るシステム障害の共通パターン]]（登壇者: 小山智之 / 株式会社メルカリ） > 公式ページ: https://sre-next.dev/2026/schedule/#slot071 ／ スライド: https://speakerdeck.com/tomoyk/sre-next-2026 - 学術論文とポストモーテムを「OSINT for SRE」として体系的に分析し、障害原因に関する学術的知見が運用現場で活かされていない現状に対して、データに基づく定量的な優先度判断を提案する。 - インフラ障害はHDDのハードウェア故障がMicrosoft、Baiduともに70〜80%台を占めるが、それ自体はサービスレベル障害の主因ではなく、連鎖障害の大半は深さ2、すなわち高々3システムにとどまる。 - コンフィグミスは設定パラメータとコンソールコマンドの誤りが70〜85%を占め、Skyscannerの括弧欠落による478サービス一括削除事例は、ソフトウェア設計そのものが誤りを誘発しうることを示す。 事前にSRE NEXTに誘ったり、プロポーザルや資料をすこしレビューさせてもらっていた。論文からシステム障害の分析事例を紹介してくれる話。非常に好評でよかった。数少ないアカデミア仲間ということもあり、自分の講演だと間違えられることもあった。 ![[Pasted image 20260714225344.png|600]] ## しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 > [[2026__SRENEXT2026__しぶいSRE サーバから見えない障害にどう向き合うか ラストワンマイルのデバッグ実践]]（登壇者: 星北斗 / 株式会社LayerX） > 公式ページ: https://sre-next.dev/2026/schedule/#slot097 ／ スライド: https://speakerdeck.com/kanny/shibui-sre - サーバのログやメトリクスが正常でも、クライアント側やユーザー環境の通信経路で起きる障害はサーバサイドの観測範囲の外にあり、原因不明のまま埋もれてしまう。 - HARファイルのウォーターフォールチャートを読むと、企業ファイアウォールのTLS検査がHTTP/2のストリームをバッファリングして表示を遅延させている挙動まで切り分けられる。 - SMTPUTF8のMTA間対応不整合によるメールのサイレントロスト、message/partial分割によるプリンター発メールの添付欠落、36行のAレコードが招いたDNSのTCPフォールバック失敗など、いずれもサービス提供者側からは観測できない「ラストワンマイル」の障害である。 発表者の星くんとは期中に散々おしゃべりしていた。LayerXでは、顧客環境が地方のSOHOのレガシーだらけの環境だったりして、顧客環境でのトラブルシューティングにしぶい技術が必要とのこと。 ![[Pasted image 20260714225635.png|600]] ## ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略 > [[2026__SRENEXT2026__ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略]]（登壇者: 福嶋達也 / ソニー銀行株式会社） > 公式ページ: https://sre-next.dev/2026/schedule/#slot114 ／ スライド: 未公開 - ソニー銀行は2013年からのクラウドシフトを「攻めのIT」への転換手段と位置づけ、周辺系から勘定系まで全方位でクラウド化を完遂し、ビジネスアジリティ（QCD）を向上させた。 - 最も保守的になりがちな勘定系システムについて、旧C言語資産を一括変換せず全面的にJavaへフルスクラッチで書き直し、サーバーレスとマイクロサービスの考え方でクラウドネイティブ化した点が最大の踏み込みである。 - 副次効果としてオンプレミス比で消費電力を8割以上削減し、2014年からの継続的な働きかけがAWS大阪リージョン誘致(アメリカ国外で初の複数リージョン化)にもつながった。 すごく謙遜されていたけど、偉業としかいいようがない話だった。AWSにはたらきかけて、日本は火山の上にあるような島なんだといったり、信頼性について非常に高いレベルが求められることなどを丁寧に説明して、大阪リージョンを誘致したりとか、シフト前のコードは1行もないとか、マイクロサービス化にしても非同期トランザクションを扱う教科書的なやり方ではなく、銀行システムの同期トランザクションの単位にあわせて分割したり、システムのコアである勘定処理の部分から、ClaudeなどでAIコード生成を始めてかなりの手応えを得ているなど。