障害対応で時間を使うのは、原因を考える場面だけではありません。監視画面、AWS、コード、デプロイ履歴、ServiceNowを往復し、見つけた情報をチケットへ戻す作業も積み重なります。

2026年8月6日、AWS DevOps AgentをServiceNow MCP Serverへ接続する構成が公開されました。ポイントは、AIにServiceNowを読ませるだけなのか、それともServiceNowの権限制御を保ったまま調査と操作をつなげられるのか、という違いです。

ここでは、インシデントが調査へ渡り、結果が同じレコードへ戻るまでの経路を分けて見ていきます。導入判断に欠かせないIAM、OAuth、ツールACL、契約条件の境界も一緒に整理します。

MCP連携で調査結果をServiceNowのインシデントへ戻せる

AWS DevOps Agentは、Agent Spaceを単位に参照できるリソースや連携先を定め、テレメトリ、コード、デプロイ情報を関連付けて運用上の問題を調査するサービスです。今回の構成では、このエージェントがMCPクライアントとなり、ServiceNow側がMCPサーバとしてツールを公開します。

MCPはAIアプリケーションと外部のデータ、ツール、ワークフローを接続するオープン標準です。ServiceNow MCP Server Consoleでインシデント参照、CMDB照会、変更要求作成などをツールとして選び、AWS DevOps Agentは接続時に利用可能なツールを発見して呼び出します。専用の連携コードに操作を固定するのではなく、公開されたツールのカタログを境界にできるわけですね。

インシデントを受けた後の流れは、次のように整理できます。

1. CloudWatchなどのテレメトリ、デプロイ情報、コード変更を関連付ける
2. ServiceNowから関連インシデント、変更レコード、CMDBの構成情報を取得する
3. 両方の文脈から原因候補と緩和策を組み立てる
4. 調査結果、根本原因分析、緩和計画を元のインシデントへ書き戻す
5. 許可された場合だけ、変更要求作成などのServiceNowアクションを実行する

ServiceNowが単なる結果の保存先ではなく、参照と実行を統制する側に残る点が大切です。ServiceNow Action Fabricの発表でも、MCP Serverを通るアクションはID、権限、監査の管理対象になるとされています。

自動起動とServiceNow操作は2つの接続経路で考える

ここは構成を混同しやすいところです。MCP接続は、AWS DevOps AgentがServiceNowの情報を読み、許可されたツールを実行する経路です。一方、ServiceNowでインシデントが作成された瞬間に調査を始めるには、ServiceNow連携のWebhookとBusiness Ruleを設定します。

AWSのServiceNow接続ガイドでは、チケットの作成や更新をBusiness RuleからWebhookへ送り、対象のAgent Spaceで調査を開始し、主要な発見を元のチケットへ投稿する手順が示されています。したがって、全体は次の2本立てです。

• トリガー経路: ServiceNowのBusiness Rule → Webhook → Agent Spaceの調査
• ツール経路: AWS DevOps Agent → ServiceNow MCP Server → インシデント・変更・CMDBの参照や更新

AWS DevOps Agentの自律インシデント対応は、受け取ったイベントを既存の調査へ結び付けるか、新しい調査として扱うかをトリアージします。Webhookが届くたびに無条件で別調査を増やす仕組みではないため、PoCでは「どのチケット条件をどのAgent Spaceへ送るか」と「関連イベントが同じ調査へまとまるか」をセットで試すと、運用像が見えやすくなります。

IAM、OAuth、MCPツールの3層で権限を狭める

自動調査の権限は一か所では決まりません。AWS側ではAgent Space用のIAMロールが、エージェントから見えるサービス、リソース、リージョンを制限します。AWSのアクセス制限ガイドによると、有効権限はIAMロールのポリシーとサービス側のセッションガードレールの共通部分です。最初は調査に必要な読み取り権限に絞るのが分かりやすいでしょう。

ServiceNow側では、接続に使うOAuthのIDが既存のロールとACLを引き継ぎ、その上でMCPサーバに載せたツールとツール単位のACL、Role Maskingが実行範囲を絞ります。つまり「インシデントを読める」と「変更要求を作れる」は別の許可として設計できます。

ただし、認証手順には公開情報の差があります。2026年8月6日の構成例はOAuth 2.0 Client Credentialsを選ぶ手順ですが、ServiceNow社員が2026年7月1日に更新したMCP Server Console FAQはAuthorization Code Grantのみをサポートし、Client Credentialsは未対応と説明しています。記事の手順をそのまま本番へ写す前に、利用中のServiceNowリリースとパッチ、MCP Server Consoleの画面、ServiceNowサポートの回答をそろえる必要があります。

FAQでは、SubflowとActionをMCPツールにする場合はAI ACLが必須で、待機や承認を含む非同期フローは対象外とも説明されています。既存の承認フローがそのままツールになるとは限らないため、変更要求作成まで自動化したいチームほど先に互換性を見ておきたいところです。

Agent Spaceの配置とServiceNowの契約条件を先に確定する

AWS DevOps Agentは2026年3月31日に一般提供になりました。2026年8月7日時点の対応リージョンには東京を含む11リージョンがあり、運用調査機能は全対応リージョンで利用できます。Agent Spaceの調査データやトポロジーは作成したリージョンに保存され、MCPサーバなどの外部連携はAgent Spaceごとに設定します。

導入前に必要なものは、AWSアカウント、Agent SpaceとWebアプリ用のロール、AWS DevOps Agentへのアクセス、ServiceNowの管理権限、ServiceNow MCP Serverです。複数のServiceNowインスタンスを扱う場合も、2026年6月13日から1つのAgent Spaceへ複数インスタンスを登録可能になっています。環境ごとにAgent Spaceを分けるか、1つへ集約するかは、データ境界と運用担当の分け方から決められます。

ServiceNowの利用資格は、公開情報だけで一意に確定できません。構成例はAI NativeのFoundation、Advanced、Primeまたは単体MCPアドオンを前提にしますが、2026年3月更新のServiceNow product tiersはInbound MCP ServerをPrimeのみと掲載し、契約上の利用可否はアカウントチームへ問い合わせるよう案内しています。一方、2026年5月のAction Fabric発表は、MCP ServerがすべてのNow AssistおよびAI Native SKUに含まれるとしています。契約名だけで判断せず、対象インスタンスのentitlementと消費単位を見積もり時に確認するのが安全です。

PoCは読み取りから始め、チケットの完全性と費用を測る

最初のテストは、構成例と同じく「過去1週間のインシデントを表示する」といった読み取りクエリで十分です。正しいツールが選ばれ、想定した件数とフィールドだけが返り、呼び出しを監査できることを確認してから、自動トリガーとチケット更新を追加します。

次の段階では、限定したカテゴリやサービスのテスト用インシデントをBusiness Ruleから送ります。調査結果について、少なくとも次を記録しておくと比較できます。

• 元のインシデント番号と調査IDが正しく対応したか
• 関連変更、影響リソース、時刻の情報が欠けていないか
• 同じ障害から複数イベントが来たときに重複調査が増えないか
• 読み取り失敗や権限不足が、空の結果と正常結果として混同されないか
• 人が調査を始められる情報がそろうまでの時間が従来より短くなったか

「数時間が数分になる」という効果は構成例の主張であり、比較条件や測定結果は公開されていません。自社の平均復旧時間を先に約束するのではなく、手作業の転記回数、初動に必要な情報の充足率、調査開始までの時間を同じ条件で測る方が判断しやすいです。

費用もPoCの測定項目に入ります。AWS DevOps Agentの料金はエージェントが作業した秒数に基づき、CloudWatch Logs Insightsなど接続先AWSサービスの料金は別に発生します。ServiceNow側のAssist消費やMCPの利用資格と合わせ、1件あたりの調査時間と月間件数から見積もる必要があります。

ServiceNowを記録先から権限制御された実行面へ変える

AWS DevOps AgentとServiceNowのMCP連携が解くのは、調査ツールを一つに統合する問題ではありません。AWS側で得たテレメトリと変更の文脈を、ServiceNowが持つインシデント、CMDB、変更管理の文脈へつなぎ、結果と許可済みアクションを同じ統制面へ戻す設計です。

すでにAWSとServiceNowを運用の中心に置くチームなら、まず読み取り専用のMCPツールと限定したBusiness Ruleで一つのサービスを試す価値があります。OAuth方式とentitlementの差異を解消し、正確性、監査、費用を測ってから書き込み権限を増やす。この順序なら、自律化を急がずに、コンテキスト切り替えを減らせる範囲を具体的に見極められます。

出典

• Title: Scaling Autonomous Operations with AWS DevOps Agent and ServiceNow
• URL: https://aws.amazon.com/blogs/devops/scaling-autonomous-operations-with-aws-devops-agent-and-servicenow/