developersIO
AWS DevOps Agentがリソースを更新できるようになったので試してみた

AWS DevOps Agentがリソースを更新できるようになったので試してみた

AWS DevOps Agent のエージェントアクション機能が新しく追加されました。リソース変更を実際に実行できるようになったこの機能について、Lambda 関数のタグ更新を例に、セットアップから実行承認までの全体の流れを試してみました。
AWS DevOps Agent
2026.08.28

こんにちは。クラウド事業統括本部コンサルティング1部の桑野です。

皆さんは DevOps Agent を使っていますでしょうか？
私は最近結構触ってます。

AWS DevOps Agent は読み取り専用のエージェントで、調査や対処方法の提案はしてくれるものの、実際にリソースを直す作業は自分で行う必要がありました。

しかし先日、Directed actions（コンソール上の表記はエージェントアクション）という機能が追加され、エージェントがリソースの変更を実行できるようになりました。

早速この機能を有効化して、Lambda 関数のタグ更新を実際に依頼するところまで試してみました。
今回はその内容を共有します。

先に結論

エージェントアクションを使うには、以下の 3 つが必要です。

設定 内容
エージェントスペースの有効化 設定タブでエージェントアクションのトグルを ON にする
アカウントごとのアクションロール 変更を実行するための IAM ロールをアカウントごとに登録する
実行時の承認 変更のたびにチャット上で Approve する

有効化してすぐに操作を依頼できるというわけではなく、ロールを登録した上で、さらに個々の操作を承認して初めてエージェントが操作できます。

ただし、一部の操作はエージェントは実行できません。
IAM ロールで許可していても、承認しても実行されない設計になっています。詳しくは後述します。

Directed actions とは

まず公式ドキュメントの内容を確認しておきます。

https://docs.aws.amazon.com/devopsagent/latest/userguide/working-with-devops-agent-working-with-directed-actions.html

エージェントの操作は 2 種類に分けられています。

種別 内容 既定の状態
Read-only actions 接続済みのサービスや AWS アカウントから情報を読み取るだけの操作 既定で利用可能
Directed actions リソースを作成・変更する操作 既定で無効。段階的なオプトインと操作ごとの承認が必要

ドキュメントには安全性の考え方が以下のように書かれています。

The safety model for directed actions is defense in depth. The capability is disabled by default. You opt in through independent layers: enabling directed actions on the agent space, registering a per-account IAM role, and categorizing each tool. Every directed action requires operator approval at execution time. Every approval and resulting action is attributable to the approving operator in AWS CloudTrail.

エージェントスペースでの有効化、アカウントごとのロール登録、ツールの分類という独立した層を通してオプトインし、そのうえで実行時に毎回承認が必要になる、という構成みたいです。承認と実行の結果は CloudTrail で承認した人に紐づけて記録されるとのことです。

どのようなアクションがサポートされているかはコンソールから確認ができました。

スクリーンショット 2026-08-28 15.13.46

エージェントが実行しない操作

権限を与えていても、エージェント側のガードレールで拒否される操作があります。ドキュメントでは以下の 3 つが挙げられています。

操作 内容
リソースの削除 インスタンス、バケット、テーブル、関数、スタックなどの削除系操作。削除は利用者が自分の権限で行う
パーミッションバウンダリーの変更 iam:PutRolePermissionsBoundary など 4 つのアクション
iam:PassRole を伴う操作 インスタンスプロファイル付きの EC2 起動や、実行ロール付きの Lambda 関数作成など

https://docs.aws.amazon.com/devopsagent/latest/userguide/working-with-devops-agent-working-with-directed-actions.html#operations-the-agent-will-not-perform

パーミッションバウンダリーが対象外になっている理由も説明されていました。

Boundaries are a control your organization uses to constrain the agent, so the agent cannot change them.

エージェントを制約するための仕組みなので、エージェント自身には変更させないということですね。

iam:PassRole については、ロールを渡すことでサービス経由の権限が間接的に広がるためと書かれています。

これらは IAM ロールのポリシーで許可していても、承認しても実行されません。

These guardrails apply even when the elevated role's policy allows the operation. Operator approval does not override them.

以前の記事で触れた読み取り時のパーミッションガードレールと同じく、IAM とは別のレイヤで上限が引かれている形です。

https://dev.classmethod.jp/articles/athena-devops-agent-verification/

前提

以下の形で検証しています。

  • エージェントスペースが作成済み
  • プライマリアカウントのみを対象（セカンダリアカウントは登録していない）
  • 対象リソースは検証用に作成した Lambda 関数

2026年8月28日時点での検証結果である点にご注意ください。

エージェントスペースをセットアップする

どういうふうに有効化したかをご紹介します。

エージェントアクションを有効にする

エージェントスペースの機能タブを開きます。

image_01

プライマリソースのアクションロールのステータスが「未設定」になっています。この時点ではエージェントは読み取りしかできません。

設定タブを開くと、エージェントアクションの項目があります。

image_02

説明にはこう書かれています。

エージェントが AWS リソースを変更できるようにする IAM ロールとアクセス許可を設定します。各変更を実行する前に、明示的な承認が必要です。

トグルを押すと確認のダイアログが出ます。

image_03

The agent can make changes in the connected accounts using the per-account roles you configure, and can run only the actions we support. Every change needs your approval.

This setting takes effect only for accounts where you configure an Agent Actions role on the Capabilities tab.

アカウントごとにアクションロールを設定したアカウントでのみ有効になる、と書かれています。この設定自体は入口を開けるだけで、実際に使うにはロールの登録が別途必要ということですね。

有効にしてみました。

image_04

トグルが切り替わりましたね。

アクションロールを作成する

続いてアカウント側のロールを設定します。機能タブのプライマリソースから「Edit」を選びます。

image_05

「DevOps エージェントアクションロール - オプション」というセクションが増えていました。

このロールは、このエージェントスペースのエージェントアクションを有効にした後にのみ使用されます (設定タブ)。今すぐロールを設定可能ですが、Agent Actions を有効にするまで適用されません。

「はい、今すぐアクションロールをセットアップします」を選ぶと、ロールの作成方法が出てきます。

image_06

作成方法は 3 つ用意されています。

選択肢 内容
新しい DevOps エージェントアクションロールを自動作成 新しいサービスロールを作成して使用する
既存のロールを割り当て 用意済みのロールを指定する
ポリシーテンプレートを使用して新しいロールを作成する 提示された内容をもとに IAM コンソールで自分で作成する

今回はロールの中身を確認したかったので、3 つ目のポリシーテンプレートを選びました。
画面に信頼ポリシーが提示されますね。

image_07

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "aidevops.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "<アカウントID>"
        },
        "ArnEquals": {
          "aws:SourceArn": "<エージェントスペースのARN>"
        }
      }
    }
  ]
}

STS のアクションが 3 つ並んでいます。ドキュメントでは、この 3 つがすべて必要だと明記されていました。

The trust policy must allow all three: sts:AssumeRole, sts:SetSourceIdentity, and sts:TagSession. If you omit sts:SetSourceIdentity or sts:TagSession, directed actions fail at credential time even when the validation status is valid.

sts:SetSourceIdentity は、実行されたアクションを承認した人に紐づけるために使われるものです。CloudTrail に承認者が記録されるという話とつながっています。

aws:SourceAccount と aws:SourceArn の条件については、confused deputy 問題への対策だと説明されています。自分のエージェントスペースからの引き受けだけに限定する形です。

信頼ポリシーの下に、アクセス許可の選択肢があります。

image_08

選択肢 内容
AWS マネージドポリシーをアタッチする AIDevOpsAgentActionsPolicy をアタッチする
スコープポリシーを構築する エージェントが実行できるアクションを選択し、最小権限ポリシーを生成する

AIDevOpsAgentActionsPolicy の中身を確認しておきます。

https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIDevOpsAgentActionsPolicy.html

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AIDevOpsElevatedAccess",
      "Effect": "Allow",
      "NotAction": [
        "account:*",
        "cognito-identity:*",
        "iam:*",
        "identitystore:*",
        "organizations:*",
        "ram:*",
        "rolesanywhere:*",
        "sso:*",
        "sts:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AIDevOpsElevatedCarveBacks",
      "Effect": "Allow",
      "Action": [
        "account:GetAccountInformation",
        "account:GetGovCloudAccountInformation",
        "account:GetPrimaryEmail",
        "account:ListRegions",
        "iam:ListRoles",
        "organizations:DescribeEffectivePolicy",
        "organizations:DescribeOrganization",
        "sts:DecodeAuthorizationMessage"
      ],
      "Resource": "*"
    }
  ]
}

NotAction で書かれているので、除外されている 9 つのサービス以外はすべて許可という内容です。除外されているのは ID・認証情報・組織管理に関わるサービスで、そこから読み取り系のアクションだけが個別に許可し直されています。

かなり広い権限なので、本番アカウントで使う場合はスコープポリシーの方を検討したいところですね。ドキュメントにも、より狭い上限にしたい場合は自分でポリシーを書く選択肢が案内されています。

ここで気をつけたいのが、このポリシーには削除系のアクションも含まれているという点です。ドキュメントに明記されていました。

It does include delete-class actions in the ceiling. The agent itself refuses delete-class operations regardless of the role's permissions.

ロール側は削除を許可しているものの、エージェント側が拒否する形になっています。ロールのポリシーだけを見て「削除できない」と判断できる状態ではないので、SCP やパーミッションバウンダリーで別途縛るかどうかは検討したほうがよさそうです。

なお、承認された操作に対して実際に発行される認証情報は、承認された操作とリソースにセッションポリシーで絞り込まれると書かれています。ロールのポリシーは上限を決めるもので、実行時の権限とは別ということですね。

The elevated role's permission policy defines the ceiling of what AWS DevOps Agent can ever do in your account through directed actions. The agent never operates at this ceiling.

では早速保存してみますぞ！
「保存」ボタンをポチッとな！

...あれ？

image_09

「ポリシーテンプレートを使用して新しいロールを作成する」と「AWS マネージドポリシーをアタッチする」を選んだ状態で保存したところ、エラーになっちゃいました。

Invalid STS role configuration for session monitorElevatedRoleVerificationSession. Verify the role's trust policy.

信頼ポリシーの検証に失敗しています。
このエラーの原因は特定できなかったので、別の方法を試しました。
今回は自動作成に切り替えました。

作成方法を「新しい DevOps エージェントアクションロールを自動作成」に変更して保存したところ、作成とアクションロールの有効化ができました。

機能タブに戻ると、アクションロールのステータスが「有効」になっています。

image_10

自動作成されたロールを IAM コンソール側で確認します。

image_11

説明文にも用途が書かれていました。

Allows AWS DevOps Agent to perform operator-approved mutations on your resources after you enable Agent Actions.

最大セッション時間は 1 時間になっています。許可ポリシーは AIDevOpsAgentActionsPolicy の 1 つだけです。

信頼関係のタブも確認しておきます。

image_12

先ほどポリシーテンプレートの画面で提示されていた内容と同じものが設定されています。自動作成を選んだ場合も、テンプレートで案内されるのと同じ構成のロールが作られるということですね。

Lambda 関数のタグ更新をお願いしてみた

準備ができたので、実際に変更を依頼します。

対象は検証用に作成した Lambda 関数です。タグは付いていない状態にしてあります。

image_13

以下の内容で依頼しました。

arn:aws:lambda:ap-northeast-1:xxxxxxxxxxxx:function:test-kuwano
のLambda関数のタグを更新してください。
プレースホルダーには適した情報を入れてください。

Test: CreatedByDevOpsAgent_${AgentSpaceId}

image_14

タグの値に ${AgentSpaceId} というプレースホルダーを入れて、エージェント自身に埋めさせる形にしています。エージェントが自分の実行環境の情報を持っているかを確認したかったためです。

返ってきた内容です。

image_15

以下のタグを設定します：

  • Test: CreatedByDevOpsAgent_76cd4050-756e-4ca0-ab77-226dd749cf36

AgentSpaceIDをプレースホルダーに代入した値です。実行してよろしいでしょうか？

エージェントスペースの ID が入っていますね。冒頭のスクリーンショットのパンくずに出ている ID と一致しています。

そして、その下に承認を求めるパネルが表示されました。

Add a tag (Test=CreatedByDevOpsAgent_76cd4050-756e-4ca0-ab77-226dd749cf36) to the Lambda function test-kuwano in AWS account xxxxxxxxxxxx (ap-northeast-1 region) using the DevOpsAgentActionsRole-AgentSpace-1rnj2bon IAM role.

呼び出すツールは use_aws で、「必須アクション」というラベルが付いています。使用するロールとアカウントも明示されていますね。

Approve と拒否のボタンが並んでいて、押すまでは実行されませんでした。

ツールの詳細とリスクの詳細

パネルにはツールの詳細とリスクの詳細という展開できる項目がありました。

image_16

ツールの詳細では、実際に投げられる API 呼び出しの内容が確認できます。

{
  "service_name": "lambda",
  "operation_name": "tag_resource",
  "parameters": {
    "Resource": "arn:aws:lambda:ap-northeast-1:xxxxxxxxxxxx:function:test-kuwano",
    "Tags": {
      "Test": "CreatedByDevOpsAgent_76cd4050-756e-4ca0-ab77-226dd749cf36"
    }
  },
  "aws_region": "ap-northeast-1",
  "aws_account_id": "xxxxxxxxxxxx"
}

どのサービスのどの操作を、どのパラメータで実行するのかがそのまま出ています。英語なのはちょっと辛いですが、承認する前に中身を確認できるのはありがたいですね。
ここは今後日本語で教えてくれるようになることを期待したいところです。

リスクの詳細は 3 つの項目に分かれていました。

項目 内容
リスク評価 タグ付けは非破壊のメタデータ操作。関数は動作し続け、設定や挙動は変わらない。データ損失や可用性への影響はなく、タグの削除・更新で完全に元に戻せる
影響範囲 対象アカウントの Lambda 関数 test-kuwano のみ。他のリソースや下流のシステムには影響しない
アドバイザリー ロールに lambda:TagResource の権限があることを確認すること。ARN が正しいか実行前に確認すること。タグは実行・パフォーマンス・請求に影響しない

原文も引用しておきます。

Tagging a Lambda function is a non-destructive metadata operation. The function remains operational and no configuration or behavior changes occur. Tags are additive and can be modified or removed independently. There is no data loss potential, no availability impact, and no interruption to the running function. The operation is fully reversible by removing or updating the tag. The blast radius is confined to a single function resource.

タグ付けという影響の小さい操作でも、元に戻せるかどうかと影響範囲が明示されます。ここが変更内容によってどう変わるのかは、もう少し影響の大きい操作でも試してみたいところです。

承認して実行する

Approve を押しました。

image_17

ツールの実行ログが「承認済み」の表示になり、入力と出力が記録されています。

出力は以下でした。

{
  "xxxxxxxxxxxx": {}
}

空のレスポンスですが、これについてもエージェントが補足していました。

空のレスポンス {} はLambdaの tag_resource が成功時に返す正常な応答です。タグが正しく設定されています。

TagResource は成功時に本文を返さない API なので、その通りですね。

コンソールで確認します。

image_18

タグが 1 件登録されていて、値もエージェントが提示した通りになっています。

まとめ

AWS DevOps Agent のエージェントアクションを有効にして、Lambda 関数のタグ更新を実行してもらうところまで試しました。

有効化にはエージェントスペースの設定とアカウントごとのアクションロールの両方が必要で、そのうえで操作ごとに承認が入ります。承認画面では実際に投げられる API 呼び出しの内容と、影響範囲・元に戻せるかどうかが確認できました。

今回はタグ付けという影響の小さい操作でしたが、前回検証した Athena クエリ実行は S3 に結果保存するパターンもあり、その場合はs3:PutObjectを要求するので、今回の機能を活用すれば DevOps Agent から承認ありですが、実行ができるかもしれないですね。
引き続きユースケースついて考えたり気になったことを検証したいと思います。

最後までご覧いただきありがとうございました。

この記事をシェアする

関連記事

AWS DevOps Agent スペースのセカンダリソースの追加に必要な IAM ロールを CloudFormation StackSets で作成してみた
yhana
2026.07.23
2026年07時点のDevOps AgentのIAM権限を調べてみた
たかやま
2026.07.31
DevOps Agentの権限ガードレールがReadOnlyAccessポリシーに対応しました
たかやま
2026.08.15
AWS DevOps Agent スペースに AWS Organizations 配下のアカウントをセカンダリソースとして AWS CLI でまとめて追加してみた
yhana
2026.07.23