「AWS DevOps Agentはどこまで任せられるか 〜機能の現在地と、機能拡張の実践〜」というタイトルでDevelopersIO 2026 TOKYOで登壇しました #devio2026
こんにちは。たかやまです。
2026年10月24日に DevelopersIO 2026 TOKYO にて「AWS DevOps Agentはどこまで任せられるか 〜機能の現在地と、機能拡張の実践〜」というタイトルで登壇しました。ご参加いただいた皆さま、ありがとうございました！
AWS DevOps Agentはプレビュー公開から多くの機能が追加され、障害調査の初動を任せられる場面が増えてきました。
一方で、EC2のOS内部の調査や、原因を特定したあとの復旧作業など、標準機能だけでは届かない領域もあります。
本記事では、これまでのアップデートの振り返りと、DevOps Agentを拡張して届かない領域を補った実践を、登壇資料とあわせて紹介します。
登壇資料
内容サマリー
前半は「機能の現在地」として、DevOps Agentのアップデートを振り返り、任せられること・任せられないことを整理しました。
後半は「機能拡張の実践」として、標準機能で届かない以下の2つを補う取り組みを紹介しています。
- OS調査 : MCPでEC2のOSの中まで調べる
- 自動修復 : 調査完了から承認付きで修復まで動かす
アップデートの流れ
調査まわりのアップデートを1枚にまとめたものがこちらです。
プレビュー公開から10か月ほどで、DevOps Agentに任せられる範囲は大きく4段階に広がったと捉えています。
| 段階 | 時期 | 内容 |
|---|---|---|
| 調査と提案 | 2025.12〜 | AIが調べて提案し、人が直す |
| 本番で使える | 2026.03〜 | 人が調べ方を教え、AIが本番を調べる |
| 調査を拡張できる | 2026.05〜 | 人が道具と権限を足し、AIが読める範囲を広げる |
| 承認すれば変更も実行 | 2026.08.25〜 | AIが直し方まで出し、人が承認する |
プレビューの段階では、DevOps Agentが環境を調べて結果をまとめ、それを見て人が直す形のサービスでした。
そこから4か月ほどでGAとなり、Skillsやガバナンスまわりの機能が追加されて、本番で使える形でリリースされました。
5月から8月にかけては、MCPツールの上限の拡張やSandbox・カスタムエージェントの追加、ReadOnlyAccess相当までの調査範囲の拡大など、調査機能の拡張が続いています。
ただし、権限を広げても、作成・変更・削除といった環境を変更する操作は、DevOps Agentが管理する権限ガードレールでブロックされます。
ガードレールについては以下のブログでも詳しく紹介しています。
そして8月のDirected actions（エージェントアクション）で、ユーザーが指示して承認すれば、変更までDevOps Agentが実行できるようになりました。
なお、リソースの削除のような操作は、承認してもDevOps Agent側でブロックされ、実行されません。
Skillsのベストプラクティス
GAに伴い追加されたSkillsについて、AWSブログで公開されているベストプラクティスの一部を紹介しました。
Skillsは、ユーザーが調べ方を書いておくと、DevOps Agentが障害のときに読み込んで使ってくれる、調査をカスタマイズできる機能です。
書くときのポイントになるのが、確実に起動するdescriptionを書くことです。
descriptionはDevOps AgentがSkillを読み込むかどうかの判断材料になるので、具体的なアラーム名や、どのようなエラーのときに使うかを明示的に書くことがポイントとして挙げられています。
ブログには「テーマを絞って小さく始める」という点も書かれていて、個人的にはこの感覚が大事だと思っています。
Skillを細かくたくさん作るより、まずは直近のインシデントで多いカテゴリーの上位3つなど、効果の大きい部分に当てて効果を測っていくのが良さそうです。
また、2026年10月から、完了した調査をReviewで評価できるようになりました。
Skillsでカスタマイズした内容で精度が出ているかを調査後に判定し、足りなければSkillを直すサイクルを回すことで、調査精度を上げていけます。
Skillsのサンプルは、AWSのGitHubで公開されています。
初めてSkillsを使う方は、サンプルから近いものを選ぶのが一番始めやすいと思います。
調査のコストを事前に試算する「Investigation Cost Guardrail」のような汎用的なSkillもあるので、調査コストが気になる方は一度見てみてください。
任せられること・任せられないこと
ここまでのアップデートをもとに、DevOps Agentの現在地として任せられること・任せられないことを整理したものがこちらです。
アラートを起点にした調査、根本原因の特定、緩和計画の提示に加えて、現在は変更の実行まで任せられるようになりました。
ただし、変更の実行には操作ごとにユーザーの指示と承認が必要です。
なお、プレビュー時の緩和計画には修正手順が含まれていませんでした。
一方で、調査権限をReadOnlyAccessまで広げても、EC2のOSを調査するためのSSM Run Commandの権限は含まれないので、OSの内部の情報を使った調査は今もできません。
厳密には、OSのログをCloudWatch Logsなどの外部に出せば調査できますが、そのためにはユーザー側での設定が必要です。
また、Directed actionsは操作ごとにユーザーの承認が必要なので、調査から復旧まで人の手を介さずに任せることも現状できません。
この現在地を踏まえて、後半の本題として、届かない2つの部分を機能のカスタマイズで補う方法を紹介しました。
EC2のOSの内部は調べる道具をMCPでDevOps Agentの中に足し、調査から自動復旧までは実行をDevOps Agentの外の仕組みに任せます。
OS調査MCPの構成
Directed actionsで指示すれば、SSM Run Commandを使ってEC2のOSを調べてもらうことはできます。
ただし、ユーザーの承認が必要になるので、DevOps Agentの自律調査の中では使えません。
そこで、実行内容をSSM Document・LambdaのIAM・ツールの分類の3か所で読み取りだけに絞り、自律調査の中でOS調査ができる仕組みを検討しました。
実装した全体像がこちらです。
DevOps Agentが調査を開始すると、Lambdaで公開しているMCPサーバーに接続します。
OS調査が必要であれば、MCPサーバーが固定で登録したSSM Documentを使い、SSM Run Commandで対象のEC2のOSを調べます。
DevOps Agentが呼べるのは、ここで定義した7つのOS調査ツールだけです。
SSMのコマンドを送れるのはLambdaの実行ロールだけで、DevOps Agent自身には持たせていません。
CPU使用率を100%に張り付かせるプロセスを起動したケースでは、MCPなしでは原因のプロセスを特定できず、調査が仮説のまま止まっていました。
MCPありでは、テストで二重に起動していたreport-batchというプロセスが原因であるところまで特定できました。
MCPで機能を足すことで、権限は読み取りのまま、OSの中まで調査の材料にできることを確認できました。
カスタマイズ版の仕組み
後半の2つ目は、DevOps Agentの調査結果をもとに自動修復まで動かすケースです。
Directed actionsは承認してはじめて実行できるので、DevOps AgentがEventBridgeに送る調査完了イベントを起点に、外部のLambdaで修復を動かす方針で検討しました。
2026年10月ごろにAWSの公式サンプルで同じようなアプローチが公開されていましたが、DevOps Agentが生成した緩和計画を使わない点と、修復の対象がLambdaに絞られている点が自分の環境には合いませんでした。
そこで、公式サンプルをカスタマイズした仕組みを作りました。
カスタマイズ版では、調査完了のイベントを受けてDevOps Agentが生成した緩和計画を取得し、その内容をもとにBedrockで改めて実行手順を生成します。
修復の内容がユーザー側で許可している操作かどうかをLambdaの中で許可リストに照らして確認し、問題なければSlackで承認を求めます。
Slackには手順ごとのコマンドの全文が出るので、1回で承認できます。
ただし、許可リストで絞っているのは、AWS APIの操作の種類と、シェルを実行するインスタンスです。
実行内容が妥当かどうかは、引き続きユーザーが判断する必要があります。
OS調査の例と同じCPU障害では、アラートが通知されたところから環境の調査と修復までを、AWSにログインせずSlack上で承認して完結できました。
まとめ
- 任せられる範囲は10か月で「調査と提案」から「承認すれば変更も実行」まで広がった
- ただし、承認すれば変更まで任せられても、最後の判断はユーザーが持つ
- OSの調査や自動修復は、DevOps Agent単体ではまだできない
- 足りない機能は、MCP・EventBridge・エージェント間連携（A2A）・SaaS MCP連携といった連携の仕組みで補える
最後に
今回は「AWS DevOps Agentはどこまで任せられるか 〜機能の現在地と、機能拡張の実践〜」というタイトルで登壇した内容を紹介しました。
DevOps Agentは8月のアップデートで、調査と提案から、承認すれば変更まで実行できるようになり、任せられる範囲がだいぶ広がりました。
一方で、OSの自律調査や、調査が終わってからの修復の連携は、標準の機能では今もできません。
今回はMCPとEventBridgeの口で拡張することで、この部分を補いました。
DevOps Agentには拡張の口が多く用意されているので、できないことがあってもそこで終わりにせず、足りない部分はカスタマイズして使うことをぜひ検討してみてください。
以上、たかやま(@nyan_kotaroo)でした。
