昨年に続きSREに求められる知見を学びたくて参加しました！
イベントの概要
SRE Kaigi 2026 は「Challenge SRE !」をテーマに開催される、SREを中心として知見の共有と参加者との交流を楽しむ技術カンファレンスです。
前回テーマ「More SRE !」の目標である
「さらにSREに関わる技術者の活躍の場を増やすため」
「さらにSREを理解し、興味を持っていただける技術者を増やすため」この2つの"More"を引き続き見据えながら、「"Challenge" SRE !」の通り
「SREを前に進めるための挑戦を応援する」
ことを目指し、参加者の皆様とコミュニティをより盛り上げていければと思います。
引用：
イベント参加の背景
- SREのいない環境でプロダクト開発に携わる中、SREのことをもっと知りたいと思っている。
- 昨年のSRE Kaigiがとても楽しかったので今年も参加。
- 少し悩んでいましたが懇親会つきのチケットを購入しました！
セッション
生成AI時代にこそ求められるSRE
メモ
生成AI時代に人間のエンジニア、SREは不要になるのか？
SREの重要性はいまだかつてないほど高まっている。
AIは増幅器。
AIが開発を加速させるけど、システムの不安定さが増え、変更失敗率を高める。
そもそもSREとは？
・ユーザーのシステムの信頼性を確立する
・運用をエンジニアリングで解決する
・チームのサイズ感に合わせ小さい単位でリリースできるようにする
AIが開発に入ったことで、デリバリーパイプラインが重要になった。
ソフトウェア開発=人間系+技術系の複雑な絡み合い。
AIの爆発的な生産性の増大を、カオスではなく、持続可能なユーザー価値提供に変換する。
コンテキスト、ガードレールを作る。人間ではなく、仕組みを補強していく。
コンテキスト：AIがよりよく動くための下地
ガードレール：AIの失敗の予防
AIの出力の精度を向上するにはコンテキストが重要となる。
動的な情報：テレメトリー
静的な情報：仕様、アーキテクチャ図
・コンテキスト1：オブザーバビリティ
未知の既知。
予期せぬ事態が起きた時に活用できる情報。
今はAWS DevOps エージェントがある。
SaaSじゃなくても、AIアシスタントでも活用できる。
・コンテキスト2：IaC
設計書よりも実際に動いているものが正しい。
ソースコード、XaC（IaC、PaC、NaC…）
Everything as Code。すべてレポジトリにコードとして管理する。
AIはプレーンテキストが一番トークンとして扱いやすい。
・コンテキスト3：ポストモーテム
Slack、Zoom録画、アラート履歴、コミットログ、テレメトリーデータを統合。
一連のタイムラインを自動生成し、過去の類似障害と比較、根本原因分析の提案、ドラフトを自動作成する。
人間だけでなくAIも読むドキュメントになる。
・ガードレール1：ビルドプロセス
ビルドプロセスは外部依存を無くす。
再現性、脆弱性のために密閉ビルドであるべき。
サプライチェーンセキュリティを考慮する。
・ガードレール2：テスト
発展的なテストを取り入れる。
ファジング、プロパティベースドテスト、ミューテーションテストなど。
・ガードレール3：Policy as Codeによる統制
組織のポリシーを違反させない。
・ガードレール4：SLOに基づいたリリース
カナリアリリースや機能フラグとの組み合わせでユーザー影響を低減する。
・ガードレール5：SRE文化
自働化バイアスを取り除く。
人間の方が正しくても、自動化されているものを人は止めづらい。
SREはAIを安心して迎えるための土台となる。
メモ
SRE領域でどのようにAIを扱っていくか。
開発者として仕様駆動開発を進めていく中、質とスピードの両立は今まで以上に難しくなっていると感じています。
そのうえで、プロダクトにおける品質、セキュリティ、信頼性が今まで以上に重要になっていると思います。
コンテキストとガードレール、考えることができていなかったことに気がつきました。
チームで意識を共有したい。
ゼロからはじめるSRE：一人運用から複数プロダクト・SREチーム立ち上げまでの軌跡
メモ
創業期・会社設立期。
当時テックリードがインフラと運用を見ていたが退職してしまった。
そこから一人の運用からの脱却を考えた。
新機能開発と技術負債の解消の両立。
経営層に対するインフラ刷新の必要性を説くことが大変だった。
セキュリティを高くすることでエンプラ向けの企業への導入が速くなった。
インフラリプレイスの要点と反省
技術選定：SRE採用できた。ツール先行になってしまった。
負荷運用軽減：楽になった。開発者体験もよくなった。
基盤設計：複数プロダクト設立に対するシナジー創出という意図に対してうまくいかなかった。
負荷が集中し、リソース不足とリソースマネジメントの面でうまくいかなかった。
妥協案ではあったが、重圧からは解放された。
SLOを定めた。
アプリケーション側からを想定。
SREを採用した。
・SLI/SLOをSREのものではなく開発チームがアクションとれるためのものにした
・インフラコストのモニタリング強化とコストカット施策の実施。計画的・経営運営との最適化。
・セキュリティ。現状把握に基づく計画的な強化。AWS成熟度モデルをもとに推進。
・IaC周りの整備。コード化していたものを使える状態に。
まとめとふりかえり。
テックリード時代：当時、身の丈に合わない技術選定をしていた。
CTO時代：経営視座をもとに考えることができる状態になった。
プロダクト開発において経営的な視点を持つことも重要。
学び
属人化の脱却への過程に励まされました。
そして、試行錯誤のハードルの高さも感じました。
登壇資料を読み直して解像度をあげたいです。
SRE とプロダクトエンジニアは何故分断されてしまうのか
メモ
SREチーム。少数構成、横断的にプロダクト基盤に関与。ProductSREの欠如。
攻めがProductエンジニア、守りがSREという心理的な分断が生まれていた。
決めたSLI/SLOが続かない。
同じ会社で仲が悪いわけではないのになぜ分断が生まれてきたか。
チームごとの境界線によって引き起こされたこと。
・情報共有の低減により、見えないリスクが増加した。
・全体最適より部分最適が生まれた。
・調整コストが増大し、意思決定スピードが低下した。
分断がなぜ起きるか。
・受発注の関係の固定化
・目指すベクトルのズレ。本来はユーザーへの価値提供という同じ目的があるはず。
・1対多が生む情報の非対称性。SREが複数プロダクトを見る限界。
分断の解消法。
バウンダリー・スパニングを参考にした。
分担を破壊するためのステップ：反射→結集→変形
・Reflecting（反射）
視点の違い、共通点を共有するための土台作りをした。
そのために、SREがやっていることをプロダクトエンジニアができるようにした。
結果、ポストモーテムが標準化された。
・Mobilizing（結集）
人事目標としての共通の目標を立てた。対話を仕組み化した。
結果、SLO定例が生まれた。計測、議論、改善のための議論のサイクルができた。
・Transforming（変形）
戦略的な人材配置を行い、情報の非対称性を解消した。
マインドセット。
ひとりひとりの視座が高ければ分断は起きない。
事業全体の解像度をあげる。
目指すべきは分断の気にならない全員の視座が高い状態。
学び
プロダクト価値の実現を目的とするプロダクトエンジニアと、プロダクトが実際に使われたフィードバックを直接得るSREがなぜ分断されてしまうか気になり聴講しました。
組織のサイロ構造。いつもチーム設計が不要な分断を生むことに改めて気づきました
バウンダリー・スパニング、学びたい。
Embedded SREの終わりを設計する：「なんとなく」から計画的な自立支援へ
メモ
・なぜExit戦略が必要なのか
開発チームとの関係の終わりは明確になっているか？
毎日充実はしているが、ひとつのプロダクトに専念している。
なんとなくでの作業分担をしてしまっている。
SREの本質は会社の価値をあげること。
ただ、顧客に価値を提供するプロダクトを開発している訳ではない。
組織の効率化に注力すべき。
Platformエンジニアリングユニット。
PlatformEngineer：全社共通基盤
EmbeddedSRE：個別チームごとの支援
プロジェクトごとにゼロから構築。標準化進んでない。SREのリソース配分。
結果、サービスごとに車輪の再発明が行われていた。
だからこそ、PlatformEngineeringとEmbeddedSREが重要。
EmbeddedSREは個別サービスへの支援ではない。
戦略的アプローチを進めることが重要。現状を可視化して計画的に進める。
それをSREから提案して合意を得た。
サポートする側／される側から共通目的に向かうパートナーに。
3つのフェーズに分けて推進。
Phase1：基盤構築。SREが主導。開発者と一緒に作業
Phase2：自律移行期。開発者が主導。SREはメンター。運用を段階的に委譲。
Phase3：サポート期。困ったときに声をかけて貰う。
新たな課題：測定不可能な知識移転。
スキルを明瞭化して、定量的に見える状態にした。
2軸評価にし、自信度と経験で測れるようにした。
3つの目的にあわせて運用。
・個人の成長可視化
・Exit判断
・継続的な活用
集計シートは2種：チームカバレッジ、ダッシュボード
個人とチームで目標を変えている。
個人：60%以上、チーム目標：100%以上
可視化が対話を生んだ。自己評価が主体性を引き出す。小さな成功体験の積み重ね。
負荷増加への配慮。モチベーション維持。適切なベース。
常に大事にしていること。EmbeddedSREの成功。=自らの終焉。
SREはボトルネックではなく、触媒になれる。
自問、対話、測定をしていく。
学び
イネーブリングチームがどのように自律支援するか。
合意形成と丁寧な推進が重要と改めて感じました。
改めて日々の作業を重視するのと同様に、将来的な目的を見据えて日々を築き上げることが重要と学びました。
懇親会でもお話をお聞きすることができて嬉しかったです。
組織の難しさを感じつつ、自発的に動ける状況に組織としての魅力を感じました。
チームを巻き込みエラーと向き合う技術
メモ
信頼性は会話。
ひとりSREのころは、SWEと一緒に議論・レビューできた。
複数人になったとき、SRE内で完結した。
結果、SWEとの間に見えない壁ができてしまった。
SREがチェスタトンのフェンスを立てていた。
属人化ではなく属チーム化。私たちと、あなたたちの関係を生んでいた。
目指すSREのあり方は、開発者自身が自律的に信頼性を制御できるようにサポートできること。
・伝えたいこと
どういう状況で、どこまで許容できるかを会話して設計する。
正常と異常は2値ではない。グラデーションがある。
異常時のハンドリングの実装は適切に後回しにする。
EmbeddedSREとしてプロダクトチームに参加。
議論の主体は開発チーム。やるやらないより、いつやるかが重要。
学び
紹介された事例に、自律支援にはファシリテーションが重要であると学びました。
イネーブリングチームに求めらることが支援対象の自己組織化だとしたら、ファシリテーションが手段のひとつになるイメージを持ちました。
自分が開発チームに足を置いてしまっているから気付けなかったけど、開発メンバーに役割を少しずつ委譲するうえで、自分のなかでも整理したいです。
ファインディの横断SREがTakumi byGMOと取り組む、セキュリティと開発スピードの両立
メモ
Findyは転職サービスのため個人情報を扱う。
セキュリティの信頼性と役割が重要。
AI時代のセキュリティ戦略：AI特有の新たな攻撃手法が生まれている。
・プロンプトインジェクション
・メモリーポイズニング
・モデル抽出攻撃
対応策：AIにはAIで立ち向かう。
エンジニアはAIの結果をもとに判断していくことが重要。
Findy Team+、顧客からのセキュリティ要件が高かった。
SOC2持ってないと商談に至らなかった。
SOCとは、System Organization Control。トラストサービス基準がある。
SOC取得により、営業・カスタマーサクセスが安心してセキュリティを説明できるようになった。
SAST：静的解析、ソースコードを解析して脆弱性を発見。
DAST：動的解析、稼働中のアプリに疑似攻撃を行う。
Takumi導入決め手は、SRE負荷増大や開発速度の圧迫があった。
Takumiは継続的なセキュリティレビュー、セキュリティ対応の効率化、高い検知率と低い誤検知率。
SREの運用負荷を大幅軽減。開発者の修正スピード向上。
Takumiの決め手：内製化/自動化の限界、監査要件の達成、ベンダーとの協業体制
Takumi導入：試験導入、マークダウンからスプシ化、takumi-tasksで定期バッチ実行、既存サービス横展開・定例共有会
学び
Tech RAMEN Conference以来の米内さんの登壇を聞きました。
AIにはAIで立ち向かうという言葉が強く残っています。
難しい領域こそ細かく砕いて、再現性の高い部分はAIに委譲し、複雑性のたかいところはAIと共に整理していきたい。
Findyさんのプロダクトやサービスに求められるセキュリティについても知ることができ、学びになりました。
SRE Enabling戦記：急成長する組織にSREを浸透させる戦いの歴史
メモ
短い期間で急拡大している。
組織状況：2年半弱でグローバル展開している
それに伴い、開発組織が急拡大している。
急ピッチでの開発で障害が多発する事態が発生。
会社的にプロダクトの信頼性を上げていくことが必要になった。
なぜ、それまでSRE的なことができていなかったのか？
・Observabilityが置き去りにされていた。
・SLOが形骸化。開発チームと同意の上決めたものではなかった。
・運用を決めていなかったためアラート発火しても動けなかった。
まずはやれるところから。
・Postmortemの運用刷新
改善活動の開始：開発チームのEM、QAと協力してタスクフォースを組活。
現状分析：既存テンプレの項目の複雑化、NotionDB管理の難しさ、再発防止策の未実行
対策1：
・書くべきポイントを絞り、敷居を下げた
・個別管理用のDB作った
・優先順位を設定した
対策2：
・社内Meet UpイベントでPostmortemの重要性を力説。啓蒙活動。
・Observability向上
Akupara。
開発ライフサイクルの各ステップの開発体験向上を目指す。
Datadog導入。OpenTelemetryを利用。
trace拡充を進めた。未実装処理に対する対応。Pub/Sub間をつなぐ。
・TelemetryDataの活用
Platform側の準備ができたので、Enablingを進めている。
後日談
Postmortem：SREがやらなくても、開発者が十分に進めている。
Observability：引き続き使える状態にできるように推進。
SLO推進：ProductionMeetingを定期開催
クリティカル・ユーザー・ジャーニーの取り組みを進めている。
Observabilityを進めるためにはPlatform Engineeringの力が必要。
学び
事業が急成長するとどこかに弱い部分が現れる。
うまくいっていない状況からの挑戦に大きな刺激をいただきました。
地道な対応がエンジニアリングを持続可能にすることに気づきます。
ショートセッションB
これってSRE？：いい部屋ネットを1,760%成長させた開発とインフラのコラボレーション
メモ
RedFrasco。不動産を扱う事業。いい部屋ネット。
4年間でAWS移行した。結果、お問い合わせ件数が17.6倍増える成長ができた。
・開発が攻めることができる土台作り
ビジネスを止めない移行プロセス：ストラングラーパターンによる移行方式を採用。ホームランより打席に立ち続ける。
ビジネスを加速させる基盤づくり：高速かつ安全にリリース。B/Gデプロイ。ダウンタイムを許容しない。無停止リリースに拘り。
インフラをボトルネックにしない取り組み
インフラ起因でリリースまでのリードタイムを伸ばさない。
デプロイまでを自動化。フィーチャー環境容易。
環境ないから止まる、といったことが無いようにする。
コストとのバランスを見ながら進めた。
・筋肉質なインフラをつくる
無駄を徹底的にそぎ落とす。要らない機能を捨てる。
コストを下げてリソース効率をあげる。
学び
CMでよく見かけるいい部屋ネットの話。
ログイン機能？を捨てたという発言に対して、会場からそこまで？といったどよめきがあったのが印象的でした。
筋肉質なインフラと言う言葉も印象的でした。「筋肉質」、意識したいです。
ベテランCTOからのメッセージ：AIとか組織とかキャリアとか気になることはあるけどさ、個人の技術力から目を背けないでやっていきましょうよ
メモ
ソフトウェアエンジニアとしての個人の技術力を高めることは必要。
技術力があることが組織の力になる。
プロフェッショナルの信頼の土台になる。
手を動かした人だけが世界を変える。
自分がやらないとだめ。やれないと、結局できるようにならない。
読む能力と書く能力はセット。書かないと読めない。
ソフトウェアは誰が書いても同じように動く。
但し、同じように書けば。
チームや組織にはちょっとだけ突出した個人が必要。
技術で解決できるものは技術で解決する。
ちょっとだけ突出した個になるための行動をする。
コミュニティは仲間。カンファレンスはティーチングスタイル。
懇親会の雑談は実情を交換する。
学び
大きな刺激をいただきました。
手を動かした人だけが世界を変える。
何を実現したくて何にオーナーシップを持つのか。
エンジニアリングにこだわりを持ちたいです。
ブース
Henryさんや、Dress Codeさんなど、コミュニティを通して知り合った方にご挨拶できて嬉しかったです。
また、コドモンさんのブースでもお話聞けて嬉しかったです。
今春娘が卒園してしまいますが、保育園に安心して預けることができたのはコドモンさんによるところも大きいと思っています。
リーナーさんのブースでは多摩.devの絵馬を書きました。
絵馬を書きました！#srekaigi #tamadev pic.twitter.com/6tQAPdC2O2
— 幡ヶ谷亭直吉@多摩.dev (@asagayanaoki) 2026年1月31日
そして、千さんのブースではコミュニティのお話ができたことも嬉しかったです。
カンファレンス熱い…！！
— 幡ヶ谷亭直吉@多摩.dev (@asagayanaoki) 2026年1月31日
SENさんのブースに奈良アジャイルに励まされたお話しにお伺いしたら、立川でコミュニティを考えている方に！#srekaigi #naragile #tamadev
いろいろなことが繋がっていく感じがしています。楽しいです。
懇親会
今回、自分はSREではないのでとし参加を悩んでいましたが、結果参加して本当に良かったです。
交流させて頂いた皆さまありがとうございました。
イネーブリングの話や、フィードバックサイクルの話、子育ての話、コミュニティの話など、いろいろな会話ができて楽しい時間を過ごすことができました。
いろいろなコンテキストがあって、そこでエンジニアリングに携わる人たちがいて、それを知ることが自分の世界を広げてくれます。
渋谷アジャイルや、プロダクトエンジニアリングナイト、D-Plusなどコミュニティで出会った方との交流が増えていくことが楽しいです。
まとめ
SRE Kaigiに今年も参加できて嬉しかったです。
1年通して感じるのは、昨年よりもご挨拶できる人が多くなったこと。
SREという領域は自分には少し遠い世界で、SREの方の話を聞けることはとても貴重な体験となっています。
今回特に印象に残ったのは、AIの登場によるSREに求められることの変化と、EmbeddedSREという考え方と課題感でした。
改めてSREはプロダクト開発にとって重要な存在となるイメージが持てました。
それをアウトプット量が加速する世界でどう実現していくか。
貴重な学びの場をありがとうございました。
