APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

"Embeddedの終わり"から"コスト障害"まで。SREが向き合うChallengeの最前線

はじめに

こんにちは、ACS事業部 の小原です。 2026年1月31日に開催された SRE Kaigi 2026 に参加してきました。

今年のテーマは 『Challenge SRE!』。 会場の熱気も凄まじく、従来のWeb運用の枠を超え、組織づくりやセキュリティ、そしてAIといった新領域へSREがどう拡張していくかが大きな焦点となっていました。

本記事では、私が特に感銘を受けた「組織の自走化(Embeddedからの卒業)」、「 守りの拡張(コスト、セキュリティ)」 に関するセッションに焦点を当ててレポートします。

SRE Kaigi 2026 とは?

本題に入る前に、SRE Kaigi について簡単に触れておきます。 SRE Kaigi は、Site Reliability Engineering(SRE)の実践や運用技術に関心を持つエンジニアのための、コミュニティ主導型カンファレンスです。 Web系だけでなく、エンタープライズ(大規模組織)や社内IT(SaaS管理)、そしてAI基盤など、多様なドメインのエンジニアが集結し、現場のリアルな悩みと解決策を共有する場です。

今年は、2026年1月31日に中野セントラルパーク カンファレンスにて開催されました。 テーマの『Challenge SRE!』からは、これまでの "安定稼働を守る" という文脈から一歩踏み出し、新しい技術領域への挑戦や、組織変革への挑戦など、SREの可能性を広げようという強いメッセージを感じました。

2025年 vs 2026年の変化考察

今回、セッションを聴講する上で意識したのが、前回のSRE Kaigi 2025との空気感の違いです。

2025年:"More SRE!"

昨年の初開催時のテーマは "More SRE!" でした。 当時は「SREの実践者を増やそう」「組織にSREをどう根付かせるか」といった、SREの認知拡大とベストプラクティスの共有に主眼が置かれていた印象でした。 「普及と拡大」といったところでしょうか。

2026年:"Challenge SRE!"

対して今年は、フェーズが明らかに一段階進みました。SREがいるのは当たり前になった前提で、"では、SREは次にどこへ向かうのか?" という問いが投げかけられていました。 「普及と拡大」から、ビジネスの不確実性と戦うための "Challenge" へ。 この変化を感じ取り、今回は "組織の自走化" と "守りの拡張"、そして "AI" という3つの視点でセッションを回りました。

テーマ別考察

今回の SRE Kaigi では、私が聴講したセッションの多くが不思議と相互に関連し合っていました。 そこで本記事では、私の観測範囲で感じ取った大きく3つのテーマに分けてレポートします。

▼テーマ 1:Embedded SRE はゴールではない

このテーマに関しては、以下のセッションでの発表内容が非常に印象的でした。"SREがチームに入り込むことはあくまで手段であり、最終ゴールではない"、という共通したメッセージを感じました。

関連セッション

  • Embedded SREの終わりを設計する 「なんとなく」から計画的な自立支援へ

    speakerdeck.com

    「なんとなくEmbedded 」の危険性とExit戦略について、計画的に終わり(離脱)を設計しないと、SREが単なる便利屋になってしまうリスクが語られていました。 SREがチームに入り込むと "インフラのことは全部あの人に任せよう" となりがちです。セッションの中で特に刺さったのが、抜けるときに関係が悪化するのではないかという不安についての言及です。 これに対する答えは、ゴール(期待値)を合わせることで、互いが成長する前向きな卒業にする というものでした。SREがチームに常駐するのは、"ずっと助けるため" ではなく "自立を促進するため"。このマインドセットの切り替えは、今の自分に必要な視点だと感じました。

  • SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル

    speakerdeck.com

    Enablingの事例では、SREチームだけでなく支援を受ける側のメンバーも一緒に登壇していました。一方的な指導ではなく、互いが成長する関係性が築かれていることが伝わってきて、理想的なEnablingの姿を見た気がします。 また、オンボーディング資料の活用や「だっしゅぼーどを眺める会」など具体的な現場の活動の紹介がありました。「だっしゅぼーどを眺める会」でのアプローチがEnablingそのものだったのではないか、という気づきに共感しました。

  • 認知負荷を最小化するオブザーバビリティとSLOの導入 ―4名のSREが200名のプロダクトエンジニアを支援

    speakerdeck.com

    4名のSREで200名の開発者を支えるために、SLO計測やオブザーバビリティの設定を共通基盤化し、開発者の認知負荷を下げる工夫が紹介されました。 人海戦術ではなく、開発者が迷わずに使えるツールを提供することで、少人数でのスケーリングを実現することは、組織拡大における理想形だと感じました。 また、RICEスコアを用いてやるべきことの優先順位を整理するなど、ビジネス計画に対するアジリティと信頼性のバランスを論理的に決定している点が印象的でした。

▼テーマ 2:コストとセキュリティを エンジニアリングする

コストやセキュリティを、SREの技術でハックするという視点です。

関連セッション

  • 予期せぬコストの急増を障害のように扱う――「コスト版ポストモーテム」の導入とその後の改善

    speakerdeck.com

    予期せぬコストの急増を障害のように扱うというアプローチは目から鱗でした。 コスト超過を単なる "使いすぎ" で終わらせず、システム障害と同様にポストモーテムを実施する。 これの何が良いかというと、オーナーシップの明確化ができる点だと思います。 どうしても開発チームは機能開発を優先してしまい、コストの異変に対する気づきが遅れがちです。これを障害と定義することで、FinOpsチームと開発チームが合同で原因究明を行うプロセスが生まれ、結果としてコスト意識が文化として定着する。非常にエンジニアリングらしい解決策だと思いました。

  • コスト削減から「セキュリティと利便性」を担うプラットフォームへ、Sansanの認証基盤のこれまでとこれから

    speakerdeck.com

    "セキュリティを理由にプラットフォームを押し付けない" という言葉は、Platform Engineeringの本質を突いていると感じます。 "これを使えば便利になる" という価値(利便性)を届けることにフォーカスし、その裏側でセキュリティを担保する。これが本当の意味でのShift Leftなのだと考えさせられました。

  • IaaS/SaaS管理におけるSREの実践

    speakerdeck.com

    非エンジニアからの依頼をIssueテンプレートからPR作成まで自動化する事例が紹介されており、"ちょうどよい統制" を目指してSREの技術を広げている点に、職能の広がりを感じました。

▼テーマ 3:生成AI時代のSRE

最後に触れておきたいのが、AI領域への拡張です。

関連セッション

  • 生成AI時代にこそ求められるSRE

    speakerdeck.com

    AIを使うか使わないかの議論は終わり、どう使いこなすかのフェーズに入った、と解説されていました。 ここでSREに求められるのは、AIに適切なコンテキストを与え、脱線しないためのガードレールを設計することです。 コード化の重要性として、コミット履歴から背景を理解できるようになる点などが説明されていました。

全体考察

SREの守備範囲と役割の再定義

今日一日、様々なセッションを聴講して感じた私の中の2026年のSRE像は、「広さ」へのシフトです。 これからは、チームの運用はEnablingによって開発者に移譲し、SRE自身は浮いたリソースで、より多くのチームを横断的に支える基盤作りや、AI、セキュリティ、コストといった課題を開拓しにいく。 より大きなビジネス課題に立ち向かうためにSREが現場を離れるのは攻めの配置転換である、と解釈しました。そう考えると今日のセッションは一本の線で繋がります。

SRE × Platform Engineering による組織のスケール

今回、私が最も強く感じた課題感。それは、"一つのプロダクトチームだけでなく、複数のチームに横断的に関わりたいが、SREのリソース(人数)が圧倒的に足りない" というジレンマです。

Embeddedは強力な手法ですが、SREの人数分しかスケールしません。組織全体に信頼性を横展開しようとすると、このリソースの壁にぶつかります。 この壁を突破するために Platform Engineering は強力な効果があると感じました。 開発者が自律的に信頼性を担保できるプラットフォーム(基盤、ツール、ルール) を提供することで、少ないSRE人数でも効果的に組織全体を支えることができる。 現在、私の事業部でも推進している Platform Engineering ですが、SREの価値を組織全体へさらにスケールさせるための武器なのだと、背中を押された気持ちです。

まとめ

SRE Kaigi 2026 を通して感じたのは、"SREチームだけでシステムを守る時代の終わり" です。

システムが複雑化し、AIのような不確実な要素が増える中で、SRE一人が全ての門番をするのは難しいです。だからこそ、今、組織の力へどう結び付けていくかにより目を向けていく必要があると考えます。

単なる成功事例の発表会ではなく、今、SREコミュニティがどこに向かおうとしているのかという現在地を確認できる貴重なイベントでした。

会場で配られた「わかばちゃんと学ぶSRE」という小冊子も非常に良かったです。 SREという難解になりがちな概念を、マンガで直感的に解説してあり、SREを知らない開発者にSREの文化を伝えるための最高のツールだと感じました。

こういった "誰にでもわかる言葉で伝える" という姿勢は、SREの民主化の考え方そのものであり、カンファレンスの空気感をよく表していると感じました。

sre-kaigi.hateblo.jp

謝辞

最後になりますが、この規模のカンファレンスを準備・運営してくださったスタッフの皆様、そして貴重な知見(Challenge)を惜しみなく共有してくださった登壇者の皆様に、心から感謝申し上げます。

「Challenge SRE!」というテーマの通り、参加者である私たち自身も、明日からまた新しい挑戦を始めていきましょう。 また来年、会場でお会いできるのを楽しみにしています!


ACS事業部のご紹介

私達ACS事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering、AI駆動開発支援などを通して、攻めのDX成功に向けた開発者体験・開発生産性の向上・内製化のご支援をしております。
www.ap-com.co.jp www.ap-com.co.jp また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。 www.ap-com.co.jp

本記事の投稿者: 小原 丈明
Azureをメインにインフラ系のご支援を担当しています。