以下の内容はhttps://tech.andpad.co.jp/entry/2026/02/10/100000より取得しました。


アンドパッドSRE/CRE/FinOpsメンバーによるSRE Kaigi 2026のおすすめセッション

こんにちは。FinOpsチームのテックリードの吉澤です。

アンドパッドのSRE/CRE/FinOpsチームのメンバーで、2026/1/31(土)に中野で開催されたSRE Kaigi 2026に参加してきました!

今回は、現地参加したメンバーによるおすすめセッションをご紹介します。これからSRE Kaigi 2026の内容を追う方は、ぜひ参考にしてみてください。

ちなみにイベントレポート第1弾として、私の一般セッションでの発表(予期せぬコストの急増を障害のように扱う)とその反響を以下の記事にまとめています。こちらもあわせてご覧ください。

tech.andpad.co.jp

現地参加したメンバーによるおすすめセッション

現地で直接聞いたセッションから、1人あたり数本に厳選して紹介文を書いてもらいました。その結果、アンドパッドメンバーのなかでは、以下の2つのセッションが特に好評でした!

見る人の専門性(SRE/CRE)や立場(マネージャー/メンバー)によって視点が異なるため、1セッション1紹介文に絞ることはせず、すべての紹介文を掲載します。

サービスプラットフォーム部部長 兼 SREチームマネージャー 角井のおすすめ

小さく始めるBCP ― 多プロダクト環境で始める最初の一歩(株式会社SmartHR 中間さん)

SmartHRさんの「小さく始めるBCP」は、BCP/DRの話を「壮大な設計論」ではなく「明日から動かせる一歩目」として捉え直してくれた点がとても印象的でした。4名のSREで40プロダクト・200名のエンジニアを支える体制の中、完璧なRTO/RPOを最初から定義するのではなく、いま無理なく実現できる最小限のDR戦略から始めるという割り切りは、現場感にあふれた実践知として腹落ちしました。

プロダクトごとに復旧の緊急度が異なる点(給与計算系とタレントマネジメント系では求められる復旧速度が違う)を言語化し、依存関係を可視化した上で開発者・ビジネスサイド双方からレビューを受けたというプロセスも、多プロダクト環境での役割分担の参考になりました。

技術面では、Google Cloud上でコールドスタンバイを採用し、terraform state pull で状態取得→復旧対象リソースの特定→手順書作成→検証環境での復旧試行、という流れで復旧時間の概算まで取得していた点が具体的で再現しやすいと感じました。訓練も「カオスエンジニアリングはしない」「関係各所との調整練習はしない」とスコープを明確に絞ることで、まず前に進むことを優先していたのが印象的です。

「事業を止めたくない」という思いと「コストやリソースには上限がある」という現実のトレードオフを、机上で議論し続けるのではなく、小さく始めて実測値と経験から解像度を上げていく姿勢は、SREの漸進的な改善文化にもよくフィットしていました。BCPを"特別な大プロジェクト"ではなく日々の信頼性向上の延長線上に位置づけていた点も、自分の現場に持ち帰りやすいポイントです。全体として、「BCPやらなきゃいけないのはわかっているけど重くて手を付けられない」という心理的ハードルを下げてくれる、SRE Kaigiらしい現場で試したくなるセッションでした。

レガシー共有バッチ基盤への挑戦 - SREドリブンなリアーキテクチャリングの取り組み(株式会社コドモン 小西さん)

レガシーな共有バッチ基盤に対して、SREチームが腰を据えて向き合うストーリーが、とても現場感のある内容でした。「秘伝サーバー」をいきなり置き換えるのではなく、実環境からの情報収集や過去のアラート履歴の棚卸し、AIを活用した処理内容の理解、複数チームへのヒアリングから始める進め方が、非常に丁寧で良かったです。

技術選定の軸として「シンプルさ」と「認知負荷の軽減」を明示し、マネージドサービスを活用して独自実装を最小限にする判断が印象的でした。単なるモダナイズではなく、「作った人しか仕様がわからない状況」の再発防止を重視しているのが伝わってきました。

弊社でも2023年に同様のバッチサーバ廃止に取り組んでおり(参考:データパッチ環境と有事の際のログイン環境をサーバレス化・コンテナ化した取り組み)、関係者へのヒアリングや要件定義の丁寧さが成功の鍵だった点が共通していて、強く共感できました。

「レガシーだから無理」と諦めるのではなく、現状理解とシンプルな再設計を積み重ねれば改善できるというメッセージに勇気づけられた方が多かったのではないでしょうか。SREチームが組織横断でレガシー基盤をリアーキテクティングしていく好例として、参考になる良い事例でした。

SREチーム 千明のおすすめ

生成AI時代にこそ求められるSRE(アマゾンウェブサービスジャパン合同会社 山口さん)

現在、業務に欠かせなくなった生成AIに対してSREとして求められることはなにかについてのセッションでした。主にコンテキストの収集とガードレールの強化の2点に分けて解説されていました。

まずコンテキストについては、私たちも日頃から収集できていて、Datadogへのメトリクス集約、Terraformを用いたIaC整備、ポストモーテム作成など活用できるデータは数多くあります。ただ、これらのコンテキストをうまく活用できていないのも事実で、これらのデータをどうAIに活用させていくかが今後の課題になると感じました。

また、AIを使う上でガードレールを適切に設定する大事さも解説されていて、昨今サプライチェーン攻撃などが増えている中で、AIを安全に活用するためのポイントが整理されていて参考になりました。

SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル(イオンスマートテクノロジー株式会社 久保さん、川田さん)

前半はインフラエンジニアがSREチームにジョインしていく内容で、後半はフロントエンド開発チームがモニタリングをSREから巻き取る内容のセッションでした。

前半の話は採用の話としても学ぶことが多く、オンボーディングの方法やモブワークを通して業務に慣らしていく方法など、今後弊社でも人員拡大を考える上で参考になりそうな内容だと感じました。

また後半に関しても、開発チームが主体的にモニタリングを活用できるようにしていくための実例として参考になりました。弊社でもDatadogでダッシュボードを作成していますが、習慣的に眺めて負荷やコスト増を事前に把握するのには使えていないので、是非参考にしたいと思いました。

SREチーム 谷合のおすすめ

IaaS/SaaS管理におけるSREの実践(株式会社MIXI 多羽田さん)

弊社でも「強い権限を持つ管理者」に依頼が集中し、管理者(人数の少ないSRE)の作業待ちになってしまうことがあります。このセッションはこういった課題に対して、SREがどのように効率化したかを紹介しており、大変参考になりました。

解決アプローチは「申請」から「Pull Request」に変えることで、InterfaceをGitHubに統一し、SREの負荷を下げるというものでした。これは弊社でも似たようなアプローチをとっており、非常に共感できました。また、以前アカウント申請の自動化を検討した際に、コードの自動生成を目指したことがありましたが、現状の運用でも誤りではないと再認識できました。

さらにAWS Identity Center(現AWS SSO)を利用して、SaaSの権限管理を一元化している点も参考になりました。弊社もIAMユーザーからAWS Identity Centerに移行中で、SSOやPermission SetのTerraform管理は導入済みです。方向性は合っているんだなーと答え合わせできました。

MIXIではプロダクトごとにProjectを切っており、そのディレクトリごとにCODEOWNERを設定している点も参考になりました。将来的にCODEOWNERを活用して、SREはApplyするだけの世界線が来ると良いなと思いました。

また、退職者を自動検知してPRを作成するBotは面白いなと思いましたし、ぜひ実装してみたいと思いました。

最後にこの図が非常に刺さりました。

CREチーム 島根のおすすめ

小さく始めるBCP ― 多プロダクト環境で始める最初の一歩(株式会社SmartHR 中間さん)

発表はSREが主導して事業継続計画をスモールスタートで始めていった経緯と実際に取り組んだ上での気づきという内容でした。同社ではもともと事業継続計画には取り組んでいたものの、社として今後はプロダクトを社会インフラにしていくことを目指していくという目標に併せてSREチームがリードしていくことになったとのこと。

アンドパッドもプラットフォームになることを目指しているので、背景が似ていると感じました。また、課題に直面しながらも、これまでのプロダクト開発を参考にしながら前進するという考え方は、弊社でも参考にできそうです。

SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル(イオンスマートテクノロジー株式会社 久保さん、川田さん)

発表は別の会社で異なるロールを担っていたところからイオンスマートテクノロジーのSREになって取り組んできたことや文化などについて紹介されている内容でした。

弊社も幸いなことに新しいメンバーがたくさん参画して頂く機会が多くありますが、新しく参画されたメンバーからフィードバックを受ける機会はあまり多くありません。この発表ではオンボーディングを受けた川田さんの所感を交えながら、同社が実施しているオンボーディングプログラムや文化を客観的に紹介されており、参考になりました。

特に、何から始めれば良いかをまとめているアクションアイテムを「クエスト」という形式で一つずつこなすことで、終わった時には独り立ちできているという仕組みには工夫を感じました。

FinOpsチームテックリード 吉澤のおすすめ

コスト削減から「セキュリティと利便性」を担うプラットフォームへ、Sansanの認証基盤のこれまでとこれから(Sansan株式会社 樋口さん)

Sansanで、Bill Oneの認証基盤の内製化に携わった樋口さんによる講演。現在はチームごとPlatform Engineering Unitに異動されて、認証基盤の全社統一を進められています。

Bill Oneでは、認証基盤としてAuth0を利用していました。しかし、Auth0のMAU単価の高さ、およびBill Oneのサービス特性(ユーザー数課金ではない)とのミスマッチから、他のIDaaS(Amazon Cognito)に移行し、足りない機能は自前開発で補うという方針決定をされたそうです。

講演では、移行先にAmazon Cognitoを選定した理由や、移行に伴うユーザー影響を最小化するための工夫などが詳しく解説されており、非常に参考になりました。システム面では、AWSのサーバーレス製品(ECS Fargate、Aurora Serverless、ElastiCache Serverless)の積極採用や、導入後のパフォーマンスチューニングの話が興味深かったです。

認知負荷を最小化するオブザーバビリティとSLOの導入 ―4名のSREが200名のプロダクトエンジニアを支援(株式会社SmartHR 樋口さん)

SmartHRのSRE樋口さんによる講演。Room Aが満員になっており、注目度の高さを感じました。

講演の前半はSmartHRのSREチームの立ち位置やロードマップ策定の話、後半はSLOにフォーカスした話でした。私は特に後者の話を興味深く聞きました。

SmartHRでは現在16の開発チームがNew RelicでのSLO運用をしている一方、SREチームは4名。SREが個別対応しなくても運用が回るようにするための施策として、IaC(Terraform)によるダッシュボードの自動設定、共通モジュールを活用した設定の簡素化、CUJからSLI/SLOを導き出すためのワークショップ、SLO星取表などが紹介されました。

マルチプロダクト戦略を取っている点はアンドパッドも共通しているため、今後SLO運用を改善する際の参考になりそうです。

SRE Kaigi 2026全体を通しての感想

SRE Kaigiは昨年が初開催で、今年は2回目でした。初開催が大成功して、一般セッション・スポンサーともに競争率が高かったためか、昨年よりますますクオリティが上がっていると感じました(弊社もスポンサー落選しました。来年こそ……)。

セッションの内容としては、現場での実践に基づく、具体的な内容のものが多かった印象です。また、上でご紹介したセッションは、具体的な話をするだけでなく、うまくナレッジに昇華されていました。そのため、自分が関わっている業務に関係するものは刺さりましたし、そうでないものも「似た業務をすることになったら参考のために見返そう」と思えるクオリティの高いものでした。

それと、"Challenge SRE!" というSRE Kaigi 2026のテーマをスライドにキレイに織り込んでいる人が多かったです(自分の番まで他の人の発表を聞いていて「あっマズい」と慌てました)

弊社の実践もこのような場で発信していくために、引き続き社内でプロポーザルのネタ出し会やレビュー会などを実施し、底上げに励んでいきたいと思いました。

最後に、このような貴重な機会を提供してくれた、SRE Kaigi 2026のすべてのスタッフ、スポンサー、関係者の皆様に御礼申し上げます。いつもありがとうございます!

We are hiring!

アンドパッドでは、「幸せを築く人を、幸せに。」というミッションの実現のため、一緒に働く仲間を大募集しています。アンドパッドのマルチプロダクト戦略を支えるSRE、CRE、FinOpsなどの組織横断チームにご興味がありましたら、以下のページからご応募ください。カジュアル面談も実施しています。

hrmos.co

hrmos.co




以上の内容はhttps://tech.andpad.co.jp/entry/2026/02/10/100000より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14