変更履歴
- 2026-10-28：公開
初めに
AWS DevOps Agent（障害の調査を支援する AWS のサービス）に、障害を調査させる検証を始めた。その結果を記事にする前に、DevOps Agent の基礎知識をまとめておく。
想定読者は、AWS で運用している人で、設定から調査の結果までの画面を順に紹介する。画面の例には、検証環境で起こした 3 種類の障害の調査を使う。画面は 2026-10-26 に撮ったもので、プレビューの機能も多いので、今後変わることがある。
実際に見た画面と、公式の文書の説明は分けて書く。画面で確かめていない説明には（公式）と添えるか、「公式の文書によると」と書いた。今回触っていない機能は 9 章にまとめた。
機能の一覧と本記事の構成
| 機能 | 画面 | 何をするか | 今回 | 章 |
|---|---|---|---|---|
| Agent Space | コンソール | 調査の対象の AWS アカウントや外部ツールとの連携をまとめて管理する単位 | 確認 | 4 |
| トポロジー | コンソール・Web アプリ | リソース間の関係を自動で集めて描く | 確認 | 5 |
| アーティファクト | Web アプリ | エージェントが作った文書（Agent Space の構成のまとめなど）を置く | 確認 | 5 |
| インシデントレスポンス（調査） | Web アプリ | アラームなどを受けて原因を調べ、根拠と直し方を出す | 確認 | 6 |
| ナレッジ（指示・スキル・メモリ） | Web アプリ | 人が与える指示と手順、エージェントが保持する情報を置く | 確認 | 7 |
| 改善事項 | Web アプリ | 終わった調査を見直し、障害を防ぐ改善を提案する | 確認（提案は無し） | 8 |
| チャット | Web アプリ | 環境や調査について、言葉で質問する | 候補の表示だけ | 8 |
| エージェント | Web アプリ | カスタムのエージェントを作り、時刻やイベントで走らせる | 公式の説明 | 9 |
| MCP・A2A | 外部から | IDE やほかのエージェントから DevOps Agent を呼ぶ | 公式の説明 | 9 |
| リリース管理（プレビュー） | コンソール・ソースコード管理 | 本番に出す前のコードの変更を見る・試す | 公式の説明 | 9 |
1 章で DevOps Agent の役割、2 章で今回の環境、3 章で 2 つの画面の分かれ方を説明し、4 章から上の表の順に見ていく。料金は 10 章にまとめた。
1. AWS DevOps Agent とは
この章は、公式の文書の説明をまとめたものである。
本番環境で起きた障害の調査を支援する AWS のサービス。アラームやチケットを受け取ると、メトリクス・ログ・CloudTrail・リソースの設定を自分で調べ、根本原因の候補と直し方を出す。調査のあとには、同じ種類の障害を防ぐための改善も提案する。
エージェントは読み取りの権限で調べる。直すためのコマンドは提案するが、自分では実行しない。
全体の関係は以下。
図1：管理者がコンソールで設定し、運用担当者が Web アプリで調査を始めて追う。エージェントは Agent Space につないだ先を、付けた IAM ロールの権限で読み取って調べる。
2. 今回の環境
東京リージョン（ap-northeast-1）に、注文を受け付ける簡単な Web アプリを置いた。ALB の後ろに EC2 が 1 台あり、データは RDS（PostgreSQL）と S3 に置く。監視は CloudWatch のアラームとログである。
この環境で 3 種類の障害を 1 つずつ起こし、DevOps Agent に調査させた。
- EC2 の CPU 使用率が 100% に張り付く（負荷をかけるコマンドを動かした）
- EC2 のデータ用のディスクが満杯になる
- RDS の接続数が上限に達する
リソースには、検証用だと分かるタグ（Environment=sandbox・Purpose=qiita-devopsagent・Owner=yuki）を付けていた。エージェントはこのタグも読める状態で調査しており、画面にもタグが出てくる。原因を「検証環境での意図的な負荷テスト」とまとめている画面（図12 など）は、エージェントが手がかりなしに突き止めた例ではない。出力の形の例として見てほしい。調査の当たり外れは、別の検証記事で評価する。
3. 2 つの画面
画面は役割で 2 つに分かれている。
| 画面 | 使う人 | やること |
|---|---|---|
| AWS マネジメントコンソール | 管理者 | Agent Space を作る、AWS アカウントや外部ツールをつなぐ、アクセスの権限を決める |
| Web アプリ | 運用担当者 | 調査を始めて追う、チャットで聞く、トポロジーを見る、改善の提案を読む |
図2：コンソールの Agent Space の一覧。右の「IAM 経由で起動する」から Web アプリを開く。
Web アプリは、コンソールとは別のドメインで開く独立したアプリである（公式）。今回は、コンソールの Agent Space の画面にある「IAM 経由で起動する」から入った。今のコンソールのログインをそのまま使う管理者向けの入り方で、1 回の利用は 8 時間まで（公式）。チームで使うなら、IAM Identity Center や外部の ID プロバイダーでサインインさせる（公式）。
図3：Web アプリの最初の画面。左のメニューから 4 章以降で見る画面へ移り、中央でチャットを始める。
4. Agent Space
Agent Space は、調査の対象の AWS アカウントや外部ツールとの連携をまとめて管理する単位である。Agent Space には IAM ロールを付け、エージェントはその権限の範囲で読む（公式）。
つなぐのは、AWS アカウント（最初の 1 つがプライマリ、追加するものがセカンダリ）と外部ツールである。外部ツールには、監視・ソースコード管理・CI/CD・通知の製品（Datadog・GitHub・Slack など）と、自分で用意した MCP サーバー1がある（公式）。今回はプライマリの AWS アカウントを 1 つつないだだけである。
図4：Agent Space の詳細。中ほどの「トポロジマッピング完了」の行と、その下の関係の数（96）を見る。
AWS アカウントや外部ツールとの接続の状況は、「機能」のタブで確かめる。
図5：「機能」のタブ。上の表がつないだ AWS アカウント、下の「テレメトリ」が外部ツールのソース（今回は 0）。
5. トポロジー
Agent Space を作ると、つないだアカウントのリソースと、リソース間の関係を自動で集め始める。これがトポロジーで、調査のときにエージェントが構成をつかむ土台になる（公式）。
Agent Space の画面には「これまでにマッピングされた関係」の数が出る。画面の説明は「これまでに発見されたリソース間の重要なつながり」。今回は 96 だった。Agent Space を 21:12（日本時間）に作り、画面に「トポロジマッピング完了」と出たのは 21:18 だった（1 回の観察）。
図6：Web アプリのトポロジー（既定の表示）。リソースが役割のまとまりで描かれる。
今回は、アプリ・監視・ネットワーク・入り口の ALB（Web Gateway）のように分かれた。左上の「表示」で、System・Container・Resource の 3 段階の細かさに切り替えられる。切り替えた先の表示は今回見ていないので、ここでは名前の紹介にとどめる。
調査を始める前に、Agent Space の構成をまとめた文書も自動で作られていた。「アーティファクト」の画面の「Agent Space Summary Report」で、リージョンごとに何があるかを、本番・未使用に分けて書いていた。
図7：アーティファクトの Agent Space Summary Report。「Environments」の表の Production と Unused の行を見る。
6. 調査
6-1. 調査の始め方
調査は、Web アプリの「インシデントレスポンス」の「調査を開始」から手で始められる。CLI からも始められる。今回はアラームとの連携を作らず、毎回同じ形で頼めるように CLI で始めた。渡したのは、アラームの名前・鳴った時刻・調べてほしいことである。
次は Bash の例で、Agent Space を作ってあることが前提である。今回は Agent Space を東京リージョンに作ったので、CLI の操作先も東京リージョンにした。AGENT_SPACE_ID には、作った Agent Space の ID を入れる。
AGENT_SPACE_ID="<Agent Space の ID>"
aws devops-agent create-backlog-task \
--region ap-northeast-1 \
--agent-space-id "$AGENT_SPACE_ID" \
--task-type INVESTIGATION \
--priority HIGH \
--title "アラーム devopslab-ec2-cpu-high が鳴った" \
--description "2026-10-26 21:35 JST にアラーム devopslab-ec2-cpu-high が ALARM になった。原因を調べて、根拠と直し方を示して。"
-
--task-type INVESTIGATION：調査として始める指定 -
--priority HIGH：調査の優先度 -
--titleと--description：運用担当者が受け取る通知の文に近い形で書いた。devopslab-ec2-cpu-highは、CPU 使用率が 90% 以上で鳴るように作ったアラームの名前である
実行すると、Web アプリの「インシデントレスポンス」の一覧に調査が並び、そこから開ける。
図8：インシデントレスポンスの一覧。CLI で始めた調査が並び、「以下によってトリガーされます」の列は「ユーザー」になる。左上に「使用した調査時間」が出る。
一覧の左上には「使用した調査時間」が表示される。調査の課金の対象になる利用時間は、ここで確かめられる（10 章）。
6-2. 調査の画面の 5 つのタブ
調査を開くと、上に 5 つのタブがある。
| タブ | 中身 |
|---|---|
| 概要 | インシデント・原因・緩和策の要約、根拠の一覧（Findings & evidence）、指標のカードとグラフ |
| 調査タイムライン | エージェントが何をどの順で調べたか |
| 根本原因 | 影響と根本原因を、根拠となる観測結果とともに整理したもの。コピーとダウンロードができる |
| 緩和計画 | 直すための手順。事前の確認・適用・事後の確認・切り戻しに分かれる。今回の調査では AWS CLI のコマンドも示された |
| レビュー | 終わった調査の質の評価（公式） |
図9：概要のタブ。上の枠の「原因」の段落と、下の「Findings & evidence」の一覧を見る。
図10：概要の下の方。エージェントが選んだ指標のカードと、時系列のグラフが出る。
CPU の調査では、グラフに時刻の目印が 3 つ付いていた（負荷のコマンドの投入・CPU 100% への到達・アラーム）。グラフはエージェントが調査の中で作ったもので、こちらで用意したダッシュボードではない。タグを読める状態での調査である点は、ここでも同じである（2 章）。
6-3. 調査タイムライン
いちばん情報が多いのは調査タイムラインである。時刻の順に、エージェントの考え、AWS の API を呼んだ回数、調査を分担するサブエージェントの結果が続く。
図11：調査タイムラインの冒頭。左の列が経過時間で、「5 件のツール呼び出し」のような行が API の呼び出し。下の方に、エージェントが読んだタグが出ている。
CPU の調査では、CloudTrail による変更履歴、CPU のメトリクスの内訳、プロセスの一覧のログを、3 つのサブエージェントが同時に調べていた。3 つの結果がそろったところで、直し方を作るサブエージェントに渡していた。
プロセスの一覧のログは、検証環境で用意したものである。EC2 の中で 1 分ごとにプロセスの一覧を書き出し、CloudWatch Logs のロググループに送っていた。エージェントが読んだのは、このロググループである。
図12：調査タイムラインの終わりの方。「最終サマリー」の箇条と、その下の「調査結果」の枠を見る。
結論に至った根拠と順番がここに残るので、原因の要約が合っているかを、自分で追って確かめられる。
6-4. 緩和計画
今回の緩和計画には、事前の確認・適用・事後の確認・切り戻しの手順と、実行するコマンドの例が示されていた。今回はコマンドを実行しておらず、正しさも確かめていない。
図13：緩和計画の冒頭。太字の見出しが計画の要約で、その下の「ステップ 1: 事前検証」からコマンドの例が続く。
図14：「ステップ 2: 適用」。コマンドの例の下にある、青と黄色の注意の枠を見る。
手順のそれぞれに、目的と注意が付く。実行するのは人である。
今回の CPU の調査では、エージェントはインスタンスのタグ（図11 の下の方）も読んでいた。原因の要約は「検証環境での意図的な負荷テスト」で、緩和計画の注意には「止める前に Owner へ可否を確認すること」とあった（図13・図14）。タグを読める状態での調査なので（2 章）、この点も出力の形の例として見てほしい。
6-5. フィードバックと調査の分岐
調査の画面の右上には「フィードバックを追加する」がある。今回は使っていない。
公式の文書によると、原因の当たり外れを返すと、エージェントはそれを教訓として残し、同じアラームの次の調査で読む（7 章のリフレクション）。調査タイムラインの途中のメッセージから調査を分岐させ（フォーク）、別の仮説を追うこともできる。
7. ナレッジとメモリ
ナレッジの画面では、エージェントに渡す情報を扱う。人は調査の方針や手順を与えられ（指示・スキル）、エージェントは環境の情報や調査の教訓を保持する（メモリ）。今回は、構成の情報をまとめたメモリを、調査が読み込む様子が見えた。
ナレッジの画面には「指示・スキル・メモリ」の 3 つのタブがある。
| タブ | 誰が用意するか | 中身 |
|---|---|---|
| 指示 | 人 | 全部のエージェントが毎回読む指示。AGENTS.md2 に近い（公式） |
| スキル | 人 | 調べ方の手順や知識をまとめた文書（Markdown・PDF・画像など）。関係する調査のときだけ読み込まれる（公式） |
| メモリ | エージェント（人も直せる） | 環境の情報や調査の教訓 |
スキルに入れるのは実行しない文書だが、Agent Space の「サンドボックス」（プレビュー。図5 の画面の中ほどにある）を設定すると、実行できるコードも入れられる（公式）。
指示のタブを開くと、指示が各エージェントの詳細ページへ移ったという案内だけが出ていた。指示を書く場所は「エージェント」の画面にある。
図15：ナレッジの指示のタブ。指示がエージェントの画面へ移ったという案内だけが出る。
メモリには 2 種類ある。人が作るカスタムのメモリストアと、エージェントが作って更新するマネージドのメモリストアである。
図16：ナレッジのメモリのタブ。下の方にマネージドのメモリストアが並ぶ。
マネージドのメモリストアには、次の 5 つが並んでいた。
-
understanding-agent-space：Agent Space の構成の理解 - モニター：アラームごとの原因の傾向
- ディレクティブ：チャットで残した指示（今回はチャットを使っていない）
- リフレクション：フィードバックから得た教訓
-
tool-use-best-practices：ツールの使い方。「少なくとも 10 件の完了済み調査が必要（現在 3 件）」と表示されていた
2 回目と 3 回目の調査では、調査タイムラインの冒頭で、このメモリのファイル（/aidevops/memory/understanding-agent-space/overview.md など）を読み込んでいた。調査をまたいで環境の情報を参照していることは、タイムラインから分かる。ファイルの中身がいつ・何から作られたかは、画面からは分からない。
図17：ディスクの調査のタイムラインの冒頭。調べ始める前に、メモリのファイルを読み込んでいる。
8. 改善事項とチャット
改善事項は、終わった調査をまとめて見直し、同じ種類の障害を防ぐ提案を出す画面である。公式の文書によると、既定では週に 1 回、自動で評価が走り、提案は「可観測性・インフラ・ガバナンス・コードの最適化」の 4 つに分類される。画面には「今すぐ実行」もある。
図18：改善事項の画面。右上の「使用した評価時間」と、「推奨事項」の件数を見る。
撮影の時点では、推奨事項は 0 件で、「使用した評価時間」も 00:00 だった。評価が走ったかどうかは、画面からは分からない。評価に使った時間は、調査の時間とは別に数えられる。
チャットは、どの画面でも左の欄にある。調査を開くと、候補が「調査を要約」「調査計画を説明」のように変わった。質問は送っていないので、回答は分からない。公式の文書では、開いている画面に合わせて答える作りとされている。
9. 今回触っていない機能
次の 3 つは、公式の文書の説明だけを書く。
- エージェント：カスタムのエージェントを作り、決まった時刻や webhook のイベントで走らせる。公式の例は、毎朝のデータベースの健康状態のレポートである。調査や学習を受け持つ、AWS が用意したエージェント（マネージドのエージェント）もこの画面にある。
- 外部からの呼び出し：MCP で、IDE やコーディングエージェントから DevOps Agent に調査を頼める。A2A3 で、自分のエージェントから DevOps Agent に仕事を任せたり、DevOps Agent から外部のエージェントに処理を委任したりできる。
- リリース管理（プレビュー）：本番に出す前のコードの変更を見る。見るのは、リポジトリをまたいだ依存の影響・社内の基準への適合・アクセス権の変更である。結果は GitHub や GitLab のプルリクエストにコメントする。変更に合わせたテストを作り、本番に近い環境で動かす機能もある。
10. 料金
料金は、2026-10-27 に公式の料金のページで確かめた（料金は変わることがある）。
課金の対象は、エージェントの稼働時間である。調査・評価・オンデマンドの SRE タスク（チャットとカスタムのエージェント）のどれも、エージェントの稼働時間 1 秒あたり 0.0083 USD が課金される（1 時間で約 30 USD）。エージェントが待っている時間は数えない。リリース管理は、プレビューの間は追加の料金がかからない。
初めて使う利用者には、最初の作業から 2 か月の無料期間がある。1 か月あたり、Agent Space 10 個・調査 20 時間・評価 15 時間・オンデマンドの SRE タスク 20 時間までが無料で、超えた分は通常の料金になる。CloudWatch Logs Insights など、連携先のサービスの料金は別にかかる。
使った時間は、調査の一覧の「使用した調査時間」と、改善事項の「使用した評価時間」に表示される。CLI では aws devops-agent get-account-usage で見る。今回の 3 回の調査は、合わせて約 31 分だった。上の単価では約 15 USD に当たる。無料期間の対象になったかは、まだ分からない。
最後に
原因の要約が合っているかを確かめるときは、調査タイムライン（6-3）を見る。何を根拠に、どの順で絞り込んだかが残っている。
調査の当たり外れは、10 種類の障害を起こした検証の記事で評価する。
参考（確認日：2026-10-26）
- About AWS DevOps Agent
- What is a DevOps Agent Web App?
- Proactive incident prevention
- DevOps Agent Skills（2026-10-27 にサンドボックスの例外を確認）
- DevOps Agent Memories
- Connecting to DevOps Agent Remote Servers
- Release readiness code reviews
- What's new
- AWS DevOps Agent Pricing（2026-10-27 確認）