個人で触っているAWS DevOps AgentのSkillsに新たなモード（Create skill with Chat）が生えていたので、検証を兼ねて触ってみたいと思います。
対象者
主にAWS DevOps Agentを利用している方向けに執筆しています。特に、次のような課題を持っている方に本記事をお役立てていただければ幸いです。
- AWS DevOps Agentのモードについて理解したい方
- Create skill with Chatのメリデメを知りたい方
本記事ではSkillsについてはある程度知っている前提で執筆しているため、
Skillsの詳細説明については割愛いたします。
AWS DevOps Agent Skillsについて
Skillsについては以下ドキュメントに記載されています。
Skillsを利用するメリットとしていくつかありますが、主に以下観点があると考えています。
- エージェントを専門化させる：特定の環境調査に特化させる
- 調査時間を削減させる：Skillsで調査手順を定めることで効率的な調査を行う
- 複数機能と統合できる：GitHub ActionやDnyatraceなどのサードパーティ統合を実現できる
また、AWS DevOps Agentでの調査結果を踏まえ自動的にSkillsを生成してくれます。
今までのSkills登録方法の課題
今回登場したCreate skill with Chat以外でもSkillsを登録する方法はあります。
実現したいSkillsを登録するCreate Skillsとあらかじめ作成したSKillsを登録するUpload Skillsの2つがあります。
Create Skills
読んで字のごとくSkillsをイチから登録する方法です。
AIエージェントがどのタイミングでどのような流れで調査を開始するかを具体的に記載することで、精度が高いSkillsを作成することが出来ますが、初学者にはハードルが高いです。例えば、複数サービスが動いているAWS環境でSkillsを作成しようとした場合、Skills作成前に環境調査を行い、どのような構成なのか整理する必要があります。
また、他エージェントスペースに登録されているSkillsと連携していないため、初学者が全くSkillsが登録されていないエージェントスペースへSkillsを登録するのは至難の業だと考えられます。
Upload Skills
mdファイルに記述しているSkillsを登録する方法です。
Create Skillsと比べて他環境で利用しているSkillsを登録できるというメリットはありますが、GitHubが使えない環境でSkillsを登録する場合、困難になります。
また、Skillsを作成するための環境調査の手間はかかるため、初学者が行うには難易度が高い印象があります。
今回登場したCreate skill with Chatを利用することで、Skillsに対してあまり知見が無くても実環境に適したSkillsを登録できるようになるというメリットがあると考えられます。
試してみる
Create skill with Chatの機能を試すために、新規でエージェントスペースを構築します。エージェントスペースの構築自体、2～3回マネジメントコンソールで操作するだけで完了します。作成手順については割愛します。
また、今回Skills機能を検証するためにあらかじめAWS環境にリソースを構築しておきます。リソース自体はコードで管理できるようにTerraformで執筆しております。
内容として、CloudFront／S3／EC2で構成されている簡単なWebサイトとなります。また、エラーを検知できるようにCloudWatch Logsの設定は有効化しております。なお、注入している障害は以下8つとなります。
カテゴリ1: ネットワーク・接続性の問題
| # | 障害 | 影響 | 検知手段 |
|---|---|---|---|
| 1 | ALBセキュリティグループでEC2からのヘルスチェック応答ポート（エフェメラルポート）が未許可 | ヘルスチェック失敗 → ターゲットunhealthy | ALB TargetResponseTime, UnHealthyHostCount |
| 2 | EC2セキュリティグループのアウトバウンドでHTTPS(443)のみ許可（HTTP 80未許可） | EC2からの外部API呼び出し失敗、パッケージ更新不可 | アプリケーションログのconnection timeout |
カテゴリ2: アプリケーション・サーバーの問題
| # | 障害 | 影響 | 検知手段 |
|---|---|---|---|
| 3 | EC2のディスク容量不足（/var/log が肥大化するcronジョブ） | ログ書き込み失敗 → アプリケーションクラッシュ | CloudWatch DiskSpaceUtilization, アプリログ |
| 4 | ALBヘルスチェックパスが /health だが、アプリは /api/health で応答 | 全ターゲットunhealthy → 503エラー | ALB UnHealthyHostCount, 5xxエラー率 |
カテゴリ3: CDN・静的コンテンツの問題
| # | 障害 | 影響 | 検知手段 |
|---|---|---|---|
| 5 | S3バケットポリシーでCloudFrontのOAC/OAIからのアクセスを拒否 | 静的コンテンツ403エラー | CloudFront 4xxErrorRate |
| 6 | CloudFrontのキャッシュTTLが86400秒（24時間）で、デプロイ後も古いコンテンツ配信 | デプロイ反映遅延 | ユーザー報告（メトリクスでは検知困難） |
カテゴリ4: 監視・運用の問題
| # | 障害 | 影響 | 検知手段 |
|---|---|---|---|
| 7 | CloudWatch Agentの設定ミス（ログファイルパスが間違い） | ログが収集されない → 障害調査不可 | CloudWatch Logs IncomingLogEvents = 0 |
| 8 | Auto Scaling のクールダウン期間が600秒（10分）で、スケールアウト遅延 | 負荷急増時にレスポンス劣化 | ALB TargetResponseTime, RequestCount |
ケース1：Skillsを利用しない場合
Skillsを利用しない場合、どのくらい検出するのか調べてみたいと思います。
プロンプトとして以下を利用します。
当社のWebサービス（CloudFront + S3 + ALB + EC2構成）で複数の問題が発生しているようです。CloudWatchアラームの状態、ALBターゲットのヘルス状態、CloudFrontのエラー率を確認して、現在の環境全体の健全性を評価してください。
補足：Terrafrom実行途中でAWS DevOps Agentのインシデント調査を行ったところ健全状態という結果になりました。
検出結果として以下の通りでした。
カテゴリ1: ネットワーク・接続性の問題
| # | 障害 | 影響 | 結果 |
|---|---|---|---|
| 1 | ALBセキュリティグループでEC2からのヘルスチェック応答ポート（エフェメラルポート）が未許可 | ヘルスチェック失敗 → ターゲットunhealthy | OK |
| 2 | EC2セキュリティグループのアウトバウンドでHTTPS(443)のみ許可（HTTP 80未許可） | EC2からの外部API呼び出し失敗、パッケージ更新不可 | NG |
カテゴリ2: アプリケーション・サーバーの問題
| # | 障害 | 影響 | 結果 |
|---|---|---|---|
| 3 | EC2のディスク容量不足（/var/log が肥大化するcronジョブ） | ログ書き込み失敗 → アプリケーションクラッシュ | OK |
| 4 | ALBヘルスチェックパスが /health だが、アプリは /api/health で応答 | 全ターゲットunhealthy → 503エラー | NG |
カテゴリ3: CDN・静的コンテンツの問題
| # | 障害 | 影響 | 結果 |
|---|---|---|---|
| 5 | S3バケットポリシーでCloudFrontのOAC/OAIからのアクセスを拒否 | 静的コンテンツ403エラー | NG |
| 6 | CloudFrontのキャッシュTTLが86400秒（24時間）で、デプロイ後も古いコンテンツ配信 | デプロイ反映遅延 | NG |
カテゴリ4: 監視・運用の問題
| # | 障害 | 影響 | 結果 |
|---|---|---|---|
| 7 | CloudWatch Agentの設定ミス（ログファイルパスが間違い） | ログが収集されない → 障害調査不可 | OK |
| 8 | Auto Scaling のクールダウン期間が600秒（10分）で、スケールアウト遅延 | 負荷急増時にレスポンス劣化 | NG |
CDN・静的コンテンツ関連の調査についてはあまり良い精度が出ておりませんでした。
エージェント実行時間に関しては2分58秒でした。
それでは、Skillsを作成して調査を行ってみたいと思います。
Skillsを作成してみる
Create skill with ChatボタンをクリックするとSkills生成が自動的に実行されます。
Skills作成時にもエージェントが実行していると推察されますが、課金は同じなのか気になりますね。（私が見た限り公式ドキュメントに記載がなかったので）
5分～10分ほどでSkillsが生成されます。
生成されたSkillsの中身は以下の通りでした。
ダウンロードもできるため、他エージェントスペースへの同期も可能です。
なお、Skillsの中身を修正したい場合はregenerateボタンをクリックすることで再生成されます。
先ほどと同じプロンプトで障害調査してみたいと思います。
プロンプトの中身は変えていないですが、作成したSkillsをチェックしていることがログから判断できました。
カテゴリ1: ネットワーク・接続性の問題
| # | 障害 | 影響 | 結果 |
|---|---|---|---|
| 1 | ALBセキュリティグループでEC2からのヘルスチェック応答ポート（エフェメラルポート）が未許可 | ヘルスチェック失敗 → ターゲットunhealthy | OK |
| 2 | EC2セキュリティグループのアウトバウンドでHTTPS(443)のみ許可（HTTP 80未許可） | EC2からの外部API呼び出し失敗、パッケージ更新不可 | OK |
カテゴリ2: アプリケーション・サーバーの問題
| # | 障害 | 影響 | 結果 |
|---|---|---|---|
| 3 | EC2のディスク容量不足（/var/log が肥大化するcronジョブ） | ログ書き込み失敗 → アプリケーションクラッシュ | OK |
| 4 | ALBヘルスチェックパスが /health だが、アプリは /api/health で応答 | 全ターゲットunhealthy → 503エラー | OK |
カテゴリ3: CDN・静的コンテンツの問題
| # | 障害 | 影響 | 結果 |
|---|---|---|---|
| 5 | S3バケットポリシーでCloudFrontのOAC/OAIからのアクセスを拒否 | 静的コンテンツ403エラー | OK |
| 6 | CloudFrontのキャッシュTTLが86400秒（24時間）で、デプロイ後も古いコンテンツ配信 | デプロイ反映遅延 | OK |
カテゴリ4: 監視・運用の問題
| # | 障害 | 影響 | 結果 |
|---|---|---|---|
| 7 | CloudWatch Agentの設定ミス（ログファイルパスが間違い） | ログが収集されない → 障害調査不可 | NG |
| 8 | Auto Scaling のクールダウン期間が600秒（10分）で、スケールアウト遅延 | 負荷急増時にレスポンス劣化 | NG |
先ほどと比較して不具合検知率は約75％と高まっていますが、監視運用に関する問題は特定できていませんでした。ただし、復旧策の提案まで進んでいるため、Skillsがない場合よりより深掘りして調査できているように見受けられます。
まとめ
今回登場したCreate skill with ChatによってSkills管理がより容易になった印象を受けています。そのうえで、Skills作成までの時間が少々長い（今回シンプルな構成だが、5分ほどかかっているため）印象を受けました。
AWS DevOps Agent自体新機能が常に問う乗じている印象を受けているため、引き続き検証を行っていきたいと思います。
