Reliability in the Age of AI: Engineering for AI Velocity

AIを踏まえた開発の予防と処方の在り方 ( https://forkwell.connpass.com/event/394661/ ) #Forkwell_開発の予防処方 というイベントで「Reliability in the Age of AI: Engineering for AI Velocity」というタイトルで発表した際の資料です。

Transcript

1. Reliability in the Age of AI: Engineering for AI Velocity AI を踏まえた開発の予防と処方の在り方 — #Forkwell_開発の予防処方 株式会社 Topotal / Ryota Yoshikawa — @rrreeeyyy
2. Ryota Yoshikawa @rrreeeyyy ( https://x.com/rrreeeyyy ) CTO @ Topotal, Inc. 「SRE as a Service™」を運営 複数顧客の SRE を横断して支援する立場 「Waroom™」を開発 AI も活用したインシデントマネジメント SaaS ぷよぷよが好きです
3. 本日話すこと Part 1 / 現実 — データで見る AI 時代の開発と信頼性 Part 2 / 課題 — AI 時代の信頼性を支える Site Reliability Engineering Part 3 / 進化 — AI を用いた SRE プラクティスの進化 Agenda
4. 01 / Reality データで見る AI 時代 の現実 研究と業界調査から、いま何が起きているかを読む ※ AI 領域の研究は現在も活発に進行中であり、AI 自体も継続的に変化している。 ここで示すデータや結論は現時点でのものであり、今後の研究で更新されていく可能性が高い。 しかし 2026 年現在ここで挙げられているデータと @rrreeeyyy での現場での感覚はかなり近いものになっている。
5. AI 採用は 業界全体に浸透している 大規模な業界調査で開発者の大多数が AI を業務利用している DORA Research: 2025[1] (State of AI-Assisted Software Development) 開発者の 90% が業務で AI を利用 (前年比 +14pt、日平均 2 時間以上) コミュニティ調査でも同方向の結果が示されている Stack Overflow Developer Survey 2024[2] (コミュニティ運営、数万人規模) 76% が AI を利用または計画 [1] https://dora.dev/dora-report-2025/ [2] https://survey.stackoverflow.co/2024/ai Adoption
6. 生産性向上は 研究でも認められている 実験室では明確な速度向上が示される The Impact of AI on Developer Productivity[3] (Peng et al. 2023, GitHub) 95 名対象の実験室での比較実験、Copilot 群が +55.8% 高速 (HTTP server 実装) 事前登録された比較実験でも再現性のある形で追認される Echoes of AI[4] (Borg et al. 2025, 151 名 事前登録された 2 段階の比較実験) Phase 1 で +30.7% 高速 (常用者 +55.9%) 実環境でも、特に経験浅い開発者に対し効果が顕著 The Effects of Generative AI on High Skilled Work[5] (Cui et al. 2024, MIT/Microsoft) Microsoft + Accenture の実環境での実験、タスク完了 +26.08%、低経験者ほど効果大 [3] https://arxiv.org/abs/2302.06590 [4] https://arxiv.org/abs/2507.00788 [5] https://economics.mit.edu/sites/default/files/inline-files/draft_copilot_experiments.pdf Productivity
7. しかし、信頼性指標は 悪化を続けている 3 つの軸でデータを見ていく DORA: AI 採用と不安定さの関係 AI 生成コードの品質・技術的負債 AI 組み込みサービスのインシデント特性 Reliability
8. AI 採用と不安定さの正相関は 継続 DORA 2024 では AI 採用が増えるほどデリバリーが不安定になる傾向が観測された DORA Research: 2024[6] (Accelerate State of DevOps Report) AI 採用 +25% でデリバリー安定性 -7.2%、スループット も -1.5% DORA 2025 でスループットは反転して向上、しかし不安定さの悪化傾向は継続している DORA Research: 2025[1] (State of AI-Assisted Software Development) 不安定さ (変更失敗率 / 手戻り / サイクルタイム) の悪化は 継続 変更失敗率の理想 (0-2%) を達成しているのは 16.7% のみ [6] https://dora.dev/research/2024/dora-report/ [1] https://dora.dev/dora-report-2025/ DORA Metrics
9. AI コードの品質・技術的負債は 残り続ける AI コミットは一定割合で不具合を導入し、その大半が永続化する Debt Behind the AI Boom[7] (SMU + HUST, 304,362 AI コミットの静的解析) AI コミットの 15-29% が不具合を導入 24.2% がリポジトリの最新版に残ったまま セキュリティ上の問題は 41.1% が残り続ける AI コードは人間コードより修正されにくく、結果として残り続けやすい Will It Survive?[8] (Rahman & Shihab, Concordia, 210,184 行のコードを Cox 回帰で生存解析) 修正されにくさを示す指標 (death rate) は 53.9% (人間 69.3%)、コードの所有権の影響も指摘 [7] https://arxiv.org/abs/2603.28592 [8] https://arxiv.org/abs/2601.16809 Code Quality
10. AI 組み込みサービスは 従来監視では検知できない 生成 AI 特有の失敗パターン (不正な推論など) は自動監視では検知できず、人手検知に依存する Production Incidents in Generative AI Cloud Services[9] (Microsoft Research) 社内インシデント管理データ 2020-06〜2024-02 人手検知率 38.3% (生成 AI 以外のサービスでは 13.7%、約 3 倍) 監視に使えるメトリクスがまだ少なく、インシデント対応にも時間がかかる 1 サービスあたりの監視メトリクスの種類は従来サービスの約 1/3 (25.9 vs 74.4) インシデントの収束までに従来サービスの1.83 倍の時間がかかる [9] https://arxiv.org/abs/2504.08865 Generative AI Operations
11. 速度と信頼性のジレンマが AI 時代に再来 している AI で開発速度は確実に上がっている しかし、信頼性に関しては課題感が増している DORA は不安定さの悪化を継続して報告 AI コードに品質問題が残り続け、修正もされにくい AI 組み込みサービスは従来監視では検知しづらい Part 1 — Recap
12. 02 / Challenges AI 時代の信頼性を支える Site Reliability Engineering 信頼性を支える本来の役割と、AI 時代に向き合う課題
13. SRE は本来「速度と信頼性のバランス」を取る役割 AI 時代に速度は加速し、信頼性指標は悪化している (Part 1 のデータ) SRE はこれまでも両者の間でバランスを取る役割を担ってきた AI 時代では「生成物のコントロール」と「本番での観測・担保」の両方が重要になる 生成 AI の成果物が安全になるようなコントロール (テスト・レビュー・ハーネス) はもちろん必要 成果物がプロダクションで正しく安全に動いているか観測・担保するのも同様に重要性が高い AI 時代に SRE が向き合うべきことを、2 つの課題で整理する (i) 変化のスピードに追従する観測・判断 (ii) SRE プラクティス自体のスケーラビリティ SRE Fundamentals
14. 変化のスピードに 観測 → 判断 のサイクルを追従させる AI で変更頻度・変更量が加速度的に増加し、観測 → 判断の追従の重要性が増している レビュー・影響分析・障害判定のような人手の判断作業がボトルネックになりつつある 変更が次々に積み上がる中で、影響範囲を把握しきれないまま本番に届くケースが増える これまでも存在していた問題だが、AI 時代に更に増えることになる 個人の感覚の判断では追い付かなくなり、データドリブンな判断の重要性が増す 観測データを意思決定の中心に据えることが、AI 時代に一層重要になる データを用いた判断であれば AI の力を借りることも可能になる サービスの信頼性や状態がどのようになっているかというデータをしっかり集める必要がある Challenge (i) — 1 / 3
15. SLI/SLO とエラーバジェット で速度と信頼性を制御する SLI/SLO: サービスの信頼性を観測指標 (SLI) と目標値 (SLO) で表現する仕組み ユーザー体験から逆算した「どこまでの信頼性を保証するか」を数値で合意する 観測データで信頼性の変化を継続的に把握できる 例: SLO の達成率を継続観測し、AI による変更が信頼性に与える影響を可視化する 例: 出力品質スコア / ハルシネーション率 / RAG 検索精度を SLI に加える エラーバジェット: SLO で許容される失敗の量 (= 100% - SLO) 例えば SLO が 99.9% なら、エラーバジェットは 0.1% (≈ 月 43 分) バジェットが残っている間は変更速度を上げられる、消費されれば自動的に速度を抑制する 変更速度を「信頼性が許容する範囲」で管理できるようになる 例: バジェットが残れば AI 補助による自動承認を許容、消費されれば人間承認に戻す Challenge (i) — 2 / 3
16. データドリブンな観測・対応 を支える SRE プラクティス Observability: メトリクス・ログ・トレースでサービスの状態を継続的に観測する 例: メトリクス・ログ・トレースを統合し、サービスの状態や障害の原因をデータで判断する 例: 観測対象を継続的に広げ、新しいシグナル (LLM 出力品質など) も取り込めるように設計する インシデントレスポンス: 障害の検知・対応・収束をデータに基づいて回す 例: MTTD / MTTA / MTTR などの TTX メトリクスを観測し、対応プロセスを継続改善する 例: タイムラインや対応履歴を蓄積し、ポストモーテムを通じて次の障害対応の判断材料に変える Toil の計測と削減: 運用負荷を観測し、ソフトウェアで減らしていく 例: Toil の時間と頻度を計測し、削減効果が高いものから自動化する 例: 自動化前後の効果を計測し、削減の効果をデータで検証する Challenge (i) — 3 / 3
17. SRE プラクティス自体の スケーラビリティ 開発加速に SRE 業務 (PRC / 障害対応 / ポストモーテム) が追従できない 変更量に対して人手のレビュー・調査・分析が線形に増えない SRE 業務がボトルネックになり、開発速度を損なうか信頼性を犠牲にすることになる AI は組織の既存の状態を増幅する (DORA Research: 2025 の中心的な発見) DORA Research: 2025[1] (State of AI-Assisted Software Development) "AI doesn't fix a team; it amplifies what's already there" 整った組織は AI でさらに伸び、整っていない組織は弱みが露呈する SRE プラクティス自体もスケーラブルに設計し、拡張していく必要がある [1] https://dora.dev/dora-report-2025/ Challenge (ii)
18. Google SRE も同じ パラダイムシフト を認識[10] AI による速度加速で、従来の人手プラクティスは持続不能になる "AI coding assistants … with organizations targeting up to a 4x increase in productivity — traditional, manual practices are becoming unsustainable" "Human code review cannot scale linearly with machine-generated code volume" SRE の本質 (SLI/SLO / エラーバジェット / toil 削減) は変わらないが、運用は新フェーズに入る "…the operational landscape has reached a new inflection point" SRE は「直接の対応者」から「AI 安全性の設計者」へシフトする "SREs must move up the abstraction ladder, transitioning from direct incident responders to architects of AI safety" [10] https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/ Google SRE Perspective
19. 03 / Evolution AI を用いた SRE の進化
20. SLI/SLO の 設計と運用支援 背景: SLI/SLO の設計は SRE プラクティスの起点だが、設計コストが高く属人化しやすい サービスごとに観点が異なり、ベストプラクティスが個別最適化されたまま蓄積されない 取り組み: SLI/SLO の設計と運用観測を AI で補助する GitHub のリポジトリを AI に読み込ませ、サービスの構造から SLI/SLO の候補を提案する PR で重要な機能が追加されたら、SLI/SLO への追加が必要かを AI が確認する 既存のメトリクスや過去のポストモーテムを AI が解析し、SLI の改善案を出す SLO 違反の予兆を AI が継続観測で検知し、原因の仮説を提示する SLO の見直しタイミングや組織レベルの妥当性も AI で評価する Case 1
21. Production-Readiness Check の AI 化 背景: 変更レビューは観点が増え続け、レビュアの認知負荷が高く属人化しやすい AI で開発速度が上がる中、人手のレビューがボトルネック化しやすい 取り組み: 変更内容を AI が Production-Readiness 観点でレビューし、人間が承認する形で進行中 リリースタイミングで差分を AI に読み込ませ、PRC 観点でのリスクと観点漏れを提示する 過去のリリースと本番障害の相関から、Readiness Check への反映を AI が提案する 最終的な意思決定は人間が保持する Case 2
22. 障害対応 → ポストモーテム の AI 化 背景: 対応から事後の学習まで、人間の認知負荷が高く属人化や学習サイクルの停滞を招きやすい AI で変更頻度や障害件数が増える中、対応と学習の両方が追いつかなくなりつつある 対応中: 障害対応中の調査・状況把握・仮説生成を AI が補助する Slack ログ / 観測データ / 過去事例から状況サマリーや対応策の提案を行う Sentry や CloudWatch からエラーやメトリクスを取得し、原因の仮説を提示する タイムライン記録とステークホルダー報告の下書きで認知負荷を下げる 事後: ポストモーテムの下書きを AI が生成し、人間が編集・承認する タイムライン → 原因分析 → Lessons Learned の構造化と、再発防止策の Issue 化までを支援する AI 提案は提示にとどめ、最終判断と組織への接続は人間が保持する Case 3
23. 更に AI に任せていくには 段階を踏む必要 がある ここまでの取り組みは「AI が提案・下書き、人間が最終判断」する段階 AI の判断根拠を提示しつつ、最終的な意思決定は人間が保持する 過去事例や観点を AI に取り込み、補助の精度を継続的に上げていく 更にプロダクションの作業を AI に任せていくには、段階的に整える必要がある Google SRE の Autonomy Levels (L0 → L4)[10] のような段階モデルを参考にする Safety Trifecta のような安全前提を各段階で整える 評価データ・ガードレール・運用観点を各段階で蓄積していく [10] https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/ Beyond
24. Google SRE が示す 5 段階 の自律性モデル Level 名称 役割分担 L0 Manual Execution すべて人間主導 L1 Assisted モニタリング + 調査を AI が補助 L2 Partial Autonomy AI が提案、人間承認が必須 L3 High Automation 特定シナリオで AI が完全自動実行 L4 Full Autonomy マルチステップ解決を AI が自動実行 いきなり L3-L4 を目指すのではなく、L1-L2 で実証 → 段階的に進む形が現実的 [10] https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/ Framework: Autonomy Levels
25. 各段階で求められる 3 つの安全前提 Transparency (可観測性): AI の行動と判断が観測・理解できる AI が何を見て、どう判断したかを記録し、人間が後から追跡・検証できるようにする 観測できない AI の振る舞いは評価ができず、信頼性を保証できない Real-time Risk Evaluation (実行時リスク評価): AI の提案する行動はリスク評価を経る Dry-run や影響範囲の事前評価で、本番への意図しない影響を最小化する AI Agent の提案ごとにブラスト半径を評価し、危険な動作を実行前に止める仕組みを持つ Progressive Authorization (段階的権限付与): AI に最初から本番権限を与えない 読み取り → 提案 → 限定実行 → 広範囲実行 と段階的に権限を広げる 各段階で評価データ・ガードレール・運用観点を積み上げてから次の段階に進む [10] https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/ Framework: Safety Trifecta
26. AI エージェントを安全に運用するための 4 つの要件 No Ambient Access & Least Privilege: AI と人間の権限を明確に分け、必要時のみ権限付与 AI Agent の identity を人間ユーザーから分離し、必要なときだけアクセスを許可する Agentic Circuit Breakers: AI の動作はいつでも中断可能にする 暴走した動作を即座に止められる「非常停止スイッチ」を組み込む Mandatory Dry-Run Support: AI 操作対象は dry_run モードを必須でサポート 実行前に影響を確認できる仕組みを、AI 操作対象のシステム側に標準で備える Zero-Trust, Safe-by-Default Actuation: AI はゼロトラスト設計の安全ツールのみを操作 AI 自体が無制限に動作するのではなく、安全機構を備えたツールを通じて操作する [10] https://sre.google/resources/practices-and-processes/ai-engineering-reliable-operations/ Framework: Architectural Guardrails
27. 本日のまとめ 現実: AI で開発速度は上がる一方、信頼性指標は悪化を続けている DORA 2024-25 で AI 採用と不安定さの正相関が継続して観測される AI コードは品質問題が残り続け、AI 組み込みサービスは従来監視では検知しづらい 課題: SRE は速度と信頼性のバランスを AI 時代に取り直す必要がある 変化のスピードに観測 → 判断のサイクルを追従させ、データドリブンな判断ができるようにする AI 生成物のコントロールと、安全なデプロイ担保の両方の重要性が増している 進化: SRE プラクティス自体も AI を活用して、開発加速に追従する必要がある SRE 業務に AI を取り込み、信頼性運用をスケーラブルにする 更に AI に任せていくには、段階的にガードレールや評価データを整える必要がある Summary