障害調査を迅速化するため、MCPでAWS DevOps AgentからBacklogの課題・ナレッジを参照できるようにしてみた

障害調査を迅速化するため、MCPでAWS DevOps AgentからBacklogの課題・ナレッジを参照できるようにしてみた

AWS DevOps AgentのインシデントレスポンスからBacklogのデータをリアルタイムで参照できるよう、カスタムMCPサーバーをLambdaで構築しました。OAuth 2.1認証やLambda Web Adapterの採用など、構成と設計の概要をまとめています。
2026.04.12

こんにちは、カスタマーサクセス部のやまとです。

AWS DevOps Agentは、AWS環境のメトリクスやログを自動で調査し、根本原因の分析から緩和策の提示までを自律的に行うフロンティアエージェントです。インシデントの解決に加え、再発防止の提案もカバーしています。

https://aws.amazon.com/jp/devops-agent/

今回は、このAWS DevOps Agentとプロジェクト管理ツールの「Backlog」を、MCP経由で連携させました。本記事では「何をしたか」「なぜやってみたのか」「どういう構成か」など概要をざっくりまとめてみました。そのシステムの実装や実践的な調査に関して今回はスコープ外としています。

結論

実装できました!

AWS DevOps Agentの機能「インシデントレスポンス」から、特定のBacklogプロジェクト内の情報をリアルタイムかつ同期的に取得し、調査のコンテキストの中で参照させることに成功しました。

実例

  1. インシデントレスポンスから「<BacklogドキュメントのURL>からMCP経由で情報を取得し、実際に調査を行ってください」と依頼
    Starting an investigation by providing a Backlog document URL
  2. 今回はテストとしてLambdaに特定のタグがついているものを調べさせます。ちゃんとBacklogドキュメントを読み込めているか確認するため、ドキュメントに以下の記載を施します。
    Example of investigation instructions written in a Backlog document
  3. 結果がでました!ちゃんとBacklogドキュメントを参照して調査を進めています!
    Investigation results: The agent autonomously identified the target Lambda functions
  4. 確認のため、Lambdaコンソールにもアクセスします。正しい情報をもとに調査できています。
    Verifying the results in the AWS Lambda console
  5. ついでにSlackにも連携させており、そこもしっかり反応してくれてました。
    Automated Slack notification for the started investigation

なぜやってみたのか

一般的な障害対応だと、「Backlogで課題を起票してから、別画面でAWSのログやメトリクスを見に行く」という流れになると思います。また、調査を行う際に、必要なシステム情報や対応方針をBacklogなどの管理ツールから調べることもプロジェクトによっては発生します。このような「ツール間の往復」や「インプットの手間」を効率よく実施できないかというのが今回の出発点です。

期待していたのは以下の3点です。

  • 調査の初動にかかる時間の短縮:Backlogに起票された課題の情報をエージェントが直接読めれば、コンテキストを学習させる工程が不要になります。
  • 蓄積済みナレッジの調査中参照:BacklogのWikiやDocumentに記録されている運用手順を、エージェントが調査中に参照できれば、特定の運用ルールに沿った対応が可能になります。
  • ナレッジ検索:「あの手順どこだっけ」をエージェント自身で問い合わせする導線ができれば、検索の手間が減ります。

これらを検証するため、PoCとして着手しました。

システム構成

今回構築したシステムの構成図です。

※ aws-diagram-mcp-serverで生成した構成図
System architecture of the AWS DevOps Agent and Backlog integration

構成上の判断(工夫したこと)

  • Lambda Web Adapter:今回、MCPサーバーはPythonの「FastMCP」を用いてStreamable HTTPサーバーとして実装しています。これをそのままAWS Lambda上で動かすために使用したのがLambda Web Adapterです。これを使うことで、既存のWebフレームワークで作られたコンテナ化アプリケーションを、コードを変更せずにサーバーレス環境で実行できました。
  • API Gateway HTTP API:LambdaをHTTPで公開するにはLambda Function URLを使うのが簡単ですが、組織のセキュリティポリシー(CloudFormationのEarly Validationフックなど)でURLの直接公開が禁止されているケースを想定して、前段にAPI Gatewayを配置しました。
  • APIキーの分離:BacklogのAPIキーは、Lambdaの実行ロール経由でのみSecrets Managerから取得する構成にしています。DevOps Agent側にはこのキーを一切渡していないため、万が一エージェントがプロンプトインジェクションを受けた場合でも、エージェント経由でBacklogのAPIキーが漏洩する経路を物理的に遮断しています。

既存のBacklog MCPサーバーではそのまま接続できない

公開されている既存のBacklog MCPサーバーをそのまま登録しようとしても接続できません。原因は2点です。

  1. 通信プロトコルの違い

    既存のBacklog MCPサーバーはローカル実行前提の stdio トランスポートのみに対応しています。AWS DevOps Agentが外部のMCPサーバーと通信するには、HTTPS経由の Streamable HTTP プロトコルへの対応が必要です。

  2. Investigation Agent固有の認証要件

    DevOps Agentのチャット機能(Chat Agent)から呼び出すだけであれば、API Key認証でも通りました。しかし、自律的にインシデント調査を行う「Investigation Agent」にツールを認識させ実行させるには、事実上以下の認証フローの実装が必須であることが検証で判明しました。

    • OAuth 2.1: セキュリティが強化された最新の認可フレームワーク標準です。
    • Dynamic Client Registration (DCR): クライアント(DevOps Agent)が動的に自身を認可サーバー(今回のカスタムMCPサーバー)に登録する仕組みです。
    • PKCE (Proof Key for Code Exchange): 認可コードの横取り攻撃を防ぐためのOAuthのセキュリティ拡張仕様です。

以上から、要件を満たすカスタムMCPサーバーをAWS上に構築する方針にしました。

構築の流れ

手順の概要です。

  1. アプリケーションコードの実装:PythonとFastMCPで、Backlog APIを呼び出す読み取り専用のツール(backlog_list_projectsbacklog_get_document など)を定義します。OAuth 2.1のエンドポイントも同一アプリケーション内に実装します。
  2. シークレットの登録:AWS Secrets Managerに、BacklogのAPIキー、MCPサーバー用のAPIキー、OAuth JWT署名用のシークレットを登録します。
    Authentication secrets securely stored in AWS Secrets Manager
  3. デプロイ:コンテナの構成を定義する「Dockerfile」と、AWSリソースを定義するSAMテンプレート(template.yaml)を用意します。sam build から sam deploy を実行することで、API GatewayとLambdaコンテナ環境を自動構築します。
  4. DevOps Agentへの登録:DevOps Agentコンソールの機能プロバイダーから設定を行います。機能プロバイダーとは、MCPサーバーやCI/CDパイプラインなどの外部ツールをAWSアカウントレベルで登録し、一元管理するための機能です。ここでAPI GatewayのエンドポイントをMCPサーバーとして登録し、対象のAgent Spaceに紐付けます。
    Registering the custom MCP Server in Capability Providers

登録が完了すれば、DevOps Agentの画面から「Backlogの<特定のプロジェクト>の課題やドキュメントを検索して」と指示するだけで、エージェントがBacklog APIを呼び出して結果を返してくれます。

コスト

この構成の月額コストのざっくりとした内訳です。

MCPサーバー側:LambdaとAPI Gatewayはリクエスト単位の従量課金であるため、待機コストはほぼかかりません。主なコストはSecrets Manager(シークレット1つあたり月額$0.40)で、今回は3つ登録したため月額$1.20になりました。

DevOps Agent本体:エージェントがインシデント調査や評価などのタスクを実行した秒数に対して、$0.0083/秒で課金されます。アイドル状態や待機中には一切課金されません。

さいごに

今回は「AWS DevOps AgentとBacklogをMCP経由で連携させる」という検証結果の概要をまとめてみました。

構築の過程では、FastMCPのDNS Rebinding Protection(本来は悪意のあるサイトがブラウザを踏み台にしてローカル環境へアクセスするのを防ぐセキュリティ機能)が有効になっていたため、API Gateway経由のリクエストが不正なホストからのアクセスと見なされて421エラーで弾かれたり、Lambdaの水平スケール時にメモリ上のMCPセッションが消失してしまいツールが呼ばれなくなる問題(stateless_http=True オプションで解決)など接続成功するまでに何度も壁に阻まれました。

実装の手順や技術的な詳細、調査デモについては、それだけでブログ1本分以上のテーマになるので、本記事ではここまでとします!AWS DevOps AgentとBacklogの連携はインシデント調査の実践的な活用方法で、業務に役立つと思いますので、みなさんも是非試してみてください!

参考資料

AWS運用エンジニア(24x365)募集

クラウド運用チームで AWS エンジニアを募集中!クラウドに関する Web システムや基幹システムの運用保守経験をお持ちの方を歓迎します。先輩エンジニアによる丁寧な OJT 研修、AWS 資格取得支援など充実のサポート体制で、AWS未経験からでも安心してAWS運用エンジニアとしてのキャリアをスタートできます。

▼ 詳細・応募はこちら

https://www.career-cloud.asia/mid/entry/job/offer/annotation/detail/4958

※ カジュアル面談も実施中!まずは話を聞いてみたいという方も大歓迎です。

AWS運用代行・サーバー監視のご案内

クラスメソッド マネージドサービスは、AWS国内支援実績No.1のクラスメソッドが提供する、クラウド特有の対応やクラウド技術者の不足に課題をお持ちのお客様向けのAWS運用トータル支援サービスです。
監視や運用支援にとどまらず、お客様のクラウド利用を最適化し日々の負担を最小化することで、お客様のビジネス効果の最大化を支援します。

https://classmethod.jp/aws/services/operating/

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。

この記事をシェアする

関連記事