はじめに
オイシックス・ラ・大地は 7/11-12 に開催された SRE NEXT 2025 でSilver スポンサーとして協賛してきました！
今年のテーマ「Talk NEXT」の通り、たくさんの参加者の皆様とお話しする機会を得られ、大変有意義でした。
参加メンバーが当日のブースやセッションについて報告いたします。
ブース紹介
ブースにはいつもの野菜ジュース・フルーツジュースに加え、Oisix商品の本物のお野菜も展示していました。テックイベントらしからぬ第一次産業味が溢れる展示で異彩を放っておりましたが、逆に興味を持ってくださった方がたくさんいらっしゃいました。
スポンサー協賛の予告ブログ1でもご紹介したチラシも反響が大きかったようで、「SRE憲章真似してみたい！」や、「25年モノのシステムなのにモダン！」というお声を多数いただきました。
参加メンバーの感想
三木
ブース担当として参加しました。（セッション未参加）
出展側としてはスタンプラリー企画がありがたかったです。過去のイベントでよく見かけた「声掛けに戸惑うシーン」が（他社さん含め）今回はほとんど見られず、自然な会話のきっかけになっていたと感じます。
意外だったのは、思っていたより各社さん生成 AI 系の取り組みについての言及が少なかったこと。とはいえ、信頼性の向上にも生成 AI を活用することは今後避けて通れない道なので、各社がどうアプローチしていくのか、来年のSRE NEXTが非常に楽しみです。きっと大きく様変わりしていることでしょう。
そして何より、マスコットキャラの「けろぺん」がめちゃめちゃ可愛い！！ノベルティも可愛いし、参加してよかったと心から思いました。ぬいぐるみの物販があったら迷わず買ってましたね。かわいい。あとノベルティでけろぺん柄の洗濯ネットを頂いたのですが、このチョイスも嬉しい！我が家でも大活躍です。 本当に「けろぺん」が可愛くてよかった。
髙木 (@ken_tkg10)
SRE NEXTに現地参加するのは今回が初めてでした。 ブースを担当しつつ空いている時間にセッションやスポンサーブースを周り、SRE界隈の盛り上がりを肌で感じました。
いくつかのセッションやスポンサーブースの話を聞いて、SREが組織の境界を超えて開発者や事業の課題を解決しながら信頼性を高める動きを行い、SREのプラクティスやカルチャーを浸透させることが重要であると改めて実感しました。 書籍『SLO サービスレベル目標』に書いている「信頼性は会話です。」という言葉を思い出しました。 AIの時代であっても、人と人が会話・対話をしながら信頼性目標を定め、信頼性目標の達成に向けて動かなければならないと考えました。
気になったセッション1つだけについて感想を書きます。
SRE へのサポートケースをAIに管理させる方法
Ubieが直面したSREへの問い合わせ件数が多いことによる業務負荷をSlack Bot + 内製Webアプリ + AIで軽減する事例でした。
弊社もSREへの問い合わせ件数が多く、「コンテキストスイッチが多い」「緊急度が低いが重要度が高いタスクになかなか取り組めない」といった課題を抱えています。課題解決のための参考になればと思い聴講しました。
問い合わせの一時回答をAIに任せ、定型的な問い合わせはAIが提示したドキュメントで解決させる取り組みを、ドキュメント整備と併せてぜひ真似したいと思いました。 一方で、チケット管理のWebアプリケーションを内製して運用するのはなかなかハードルが高そうです。この辺りはすでに利用しているチケット管理SaaSでいい感じにできると嬉しいです。
簡単な問い合わせが減ったら難しい問い合わせが増え、問い合わせにかかる工数がむしろ増えたという結末には笑ってしまいました。 とはいえ、本質的な課題に取り組める時間が増えるのは素晴らしいことですね。
懇親会
懇親会には非常に多くの方が参加していました。 美味しい食事やFindy様の開発生産性IPA、かわいいけろぺんラベルのビールなどの美味しいお酒を飲みながら色々な方と会話でき、大変楽しい場でした。 来年も懇親会まで参加したいです！
子安 (@koyapig)
SREの子安です。5年ぶりにSRE Nextに参加しました！私視点での感想を書かせていただきます。
実は前回（SRE Next 2020）参加した時もスポンサーとして協賛しておりブースも出展していました。その時と比べるとブース自体のクオリティも上がっており、なによりSREの取り組みなどを記載したチラシをSRE Next用に作成したことで、お手に取っていただけた方にオイシックス・ラ・大地のSREについて少しは知っていただけたと思います。
私もブース側に長くいたことであまりセッションを聞けなかったのですが、1件だけ感想を書かせていただきます。
ロールが細分化された組織でSREは何をするか？
KINTOテクノロジーズ株式会社 長内さんのセッションです。
このセッションでは、ロール（専門チーム）が細分化されたことでSREの立ち位置や曖昧になっていく中で、どのような価値を提案していったのかが知ることで大変参考になる内容でした。
「SRE = 何でも屋」はどこの企業も課題としてあるのではないでしょうか。そこでVsionである「サービスレベルに基づいた開発と運用のバランスが取れた組織を実現」に立ち返り、Observabilityの向上の事例を発表されてました。
New Relicを導入し、メトリクス・ログ・トレースを統合し、さらにSlack連携でトレース情報を取得できる仕組みを構築することでスキルに依存せず確認できる仕組みは我々を実践できないか考えてみたいです。
その場の対応やツールの導入するのではなく、Visionに照らして「何をやるのか」「どこに価値があるのか」を考えながら行動している姿勢は非常に学びの時間になりました。
ミカエル
SREのミカエルです！ブース担当としてSRE NEXTに参加しました。今回はセッションに参加できなかったのですが、次回は絶対に参加したいです！
Oisixのこと、メインの事業ではなく野球のスポンサーで知ってくれている人が多かったのに驚きました！この戦略は効果を上げているようですね。
また、業界の人たちと直接話せたことは、非常に貴重な経験でした。他社がどんな課題に直面し、どのように解決しているのかを聞くことができ、最高でした。
私にとって日本でこのようなイベントに参加するのは初めてでしたが、日本のSREコミュニティの熱気を肌で感じることができました。このような素晴らしいコミュニティの一員として、今後も積極的に関わっていきたいです！
石田
バックエンドエンジニアの石田です。SREメンバーに混ざってブース担当としてSRE NEXTに初参加しました。 ブースには想像以上に多くの方に足を運んでいただき、弊社のSREの活動や取り組みを知っていただくとともに、参加者や他のスポンサーの方との会話を通じて多くの気づきを得られた貴重な一日となりました。
普段はバックエンドエンジニアとして業務を行っていますが、サービスの信頼性を維持しつつ、開発速度を最大化していくためには、SREチームに任せきりにするのではなく、私たち開発チーム自身が「信頼性」を責任の一部として捉え、対話を通じて相互理解を深めていく必要があることを改めて実感しました。
会場内にあったアンケートボードの「Q6（SRE本読んでいる？）」ではO'Reilly Japanの『SRE サイトリライアビリティエンジニアリング』がやはり圧倒的多数でした。今回のイベント参加をきっかけに、バイブルとも言われるSRE本をぜひ読破して、SREのプラクティスや思想への解像度を高めて日々の業務に活かしていきたいと思います！
青木
SREの青木です。実はスポンサーの応募申し込みから私が担当しました！ いつも通りに野菜ジュースのタワーを作ったら間違いなく目を引くんだけど、そこからどうやったらオイシックスのSREの活動に興味を持ってもらえるんだろうか、ということを考えて展示物（といっても主にチラシ）を決めました！
これまで協賛したテックカンファレンスで配布していたチラシでは、どちらかというとオイシックス・ラ・大地の事業紹介や採用宣伝にフォーカスした内容が多かったのですが、 弊社オリジナルのSREの活動や、システムのモダナイゼーションに取り組んでいることを知っていただきたいという思いから、SRE憲章やアーキテクチャ図を掲載してみました。 他社さんと比べると手作り感が強めでしたが、上でも記載した通りたくさんの方に興味を持っていただきました。
レビューしてくれたメンバーのみなさん、アーキテクチャ図を作ってくれた高木さん、ありがとうございました！ そして、お野菜やジュース、ステッカーの手配や展示物の相談に乗ってくれたHRの小川さんにも大変感謝しております！
当日聴講した中で印象に残ったセッションを2件ご紹介します。
アクセスピークを制するオートスケール再設計: 障害を乗り越えKEDAで実現したリソース管理の最適化
マネーフォワードさんのオンプレミス環境からAWSのEKS環境に移行した際の障害に関するセッションでした。
CPUの使用率を閾値にしたHPAによるオートスケーリングを設定し備えていたものの、移行後の初めてのアクセスピーク時、オートスケールが発動せず、レスポンス遅延や5xxエラーが頻発する障害が発生してしまったそうです。
HPAによるオートスケールが発動しなかった原因としては、アクセス数は増加していたもののCPU使用率は閾値を超えていなかったためででした。対策としてイベントトリガー型のオートスケーリングKEDA (Kubernetes Event-driven Autoscaling) 2を採用されていました。
KEDAでは、Kubernetes上でイベント駆動のオートスケーリングを実現することができます。Kubernetes標準のメトリクスだけでなく、様々な外部イベント、メトリクスをトリガーにオートスケールすることが可能です。 外部イベントやメトリクスを監視し、スケーリングを判断するものをKEDAではScalerと呼ぶのですが、KEDAがサポートしているScalerは執筆時点（2025/07/17）では74個ありました。 マネーフォワードさんのセッションではDatadogのScalerを活用し、Datadogでモニタリングしているリクエスト数に応じてオートスケール仕組みを導入されたそうです。
お恥ずかしながらKEDAの存在をこのセッションで初めて知りました。弊社でもDatadogでモニタリングしているメトリクスと連動してオートスケールさせたい場面がありますので、これを機に検証してみたいなと思いました。
SREの次のキャリアの道しるべ 〜SREがマネジメントレイヤーに挑戦して、気づいたこととTips〜
ココナラ川崎さんによるSREのキャリアに関するセッションです。
私はこの会社で約6年SREという立場でエンジニアをしていますが、不得意な領域はありつつも、おかげさまで業務の守備範囲をかなり広げることができました。 ただ、一組織の中である程度守備範囲を広げたその先はどこに向かっていったらいいんだろうという悩みがぼんやりとあり、セッションを聴きに行きました。
結論、「SREのプラクティスは汎用性があり、他の領域にも活かすことができる」という、考えてみれば納得の気づきが得られました！
SREのプラクティス確かに汎用性ある。エンジニアリングに限らず活かせるといいな #srenext
— あおきめ (@meimei_aa428) 2025年7月12日
川崎さんのキャリアを例に、マネジメントレイヤーとSREを比較してみると、共通点があります。 例えば、エラーバジェットの考え方は、経営判断のリスクを数値化することで、どのくらいチャレンジできる幅があるのか、という経営視点の考え方に置き換えることができます。 また、SLI/SLOの設定は、経営面だと売上/売上目標などの経営指標そのものがSLI/SLOになるので、定期的にモニタリングし未達成であれば改善する、という行為はSREプラクティスそのものです。
次の一歩を決められなかったり踏み出せなかったりする時は、SREプラクティスを活かしてチャレンジできるだけの経験はある（はず...）ことを思い出すと自信につながるのかもしれないなぁ、と思いました。
まとめ
大変学びや刺激の多い二日間でした。得られた知見は社内で活かし、来年はみんなでCfPを出してさらに盛り上げていきたいと思います。
スピーカー、参加者、スポンサー、そしてSRE NEXT運営の皆さま、素晴らしいカンファレンスを開催してくださりありがとうございました！
イベント開催します！ 🥳
最後に重要なお知らせですが、7/24 (木) にオイシックス・ラ・大地本社のキッチンにてSREのイベントを開催します！
なんとPlatform Engineering界で著名な jacopenさんにご講演いただきます！！
講演タイトル：SRE or Platform Engineer - エンジニアとしてどちらを選ぶか
講演概要：
SRE NEXT 2025のエスカレーター近くにあったアンケート、覚えていますか？ そこには興味深い結果がありました。参加者のうち、Platform Engineeringに携わる人が最多勢力だったのです。
この分野が注目されるようになって約3年。最近は業種業態問わず、取り組んでいる会社が増えてきました。エンジニアとしてのキャリアを考えるとき、SREとPlatform Engineer、どちらを選べば良いのでしょうか？ そもそもその2つはどう違い、どう関係するのでしょうか。
本セッションでは、SRE NEXTを振り返りながらこの2つの考え方について解説したいと思います。
そしてSRE NEXT 2025で登壇され、かつオイシックス・ラ・大地の卒業生でもあるもりはやさん、tomoさんにもLT参戦いただきます！奮ってご参加ください 🙌
- 日時：7/24 (木) 19:00開場、19:30開始
- 場所：オイシックス・ラ・大地 大崎本社 1F Kitchen Studio
- とってもわかりやすいアクセス方法はこちら
-
オイシックス・ラ・大地はSRE NEXT 2025にSilverスポンサーとして協賛します
creators.oisixradaichi.co.jp↩ -
KEDA (Kubernetes Event-driven Autoscaling)
keda.sh↩
