はじめに

皆さま、お久しぶりです。入社5年目の堀内です。普段はJavaやPHPで開発・運用保守を担当しています。
2025年12月、AWS re:Invent 2025に参加してきました。本イベントは、“Frontier Agents” (常時稼働の自律型 AI エージェント)と呼ばれる新しいエージェント群の発表により大きく盛り上がりました。
その中でも、開発・運用領域を支える新サービス AWS DevOps Agent(以下、DevOps Agent)が特に注目を集めていました。普段から運用でインシデント対応に関わる身として、実際に現地ラスベガスでKeynoteを聴講し、その後のセッションやハンズオンに参加した内容を二部構成で記していこうと思います。本記事は2部目です。1部目はこちら↓↓。

tech.nri-net.com
監視 → 検知 → 根本原因分析 → 緩和策生成 → 再発防止提案という一連のサイクルを、DevOps Agentがどの程度自動化できるのかを実際のハンズオンを通して確認しました。

触ってみた

Step 1:Agent Space の作成

まずはDevOps Agentが利用する「Agent Space」を作成します。まずAWSコンソールから、リージョンを us-east-1 に変更します。※DevOps Agentは現在プレビュー版としてバージニア北部（us-east-1）にて利用可能となっています。 DevOps Agentを開き、右側の「Begin Setup」をクリックします。

「Auto-create a new DevOps Operator role」を選択し、Createでエージェントを作成します。

Agent Space が作成されると、DevOps Agentがこのスペース内でメトリクス・ログ・トレースデータを収集し、インシデント分析を行います。

Step 2: DevOps Centerでアプリ全体を把握

Agent Space の設定後、DevOps Centerを使うことでアプリケーションの依存関係がグラフ構造で可視化できます。

アプリ全体の関連を把握しやすく、インシデント調査に非常に役立つと感じました。

Step 3: Amazon CloudWatch Alarmの調査

わざと設定を変更しアラームを発生させます。
今回のハンズオンではAmazon DynamoDBの書き込みキャパシティのプロビジョンドキャパシティユニットを250→2に変更します。
書き込みスループット不足を引き起こします。

設定変更後しばらくすると、CloudWatchで「DynamoDBWriteThrottleAlarm」というアラームが発生します。

CloudWatchだけでは原因は特定できないため、DevOps Agentの調査機能（Investigation）に進みます。

Step 4: Investigation（原因調査）

「Start Investigation」から調査を開始すると、DevOps Agentは自動収集を開始します。ここからが DevOps Agentの本領発揮です。

Investigation画面では、

異常発生の兆候
メトリクス相関分析
依存関係の影響分析
ログのサマリ
根本原因の仮説

等が表示されます。特に衝撃を受けたのは、根本原因の仮説生成です。
今回生成された仮説として、「Manual DynamoDB capacity reduction from 250 WCU to 2 WCU」と「DynamoDB write throttling due to insufficient provisioned capacity」が打ち立てられていました。

詳細には、12/04/11:02に AWS コンソールから、キャパシティを99.2％削減したため、ワークロードが処理できなくなった旨が記載されていました。意図的に設定を変更したことが完全にバレていました。恐るべし、DevOps Agent。

Step 5: Mitigation Plan（緩和策の生成）

その後、表示される「Generating mitigation plan」をクリックすると、問題解決の方法（Mitigation plan）が提示されます。

エラー発生から、緩和策の生成までは、約10分ほどかかりました。
※ワークショップ中、私は周りの受講者と談笑して待機していましたので、あっという間でした。提示されたMitigation planをCloudShell上で実行していくと、修正が完了し、エラーが解消しました。

Step 6: Prevention（再発防止策）

Preventionタブに移動すると、再発防止のための推奨点が提示されました。

提案された策としては「破壊性の高いDynamoDB キャパシティ削減を検出し自動で元に戻すための EventBridge ルールを実装する」というものでした。今回は、わざと DynamoDB のキャパシティを削減したことがエラーの原因になっているので、対策は的を射ているなと思いました。

ワークショップを通じて

今回のワークショップを通じて感じたのは、DevOps Agentは圧倒的なスピードと精度で、インシデント対応を支援してくれる強力な存在だということです。CloudWatchだけでは追い切れない因果関係の可視化、依存リソースの影響把握、さらには根本原因の仮説提示まで、自動でここまでやってくれるのかと驚かされました。
また、Mitigation（緩和策）や Prevention（予防策）まで一気通貫で提示してくれることで、インシデント対応の一連の流れが非常にスムーズに進む点も好印象でした。現場の負担を減らすだけでなく、運用全体の質を引き上げるポテンシャルを強く感じました。

今後の展望

テスト工程への参加

DevOps Agentを連結テストに組み込むことで、テストの実施速度と品質の向上が見込めます。具体的なメリットとしては下記です。

ログやメトリクスをリアルタイム解析し、テスト環境の状態変化を常時可視化できる。
問題の兆候を即座に捉えられるため、調査の手戻りが減り、品質が向上する。
分析や判断が標準化され、テスト工程で一定の品質を確保できる。

上記はメリットの一部ですが、属人化が解消されることで、誰がテストを担当しても一定の品質を保てるのは大きなメリットになると思います。

学びの機会が減る!?

DevOps Agentを導入すると、エラー原因の特定やログ分析が自動化され、作業効率の大きな向上が見込めます。その一方で、エラーに自ら向き合う経験が減ることで本来得られる“学びの機会”が損なわれる可能性があります。
エラー原因の深掘りはシステム構造や依存関係を理解する貴重なプロセスです。Agent が瞬時に答えを提示してしまうと、問題を自力で調査するプロセスを経ずに解決してしまい、「なぜそうなるのか？」という思考が育ちにくくなる恐れがあります。また、Agent が使えない場面では対応ができないなんてことも考えられます。

まとめ

今回のワークショップでは、DevOps Agentを交えてエラー発生から、解決までの流れを体験しました。関連リソースを横断的に分析し、次のアクションまで提示してくれるため、インシデント対応のスピードが向上し運用品質を底上げできることを実感しました。
一方で、AI に過度に依存すると、人間が本来得られる学習機会が減るという懸念もあります。提示された分析やプランをきちんと分析し、チームの知見として言語化・標準化して蓄積していくことが重要になると思います。
効率化と学びの両方を適切にバランスさせることで、DevOps Agentを最大限活かしつつ、より強い運用体制を築いていけると感じました。
インシデントに強いチームをAWS DevOps Agentと一緒に作っていきましょう。