はじめに
トラストバンク SREグループの @kgkukoaoisi です。
2026/01/31開催のSRE Kaigi 2026にオフラインで参加したので、メモや感想をまとめます。
参加したセッション
※（）内は個人の感想
生成AI時代にこそ求められるSRE
- AIがコードを書く時代にSREは不要になるのか？
- SREの重要性は、かつてないほど高まっている
- AIの爆発的な生産性をユーザ価値へと変換する際の信頼性を担保するため
- （どんなにAIがコードを生産してもプロダクトにデプロイできるレベルでないと価値提供はできないな）
- SREの重要性は、かつてないほど高まっている
- SREがもたらす価値をコンテキストとガードレールという観点で考える
- コンテキスト: AIの精度を上げるための下地
- AIは一般的なことしか知らないのでどれだけシステム固有の情報を準備できるか
- 例: テレメトリー、IaC、インフラ構成図、ポストモーテムなど
- （ドキュメントをどこでどう保存するか、悩み中...）
- ガードレール: AIの失敗を防御・フォローするための仕組み
- ハルシネーションやバグ、脆弱性を含むコードのリリースを仕組みで防ぐ
- 例: CI/CDでのテスト、Policy as Code、カナリアリリース
- （AIが何をやってはダメかを定義して、その中で自由にやってもらった方が効率いいのはイメージできる）
- コンテキスト: AIの精度を上げるための下地
ゼロからはじめるSRE：一人運用から複数プロダクト・SREチーム立ち上げまでの軌跡
- さくらのクラウド -> AWSへの移行
- インフラ移行のメリットってなかなか経営層に伝わりにくい
- 狙い
- インフラ＋セキュリティ対応の属人化を脱却
- 運用負荷を軽減したい
- モダンな技術採用による採用力アップ
- 理想を追い過ぎて身の丈に合わない技術選定もあった
- インフラ＋セキュリティ対応の属人化を脱却
- スピード重視でAWSに持って行った
- その他
- SLI/SLOを定義＆異常検知する仕組みを導入
- AWSセキュリティ成熟度モデルをもとに半期ごと振り返りとやること決め
- SREはガードレール設計者へ
SREが向き合う大規模リアーキテクチャ〜信頼性とアジリティの両立〜
- 課題
- バッチの機能追加や改修が大変
- テーブル定義に引っ張られている部分もある
- バッチの機能追加や改修が大変
- 解決策
- テーブル設計から見直して運用しやすいようにした
- 工夫
- インシデントは起こる想定で考える
- 新旧のバッチが並行稼働できるように設計
- 新バッチがこけてもサービス影響がないようにした
- 本番環境に反映してわかることもあり、並行稼働期間でバグを潰した
- プロダクトの性質上バッチにSLOを設けた
- CUJがバッチになることもある
- （画面とかAPIが多いイメージだけど、バッチもCUJになるのは勉強になった）
- CUJがバッチになることもある
- バッチをdry run実行できるようにしてデータ不備やパフォーマンス悪化を検知
- トランザクション貼って、rollbackするイメージ
- インシデントは起こる想定で考える
小さく始めるBCP ― 多プロダクト環境で始める最初の一歩
- BCP (Business Continuity Plan：事業継続計画)
- 緊急事態が起きても、事業を継続できるようにあらかじめ立てておく計画のこと
- プロダクトの信頼性を高めるという点でSREチーム中心に取り組んでいる
- 課題
- 復旧目標の決めづらさ
- 災害時のユーザからの期待値や災害頻度を把握できない
- （準備にお金かけたり、すぐ復旧してもそれがユーザ価値につながらないと意味ないよね）
- プロダクトごとに異なる復旧レベル
- すぐに復旧が必要なプロダクトとそうではないプロダクト
- SmartHRだと
- 勤怠管理、給与計算: すぐに復旧したい
- スキル管理、キャリア台帳: すぐ復旧しなくても大丈夫
- SmartHRだと
- すぐに復旧が必要なプロダクトとそうではないプロダクト
- 復旧目標の決めづらさ
- アプローチ
- 小さく始めてフィードバックを受けつつ、軌道修正する
- 不確実なものは完璧を求めず、現実的な復旧目標を定める
- 業務影響度とプロダクト間の依存度から復旧レベルを各々定める
- 開発者やビジネスサイドにもレビューをしてもらう
- 小さく始めてフィードバックを受けつつ、軌道修正する
- 計画に沿って訓練
- 小さく始めつつ、効果を得られる目的やスコープを定める
- 実際に手を動かして、見つかった課題を元に計画を修正
- 学び
- 最初から完璧を求めず、とりあえず始めてみる
- そこで見えてきた課題に対して継続的に改善していく
- （弊社SREチームでもBCPに取り組み始めたので勉強や共感の嵐）
レガシー共有バッチ基盤への挑戦 - SREドリブンなリアーキテクチャリングの取り組み
- Amazon Linux 2のEOLに向けて、SREが主導してバッチサーバをコンテナ化
- 影響範囲が広く重要度が高い一方で、ブラックボックスになりつつある
- まずは構成を把握して移行方針を立てることから
- インフラ構成だけでなく、アプリケーションも見る
- 全体を見て最適な方針を立てられる
- 開発チームとの関係性を築きやすい
- インフラ構成だけでなく、アプリケーションも見る
- アーキテクチャ選定
- 単純で理解しやすい構成へ
- マネージドサービスを活用
- 独自の作り込みが最小限
- 標準的な構成にすることで認知負荷がグッと減る
- （スライドには実践的なアーキテクチャ選定が載ってるので勉強になった）
- 単純で理解しやすい構成へ
- リリースに向けて
- 小さく早く失敗して、修正する
- CI/CD、監視周りは早めに運用
- 負荷試験による高負荷時の挙動確認
- 影響の少ないものから徐々に移行
- 小さく早く失敗して、修正する
チームを巻き込みエラーと向き合う技術
- 信頼性は会話
- 関係者間での対話により信頼性目標が決定し、実現のためのアクションが行われていく
- SRE拡大期の失敗
- アプリケーションの改修をSREも担当
- SRE内で議論やレビューが閉じることでコンテキストをSWEが認知できなくなった
- 仕組みを作っても、背景・意図・運用がSREに閉じていると他チームが手を出しにくい
- 属人化につながる
- アプリケーションの改修をSREも担当
- 目指しているSRE
- 開発者が自律的にサービスの信頼性を制御できるようにするサポートチーム
- SREがいなくても回るようにする
- 開発者に自律性を持たせて方針がずれそうな時はサポートする
- （SREにちゃんとスキルがないとサポート難しそう）
- 開発者が自律的にサービスの信頼性を制御できるようにするサポートチーム
- 6つのケーススタディを例にどのようにSWEとSREが会話を通して方針を決めたのか
- 議論ができるようになったきっかけはSREがインシデント時の振る舞いや改善提案をする場を作ったから
- （実際の議論が見れたのでわかりやすかったと同時に、自分には同じ動きはできないなと感じた）
- MetaのSRE Engagement Modelが参考になる
-
https://certomodo.io/best-practices/sre-engagement-models.html
- （おそらくこれ、読んでみよう）
- 今やるべきことに集中する
- それ以外は後回しにする勇気が必要
-
https://certomodo.io/best-practices/sre-engagement-models.html
- 信頼性は会話で決め続ける
- 判断軸: 何を守るか
- レバー: 何を捨てるか
- タイミング: いつやるか
- SREは決まったことの発信者にならない
ファインディの横断SREがTakumi byGMOと取り組む、セキュリティと開発スピードの両立
- 開発者にSRE文化をインストールするためのSRE留学制度があるとのこと
- 2025年 脆弱性傾向
- AI駆動型攻撃の増加
- サプライチェーン攻撃
- ランサムウェアの進化
- AIを活用した大規模な攻撃
- プロンプトインジェクション
- メモリーポイズニング
- モデル抽出
- AIの脅威にはAIで立ち向かう
- 検知~対応まで仕組み化して運用負荷が上がらないようにする
- （Security Hubとか入れてるけど対応まで考えるとなかなかね...）
- 意外とマルウェアは転がっている
- npmレポジトリにも
- （セキュリティについて自分の知識のなさを痛感した）
予期せぬコストの急増を障害のように扱う――「コスト版ポストモーテム」の導入とその後の改善
- インフラコスト削減を進めていくにつれて、コスト版ポストモーテムが必要だと感じた
- コスト削減を通じて感じた課題
- 不必要なコストを発生させる問題の見つけにくさ
- 開発チームのコストへのナレッジ不足
- 過去の問題を分析して組織のナレッジにするため、ポストモーテムを導入
- 不必要なコスト増加を対象
- 予期せぬコスト増加（設定ミスなど）をコスト異常として扱う
- 導入結果
- タイムラインやコスト影響を整理
- コスト影響から優先度の認識が合う
- 予期せぬコスト増加をインシデントと同じように扱うということを組織内で合意
- コスト異常発生時のワークフローを定義
- よかった
- リードタイムの短縮
- 対応状況の可視化
- 再発防止策のフォローアップ
- 難しかった
- 対応すべきクラウドサービスのスコープ
- サービスが提供するコストダッシュボードの機能不足
- 自前で作り込む？
- （AWSが凄すぎる...）
- FinOpsチームの負荷の高さ
- よかった
- 生成AI活用による分析の自動化
スポンサーブース
- お昼休憩として1時間ぐらいセッションのない時間があったのでスポンサーブースを回りました
- 印象深かったスポンサーさん
屋台
- 屋台があることを当日の開会式で初めて知った
- お弁当があるイベントはあったが、屋台は初めて見た
- お祭りで見るような、屋台でびっくり
- ５種類ぐらいあって、唐揚げとたい焼きをいただいた
最後に
- イベントに来るとモチベ上がる
- リアーキテクチャ系のセッションを多めに聞いてた
- インフラ系の技術スタックに寄ってるので、アプリケーションのことも勉強せねば
- ビジネス的な観点も必要
- ナレーション（？）が杉田 智和さんで、登壇された方は名前呼んでもらっていいな
- 写真撮り忘れたので、今度からイベントに行ったらちゃんと写真を撮ろう