こんにちは。 ビジネスソリューション事業部（BS事業部）の西村です。2026年6月25日〜26日、幕張メッセの AWS Summit Japan 2026 に、BS事業部から3名で現地参加してきました。

会場は、とにかく 生成AI一色。基調講演もセッションも展示も、どこを向いても生成AIとAIエージェント、そしてデータ活用の話でした。もはや「AIを導入するか否か」ではなく「どの業務に、どう安全に使うか」という実践フェーズに完全に移った、という空気感を肌で感じました。

そんなAIで何でも楽になりそうな空気のなか、初日に私が一番心を掴まれたのは、むしろ正反対のメッセージでした。満員の会場、参加者が一斉にスマホを構えるなか、スクリーンにはこう映っていたのです。

「なぜあなたの運用は AI で楽にならないのか」

この一言に、私は自分のチームの現場を重ねて深く頷いていました。結論を先に言うと、Summitを通して確信したのはこれです。生成AIは「運用の手間」を確かに肩代わりする。でも「運用の責任」は肩代わりしない。だからAIと組織力は“両輪”で回すしかない。

この記事では、それについて自分なりに感じたことを書きます。技術的な深掘りは、同じく現地参加した久保が別記事で書くので、そちらと合わせてどうぞ。

対象読者

• 生成AIを使いながら、運用やインシデント対応の体制をどう組み立てるか考えている方
• AIエージェント（AWS DevOps Agent など）を「どこまで任せられるか」見極めたい方
• 属人化しがちな運用を、チームの仕組みとして立て直したいと考えている方

AIで開発が加速するほど、運用が苦しくなるという現実

この「開発が速くなるほど運用が苦しくなる」構図を、はっきり言葉にしていたのが、PagerDuty のセッション（登壇：草間一人さん）でした。自分なりに要約するとこうです。生成AIで開発は速くなった。けれど、開発が速くなりリリースが増えるほど、障害もインシデントも増える。つまり ボトルネックは「開発」から「運用」へ移る。

そして核心は「じゃあインシデント対応もAIに丸投げすればいい、という考えは甘い」という一言でした。障害がAIエージェント由来なのか、人為ミスなのか、インフラ障害なのかで対応はまるで違う。誰が指揮を執り、どんな情報を、どの粒度で、誰に、いつ伝えるのか。こうした 「人と組織の段取り」がなければ、AIがいくら賢くても現場は回らない、という話です。

誤解のないように言うと、「AIは使うな」ではありません。むしろ逆で、省力化のためにAIは徹底的に使うべき。ただ、AIと組織力は“どちらか”ではなく“両輪” だということです。

AIは「トリアージ」まで来ている。その先が問題

これはSummitでのAWS自身の動きを見ると、技術の最前線も同じことを言っていると感じました。その象徴が AWS DevOps Agent です。

本日、AWS DevOps Agent の一般提供開始をお知らせします。AWS DevOps Agent は、いつでも対応可能な運用チームメイトです。インシデントの解決とプロアクティブな予防を行い、アプリケーションの信頼性とパフォーマンスを最適化し、そして AWS、マルチクラウド、オンプレミス環境をまたいでオンデマンドの SRE タスクをこなします。

運用チームはインシデント調査、複数ツールにわたるデータの相関付け、アラートの手動トリアージに膨大な時間を費やしています。この運用負荷がエンジニアをイノベーションや戦略的な業務から遠ざけています。AWS DevOps Agent は、経験豊富な DevOps エンジニアのようにインシデントを調査し、この負担を解消します。アプリケーションとその関係性を学習し、オブザーバビリティツール、ランブック、コードリポジトリ、CI/CD パイプラインと連携して、それら全てのテレメトリ、コード、デプロイデータを横断的に相関付けます。プレビュー期間中、AWS DevOps Agent を使用したお客様とパートナーからは、MTTR が最大 75% 削減、調査時間が 80% 短縮、根本原因特定精度が 94% を達成し、インシデント解決が 3〜5 倍速くなったと報告されています。

出典：AWS「AWS DevOps Agent の一般提供開始のお知らせ」

ここまで読むと「じゃあ本当に運用は楽になるのでは？」と思えます。実際、アラートの一次調査という“手間”は、AIが確かに肩代わりし始めています。しかし、調べていくと2つの現実が見えました。

AIに任せるにも「組織の下ごしらえ」が要る

• CloudWatchのアラートが出ても、DevOps Agentが勝手に全部やってくれるわけではない。自動で起動させるにはWebhook等の設定が要る。連携先の監視やランブックが整って初めて力を発揮する。
• あくまでチームを迅速な解決へ導く存在。最終的に「何を対応すべきか」「誰が指揮するか」は人と組織が持つ。

つまり、最先端のAIエージェントを入れても、ランブック・監視・インシデント時の段取りという組織の土台がないと、AIは十分に働けない。そして土台があってなお、判断と責任は人に残る。図2の両輪が、AWS自身のサービスの設計思想としてそのまま現れていました。運用の手間は減らせても、誰も運用しなくてよくなるわけではないのです。

これについてはAWS Villageで実際に確かめてきました。Slackのアラート通知からボタン一つでDevOps Agentに調査を走らせるデモを見せてもらい、「特定のアラートが出たらこう処理してほしい」「月次でアラートを集計してほしい」といった、いま現場で人が手でやっている機械的な作業をどこまで任せられそうか、AWSの方に率直に聞いてみました。返ってきたのは、Skillとして手順をあらかじめ定義しておけば一定の制御はできそう、という感触。トリアージの機能もあり、このあたりは実運用でも十分に使えそうだと感じています。

理想論にしないために。私たちのチームの現在地

「組織力が大事」と言うだけなら簡単です。でも私がこの主張に強く頷けたのは、自分のチームがまさに同じ土台を積み上げている最中 だからでした。正直、体制はまだ“完成”には程遠く発展途上です。それでも今回、「この方向は間違っていない」と確信できました。

1. リリースを“仕組み”で回す

本番リリースのたびに リリース計画書を作成し、リリース前に複数名で内部レビュー を行っています。「担当者の頭の中の手順」でその場リリースするのではなく、計画 → レビュー → 実施 という型を必ず通す。地味ですが、生成AIでリリース頻度が上がるほど、この一手間が効いてきます。

2. 障害時は“指揮役”を事前に決めておく

インシデントが起きたとき、対応リーダー（指揮役）が誰かを事前に決めています。だから障害の瞬間に「で、誰が仕切るんだっけ？」で止まらない。草間さんのセッションでも核心だった「責任の所在と意思決定の経路を明確にする」という考え方に沿った運用です。そして、これはまさに AIが肩代わりできない部分 でもあります。DevOps Agentがトリアージを進めてくれても、何を対応すべきか判断し、誰が指揮を執るかは人が担う。だから指揮役を先に決めておくことに意味があります。

3. 振り返って終わりにせず、手順に還元する

起きたインシデントは、月次で振り返っています。ポイントは反省会で終わらせないこと。振り返りから改善策を決め、実際にリリース手順や対応プロセスに反映しています。

たとえば、リリース作業の担当者が急きょ交代した際に環境設定の不備で対応が遅れたことがありました。その反省から、リリース前チェックに 「割り当てられた担当者以外も同じ設定を再現できる状態か」を確認する項目を追加 しました。特定の人しかできない状態＝属人性こそが障害の火種になる、という学びを、チェック項目という“仕組み”に変えたわけです。こうして 一度の障害を、次に同じことを起こさないための手順に還元していく。「インシデントは必ず起きる。起きる前提で設計する」を、少しずつ形にしています。

この “学習して強くなる”ループこそ、AIには肩代わりできない組織の資産 だと考えています。DevOps Agentが過去のインシデントからパターンを学ぶように、私たち自身も学んでプロセスを育てていく。人とAI、両輪で強くなるイメージです。

そして、次の一歩：AIでトリアージを

この土台の上に、いま新しい一歩を踏み出そうとしています。長期運用の保守現場では、年月とともにアラートが増え続け、その一次調査に時間を奪われがちです。ここに AWS DevOps Agent のトリアージを効かせられないか、検証を始めるところ です。狙いは、AIに一次調査という手間を任せ、人は「何を直すか」の判断と改善に集中すること。まさに両輪の実践です。

おわりに

AI時代の運用で問われるのは、派手なAI活用より「AIに任せるための土台」が整っているかどうか。ランブック、監視、インシデント時の指揮系統、そして振り返って手順を育てる習慣です。まずは自分のチームを、この観点で点検してみてください。同じような課題に取り組む方の参考に、この記事が少しでもなればうれしいです。

【おまけ】Summitオリジナルクッションを追いかけて

ここからは余談です。今回の参加は、私ともう一人のエンジニア久保がAll AWS Certifications Engineer 2026に選出されたことがきっかけでした。「せっかくだったらAWSサービスの最前線を見たい」と思って上長に直談判して参加が実現しました。

全冠エンジニア2人、勇んで幕張へ——なのですが、当日はまず行列の洗礼を受けることになります。

• 自分：人やばすぎやろ、最後尾どこ（笑）
• 自分：早く来たと思って並んでたけど、そもそも列の存在に気づかず中で写真撮ってた自分が恥ずかしい…
• 自分：お弁当とクッションってもらえるのか？
• 同僚：「1日を快適に過ごせるSummitオリジナルクッション」らしいよ。どんだけ快適なのか気になるから是非ゲットしてきてw
• 同僚：待機列、想像の500倍長かった（笑）
• 自分：…今僕は何の列に並んでるんだ
• 自分：クッション発見！と思ったら、どうやらサンドイッチ配給の列に並んでいたようです

結局のところ、クッションは基調講演の座席に置いてあり、チケットさえ持っていれば全員もれなくもらえる のでした。

ひとしきり列に翻弄されましたが、こういう出たとこ勝負も含めて、現地参加は楽しいものです。