SRE NEXT 2026イベントレポート②～セッションレポート編～
SRE NEXT 2026のセッションレポートです！
第二回レポートは、SRE NEXTに参加した弊社のクラウドインフラチームの菊地、中原、金子の3名が、印象的だったセッションをいくつかピックアップしてご紹介します。
＼ 前回の記事はこちら ／
インフラチームメンバーのご紹介
各セッションのご紹介
⭐菊地セレクト
①パネルディスカッション：SREの未来予想図：スペシャリスト、マネジメント、外部支援──3つの視点から紐解くエンジニアの成長戦略
弊社の技術顧問を担当している藤原さんが登壇されたパネルディスカッションでした。
自分達が普段からサービスの運用業務の一貫で取り組んでいたことに対して、気がついたらSREというラベルが貼られるようになったということを語られていました。
藤原さんには普段からお世話になっているので、藤原さんの考えるSREの未来について聞けたのはとても嬉しいポイントでした。
②インフラ寄りSREでも開発に踏み出せる 〜境界を越えてユーザー体験に向き合いたい〜
登壇者：じょーしさん（Sansan株式会社）
インフラ寄りのキャリアを歩んできたじょーしさんが、SREチームから開発チームへの異動に挑戦した話です。
個人学習やマネージャへの働きかけを重ね、念願の異動を実現したじょーしさん。開発現場でもインフラ経験やAI活用が武器になったそうです。
新しいことに挑戦するには、日頃の信頼貯金が大切だと実感しました。
実は、前回開催されたSRE NEXTでもこの登壇者の方のセッションを視聴していました。前回は、インフラ中心のキャリアだったじょーしさんが、バックエンドエンジニアとして開発チームにジョインされたお話でした。
その後どのような変化が起きていたのか気になっていたのですが、インフラからアプリケーションに越境していく取り組みを密かに応援していました。
私はその逆でバックエンドエンジニアからクラウドエンジニアにキャリアを変更したのですが、じょーしさんと同じく技術領域の越境という点では共通点があり、新しい分野へ挑戦していく大変さにとても共感しました。
③Terraform CI/CDに潜む権限昇格リスクと対策〜金融システムにおける権限分離と制御事例〜
登壇者：a_bickyさん（株式会社Datachain）
Terraform CI/CDではworkflowの改変などでtokenやsecretが抜かれるリスクがあり、その対策としてAtlantisを採用し、planとapplyを別Virtual machine・別権限で運用しているというお話でした。
「Secrets Managerと、パラメータストア管理のベストプラクティスって何だ？🤔」と疑問に思いながら日々の業務を進めていたので、他社がどうしているか以前から気になっていました。
本セクションでは、Secrets Managerとパラメータストアの使い分けにも触れられており、気になっていたことが知れたので大変参考になりました。
普段から気をつけていることはもちろん、SREでも常に強い権限を与えるべきではないという視点は抜けていたので大変学びになりました。
④Terraform共通モジュールをチーム横断で”変えられる”運用へ - リリースと運用の分離
登壇者： 中間 啓介さん（株式会社SmartHR）
約40のプロダクトチームを抱えるSmartHRで、SREチームが整備するTerraform共通モジュールの運用課題に関するお話でした。
共通モジュールは環境複製に便利な反面、チームごとの柔軟なカスタマイズが難しくなるという課題があり、その解決策としてtfactionによるバージョン管理を紹介されていました。
Terraformの共通モジュールの運用は複数の同じ環境を複製するのにとても便利ではありますが、逆に細かい変更に柔軟性を持たせることが難しくなるという側面があります。それをどのように他社が活用しているのかが気になりましたが、tfactionでterraformのソースコードをバージョニング管理することができるということを初めて知り、目から鱗でした。
この機能を活用することでベース部分は基本同じでも、自チームに取って扱いやすいようにコードをカスタマイズすることができるのは便利だと思いました。
🌱中原セレクト
①AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用
登壇者：OJIさん（GMO Flatt Security株式会社）
セキュリティ特化のAIエージェント「Takumi」の実行基盤として、KVMベースの仮想化基盤「Sunaba（すなば）」をフルスクラッチで内製した話でした。
なぜ内製したのか
コンテナでは隔離が不十分、かといってVMの常時起動はコスト高。「欲しいときに欲しいだけVMを秒で生成し、不要になれば即殺す」という理想を求めてフルスクラッチ開発。
Sunabaの中身
ハイパーバイザーはFirecracker。VM起動は約5秒、ピーク時は週約100万VMを処理。CoWでRead-Only層をVM間で共有し、容量削減と起動高速化を両立。
VMがリクエストから約5秒で立ち上がるという数値がとても印象的でした。聴講中は自社オンプレかと思っていたのですが、実体はGCEインスタンスの集合、つまりクラウドの上にさらに自前の仮想化レイヤーを積む構成でした。要件に合うものがないなら作る、という判断を本当にやり切ってしまう割り切りの良さが面白かったです。
国内では採用事例がまだ公開されていないFirecrackerを、先行事例なしで運用しているくだりにも驚かされました。「欲しいときに欲しいだけVMを用意し、不要になれば即削除する」という要件をここまで突き詰め、CoWでRead-Only層を共有して容量削減と起動高速化を両立させ、さらにVMPoolのDrain機構までも自作するという、運用の細部まで作り込む徹底ぶりに、同じインフラに携わる者として大いに刺激を受けました。
②ポストモーテム！DDoSからサイトは守れた。でもビジネスは守れなかった。
登壇者：原口 慎太郎さん（弁護士ドットコム株式会社）
法律相談ポータルが実際にDDoS攻撃を受けた経験のポストモーテムです。
サイトは守れた、コストは守れなかった
リクエストは平常時の20万倍。WAFがブロックしダウンタイムはゼロだったが、従量課金が災いしインフラコストは約40倍に。可用性に加えて費用も狙う「EDoS」でもあった。
見逃した原因と対策
攻撃初日の日次アラートが月次アラートと金額が近く、「月末のいつもの通知」と思い込んで見落としてしまった（区別のつきにくい通知設計そのものにも一因があった）。対策として、最終手段の「サイトを落とす決断」についてしきい値・手順・決定権まで事前に取り決めた。
サイトが落ちたときのルールはあっても「コスト急増時のルール」は果たしてあるのか？という問いが特に印象に残りました。
可用性は守れても、事業に響きかねないほどのコスト増という別の被害があり得ると気づかされたのは大きな収穫です。
「無意味なアラートは無視される」というくだりも他人事にはできず、自分たちの予算アラートやコスト急増時の対応ルールが形骸化していないか、改めて見直すきっかけになりました。未然に防いだ成果は数字にしないと伝わりにくい、という指摘も社内で活かせそうな観点だなと思いました。
🌸金子セレクト
①生成AIに「技術」を任せ、「非技術」で仲間を集める〜一人目SREが採用・組織化を最大化した軌跡〜
登壇者： 長野太一さん（クロスマート株式会社）
一人目SREとして生成AIを活用しながらインフラ課題の解決と採用・組織づくりを同時に推進した、というセッションでした。
技術的負債よりも「心理的負債」の方が根深いという話から始まり、
「動いているものを壊したらどうしよう」という恐怖からなかなか問いを立てられない壁を、生成AIとの壁打ちで突破していったという内容です。
運用や保守に関わったことがある人なら、この「気後れ」は誰しも経験があるのではないでしょうか。
私自身も既存環境に対して疑問を持ちつつ口に出せなかった経験があり、非常に共感しました。
AIの出力を後追いで検証するステップを踏むことで自分自身の理解が深まり、「わからなくても前進できる」という自信が生まれたという流れには説得力がありました。
特に、AIとのやりとりが自然とドキュメントになりチーム全体の「地図」になったという点は、散らかった一次情報の整理にいつも苦労している身として、ぜひ取り入れたいアプローチです。
最後の「改修しきれず課題が残っても、それは"活躍の余白"」という言葉も強く印象に残りました。
全てを一人で解決するのではなく、次の仲間が活躍できる環境を整えることこそが一人目SREの役割なのだと感じました。
②SREプラクティスを複数のプロダクト・組織で自律的に回し続けるための仕組みづくり
登壇者：手崎さん（KINTOテクノロジーズ株式会社）
複数プロダクトを横断してSREプラクティスを展開・定着させるための段階的アプローチと、その先にあるAgent活用の構想についてのセッションでした。
モニタリング導入から始まり、「導入しただけでは使われない」壁を定期MTGや日次定例でのダッシュボード共有で乗り越え、組織横断型Enablingの限界からEmbedded SREへ移行、さらにそのスケール限界をAgentで超えるという段階が語られました。
「導入しただけで満足」してしまうパターンは自分の経験でも心当たりがあり、地道に使い続ける仕組みを作る重要性を改めて感じました。
特に興味深かったのはSRE Agentの位置づけです。
単なる運用自動化ではなく、デプロイ後の状況変化の監視やポストモーテム文化の浸透といったEnabling活動そのものを推進するAgentという構想でした。
聞けば答えるだけでなく自ら関与し続けチームに影響を与えるという発想は、人のスケール限界を仕組みで超えるSREらしいアプローチだと感じました。
一度構築して終わりではなく日々の運用として定着するまで推進し続けるという姿勢も、繰り返し見える形で実施してこそ定着するという点で、自分の業務にも通じる学びでした。
③一人目専任SREの立ち上げを加速する ― AIと進めたオンボーディングで2分を0.04秒にした話
登壇者： 星野裕紀さん（株式会社PKSHA Technology）
一人目の専任SREとしてチームに参加した星野さんが、AIを活用してオンボーディングを加速し、レイテンシー2分→0.04秒という成果に繋げたセッションでした。
Embedded SREに必要な4種類のコンテキストを整理した上で、社内知識の「ありか」にAIが接続された環境を活かし、AIで解像度を先に上げてから人には「判断」だけを聞くというアプローチが紹介されました。
慣れた環境がパフォーマンスを下支えしてくれていたという気づきには非常に共感しました。
新しい環境で感じる不安の正体はコンテキストの欠如なのだと腑に落ちます。
特に印象的だったのはSlack上でのDevin活用で、他メンバーのプロンプトと対話の流れが全員に見える仕組みです。
質問の型そのものが暗黙知であり、先輩の聞き方がログとして残ることで生きたオンボーディング教材になるという発想は目から鱗でした。
AIで事実の切り分けまでを行い人には判断だけを聞くアプローチは、同僚の時間を最大限活かす非常に効率的な方法だと感じました。
「一人目でも、一人で戦う必要はない」というメッセージが心に残るセッションでした。
おわりに
今回参加したセッションに共通していたのは、AIを単なる効率化ツールとしてではなく、「人の力を拡張する相棒」として活用しているという点でした。
心理的な壁を乗り越える壁打ち相手として、複数プロダクトへのSREプラクティス展開を担うAgentとして、そしてオンボーディングを加速する探索インターフェースとして、それぞれ異なるアプローチながら、AIとの協働が人間的な貢献や組織の成長に繋がっていく姿が見えたカンファレンスでした。
カヤックボンドのインフラチームメンバーでカンファレンスに参加しましたが、それぞれが学びを持ち帰り、他社の取り組みやノウハウを知れたことで、普段の業務取り入れられそうなことや、改善できそうなポイントが話し合えたのはとても良い機会となりました。
チームとして、とても刺激を受けたカンファレンスとなり、また来年も参加したいなと思いました。
＼ この記事を書いたひと ／
＼ カヤックボンドでは一緒に働く仲間を募集しています ／
