https://ozaki25.hatenadiary.jp/entry/2026/01/31/182901

2026/1/31
https://2026.srekaigi.net/

生成AI時代にこそ求められるSRE

山口能迪さん(AWS)
https://speakerdeck.com/ymotongpoo/sre-for-gen-ai-era

AIによる加速
- 開発速度は上がるが不安定さも増大させる
- 変更失敗率も上がる
- 組織の持っているものが増幅される
AI駆動開発
- 開発者がどうAIを使うかにフォーカスが当たりがち
- デリバリーパイプラインについてももっと活用できる
コンテキストの補強/ガードレールの強化
- SREがもともとやってきていたこと
- SREがAI時代にもたらす価値になる
コンテキスト
- システム固有情報はコンテキストとして与えないといけない
  - 動的な情報：テレメトリ
  - 静的な情報：仕様やアーキテクチャ
- オブザーバビリティ
  - 今どういう風に動いているか知る
  - 従来だとCPU仕様率とかエラー数とかだけ
  - サービス名やトレース情報など高次元なイベントがとれるようになってる
  - テレメトリをとってれば解析してくれる
    - AWS DevOpsエージェント
    - Datadog Bits SRE
  - MCPサーバ経由で手元でも活用できる
- IaC
  - 仕様書やアーキテクチャ図は本当にその通り作られてないことも多い
  - IaCのコードが一番正しい情報源
  - Everything as Code
    - あらゆるものをコードで管理
    - 再現性と一貫性
    - プレーンテキストがAIにとって読みやすい
    - commit履歴で経緯も読み取れる
- ポストモーテム
  - AIが作成を支援
  - 成果物はAIも読む
ガードレール
- ビルドプロセスは外部依存しないことが望ましい
  - セキュリティ
  - 冪等性
- 密閉ビルド
- サプライチェーンセキュリティ
  - 内部アーティファクトリで間違ったライブラリインストールしないように
  - もしインストールしてしまってもスキャンしてしてしまっても脆弱性を検知
- 発展的なテスト
  - ファジング
  - プロパティベーステスト
- Ppolicy as Codeによる統制
  - CI/CDで
- SLOに基づいたリリース
  - カナリアリリースやフィーチャーフラグと組み合わせて
  - 自動ロールバック
- AIの出力結果にNoといえる文化

制約が導く迷わない設計 - 信頼性と運用性を両立するマイナンバー管理システムの実践

内藤翔太さん(DressCode)
https://speakerdeck.com/bwkw/zhi-yue-gadao-kumi-wanaishe-ji-xin-lai-xing-toyun-yong-xing-woliang-li-surumainanbaguan-li-sisutemunoshi-jian

制約を使って設計判断を進める
制約を洗い出すことが設計判断の第一歩
- 外部から課される自由度を制限するもの
- 法令/規制
- ビジネス要件
- 技術環境
- チーム/体制
- 運用ルール
除外として効くものと比較として効くもの

SREが向き合う大規模リアーキテクチャ〜信頼性とアジリティの両立〜

守屋邦昭さん(シンプルフォーム)
https://speakerdeck.com/zepprix/sregaxiang-kihe-uda-gui-mo-riakitekutiya-xin-lai-xing-toaziriteinoliang-li

法人の健全性をモニタリングするサービス
- 不穏な動きがある法人を検知したいがノイズが多いと業務が却って非効率になる
- 複合できな事象を組み合わせて検知が必要なケース
業務要件実現のためのリアーキテクチャ
- バッチが4時起動で7時がデッドライン
  - 通常は60分なので90分をSLOとして検知
- 並行期間を設けてバグをつぶす
  - ダウンタイムゼロで移行

Embedded SREの終わりを設計する：「なんとなく」から計画的な自立支援へ

鷹箸孝典さん(Sansan)

Embedded SREのExit戦略
- なんとなくで関わり続けてしまう
- 他にもプロダクトはあるのに
SREのスケーラビリティの限界
- プロジェクトごとにゼロから構築
- 標準化が進まず車輪の再発明
- SREがチームAの対応をしてる間にチームBやCが独自で動いてる
- SREのリソースがボトルネックに
Platform EngineerとEmbeddedSREの両輪で
- 全社で利用可能なプラットフォーム
Exit戦略
- 基盤構築期
- 自立移行期
- サポート期
SRE Knowledge Transfer Matrix
- 開発チームのメンバーが何をどれくらいできるか可視化
- 二軸で定量化
  - 自信度
  - 経験
- チームとしてどれくらいカバレッジがあるか
  - 最高スコア
  - 基準を満たした人数

SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル

川田雅彦さん(イオンスマートテクノロジー)
久保翔馬さん(イオンスマートテクノロジー)
https://speakerdeck.com/aeonpeople/sre-kaigi-2026

Embedded SREと開発チーム
週一でダッシュボードを眺める会
- エラーが増えてるとかコスト上がってるとか見る
月一で特別回
- ビジネス部門や関連システムの人も呼ぶ
- 今後の施策やイベントの情報を共有してもらう
- 先回りして対策が取りやすくなる
眺める会の主催がSREから開発チームへ
- 自然と移行が進みEnablingが上手くいった

認知負荷を最小化するオブザーバビリティとSLOの導入 ―4名のSREが200名のプロダクトエンジニアを支援

樋口貴志さん(SmartHR)

人事労務領域における社会インフラになる
- 信頼性とアジリティ
40の開発チーム200名のエンジニア
- SREは4名
- Enablingを主体に活動
SmartHRのSRE
- SREに期待することは組織によって違う
- SREチームと開発チームの責任分界点の明確化
  - SRE：SLO計測の仕組みを提供
  - 開発：SLO目標値の策定運用
  - 文書化して展開する
ロードマップを作って計画的に
- RICEスコアで優先順位
少人数での取り組み
- ダッシュボードと分析手順
SLI/SLOの策定
- 開発チームが策定しようと思っても難しい
- CUJを考えて設計する
  - プロダクトの価値を考えてそれを実現する導線を整理
  - それを実現するのに通る画面やAPIから対象を決める
  - どれくらい品質が下がると価値に問題が出るかで基準を決める

15年続くIoTサービスのSREエンジニアが挑む、可観測性向上〜技術をビジネス価値に翻訳する試行錯誤の記録〜

Banri Kakehiさん(エレクトリックワークス)
黒崎耕平(エレクトリックワークス）
https://speakerdeck.com/melonps/15nian-sok-kuiotsabisuno-sreenziniagatiao-mu-fen-san-toresingudao-ru

分散トレーシングの導入
- k8s移行&マイクロサービス化でトラブルシューティングが難しくなった
- 分散トレーシングを導入したがコストが想定の10倍
- 担当メンバーも異動になり導入断念
導入失敗の要因
- 技術面
  - スクルや知識の不足
  - 計装のノウハウがない
    - いきなりデバイスからのE2Eを実装して複雑なことをしていた
  - コストの見積もり
    - 何をするとどれくらいコストがかかるかなど
    - SaaS利用料
    - 実装コスト
  - 何を可視化したいのか明確になってなかった
- 認識面
  - ビジネス価値にどう貢献するか共通認識がなかった
分散トレーシングで何をしたいか
- 問いを明確化
- 自動計装でいいか主導計装が必要か
- サンプリング戦略
- SaaSが必要かOSSでできるか
ビジネス価値への貢献度の見積もり
- 問い合わせ調査時間の減少
- 属人化の解消