【DevOps Agent】AWS DevOps Agent のできること・できないことを責任共有モデルから考えてみる

はじめに

AWS DevOps Agent は re:Invent 2025 で発表された Frontier Agent で、インシデント発生時に自律的に調査を行い、根本原因の特定から緩和策の提案まで支援してくれるサービスです（2026年3月時点でパブリックプレビュー中）。

以前、ハンズオン記事を書いて基本的な使い方を紹介しました。

触ってみたものの、DevOps Agent でどこまでできて、どこからはできないのかはあまりイメージできていませんでした。今回はAWSの責任共有モデルの考え方から、DevOps Agent ができること・できないことを推察・整理してみたいと思います。

AWSの責任共有モデル

AWSの責任共有モデルは、クラウドのセキュリティと運用の責任をAWS側と顧客側に分けて定義するフレームワークです。

ざっくり言うと以下のような分担になっています。

• AWS の責任
  • クラウドのセキュリティ
    • ハードウェア、ネットワーク、データセンター、マネージドサービスの基盤部分
• 顧客の責任
  • クラウドにおけるセキュリティ
    • データ、アプリケーション、OS設定、ネットワーク構成、IAM設定　など

この考え方を用いて、DevOps Agent がアクセスできる範囲・できない範囲を推察してみたいと思います。

推察の軸となる4つの原則

責任共有モデルから DevOps Agent の境界を推察する上で、以下の4つの原則を軸にしました。

原則1：AWSが管理・提供するメタデータやメトリクスにはアクセスできる

AWSが責任を持つインフラ層が生成する情報は、DevOps Agent が読み取れると推察できます。

例えば以下のようなものです。

• CloudWatch メトリクス（CPU使用率、ネットワークI/Oなど）
• CloudWatch アラームの状態
• CloudFormation スタックのリソース構成
• EC2 / ECS / Lambda などのリソースメタデータ（インスタンスタイプ、設定値など）
• VPC のネットワーク構成情報

原則2：顧客が作成・管理するデータの中身には原則アクセスしない

責任共有モデルにおいて「顧客のデータ」とされる部分は、AWSのサービスが勝手に読み取ることはないと推察できます。

例えば以下のようなものです。

• アプリケーションのソースコード（GitHub / GitLab / CodeCommit 内）
• S3 バケット内のオブジェクトの中身
• RDS / DynamoDB 内のデータレコード
• Secrets Manager / Parameter Store の値

原則3：顧客がAWSに出力したログやトレースは対象になりうる

顧客が CloudWatch Logs に送信したアプリケーションログは、顧客が自らAWSの管理するストレージに置いたデータです。そのため、DevOps Agent がアクセスできる領域だと推察できます。ただし、ログの中身の管理（PII のマスキングなど）は顧客の責任になると考えられます。

原則4：顧客が明示的に許可した外部データソースにはアクセスできる

原則1〜3は「AWSの管理領域か、顧客の管理領域か」という軸ですが、もう一つ別の軸があります。顧客が Agent Space の設定で明示的に接続を許可した外部サービスのデータです。

例えば以下のようなものです。

• GitHub / GitLab のコミット履歴・差分（ソースコード連携）
• Datadog / Splunk 等の外部オブザーバビリティツール
• ServiceNow 等の外部チケットシステム

これらは責任共有モデルの「AWS管理 / 顧客管理」とは別の軸で、「顧客の同意に基づくアクセス」と位置づけられます。読み取りが主ですが、チケット作成など一部の書き込み操作も含まれると推察できます。

責任共有モデルから推察するできること・できないこと

上記の原則を踏まえて推察を整理します。

できること

カテゴリ	具体的にできること	推察理由
メトリクス分析	CloudWatch メトリクスの読み取り・相関分析	AWSインフラが生成するメトリクスはAWS管理領域
アラーム監視	CloudWatch アラームの状態確認・履歴参照	アラームの状態管理はAWSサービスの機能
ログ分析	CloudWatch Logs に送信されたログの検索・分析	顧客がAWSに出力したデータなので対象になる
トレース分析	X-Ray のトレースデータの参照	同上
リソース構成把握	CloudFormation スタックからのトポロジマップ構築	リソースメタデータはAWS管理領域
リソース状態確認	EC2 / ECS / Lambda / RDS 等の状態・設定値の参照	インフラの状態情報はAWS管理領域
変更追跡	CloudTrail によるAPI呼び出し履歴の参照	監査ログはAWSが管理する仕組み
外部ツール連携	Datadog / Splunk 等のメトリクス・ログ取得	顧客が明示的に接続を許可した外部データソース
チケット操作	ServiceNow チケットの更新、AWS Support ケース作成	顧客が明示的に許可した書き込み操作
コード変更の把握	GitHub / GitLab のコミット履歴・差分の参照	顧客が明示的に連携を許可したソース管理

できないこと

以下はあくまで責任共有モデルからの推察です。実際の仕様はプレビューの進展や GA に伴い変わる可能性があります。

カテゴリ	具体的にできないこと	推察理由
コード実行	ソースコードの修正・プッシュ・デプロイ	コードは顧客のデータであり、書き換えはサービス境界を超える
デプロイ操作	ロールバック、新バージョンのデプロイ実行	デプロイ判断は顧客のビジネスロジックに直結する
インフラ変更	セキュリティグループの変更、インスタンスの停止/再起動	インフラ構成の変更は顧客の設計判断にあたる
データベースの中身	RDS / DynamoDB のレコード読み取り・変更	顧客のビジネスデータそのもの
秘密情報	Secrets Manager / Parameter Store の値参照	顧客が管理する機密データ
S3 オブジェクト	バケット内のファイルの中身を読み取り	顧客のデータ
PII フィルタリング	ログ内の個人情報を自動マスキング	ログの中身の管理は顧客責任
サービス再起動	ECS タスク / Lambda 関数の再起動	サービス運用の実行判断は顧客側にある

「読み取り専用」設計の意味

ここまでの推察を振り返ると、DevOps Agent は基本的に読み取り専用で動作し、書き込みはチケット作成や Support ケース作成、通知の送信といった限定的な範囲にとどまるのではないかと考えられます。

なお、DevOps Agent が使用する AWS マネージドポリシーを確認すると、Describe* / Get* / List* といった読み取り系のアクションのみで構成されており、この推察の方向性と一致しています。

これは責任共有モデルの観点からも整合性があると感じます。

AWS側ができる範囲として、メトリクスやログ、トレース、リソース状態、アラーム状態、CloudTrail などは読み取りが可能です。一方、緩和策の実行やデプロイ、ロールバック、インフラ変更などは提案のみで、実行は人間に委ねられています。

もし DevOps Agent がインフラ変更やデプロイを実行できてしまうと、AWSのサービスが顧客の責任領域に踏み込むことになります。万が一の誤操作による影響は甚大であり、その責任の所在が曖昧になってしまいます。

「調査・分析・提案」に徹し、「実行」を人間に委ねるという設計は、責任共有モデルの観点からも整合性があります。

推察だけでは割り切れない領域

ここまで責任共有モデルをベースにできること・できないことを推察してきましたが、どちらとも言い切れない領域もあります。ここでは特に気になる2つのケースを挙げてみます。

ログの置き場所で境界が変わるのか

原則3で「顧客がAWSに出力したログは分析対象になる」と推察しました。CloudWatch Logs に送ったログであれば DevOps Agent が分析できるだろうという考えです。

では、同じログを S3 に保存している場合はどうでしょうか。原則2に従えば「S3 バケット内のオブジェクトの中身は顧客のデータなのでアクセスしない」となります。

しかし、中身は同じログです。CloudWatch Logs なら見られて、S3 に置いたら見られないというのは直感的には不思議です。ログの「保存先」で境界が変わるのか、それとも「データの種類」で判断されるのか。責任共有モデルの推察だけでは答えが出ないポイントかと思います。

DB 内のオペレーショナルデータはどう扱われるか

原則2では「RDS / DynamoDB 内のデータレコードは顧客のビジネスデータなのでアクセスしない」と推察しました。

しかし、DynamoDB にアプリケーションのセッション情報やジョブの実行状態を格納しているケースはよくあります。これらは「ビジネスデータ」というよりは「運用データ」に近い性質を持っています。障害調査の文脈では、こうしたデータを見られるかどうかで原因特定のスピードが大きく変わる場合もあるかと思います。

責任共有モデルの分類上は「顧客のデータ」ですが、運用上の有用性を考えると境界は曖昧です。実際にどう扱われるのか検証してみたいポイントです。

プレビュー期間中の制限

なお、2026年3月時点のプレビュー期間固有の制限もあります。

項目	制限
Agent Space 数	10個/アカウント
インシデント解決時間	20時間/月
インシデント予防時間	10時間/月
チャットメッセージ	1,000件/月
並行インシデント調査	最大3件
並行インシデント予防	最大1件
利用リージョン	us-east-1 のみ（監視対象は任意リージョン）
言語	英語のみ（日本語の表示などはできるようになってきています）

おわりに

以上、簡単ではありましたが責任共有モデルから DevOps Agent ができることとできないことを考えてみました。

曖昧な部分などは実際に検証して確かめてみたいと思います。

ありがとうございました。