# 概要
* 日時：2026/1/31（土） 09:30〜
* 公式：https://2026.srekaigi.net/
* 場所：中野セントラルパーク カンファレンス
* 昨年と同じく、スポンサーチケットでSRE Kaigiに参加
* 今年も杉田智和さんのナレーションでテンションがあがり
* [【SRE Kaigi 2026】ナレーションを杉田智和さんにご担当いただきます！](https://sre-kaigi.hateblo.jp/entry/2025/12/18/154614)
# 感想
* 出張・代休の処理が少し面倒であるが、slackの呼び出しがないからセッションに集中できたかも
* wifiが提供される。たまに切れることもあったけど、どこでも使えるのは助かる。今年もkubernetesで作っているかも？
* 「SREとはなにか？」を知らせる為に作ったマンガ同人誌が配られてた。取り敢えず息子に読んでみるように渡した
* 書店であまり置かないマニアックな本が多く、書籍販売コーナーで立ち読みできるのは嬉しい。ここでは買わないけど、いくつか買いたいものがあった。受験勉強（？）が落ち着いたら買うかも
* プラットフォームエンジニアリング
* 今年はランチセッションがないせいか、お弁当なしだったけど、屋台があったので食べるものには困らなかった
# スポンサーブースー
* 今年は普段見かけることが多かった企業が多かったことで、スポンサーブースーで話す時間が長かった感じ。
## SmartHR
* 社内で使用しているSaaS。GCP / railsで作られているらしい
## nulab（backlog）
* 普段は課題かwikiしか使ってないけど、担当の人からbacklogのドキュメント機能を勧められた。notepmと似たような感じで使えるかも？今度試してみる
* 今年の3月からAI機能がリリースされるらしい。質問時にプロジェクトを指定すると、今までの課題をまとめて返答してくれる。問い合わせ対応もこれで楽になるかも？
## CoDMon（コドモン）
* 子供が通っている幼稚園で使用しているアプリ。個人的にはすごい良い感じで使っていたので、結構長く話していた。
* Fargate + RDSの割とシンプルな構成。負荷が掛かる時間帯が決まっているのでスケーリングをスケジュールして対応しているらしい
* テストの為k8sを利用している。その度に環境作成・破棄を繰り返しているらしい。本番系と違う構成になっているのが課題らしい
## 転職ドラフト
* ここはあまり話してはないが、「このSREが806万円の提示年収をもらえる理由は？」といたテーマーで色んな付箋の書き込みが目立っていた。この会社らしい
# 参加したセッション
* いくつか良かったのをまとめる
## 生成AI時代にこそ求められるSRE
* 資料：https://speakerdeck.com/ymotongpoo/sre-for-gen-ai-era
* 個人的に一番良かった話だった
* AIがコードや設定を書く時代にSREは不要になるのか？
* AIでシステムが不安定化されやすくなっていることで、SREの重要性は高くなっている
* SREの責務：AIの生産性を持続可能なユーザー価値へと変換する
* AI時代にSREがもたらす価値
* コンテキスト
* ガードレール
### コンテキスト
1.オブザービリティ
* システム固有の情報を与える
* 動的な情報：テレメトリー
* オブザーバビリティ・エンジニアリング この本もほしい
* テレメトリを取ると分析してくれるサービスもある
* AWS DevOpsエージェントなど
* cloudwatchのmcpサーバーで分析できる。使ってみたい
2.IaC
* 仕様書は実物とズレる可能性がある為、ポリシーのチェックもコードで書くべき
* Everythng as Code
* Config / Security / Doc / Operation / Observablity / DB
* 人間しか知らないことをなくす
3.ポストモーテム
* slack / テレメトリーデーターなどをもとにタイムラインを自動作成
* 人間も読めるしAIも読める
### ガードレール
1.密封ビルドとサプライチェーンセキュリティ
* 学習したデータが質が悪い場合が多いので、AIで生成されたコードは脆弱性を持っている可能性がある
* pushする際に脆弱性をチェックした方がいい
2.テスト
* AIよるデバックのためのコンテキストを投入
3.Policy as Code
* ポリシーをプログラムとして記入する
4.SLOに基づいたリリース
* カナリアリリースや機能フラグと組み合わせ
5.SRE文化
* 自動化バイアス：人間の意思決定が正しくても自動化をやめられない
## IaaS/SaaS管理におけるSREの実践
* 資料：https://speakerdeck.com/bbqallstars/saasguan-li-niokeru-srenoshi-jian-sre-kaigi-2026
### 行われた活動と効果
1.SRE採用を見据えて技術選定
* 人材採用できた、k8s導入できた
* 身の丈に合わない技術選定をしてしまった
2.マルチプロダクト展開を見据えた基盤設計
* リソース不足と大量のタスク、不安
* 将来的な理想は捨てた
* 新規事業のスピード立ち上げ
3.AWS移管後の運用改善
* SLOを策定
* シンプルにエラーベースで観測した
* SLO取り組み
* 月一回、数値の共有を行っている
### ガードレール
* GitHub CopliotでPRチェック
* AWS Contol Towerを適用
## 開発チームが信頼性向上のためにできること: 医療SaaS企業を支える共通基盤の挑戦
* 資料 : https://talks.kosui.me/2026/sre-kaigi-2026/1
* 医療SaaS特有の品質要求
* 課題1トレーサビリティの欠如
* ユーザー情報の追跡が必要
* 課題2品質要求の相反
* 整合性とトレーザビリティが重要
* 行レベルセキュリティ（RLS）：DBレベルでの個人情報保護
* 複数ポリシーの運用：一つのトランザクションには一つのポリシーを適用
* データ連携パターン比較
* データ基盤連携（これを採用）
* API連携
* イベント連携
* データ基盤連携：タイムトラベル + Delta Lakeを採用
* ドメインイベント：出来事が全て記録される
* 状態テーブルを更新しづつ「イベントテーブル」にINSERT
* ユーザーがどんな操作をしていたのかが取れる
* フルリプレイスは現実的ではないので、段階的に適用
* イベントにバージョンを入れた方がいい
* サービスベースアーキテクチャの採用
* 共通DBを利用。これには読み取りのみ許容
* 分散トレーシングの構成
* ネットワークとかSaaSの料金が上がった
* ビジネス価値への貢献度を見積もる
* 後日（2/3）にこの人の別の発表があったので参加した
* 自分らしく続けるアウトプットの始め方と継続のヒント
