Slide 1

Slide 1 text

JAWS-UG 千葉支部 山口 正徳 AWS Community Hero AWSが提唱するフロンティアエージェントの真価とは AWS DevOps Agent 入門 - 検証で見えた可能性と限界 1

Slide 2

Slide 2 text

© 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 自己紹介

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

・自律的 (Autonomous) 単にタスクをこなすのではなく、 「ゴール(目標)」を与えられると、 それを達成するための方法を自ら考える。 人間が手取り足取り指示する必要がない ・大規模スケール(Scalable) 個々のエージェントが並行して複数のタ スクをこなすだけでなく、エージェント 自体を分散させ、作業をスケールアウト する ・長時間実行 (Long-running) 人間の介入なしに、数時間から数日間に わたり、複雑で曖昧な目標を達成するた めに働き続けることができる。

Slide 5

Slide 5 text

ソフトウェア開発を再定義する3つの FRONTIER AGENTS バックログの複雑なタスク (機能追加、バグ修正、コ ードカバレッジ改善など) を割り当てると、Kuroは自 律的に計画を立て実行。 チームの状況やパターンも 学習する。 設計段階からソフトウェア にセキュリティを組み込む。 設計書をレビュー、コード のセキュリティスキャン、 オンデマンドの侵入テスト を行い。エージェント自身 もスケールし全てのアプリ ケーションをテストする。 インシデントの調査や改善 点の特定を、まるで経験豊 富なDevOpsエンジニアの ように対応する。 相関関係の理解、根本原因 の特定、将来の障害予防ま でエージェントが対応。

Slide 6

Slide 6 text

6 AWS DevOps Agent 概要

Slide 7

Slide 7 text

7 AWS DevOps Agentとは エージェントを利用した自律的なインシデント対応と予防 ・即時対応 アラートやチケットをトリガーにインシデント調査を即時開始 ・根本原因の特定 テレメトリーデータ、コード、監査情報、デプロイ環境を相関 分析し、インシデントの根本原因を特定 ・プロアクティブな改善 過去のインシデントパターンから学習し、監視、インフラ、 デプロイパイプラインなどの改善点を提案

Slide 8

Slide 8 text

8 AWS DevOps Agentとは 導入時に得られるメリット ・平均復旧時間 (MTTR) の短縮 ・再発防止とシステム回復力の向上 ・既存のツールやワークフローとのシームレスな統合 ・運用に関するトイルを削減し、生産性の高い作業に集中 ※ 現時点でDevOps Agentは書き込み操作はできず、 緩和策の実行は 他のツールが必要

Slide 9

Slide 9 text

9 Agent Spaces 独立した環境 各スペースは独立して動作し、固有 のAWSアカウント設定、外部ツー ル統合、ユーザー権限を設定可能。 AWSアカウントの分離 専用のIAMロールを使用し、設定さ れたリソースのみにアクセスを制限。 環境の分離 本番環境と開発環境など、エージェ ントが調査可能なスペースに分ける ことで、誤操作を防止。 外部ツールとの連携 GitHubやNew Relicなどの外部ツ ールへの連携も可能。外部ツールの 接続もスペースごとに分離。

Slide 10

Slide 10 text

10 デュアルコンソール 管理者向け 管理者は AWSマネージメントコン ソールから操作 オペレーター用 オペレーターは専用のWebアプリ から操作 設定と管理 ・Agent Spaceの作成 ・AWSリソース連携設定 ・サードパーティツール統合 ・IAMによるアクセス権限管理 日々の運用と対応 ・インシデント調査の実行 ・自然言語チャットでの対話 ・トポロジーの確認 ・予防的推奨事項のレビュー

Slide 11

Slide 11 text

11 デュアルコンソール 管理者向け 管理者は AWSマネージメントコン ソールから操作 設定と管理 ・Agent Spaceの作成 ・AWSリソース連携設定 ・サードパーティツール統合 ・IAMによるアクセス権限管理

Slide 12

Slide 12 text

12 デュアルコンソール オペレーター用 オペレーターは専用のWebアプリ から操作 日々の運用と対応 ・インシデント調査の実行 ・自然言語チャットでの対話 ・トポロジーの確認 ・予防的推奨事項のレビュー

Slide 13

Slide 13 text

13 プロンプトインジェクションによる悪意ある変更からの保護 多層的な防御策(Safeguards) ・限定的な書き込み能力: リソースを変更する調査は行わないのが基本。 ・アカウント境界の強制: 設定されたIAMロールの権限囲内でのみ動作。 ・AIセーフティ保護: Claude Sonnet 4.5に組み込まれたASL-3保護 機能が攻撃を検知・防止。 ・変更不可能な監査証跡: エージェントジャーナルにより、悪意のある アクションの隠蔽を防止。 ユーザーの責任範囲とリスク ・ カスタムMCPサーバーツール: 独自のツールは追加のリスクとなる可能性がある。 ・承認済みユーザーによる攻撃: データソースを変更できる権限を持つユーザーは 注意が必要。

Slide 14

Slide 14 text

14 インシデント対応フロー(専用Webアプリケーションから実施) 検知 自動調査 原因調査 チャット対話 緩和策提示 振り返り 恒久予防 ・アラート受信 ・Webhookなどを トリガーにして 調査を自動開始 ・手動で調査指示 を開始 ・調査状況をリアル タイムで確認可能 ・チャットで調査方 針や詳細節名など 追加指示が可能 ・具体的なアクショ ンプラン、検証、 ロールバック手順 を提示。 ・Slackへの通知や AWS Supportの 起票も可能。 ・将来のインシデン トを予防する対応 策も提示

Slide 15

Slide 15 text

15 • Agent Spaceの作成数: 最大10個 • インシデント解決(Resolution)の利用時間: 月間20時間 • インシデント予防(Prevention)の利用時間: 月間10時間 • チャットメッセージ数: 月間1,000件 • 同時実行タスク数: ◦ インシデント解決調査タスク:同時に3つまで ◦ インシデント予防評価タスク:同時に1つまで プレビュー中の制限

Slide 16

Slide 16 text

16 その実力を見せてもらおうか! AWS DevOps Agent 検証

Slide 17

Slide 17 text

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 を使って 障害調査、障害対応を行う手順を確認することができます。 簡易な検証方法の紹介

Slide 18

Slide 18 text

18 今回は別の環境を用意し、検証観点をもって動作確認します。

Slide 19

Slide 19 text

19 1. ミドルウェア、アプリケーションレベルの問題は調査可能か? 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか? 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか? 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? 検証観点

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

22 1. ミドルウェア、アプリケーションレベルの問題は調査可能か? ALB Nginx (Session Manager有効) https://{alb-fqdn}:8080/ Session Manager CloudWatch Logs オペレーションログ送信 OSオペレーション オペレーションログの記録(CloudWatch Logs)を有効化

Slide 23

Slide 23 text

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)が発生している原因を調査 オペレーションログ送信

Slide 24

Slide 24 text

24 1. ミドルウェア、アプリケーションレベルの問題は調査可能か? Session Managerで記録したオペレーションログをもとにOS内の設定状況を調査し、 ミドルウェア(Nginx)の設定に起因する問題特定を行うことができた。

Slide 25

Slide 25 text

25 1. ミドルウェア、アプリケーションレベルの問題は調査可能か? 根本原因の特定、緩和計画(是正対応の作業手順)も作成可能。

Slide 26

Slide 26 text

26 1. ミドルウェア、アプリケーションレベルの問題は調査可能か? 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか? 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか? 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? 検証観点 ミドルウェア、アプリケーションレベルの問題も調査可能。 ただし、OSのオペレーションログがなければ調査できない可能性がある。

Slide 27

Slide 27 text

27 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか? ALB Nginx (SSH接続のみ) AWS環境にオペレーション ログの保存なし OSオペレーション ローカルPCから SSH接続 ローカルに オペレーション ログを保存 https://{alb-fqdn}:8080/test/

Slide 28

Slide 28 text

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/

Slide 29

Slide 29 text

29 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか? 責任共有モデルにおいてAWSが責任を負う範囲(AWS APIで参照可能な範囲)には、EC2 インスタンス内部の状況を確認できる情報が含まれていないため、推測に基づいた調査結果の 提示となった。

Slide 30

Slide 30 text

30 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか? 根本原因も特定することはできず、仮説になる。

Slide 31

Slide 31 text

31 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか? 根本原因を特定できないため、緩和策を提示することができない。

Slide 32

Slide 32 text

32 1. ミドルウェア、アプリケーションレベルの問題は調査可能か? 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか? 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか? 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? 検証観点 OSオペレーションに起因する調査は、OSオペレーションログが必要。 推測に基づいた原因の提示はできるが、根本原因や緩和策の提示はできな い。また、Session ManagerやSSHでOSに接続して調査を継続すること も現時点ではできない。

Slide 33

Slide 33 text

33 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか? ALB Apache (Session Manager有効) https://{alb-fqdn}:8081/ Session Manager CloudWatch Logs オペレーションログ送信 OSオペレーション オペレーションログの記録(CloudWatch Logs)を有効化

Slide 34

Slide 34 text

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)が発生している原因を調査 オペレーションログ送信

Slide 35

Slide 35 text

35 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか? Session Managerで記録したオペレーションログをもとにOS内の設定状況を調査し、 ミドルウェア(Apache)の設定に起因する問題特定を行うことができた。

Slide 36

Slide 36 text

36 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか? 根本原因の特定、緩和計画(是正対応の作業手順)も作成可能。

Slide 37

Slide 37 text

37 1. ミドルウェア、アプリケーションレベルの問題は調査可能か? 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか? 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか? 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? 検証観点 Nginx、Apacheレベルであれば調査品質に違いはなし。 情報量が多いプロダクトは学習が十分にされているため問題ないと 思われれる。(MySQL、PostgreSQLなど)

Slide 38

Slide 38 text

38 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? ALB Nginx (Session Manager有効) https://{alb-fqdn}:8080/ Session Manager オペレーションログ送信 OSオペレーション オペレーションログの記録(S3)を有効化 S3 Bucket

Slide 39

Slide 39 text

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が原因を特定できない状況を作るため

Slide 40

Slide 40 text

40 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? DevOps Agent作成時に自動的に作成されるIAMロール・IAMポリシー

Slide 41

Slide 41 text

41 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? CloudWatch Logsのロググループ(ログストリーム)をクエリする権限が付与されている。

Slide 42

Slide 42 text

42 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? S3に対してはオブジェクトへのアクセス権限が付与されていない。DevOps Agentは、 S3に存在するオブジェクトへの調査は想定していないのか・・・?

Slide 43

Slide 43 text

43 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? 検証のため、GetObjectを含む S3 の読み取り権限を与えるポリシーを付与。

Slide 44

Slide 44 text

44 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? DevOps Agentは、S3に存在するオブジェクトへの調査は想定していないのか? 切り分けのため、DevOps AgentへS3バケットにログがあることを補足情報として 渡さずにTarget Groupで発生しているエラーの調査指示を行った。

Slide 45

Slide 45 text

45 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? 結果的な調査結果しか提示できず、なぜ /health/health.html が存在しないのか、 ミドルウェアの設定ミスなどの可能せについては言及されない。

Slide 46

Slide 46 text

46 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? DevOps AgentへS3バケットにログがあることを補足情報として渡し、追加調査の指示を 行った。

Slide 47

Slide 47 text

47 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? DevOps AgentへS3バケットにログがあることを補足情報として渡すと、該当オブジェク トを参照し、その内容をもとに調査をしてくれることが分かった。

Slide 48

Slide 48 text

48 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? 根本原因の特定、緩和計画(是正対応の作業手順)も作成可能。

Slide 49

Slide 49 text

49 1. ミドルウェア、アプリケーションレベルの問題は調査可能か? 2. DevOps AgentがOSオペレーションを確認可能または不可能となる 境界はどこにあるのか? 3. 著名なミドルウェアでもプロダクトによる調査品質に違いはあるか? 4. DevOps Agentスペース作成時に自動的に作成されるIAMロール・ IAMポリシーを超えた調査指示はどのように実現できるのか? 検証観点 DevOps Agent スペースに関連付けされているIAMロールに対して、 必要なオペレーションを許可するIAMポリシーを付与する。 さらに、 DevOps Agent に対して明示的に該当リソースに対する 調査指示を行うことで実現可能。

Slide 50

Slide 50 text

50 日本語は未対応 ・ブラウザの日本語翻訳は利用可能だが、画面遷移すると JSエラーになる。

Slide 51

Slide 51 text

51 日本語は未対応 ・日本語入力は未対応。

Slide 52

Slide 52 text

52 (仕様?)AWSタグはスペース作成時に設定しないと動作しない? AWS DevOps Agentスペース作成後もタグ指定できるが、 タグ未指定時と同じ挙動となる。

Slide 53

Slide 53 text

53 (仕様?)AWSタグはスペース作成初期に設定しないと動作しない? CloudFormationでデプロイした環境をAWS DevOps Agentの対象 とする場合は、予めスタックへのタグ付けをした上で、AWS DevOps Agentスペースでタグ指定をする必要あり。

Slide 54

Slide 54 text

54 1. DevOps Agentはミドルウェア、アプリケーションレベルの問題も 調査し、根本原因の特定と緩和策の提示をしてくれる。 2. DevOps AgentにOSレベルの調査を期待する場合は、オペレーション ログ(履歴)を保存し、DevOps Agentがアクセス可能な状態でなけ れば推測レベルの調査になってしまう。 3. Nginx、Apacheでは調査品質に違いはなかった。情報が多い(学習し やすい)著名なミドルウェアの調査は問題ないと思われる。 4. DevOps Agentが想定する範囲を超えたリソースの調査は、DevOps Agentに権限を与え、調査指示することで対応可能となる。 検証結果まとめ

Slide 55

Slide 55 text

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