トップ > AWS Summit Japan 2026 > 【AWS Summit Japan 2026】AIOpsはどのように設計するべきか

【AWS Summit Japan 2026】AIOpsはどのように設計するべきか

AWS Summit Japan 2026
記事タイトルとURLをコピーする

はじめに

皆さん、こんにちは。サーバーワークス マネージドサービス部 マネージドサービス課のイです。

本記事では、AWS Summit Japan 2026 で見た AIOps の事例をもとに、AIOps を設計するにはどのようなポイントを考慮すべきなのかを考えてみました。

取り上げるのは、印象に残った 2 つのブースです。1 つは Server-Timing を起点にユーザーリクエストの遅延を可視化する事例、もう 1 つは通信ネットワーク運用を複数のエージェントで分担する事例です。

特に注目したいのは、AI エージェントそのものではなく、エージェントが判断できる状態をどうつくるかという点です。以下では、観測可能なデータ、問題の分解、権限設計という 3 つの観点から、AIOps のアーキテクチャを考えていきます。

AWS Summit Japan 2026 で見た 2 つの事例

事例 1: Server-Timing で観測可能なデータをつくる

このブースのテーマは「ヘッダー 1 行から始める！レイテンシ改善」でした。

問題意識: 遅いリクエスト、どこで詰まっているのか？

Web アプリケーションへの 1 つのリクエストは、思った以上に長い経路を通過します。

DNS 解決 → TCP/TLS 接続 → エッジ処理 → オリジン処理 → 転送 → 応答

ボトルネックがどこにあるのか、その内訳が見えなければ改善の手がかりは見つかりません。まずはリクエストのどの区間で時間がかかっているのかを可視化する必要があります。とはいえ、そのために最初から重厚な APM ツールを導入するのは負担が大きいものです。このブースでは、より手軽な第一歩として Amazon CloudFront の Server-Timing ヘッダーの活用を紹介していました。

Server-Timing ヘッダーとは？

Server-Timing は、HTTP レスポンスヘッダーに処理時間メトリクスを載せて伝える W3C 標準仕様です。ブラウザ対応率は 95% 以上で、追加の SDK やエージェントなしに Chrome DevTools の Timing タブからすぐ確認できます。

3 ステップのアプローチ

ブースでは、次の 3 ステップで計測 → 収集 → 自動化を構成する方法が紹介されていました。

Step 1: CloudFront の Server-Timing 有効化

CloudFront のレスポンスヘッダーポリシーで Server-Timing を有効化すると、CloudFront が自動的に以下のようなエッジ計測情報をレスポンスヘッダーに付与してくれます。

aws.amazon.com

メトリクス 説明
cdn-cache-hit / cdn-cache-miss キャッシュヒットの有無
cdn-upstream-dns;dur=0 オリジンの DNS 解決時間（ms）
cdn-upstream-connect;dur=114 TCP/TLS 接続完了までの時間（ms）
cdn-upstream-fbl;dur=177 オリジンからの最初のバイト受信まで（ms）
cdn-downstream-fbl;dur=436 ビューワーへの最初のバイト送信まで（ms）
cdn-pop;desc="NRT12-C2" リクエストを処理したエッジロケーション

CloudFront が起点となり、エッジからオリジンまでのレイテンシの内訳をブラウザからすぐに確認できるようになります。

Step 2: アプリケーション固有の計測を Server-Timing に追加する

CloudFront が付与してくれるのは、エッジロケーションを起点にオリジンとやり取りする区間、いわばリクエストがエッジに到達してからビューワーへ応答するまでのラウンドトリップの指標です。裏を返せば、オリジンのアプリケーション内部で具体的に何に時間がかかっているのか（DB なのか、外部 API なのか）までは、この指標だけでは分かりません。そこで、オリジン側でも DB 接続・クエリ・外部 API 呼び出しといった処理時間を、アプリケーション自身が Server-Timing ヘッダーに追加します。

docs.aws.amazon.com

たとえば CloudFront のエッジ指標とアプリケーションの DB 処理時間が 1 つのヘッダーにまとまると、次のような形になります。

Server-Timing: cdn-upstream-fbl;dur=177, cdn-cache-miss, cdn-pop;desc="NRT12-C2", db-connect;dur=5, db-query;dur=53

このように CloudFront 側のメトリクスとアプリケーション内部の処理時間を同じ Server-Timing ヘッダーに載せることで、CDN からオリジン、アプリケーション内部までの遅延要因を 1 つの入力として扱えるようになります。これを Amazon CloudWatch RUM などで収集すれば、後続のエージェントが原因分析に利用できるデータになります。

Step 3: CloudWatch RUM で収集 → DevOps Agent で自動化

DevTools で見るだけで終わりにせず、ブラウザの Performance API で Server-Timing 値を取得し、CloudWatch RUM へカスタムイベントとして送信すれば、実ユーザーのデータを継続的に収集・可視化できます。

Performance API → CloudWatch RUM → CloudWatch Logs → メトリクスフィルター
                                                              ↓
                                                      CloudWatch Alarm
                                                              ↓
                                              Lambda（Webhook 送信）
                                                              ↓
                                                      DevOps Agent
                                                  （原因分析 → 改善提案）

CloudWatch RUM に集約した Server-Timing の値は、メトリクスフィルターで数値を抽出し、パーセンタイル統計による傾向分析や閾値監視に利用します。レイテンシの閾値を超えるとアラームが発火し、AWS Lambda を通じて Webhook が AWS DevOps Agent に渡されます。DevOps Agent は Server-Timing 情報を参照して原因を自動的に分析し、改善案を提示します。

ブースでは、次のような DevOps Agent の出力例も紹介されていました。（以下の数値は発表資料に基づきます）

  • 原因特定: origin_process が 6,600ms（TTFB の 85%）。CDN オーバーヘッドはわずか 9ms
  • 内訳: db_connect 941ms（接続プール初期化）・db_query 102ms・Lambda 実行 7,190ms
  • 根本原因: Lambda デプロイ直後に CloudFront 全体のキャッシュ無効化（/*）を実行 → コールドスタート + キャッシュミス 100% という最悪の組み合わせで TTFB 7,742ms
  • 改善提案: 段階的なキャッシュ無効化・Lambda のウォームアップ期間の確保・カナリアデプロイ

セキュリティ上の注意点

Server-Timing はクライアントに公開される HTTP ヘッダーです。ブースの発表資料では、本番運用で意識すべき点として次の 3 つが紹介されていました。

  • メトリクス名は cache、db のように汎用化し、redis-cache などの内部技術名は使わない
  • ログイン・認証・決済などタイミング攻撃のリスクが高いエンドポイントでは無効化する
  • 開発環境は詳細名 + 100% サンプリング、本番環境は汎用名 + 低サンプリングというように環境で粒度を変える

この事例を AIOps の観点で見ると、重要なのは Server-Timing そのものではなく、エージェントにどの判断を任せたいのかを先に決め、その判断に必要なデータをそろえて渡せる形にしている点だと思います。

事例 2: 通信ネットワーク運用を役割別エージェントに分ける

2 つ目に印象的だったブースは、通信インフラの運用に AI エージェントを適用した事例の紹介でした。テーマは「通信ネットワーク運用の未来 ― エージェンティック AI が実現する自律運用」です。

通信ネットワーク運用の 3 つの課題

課題 AI エージェントによる解決
深夜のアラーム対応 — 人が起きてログを追い、迂回経路を設定する。NOC エンジニアの疲弊 自律エージェント化 — 複数のエージェントが協調し、アラーム検知から障害機器の交換手配まで一括で実行
リアクティブな対応 — 障害発生後の事後対応。SLA 違反と顧客解約のリスクが積み重なる 予測と予防 — 障害が起きる前に需要急増を予測し、予防策を自動で立案
画一的な顧客通知 — SLA 等級を無視した一斉メール。エンタープライズ顧客の信頼を損なう 顧客別コミュニケーション — 顧客ごとの影響度・SLA・感情スコアに応じたパーソナライズ通知を自動生成

アーキテクチャ概要

想定環境はクラウド + オンプレミスのハイブリッドネットワークです。大きく 3 つのレイヤーで構成されます。

① ネットワークデータの収集

  • AWS インフラ: Amazon CloudWatch、EKS Telemetry、VPC Flow Logs
  • CNF プラットフォーム: Kubernetes API、Prometheus
  • オンプレミス: SNMP/Syslog、NetFlow、ベンダー NW 管理システム

② データ統合 / 知識基盤（AWS Glue による 4 段階パイプライン）

  • Amazon DynamoDB: ノード情報・インシデント履歴
  • Amazon Timestream: KPI 時系列データ
  • Amazon Neptune: トポロジーグラフ（障害伝播経路の探索）
  • Amazon Bedrock Knowledge Bases: 運用ドキュメント・インシデントレポート・設計情報を RAG で検索

③ 運用 AI エージェント（Amazon Bedrock AgentCore）

  • Network Observer、Root Cause Analyzer、Actuation Orchestrator など役割別のエージェントが協調

デモで見たもの

ブースでは合計 4 つのデモが用意されていましたが、そのなかでも特に印象的だった 2 つを紹介します。

デモ②: ネットワーク障害の自動検知・復旧

バックホール（基地局とコア NW 間の中継回線）の物理障害シナリオです。従来は検知から復旧まで 15〜30 分以上かかっていましたが、エージェントを通じて次の流れを数分以内に完結させました。

アラームスパイクの検知 → Root Cause Analyzer が GNN（グラフニューラルネットワーク）で連鎖アラームから根本原因を特定 → Actuation Orchestrator がバックアップルートへ切り替え → 障害機器の交換チケットを自動発行

デモ③: 予測ベースのネットワーク最適化

MWC のような大規模イベント時に、トラフィックが平常時の 3 倍以上に集中するシナリオです。Amazon SageMaker AI の予測モデルが過去データから需要急増を予測し、3 つの最適化戦略を自動で立案します。人が戦略を選択した後にエージェントが実行する Human in the Loop の設計が印象的でした。

このブースの中心的なメッセージは「AI エージェントが分析・実行を担うことで、人は戦略的な意思決定に集中できる」という点でした。実際の通信事業者の機器を想定したハイブリッド構成で、現実的な適用イメージを持たせてくれるブースでした。

この事例を AIOps の観点で見ると、エージェントの数が多いことよりも、役割と責任が分かれていることのほうが重要に思えました。

2 つの事例から見える AIOps アーキテクチャのパターン

2 つの事例を比べてみると、いくつかの共通した構造が見えてきます。この章では、それをもとに、AIOps を検討する際に参考になりそうなアーキテクチャのパターンを整理してみます。

1. エージェントに任せる判断から必要なデータを逆算する

AIOps を考えるうえで重要なのは、単に多くのデータを集めることではなく、まず「どの判断をエージェントに任せたいのか」を定義することだと思います。任せたい判断が決まると、その判断に必要なデータも逆算できます。

事例 1 では、レイテンシの原因分析を行うために、CDN、オリジン接続、アプリケーション内部処理のどこで時間がかかっているのかを比較できる情報が必要になります。Server-Timing は、そのための入力を 1 つの形にまとめる手段として見ることができます。

事例 2 でも同じ構造が見られます。ネットワーク障害の原因や影響範囲を判断するには、アラーム、KPI、トポロジー、過去インシデント、運用ドキュメントを関連づけて参照できる必要があります。つまり、データ統合の目的は単なる蓄積ではなく、判断に必要な情報を種類や出所ごとに切り分け、エージェントに渡す入力を明確にすることにあります。

エージェントにとって良いデータとは、量が多いデータではなく、任せたい判断に対して必要な情報が必要な形式でそろっているデータだと言えます。

2. 問題を役割と責任の単位で分解する

2 つの事例とも、単一の AI がすべてを処理するのではなく、役割ごとに特化したサブエージェントを組み合わせる構造を取っていました。

事例 2 では、次のようにエージェントが分担します。

エージェント 主な役割 分離する意味
Network Observer 全体の監視・指揮 監視と判断の起点を明確にする
Data Harmonizer データの正規化 後続の判断に必要な入力をそろえる
Root Cause Analyzer 根本原因の分析 原因特定の判断を独立させる
Actuation Orchestrator 復旧アクションの実行 実行権限を分析とは分離する
Customer Impact Analyzer 顧客影響の評価 技術的影響と顧客影響を分けて扱う
Communication Manager 顧客通知のドラフト作成 外部向けコミュニケーションを分離する

事例 1 は、事例 2 のような明示的なサブエージェント構成ではないものの、観測データを集める部分と、それをもとに分析・提案を行う部分が分かれていました。CloudWatch Alarm が異常を検知すると Lambda が Webhook をトリガーし、DevOps Agent が Server-Timing 情報を参照して原因分析や改善提案を行います。

エージェントを役割ごとに分離すると、各エージェントのコンテキストが狭まって判断基準を整理しやすくなり、特定のエージェントだけを差し替え・改善することも容易になります。

さらに、役割が分かれるとエージェントごとに必要な権限も区別しやすくなります。参照だけを行うエージェントと、インフラ構成を変更するエージェントに同じ権限を与える理由はありません。つまり役割と責任の単位での分解は、エージェントごとに認可（権限）の境界を明示的に引けるようにしてくれます。これは後で扱う、ブラスト半径（影響範囲）に応じた権限の細分化の出発点になります。

3. AI モデルが判断できる単位まで問題を分解する

Summit で AIOps を振り返るなかで、1 つの問いが浮かびました。ドメインに最適化していない汎用 LLM で、どうやって自分たちの問題に対応できるのか、という問いです。

これに対する答えは、モデル側よりもアーキテクチャ側に近いように見えました。「通信ネットワーク全体を自律的に運用せよ」という要求を汎用モデルにまるごと投げると、一度に入れなければならないコンテキストが膨大になります。コンテキストが大きくなるほど、モデルは肝心な情報に集中しにくくなり、トークン消費も増えていきます。

逆に問題を細かく切り分けていくと、あるところで「この連鎖アラームのうち、主原因と二次被害を区別せよ」「この顧客の SLA 等級と売上規模は何か」といった、汎用モデルが必要最小限のコンテキストだけで解ける小さな単位の問題になります。

問題を小さくする具体的な方法こそが、前の 2 つの節で見たデータの正規化と役割の分離です。データを参照する観点ごとに切り分けておき、役割ごとにエージェントを分けると、各段階でモデルが一度に抱える必要のあるコンテキストはその分だけ小さくなります。

ここにもう 1 つの原則を加えてみることができます。LLM にすべての生データを読ませない、という原則です。すべてのログとドキュメントを 1 か所に入れ、障害が起きたらエージェントに全部探せ、というやり方は一見シンプルに見えます。しかし、現在のアラーム状態、特定の時間帯の KPI、顧客の SLA 等級といった値は、モデルが推測する対象というよりも、システムが正確に返すべき値に近いものです。

特定の時間帯の数値や特定のアラームの状態のように、決定論的に照会すべき事実までモデルの推論に任せると、コンテキストが大きくなり、答えも不安定になりかねません。事実の照会と集計はデータベースや検索システムのような決定論的なツールに任せ、LLM はその結果をもとに、原因の解釈、影響の判断、対応案の作成といった推論が必要な部分に集中するほうが安定する、と考えています。

結局のところ、モデルを自分たちのドメイン全体に無理やり合わせるのではなく、問題をモデルが安定して解ける大きさまで分解していくこと。こうした方向で AIOps アーキテクチャを設計してみることができるのではないかと思います。

4. 実行を任せるときはブラスト半径を設計する

2 つのブースに共通して見られたのは、エージェントが実行に関与するほど、権限の境界を明確に設計する必要があるという点でした。

事例 1 の DevOps Agent は Read-only 設計を原則とし、改善計画を「提案」して、実行は人間が承認します。事例 2 の予測最適化のデモでも、3 つの戦略をエージェントが提示し、人が 1 つを選択してから初めてエージェントが実行に入る、という流れでした。

ただし、すべての行動に人がいちいち承認のハンコを押さなければならないとしたら、エージェントの自律性は意味を失います。そこで重要になるのが、各行動のブラスト半径をまず把握することです。どの操作がどこまで影響を及ぼすのか、間違えたときに元に戻せるのか — この影響範囲を把握して初めて、何をエージェントに任せ、何を人が握っておくべきかの線を引けます。

結局のところ重要なのは、リスクの大きさごとに権限を細分化してエージェントに付与するという観点です。

ブラスト半径 対応方針 例
小さい エージェントが自律的に実行 読み取り専用の照会、メトリクス収集、一時的なアラームクリアなど
大きい 人の承認を経る（Human in the Loop） インフラ構成の変更、外部顧客への通知、元に戻しにくい操作

「自律か制御か」という二分法ではなく、行動のリスクの大きさに応じて権限を細かく分けて適用すること — これがエージェントを安全に運用しながら自律性のメリットも活かす、現実的な設計だと考えています。

5. リアクティブから予測型へ進むには？

2 つの事例とも、現在のアラーム・障害対応（リアクティブ）を超えて、問題が起きる前にエージェントが手を打つ予測型の運用を目標にしていました。では、リアクティブな AIOps を予測型へ発展させるには何が必要でしょうか。

過去データの蓄積が前提

予測モデルは過去のパターンから学習します。事例 2 で SageMaker AI がトラフィックの急増を予測できたのは、Timestream に蓄積された KPI 時系列データや DynamoDB のインシデント履歴があったからです。事例 1 で CloudWatch RUM に Server-Timing メトリクスを蓄積し続けるのも同じ文脈です。「今、何が起きているか」を測定することが、「これから何が起きるか」を予測するための土台になるでしょう。

異常を異常と判断するためのベースライン

予測とは結局「平常時と異なるパターンを早期に検知すること」です。そのためには、平常時がどのような状態なのかをエージェントが知っている必要があります。データが蓄積されると、パーセンタイル統計などを使って平常時のベースラインを定義し、その基準からの乖離を機械的に検出できるようになります。これにより、異常の有無そのものを LLM の判断に委ねるのではなく、統計的な手段で検知した結果をエージェントの入力として扱うことができます。

リアクティブな運用の記録が予測精度を高める

興味深いのは、リアクティブな運用をきちんと行うこと自体が予測型への道だ、という点です。どのアラームがどんな原因で発生したのか、どんな対応をして結果はどうだったのかをインシデント履歴として積み上げていけば、エージェントはそのパターンを活用できます。事例 2 の Bedrock Knowledge Bases が過去のインシデントレポートを RAG で参照できるようにしたことや、DevOps Agent の Prevention 機能が過去のインシデントを横断的に分析して改善提案を生成することは、その良い例です。

要するに、いますぐ予測型を目指すよりも、まず「測定し、記録し、エージェントが参照できるようにする」というリアクティブな運用の基盤を整えることが、予測型 AIOps へ進むための現実的な出発点だと考えています。

まとめ

今回の AWS Summit Japan 2026 の 2 つの事例を通じて見た AIOps の要点は、エージェントそのものよりも、エージェントが判断し行動できる基盤をどう設計するかにありました。

Server-Timing の事例では、まず観測可能なデータをつくり、それを CloudWatch RUM と DevOps Agent につなげることで、障害の原因分析の出発点を整えました。通信ネットワーク運用の事例では、複数のデータソースを正規化し、役割別のエージェントで問題を分解することで、複雑な運用業務を段階的に処理する構造を見せてくれました。

2 つの事例で共通して確認できたのは、次の 3 つでした。

  • エージェントが参照できるようにデータを正規化し、蓄積すること
  • 大きな運用の問題を、モデルが判断できる小さな単位に分解すること
  • 実行を任せるときは、行動のリスクとブラスト半径に応じて権限を細分化すること

AIOps は、単に AI エージェントを導入したからといってすぐ実現されるものではないように思います。まず測定し、記録し、整理し、権限の境界を設計するプロセスが必要に見えます。その基盤の上にエージェントを載せたとき、初めて安全で実用的な自動化に近づけるはずです。

今後 AIOps を検討する際は、「どの AI を使うか」よりも先に、次の順序で現在の運用基盤を点検するのが現実的だと考えています。

  1. 運用に必要なデータはどこにあるのか
  2. そのデータはエージェントが照会可能な形に整理されているか
  3. どの判断をモデルに任せ、どの事実照会をシステムに任せるか
  4. どの対処を自動実行し、どの対処を人の承認を経るか
  5. 対応の結果を次の判断に使えるよう適切な形式で記録しているか

実際の運用に適用するには、権限設計、ロールバック手順、監査ログ、コスト管理といった追加の検討も欠かせません。 今回の 2 つの事例は、その前段階として、AIOps を考える際にどのようなアーキテクチャ上の論点を押さえるべきかを整理する手がかりになったと思います。