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
ソフトウェア開発を再定義する３つの 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
ご清聴ありがとうございました。