こんにちは、株式会社クイックのmonochro-photoです。
2026/7/10（金） - 7/11（土）の2日間に渡って開催されたSRE Next 2026に参加してきたので、自分なりのまとめもかねて投稿します。
今回は参加できたセッション数も多く、どれも大変勉強になりました。その中でも特に心に残ったもの2つに絞ってまとめました。
※ なおこの内容は私の「解釈・感想」を多分に含んでいます。もしかしたら発表者の意図と異なる部分もあるかもしれません。その点は予めご了承ください。
心に残ったセッション①
AI-native時代の信頼性を育てる、インシデント学習と改善ループの実践
Track A
7/10 13:00 - 13:30 株式会社メルカリ
Engineering Manager
foostan
テーマ： メルペイのオブザーバビリティ（SLO）
問題は原因そのものよりも、継続して直し続けれる「体制構築面」だった
- SLOを下回る要因は様々、しかし根っこは大きく３つくらいに集約された
- 問題はそれを直すことよりも、継続して直し続けれる「体制構築面」だった
- 数値に囚われきらないこと
- 監視している機能が、本当にユーザーにとっても価値がある機能なのか？（監視対象＝価値 になっている？）
対策「顧客体験を数値化して、定量化して判断する」プロジェクトを立ち上げた
- EM,VPoP等と「共通言語」で判断できる状態を作った
- 求められるSLOの数値が出せた
- ROIが明確になり、コストや対応増加によってできなくなることへの「トレードオフ」が明確になった、かつプロジェクトメンバー内で意識が統一された、異なる職種での一体感が生まれた
まとめ：自律的な改善ループ
- 開発チームが「自分ごと、自分のサービス」として改善ループを自主的に回せることが大事
- SREチームは「そのための仕組み化に注力」することが重要
- 人、AIを含めた「自律的な改善ループ」の設計と導入
- 注意：高すぎる非現実的な目標は逆効果、根拠と合意形成が成功の秘訣
感想
SLOという数値に囚われて、その数値を守ることを目的にしてはいけない。
数値はあくまでも数値、データであって、顧客体験そのものではない。
我々が担保すべきは顧客体験であり、そのために何をすべきか？を、ロールを超えて共通言語として機能させるための「定量的なモノサシの1つがSLOである」という理解。
これってシンプルだけど、ものすごく大事なことだと改めて感じました。
心に残ったセッション②
SREプラクティスを複数のプロダクト・組織で自律的に回し続けるための仕組みづくり
Track C Platinum Sponsor
7/11 15:35 - 16:05 KINTOテクノロジーズ
テーマ：品質維持×開発サイクル高速化
たどり着いた体制：セントラルSRE60% × エンベデッドSRE40%
- セントラルSRE で作った仕組みを、エンベデッドSREが開発チームへジョインして「SRE仕組み浸透化」+「個別最適」することで全体最適を図る
- セントラルSRE だけでうまく行かない部分がある。プロダクト固有の課題、チーム毎の課題がどうしても存在する。それを一律でうまくやるのはどうしても難しい面がある
課題感
最初は、セントラルSRE だけでスタートした
- 仮説→実装→観測の高速化
- まずはNewRelicで状態可視化したけど浸透しない！！
- ツール入れて終わりではない、使い方を知らないと、ツールがあっても結局使えない。使えないと浸透しない！のループ
- 各チームが自力で対応できるような手順を作成してみた
- 日常的にNewRelicを見ない。何かあった時だけしか見ない！！
- 既存運用に「上乗せ追加」するやり方だったからかも？単純に負荷が増えただけ
- まずは、毎回眺めてもらう癖付けから改善を始めた
- 勉強会定例会やった
- 参加者の意欲に左右される
- チーム毎の差が激しくなる
- まとめ：組織横断的な取り組みだけでは限界がある
解としてのエンベデッドSRE スタート
- 文字通り、開発チームに入って対応するSRE
- チームによって様々な状況差異がある
- 人数、技術スタックなどなど
- 何がそのチームにとって効果的なのか？をまず見極めること
- これは信頼構築でもある
- チケット対応するだけでは効果は限定的で、品質改善って部分には対応が追いつかない
- チームで改善を具体的に繰り返すことでやり方を癖付けする
- 曖昧な品質でSRE増やしても信頼は下がるだけ
- 人を増やすのは一時的な対応で、それ自体が本質的な解決ではない
- 人が要らないという意味ではない
- 人を増やす選択肢しかないと、組織事業スケールの観点でボトルネックになるという意味
- 1人あたり、2-3プロダクトが限界と考えている
- 人を増やすのは一時的な対応で、それ自体が本質的な解決ではない
AIエージェント で増員問題へアプローチ
- 人と同じ判断基準で品質を判定して、置き換えれるかを評価
- 同じエージェントでもプロダクト毎違いを吸収させるために、あえて個別最適でプロダクト毎にAIエージェントを入れた
- 全体最適のためにAIエージェントを入れているのだが、「個別最適によるチューニング」をしてチーム個別に最適化を横展開することで、結果として全体最適を実現する形
エージェントの目的はSREのEnablingであり、運用サポートだけではない
- 癖がないチームでは「癖付け」もAIエージェントの役割になる
- 例：稼働状況レポート送信、ポストモーテム実施の促しetc
- つまりは、EnableingSREメンバーそのものと同じ動きが求められる
- レポートは普段遣いのツールに格納することが認知負荷を下げるので◎
- エージェントのコンテキスト情報としてランブックの登録と保存によってこれまでの対応履歴として引き出した上で分析できるようにしている
- 聞けば答えるだけでなく、エージェント自身が能動的にチームに働きかける存在であることが重要
- そうなれば機能追加をすることで、AIエージェントによる対応範囲を広げていくことができる
感想
組織横断 × 個別最適のバランスが秀逸だなと感じました。
そして増員依存の組織スケール問題に、AIエージェントを使い、人の育成と一緒の感覚で育てていくという点が重要なのだとも感じました。
「AIエージェント」っていう人じゃない技術としてみるからうまくいかない。新卒を取って1から育てるのと同じ考え方でやってみるイメージが近いのかな？
人がやるときのステップを思い出して、どういう目的目標で、何をどうやるか。
ステップで細かく区切って、ステップ毎にAIエージェントに置き換える形で「導入評価」を行うのが良いんだろうなという解釈をしました。
まとめ
今回は以上です。
他にもたくさんの良いセッションがありましたが、この中でも特に心に残った2つをピックアップさせていただきました。
弊社ではPlatform Engineeringは走り出したばかりなので、参考になることばかりです。
どんどんいいものを取り入れて、ユーザーに対してよい価値を届けていきたいと考えています！
それでは最後までお付き合いいただきありがとうございました。