あいまいな指示でも不備を検知！AWS DevOps Agentで「楽で安全な」インフラ運用を手に入れる方法 JAWS DAYS 2026 登壇レポート
2026年3月7日、JAWS DAYS 2026が開催されました。SHIFTがPLATINUM スポンサーを務めた本イベントに、AIアジャイル開発部の奥田雅基が登壇。
「DevOpsエージェントで実現する！！AWS Well-Architected（W-A）を実現するシステム設計」と題したセッションにて、AWS運用の辛さを解消し、システムの運用改善を劇的に推し進める「AWS DevOps Agent」の活用方法について語りました。
AWSを用いたシステムの設計や運用において、「辛さ」を感じたことはないでしょうか？複雑化する設定項目、見えにくい設定不備、そしていざトラブルが起きたときの原因究明のむずかしさ——これらは多くのエンジニアが日々直面する課題です。
奥田は、「AWS DevOps Agent は高いオブザーバビリティ（可観測性）をもたらすだけでなく、最終的にAWS Well-Architected Framework（W–A）の柱である『運用上の優秀性』を体現するための強力な鍵になる」と語ります。
本記事では、「実務でありがちな障害ケースをエージェントは解決できるのか？」「監視サービスの設定がなぜ重要なのか？」といった現場のエンジニアとしてのこだわりを詰め込んだ検証結果と、検証のなかで気づいた注意点を共有します。
※当日の実際のセッションの様子は、以下のアーカイブ動画からご覧いただけます。
▶ JAWS DAYS 2026 セッションアーカイブ動画はこちら
-
AIアジャイル開発部 DevOpsエンジニア 奥田雅基
2016年、システム運用保守としてIT業界でキャリアをスタート。通信会社の新規ネットワークサービス立ち上げPJのPMO・ネットワークエンジニア、人事（社員教育担当）、社内プロダクト開発PJのシステムエンジニアを経て、2025年8月、株式会社SHIFTに入社。DevOpsエンジニアとして案件に取り組みつつ、社内外への技術発信活動にも挑戦している。
目次
設定ミスと属人化。人間による監視には限界がある
システム運用において恐ろしいのは、「設定ミスによる想定外の障害」と「トラブル発生時の原因特定に時間がかかること」です。
現場のエンジニアは、セキュリティグループの過度な解放や、アクセスログの未取得といった一見些細な不備が、後に重大なインシデントに繋がることを痛感しています。
しかし、無数にあるAWSリソースのすべての設定を完璧に網羅し、継続的に監視しつづけることは、人間の力だけでは限界があります。
こうした、運用にまつわる辛さをどうにかして軽減できないか。これが、現場のエンジニアたちがつねに抱えている大きな課題感です。
その課題を解決する一手として登場したのが「AWS DevOps Agent」です。これは、インシデントを解決・予防し、システムの信頼性とパフォーマンスを継続的に向上させるための自律型エージェントです。
最大の特徴は、まるで経験豊富なベテランDevOpsエンジニアが隣に座り、いっしょにインシデントを調査して運用上の改善点を特定してくれるかのような体験が得られる点です。
事象の調査だけでなく、改善提案までを自律的におこなってくれるため、インフラ運用の負荷を劇的に下げることができます。
AWS DevOps Agentの非常に面白いポイントは、AWSマネジメントコンソールとは別の「専用ダッシュボード」が用意されていることです。
例えば、オペレーターの方がAWSコンソールを触ると、操作ミスによって稼働中のサーバーを落としてしまうなどのリスクがつねに付きまといます。
専用ダッシュボードを利用することで、そうした誤操作のリスクを低減しつつ、安全に調査や管理を行うことが可能になります。
ただし、現時点はプレビュー版であるため、料金は無料ですが、利用できるのはバージニア北部リージョン（US-EAST-1）のみとなっているなど、いくつかの制約事項も存在します（※講演時点：2026年3月時点の情報です。2026年4月以降、一般提供されているため最新情報は公式サイト等でご確認ください） 。
また、プレビュー期間においては1ヶ月あたりの利用制限があり、エージェントの対応時間は月20時間、保守時間は月10時間に限られています。
そして、サポート言語は英語のみであるため、調査指示も英語で行う必要があります。
【独自検証】曖昧な指示 vs 明確な指示。見えてきた AI特有の落とし穴
AWS DevOps Agentの実力を測るため、私は実務で起きがちな障害ケースを想定した検証環境を構築しました。「ネットワーク」「サーバー」「ストレージ」という、障害が起きやすく影響範囲が大きい3つの観点に絞りました。
具体的には、セキュリティグループの過度な開放（0.0.0.0/0）、エフェメラルポートの通信拒否、VPCエンドポイント未設定によるインターネット経由の情報漏洩リスク、Amazon EC2のAWS IAM ロール未設定や詳細モニタリングの無効化、さらにはAmazon Elastic Block Storeボリュームの非暗号化やバックアップの欠如などです。
検証の際、SHIFTのエンジニアとしてのこだわりとして、これらをコンソールから手作業で構築するのではなく、すべてInfrastructure as Code（IaC）ツールであるTerraformを用いてコードベースで構築しました。
実務に限りなく近いリアルな障害環境を用意することで、エージェントの真価を問うための準備を整えました。
検証では以下の条件を設定し、結果にどのような違いが出るのかを調査しました。
プロンプトに関しては、「Amazon EC2やAmazon S3で何か障害が起きているので調べてください」といった曖昧な指示と、「特定のプロジェクトタグがついた環境で、ネットワークのセキュリティグループやサーバーの詳細モニタリング設定に不備がないか調べてください」といった明確な指示の2パターンを用意しました。
結果として、明確な指示を出した場合は10件の不備を迅速に検知できました。さらに曖昧な指示であっても、ログ関連の不備を含めて実に17件もの不備を検知することができたのです。
しかし、明確に指示しすぎた場合では、「どう対処すればよいか」という詳細な改善提案が省略されてしまうケースも見受けられました。
また、上記からもわかる通り「Amazon CloudWatch Logs」の設定が有用であることも判明しました。
ログの詳細情報がないと、Amazon VPC周りの不備などは「詳細情報がないため検知できません」とエージェントに突き返されてしまいます。
さらに、AI特有のハルシネーションの存在も確認できました。
CloudWatch Logsを設定した環境で明確な指示を出した際、実際にはログ関連の設定を一切修正していないにもかかわらず、エージェントが「ログ関連も含めて修正済みであることを確認しました」とレポートを返してきたのです。
AIの回答を鵜呑みにせず、最終的な確認は人間の目で行うことの重要性を再認識しました。
ここで、私が実際に直面した失敗談を共有します。Google ChromeでAWS DevOps Agentを使った際、なぜかエージェントの画面で謎のエラー文字列が表示され、調査を開始できない事象に遭遇しました。
原因は、AWSマネジメントコンソールの表示言語でした。言語設定を日本語から英語に変更しないと、AWS DevOps Agentが正常に動作しなかったのです。
プレビュー版特有の仕様ですが、原因特定までに1時間もかかってしまいました。みなさまが利用する際は、必ず言語設定を英語にしてから挑んでください。
オペレーショナルエクセレンスを実現する3つのアプローチ
AWS DevOps Agentは、W-Aの「運用上の優秀性（オペレーショナルエクセレンス）」の柱を強化する上で非常に強力なツールとなります。
W-Aとは、クラウド環境において、よりよい設計やアーキテクチャを実装するために、AWSが提唱している主要な概念です。
そのなかのひとつの柱である「運用上の優秀性」とは何か。専門的な言葉で語られることが多いですが、一言で表すなら「いかにシステムを『楽に』かつ『安全に』運用しつづけられるか」という考え方です。
検証をするうちに、AWS DevOps Agentを活用し、この理想的な運用状態に近づくための3つのアプローチが見えてきました。
1つ目は、ログ出力設定の継続的な改善です。システム運用において、トラブルの根本原因を特定するには適切なログが不可欠です。
しかし、どのようなバランスでログを出力すべきかの判断は容易ではありません。
AWS DevOps Agentを利用すれば、「現在のログ出力の仕方で、障害を正しく検知できる状態になっているか」を自律的に見極め、評価してくれます。
つまり、発生したリソースの障害を直すだけでなく、ログ出力の仕組みそのものを継続的に改善することが可能になります。
2つ目は、専用ダッシュボードを活用した安全な運用体制の構築です。
システム監視を運用会社やオペレーターに委託する場合、AWSアカウントの強力な権限を直接渡すことには抵抗があると思います。
AWS DevOps Agentの専用ダッシュボードを利用すれば、オペレーターはAWSコンソールに直接ログインすることなく、ダッシュボード上から安全に障害調査を行うことができます。
これにより、設定を誤って変更してしまうリスクを低減し、誰でも安全に運用できる環境を担保できます。
3つ目は、インシデント管理のプロセス化と簡略化です。
通常、インシデントが発生すると自前のチケット管理ツールに事象を起票し、エラー内容やログを貼りつけて管理する手間が発生します。
AWS DevOps Agentでは、調査（Investigation）を実行するたびに独立したチャットが生成されます。
このチャット自体が一つの「インシデントチケット」として機能するため、「あの障害のステータスはどうなっているか？」といった煩雑な管理から解放されます。
完璧ではない、だからこそ面白い。次世代の運用体験
AWS DevOps Agentは、日々の運用でありがちな設定不備を検知し、安全で楽な運用体制（運用上の優秀性）を構築するための非常に強力な武器です。
確かに、現在はプレビュー版であり、東京リージョンで利用できない点や、AWS IAM Identity Centerの統合における制限、言語の壁など、乗り越えるべきハードルは存在します。
ハルシネーションのリスクなど、扱う側にもリテラシーが求められます。
しかし、それらの制約を差し引いても、このエージェントがもたらす「ベテランエンジニアが伴走してくれる安心感」は計り知れません。
まずはご自身の手で実際に触ってみて、新しい運用体験の楽しさを実感してください。
今後のCI/CDへの組み込みやサードパーティ統合など、さらなる機能展開にも大いに期待しましょう。
SHIFTでは、こうした最新技術に主体的に触れ、お客様の課題解決に向けてともに挑戦していく仲間を募集しています。
インフラ運用を技術の力で効率化し、新しいスタンダードをいっしょにつくっていきませんか。
（※本記事の内容は、イベント開催当時のものです）
