AWS DevOps Agent 検証で見えた可能性と限界 / AWS DevOps Agent

Transcript

1. JAWS-UG 千葉支部 山口 正徳 AWS Community Hero AWSが提唱するフロンティアエージェントの真価とは AWS DevOps Agent 入門 - 検証で見えた可能性と限界 1
2. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. 山口 正徳 JAWS-UG千葉支部 AWS re:Inforce 最後の日本人登壇者 グローバル認定/表彰 ・AWS Community HERO ・AWS Ambassador ・APJ AWS Community Leaders Award 2回受賞（2022、2024） ・AWS Gold Jacket Club 日本国内認定/表彰 ・AWS Samurai 2020 ・Japan AWS Top Engineer 2019 – 2023、2025 ・APN ALL AWS Certifications Engineers 2023 – 2024 自己紹介
4. ・自律的 (Autonomous) 単にタスクをこなすのではなく、 「ゴール（目標）」を与えられると、 それを達成するための方法を自ら考える。 人間が手取り足取り指示する必要がない ・大規模スケール（Scalable) 個々のエージェントが並行して複数のタ スクをこなすだけでなく、エージェント 自体を分散させ、作業をスケールアウト する ・長時間実行 (Long-running) 人間の介入なしに、数時間から数日間に わたり、複雑で曖昧な目標を達成するた めに働き続けることができる。
5. ソフトウェア開発を再定義する３つの FRONTIER AGENTS バックログの複雑なタスク （機能追加、バグ修正、コ ードカバレッジ改善など） を割り当てると、Kuroは自 律的に計画を立て実行。 チームの状況やパターンも 学習する。 設計段階からソフトウェア にセキュリティを組み込む。 設計書をレビュー、コード のセキュリティスキャン、 オンデマンドの侵入テスト を行い。エージェント自身 もスケールし全てのアプリ ケーションをテストする。 インシデントの調査や改善 点の特定を、まるで経験豊 富なDevOpsエンジニアの ように対応する。 相関関係の理解、根本原因 の特定、将来の障害予防ま でエージェントが対応。
6. 6 AWS DevOps Agent 概要
7. 7 AWS DevOps Agentとは エージェントを利用した自律的なインシデント対応と予防 ・即時対応 アラートやチケットをトリガーにインシデント調査を即時開始 ・根本原因の特定 テレメトリーデータ、コード、監査情報、デプロイ環境を相関 分析し、インシデントの根本原因を特定 ・プロアクティブな改善 過去のインシデントパターンから学習し、監視、インフラ、 デプロイパイプラインなどの改善点を提案
8. 8 AWS DevOps Agentとは 導入時に得られるメリット ・平均復旧時間 (MTTR) の短縮 ・再発防止とシステム回復力の向上 ・既存のツールやワークフローとのシームレスな統合 ・運用に関するトイルを削減し、生産性の高い作業に集中 ※ 現時点でDevOps Agentは書き込み操作はできず、 緩和策の実行は 他のツールが必要
9. 9 Agent Spaces 独立した環境 各スペースは独立して動作し、固有 のAWSアカウント設定、外部ツー ル統合、ユーザー権限を設定可能。 AWSアカウントの分離 専用のIAMロールを使用し、設定さ れたリソースのみにアクセスを制限。 環境の分離 本番環境と開発環境など、エージェ ントが調査可能なスペースに分ける ことで、誤操作を防止。 外部ツールとの連携 GitHubやNew Relicなどの外部ツ ールへの連携も可能。外部ツールの 接続もスペースごとに分離。
10. 10 デュアルコンソール 管理者向け 管理者は AWSマネージメントコン ソールから操作 オペレーター用 オペレーターは専用のWebアプリ から操作 設定と管理 ・Agent Spaceの作成 ・AWSリソース連携設定 ・サードパーティツール統合 ・IAMによるアクセス権限管理 日々の運用と対応 ・インシデント調査の実行 ・自然言語チャットでの対話 ・トポロジーの確認 ・予防的推奨事項のレビュー
11. 11 デュアルコンソール 管理者向け 管理者は AWSマネージメントコン ソールから操作 設定と管理 ・Agent Spaceの作成 ・AWSリソース連携設定 ・サードパーティツール統合 ・IAMによるアクセス権限管理
12. 12 デュアルコンソール オペレーター用 オペレーターは専用のWebアプリ から操作 日々の運用と対応 ・インシデント調査の実行 ・自然言語チャットでの対話 ・トポロジーの確認 ・予防的推奨事項のレビュー
13. 13 プロンプトインジェクションによる悪意ある変更からの保護 多層的な防御策（Safeguards） ・限定的な書き込み能力： リソースを変更する調査は行わないのが基本。 ・アカウント境界の強制： 設定されたIAMロールの権限囲内でのみ動作。 ・AIセーフティ保護： Claude Sonnet 4.5に組み込まれたASL-3保護 機能が攻撃を検知・防止。 ・変更不可能な監査証跡： エージェントジャーナルにより、悪意のある アクションの隠蔽を防止。 ユーザーの責任範囲とリスク ・ カスタムMCPサーバーツール： 独自のツールは追加のリスクとなる可能性がある。 ・承認済みユーザーによる攻撃： データソースを変更できる権限を持つユーザーは 注意が必要。
14. 14 インシデント対応フロー(専用Webアプリケーションから実施） 検知 自動調査 原因調査 チャット対話 緩和策提示 振り返り 恒久予防 ・アラート受信 ・Webhookなどを トリガーにして 調査を自動開始 ・手動で調査指示 を開始 ・調査状況をリアル タイムで確認可能 ・チャットで調査方 針や詳細節名など 追加指示が可能 ・具体的なアクショ ンプラン、検証、 ロールバック手順 を提示。 ・Slackへの通知や AWS Supportの 起票も可能。 ・将来のインシデン トを予防する対応 策も提示
15. 15 • Agent Spaceの作成数: 最大10個 • インシデント解決（Resolution）の利用時間: 月間20時間 • インシデント予防（Prevention）の利用時間: 月間10時間 • チャットメッセージ数: 月間1,000件 • 同時実行タスク数: ◦ インシデント解決調査タスク：同時に3つまで ◦ インシデント予防評価タスク：同時に1つまで プレビュー中の制限
16. 16 その実力を見せてもらおうか！ AWS DevOps Agent 検証
17. 17 AWS DevOps Agent 公式ドキュメントに検証環境の構築手順、検証方法が記載 されています。 「Getting started with AWS DevOps Agent」 https://docs.aws.amazon.com/devopsagent/latest/userguide/getting- started-with-aws-devops-agent.html EC2、Lambdaで稼働する、それぞれの環境に対して DevOps Agent を使って 障害調査、障害対応を行う手順を確認することができます。 簡易な検証方法の紹介
18. 18 今回は別の環境を用意し、検証観点をもって動作確認します。
19. 19 1. ミドルウェア、アプリケーションレベルの問題は調査可能か？ 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか？ 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか？ 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ 検証観点
20. 20 検証環境（全体構成） バージニア北部 (us-east-1) Availability Zone Availability Zone Public subnet Public subnet Private subnet Private subnet ALB ALB Webサーバー群 Session Manager S3 Bucket DevOps Agent CloudWatch Logs
21. 21 検証環境（ALBリスナー・ルール） ALB Nginx (Session Manager有効） Apache (Session Manager有効） Nginx (SSH接続のみ） https://{alb-fqdn}:8081/ https://{alb-fqdn}:8080/ https://{alb-fqdn}:8080/test/ Target Group
22. 22 1. ミドルウェア、アプリケーションレベルの問題は調査可能か？ ALB Nginx (Session Manager有効） https://{alb-fqdn}:8080/ Session Manager CloudWatch Logs オペレーションログ送信 OSオペレーション オペレーションログの記録（CloudWatch Logs）を有効化
23. 23 1. ミドルウェア、アプリケーションレベルの問題は調査可能か？ ALB Nginx (Session Manager有効） https://{alb-fqdn}:8080/ Session Manager CloudWatch Logs ① index.htmlを リネーム ② HTTP ステータス 4xx に変化 Target Groupでエラー(Unhealthy)が発生 DevOps Agent ③Target Groupでエラー (Unhealthy)が発生している原因を調査 オペレーションログ送信
24. 24 1. ミドルウェア、アプリケーションレベルの問題は調査可能か？ Session Managerで記録したオペレーションログをもとにOS内の設定状況を調査し、 ミドルウェア（Nginx）の設定に起因する問題特定を行うことができた。
25. 25 1. ミドルウェア、アプリケーションレベルの問題は調査可能か？ 根本原因の特定、緩和計画（是正対応の作業手順）も作成可能。
26. 26 1. ミドルウェア、アプリケーションレベルの問題は調査可能か？ 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか？ 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか？ 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ 検証観点 ミドルウェア、アプリケーションレベルの問題も調査可能。 ただし、OSのオペレーションログがなければ調査できない可能性がある。
27. 27 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか？ ALB Nginx (SSH接続のみ） AWS環境にオペレーション ログの保存なし OSオペレーション ローカルPCから SSH接続 ローカルに オペレーション ログを保存 https://{alb-fqdn}:8080/test/
28. 28 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか？ ALB Nginx (SSH接続のみ） ① /test/index.htmlを リネーム ② HTTP ステータス 4xx に変化 Target Groupでエラー(Unhealthy)が発生 DevOps Agent ③Target Groupでエラー (Unhealthy)が発生している原因を調査 ローカルPCから SSH接続 https://{alb-fqdn}:8080/test/
29. 29 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか？ 責任共有モデルにおいてAWSが責任を負う範囲（AWS APIで参照可能な範囲）には、EC2 インスタンス内部の状況を確認できる情報が含まれていないため、推測に基づいた調査結果の 提示となった。
30. 30 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか？ 根本原因も特定することはできず、仮説になる。
31. 31 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか？ 根本原因を特定できないため、緩和策を提示することができない。
32. 32 1. ミドルウェア、アプリケーションレベルの問題は調査可能か？ 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか？ 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか？ 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ 検証観点 OSオペレーションに起因する調査は、OSオペレーションログが必要。 推測に基づいた原因の提示はできるが、根本原因や緩和策の提示はできな い。また、Session ManagerやSSHでOSに接続して調査を継続すること も現時点ではできない。
33. 33 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか？ ALB Apache (Session Manager有効） https://{alb-fqdn}:8081/ Session Manager CloudWatch Logs オペレーションログ送信 OSオペレーション オペレーションログの記録（CloudWatch Logs）を有効化
34. 34 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか？ ALB Apache (Session Manager有効） https://{alb-fqdn}:8081/ Session Manager CloudWatch Logs ① index.htmlを リネーム ② HTTP ステータス 4xx に変化 Target Groupでエラー(Unhealthy)が発生 DevOps Agent ③Target Groupでエラー (Unhealthy)が発生している原因を調査 オペレーションログ送信
35. 35 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか？ Session Managerで記録したオペレーションログをもとにOS内の設定状況を調査し、 ミドルウェア（Apache）の設定に起因する問題特定を行うことができた。
36. 36 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか？ 根本原因の特定、緩和計画（是正対応の作業手順）も作成可能。
37. 37 1. ミドルウェア、アプリケーションレベルの問題は調査可能か？ 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか？ 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか？ 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ 検証観点 Nginx、Apacheレベルであれば調査品質に違いはなし。 情報量が多いプロダクトは学習が十分にされているため問題ないと 思われれる。（MySQL、PostgreSQLなど）
38. 38 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ ALB Nginx (Session Manager有効） https://{alb-fqdn}:8080/ Session Manager オペレーションログ送信 OSオペレーション オペレーションログの記録（S3）を有効化 S3 Bucket
39. 39 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ ALB Nginx (Session Manager有効） https://{alb-fqdn}:8080/ Session Manager ① Target Groupの ヘルスチェックパスを 存在しないHTMLファイル /health/health.htmlに変更 (※) ② HTTP ステータス 4xx に変化 Target Groupでエラー(Unhealthy)が発生 DevOps Agent ③Target Groupでエラー (Unhealthy)が発生している原因を調査 オペレーションログ送信 S3 Bucket ※これまでの検証で実施したオペレーション履歴からDevOps Agentが原因を特定できない状況を作るため
40. 40 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ DevOps Agent作成時に自動的に作成されるIAMロール・IAMポリシー
41. 41 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ CloudWatch Logsのロググループ（ログストリーム）をクエリする権限が付与されている。
42. 42 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ S3に対してはオブジェクトへのアクセス権限が付与されていない。DevOps Agentは、 S3に存在するオブジェクトへの調査は想定していないのか・・・？
43. 43 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ 検証のため、GetObjectを含む S3 の読み取り権限を与えるポリシーを付与。
44. 44 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ DevOps Agentは、S3に存在するオブジェクトへの調査は想定していないのか？ 切り分けのため、DevOps AgentへS3バケットにログがあることを補足情報として 渡さずにTarget Groupで発生しているエラーの調査指示を行った。
45. 45 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ 結果的な調査結果しか提示できず、なぜ /health/health.html が存在しないのか、 ミドルウェアの設定ミスなどの可能せについては言及されない。
46. 46 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ DevOps AgentへS3バケットにログがあることを補足情報として渡し、追加調査の指示を 行った。
47. 47 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ DevOps AgentへS3バケットにログがあることを補足情報として渡すと、該当オブジェク トを参照し、その内容をもとに調査をしてくれることが分かった。
48. 48 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ 根本原因の特定、緩和計画（是正対応の作業手順）も作成可能。
49. 49 1. ミドルウェア、アプリケーションレベルの問題は調査可能か？ 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか？ 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか？ 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか？ 検証観点 DevOps Agent スペースに関連付けされているIAMロールに対して、 必要なオペレーションを許可するIAMポリシーを付与する。 さらに、 DevOps Agent に対して明示的に該当リソースに対する 調査指示を行うことで実現可能。
50. 50 日本語は未対応 ・ブラウザの日本語翻訳は利用可能だが、画面遷移すると JSエラーになる。
51. 51 日本語は未対応 ・日本語入力は未対応。
52. 52 （仕様？）AWSタグはスペース作成時に設定しないと動作しない？ AWS DevOps Agentスペース作成後もタグ指定できるが、 タグ未指定時と同じ挙動となる。
53. 53 （仕様？）AWSタグはスペース作成初期に設定しないと動作しない？ CloudFormationでデプロイした環境をAWS DevOps Agentの対象 とする場合は、予めスタックへのタグ付けをした上で、AWS DevOps Agentスペースでタグ指定をする必要あり。
54. 54 1. DevOps Agentはミドルウェア、アプリケーションレベルの問題も 調査し、根本原因の特定と緩和策の提示をしてくれる。 2. DevOps AgentにOSレベルの調査を期待する場合は、オペレーション ログ（履歴）を保存し、DevOps Agentがアクセス可能な状態でなけ れば推測レベルの調査になってしまう。 3. Nginx、Apacheでは調査品質に違いはなかった。情報が多い（学習し やすい）著名なミドルウェアの調査は問題ないと思われる。 4. DevOps Agentが想定する範囲を超えたリソースの調査は、DevOps Agentに権限を与え、調査指示することで対応可能となる。 検証結果まとめ
55. 55 ご清聴ありがとうございました。