AWS DevOps Agentの全体構造と設定箇所を図解してみた
はじめに
今回は、AWS DevOps Agentの構造を改めて正確に理解するために図解していきます。自分は、DevOps Agentのベータリリースの時に触っていました。最近のDevOps Agentの設定内容を見ると当時より大幅に進化しています。
ただ、逆に複雑になってきていることで、1から理解する情報はまだ少ないかと考えたので改めて整理します。これによって、今後DevOps AgentをPJへ展開する前にどんなものなのか理解して進めることの助けになれば幸いです。
全体構造
DevOps Agentは主に以下のような構造をもっています。主にユーザー側で設定が調整可能な部分にフォーカスして書いています。
- Capability Providers(機能プロバイダー)
- Agent Space
- Web App
- Knowledge(Instructions/Skill/Memory)
- Custom Agent
- Web App
DevOps Agentの画面上だと、左のサイドバーにあります。
おおまかな図で書くと以下のような構造です。
ここからそれぞれの機能や設定内容について紹介していきます。
Capability Providers
Capability Providers(機能プロバイダー)は、主に外部やアカウント内部のVPCなど、どんなサービスと接続するか設定する部分です。各サービスとの認証情報を使った接続設定をこちらで行い、後述するAgent Spaceではサービスごとに、どのリソースと接続するかの詳細な部分を設定します。主には以下のサービスとの接続を設定できます。図にすると以下のようなイメージです。
Cloudとしては、Azureとの接続が設定できます。AzureテナントというAWSでいう管理アカウントのような単位で接続設定を行い、AzureサブスクリプションというAWSでいうアカウントのような単位で接続を設定する2段階になります。AWSに詳しい方は、Azureの各サービスが何に相当するのかをまとめたこちらの記事が参考になります。
個人の所感ですが、Azureテナント全体に管理者同意を与えるAdmin Consentは結構ハードルが高そうです。その場合は自前でEntraアプリケーションを作るApp Registrationも選べます。AzureにはDevOps Agentと似たようなSRE Agentがあるので、AWSでの実装が多い組織で、一部のみAzureでリソース管理をしているような会社なら選択肢に入りそうです。
Telemetryとして複数のSaaSと接続できます。SaaSごとに接続設定が異なります。例えば、DynatraceであればOAuth、Grafana/New Relicであれば固定のキー情報を設定して接続します。これらに接続することにより、各SaaS側が持つメトリクスやダッシュボード、アラートなどの監視データを調査用のコンテキストとしてDevOpsエージェントに渡すことができます。
Pipelineでは、ソースコードやCI/CDの管理サービスと接続することができます。現在は、GitHub/GitLab/Azure DevOpsと接続できます。GitHub Organization単位で接続を設定すると、ソースコードやコミット情報、issue/Pull Request、GitHub Actionsなどの読み取り/書き込み操作を許可することになります。読み取り権限のみにしたい場合用の設定もあります。より細かく権限を設定したい場合は、Fine-grained PATを作ることで調整できます。
書き込み操作までを許可するのに抵抗がある場合や、特定のリソースの読み取り許可をしたくない場合も、細かく設定でき影響範囲を狭めた状態から開始できます。
Communicationでは、チケット管理や外部チャットと接続できます。Slackの場合は、Slack上のチャット情報を取得したり、SlackからDevOps Agentにメンションして作業を指示したりということができます。ServiceNowではインシデントチケットの起票に合わせて、DevOps Agentを起動し調査させることもできます。以下のページが参考になりました。
External Capabilitiesと独自でまとめていますが、こちらではMCP ServerやRemote Agentの接続もそれぞれ設定できます。
MCP Serverは、Streamable HTTPトランスポートプロトコルを採用しているサーバのみ接続できます。認証のフローとしては、現状以下の5つが設定できます。
- OAuthクライアント認証情報
- OAuth 3LO
- APIキー
- 複数Authヘッダー
- AWS SigV4
OAuthでの複数の認証設定もできますし、APIキーやヘッダーなど固定の認証情報、AWS SigV4も選択できます。DevOps Agentとして、デフォルトで接続を提供しているサービスもありますが、それ以外のサービスもMCP経由で接続範囲を拡大できます。リモートでMCPサーバを提供しているサービスであればOAuthやAPIキーで接続できます。また、ローカルMCPサーバや独自のMCPサーバを作って接続したい場合は、Lambda上にリモートMCPサーバとしてホストすることで接続できます。
Remote Agentは、Agent-to-Agent(A2A)プロトコルでAIエージェント間を接続することで、DevOps Agentが必要に応じて外部のAIエージェントを利用できるようになります。これにより、インシデント調査時にほかのSaaSが提供するエージェントと協調して詳細な調査が行えます。この部分では、DevOps Agent→Other Agentへの接続を設定できます。Other Agent→DevOps Agentの通信をする場合は、DevOps AgentのWebアプリから設定できます。
Private Connectionsでは、VPC内のプライベートなサービスへの接続を設定できます。VPC Latticeを使い、Resource Gateway経由で対象サービスのIPアドレスやDNS名にアクセスします。これにより、VPC内のアプリケーションやプライベートネットワークのアプリケーションへもVPC経由で接続できます。詳細は、以下の記事が参考になりました。
ここまでが、Capability Providersの設定でした。前述したように大まかな権限設定はこちらで行い、詳細設定はAgent Spaceで行います。次にAgent Spaceを紹介していきます。
Agent Space
Agent Spaceは、障害やサービス状況を調査するスコープを定義する機能です。AWSアカウントや他のクラウドサービス、テレメトリ/ソースコードなどの接続範囲などをまとめて設定できます。またエージェント操作を行うアプリケーションもあります。先にAgent Space上で設定できる内容を図で紹介します。
Account Permission
DevOps Agentのリソースアクセス権限と利用者向けのアクセス権限として、以下のように3つのロールが設定できます。
- Monitoring Role（読み取り用）
- Elevated Role（更新用）
- Operator Role（Agent SpaceのWebApp操作用）
Monitoring Roleは、DevOps Agentがどんな範囲でリソースを読み込んで良いかを設定します。デフォルトのロール/ポリシーを使用すると、多くのサービスの読み取り権限だけを設定できます。読み取りはできますが、S3やDynamoDBなどの業務情報が含まれるようなサービスのデータそのものへのアクセスは許可されていないです。もしここのS3のデータだけみて欲しいという場合は、権限を追加でインラインポリシーに付与してあげる必要があります。権限を追加してもDevOps Agent自体の機能ガードレールが働いてブロックされる場合があります。詳細は以下を参考にしてください。
Elevated Roleは、更新系の操作で利用されます。更新系の操作では、DynamoDBのテーブル作成/データ追加、Lambdaの同時実行数なども多くの内容が更新できます。Elevated Roleを登録しても、Agent Spaceで設定を有効化しない場合、読み取り調査と手順提示のみになります。
更新系の操作自体は、AIエージェントが自動実行すると2次災害が発生する可能性があるため、人間による確認が必須となるように設計されています。ですので、人間が気付かぬうちに設定を変更して問題が起きているという事態は防げそうです。また、サービス側ガードレールとして、削除系の操作とiam:PassRoleを要する操作は承認しても実行されないよう制御されています。
Operator Roleは、DevOps Agentに指示を行ったり、ナレッジを設定したりやりとりをするWebアプリの操作用ロールになります。ユーザーは、AWSのコンソールでDevOps AgentのIAM経由で起動するのボタンを押したり、ウェブアプリリンクからURLにアクセスするとこのロールをAssumeしてWebアプリを操作します。
Cloud
Cloudの部分では、上記のAccount Permissionの部分と合わせて、他のAWSアカウントへの接続やAzure Tenant/Subscriptionとの接続を管理できます。他のアカウントに接続する場合は、ServiceLinkedRole作成用ロールとElevated Roleの2種類を設定することになります。ServiceLinkedRole作成用ロールを他のアカウントに設定して、DevOps Agentから他のアカウントに向けてServiceLinkedRoleを作成可能な状態にすると自動でロールが作成されます。Elevated Roleの方は、Agent Spaceでロールを設定する場合とほぼ同じ内容になります。
これらの設定を行うことで、複数のAWSアカウントで横断的に操作を行なっているようなAWSリソースを簡単に監視し、問題発生時のエージェント調査もやりやすくなります。
Azureとの接続は、TenantやEntraアプリケーションなどへの紐付け設定はCapability Providerで行い、Azure Subscriptionへの紐付けはAgent Space単位で行います。詳細が気になる場合は以下をご確認ください。
Telemetry/Pipeline/Communication/External Capabilities
Capability Providersと同じように、Telemetry/Pipeline/Communication/External Capabilitiesを設定できます。こちらでは、より詳細な設定を行います。例えば、GitHubであれば接続可能なリポジトリの設定、Slackなら連携するチャンネルの設定などを行えます。MCPサーバの場合だと認証設定は、Capability Providersで行い、Agent SpaceではどのMCPでどのツールの使用を許可するかを設定します。
その他設定
他には、Webhookとプレビュー機能としてSandboxがあります。
Webhookでは、サードパーティのアプリやサービスがイベントを飛ばしてDevOps Agentの調査を実行できます。他のサービス→DevOps Agentの方向のHookになります。以下のようなデータスキーマでpayloadを作って、シークレットによるHMAC署名かAPIキーのどちらかで接続できます。APIキーだと以下のようになります。
interface Payload {
eventType: 'incident';
incidentId: string;
action: 'created' | 'updated' | 'closed' | 'resolved';
priority: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "MINIMAL";
title: string;
description?: string;
timestamp?: string;
service?: string;
// The original event generated by service is attached here.
data?: object;
}
function sendEventToWebhook(webhookUrl, secret) {
const timestamp = new Date().toISOString();
const payload: Payload = {
eventType: 'incident',
incidentId: 'incident-123',
action: 'created',
priority: "HIGH",
title: 'Test Alert',
description: 'Test description',
timestamp: timestamp,
service: 'TestService',
data: {}
};
fetch(webhookUrl, {
method: "POST",
headers: {
"Content-Type": "application/json",
"x-amzn-event-timestamp": timestamp,
"Authorization": `Bearer ${secret}`,
},
body: JSON.stringify(payload),
});
}
今のところは各Agent Spaceには、HMAC用Webhookを1つとAPIキー用Webhookを1つだけ設定できます。DynatraceやServiceNowなどのサービス固有のWebhookは各サービスの設定時に自動生成されます。
Sandbox機能は、アウトバウンド通信を制御したり、プリインストールするパッケージを設定したりできます。2026/09/21時点では、pip/npmのパッケージ、アウトバウンドで通信できるドメインやメソッド、パスパターンの許可を調整できます。プレビュー機能のためus-east-1/us-west-2/ap-northeast-1/eu-west-1の4リージョン限定で利用できます。
DevOps Agentの実行時に、追加のパッケージを使って詳細な調査をさせたり、コードを使ってエージェントに実装しながら調査させることができます。気になる場合はこちらのブログが参考になります。
Web App
Agent Spaceに対して実際にユーザーが指示したりするものとして、WebAppがあります。これは、Agent Spaceのウェブアプリリンクなどから起動できます。アプリ自体の接続は、AWSコンソールにサインインしているセッションをそのまま使えますし、IAM Identity Centerの組織インスタンス/アカウントインスタンスの権限、外部IdPも利用できます。IAM認証は30分のセッション期限があるので、可能な限りIAM Identity Centerに移行するのがおすすめです。IAM Identity Centerに移行すればセッション時間を最大12時間まで延長できます。
ログインすると以下のような画面になります。一般的な指示はこのチャットからできます。実行中の調査はインシデントレスポンスから見られます。
今回はDevOps Agentの構造把握を目的とするため、カスタムエージェントとナレッジの部分を紹介します。図にすると以下のような構造です。
カスタムエージェント
カスタムエージェントは、ユーザー側で独自に設定を定義できるAIエージェントです。障害発生時の調査や予防だけでなく、ユーザー側で希望する調査をまとめて定義できます。実態としては、システムプロンプトと後述するナレッジのスキルやメモリを接続して設定します。設定方法はフォームに入力するか、チャットで指示するか、GitHubで公開されているものを追加するかの3通りがあります。
以下のリポジトリでコミュニティから公開されているものもあり、追加可能です。
以下のURLのように直接エージェント用のMarkdownファイルのURLを指定すると読み取れます。
ナレッジ
ナレッジでは、Instructions(指示)/Skill/Memoryの3つを設定できます。Instructionsでは、どのエージェントにどんなプロンプトを読ませるか、AGENTS.mdの形式で設定できます。毎回打ち込むようなプロンプトはここで設定できます。
Skillでは、特定の条件で必要になるプロンプトやリファレンスとなるデータを設定できます。具体的には、SKILL.mdやリファレンスなどが設定できます。
また、DevOps Agentにはいくつかのタイプのエージェントがあり、どのタイプのエージェントから使用できるかを設定できます。
Memoryは、直近の調査結果から傾向を学んでMarkdownとして記録してくれます。マネージドで自動作成されるものと、カスタムで作成する2種類があります。マネージドの方は自動で作成されるので、基本的には意識しなくても積み上がっていきます。カスタムでは、メモリストア単位で作成でき、名前と説明をエージェントが参照して読み込むかを判断します。
機能が3つあるので使い分けを記載します。常時守らせたい情報の場合はInstructions、手順や方法論として特定のタイミング（DB障害やログ収集など）で使用したい場合はSkill、手順でなく参照させたい情報の場合はMemory、という区分けで設定するとよいです。
アクセストークン
ほかの機能として、アクセストークンを使用して、KiroやClaude CodeなどからAgent Space自体の情報取得や操作ができます。事前にAWSコンソールの設定タブからアクセストークンを有効化して、Webアプリの画面の設定→アクセストークンからトークン生成ができます。どのぐらいの有効期限でどんな権限を与えるのかなどが設定できます。
普段使っているエージェントが別にあって、本番環境への権限を与えるのは難しいが、読み取り専用の調査だけなら問題ないような場合は有効に機能しそうです。
所感
今回は自分の理解のために、DevOps Agentの構造や設定できる部分を整理してみました。最初期のDevOps Agentはロールも隠蔽されており、Agent Spaceもなかったため簡素な印象でした。現在は、マルチアカウント対応や複数SaaSの対応など細かい要望に対応して複雑化してきていると感じました。
使い始める場合、最低限コードリポジトリの接続さえできていれば、一定の影響調査などは任せられそうです。まずはそこから始めて、段階的に自社のSaaSにMCPサーバー経由で繋いだり、SkillやInstructionsなどのナレッジとしてためていけると良さそうです。この記事がどなたかの理解の助けになれば幸いです。
参考資料
