AI-native時代の信頼性を育てる、 インシデント学習と改善ループの実践

AIでリリースは加速し、インシデントも増える。素早く解決するだけでは、振り返りと改善のループが止まり、同じ問題が再発する。メルペイは「運用でカバー」に陥ったが、SLOを見直すPJ-5Ninesで中長期改善への投資判断を動かし、ループを再起動した。SREが手を動かす側から、ループを設計し、開発者とAIが自律的に回す側へ移る。その転換を実例で話す。

1. 1 AI-native時代の信頼性を育てる、 インシデント学習と改善ループの実践 SRE NEXT 2026
2. 2 メルカリおよびFintech事業のSREチームを担 当し、組織横断で信頼性向上に取組中 • SLOを用いた監視基盤の構築 • インシデントマネジメント体制の強化 • BCP/DR戦略の策定・推進 • etc foostan Engineering Manager, SRE
3. 3 メルカリの提供するサービス 2013 メルカリリリース 毎月2,484万人※が利用す る 個人が簡単にモノの売り 買いが楽しめるフリマアプリ 「メルカリ」 ※ FY2026.6 第3四半期 2019 メルペイ リリース 2,065万人※が利用するモ バイル決済サービス 「メル ペイ」 ※ メルペイ利用者の合計（自主 退会・重複を除く） 2026年3月末 時点 2023 メルコイン リリース モノや信用に加えて、あ らゆる価値が交換できる マーケットプレイスへ 2025 メルカリ グローバルアプリ 台湾・香港での提供を皮切 りに世界50ヵ国以上へ
4. 4 気づけば、 改善が回っている。 リリースは加速する、 Human in the loop から on the loopへ 改善を止めない、自律的に信頼性が育つ組織へ 目標
5. 5 AIによる開発サイクルの変化と影響 リリースは加速している ▶ PJ-Double が AI Pods / Agent 駆動開発で、開発 と QA のインパクトを倍にしようとしている ▶ リリース加速は偶然ではなく会社の意思 ▶ SRE は加速を止める側ではなく、安全に加速させ ることに貢献する。 インシデントも増えている ▶ インシデントの発生原因はソフトウェアの変更であるこ とが多い。 ▶ リリース回数に相関していて、確実に増えてしまってい るのが現状。
6. 6 リリースは増やしたい、インシデントは減らしたい ▶ サービスを提供し続ける限り インシデント は発生する ▶ インシデントから何を学び、 いかに改善する かが重要 Design Develop Release Detect Acknowledge Mitigate Resolve Postmortem Incident improve
7. 7 改善ループを回して、インシデントを減らす ▶ インシデントを素早く解決 してお客さま影響を抑える ▶ 振り返りと 改善をしてインシデントを減らす Design Develop Release Detect Acknowledge Mitigate Resolve Postmortem Incident improve Fast Recovery
8. 8 改善ループが追いつかないと、劣化する ▶ インシデントの解決が遅れると お客さま影響が拡大 する ▶ 振り返りや改善がされないと 再発を繰り返す負の循環 が始まる Design Develop Release Detect Acknowledge Mitigate Resolve Postmortem Incident improve SLOW Recovery
9. 9 影響調査の自律化 ▶ CUJ SLOでお客さま影響を把握 ▶ AI Agentが影響範囲を即通知 ▶ 原因を調査してレポートを作成 AIがあらかじめ影響と原 因を調査する
10. 10 状況整理の自動化 ▶ Slackの情報を収集 ▶ 概要整理 ▶ 外部レポート作成 ▶ レトロスペクティブレポート生成 ▶ レトロスペクティブレポート評価 ▶ 分析基盤への情報提供 AIが情報を収集し任意 のフォーマットで出力
11. 11 横断分析の実現 ▶ Notion連携によるレポート作成と他 チーム連携 ▶ Socrates連携による分析の促進 ▶ 複数のインシデントを横断的に分 析し傾向や連鎖障害を把握 他サービスとデータ連携 し分析する 生成AI「Socrates」が変 えるCRM分析 ― 工数 ゼロを目指して
12. 12 インシデント原因の分析 ▶ 発生原因を過去のインシデントから調査した ▶ 大きな偏りはなく全てのフェーズで原因が埋め込まれることが分かった 発生原因 1位 コードバグ (25%) 2位 連鎖障害 (20%) 3位 リリースミス (15%) 4位 手動操作 (11%) 5位 コンフィグミス (10%) Design Develop Release
13. 13 インシデント原因の分析 ▶ いくつかの機能に対してインシデントが集中していることが分かった (上位5カテゴリで70%) ▶ また特定の共通コンポーネントが連鎖障害を繰り返していることが分かった Design Develop Release Feature Category A (27%) B (14%) C (12%) D(9%) E(8%)
14. 14 インシデント原因の分析 ▶ 改善はしている が短期改善ばかりで 中長期改善が進んでいない ことが分かった ▶ 表面上の問題は解決するが、根本が解決されないため再発することが分かった Design Develop Release Postmortem improve 根本解決がされずに 再発するリスクが残る
15. 15 インシデント原因の分析 短期改善 ▶ 改善しやすい、内容が明確、回しやすい 例 ▶ 暫定対応 :インスタンス追加、レートリミット ▶ 恒久対応 :クエリインデックス追加、バグ修正 中長期改善 ▶ コストが高い、投資判断が必要、止まりやすい 例 ▶ 恒久対応 : アーキテクチャ改善、技術的負債の解消 ▶ 再発防止策 : E2Eテスト必須のリリースゲートを設置、 SLOアラートによる劣化検知と対応の仕組み化 暫定対応 : 今起きている問題を止血する。原因を直さず影響を抑える 恒久対応 : 問題の直接原因を直す。該当箇所限定の修正 再発防止策 : 発生した要因に対処し、誰がやっても同じ間違いが起きない状態にする
16. 16 改善ループの必要性と課題まとめ 改善ループ ▶ 再発を繰り返す負の循環 を防ぐため、インシデントを素早く解決 し振り返りと改善 ループを回すこと が重要 課題 ▶ 発生原因に大きな偏りはなく全てのフェーズで対応が必要 ▶ いくつかの機能やコンポーネントにインシデントが集中している ▶ 中長期改善進まず、改善ループが止まる -> 根本的な課題解決がされない
17. 17 改善ループが止まる原因と直近の成功事例 原因 ▶ 基本的にビジネスの成長が重要しされ改善するためには 明確な目的が必要 ▶ 再発防止策などの中長期課題はコストが掛かる ため組織的判断が必要 ▶ 課題に対する認識が曖昧で長期的に対応する投資判断ができず、 チケットが積まれるだけ になりがち 成功事例 ▶ 前提: お客さま体験を数値化 して、定量的に判断できるようにする ▶ 短期: プロジェクト化 することで、関係者の認識と期待値を揃える ▶ 長期: インシデント対応やSLO Breachに対するポリシーなどを定義し、定期的なレポート作成や振り返りを実 施することで改善を文化として定着させる
18. 18 例: メルペイにおける失敗と成功 ▶ メルペイの性能劣化と改善の成功体験を例として取り上げる ▶ 一見上手く回っていたが、お客さまが求める期待値を見誤り低水準で改善を繰り返していた Design Develop Release Detect Acknowledge Mitigate Resolve Postmortem Incident improve
19. 19 安定稼働しているように見えていた メルペイにおける失敗と成功 ▶ SLOは99.99%に設定されている ▶ エラーが増加することもあるが SLOは満たせている ▶ 数字上は安定しているように見えていた
20. 20 運用でカバーしていた ▶ 実はエラーが発生するたびに手動で修正バッチを動かしていた ▶ この運用が日常化しておりあまり気にもとめていなかった ▶ SREチームも問題と認識していなかった メルペイにおける失敗と成功
21. 21 許容範囲を超え始める ▶ 修正を要するエラーが増え、チームが疲弊してきた ▶ SLOを下回ることも増え、 SREチームに相談が来る ▶ 原因の調査および改善を実施するがジリ貧に メルペイにおける失敗と成功
22. 22 99.99% 99.999% マイクロサービスと機能の稼働率 ▶ 複数のマイクロサービスで機能を提供 ▶ お客さまへ提供される機能の稼働率を上げるには全ての レイヤーの改善が必要 99.999% BFFレイヤー 共通サービスレイヤー ドメインレイヤー メルペイにおける失敗と成功 99.979%
23. 23 99.999% 99.999% 99.99% 共通サービスの罠 ▶ サービスの共通化は理にかなっているように見えるし、ほとんどの場合はそれが正解 ▶ ただし機能毎に求められる信頼性が異なっていて、共通サービスはその最大値を期待される ▶ 共通サービスがボトルネックになる メルペイにおける失敗と成功 SLO: 99.99% BFFレイヤー 共通サービスレイヤー ドメインレイヤー SLO: 99.9%
24. 24 99.999% 99.999% 99.99% 課題は大きい、対応コストも高い ▶ SLO 99.99%をキープしていても “運用でカバー” している、そもそもSLOが間違っているのでは ▶ 共通サービスを経由してしまう構成は、 SLO 99.99%を満たせないしそれ以上はもっと無理 ▶ 解決するには共通サービス依存をなくす必要があるが … ▶ 投資判断ができずしばらくこの状態が続いた メルペイにおける失敗と成功 SLO: 99.99% は適切？ BFFレイヤー 共通サービスレイヤー ドメインレイヤー ボトルネック解消？
25. 25 新規プロジェクトの立ち上げ ▶ お客さま体験を数値化して、定量的に判断する ▶ 現場のエンジニア、SRE、EM、PM、VPs、皆の認識を数値で統一する ▶ 現在の状況を定量化、目標とのギャップを示して優先度判断の場に持っていく ▶ 困難だった意思決定を前に進め、中長期課題を解決する PJ-5Nines 強インパクトかつあるべき信頼性の提示 メルペイにおける失敗と成功 5Nines (99.999%)の妥当性 ここで提供されるものは、レジ前のお客さまやネット決済などお金が絡む体験であり、水準 は非常に高い。またこれまでの実績から見ても無理な目標ではない。 improve improve
26. 26 SLOの見直しと、アーキテクチャ変更への投資判断 ▶ これまでの運用実績と業界水準をもとに関係者 で議論してSLOをアップデート ▶ ボトルネックだった共通サービスレイヤーを外す ことのトレードオフを受容して決断 ▶ 飛躍的に稼働率は上がったがまだ未達であり、 プロジェクトとして継続して改善を続けている 99.999% とある決済機能で本当に求められていた稼働率 メルペイにおける失敗と成功 99.999% 99.999% BFFレイヤー 共通サービスレイヤー ドメインレイヤー 99.998% 継続的なメンテナンスコストの増加や実装 コストなどのトレードオフを受容
27. 27 PJ-5Ninesによる社内へのインパクト 詳細なエラーへの意識向上 • 単発のエラーや軽微な可用性低下は、これまで見過ごしていた • SLOを上げたことで、それらが見る必要性のあるものに変わった コンポーネント依存関係への意識改善 • 元からリスクと感じ対応すべきと思っていたが、優先度が上がらず未着手だった • SLO基準を上げたことで、この課題も拾えるようになった Observabilityへの意識向上 • SLIは分かりやすさとコストの低さを重視し、単純なメトリクスを採用している • ただし原因究明・改善には、詳細なテレメトリが必要となる メルペイにおける失敗と成功
28. 28 PJ-5Ninesによる社内へのインパクト インシデント対応の洗練化およびメンバーとの信頼構築 • コミュニケーション量が増え、距離感が近くなった • 同じ目標に向かって取り組むことで、良好な関係を築けた 周囲からの言及頻度の増加 • 目標名のインパクトで注目されるようになった • 自然とアイデアや意見が集まる雰囲気づくりにも一役買っている 注意点 高すぎる非現実的な目標は逆効果、確かな根拠と関係者での合意形成が絶対条件 メルペイにおける失敗と成功
29. 29 改善ループを自律的にまわすため SREチームの役割 Incident improve Fast Recovery 自律的な改善ループ ▶ 開発チームが自分のサービスの SLOを自分で守 り、改善ループを自律的に回す ▶ AIを活用して、調査・整理・分析を先回りし、ルー プを回すコストを下げる SREチームの役割 ▶ ループそのものを設計する ▶ SLOの仕組み、Breach Policy、Reliability Reportの発 行など、SRE文化を形成する 今日一番伝えたいこと SRE がループの中で手を動かす状態から、 SRE がループを設計し、開発者が自律的に 回し、AI が駆動する状態へ Move Fast with the SRE Culture
30. 30 改善は回り始めた。 続けるほど、 AI Nativeは加速する。 お客さまの期待を SLOとして数値化し、それを守るポリシーと改善の文化ができてきた この土台の上でこそ、 AIは信頼性を育てる力になる SRE がループの中で手を動かす状態から、 SRE がループを設計し、開発者が自律的に回し、 AI が駆動する状態へ 現在
31. 31 We are hiring! Software Engineer (Site Reliability) - Mercari Minato City, Tokyo, Japan AI NativeなSREチームを一緒に作ってくれる仲間を積極的に募集しています。 興味がある方はぜひ声をかけてください！