トップ > AWS re:Invent 2025 > 【AWS re:Invent 2025】AWS DevOps Agent (プレビュー) を試してみた - 3人目

【AWS re:Invent 2025】AWS DevOps Agent (プレビュー) を試してみた - 3人目

AWS re:Invent 2025 DevOps
記事タイトルとURLをコピーする

AWS re:Invent 2025 で AWS DevOps Agent のパブリックプレビューが発表されました。
現地でハンズオンのセッションが開催されましたので、本稿ではその参加の紹介になります。

re:Invent はどれだけ睡眠時間を確保できるかが肝要です。キツかったら寝よう。
内村でございます。

アプリケーションのダウンタイムは、売上やお客様の信頼に直結する大きな問題です。
本セッションでは、re:Invent で発表された新サービス「AWS DevOps Agent」を使って、インシデント対応をどこまで自動化できるのかをハンズオン形式で体験してきました。 
その参加レポートを共有致します。

とはいってもすでに当社から2つも記事を書いていただいています。
よければそちらもご参照ください。

blog.serverworks.co.jp

blog.serverworks.co.jp

内容についての諸注意

当記事は 2025年12月時点で調査した製品、サービス内容を記載しています。 最新の情報に関しては各種公式サイト、マニュアル等をご確認下さい。
当記事作成の際には十分注意しておりますが、内容に公式と相違がある場合は公式を優先とさせていただきます。
当記事内の試算およびそれに準ずる内容は、本資料の説明のために用いるものであり、不利益が生じた場合、一切の責任は負いかねますので予めご了承ください。

セッション概要

  • タイトル： 『[NEW LAUNCH] Resolve and prevent future operational issues with AWS DevOps Agent [REPEAT]（DVT337-R1）』
  • 日時： 12月3日水曜 15:30–17:30（PST）
  • 会場： Mandalay Bay | Level 2 South | Mandalay Bay Ballroom K
  • 種別： Workshop（Level 300 – Advanced）
  • 主なトピック
    • Artificial Intelligence（人工知能）
    • Developer Tools（開発者ツール）
  • Area of Interest（関心分野）
    • Generative AI（生成AI）
    • Agentic AI（エージェント型 AI）
  • 想定ロール： Developer / Engineer、IT Professional / Technical Manager
  • 登壇者
    • Yasemin Avcular さん （Principal Software Engineer, AWS）
    • Carl Caum さん （Senior Product Manager, AWS）
    • （以下敬称略）

インシデントライフサイクルのつらみ

セッション冒頭では、登壇者の Carl から、典型的なインシデントライフサイクルのおさらいがありました。

  • 夜中の 2 時にアラームが鳴る
  • ベッドから飛び起きて、PC の前に座る
  • どのサービスが怪しいのかをログ・メトリクス・ダッシュボードを渡り歩きながら調査
  • 必要であれば他チームのメンバーを起こすかどうか判断
  • 原因がわかったら、
    • 『強行リリース（break glass）』で手早く修正するのか
    • きちんと CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインを通すのか
  • その後、暫定対応で発生したコンフィグの『ドリフト（設定ずれ）』をどう正すのか
  • 最後に、再発防止のためにテスト・アーキテクチャ・観測性（Observability）を見直す

こうして並べてみると、普段何気なくやっていることがいかに人力と「属人知」に頼っているか、改めて突きつけられます。
ここで登場するのが今回の主役「AWS DevOps Agent」です。

AWS DevOps Agent とは？

AWS DevOps Agent は、生成 AI とエージェント技術を活用して、インシデントの検知から調査・復旧・再発防止までを支援する「運用専任エージェント」です。
登壇の説明をまとめると、主な特徴を後項にまとめました。

「常時オン」のインシデントレスポンダー

  • モニタリングツールからアラームやイベントが発生すると、自動的に AWS DevOps Agent が起動。
  • アプリケーションのトポロジー情報や、各種ログ・メトリクス・トレースなどを使って、
    • 初動調査
    • 仮説立案
    • 追加調査
      を自律的に実行します。
  • エンジニアが PC を開いた時点で、すでに『一次診断レポート』がチケットに書き込まれている──そんな体験を目指しています。

復旧に向けた『ミティゲーションプラン』の提示

  • 単に「原因はこれです」で終わらず、
    『どのように復旧すべきか』をステップ付きのプランとして提示します。
  • 例えば、
    • 設定のロールバック
    • 影響範囲を限定するための一時的なスロットリング
    • 再デプロイの実施 など、実際のオペレーションに落とし込めるレベルまで噛み砕いてくれます。

週次の『再発防止サジェスト』

  • 一度インシデントが収束した後も、週に一度、最近のインシデントを横断的に分析。

テストやアーキテクチャ、観測性の改善案などを洗い出し、優先度付きで提案します。
登壇者の表現を借りると、 『100 個の小さな提案を出すツールではなく、本当に効く 4 つを出すツール』を目指しているとのことでした。

既存ツールとの連携を前提とした『チームプレイヤー』

AWS DevOps Agent 単体で完結するのではなく、既存の運用ツールと連携して動作することが前提になっています。

  • インシデント管理ツール（チケットシステム）と連携
    • チケットの作成
    • 調査メモや仮説の追記
    • ミティゲーションプランの共有

これらを自動化してさらに、以下へ投稿することで、関係者がリアルタイムに追えるようにします。

  • チャットツールのチャンネル
    • 調査の進捗
    • 重要な観測結果

そして既存のダッシュボードやメトリクスを活かしつつ、その上にエージェントを載せる形で、

  • 観測基盤（APM やメトリクス基盤）をプラグインの形で連携

（会場のハンズオンでは、Dynatrace を利用しました）

ハンズオンで体験したこと

ワークショップでは、あらかじめ用意されたサンプルアプリケーションとインシデントシナリオを題材に、AWS DevOps Agent の振る舞いを実際に確認しました。
大まかな流れは次のようなものです。

  1. サンプル環境とツール連携の確認
    • 事前に用意された observability（監視・可観測性）ツール、ソースコードリポジトリ、CI/CD パイプラインと AWS DevOps Agent が連携していることを確認
  2. インシデントの発生と検知
    • 負荷テストや設定変更などで障害を発生させ、アラーム → チケット作成 → AWS DevOps Agent 起動までの流れを実際にたどる
  3. AWS DevOps Agent による調査ログの確認
    • チケットやチャットに以下が順番に記録されていく様子を確認
      • 調査のステップ
      • 仮説（Hypothesis）
      • 収集したログの要約
  4. ミティゲーションプランと再発防止案のレビュー
    • 提示された復旧手順を基に環境を正常化
    • さらに「どんな恒久対策を入れるべきか」の提案を読み解き

個人的には、エージェントが自分の代わりに手を動かしてくれていて、ログを読みに行く頃にはだいたいの状況が整理されている感覚がかなり新鮮でした。

どんなチームにフィットしそう？

セッションを通して感じた、AWS DevOps Agent が特にフィットしそうなユースケースを挙げてみます。
ただし個人的に今の感覚値であることをご容赦ください。

  • 24/7 監視が必要、しかし当番の負担を少しでも減らしたい
  • マイクロサービス化が進み、「どこから調べればよいか」が毎回議論になる
  • インシデント後のふりかえり（i.e. ポストモーテム）で、毎回以下の時間がかかっている
    • ログの抜き出し
    • タイムライン作り
  • 再発防止策のアイデアは出るものの、優先順位付けや具体化に悩んでいる

もちろん、万能薬・銀の弾丸ではありません。
『インシデント対応の標準プロセス』と『観測性のベース』さえ整っていれば、その上に AWS DevOps Agent を載せることで、運用チームの生産性を一段階引き上げられそうだと感じました。

参加してみての所感

最後に、個人的な学びを3点ほど。

  1. エージェントは「チャットボット」ではなく「運用メンバー」である
  2. 単に質問に答えるのではなく、自らアクションを起こし、仮説検証を繰り返す存在としてデザインされている
  3. 既存ツールの『上に載せる』設計が現実的
  4. チケット・チャット・監視など、既に多くのツールが動いている現場に対して、以下のアプローチなのが新しかった
    • 『全部 AWS DevOps Agent に置き換えてください』ではない
    • 『今ある仕組みを活かしたまま、自動化レイヤーを追加する』
  5. インシデントの『予防』に本気で踏み込んでいる
  6. 週次の分析で、横断的にパターンを見てくれるのは、人手だけではなかなか難しい領域
  7. 現実的に効く対策を出すという考え方は、現実的で良いなと

まとめ

AWS DevOps Agent は、 インシデントレスポンスの現場に生成 AI とエージェント技術を持ち込むという、かなりチャレンジングなサービスだと感じました。

  • インシデント対応の初動を自動化
  • 復旧プランを提示
  • さらに週次で再発防止策を提案する

この一連の流れは、オンコール担当者の心理的負担をかなり軽減してくれると思われます。
「夜中 2 時のアラームが、ほんの少しだけ怖くなくなる世界」に近づく一歩、と言っても良いかもしれません。

本記事が、AWS DevOps Agent に興味持たれた方の参考になればうれしいです。
現在はパブリックプレビューのため、us-east-1 のみで検証が可能です。
日本で使えるようになった暁には、実案件での検証レポートもお届けできればと思います。

現場からは以上です。