【New Relic AI MCP × AWS DevOps Agent】さよなら、深夜3時の障害対応。調査はAIに任せて人間は寝る

はじめに

この記事は New Relic Advent Calendar 2025 17日目の記事です。

目次

• AWS DevOps Agentの登場
  • AWS DevOps Agentとは？
  • AWS DevOps Agent の主な機能
• AWS DevOps AgentとNew Relic / GitHub 連携設定
  • 前提条件と環境構成
  • AWS DevOps Agent → AWSリソースの連携設定
  • AWS DevOps Agent → NewRelic / GitHub連携設定
• 【検証】 New Relic AI MCP x DevOps Agent　で障害の原因を特定できるのか？
  • 障害シナリオの確認
  • New Relicにて障害が発生
  • AWS DevOps Agentの自律調査プロセス
• 緩和計画（復旧方法）の提案
• 余談　チャット機能
• まとめ
• 参考: DevOps Agentの調査内容 全体スクショ

なぜ「オブザーバビリティ」を導入しても眠れないのか

インフラエンジニアの皆さま、最後に深夜の障害アラート通知で飛び起きたのはいつでしょうか？

時代はモニタリングからオブザーバビリティへと進化し、ログ・メトリクス・トレースといったシステム全体を知るするしくみ（可観測性）は手に入れました。

しかし、現実はどうでしょう？

• アラートで飛び起き、脳が働かないままPCを開く
• 複数のダッシュボードやソースコードを横断して、画面を行き来するだけで時間が過ぎる
• データは揃っているのに、それを読み解く「人間」が最大のボトルネックになっている

私も経験があるのですが、障害が発生するたびに複数のダッシュボード/コンソールを行き来し、脳が働かない中で原因究明・復旧対応をした経験は皆さまはないでしょうか？

本記事では、この「人間のボトルネック」を最新のAI技術で解消し、エンジニアが安心して「寝ていられる」次世代の障害対応を実現する方法を解説します。

AWS DevOps Agentの登場

本ブログの主題は、先日開催されたAWS re:invent2025 で発表された、AWSの運用特化型の生成AIエージェント「AWS DevOps Agent」となります。

AWS DevOps Agentとは？

従来のチャットボット（Amazon Q）とは異なり、アラート検知をトリガーに「自律的」に調査を開始するエージェントです。
主な機能としては

• 人間が状況を聞く前に、裏側でログやメトリクス、変更履歴を横断して分析してくれる
• 根本原因を特定し、具体的な復旧手順（緩和計画）まで提案してくれる

といった機能があります。

AWS DevOps Agent の主な機能

AWS DevOps Agentには主に３つの機能が備わっています。

自動調査(Investigation）

DevOps Agentが連携している各サービスからログ、メトリクス、トレースといった稼働状況やコードの変更履歴などを横断分析し、問題の根本原因を調査します。

根本原因(Root Cause)

「このエラーは、昨日のこのデプロイ以降増えている」といった根本原因について詳細に解説してくれます

緩和計画(Mitigation plan）

根本原因をもとに、具体的な修正すべきソースコードの指摘やCLIコマンド、「再起動すべき」などの判断材料を提示し、サービスの迅速な復旧を支援してくれます。

外部連携

AWS DevOps Agentはさまざまな外部ツールと連携し調査を行ってくれます。

今回主に紹介するNew Relicも、MCPサーバ(2025年12月時点ではPreview)が登場し、チャットで質問することで、AIがNew Relic上のメトリクスやログを深掘りし調査可能となりました。

New Relic AI MCPについては以前ブログで紹介しているのでまだご存知でなければご覧ください。
AWS GameDayでも大活躍！New Relic MCPサーバーで実現する「話しかけるだけ」のNew Relic活用

この機能をAWS DevOps Agentと連携することができ、人間が質問しなくても自動で調査を進めることが可能となりました。

AWS DevOps Agentの注意事項

• 本記事執筆時点（2025年12月中旬）ではプレビュー版です。そのため、GA（一般提供）までに仕様が変更される可能性があります。
• 現在、バージニアリージョン（us-east-1）のみで利用可能ですが、監視対象はどのリージョンでも可能です。
• 日本語未対応　※この後ご紹介するデモは「翻訳したver. 」となります

そして重要なポイントですが、最終判断は必ず人間が実施しましょう！！！

AWS DevOps AgentとNew Relic / GitHub 連携設定

実際に、意図的な障害を発生させてAIがどう動くか、障害の原因を特定できるのかをやってみます。
まずはその準備のための環境構築を行います。

前提条件と環境構成

今回はこのようなAWS上にコンテナを使ったWebアプリケーションの構成を用意しました。
詳細なCDKのコードは割愛しますが、下記のような環境を準備しています。

• AWSアカウント
  　AWS DevOps AgentはPreview版のため バージニア北部リージョン(us-east-1) を使用。他リソースは東京リージョン。
• New Relicアカウント
  　ECSコンテナに対するNew Relic ECS インテグレーション（APM）を有効化
• GitHubアカウント

AWS DevOps Agent → AWSリソースの連携設定

AWS DevOps Agentの設定

2025年12月中旬現在、東京リージョンでAWS DevOps Agentを開くとこのような画面になります。
利用可能なバージニア北部リージョンで作成をします。

「Begin setup」から実際に設定をしていきます。

エージェントスペース

「Agent Space」 こちらが実際にエージェントが調査をする場所となります。エージェントがアクセスできる範囲と実行可能な操作を制御をします。
こちらをプロジェクトやシステムごとに作成するイメージです。

プライマリアカウントのアクセス設定

DevOps Agent を作成するアカウント(プライマリアカウント)に付与するロールを選択します。
今回は自動設定のIAMロールを利用します。

リソースフィルタリング / Webアプリ設定

リソースフィルタリング
AWSリソースの調査対象をタグで制御することもできます。
今回はCDKで作成したので、スタック名でフィルタしました。
設定しない場合は、IAMロールが確認可能な範囲が対象となります。

Webアプリ設定
こちらはインシデント調査や推奨事項を確認できる Web ページの設定です。
利用するために必要なロールをどうするか設定します。
こちらも自動作成されるDevOps Agentロールを利用します。

設定できたか確認

設定が完了するとこのような画面になります。

しばらくすると、Topologyの箇所が更新されDevOps Agentにチェックされる、管理対象のAWSリソースを確認することができます。

AWS DevOps Agent → NewRelic / GitHub連携設定

AWS外との連携については「Capabilities」で実施します。

今回はこちらに、

1. AWS DevOps AgentにNew Relic AI MCPを設定
2. New Relicの障害通知先にAWS DevOps Agentを追加
3. GitHubとの連携（GitHub Actions）

を実施します。

他機能や設定方法について、AWS DevOps Agentの詳細は、ドキュメント をご確認ください。なお、プレビュー版のため、まだドキュメントも整備中な項目が多いです。

1. DevOps AgentにNew Relic AI MCPを設定

DevOps Agent - Capabilities の画面から、「MCP Server」の「Add」を押下して、
「New Relic AI MCPサーバ」を登録します。

「MCP Server」の中にある、「New MCP Server Registration」を「Register」します。

• Name: 任意の名前 ※スペースは使えない模様
• Endpoint URL: https://mcp.newrelic.com/mcp/
• Enable Dynamic Client Registration: チェックを入れて有効化

を入力します。

認証は「API Key」を利用します。

• API Key Name: 任意の名前
• API Key Header: api-key
• API Key Value: NRAK-xxxx ※New Relicユーザーキー

を設定します。

参考までに、APIキーの作成方法はこちらです。

※「New Relicの障害通知先にAWS DevOps Agentを追加」の章では詳しく手順記載していますので、必要であればそちら参考にしてください。

さいごに、MCPサーバーが使うツールを指定します。
今回は全て有効化しました。

こちらで、AWS DevOps Agentが New Relic AI MCPサーバーを使う設定は完了です。

2. New Relicの障害通知先にAWS DevOps Agentを追加

DevOps Agent - Capabilities の画面から、「Telemetry」を作成します。
「Add」を押下します。

今回はNew Relicを利用するので、New Relicを「Register」します。

New Relic API Key(User key)が必要となるため、New Relicの画面から作成します。

• 調査対象としたいNew Relicアカウントを選択
• Key type: User
• Name: 任意の名前

をそれぞれ設定し、User Key を作成します。

キーが表示されるので忘れずにコピーしてください。

作成したAPI Key(User key)と対象のNew RelicアカウントIDを入力します。

このNew Relic MCPサーバーをエージェントスペースに関連付け、利用可能なすべてのNew Relicツールとリソースへのアクセスを有効にしてください。
とのことなので、「Save」します。

AWS DevOps Agentへ障害通知を連携するための、「Webhook URL」と「API Key」が表示されるのでメモしておきます。※画面は閉じずに連携が完了するまではそのままにしておきましょう。

このようなスキーマをDevOps Agent送ってくださいということなので、New Relicのスキーマを合わせる形で後ほど修正します。

New Relicの通知設定をします。
Alerts - Destinations - Webhook
を押下します。

任意のWebhook名（今回は「DevOps Agent」としました。）とAuthorizationは 「Berer token」を選択します。先ほどメモした、「Endpoint URL」と「Token ※Bearerの部分は不要）」を入力し「Save」します。

あとはDevOps Agentへ障害通知を連携したいWorkflowsを選択し、通知先に作成したWebhookを追加してあげるだけです。DevOpsAgentの画面で、現時点ではどのJSONがどうなるという情報がないので、同じようなKeyでマッピングしてJSONを作成します。

「Send test notification」 を実行して、

Test notification sent successfully

が表示されれば成功です。忘れずに、「Save Message」を押下してください。

New Relicの障害をDevOps Agentで受け取れているか確認

AWS - Agent Spaceの画面から「Web app」を選択して、「Operator access」を押下します。

このように、New Relicの障害通知が、DevOps Agentのインシデントとして記録されていれば成功です！

3. GitHubとの連携（GitHub Actions）

DevOps Agent - Capabilities の画面から、「Pipeline」の「Add」を押下します。

今回はGitHubを利用するので、GitHubの「Register」を押下します。

この後はGitHubとの連携設定となるので詳細は省略します。

ここまでで準備は完了です。これで、NewRelicが障害を検知するとDevOps Agentにも通知がされ、自動で調査が開始されるようになりました。

この後は実際に障害を発生させ、DevOpsAgentがどのような調査を実施するのか詳しくみていきます。

【検証】 New Relic AI MCP x DevOps Agent　で障害の原因を特定できるのか？

実際に、意図的な障害を発生させてDevOps Agentがどう動くかを検証してみます。

障害シナリオの確認

• 障害内容: DB処理を2〜6秒遅延させる pg_sleep() 関数をアプリケーションに埋め込みデプロイ
• 障害通知: New Relicの外形監視（Synthetics）がレスポンス悪化を検知し、DevOps Agentに通知

アプリケーションに意図的に遅いSQLクエリを仕込み、CI/CD経由でアプリケーションの更新を行います。
→ この更新が原因と特定したら、DevOps Agentは本当にすごいなぁと思いながら、検証を進めます。

New Relicにて障害が発生

今回は対象のURLが一定の遅延を超えたら障害通知を行うように監視設定をしています。
対象のURLのレスポンスが異常に遅くなりました。

閾値を超えたことをトリガーにNew RelicとDevOps Agentにて障害（インシデント）として記録されます。

※gifなので動かなければ画像をクリックしてみてください

AWS DevOps Agentの自律調査プロセス

DevOps Agentがインシデントを受信すると、自動で原因調査を開始します。

※gifなので動かなければ画像をクリックしてみてください

ざっくりと下記流れで原因調査〜原因特定までを行います。

1. 調査開始: アラートを受信したDevOps Agentが即座に調査を開始
2. New Relicの分析: 監視内容から状況を確認、APMのトレース情報を参照し、DBクエリがボトルネックであることを特定
3. AWSリソースの相関/デプロイ履歴の調査: CloudTrailやデプロイ履歴を確認し、特定のデプロイ以降に問題が発生していることを発見
4. 根本原因の特定: 「このコミットで導入された pg_sleep() が原因」と断定

本ブログの最下部に、DevOps Agentによる調査の全容のスクリーンショットを添付しています。解像度が荒く申し訳ないですがご参考になれば幸いです。

1. 調査開始: アラートを受信したDevOps Agentが即座に調査を開始

New Relicのデータを検索する上で必要不可欠なクエリ言語、NRQLもMCPと連携して作成・実行してくれます。
→ 特定の情報を抜き出すNRQLを作成するのが運用調査でのつまづきポイントなので、そこを自動で調査してくれるのは非常に嬉しいです。

2. New Relicの分析: 監視内容から状況を確認、APMのトレース情報を参照し、DBクエリがボトルネックであることを特定

もともと1~2msで終わっていた処理が、3~6sec かかることを発見し、DBクエリがボトルネックになっていることを特定しました。

3. AWSリソースの相関/デプロイ履歴の調査: CloudTrailやデプロイ履歴を確認し、特定のデプロイ以降に問題が発生していることを発見

AWSリソースに対する変更や更新作業が行われていないかCloudTrailやCloudWatchメトリクスから調査を行います。

結果、CI/CDにより新しいアプリケーションがデプロイされ、その中に含まれているDBクエリが影響していることを突き止めました。

4. 根本原因の特定: 「このコミットで導入された pg_sleep()が原因」と断定

原因が判明すると、
調査結果と、根本原因を簡潔に解説してくれます。

先ほど記載した、

アプリケーションに意図的に遅いSQLクエリを仕込み、CI/CD経由でアプリケーションの更新を行います。
→ この更新が原因と特定したら、DevOps Agentは本当にすごいなぁと思いながら、検証を進めます。

これをDevOps Agentが見抜くことに成功しました。意図的なクエリとはいえ、ちゃんと発見するとはすごいですね。
何よりすごいのはアラート発生〜原因特定まで、10分も経過していないことです！
エンジニアが夜間対応することを考えたら、PCを開く→各コンソールにログインする間にそれくらいは時間が経ってしまうかもなので、とてつもなく迅速な調査を行ってくれてることがわかります。

緩和計画（復旧方法）の提案

AWS DevOps Agentのもう一つの機能が緩和計画（復旧方法）の提案です。
先ほど特定した根本原因をもとに、具体的な修正すべきソースコードの指摘やCLIコマンド、「再起動すべき」などの判断材料を提示し、サービスの迅速な復旧を支援してくれます。

実行後、しばらくすると緩和計画が表示されます。

実行するコマンドや、確認ポイントなど詳細に記載してくれています。

今回は、下記1〜4の手順を提案してくれました。

1. 準備
   ・現在の構成確認
2. 事前検証
   ・ECSのタスク定義バージョンをロールバックを実施し、動作テスト
   → 影響が出ないかをチェック
3. ロールバックの実行
   ・コミットのロールバックを実行
   ・CI/CDを実行
   ・ECSの更新が成功したか確認
4. 動作確認
   ・新しい（正常な）アプリケーションのデプロイの成功確認
   ・メトリクスの改善確認

のように、最小限の影響となるようなリカバリプランを検討してくれました。
今回の場合はこちらを適用すれば無事にアプリケーションの異常は解消するでしょう。

もちろんAIが提案をしてくれた手順をそのまま環境に適用をするのはリスクがあるので、十分確認した上で実行してください。

余談　チャット機能

DevOpsAgentの画面右側にはチャットで調査内容に関する質問や追加調査を依頼できるチャットスペースがあります。
試しに緩和計画に基づくロールバックの実行を依頼したら成功しませんでした...

どんな機能を備えているか質問したところ下記回答がされました。

AWS DevOps Agent のシステムアーキテクチャ

1. 調査エージェント (Investigation Agent)
   ・パフォーマンス問題を分析
   ・根本原因を特定
   ・緩和策を生成
2. 緩和エージェント (Mitigation Agent)
   ・緩和策を実行する独立した自律エージェント
   ・AWS CLIコマンドの実行機能
   ・AWSインフラストラクチャ（ECS、CodePipeline、CloudWatchなど）との連携が可能
   ・緩和策の各ステップを自動実行
3. タスクチャットエージェント (Task Chat Agent)
   ・調査結果の理解を支援
   ・問題点や緩和策に関する質問に回答
   ・調査エージェントや緩和策エージェントへ指示送信可能
   ・AWSコマンドを直接実行不可 - 他エージェントを誘導

緩和エージェント には AWS CLIコマンドの実行機能/ 緩和策の各ステップを自動実行といった機能を備えているとのことなので今後アップデートで実装されるのでしょうか？この辺りも要チェックですね。

まとめ：オブザーバビリティは「AIが読み解くもの」へ

これまで、オブザーバビリティは「人間がシステムの状態を理解するためのもの」でした。
しかし、New Relic AI MCP / AWS DevOps Agentの登場によりこれからは、「AIが自動でシステムを理解し、人間はその結果を判断するもの」へと進化しつつあります。

今回の検証はプレビュー版であり、リージョンや言語の制約もありますが、そのポテンシャルは計り知れません。New Relic AI MCPと自律型エージェントの組み合わせは、私たちが長年追い求めてきたエンジニアが少しでも「寝ていられる運用」の第一歩となるでしょう。

これらがGAされれば

• 24/365で監視が必要だが、エンジニアの負担を極力減らしたい
• マイクロサービス化が進みシステム把握が困難となり、調査範囲・箇所の判断が難しい
• 障害が発生していた時間や影響範囲の把握調査に時間がかかる
  といった、夜間担当エンジニアの負担がだいぶ軽減できるはずです。

これらのアップデートは引き続きウォッチしていきたいと思います！
それではおやすみなさい。

参考：DevOps Agentの調査内容 全体スクショ

画像が荒くて詳細は見れないですが、調査の全容はこのようになります。
これを10分程度で調査し、原因特定してくれました。