はじめに

この度、2026年2月に開催されたAI運用勉強会に登壇しました。
本記事では、登壇内容を簡単にまとめます。

概要

AI運用勉強会とは

まずは、AI運用勉強会について説明します。

AI運用勉強会は、PagerDuty Japan Communityが中心になって運営している、AIをシステム運用にどう生かして行くかを共有し、共に学んで行く勉強会です。
AIコーディングエージェントの劇的な進化により、システム開発でAIを活用するのは当たり前の時代となりました。それに伴い、運用面においても今後ますますAIの必要性が増していくと考えられます。
しかし、運用ではAIの誤動作が即座にユーザー体験へ影響するため、開発と同じ発想ではリスクを抑えきれません。そのため、開発とはまた違った観点での活用が必要となっていくでしょう。
この勉強会は、そのような発展途上のAIシステム運用についての知見を蓄えていくことを目的としています。

簡単に説明するとシステム運用にAIをどう活用していくかを学ぶ場であり、PagerDuty Japan Communityが主催しています。PagerDuty Japan主催とありますが、システム運用に関心のある方であれば誰でも参加可能なオープンな勉強会です。

AI運用勉強会は偶数月に開催されており、今回が2回目の開催です。
なお、筆者も運営の一員として参加しており、今回は登壇者とそして司会としても参加しました。

登壇内容

ここからは、筆者が登壇した内容について簡単にまとめていきたいと思います。
まずは、登壇タイトルと登壇者情報です。

  • タイトル: クラウド運用とAIエージェント
  • 登壇者: クラウドインテグレーション事業部　MSP開発セクション　山田顕人（このブログの筆者）
  • アイレット公式プロフィール

※2025年1月20日に大変光栄なことに初代PagerDuty アンバサダーに就任いたしました。リンク

概要としては、以下の通りです。

昨年の2025年はAIエージェント元年となりました。そんなAIエージェント時代でも弊社は変わらずPagerDutyとともにクラウド運用をしてきました。同時に次世代監視基盤（以下、AMS）というMSPのバックエンドを支える内製システムの運用も進めています。 AMSはPagerDutyを中心に据えたシステムとなっており、障害発生から復旧までにかかる作業を自動化しています。今回はそんなAMSの凄さを運用分析で得られた数値をベースに振り返りつつ、AIエージェントが導入されるとどんな運用が実現できるのかを紹介したいと思います。

本編（要約）

  • クラウド運用の一次対応には内製システム、AMS(Advanced Monitoring System)を活用している
  • AMSはPagerDutyを中心に据えたシステムであり、障害発生から復旧までの作業を自動化している
  • AMSの導入により、障害対応の平均対応時間が大幅に短縮された
    • 一次対応に平均対応時間は約35秒、長くても50秒以内
    • 対応件数の93%はAMSによる自動対応で完結
  • 分析ではRedashを活用していたが、分析プラットフォームの運用を減らすためにLookerとAmazon Athena、Looker Studioに移行
    • Lookerの会話分析により、自然言語で運用を分析できるといった高度な分析が可能になった
  • AIエージェントの導入により、さらなる運用効率化が期待できる
  • 今後の展望として、AIエージェントとAMSの連携により、より高度な自動化と効率化が実現できる

本編

ここからは、登壇内容の一部を抜粋して紹介します。

発生したアラートは自動で解決、分析も自動化！

まず、弊社のクラウド運用について裏側がどうなっているのかを簡単に説明しました。

弊社のクラウド運用では、AMS(Advanced Monitoring System)という内製システムを活用しています。AMSはPagerDutyを中心に据えたシステムであり、障害発生から復旧までの作業を自動化しています。

また、読んで字のごとく運用分析プラットフォームという分析の仕組みも存在します。この分析プラットフォームでは、LookerやAmazon Athena、Looker Studioを活用しており、運用データの可視化や分析を行っています。

AMSとは何か、導入効果

AMS（Advanced Monitoring System）は監視業務の一次対応を自動するシステムです。
監視業務の自動化だけでなく、常に同じアラート対応ができるようなそんなシステムです。大量の1次対応に貢献しているシステムです。
クラウドはAWSを使っており、マルチリージョンで展開されています。

AMSの導入効果は大きなところでは監視業務負荷の削減がありますが、それ以外にも様々な効果があります。
定性的な評価をするとアラート対応の均一化が挙げられます。

有人対応によるアラート対応ではミスがつきものですが、それらを回避できている側面もあります。
また、複数アラートが発生した場合においては本当に有人対応しなければいけないアラートにフォーカスすることもできます。

システム運用を分析するプラットフォーム

AMS含め、弊社のクラウド運用には重要な要素として運用分析プラットフォームというものがあります。

最初はRedashを使った分析環境でしたが、現在はLookerとAmazon Athenaを使った分析プラットフォームに進化しています。また、自由なBI環境を提供するためにLooker とは別にLooker Studioも提供しています。
技術的な側面でみるとLookerを介してLooker StudioでAmazon Athenaを操作しているようにみえるので不思議な感じがするかもしれません。

※本編では解説しきれなかった分析環境の詳細については、以下の記事をご参照ください。

運用を分析したことでわかったAMSの導入効果

2025年の10月から12月で試算したところによると
AMSは一次対応の93%、583,359件を処理しており、対応時間の合計は236人日、アラート対応1件につき平均35秒で処理しています。

平均対応時間については2025年の7月から9月までの数値で計算しても45秒程度、4月から6月まででも48秒
ということで、50秒以内に収まっています。

それでもやっぱりクラウド運用は難しい

平均35秒でアラートを処理しているけども、実際はそこまで簡単な話でもないのが現状です。

具体的にはおよそ1万台のEC2からアラートが発生したり、15分から30分で復旧するシステムがAMSの先にあります。
また、AMSというのはアラート発生をトリガーに復旧コマンドを実行するという仕組みになっていますのでコマンド実行できるのが当たり前となっています。

AMSに何か問題があれば、AMSの復旧が必要になります。復旧の間はAMSが動かないため、手動での対応が必要になり、MSPに負担をかけてしまいます。

主な対応

  • コマンドを実行しているのでコマンド実行内容の精査や内容の修正
  • 大量のアラートを捌いているのでOut Of Memoryやスケールイベント、エラーカウントのチェック
  • アラートが滞留していないかのチェックです

余談：Content-Based Alert Groupingの活用

AMSはPagerDutyのContent-Based Alert Groupingを活用しています。
Content-Based Alert Groupingはアラートの内容に基づいてグルーピングを行う機能です。
AMSではこの機能を活用して、同一の問題に関連するアラートをまとめています。まとめることによってAMSの負荷を下げたり、対応の効率化を図っています。

このほかにも、Time-Based Alert GroupingやIntelligent Alert Groupingがあります。

AMSというシステム運用を通して考えを深める

Content-Based Alert Groupingの活用をするなどのアラート削減の取り組み中でAMSというシステム運用に必要なことがどんなことなのかについて考えを深めることが増えてきました。ここで課題になり始めるところとしては莫大なアラート件数に対してどのような最適化を図るかというところです。

現在は問い合わせされた内容に対して個々にアプローチをかけています。欲を言えば、アラートグルーピング同様に
アラートを減らす取り組みやアラートの解決速度をあげるような取り組みをする必要があると感じています。

そういった欲を実行に移すには莫大なアラート情報をソースとして全体を見渡してAIエージェントでアプローチをかける必要があると考えています。

AIエージェントを作る土台はすでにある

すべてのデータはPagerDutyとAWSにあるため、データを使って運用を改善する土台はすでにあります。
あとはAIエージェントを導入して、運用改善に取り組むだけです。

実際に取り組む前に考えるべきこと

運用の改善にAIエージェントを導入する前に考えるべきことがあります。一番はやはり、運用を混乱させないことです。
運用を混乱させないためにも段階を踏んでシステム運用にAIエージェントを導入していく必要があります。

AIエージェント導入のステップ

分析とシステム運用の両面からAIエージェントを導入していくステップを考えてみます。

分析

  • アラートをなんとなーく分析できるAIエージェント
  • 分析から浮かんできた内容を踏まえて改善計画立てるAIエージェント
  • 改善計画から逆算して分析ダッシュボードを自動で作成するAIエージェント

システム運用

  • MSPと並走してアラート対応のアドバイスをするAIエージェント
  • アラートから対応すべき内容を調査して実行計画を作成するAIエージェント
  • 実行計画を参照してコマンド実行を担うAIエージェント

上記の中でもすでにLookerの会話分析のように分析面でのAIエージェント導入が始まっています。

事例：Looker 会話分析（Conversational Analytics）による運用分析

Lookerの会話分析は自然言語でLookerのデータを分析できる機能です。
今回は以下の内容を紹介しました。

AIエージェントを活用した次世代のクラウド運用へ

最後に、AIエージェントを活用した次世代のクラウド運用について紹介しました。
現在の取り組みとしては、Lookerの会話分析を活用した運用分析の効率化がありますが、将来的にはシステム運用の自動化も視野に入れています。

たとえば、Amazon Bedrockによる障害一次調査の自動化を視野に入れています。現在は大量の一次調査を私を含め、メンバーでせっせと対応していますが、AIエージェントに任せることで、より高度な調査や対応が可能になると考えています。

ちなみにPagerDutyにはMCPが存在するので新たにエージェントを作る場合や今回紹介したAMSにはPagerDutyのAPIが利用されていますのでMCPを積極利用するのもありだと考えています。

PagerDuty MCPについては以下のリンクをご参照ください。

おわりに

以上、AI運用勉強会#2での登壇内容を簡単にまとめました。
AIエージェントを活用したクラウド運用の未来について、少しでもイメージを持っていただければ幸いです。
今後もAI運用勉強会では、システム運用に関する様々なテーマで登壇が行われる予定です。興味のある方はぜひ参加してみてください。

宣伝： PagerDuty on Tour Tokyo 2026

最後に宣伝です。2026年4月15日から16日にかけてPagerDuty on Tour Tokyo 2026が開催されます。
PagerDutyそして、システム運用に関心のある方はぜひご参加ください。詳細は以下のリンクをご参照ください。