はじめに
こんにちは！スタイル・エッジでSREエンジニアをしているpeipeiです。
今回は SRE Kaigi 2026に参加してきました！
SRE Kaigiは、SREに関わる人たちが集まり、現場の知見や悩みを共有するカンファレンスです。参加者同士の交流を通じて、新たな発見やインスピレーションを得られる場として注目されています。
筆者自身、SRE Kaigi 2025のアーカイブ動画をすべて視聴するほど、以前から気になっていたイベントでした。
「この熱気を会場で味わいたい！他社SREの生の声が聞きたい！」と思い、上司に相談したところ快く背中を押してもらい、福岡から東京へ出張し、SREに興味を持っているエンジニアのせっちゃんと2名で現地参加してきました。
この記事では、会場の雰囲気や印象に残ったセッション、そして今後スタイル・エッジのSREとして取り組んでいきたいことをまとめます。
参加の目的
今回の参加目的はいくつかありますが、なかでも一番大きいのは、「他社の苦悩や失敗談のリアルを聞き、同じ状況で悩んだときの羅針盤にすること」です。
弊社では昨年SREチームを立ち上げ、システムの信頼性や開発生産性を見直す活動を進めています。0→1のフェーズは想像以上に難しく、特に「SREを維持・継続し、文化として根付かせること」に苦戦しています。
そんなときに他社のSRE事例を見ると、驚くほど同じところで悩んでいることが分かり、「自分だけじゃないんだ」と励まされることがあります。
SRE Kaigiのようなイベントでは、表に出にくい“裏側のリアル”に触れられる機会も多く、思わず何度もうなずいてしまう場面があります。そういったリアルから学びを持ち帰り、今後の取り組みに活かしていきたいと思っています。
会場の様子・企業ブース
開会式の時点でたくさんの方がいらっしゃって、「私と同じように楽しみにしていた方がこんなにいるんだな」と感じました。実際にセッションが始まった際も、PCを持ってメモをしている方や、セッション後に登壇者へ質問しに行っている方など、積極的に情報を取りにいく姿も印象的でした。
また、企業ブースも各社が工夫を凝らしており、見応えがありました。
SREが抱える課題と、それを解決するためのアクションをポストイットに書いて貼れるようにして意見を募ったり、システムのアーキテクチャ図を用意して抱えている課題について話したりするなど、各社さまざまな工夫が見られました。
中でも株式会社MIXI様の「SRE成熟度チェック」は、特に面白い取り組みだと思いました。
やはりSREのスタートラインとも言われるSLOやエラーバジェットの運用は、一番難しいところだよなあ…と改めて感じました。また、「取組中」にシールを貼った方は、取り組み自体は進めているものの、さまざまな課題感を抱えているのだろうな、と想像しました。
セッションレポート
私が拝聴したセッションの中で、特に印象に残ったものを3つ紹介します。
生成AI時代にこそ求められるSRE
基本情報
- 登壇企業：アマゾンウェブサービスジャパン合同会社
- 登壇者：山口 能迪 氏
概要
生成AIの普及により、もはや「AIを業務で使うべきか」を議論するフェーズは終わり、多くの方が業務でAIを利用する時代になりました。生成AIはソフトウェア開発の生産性を爆発的に高める一方で、システムの不安定化や変更失敗率の増加といったリスクも同時に押し上げるといいます。
SREの責務は、この生産性向上を「カオス」にせず、持続可能なユーザー価値へと変換することにあります。本セッションでは、そのための戦略として「コンテキスト」と「ガードレール」という2つの観点を軸に掘り下げていました。
主なポイント
1. AIは組織の能力を増幅する「アンプ」である
AIは、組織の長所だけでなく課題も含めて増幅させる「アンプ（増幅器）」のような存在だ。開発速度は上がる一方で、もともと課題を抱える組織では、システムの不安定さや失敗率まで増幅される。だからこそ、SREによる信頼性の土台づくりは、これまで以上に重要になっている。
2. AIが正しく動作するための「コンテキスト」を補強する
AIは一般的な知識を持っていても、特定のシステム固有の情報までは把握していない。AIがより正確にデバッグや分析を行うには、システム固有のテレメトリーやアーキテクチャ図など、静的・動的両方の情報を「コンテキスト」として提供する必要がある。
3. AIの失敗を予防・回復する「ガードレール」を強化する
AIの不確実な出力や、爆発的に増えるコード生成量に対処するための「保険」を整える。ハルシネーションや脆弱性の混入を防ぐには、常に同じ結果を再現できるビルドプロセス、高度な自動テスト、ポリシーによる統制といった仕組みが欠かせない。
SREが提供すべき「コンテキスト」と「ガードレール」の分類
| 大分類 | 中分類 | 具体的な内容・プラクティス |
|---|---|---|
| コンテキスト (AIの精度を高める下地) | 1. オブザーバビリティ | 高次元なイベントや構造化ログを活用し、AIがシステム状況を科学的に判断するための文脈を提供する。 |
| 2. Everything as Code (XaC) | IaCやドキュメントなど、あらゆる情報をコード化して管理することで、人間とAIの両方が理解・追跡可能にする。 | |
| 3. ポストモーテム | AIと共に障害のタイムラインや根本原因を蓄積し、AIが次なるデバッグを行う際の重要な知識源（コンテキスト）とする。 | |
| ガードレール (AIの失敗を制御する保険) | 1. 密封ビルドとセキュリティ | 常に同じ結果を再現するビルドプロセスを構築し、SBOMの活用等で不適切なライブラリの混入や脆弱性を防ぐ。 |
| 2. 発展的なテスト手法 | ファジングやミューテーションテストをCI/CDに組み込み、AIが生成した大量のコードの品質を自動で担保する。 | |
| 3. Policy as Codeによる統制 | OPA等のツールを用いて、AIが生成した構成が組織のポリシーに違反していないかを自動で検証する。 | |
| 4. SLOに基づいたリリース | カナリアリリース等を活用し、SLOベースで自動ロールバックを行うことで、AIによる変更の影響を最小化する。 | |
| 5. SRE文化 | AIの提案に異議を唱えられる「心理的安全性」を拡張し、自動化バイアス（AIを鵜呑みにする傾向）を排除する。 |
得られた学び
本セッションを通じて、SREが重視してきたオブザーバビリティやSLOは、今や 「AIが正確に判断を下すための必須のデータセット」 へと進化していることを学びました。特に印象的だったのは、ポストモーテムを「AIも読むもの」と再定義し、組織の教訓をAIの知能に循環させるという視点です。
AIを正しく導くためにSREを実践し、「コンテキスト」と「ガードレール」を手に入れるという姿勢がこれからのエンジニアに求められる指針だと感じました。
ゼロからはじめるSRE：一人運用から複数プロダクト・SREチーム立ち上げまでの軌跡
基本情報
- 登壇企業：株式会社TalentX
- 登壇者：籔下 直哉 氏
概要
本セッションでは、一人でのインフラ運用からSREチームを立ち上げ、複数プロダクトを支える共通基盤を構築するまでの道のりが語られていました。
創業期のレガシーな環境からAWSへの完全移管、そして属人化の脱却を目指した組織的なSRE活動への進化が描かれていました。事業成長と技術負債の解消というジレンマに直面しながら、「現実的なスピード優先」と「理想の追求」を使い分けた意思決定のプロセスが具体的に語られています。最終的には、モニタリング・コスト・セキュリティ・IaCの4領域における体系的な改善へと至っています。
主なポイント
1. レガシー脱却と将来を見据えた基盤刷新
採用の壁やサービス停止リスクとなっていたレガシーな構成を見直し、将来のSRE採用やマルチプロダクト展開を見据えたモダンなAWS基盤（EKS/ECSなど）へ刷新した。
2. SREを「承認のボトルネック」から「ガードレール」へ
手作業中心の運用から脱却し、Terraformのモジュール化に加えて、AIや静的解析を活用した。開発者がSREの承認待ちで止まらず、安全かつ迅速に自走できる体制を整えた。
3. 経営と連動した戦略的なSRE活動
SLI/SLOを軸にした開発チームとの文化醸成、経営判断に基づくコスト最適化、成熟度モデルを用いた計画的なセキュリティ強化などを推進した。技術面に閉じず、組織・経営面も含めた最適化に取り組んだ。
AWS移管後に行われた主な運用改善
| 改善領域 | AWS移管直後の課題 | 行った施策 | 実現した効果 |
|---|---|---|---|
| モニタリングとSLI/SLO | APIの5xxエラー率を可視化しているだけで、形骸化していた。 | Slack通知の運用や月次会議を通じ、開発チームと状況を共有する文化を醸成した。 | 開発チームが自らSLOを意識し、異常時に自発的なアクションを起こせるようになった。 |
| インフラコスト管理 | 実績ベースの感覚的な予算策定となっていた。 | AWS Cost Explorerによる異常検知の導入、RI/Savings Plansの適用条件を経営層と戦略的に決定した。 | 経営と連動した「計画的・戦略的なコスト最適化」が可能になった。 |
| セキュリティ強化 | 顧客対応や外部診断に基づく、受動的なアップデートが中心だった。 | AWSセキュリティ成熟度モデルを採用。半期ごとのKPI設定や、WAFマネージドルールによる標準化を行った。 | 組織としての現在地を客観的に把握し、計画的なセキュリティ強化を推進できるようになった。 |
| IaC周りの整備(Terraform) | 手作業が多く、再現性やコード品質の維持に課題があった。 | コードをモジュール化し、GitHub CopilotやTFLintを活用したデプロイパイプラインを自動化した。 | 開発速度とガバナンスを両立する「ガードレール」が構築された。 |
得られた学び
スモールスタートで始め、改善を繰り返しながら組織を変えていく姿が非常に印象的でした。自社でも取り組めている部分と、これからの部分があるため、トライアンドエラーを重ねながら文化を育てていく必要性を改めて感じました。
特に、SLI/SLOなどの数値を出すだけでなく、「開発チームが自ら意識し、アクションにつなげられる文化」を作っている点が印象的でした。周囲を巻き込みながら、自然と根付く状態を目指していきたいです。
また、SREには「技術負債を放置するリスク」と「理想を追いすぎてオーバーエンジニアリングになるリスク」が常に付きまとうと感じました。組織のフェーズに応じて「今やるべきこと」を優先順位付けし、投資対効果を意識して戦略的に実行することが重要だと感じました。
Embedded SREの終わりを設計する 〜 「なんとなく」から計画的な自立支援へ 〜
基本情報
- 登壇企業：Sansan株式会社
- 登壇者：鷹箸 孝典 氏
概要
SREのミッションを「サービス立ち上げの速度を高め、運用コストを削減すること」と定義した際、特定の開発チームに長期間「なんとなく」関わり続けることは、SREがそのチームに固定され、知見が全社に広がらないという課題を生みます。
本セッションでは、SREが組織のボトルネックになるのを防ぐため、開発者の自立をゴールとした段階的な支援体制の設計について語られました。特に、知識移転を定量化する 「SRE Knowledge Transfer Matrix」 を導入し、データに基づいた支援と「Exit（撤退）」の判断を行っている点が特徴です。一箇所での「終わり」を組織全体の「始まり」につなげる、持続可能なSREモデルの構築を目指されている姿が印象的でした。
主なポイント
1. 「なんとなく」の関係からの脱却とExitの合意
明確な終わりのない支援はSREのリソースを枯渇させ、組織的なスケーラビリティを阻害する。そのため、開発チームと「自分たちが不要になること」を共通ゴールとして合意した。これにより、単なる「サポートする側・される側」という関係から、自立を目指す対等なパートナーへと再定義されている。
2. 定量的な知識移転の可視化（Knowledge Transfer Matrix）
主観的な「自信度」と客観的な「経験」を組み合わせた 「2軸評価」 により、知識移転の状態を数値化している。これにより、個人の成長だけでなく、チーム全体の冗長性を測定できるようになった。客観的なデータに基づいて「SREが離脱しても問題ないか」を判断できる仕組みが構築されている。
3. 「成功＝終焉」というパラドックスの追求
Embedded SREの本質的な価値は、「自らの仕事をなくすために一生懸命働くこと」 にあります。一つのチームで支援を終える（Exitする）ことで、SREは次の課題を抱えるチームへ異動でき、自立した開発者が別のチームへ異動することで知識が組織全体へ波及していくという、持続可能なサイクルを生み出しています。
得られた学び
「測定できないものは改善できない」という原則に基づき、知識移転を可視化したことで、具体的な対話と改善アクションが可能になっていた点が大きな学びでした。
また、SREがチームを抜けることを、開発者にとって単なる「仕事の増加」と捉えるのではなく、「自らの守備範囲を広げ、自立するための前向きなステップ」 であるというマインドセットを共有できていたことが印象的です。
さらに、チーム内の誰が教えられるレベルになっているかを分析して、チーム全体の能力カバレッジを100%に近づけることで、特定の個人に依存しない 「チームとしての強さ（冗長性）」 が確保されるという視点は、組織づくりにおいて重要な気づきとなりました。
全体の感想
今回は、弊社としても個人としても初のSRE Kaigiへの参加となりました。会場はSREに興味を持つ方ばかりで、とても熱量の高いイベントだと感じました。少し驚いたのは、現在SREではない方や、自社にSRE組織がない方も多く参加されていたことです。SREが特定の職種だけのものではなく、より広く必要とされている領域になっているのだと感じました。
また、「月間数億レコードのアクセスログ基盤を無停止・低コストでAWS移行せよ！アプリケーションエンジニアのSREチャレンジ💪」という宮村紅葉氏のセッションで、
「SREでない人のSRE活動にも大きな価値がある」
「SREは役職ではなく魂」
という言葉には痺れました。
SREだからSREをやるのではなく、クライアントや自社の開発メンバーのために動いた結果が、いわゆるSRE活動になるのだと思います。そういったスタンスで、できることからスモールスタートで改善を積み重ね、組織として文化を育てていきたいと感じました。
私は今後もSRE Kaigiに参加し続けたいと思います。社内のメンバーもどんどん巻き込み、もっと多くの方と一緒に現地で学びたいです。そしていつかは、弊社からもプロポーザルが出せるようになれば嬉しいなと思います。
おわりに
最後まで読んでいただきありがとうございました！
スタイル・エッジでは、一緒にSRE活動を進めてくださる仲間を絶賛大募集しています。
もし興味を持っていただけましたら、以下の採用サイトも一度覗いてみてください！
最後におまけ
屋台という形で、おにぎりや唐揚げ、たこ焼きなどが無料で提供されていました。アルコールを含むドリンクもあり、11時の時点で呑んでいる方もいました。
ノベルティもたくさんいただきました。個人的には、株式会社SmartHR様からいただいたDockerコンテナのアクリルキーホルダーが一番ツボでした。
