【登壇レポート】「その運用、まだ人が抱えますか？ AWS DevOps Agentの価値 -」というタイトルでミニセッションに登壇しました #AWSSummit
クラウド事業本部運用イノベーション部の いそま です。
AWS Summit Japan 2026 の弊社ブースミニセッションにて、「その運用、まだ人が抱えますか？ AWS DevOps Agentの価値 -」というタイトルで登壇しました！
本ブログでは、登壇資料の内容を紹介させていただきます。
登壇内容
今回の登壇では、タイトルにもある通り、AWS DevOps Agentが運用現場にもたらす価値を皆様に感じていただくことを目的としました。
登壇後には「AWS DevOps Agent早く使ってみたいです！」というお声をいただいたので、無事に目的を達成できたのではないかと思っています（主観）。
AWS DevOps Agentとは
AWS DevOps Agentについては、弊社ブログで多数紹介されていますので割愛させていただきます。
ちなみに、おすすめのブログはこちらです！
AWS DevOps Agentの概要はもちろん、一般提供（GA）に伴う変更点とプレビュー期間中に段階的に追加された変更点も紹介されていますので必見です✨
AWS DevOps Agentの活用
AWS DevOps Agentの価値を発揮するための効果的な活用方法を紹介します。
ベストプラクティス
まず、基本の「き」のベストプラクティスです。
(参考)https://aws.amazon.com/jp/blogs/news/best-practices-for-deploying-aws-devops-agent-in-production/
ベストプラクティスを達成するためには、Agent Spaceを攻略する必要があります。
Agent Space は、AWS DevOps Agent がアクセスおよび調査できる範囲を定義する論理的なコンテナです。
エージェントの運用範囲と考えてください。どのクラウドアカウントをエージェントがクエリできるか、どのサードパーティ統合が利用可能か、誰が調査に関与できるかを決定します。
Agent Space が重要なのは、AWS DevOps Agent が正確な根本原因分析を行うために十分なコンテキストを必要とするからです。
ここでは、Agent Space攻略のための３ステップを紹介します。
ステップ 1.本番環境と非本番環境を分ける
Agent Spaceはエージェントが調査できる範囲を決める枠組みだとイメージしていただきたいのですが、
その枠組みの中に例えば以下のような複数環境が混在していたら、どうなるでしょうか。
ex.
・本番・検証・開発環境
・システムAの環境,システムBの環境
エージェントがどの環境を調査するべきなのか迷ってしまいますよね。
もちろん、エージェントはとても優秀なので
インシデントログなどからどの環境が対象なのかを最終的に見つけ出すことはできるのですが、
それまでの工程が複雑になり、調査時間が長引いたり、無駄にトークンを消費する可能性があります。
そのため、あらかじめ調査する範囲を絞ってあげることが重要になります。
ステップ 2.IaCで設定を標準化する
Agent SpaceはIaC（AWS CDK（TypeScript/Python）、Terraform）でデプロイすることが可能です。
手作業(GUI操作)ではなく、同じ品質で設計を横展開することができます。
大規模な運用フローにAWS DevOps Agentを組み込まれる場合は、IaCで一貫した設定を展開することをご検討ください。
ステップ 3.調査データを繋ぐ
AWS DevOps Agentの大きな強みは外部ツールとの統合です。
現在、AWSクラウドを基盤とする数多くのシステムがありますが、
大規模なシステムになればなるほど、AWSサービス以外のツールが組み合わされています。
例えば、監視ツールにNewRelicなどのオブザーバビリティツールを使用し、ServiceNowやPagerDutyといったチケット管理ツールにインシデントチケットを発行しているというパターンです。
この場合、これらのツールをAgentSpace（またはAWS DevOps Agentそのもの）と連携させることで、
エージェントが外部ツールにまで踏み込んで調査をしてくれます。
そのため、アラートのログや画面キャプチャをエージェントにコピペする必要がなくなり、
人間が介入せずとも、必要なツールをエージェントが自動で見にいってくれるという素晴らしい構造ができあがります。
（ありがたいです…😭）
個人的なおすすめ
個人的におすすめの活用方法を最後に紹介します。
AWS DevOps Agentはとても便利で素晴らしいサービスですが、その分料金もかかります。
知らぬうちに大量に課金されておた…なんてことがないように、導入前に予防策を検討しておくことが大事です。
ポイントは
アラートの重要度によって、AWS DevOps Agentに調査させる/させない
を設計することだと考えています。
重要度が低いアラート（ex.CPU使用率が60%超）まで調査をさせてしまうと、その分料金がかかってくるため、
費用対効果の高い使い方ができているとはいえない状態となってしまいます。
解決策としては、ServiceNowやPagerDuty等のチケット管理ツールを導入し、
アラートの重要度を設計した上で、重要度の高いアラートのみAWS DevOps Agentに調査をしてもらうことで、
本当に支払うべき調査にお金をかけることができます。
AWS DevOps Agentユースケース
AWS DevOps Agentの一般的なユースケースをご紹介します。
Lambdaエラー調査
動作フロー
1. Lambda実行時にエラーが発生！
2. CloudWatch Alarmで検知、SNSに配信
3. SNSからPagerDutyにAPI経由で連携
4. PagerDutyでイベント整形/フィルタリングを実施の上で、インシデント起票
5. DevOpsAgentがキックされ、インシデントの内容をもとに調査を開始
6. エラーログおよび、連携しているGitHubリポジトリを含め包括的に調査実施
7. GitHubのコミット履歴から、最終更新時のコードソースにバグがあることを発見
8. 調査結果をPagerDutyのインシデント（メモ）に追記
全体図
人間が登場するのは、（全体図の）「担当者への通知」がされてからです。
そのため、アラート発報〜調査〜通知まで、人間が一切介入することなく、完全自動化することができます。
マルチアカウント対応
次に紹介するユースケースは、マルチアカウント対応です。
※プライマリアカウント = AWS DevOps Agentを導入するアカウント
※セカンダリアカウント＝調査対象のアカウント（インシデントが発生したアカウント）
AWS DevOps Agentは、調査対象の別アカウントをセカンダリアカウントとして連携することができます。
こちらの構成図がイメージしやすいかと思います。
「セカンダリアカウント側にもAWS DevOps Agentを導入する必要があるのか？」
というご質問をいただいたのですが、結論不要です。
セカンダリアカウント側では、IAMロールを作成し、プライマリアカウントとの信頼関係を設定するのみとなります。
設定方法はとても簡単です。気になる方は下記ドキュメントをご参照ください。
複数のセカンダリアカウントをまとめて追加したい場合は、こちらの記事がとても参考になります✨
まとめ
（冒頭にスライドを添付していますので一部割愛させていただきます）
- スコープとパフォーマンスのトレードオフを設計することが重要
- 組織において最適な、Agent Spaceの分割範囲を考える（アプリ単位、環境単位（本番/環境）、チーム単位etc…）
- AWS DevOps Agentの強みを最大限活用する
- 外部ツールとの豊富なネイティブ連携
- マルチアカウント対応
- GUI操作での導入が簡単
- CDK、Terraformを利用したIaCでのデプロイも可能
- CDK、Terraformを利用したIaCでのデプロイも可能
- 強みを引き出すためのおすすめの使い方
- アラートの重要度によって、AWS DevOps Agentに調査させる/させないを設計することで、費用対効果の高い使い方ができる
感想
AWS DevOps Agentは個人的に最注目＆最推しのサービスですので、皆様に魅力が伝わると嬉しいです。
また、AWS Summit初参加かつミニセッション初登壇でかなり緊張していましたが、充実感した時間を過ごすことができました。
改めまして、弊社ブース及びミニセッションに足を運んで下さった方に感謝申し上げます。
