先日、AWSサミットに参加してきました。特に感じたのは、AWS DevOps Agent の存在感の大きさです。基調講演でも触れられていましたし、僕自身も気になっており自身で調べたりもしていたのもありセッションで講演を拝聴しました。
自律的にインシデントに対応するエージェント、というテーマ自体は前から知ってはいたのですが、あらためてこれだけプッシュされているのを目の当たりにして、「これはうちの受託の運用保守にそのまま効く話では」と思い始めました。そこから会場で拾った断片を、あとで公式ドキュメントやAWSのブログできちんと裏取りして整理した、というのがこの記事です。
というわけで、DevOps Agentがどういうものかを押さえつつ、ネクストの受託業務でどう使えそうかを考えてみます。まだ自分で触ってはいないので、あくまで机上の考察です。
AWS DevOps Agentとは
ざっくり言うと、自律的に動くSRE / 運用担当のエージェントです。2025年12月にプレビューが公開され、その後GAになりました。サミットで扱われていたのも、ちょうどGA前後のタイミングで注目が集まっていたからだと思います。
一番の売りが自律的インシデント対応で、アラートが上がると人間が動く前にエージェントが調査を始めます。CloudWatchはもちろん、Datadog、Dynatrace、New Relic、Splunk、Grafanaといったオブザーバビリティツールと連携し、テレメトリとコードとデプロイ履歴を突き合わせて原因を探る、という流れになっています。検知から調査、復旧、予防まで、インシデント対応のライフサイクル全体に絡んでくる位置づけでした。
内部はマルチエージェント構成になっている
調べていて「なるほど」と思ったのが、内部の作りです。DevOps Agentは単一のAIが全部やっているわけではなく、役割ごとに専門化された複数のエージェントが協調する構成になっていました。
- Triage（トリアージ）: 届いたシグナルを既存の調査と相関させる。速度重視のフェーズ
- Investigation（調査）: 複数の仮説を並行生成して根本原因を突き止める、中核の推論エンジン
- Mitigation（緩和）: 特定された原因をもとに対応アクションを生成する
- Prevention（予防）: 過去のインシデントのパターンを分析して再発を防ぐ
そして、これら全部の土台になっているのが Topology Graph（トポロジーグラフ）と呼ばれる、アプリの構成マップです。CloudFormation / CDKの構成、Resource Explorer、CloudWatch Application Signalsの通信パターン、CI/CDパイプラインの4つから構築されるらしく、これによってエージェントは「やみくもにログを検索する」のではなく「アーキテクチャの文脈を踏まえて推論する」ことができる、という説明でした。ここは地味ですが、けっこう効いてくる部分だと思います。
トリアージの相関判定が実務的
もうひとつ注目したいと感じたのはトリアージです。アラートが上がったとき、いきなり全部を個別に調査するのではなく、直近20分ほどの調査中の案件と突き合わせて相関を取ります。そのうえで、既存調査に紐付ける（Linked）、無視する（Skipped）、新規で調べる（Proceed）のいずれかを判断する仕組みです。
アラートストームで同じ原因の通知が大量に飛んできて、全部個別に対応しようとして消耗する、というのは運用をやっていると誰しも経験があると思います。そこを最初に潰しにいく設計になっているのは、実務をわかっている作りだなと感じました。
実際の調査の流れ
AWSのブログに、実際の調査フローの例が載っていました。ざっくりこんな流れです。
- CloudWatchアラームが5xxエラーの増加を検知して発火する
- エージェントが自動で調査を開始し、DynamoDBのスロットリング、Lambdaのコールドスタート、APIゲートウェイの設定変更……といった複数の仮説を並行で検証する
- メトリクスの異常時刻と直近のデプロイを相関させ、少し前にデプロイされたコード変更が原因だと突き止める
- 根本原因の分析結果と、具体的な対応案（オンデマンド容量への切り替え、あるいはロールバック）をSlackに投稿する
これを最初のアラートから4〜5分で完結させていました。人間が叩き起こされてから同じことをやると、当たりをつけるだけで軽く30分は溶けるので、この速さは素直にすごいなと。
なぜ受託の話につながったのか
ネクストは受託開発をやっていて、作って納品して終わりではなく、運用保守までセットで請けるケースが多いです。この運用保守フェーズには、正直しんどいポイントがいくつかあります。
- 夜間・休日のアラート対応。誰かがオンコールで待機している
- 障害対応が属人化しがちで、「あの人しかわからない」システムが必ず生まれる
- 複数の顧客のシステムを並行で見ているので、コンテキストスイッチの負担が大きい
- 一次調査に時間を取られて、本来やりたい改善提案まで手が回らない
このあたりに、先ほどの「アラート即調査」「相関でノイズを潰す」あたりがハマりそうだと感じたわけです。特に夜間対応ですね。「午前2時だろうがピーク時だろうが、アラートが来た瞬間に調査を始める」という点は、人間より確実に速い。オンコールで起こされた直後の、頭が回っていない状態でゼロから調べるのは本当につらいので、そこが埋まるのは大きいと思います。
効きそうだと感じたところ
一次調査の肩代わり
受託の運用保守で一番時間を食うのは、実は復旧作業そのものよりも「何が起きているのかを把握する」フェーズだったりします。ログを漁って、メトリクスを見て、直近のデプロイを確認して、という一次調査です。
ここをエージェントが先回りしてやってくれて、人間はその調査結果から入れるなら、単純に立ち上がりが速くなります。DevOps Agentは Investigation Journal（調査ジャーナル）という形で、どういう推論をして、どのデータを参照して、その結論に至ったのかを不変の監査証跡として残すようになっています。人間はそのジャーナルを追うところから始められるわけで、これは受託の引き継ぎや報告の観点でも相性が良さそうだと思いました。
属人化の緩和
エージェントがトポロジーグラフでアプリの構成やサービス間の依存関係を把握したうえで動く、という点もポイントです。「このシステムはあの人しかわからない」という問題に対して、少なくとも依存関係の理解を人からエージェント側に一部移せる可能性があります。
受託だと、担当者の異動や退職で運用ノウハウが飛んでしまうのが地味に怖いリスクなので、ここは魅力的に見えました。ただ、後述するとおり、ここは楽観できない部分でもあります。
予防のレコメンド
これは即効性というより中長期の話ですが、Preventionのエージェントが過去のインシデントのパターンを分析して、観測性・インフラ最適化・デプロイパイプライン・アプリの回復性という4つの領域で改善提案を出してくれます。
受託はどうしても「言われたことをやる」に寄りがちで、こちらから改善提案を出す余力をなかなか作れません。その提案のネタ出しをエージェントに手伝ってもらえるなら、保守契約の中で「こういう改善はいかがですか」と一歩踏み込んだ提案がしやすくなるかもしれません。ここは営業的にもプラスになりそうだと感じました。
そのまま使えるわけではない、という話
ここまで前のめりに書いておいてなんですが、受託特有の事情で「そう簡単ではないな」と引っかかった点もいくつかあります。
顧客のAWSアカウントに入れられるか問題
受託の運用保守では、顧客のAWSアカウントを預かって運用するパターンが多いです。そこに自律的に動くエージェントを入れて自動で調査させるとなると、顧客のセキュリティポリシーやガバナンスの承認が要ります。「AIが勝手にうちの本番環境を見るのか」という反応は普通に想定されますし、この合意形成は技術というより社内政治の話で、おそらく一番時間がかかるところです。
マルチクラウド / オンプレ混在
DevOps Agentはマルチクラウドやハイブリッドにも対応をうたっていますが、受託案件だとAWSだけで完結していないシステムも多いです。オンプレの資産や、別ベンダーが握っている部分があると、エージェントが見える範囲に穴ができて、根本原因までたどり着けないケースが出てきそうです。
「実行はしない」を正しく理解しておく
これは調べていて認識を改めた点なのですが、DevOps Agentは緩和計画を生成はするものの、実行はしない設計になっていました。エージェントの書き込み権限は、チケットやサポートケースの作成に限定されていて、実際にリソースをいじる判断と操作は人間に委ねられています。
正直、最初は「AIが勝手に本番を触って裏目に出たら怖い」と思っていたのですが、そこはそもそも設計で線が引かれていたわけです。安心した一方で、受託の観点だと別の論点が残ります。エージェントが出した対応案どおりに人間が実行して、それが裏目に出た場合、責任は誰が取るのか。提案の主体がAIでも、実行と結果責任は運用者側に残るので、「エージェントがそう言ったから」で押し切れる話ではありません。当面は「調査と対応案の提示まではエージェント、実行の判断とトリガーは人間」という座組みを、契約上もはっきりさせておくのが現実的だと思います。
このあたりは以前書いた「生成AIが本番に乗らない理由」の記事とも通じる話で、結局は自律性をどこまで許すかの設計の問題です。全部を任せるより、決定的なワークフローの中に部品として組み込むほうが、今のところ事故りにくい。DevOps Agentが実行部分を人間に残しているのは、まさにその思想に沿った設計なのだろうと感じました。
リージョンとコスト
GAになったとはいえ、使えるリージョンや料金体系は要確認です。プレビュー時点ではバージニア北部（us-east-1）のみだったので、東京リージョン前提の顧客システムでどう扱うかは、きちんと調べる必要があります。ここはまだ自分でも把握しきれていません。
受託でどう入れるか、の当たり
現時点での自分の仮説はこんな感じです。
まず、自社で運用している案件で先に試す
いきなり顧客環境ではなく、社内システムか、比較的リスクの低い自社運用の案件で挙動を見る。エージェントの調査精度と、誤検知の頻度を体感してからでないと、顧客には勧められません。
次に、「一次調査エージェント」として提案する
「AIが全部やります」ではなく、「一次調査を高速化してMTTR（平均復旧時間）を縮めます、最終判断は人間が行います」という座組みにする。このほうが顧客も受け入れやすいですし、実態にも合っています。
保守契約の付加価値として予防レコメンドを組み込む
定例報告の際に「エージェントがこういう改善点を挙げています」を添えられると、単なる障害対応要員から一歩抜け出せます。
所感
サミットで扱われていたのを見た直後は、「これでオンコールの当番から解放されるのでは？」くらいのテンションだったのですが、受託の文脈に落とし込んで考えてみると、技術的な話よりも契約・責任・顧客合意のほうが壁として大きいな、というのが正直なところです。
とはいえ、一次調査の肩代わりと属人化の緩和は、受託の運用保守が長年抱えてきた痛みにちゃんと刺さっている気がしています。ツールとして完璧に使いこなせるかは別として、「運用保守の一次対応をAIに寄せていく」という方向性自体は、遅かれ早かれ来ると思っています。AWSがサミットであれだけ前面に出してきたということは、そういう未来に本気で張っているということでもある。むしろ、ここに早めに慣れておかないと、運用保守で価値を出せなくなる側に回ってしまいかねません。
次は実際に自社の低リスクな案件で触ってみて、誤検知の頻度や、調査ジャーナルの実用性あたりを具体的にレビューしたいですね。触ってみないとわからないことだらけなので。。。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
