はじめに
自分の環境でAWS DevOps Agentを利用するために、Terraformからリソース作成してみたので、その記録を残します。
AWS DevOps Agentとは
2025年12月のAWS re:Inventで発表されたFrontier Agentsのひとつで、環境調査や障害の根本原因の特定、改善に向けた提案を自律的に行ってくれるサービスです。
既にGAされており、東京リージョンでも利用可能になります。
TerraformからのデプロイにはAWSCCプロバイダーを利用
2026年7月時点では、hashicorp/awsプロバイダーにAWS DevOps Agent固有のリソースは実装されていませんでした。
そのため、TerraformでDevOps AgentのエージェントスペースやAWSアカウントとの関連付けを作成する場合は、AWS Cloud Control APIを利用するhashicorp/awsccプロバイダーを使用します。
IAMロールなどの一般的なAWSリソースには、引き続きhashicorp/awsプロバイダーを使用するため、両方のプロバイダーを併用する形にしています。
Terraformコード
Claude Codeに作成してもらいました。
構成は以下の通りです。
.
├── provider.tf # プロバイダー設定
├── iam.tf # IAMロール2つ
├── devops-agent.tf # DevOps Agent本体
└── outputs.tf # 出力
一つずつ確認していきます。
プロバイダー設定
terraform {
required_version = ">= 1.0"
required_providers {
# IAMロールなど従来リソース用
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
# DevOps Agentリソース用(awsプロバイダー未対応のため)
awscc = {
source = "hashicorp/awscc"
version = "~> 1.0"
}
}
}
provider "aws" {
region = "ap-northeast-1"
}
provider "awscc" {
region = "ap-northeast-1"
}
data "aws_caller_identity" "current" {}
locals {
# 自アカウントのエージェントスペースからの利用だけを許可する条件に使う
account_id = data.aws_caller_identity.current.account_id
agent_space_arn_pattern = "arn:aws:aidevops:ap-northeast-1:${local.account_id}:agentspace/*"
}
aws プロバイダーと awscc プロバイダーを両方宣言します。
また、aws_caller_identity からAWSアカウントIDを取得し、account_id というローカル変数に格納しています。
agent_space_arn_pattern には自アカウント内に作成されるDevOpsエージェントのエージェントスペースを表すARNパターンを定義しています。
末尾をagentspace/* とワイルドカードにしているのは、エージェントスペースのIDがAWSによって作成時に割り当てられるため、この時点では具体的なARNを確定できないからです。
このARNパターンは、次の iam.tf でIAMロールの信頼ポリシーに設定します。
DevOpsエージェントが調査に使うIAMロール
resource "aws_iam_role" "agent_space" {
name = "DevOpsAgentRole-AgentSpace"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "aidevops.amazonaws.com" }
Action = "sts:AssumeRole"
Condition = {
StringEquals = { "aws:SourceAccount" = local.account_id }
ArnLike = { "aws:SourceArn" = local.agent_space_arn_pattern }
}
}]
})
}
resource "aws_iam_role_policy_attachment" "agent_space" {
role = aws_iam_role.agent_space.name
policy_arn = "arn:aws:iam::aws:policy/AIDevOpsAgentAccessPolicy"
}
# エージェントがResource Explorerで環境を自動発見できるようにする
resource "aws_iam_role_policy" "agent_space_resource_explorer" {
name = "AllowCreateResourceExplorerSLR"
role = aws_iam_role.agent_space.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Action = "iam:CreateServiceLinkedRole"
Resource = "arn:aws:iam::${local.account_id}:role/aws-service-role/resource-explorer-2.amazonaws.com/AWSServiceRoleForResourceExplorer"
}]
})
}
aws_iam_role.agent_space では、DevOps AgentがAWS環境を調査する際に使用するIAMロールを設定しています。
信頼ポリシーの Principal に aidevops.amazonaws.com を指定し、さらにConditionで自アカウントのエージェントスペースのみがロールを引き受けられるようにしています。
これにより、別のAWSアカウントや想定していないAWSリソースから、このIAMロールが利用されることを防いでいます。
続いて、AWS管理ポリシーの AIDevOpsAgentAccessPolicy をIAMロールにアタッチしています。このポリシーには、AWS DevOps AgentがAWSリソースを検出し、ログやメトリクスなどを参照して、インシデントの調査や分析を行うために必要な権限が含まれています。
最後に、インラインポリシーとして iam:CreateServiceLinkedRole を許可しています。
DevOps Agentは、AWS Resource Explorerを利用して、アカウント内のAWSリソースやリソース間の関係を検出します。その際、Resource Explorer用のサービスリンクロールである AWSServiceRoleForResourceExplorer がアカウント内に存在しない場合は、新たに作成する必要があるため、このポリシーを付与しています。
オペレータアプリ用のIAMロール
resource "aws_iam_role" "operator_app" {
name = "DevOpsAgentRole-OperatorApp"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Effect = "Allow"
Principal = { Service = "aidevops.amazonaws.com" }
Action = ["sts:AssumeRole", "sts:TagSession"]
Condition = {
StringEquals = { "aws:SourceAccount" = local.account_id }
ArnLike = { "aws:SourceArn" = local.agent_space_arn_pattern }
}
}]
})
}
resource "aws_iam_role_policy_attachment" "operator_app" {
role = aws_iam_role.operator_app.name
policy_arn = "arn:aws:iam::aws:policy/AIDevOpsOperatorAppAccessPolicy"
}
このIAMロールは、ユーザーがオペレータアプリ（専用コンソール）からエージェントスペースの機能を利用する際に使用されます。
前に作成した agent_space ロールが、ログやメトリクスなどのAWSリソースを調査するためのロールであるのに対し、こちらはチャットや調査結果の確認など、オペレータアプリ上の操作を許可するためのロールです。
このロールでは、sts:AssumeRole に加えて sts:TagSession も許可しています。
sts:TagSession は、DevOps Agentがロールを引き受ける際に、対象となるエージェントスペースのIDを AgentSpaceId というセッションタグとして付与するために使用されます。
アタッチしているAWS管理ポリシー AIDevOpsOperatorAppAccessPolicy では、このセッションタグを参照し、オペレータアプリから操作できる対象を、タグに設定されたエージェントスペースに限定しています。これにより、オペレータアプリがほかのエージェントスペースを誤って操作することを防ぎます。
DevOps Agent本体
resource "awscc_devopsagent_agent_space" "main" {
name = "test-agentspace"
description = "DevOps Agent Space managed by Terraform"
operator_app = {
iam = {
operator_app_role_arn = aws_iam_role.operator_app.arn
}
}
# ポリシーアタッチ完了前にAgent Space作成が走らないようにする
depends_on = [
aws_iam_role_policy_attachment.agent_space,
aws_iam_role_policy_attachment.operator_app,
]
}
# AWSアカウントの紐付け
resource "awscc_devopsagent_association" "this_account" {
agent_space_id = awscc_devopsagent_agent_space.main.id
service_id = "aws"
configuration = {
aws = {
account_id = local.account_id
account_type = "monitor"
assumable_role_arn = aws_iam_role.agent_space.arn
resources = []
}
}
}
AWS DevOps Agentの本体となるエージェントスペースを作成し、現在のAWSアカウントを調査対象として関連付けています。
エージェントスペースは、DevOps Agentが調査に使用するAWSアカウントや外部サービスなどをまとめて管理する単位です。
operator_app には、作成したオペレータアプリ用IAMロールのARNを指定しています。これにより、このエージェントスペースでオペレータアプリを利用できるようになります。
また、depends_on で依存関係を明示し、必要な権限が付与される前にエージェントスペースの作成が始まることを防いでいます。
続いて、awscc_devopsagent_association.this_account で、作成したエージェントスペースと自分のAWSアカウントを関連付けています。
エージェントスペースを作成しただけでは、調査対象となるAWSアカウントは登録されず、Associationを作成して「どのAWSアカウントを、どのIAMロールを使って調査するか」を設定する必要があります。
service_id = "aws" は、関連付ける対象がAWSアカウントであることを表しています。
account_id には、調査対象である自分のAWSアカウントIDを指定しています。
account_type = "monitor" は、このAWSアカウントが、エージェントスペースを配置するモニタリングアカウント（プライマリアカウント）であることを表しています。別のAWSアカウントをクロスアカウントで調査対象に追加する場合は、そのアカウントを source として別途関連付けます。
assumable_role_arn には、前の手順で作成した調査用IAMロールのARNを指定しています。DevOps Agentはこのロールを引き受け、アカウント内のリソース情報やログ、メトリクスなどを参照します。
resources では、調査対象とする個別のリソースを指定できますが、今回はしていません。そのため、この構成では特定のリソースに限定せず、関連付けたAWSアカウント内のリソースを調査対象としています。
デプロイ
ちゃんとAWS上にエージェントスペースが作成されていました。
応答もちゃんと返ってきていました。
おわりに
あまりコンソール操作でリソース作成するのが好きじゃないので、新しいサービスでもちゃんとTerraformから作成できてよかったです。
DevOps Agentを使った検証についても、別の記事で紹介したいと思います。
最後までお読みいただきありがとうございました。