生成AI時代にこそ求められるSRE / SRE for Gen AI era

SRE Kaigi 2026の発表資料でエス
https://2026.srekaigi.net/#timetable?session-hall-1035

Transcript

1. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⽣成AI時代にこそ求められるSRE 信頼性を勝ち取るための「コンテキスト」と「ガードレール」 ⼭⼝能迪 (@ymotongpoo) S R E K A I G I 2 0 2 6 アマゾンウェブサービスジャパン合同会社 シニアデベロッパーアドボケイト
2. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⾃⼰紹介 ⼭⼝ 能迪（やまぐち よしふみ） アマゾンウェブサービスジャパン合同会社 シニアデベロッパーアドボケイト 専⾨領域 • オブザーバビリティ • SRE全般 @ymotongpoo
3. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 3 AI 利⽤の是⾮を問うフェーズの終了 90% 回答者が業務でAIを利⽤ Q: AI がコードや設定を書く時代に、SRE は不要になるのか︖ A: SRE の重要性は、かつてないほど⾼まっている https://dora.dev/research/2025/
4. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4 AI は組織の能⼒を増幅するアンプ 優れた組織はより強化され、課題のある組織は弱点を増幅させる 良いところも課題もすべてが増⼤ • 開発速度 • システムの不安定さ • 変更失敗率
5. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5 SRE やモダンな開発は何を変えたのか サービス 開発者 デリバリーパイプライン 監視 ビルド テスト リリース
6. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 6 SRE やモダンな開発は何を変えたのか サービス 開発者 デリバリーパイプライン 監視 ビルド テスト リリース 監視 ビルド テスト リリース 監視 ビルド テスト リリース 監視 ビルド テスト リリース 監視 ビルド テスト リリース 監視 ビルド テスト リリース
7. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 7 AI 駆動な開発は何を変えたのか サービス 開発者+AI デリバリーパイプライン 監視 ビルド テスト リリース 監視 ビルド テスト リリース 監視 ビルド テスト リリース 監視 ビルド テスト リリース 監視 ビルド テスト リリース 監視 ビルド テスト リリース ここの議論が多いが 今⽇はここの話
8. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 8 ソフトウェア開発は社会技術システム ソフトウェア開発 = ⼈間系 + 技術系 の複雑な絡み合い AI という強⼒な変数は広範囲に影響を与える • コード⽣成 • チームのコミュニケーション • 意思決定プロセス • エンジニアの⼼理 SRE の責務 AI の爆発的な⽣産性を、カオスではなく、持続可能なユーザー価値へと変換する
9. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 9 コンテキストの補強 AI がよりよく動作するための「コンテキストの補強」は SRE が求めてきたもの オブザーバビリティを⽤いたデバッグでは、与えられたリクエストの周りのコンテキ ストをできるだけ多く保存し、斬新な障害モードにつながったバグを誘発した環境や 状況を再構築できるようになります。 ⼗分に考えられて選択されたSLOは、信頼性に関する作業の機会コストについてデータ に基づく判断をしたり、その作業の適切な優先順位を決定する上で鍵となるということ です。...SLO は、どのエンジニアリング作業を優先するかの決定を助けるツールです。 1章 オブザーバビリティとは︖ 2章 SLO の実装
10. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 10 ガードレールの強化 開発速度を維持したまま品質を維持する⼿法は SRE が勤しんできたもの 27.4.2 機能フラグフレームワーク ...機能フラグフレームワークが考え出されたプロダクトがあります。そのフレーム ワークの中には、新しい機能を 0% から 100% まで逐次的に新機能をロールアウト していくために設計されたものもあります。... 深刻なバグや副作⽤があった場合、即 座に変更を独⽴してロールバックできる。 SLI と SLO は、必要なときにちょっとしたガイドを⽰してくれます。『そこは、あ あするよりもこうしたほうが、顧客のレイテンシーが改善されるはずです』であっ たり、『新しいバージョンをデプロイして本当にいいですか?』であったり、『これ が、ユーザーにとって重要なことなんですね。私たちも注意を払ったほうがいいか もしれません』などです。 序⽂
11. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 11 SRE のプラクティスが AI にもたらす価値 AI 時代にあらためて SRE がもたらす価値を • コンテキスト: AI がより良く動作するための下地 • ガードレール: AI の失敗を予防・回復するための保険 という観点から考える ⼀番⼤事なスライド
12. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 12 © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. コンテキスト
13. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 13 コンテキスト1: オブザーバビリティ AI (LLM) が知っているのは知識カットオフ時の⼀般的な情報だけ システム固有の情報はコンテキストとして与えるしかない • 動的な情報: テレメトリー • 静的な情報: 仕様、アーキテクチャ図
14. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 14 コンテキスト1: オブザーバビリティ オブザーバビリティの本当の威⼒は、問題をデバッグする際に、事前にそれほど 多くのことを知る必要がないことです。システムをよく知らない（あるいはあま り知らない）場合でも、体系的かつ科学的に次々とステップを踏んで、答えを⾒ つけるための⼿がかりを整然と追っていけるはずなのです。 8.2 第⼀原理からのデバッグ 従来のメトリクス { "payment_api_errors_total": 1500, "cpu_utilization_avg": 0.85 } ⾼次元なイベント { "status": "error", "latency": 210, "timestamp": "2026-01-06T13:30:15Z", "service.name": "payment-gateway", "trace.id": "abc-123-xyz-789", "event.name": "stripe_charge_failure", "customer.id": "cus_a1b2c3d4", "payment.plan": "premium_monthly", "app.version": "v2.1.5-canary", "cloud.region": "ap-northeast-1" }
15. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 15 コンテキスト1: オブザーバビリティ 既に AI ⽀援のテレメトリー分析機能が多く存在する eg. AWS DevOps エージェント 復旧案の提⽰ Root CauseとしてDynamoDBへアクセス実装 が不適切であることを正しく分析 裏付けるデータが⽰される （レイテンシーの悪化、タイムアウトの増加）
16. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 16 コンテキスト1: オブザーバビリティ AIアシスタントにpprofを使わせでデバッグする例を Observability Conference Tokyoで話しました AIアシスタントを使って⼿元で連携することも可能 MCPサーバー ローカルコマンド { "mcpServers": { "awslabs.cloudwatch-mcp-server": { "autoApprove": [], "disabled": false, "command": "uvx", "args": [ "awslabs.cloudwatch-mcp-server@latest" ], "env": { "AWS_PROFILE": "my-aws-profile", "FASTMCP_LOG_LEVEL": "ERROR" }, "transportType": "stdio" } } }
17. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 17 コンテキスト2: Infrastructure as Code AI (LLM) が知っているのは知識カットオフ時の⼀般的な情報だけ システム固有の情報はコンテキストとして与えるしかない • 動的な情報: テレメトリー • 静的な情報: 仕様、アーキテクチャ図 本当にこの通りに設定されているとは限らない
18. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 18 コンテキスト2: Infrastructure as Code AI (LLM) が知っているのは知識カットオフ時の⼀般的な情報だけ システム固有の情報はコンテキストとして与えるしかない • 動的な情報: テレメトリー • 静的な情報: 仕様、アーキテクチャ図、ソースコード、XaC (IaC、PaC、NaC…)
19. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 19 コンテキスト2: Everything as Code Infrastructure as Code Configuration as Code Policy as Code Security as Code Documentation as Code Operation as Code Observability as Code Database as Code あらゆるものをコードで管理することで変更を 追跡可能にし、再現性と⼀貫性を確保する • プレーンテキストで書かれたコードは ⼈間にも AI にも理解しやすい • ⼈間しか知らないことをなくす • ⼿動での設定変更 • 暗黙的なルールやオフラインの会話 ref: AWS Well-Architected DevOps Guidance
20. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 20 コンテキスト3: ポストモーテム AI が作成を⽀援し、AI のためのコンテキストとなる AI 導⼊以前 作成⽅法 1. Slack履歴をクロール 2. ダッシュボードのリンクを検索 3. 障害のタイムラインの認識の⾷い違い 4. 苦労してポストモーテムドラフト作成 ⽤途 ⼈間が読む AI 活⽤後 作成⽅法 1. Slack、Zoom録画、アラート履歴、コミットログ、 テレメトリーデータを統合 2. タイムライン⾃動作成 3. 過去の類似障害との⽐較 4. 根本原因分析の提案 5. ドラフトを⾃動作成 ⽤途 ⼈間も AI も読む c.f. トイルの削減
21. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 21 © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. ガードレール
22. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 22 ガードレール1: 密封ビルドとサプライチェーンセキュリティ 密封 (Hermetic) ビルド ビルド環境に依存せず、常に同じ結果を再現できる、完全に決定論的なビルドプロセス サプライチェーンセキュリティ ソフトウェアの企画、設計、開発、ビルド、テスト、配布、運⽤に⾄るまでの開発パイプラインにお いて、外部から混⼊されるマルウェアや脆弱性、悪意のあるコードからシステムを守るための対策 AI で加速するリスク • ハルシネーションによる存在しないライブラリ名 • 古いコードの混⼊による脆弱な依存関係
23. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 23 例: サプライチェーン攻撃の防御 (正しくは strands-agents)
24. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 24 対策: 多層的防衛 密封ビルドと検証の可能性を⾼める • 内部アーティファクトリポジトリ: 検証済みライブラリのみをミラー • SBOM有効化: 全依存関係のリスト化と脆弱性スキャン • SLSA導⼊: ビルドプロセス⾃体の信頼性証明
25. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 25 ガードレール2: テスト AI によるコードの⽣産量が激増＝従来のレビュー・テストがボトルネックに 発展的なテスト⼿法 • ファジング: 予期せぬ⼊⼒での脆弱性やシステムダウンを発⾒ • プロパティベーステスト: コードが満たすべき「性質」を定義 • ミューテーションテスト: ユニットテストの「品質」をテスト SRE の責務 発展的なテスト⼿法を開発者が「簡単に」「意識することなく」利⽤できる CI/CD パイプラインを構築・提供する AI によるデバッグのため のコンテキストでもある
26. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 26 ガードレール3: Policy as Code による統制 AI が⽣成するコードやインフラ構成は、組織のポリシーを違反する可能性 主要ツール • Open Policy Agent (OPA): Regoで汎⽤ポリシーを記述するポリシーエンジン • Conftest: OPAラッパーの設定ファイルテストツール • AWS Config: AWSリソースの設定の継続的監視 ポリシーをプログラムとして記述し、CI/CDで⾃動検証
27. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 27 ガードレール4: SLO に基づいたリリース カナリアリリースや機能フラグとの組み合わせでユーザーへの影響を低減 シナリオ例 1. 新バージョン v2 を 1% にデプロイ 2. SLO ベースの⾃動分析 • 例: レイテンシーSLOを超過した 3. 閾値超過で⾃動ロールバック 4. 通知 + ⾃動起票
28. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 28 ガードレール5: SRE ⽂化 ⾃動化バイアス (Automation bias) ⼈間が⾃動化された意思決定システムからの提案を優先し、それが正しくても⾃動化されていない ⽭盾する情報を無視する傾向。 AI の出⼒結果に対してノーと⾔える⽂化と組織作り • AI の提案は説得⼒があるが、常に正しいとは限らない • エンジニアが AI に意義を唱えられる⼼理的安全性 • ⾮難のない⽂化の拡張 • 「与えたコンテキストが何かを⽋いていたのではないか」 • 「AI の判断プロセスは改善できないか」
29. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 29 © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. おわりに
30. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 30 SRE は AI を安⼼して迎え⼊れるための⼟台 今⽇から始められる⼩さな⼀歩 • オブザーバビリティを推し進めてみる • トレースやイベント（構造化ログ）はありますか︖ • SLOを定義してみる • ユーザー視点でサービスの信頼性を⾒れていますか︖ • CI/CD パイプラインを⾒直してみる • 密閉ビルドしていますか︖ • どんなテストを⾛らせていますか︖ • ポリシー検証してますか︖ AI を正しく導くためにも SRE を実践して コンテキストとガードレール を⼿に⼊れましょう︕
31. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 31 AI で『Challenge SRE!』 ⼤事なのは信頼性 • SRE に必要なツールや設定も AI に助けてもらえば良い • 決定性があるツールや仕組みを作ることが重要 みなさんの SRE の実践が AI で加速することを願っています︕
32. © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 32 AWS Builder Center でも知⾒を共有してください