# Modernizing Incident Response with LLMs, RAG, and the MCP Navigation: [[agentic SRE]] | [[Model Context Protocol]] | [[RAGベースクラウド運用支援]] ## 概要 USENIX SREcon25 EMEA(2025-10-08、ダブリン)での [[Theofilos Papapanagiotou]]([[Amazon]])による発表。Amazon 内部で数十万規模の API サービスを支える SRE チームが、属人化した知識と分断されたツールインターフェースの課題を、[[Model Context Protocol]](MCP)による人間・エージェント共通のツールカタログと、[[RAGベースクラウド運用支援|RAG]](OpenSearch + Bedrock Titan embeddings)による知識検索で解決しようとした取り組みを報告する。「自動化ではなく理解を目指した」という主張を軸に、データ・推論・協調・評価の 4 領域で実装と学びを提示する。 ## 主要メッセージ - 障害対応の知識(メトリクス・ログ・チケット・デプロイ履歴・トポロジー・ランブック・オーナーシップ)は、MCP という人間とエージェント共通のツールハンドルで標準化できる(p.20, p.24)。 - 人間とエージェントは同一データ・同一インターフェースから推論すべきである(p.56)。同一の Grafana パネルを見ても、人間は「10分の低下」、エージェントは「12分の低下」と推論するズレが起こり得る(p.57)。 - 中心的な主張は「自動化ではなく理解を目指した(It wasn't automation, it was understanding)」ことにある(p.58)。 - Promptfoo によるオフライン評価とユーザーフィードバック(サムズアップ/ダウン)が、プロンプト改善のフライホイールを駆動する。直感ではなく評価が改善の根拠になる(p.61-p.62)。 - フィードバックはエージェントの教師信号として機能する。口頭説明では offline evaluation 94.4%、user feedback 73% という実績値が言及された(p.62)。 - 信頼性の定義が uptime 中心の system reliability から、discoverability・explainability・reasoning を含む cognitive reliability へ拡張する(p.65-p.66)。 ## 視覚的に重要な図表 **p.20 MCP アーキテクチャ図** ![[_attachments/srecon25emea-papapanagiotou-mcp-incident-response/page-020.png]] tabular/documents・streams/metrics・API といったデータソースが、metrics()/logs()/tickets()/deployments()/topology()/runbook()/ownership() から成る MCP ツールスタックに流入し、human と agent の双方へ矢印が伸びる。`langchain_mcp_adapters.client.MultiServerMCPClient` と `strands.tools.mcp.MCPClient` のコード引用を伴う。 **p.24 認証アーキテクチャ** ![[_attachments/srecon25emea-papapanagiotou-mcp-incident-response/page-024.png]] 人間セッションの IAM ロールと、Python ランタイム(boto3)が引き受けるエージェントの IAM ロールが、同一の MCP ハンドルを異なる権限スコープで利用する構成を示す。口頭説明では、人間クエリはユーザーセッションによる委任、エージェントクエリはランタイムが引き受ける IAM ロールによる認可と説明された。 **p.38 RAG インデクシングコード** ![[_attachments/srecon25emea-papapanagiotou-mcp-incident-response/page-038.png]] `OpenSearchVectorSearch.from_documents` と `BedrockEmbeddings(amazon.titan-embed-text-v1)` を組み合わせた実装例。口頭説明では、ドキュメント全体でなく Markdown のセクション単位で分割してインデクシングする方が有効だったと補足された。 **p.56 同一インターフェース図** ![[_attachments/srecon25emea-papapanagiotou-mcp-incident-response/page-056.png]] Prometheus/CloudWatch → Grafana → image renderer → metrics() という、MCP 経由の経路と人間の伝統的な閲覧経路を並列に描き、両者が同じデータ・同じツールを通過することを示す。 **p.57 human/agent 比較** ![[_attachments/srecon25emea-papapanagiotou-mcp-incident-response/page-057.png]] 同一の Grafana グラフに対し、人間は「10分間の低下」、エージェントは「12分間の低下」と読み取る例を並べ、画像入力によるエージェントの推論結果が人間の直感に近い水準にあることを示す。デプロイバージョン 4.2.4 と時期が一致するという追加の仮説提示も口頭説明で言及された。 **p.62 Feedback as supervision** ![[_attachments/srecon25emea-papapanagiotou-mcp-incident-response/page-062.png]] Average duration 565ms、Offline evaluation 94.4%、User feedback 73% という指標をダッシュボード形式で表示する。各指標の定義・計測期間はスライド上に明記がなく不確実。 **p.66 System reliability → Cognitive reliability** ![[_attachments/srecon25emea-papapanagiotou-mcp-incident-response/page-066.png]] redundancy / alerts / uptime / MTTR という従来の信頼性指標群から、discoverability / explainability / reasoning という認知的な指標群への移行を図示する。 ## 口頭説明・補足 - 講演冒頭で、オンコールエンジニアが見慣れないサービスのアラートを受け取り、Grafana・CloudWatch・ドキュメントを行き来しながら原因を推測する典型的な負荷を紹介し、「システムはどうすれば人間の思考を助けられるか」を問いとして提示した。 - 組織内の独自語彙(例: ロードバランサーを "tardigrade" と呼ぶ内部俗称)が汎用 LLM に理解されない問題を挙げ、埋め込み生成時に組織固有の用語辞書を注釈として付与する対処を紹介した。 - 本番環境での変更提案には、エージェントの推論過程とドライラン結果を提示したうえで人間が承認する「サムズアップ」ゲートを設け、最初の仮説提示までの SLO を 30 秒とする設計目標を挙げた。 - プロンプティング手法として Chain-of-Thought・Plan-and-Execute・ReAct の 3 種を比較し、ReAct(思考→行動→観察のループ)が学術的には最も良い結果を示すとした。 - 評価には Promptfoo を用い、チケットの説明・タイトルと期待される仮説を対にした社内ベンチマークデータセット("save to bench")を構築したこと、LLM-as-judge によるアサーションも併用することを説明した。プロンプトとベンチマークデータセットの両方をバージョン管理する重要性を強調した。 - メトリクスは system metrics(latency、token 数とそのコスト)、task metrics(オフライン評価の pass rate、ユーザーフィードバックの thumbs up/down、task completion rate)、tool metrics(ツール選択の正解率、パラメータの正解率)の 3 分類で捉えると説明した。 - 時系列データを画像としてエージェントに渡す方が、CSV/JSON のような表形式データを渡すよりも異常検知の推論精度が高いという DeepMind の研究を引用し、Grafana の image renderer プラグインを活用する理由とした。 - Amazon 社内ではこの改善サイクルを「flywheel」と呼び、評価→洗練→フィードバック収集→集約評価という反復が新バージョンのデプロイと観測を促すと述べた。 - 結びとして「SRE = Site Reasoning Engineering」という再定義を提案し、今後の課題としてユーザーフィードバックをオフライン評価フレームワークへ組み込むこと、モデルの役割設定を「画像解析アシスタント」から「SRE エンジニア」へ発展させることを挙げた。 ## 概念・実体への接続 - [[Model Context Protocol]] — 本講演のツール標準化の中核。人間とエージェントが同一ハンドルを異なる権限で使う認証設計の産業実装例を追加する。 - [[agentic SRE]] — MCP による本番アクセス標準化と、評価駆動開発によるプロンプト改善ループを持つ産業実装として位置づけられる。 - [[RAGベースクラウド運用支援]] — OpenSearch + Bedrock Titan embeddings による社内知識ベース検索の実装例。Markdown セクション単位でのチャンク分割という具体的知見を持つ。 - [[Theofilos Papapanagiotou]] — 登壇者。[[Amazon]] で SRE インフラを支えるチームに所属。 - [[Amazon]] — 実装の主体組織。Bedrock・OpenSearch・boto3 等の AWS スタックを内部利用。 ## 限界・不確実点 - p.49・p.50・p.68 のグラフ上部には黒塗り(社内サービス名等)があり判読できない。 - p.60 のトレース UI に表示される環境ステージ名の一部(社内固有名詞)は表記の正確性が不確実。 - p.62・p.68 の各種指標(offline evaluation 94.4%、user feedback 73% 等)は、定義・計測期間・母数がスライド上に明記されておらず、口頭説明でも詳細な補足はなかった。数値としては引用するが解釈には注意を要する。 - p.68 の Promptfoo pass rate 一覧(94.44%〜55.56%)は各行に対応する評価項目名が明示されておらず、意味が不確実。 - 発表動画(YouTube: THX_qkVLMPw)の Whisper 文字起こしを用いたが、内部用語(tardigrade 等)や固有名詞の書き起こし精度は完全ではない可能性がある。