はじめに
本記事は「2026 Japan AWS Jr. Champions 真夏のQiitaリレー」の11日目の記事となります。
昨日の記事はこちら！
今回はAWS DevOps Agentの中で、私が特に役に立ったと感じているクロスアカウント設定についてご紹介します。これは1つのエージェントスペースで複数のアカウントを集約し、横断的に調査できる機能です。実際にマネジメントコンソール上で手順を踏みながらご紹介したいと思います。
※JAWS-UG東京支部にてDevOps Agentの個人的なTipsをいくつか紹介しました。本記事はその中の1つを掘り下げたものです。
DevOps Agentとは？
AWS DevOps Agentは、re:Invent 2025で発表されたAIエージェントサービスで、AWS環境の実機調査や、インシデント調査・根本原因の特定・緩和策の提示といった一連の調査作業を行うことができるサービスです。
サポートケースの起票を除き、基本的にすべての操作が読み取り専用に限定されているのが特徴です。
DevOps Agentを使うには、エージェントスペースの作成が必要です。
エージェントスペースとはDevOps Agentを動かすための箱のようなもので、エージェントスペースごとにエージェントのアクセス範囲や調査対象を設定できます。
このエージェントスペースに対して調査対象のアカウントを関連付けていく、というのが本記事で扱うクロスアカウント設定の概要です。
クロスアカウント設定とは？
まず言葉の定義ですが、エージェントスペースを配置するアカウントをプライマリアカウント、調査対象として追加するアカウントをセカンダリアカウントと呼びます。
セカンダリアカウント側に作成したIAMロールをエージェントスペース側でAssumeRoleすることで、そのアカウントのリソース情報を取得する仕組みです。
クロスアカウント設定のメリットは、複数アカウントの情報をコンテキストとして渡すことができるため、調査精度を上げられることです。
AWSサービスやログが複数アカウントにまたがっている場合、1つのアカウントだけを見ても全体像はつかめません。関連するアカウントをまとめて調査対象にしておくことで、エージェントが十分なコンテキストを持った状態で調査できるようになります。
やってみる
エージェントスペースの作成、クロスアカウント設定、そして複数アカウントのリソース情報取得までを実際にマネジメントコンソールからやっていきます。
構成
本検証ではセカンダリアカウントは1つのみとし、プライマリアカウントとセカンダリアカウントの2アカウント構成で進めます。
| 項目 | 内容 |
|---|---|
| プライマリアカウント | エージェントスペースを配置 |
| セカンダリアカウント | 調査対象 |
| リージョン | ap-northeast-1 |
エージェントスペースをどのリージョンに作っても、アカウント内の全リージョンのリソースが調査対象になります（公式ドキュメントより）。
本検証では作業を進めやすくするため、操作に使用するIAMユーザーに AdministratorAccess を付与しています。
実際に業務で利用する際は、必要な権限のみに絞ることをおすすめします。
エージェントスペースを作成する
まずはプライマリアカウントでエージェントスペースを作成します。
名前と応答言語を設定します。今回、名前はagentspace-testとします。
応答言語をJapanese (Japan)にしておくと、調査結果が日本語で返ってきます。
その他は今回デフォルトのまま作成しました。
agentspace-test が作成されていればOKです。
セカンダリアカウントを追加する
作成したエージェントスペースの詳細画面に遷移し、「機能」＞「クラウド」＞「セカンダリソース」＞「追加」＞「AWS」を選択します。
するとセカンダリアカウントと連携するまでの手順が記載されるので、その順に進めていきます。
具体的には以下の流れです。
-
セカンダリアカウントに作成するロール名を決める（デフォルトのままでOK）
-
表示されたカスタム信頼ポリシーをコピー
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "aidevops.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "<プライマリアカウントのID>", "aws:SourceArn": "<エージェントスペースのARN>" } } } ] } -
セカンダリアカウント側のIAMロール作成画面で、カスタム信頼ポリシーに2を貼り付ける
-
許可ポリシーに
AIDevOpsAgentAccessPolicyをアタッチ -
1のロール名でIAMロールを作成
-
作成したIAMロールにインラインポリシーを追加
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCreateServiceLinkedRoles", "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole" ], "Resource": [ "arn:aws:iam::<セカンダリアカウントのID>:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer" ] } ] }このインラインポリシーは、Resource Explorerのサービスリンクロールを作成するためのものです。DevOps Agentがセカンダリアカウントのリソースを検出する際に使われていると思われます。
-
プライマリアカウントに戻り、セカンダリアカウントのIDと作成したロール名を入力して追加
長々と書きましたが、要はこういうことです。
調査してみる
DevOps Agentには専用のWebアプリがあり、その中にあるチャット機能でAWS実環境の調査を依頼することができます。
今回は、セカンダリアカウントにS3バケット「devopsagent-secondary-test-bucket」を作成したので、プライマリアカウントのエージェントスペースから取得できることを確認します。
チャット画面から以下を質問してみます。
<セカンダリアカウントのID>アカウントにS3バケット「devopsagent-secondary-test-bucket」は存在しますか
結果はこちらです。無事にセカンダリアカウントのS3バケットの情報を取得できました。
注意点・補足
デフォルトではS3オブジェクトの中身までは見に行かない
先ほどS3バケットの存在は確認できましたが、DevOps AgentのデフォルトポリシーであるAIDevOpsAgentAccessPolicyにはs3:GetObject, s3:ListBucketの権限が含まれていません（これはクロスアカウント設定というよりDevOps Agentの仕様）。
つまり、デフォルトポリシーのままでは格納されているオブジェクトの中身を取得することができないということです。
これは、セカンダリアカウント側のIAMロールに対して権限を追加することでオブジェクトを取得できるようになります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::devopsagent-secondary-test-bucket",
"arn:aws:s3:::devopsagent-secondary-test-bucket/*"
]
}
]
}
S3オブジェクトには機密情報が含まれうるため、全てのバケットに対して許可するのではなく、Resourceブロックの中で特定のバケットやオブジェクトに絞り込むことが重要です。
上記のポリシーをロールに追加した後で再度DevOps Agentに質問したところ、オブジェクトの情報が取得できるようになりました。
おわりに
DevOps Agentのクロスアカウント設定について、マネジメントコンソール上の手順から簡単な検証まで実施しました。
マルチアカウント構成の環境では特に有効な機能だと思いますので、ぜひお試しください！
参考