生成 AI × MCP で切り拓く次世代 SRE！自律型運用への挑戦と開発者体験の進化

AWS Summit Japan 2026 での登壇資料です

Transcript

1. #AWSSummit #PRT216-S 生成 AI × MCP で切り拓く次世代 SRE！ 自律型運用への挑戦と開発者体験の進化 Keisuke.Awata KINTO Technologies, Inc. xRE Group
2. #AWSSummit #PRT216-S 自己紹介 mysql > SELECT * FROM me \G *************** 1. row *************** name: 粟田 啓介 nickname: あわっち X: @_awache company: KINTO テクノロジーズ株式会社 role: DBRE/SRE MGR favorite: Aurora MySQL, Trusted Advisor 1 rows in set (0.00 sec)
3. #AWSSummit #PRT216-S KINTO テクノロジーズ株式会社 (KTC) について 2021年04月設立 2019年01月設立
4. #AWSSummit #PRT216-S KTC における SRE/DBRE の立ち位置 ⚫ 従業員数: 約400名 アプリケーション開発組織 • KINTOサービス開発 • 決済/ID基盤開発 • バックオフィスシステム開発 • モバイルアプリ開発 etc... プラットフォーム開発部 • Cloud Infrastructure • Cloud Security • xRE (SRE: 2名 / DBRE: 5名) • MSP (24×365保守運用) • Platform Engineering アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 アプリケーション 開発組織 … プラットフォーム開発部 Cloud Security Cloud Infrastructure xRE (SRE / DBRE) MSP Platform Engineering
5. #AWSSummit #PRT216-S KTC SRE のミッション・ビジョン Mission Vision 信頼性の高い価値あるプロダクトを最速で提供できるようにする サービスレベルに基づいた開発と運用のバランスが取れた組織の実現 役割が細分化された組織の中で、SRE としての立ち位置を定義し、サービスレベルを共通言語に開発と運用をつなぐ 「何を信頼性と呼び、どこに価値を置くか」をチームで言語化したことが、このミッション・ビジョンに込めた想い
6. #AWSSummit #PRT216-S KTC SRE のアプローチ Figure III-1. Service Reliability Hierarchy サービス信頼性ヒエラルキー 愚直に下から積み上げる SRE 活動を支える Observability Platform ヒエラルキーの各レイヤーを下支えするのが Observability New Relic は「ツール」ではなく SRE 活動を支えるプラットフォームとして 活用し、計測・分析・改善のサイクルを回す強力なパートナー
7. #AWSSummit #PRT216-S 本日のお話 AI が SRE を「置き換える」話ではない AI という新しい武器を使って、SRE の打ち手をどう進化させられるか Enabling 開発者の自走支援 ガイドや知見の提供を AI が補助し、 開発チームが自分で信頼性を扱える ように Observability 可観測性 膨大なテレメトリを AI が要約・相関 づけし、見るべき兆候を素早く浮か び上がらせる 障害対応 Incident Response 検知から原因究明・対応までを AI が 支援し、復旧までの時間を短縮する AI は SRE の仕事を「置き換える」のではなく、「増幅する」 人がやるべき判断に集中するために使う
8. #AWSSummit #PRT216-S KTC SRE としてやるべきこと 信頼性と開発速度を両立する 変わらないこと 障害を減らす 可観測性を高める 運用負荷を下げる 開発者が価値提供に集中できるようにする 変わったこと ── 周囲の環境 システムの複雑化 マイクロサービス SaaS クラウドネイティブ AI やるべきことは変わらない。変わったのは環境。だからこそ、AI という新しい武器を取り入れる。
9. #AWSSummit #PRT216-S SRE に新しい武器が増えた AI は目的ではなくSRE の新しい武器である これまで Monitoring Automation IaC Platform Engineering これから LLM MCP Agent 重要なのは、AI で「何を実現するか」 武器があっても、使われなければ意味がない まずは Observability から
10. #AWSSummit #PRT216-S New Relic 導入状況 1
11. #AWSSummit #PRT216-S 過去の Observability スタック 課題 ⚫ データがバラバラに管理され、障害時は複数ツールを横断して確認 ⚫ o11y 文化が根付かず、トレース・メトリクスは活用されずログだけで障害対応 ⚫ SRE がダッシュボードを提供しても、学習コストの高さから開発者の自走につながらない ⚫ ログ ：OpenSearch ⚫ トレース ：X-Ray ⚫ メトリクス：Prometheus, Grafana
12. #AWSSummit #PRT216-S New Relic 導入 ⚫ 2024月04月頃から New Relic が社内で使えるように ⚫ ログ、トレース、メトリクスが一つの場所に集約されて関連づいている ⚫ 導入するだけで見える情報が多く、初期学習コストが低い Figure III-1. Service Reliability Hierarchy
13. #AWSSummit #PRT216-S New Relic 導入の現状 ⚫ 2026年現在 KINTO に関するサービスは New Relic をほぼ全て導入している ⚫ KINTO ONE ⚫ KINTO ONE 中古車 ⚫ TOYOTA UPGRADE FACTORY ⚫ など 23サービス New Relic を導入したからといっていきなり活用が定着するわけではない
14. #AWSSummit #PRT216-S New Relic 活用の壁 2
15. #AWSSummit #PRT216-S 導入 ≠ 活用 New Relic を布教しようとする人と開発者とのギャップ New Relic 推進者 (SRE) 開発者 推進のために機能を理解している どんな機能があるか分からない SRE の思想をベースとした活用方法が分かる 障害発生時に使うツールという認識 o11y は最優先で取り組むべき領域だと感じる 開発タスク優先で関心が向けられない ログ・トレース・メトリクスを見て根本原因を追う まずはログを見て、原因が分かれば十分 ダッシュボードや SLO を継続的に運用したい 一度設定したら、あとは開発に戻りたい SRE としては導入だけではなく、活用 (Enabling) も支援していかないといけない
16. #AWSSummit #PRT216-S Enabling 活動の例 やったこと そこで見えたギャップ 1 ドキュメント作成 New Relic の機能紹介や導入方法を社内の技術スタック に合わせて記載 ⚫ あまり読まれない ⚫ SRE の負荷を軽減するものであって、あるからといって活 用が進むわけではない 2 開発チームとの定例 プロダクトに合わせた New Relic 活用を一緒に推進 ⚫ 開発側に New Relicを 活用するモチベーションのある人が いると一定の効果が出る ⚫ プロダクトにマッチした活用方法の提案が難しく、段々 と頭打ちに 3 アラート移行の支援 アラート設計を行い、IaC 化して開発チームが管理で きるようにする ⚫ 関心は向くものの、やらないといけないものにフォーカ スしてその先の活用に繋がらない ⚫ 期限もあるので設計方針が立てられるSREが作業の大半を 肩代わり 学習型のコンテンツは相手に時間を割いてもらうことが前提 開発者の業務に根差したアプローチをとっていくべきでは？
17. #AWSSummit #PRT216-S 現状の New Relic の利用シーンを考える 課題 ⚫ KTC はエラーログをトリガーにアラートを発報するアプリが多く、発生時は New Relic で調査している ⚫ 調査は個人の New Relic 活用スキルに依存 ⚫ 人によって時間も正確さも大きく変わる／複数人で重複した調査を行い非効率になる場合もある 試行 New Relic の使い方の勉強会 ⚫ 根本的な障害対応のスキル差は埋まらない ⚫ 複数人での重複調査も解消されない 打ち手 調査そのものを自動化するツールを作る 「いっそ自動でまとめてくれればいい」── その実現手段として生成 AI を活用
18. #AWSSummit #PRT216-S 生成 AI を使った Enabling 3
19. #AWSSummit #PRT216-S New Relic Analyzer の開発 ⚫ New Relic Analyzer ⚫ アラートをトリガーに New Relic から関連するログやトレースを収集して要約を Slack に共有 Figure III-1. Service Reliability Hierarchy
20. #AWSSummit #PRT216-S New Relic Analyzer の仕組み ⚫ Java Agent を使ってログにトレース情報を付与しており、fluentbit によって New Relic に送信している ⚫ NEW_RELIC_APPLICATION_LOGGING_LOCAL_DECORATING_ENABLED = true ⚫ New Relic のアラートはログレベルが ERROR を検出して発報 ⚫ SELECT count(*) FROM Log FACET trace.id WHERE entity.name = 'app-name' AND level = 'ERROR' ⚫ trace.id で facet することで、Slack に通知する際のメッセージにトレースID を含めることができる ⚫ {{tag.trace.id}} ⚫ 導入は Slack App を対象のチャンネルに追加するだけ ⚫ 16進数 32文字を含む文字列があった場合に後続の処理を実行し、要約をスレッドに返信
21. #AWSSummit #PRT216-S New Relic Analyzer の効果 把握までの時間が大幅短縮 約20〜30分 1分 Analyzer の効果 ⚫ 要約が Slack に返信され、複数人の重複調査がなくなる ⚫ 共通のコンテキストを持って次の対応に入れる ⚫ 客観的な記述で、エンジニア以外にも分かる粒度 一方で、残る領域 特定リクエストの解析ツールのため、人間の調査・判断が残る部分はまだある 根本原因の分析 影響範囲の特定 リカバリの要否 初動の「把握」は AI が肩代わり。── 人は「判断」に集中できるようになった。
22. #AWSSummit #PRT216-S New Relic MCP の活用
23. #AWSSummit #PRT216-S 2025年11月 New Relic MCP が登場 AI エージェントが New Relic のデータにアクセス・分析するための公式 MCP サーバー 36 のツールを 6 カテゴリ に整理 tag: discovery エンティティや構成を探して把握する tag: data-access NRQL や自然言語でデータを取得する tag: alerting アラートポリシーや条件を確認する tag: incident-response インシデントの状況把握と対応を助ける tag: performance-analytics 性能やゴールデンメトリクスを分析する tag: advanced-analysis デプロイ影響など踏み込んだ分析をする ツール名やパラメータを覚える必要はない ── 「知りたいこと」を自然言語で書くだけ ※ https://docs.newrelic.com/jp/docs/agentic-ai/mcp/tool-reference/ よ り
24. #AWSSummit #PRT216-S New Relic Analyzer の拡張 ① Slack でメンション @New Relic Analyzer に質問すると、 解析とは別ルートで MCP 経由の情報収集 を実行 ② スレッドに返信 収集した結果を要約し、 同じ Slack スレッドにレスポンスを返す ③ 会話を記憶 同一スレッドのやり取りを Bedrock AgentCore のメモリに保存し、 前の会話を踏まえて深掘り New Relic MCP をいち早く取り入れ、New Relic Analyzer に組み込み
25. #AWSSummit #PRT216-S New Relic Analyzer x New Relic MCP ⚫ アラートメッセージで New Relic Analyzer を直接メンション ⚫ エラーログのトレース ID を起点にユーザーの行動までを一度に調査可能に
26. #AWSSummit #PRT216-S New Relic Analyzer x New Relic MCP ⚫ 根本原因特定にも利用可能に ⚫ ECS タスクが落ちていた原因を 3回のやり取りで特定 ⚫ Slack をインターフェースとして間接的に New Relic が活用できている状態へ Figure III-1. Service Reliability Hierarchy
27. #AWSSummit #PRT216-S New Relic Analyzer x New Relic MCP ⚫ 日頃の運用にも活用 ⚫ Botで定時にNew Relic Analyzerにメンションして各環境の前日のエラーログを報告 ⚫ ダッシュボードの定点観測としても活用
28. #AWSSummit #PRT216-S New Relic MCP で変わった世界 これまで ⚫ アラートが鳴るたび、人が調査 ⚫ 調査スキルは属人的、複数人で重複 ⚫ 対応手法を「学んでもらう」しかなかった New Relic MCP と組み合わせることにより ➢ 初動の「把握」は Analyzer が自動でこなす ➢ Slack で AI にメンションし、対話で深掘り ➢ 会話を記憶し、文脈を踏まえた調査が可能に ツールを「プロダクトエンジニアに教える」から、AI と「一緒に調べる」へ。 人は把握作業から解放され、判断と改善に集中できる世界になった。 アラート AI が把握 Slack で対話 人が判断
29. #AWSSummit #PRT216-S 僕たちの開発者体験はどう変わってきているか 本質① 体験が変わる ツールを「使う」体験 価値へ「アクセスする」体験 本質② Observability の民主化 Observability AI 全開発者へ 一部の専門家のものだった可観測性が、 AI を介して全員の手に 観点 Before After 開発者の問い 「New Relic の使い方どうだっけ？」 「何が起きてる？」と聞くだけ 必要なスキル ツールの習熟が前提 知りたいことを言葉にするだけ 向き合う相手 ログ・トレースの画面 会話する AI
30. #AWSSummit #PRT216-S 自律型運用への挑戦 4
31. #AWSSummit #PRT216-S Agentic SRE 成熟度マトリクス Level Monitoring Incident Response Postmortem / Root Cause Analytics Testing / Release Capacity Planning Development Product Lv1 観測 メトリクス/ログ/ト レース収集 インシデント情報を 収集 障害情報・時系列を 収集 リリース影響を観測 使用量・負荷を継続 観測 CI/CD・変更履歴を観 測 SLO/UX/事業指標を観 測 Lv2 判断 正常から逸脱を判断 対応優先度と方針を 判断 原因と再発傾向を分 析 異常と失敗兆候を判 断 将来負荷とボトル ネックを分析 信頼性リスクの高い 変更を分析 ユーザー価値への影 響を分析 Lv3 実行 アラート調整 ダッシュボード生成 障害対応を実行 ポストモーテム作 成・改善実行 安全なリリース制御 を実行 キャパシティ調整を 実行 信頼性向上の変更を 実行 信頼性とUXを考慮し 制御 = New Relic Analyzer の現在のカバー範囲 Monitoring・Incident Response・Postmortem を Lv2（判断）をカバー
32. #AWSSummit #PRT216-S Agentic SRE の成熟ステップ 観測 → 判断 → 実行 レベルが上がるほど人の手は減り、AI が担う範囲が広がる Level 1 観測 AI が情報を収集 Level 2 判断 AI が要約・判断 Level 3 実行 AI が提案・実行 New Relic Analyzer の現在地 Human in the Loop リスク判断 ビジネス判断 信頼性戦略 改善ループを回す
33. #AWSSummit #PRT216-S まとめ 5
34. #AWSSummit #PRT216-S 生成 AI × MCP で切り拓く、次世代 SRE！ 〜自立型運用への挑戦と開発者体験の進化〜 次世代 SRE AI を新しい武器に、 SRE の打ち手そのものを進化 自律型運用への挑戦 観測・判断を AI が担う Agentic SRE が現実になり始めた 開発者体験の進化 Observability を民主化し、 誰もが価値にアクセス SRE のミッションは変わらない。 変わったのは、それを実現する「武器」── 次の道を、AI とともに進化させていく
35. #AWSSummit #PRT216-S mysql > SELECT QUESTIONS FROM you;
36. #AWSSummit #PRT216-S mysql > SELECT ‘THANK YOU’ FROM me;