これまで、インフラ運用やインシデント対応はエンジニアの「経験」と「勘」が支える領域でしたが、ここでもAIの活用が期待されています。

AWS re:Invent 2025では「Frontier Agents（フロンティアエージェント）」というソフトウェアの構築、セキュリティ保護、運用方法を変革する自律型AI群が発表されました。その一つである「AWS DevOps Agent」は、まさにこのエンジニアの「経験」と「勘」が支えてきた領域を担うAIです。

AWS DevOps Agent はテクノロジースタック全体を自律的に調査して根本原因を特定します。（参考：AWS Frontier Agents 公式サイト）

このAWS DevOps Agentがどこまで実務に耐えうるのか、あるいは人間のエンジニアを置き換える存在になり得るのか。その真価を確かめるために、NCDCでは「AI vs 人間」の実戦形式の検証イベントを実施しました。

本記事では、ベテランエンジニアと最新のAIエージェントが実際に発生しうる障害に対してどのように原因特定に挑んだのか、対戦結果と、そのプロセスからわかった「人とAIの棲み分け」や「AIを活用するために気をつけるポイント」をご紹介します。

AWS DevOps Agentとは？新しい運用のかたちを示す自律型AI

対決の内容に触れる前に、今回検証したAWSのサービスについて整理しておきます。AWS DevOps Agentは単なる人を補佐する AIチャットボットではありません。あらかじめ定義された権限の範囲内で、Amazon CloudWatchのメトリクス（システムのパフォーマンスに関するデータ）やAWS CloudTrailのログ（誰が、いつ、どんな操作を行ったかの記録）、さらにはアプリケーションのコードまでを自律的に探索し、障害の根本原因を特定して、修正案や予防策を提示するツールです。

特徴的なのは、その動作が能動的である点です。アラートが発生した際、エンジニアが指示を出すだけでなく、外部のシステム監視ツール（Dynatrace、DataDog、New Relic、Splunk 等）と連携することによってAWS DevOps Agentが自動的に一次調査を開始することも可能です。

実際のシステム運用においては、アラート発生時に人が調査を開始するまでにどうしても多少の時間を要しますが、AIであれば24時間 × 365 日いつでも即座に、 自動的に調査を開始できます。これは大きな価値を持ちます。

AWS DevOps Agent vs 人間

上記の通り、人とAIではアラートへの対応開始の速度に違いがあるのですが、今回の検証では、AWS DevOps Agentが、障害の原因特定作業において人間のエンジニアを置き換える存在になり得るのか？を測るために、あえて「よーいドン！」で開始して解決までの時間を競うこととしました。

対決には「サーバーレスアプリのタイムアウト」と「EC2のディスクフル」という、二つの対照的な障害シナリオを用意して、「45分という制限時間内でどちらが先に原因を特定できるか」というルールで勝負します。

ケース1：膨大な仕様の知識量と検索性が勝負を分けた

最初のシナリオは、フロントエンドにReact、バックエンドにAWS AppSync（GraphQL）とAWS Lambdaを使用したAIチャットアプリで発生した「時々応答がなくなる」というインシデントです。

人間サイドとして挑んだのはエンジニア歴20年以上のベテラン。対するAIサイドは、エンジニア2年目の若手がAWS DevOps Agentを相棒にして調査にあたりました。

開始直後、人間サイドは開発者ツールを開いて挙動を確認し、再現条件を探ります。しかし、この問題には「特定の条件下（複雑な質問をした場合）でなければ再現しない」という意図的な罠が仕掛けられていました。

トラブルの再現に7分を要した人間サイドは、その後Lambdaのログを確認し、コード内に仕込まれたスリープ処理を発見。さらにAppSyncのログから「GraphqlRuntimeError」が発生していることも突き止め原因特定に近づいていきます。しかし、この先で苦労します。

Lambdaのタイムアウト設定は5分に設定されており、ログ上も正常に終了している。しかし、開発者ツールのNetworkタブを見ると、リクエストはきっちり30秒で切れている。どこかにあるはずの「30秒のタイムアウトをかけている箇所」が原因と考え、それを特定しようと試みますが、決定打は見つかりません。結局「30秒のタイムアウト」の根本原因に辿り着くことができず、45分の制限時間切れとなりました。

一方で、AIサイドの若手は早い段階でエージェントに調査を指示。AWS DevOps Agentは自律的にメトリクスやログをスキャンし、すぐにある矛盾を指摘します。「Lambdaの実行時間は21秒から37秒の範囲にあるが、設定上のタイムアウト（300秒）には達していない。しかしAppSyncはタイムアウト例外を報告している」。

この矛盾から、AWS DevOps Agentは即座にひとつの仕様に辿り着きました。「AWS AppSyncにはLambdaデータソース呼び出しに対して、デフォルトで30秒の固定タイムアウト制限がある」。（参考：AWS公式ドキュメント）

ベテランエンジニアが「どこかに30秒のタイムアウトをかけている箇所があるはずだ」と原因を探している間に、AIは膨大な知識ベースから仕様との整合性を瞬時に突き止めたのです。

このケースでは、膨大な仕様の記憶量と検索性においてAIが人間を上回ったといえます。

ケース2：ログだけではわからない原因。AIは仮説に拘り迷走

続いてのシナリオは、Application Load Balancer（ALB）、Amazon EC2、Amazon RDSという、より一般的な構成のWebアプリで発生したヘルスチェックエラーです。ここでは「ファイルディスクリプタリーク」という、OSに関わる障害（プログラムが適切に閉じないことでシステムのリソースを消費し続けてしまう現象 ） を再現しました。

人間サイドは、CloudWatchアラートから異常を検知し、RDSに異常がないことを確認。その後、ヘルスチェックURLへの直接アクセスから「ストレージ不足」の可能性を察知します。そこで、EC2にログインしてディスクが100%埋まっていることを突き止めました。

しかし、なぜディスクが埋まったのか、その真の原因（削除済みファイルがプロセスに保持され続けている現象）を特定するまでにはあと一歩至らず、惜しくもタイムアップとなりました。

一方のAWS DevOps Agentは、人間とは全く異なる動きを見せます。構成要素を自動特定し、ログからエラーを発見するところまではスムーズでしたが、そこから「RDSの作成完了直後にEC2が接続を試みて失敗している」という「競合状態（Race Condition）」の仮説を立ててしまったのです。

一度この仮説を立てると、AWS DevOps Agentはその仮説を証明するために起動タイミングの相関関係などを延々と調査し続けてしまいました。真の原因であるディスク容量不足の可能性には辿り着かず、迷走してしまったのです。

十分な情報（明確に原因につながるログ）を得られないトラブルシューティングにおいて、AIは一度立てた仮説に固執し、時間を浪費する傾向があります。これは「ログの相関関係」を徹底的に追う力はあっても、ログから離れて思考を巡らす力をAIが持っていないことを象徴しています。

最終的に、この問題は人間もAIも正解に辿り着くことができませんでしたが、人間サイドは原因特定にあと一歩まで迫りました。誤った仮説から離れられなかったAIと比較すると、経験と勘の面で人間が上回ったといえます。

障害調査においてAIが輝く場所、人間が必要な場所

二つの検証から見えてきたのは、AIと人間の明確な「得意不得意」の差です。

ケース1で紹介したAppSyncの仕様制限のように、ドキュメント化されている膨大な知識の中から最適解を探し出す力は、AIが圧倒的に優れています。エンジニアが「30秒のタイムアウト」という事象に気づいた後、それがプラットフォームの制限なのか、コードの不備なのか、あるいはライブラリの仕様なのかを切り分ける際、記憶量と検索性に優るAIは強力な壁打ち相手となります。

しかし、EC2内部で起きているような複雑なOSレイヤーの障害や、複数の要因が絡み合う非定型なトラブルに対しては、まだAIの推論能力には限界があります。特にケース2で紹介した「ファイルディスクリプタリーク」のような、OSコマンドを組み合わせて状態を多角的に把握する必要があるケースでは、現時点では人間のエンジニアが「何かがおかしい」と五感を働かせてコマンドを叩く方が、解決への距離は近いと言えるでしょう。

AIによる根本的原因の調査は非常に強力ですが、それが間違った方向に進んでいないかを見極める「目利き」の存在は、これからも不可欠です。

AWS DevOps Agentを活用するための「オブザーバビリティ設計」

AWS DevOps Agentを導入すれば、明日から運用が自動化されるわけではありません。今回の検証で、エージェントがスムーズに動いた場面には共通点がありました。それは「AIが判断するための材料（ログやメトリクス）が揃っていたこと」です。

AWS DevOps Agentは魔法を使っているわけではなく、提供されたデータを高速に処理しているに過ぎません。逆に言えば、適切なログが出力されていなかったり、コンテキストが不足していたりすれば、AIは簡単に誤った仮説に飛びついてしまいます。

これからのエンジニアに求められるのは、障害が起きたときに自ら調査する力だけでなく、AIが正しく調査できるようにシステムを設計する力、つまり「AIフレンドリーなオブザーバビリティ（可観測性）の設計」です。どのようなログを出し、どのリソースにタグを付け、どのような権限をエージェントに与えるのか。この準備の良し悪しが、運用自動化の精度に直結することになります。

最新技術を「実務の武器」に変えるために

このイベントを実施した2026年2月時点では、AWS DevOps Agentはパブリックプレビュー段階にあります。提供リージョンも限定されており、実際のプロダクション環境にそのまま適用するには、まだいくつかのハードルがあります。

しかし、今回の検証で示した通り、その潜在能力は極めて高いものです。特にAppSyncの制約を見抜いたようなケースは、トラブルシューティングの時間を劇的に短縮する可能性を秘めています。

NCDCはこうした新しい技術を恐れず、過信もせず、まずは動かしてみることを大切にしています。自ら実践して能力と限界を知る。このプロセスこそが、変化の激しい時代に適応し、新しい開発・運用のスタイルを作り上げる道だと考えています。

クラウド活用とAI導入に関するご相談

NCDCでは、AWS DevOps Agentのような最新のAIツールやクラウドサービスを、実務にどのように組み込むべきかのコンサルティングを提供しています。導入にあたってのログ設計、アーキテクチャの最適化、あるいはAIと人間が共生する運用体制の構築など、現場のリアリティに基づいたご支援が可能です。最新技術を「武器」に変えたいとお考えの方は、ぜひ私たちにご相談ください。

※本記事では一部の文章作成および画像生成にAIを使用しています