目次
はじめに
こんにちは。2025年4月にソフトウェアエンジニアとして新卒入社した黒髙です。普段はデリッシュキッチンの開発に携わっています。
2026年1月31日（土）に中野セントラルパーク カンファレンスで開催された SRE Kaigi 2026 に参加してきました。本記事では、特に印象に残ったセッションをご紹介します。
SRE Kaigi 2026 とは？
SRE Kaigi は、Site Reliability Engineering（SRE）コミュニティの活性化と技術的な交流を促進することを目的としたカンファレンスです。第2回となる今回は「Challenge SRE!」をテーマに掲げ、SREを前に進めるための挑戦を応援することを目指して開催されました。
弊社にはSREエンジニアや専任のSREチームは存在せず、プロダクトごとの開発チームがそれに近い役割を担っています。私自身もその組織の一員として知見を高めたく、「SREの考え方を開発チームとしてどう取り入れるか」という視点で参加しました。
入場時には様々なノベルティをいただきましたが、『わかばちゃんと学ぶSRE』という冊子は、初めてSREに触れる私にとって理解の助けになりました。
会場には3つのセッションルームに加え、多様なスポンサーブースや書籍販売コーナーがありました。さらにマッサージブースや屋台での軽食提供、コーヒー提供などバラエティ溢れる企画があり、一日を通してとても賑わっていました。
参加レポート
生成AI時代にこそ求められるSRE
発表者: 山口能迪さん
AWSの山口能迪さんによる、AI時代におけるSREの価値を再定義するセッションでした。「AIがコードや設定を書く時代に、SREは不要になるのか？」という問いに対して、「SREの重要性は、かつてないほど高まっている」と明確に答える内容でした。
セッションでは「AIは組織の能力を増幅するアンプである」という表現が使われていました。優れた組織はより強化され、課題のある組織は弱点を増幅させる。開発速度が上がる一方で、システムの不安定さや変更失敗率も増大しうるということです。その上で、SREの責務を「AIの爆発的な生産性を、カオスではなく、持続可能なユーザー価値へと変換する」と定義していたのが印象的でした。
また、SREがAIにもたらす価値は「コンテキスト」と「ガードレール」という2つの軸で整理されていました。
コンテキストとは、AIがより良く動作するための下地のことです。LLMは学習時点の一般的な情報しか知らないため、システム固有の情報はコンテキストとして与える必要があります。具体的にはオブザーバビリティによるテレメトリーの収集や、Infrastructure as Codeによる設定のコード化、ポストモーテムの整備などが挙げられていました。
一方、ガードレールはAIの失敗を予防・回復するための保険です。AIが生成したコードに存在しないライブラリが含まれるリスクへの対策としてのサプライチェーンセキュリティや、組織ポリシー違反を防ぐPolicy as Code、SLOに基づいた自動ロールバックなどが紹介されていました。
SRE自体がAI開発の文脈の中心にいる印象はあまりありませんが、AIが当たり前のように受け入れられ開発プロセスが成熟した今だからこそ、次のフェーズとしてSREを一連のデリバリーパイプラインに適切に組み込めるかどうかが今後の鍵になると実感しました。
SRE とプロダクトエンジニアは何故分断されてしまうのか
発表者: 渡邉美希パウラさん
ワンキャリアの渡邉美希パウラさんによる、SREチームとプロダクトチームの間に生じる「分断」の構造と解消アプローチについてのセッションでした。渡邉さん自身がSREチームからフロントエンドエンジニアへ異動した経験を持ち、両方の立場を知る当事者として語られていたのが印象的でした。
セッションでは、分断を引き起こす構造的要因として「受発注関係の固定化」「目指すベクトルのズレ」「1対多が生む情報の非対称性」の3つが挙げられていました。SREが横断的に複数プロダクトを担当する体制では、「パフォーマンス改善はSREの仕事」という意識が生まれやすく、受発注関係が固定化してしまう問題があります。また、プロダクトチームは「価値提供・スピード」、SREは「信頼性・安定」を重視するため、本来は同じユーザー起点であるはずなのに対立構造を生みやすいとも言えます。こうした分断は仲の良し悪しではなく、役割分担が生む必然的な帰結として整理されていました。私たちの組織にはSREこそいないものの、「過度な役割分担が心理的な壁になる」「受発注関係が固定化する」という現象はありありと想像できました。
解決アプローチとしては「バウンダリー・スパニング」- 境界を意図的になくし、人や情報を繋ぐことで価値を創造するというリーダーシップ理論を参考に、Reflecting（反射）、Mobilizing（結集）、Transforming（変形）という3つのステップで実践されていました。具体的には、インフラ変更のリポジトリをプロダクトチーム側に統合して境界線を排除したり、SLOを両チーム共通の評価指標として定例で議論したり、チーム間で人材を異動させたりといった施策が紹介されていました。
当事者として経験しながら、同時に観察者として構造を見抜いているような視点の鋭さに感銘を受けました。「足並みが揃いづらい」という課題感を、再現性のあるフレームワークで整理し、フェーズに分けてアクションを起こしていることも学び深い点でした。最後に「結局は全員が視座高くオーナーシップを持てば分断は問題にならない」と締められていましたが、シンプルながら本質を捉えた言葉であると感じ、自分自身も心がけていきたいと思いました。
開発チームが信頼性向上のためにできること: 医療SaaS企業を支える共通基盤の挑戦
発表者: kosuiさん
カケハシのkosuiさんによる、医療SaaS企業の認証権限基盤チームが信頼性向上に取り組んだ事例紹介でした。キーメッセージは「Embedded SRE不在でも、開発チームが設計を"自分ごと"として運用し続けることで信頼性は向上できる」というもので、自分たちの状況にも通じる内容でした。
医療SaaSは患者情報という極めて機密性の高いデータを扱うため、コンプライアンス、高可用性、トレーサビリティ、テナント分離といった厳しい品質要求があります。セッションでは、小規模チームがこれらの要求を満たすために採用した具体的な設計として、DBレベルでテナントを強制分離する行レベルセキュリティ（RLS）、過去データへの即座のアクセスを可能にするDelta Lakeのタイムトラベル機能、「何が起きたか」を完全に記録するドメインイベント、強い整合性と独立デプロイを両立するサービスベースアーキテクチャなど、詳細な設計内容が紹介されていました。これらの導入により、障害時の原因特定が2〜3時間から30分以内に短縮されるなど、具体的な成果も示されていました。
SREの役割や組織についてのセッションが多かった今回ですが、その中での具体的なアーキテクチャ設計の話は新鮮で聞き応えのあるものでした。ドメインごとに異なる品質要求を、限られた人的・時間的リソースの中でどう満たすか。その試行錯誤やトレードオフの判断は興味深く、同時に設計一つがプロダクトの今後を大きく左右する責任の重さも感じました。自分が設計に携わる際にも、SRE的な観点と「設計意図の浸透」を意識していきたいと思います。
おわりに
AI時代におけるSREの再定義、チーム間の分断を防ぐ組織設計、開発チーム自身が信頼性を担うアーキテクチャ設計と、切り口はそれぞれ異なりますが、共通して感じたのは「信頼性は誰かに任せるものではなく、自分ごととして向き合うもの」というメッセージでした。
SRE Kaigi 2026全体を通して、SREという領域の幅広さと奥深さを知ることができました。また、「受発注関係の固定化」「目指すベクトルのズレ」「情報の非対称性」といった構造的な課題感は他のセッションでも度々取り上げられており、多くの組織で共通していることを実感しました。
個人的には、山口さんのセッションで語られた「AIの爆発的な生産性を、カオスではなく、持続可能なユーザー価値へと変換する」という言葉が印象に残っています。開発速度の向上も、最終的にはユーザーへの安定した価値提供があってこそ意味を持つ。その視点を忘れずに、これからは開発ライフサイクル全体の改善にも寄与していきたいと感じました。
