AIOpsはArtificial Intelligence for IT Operations、すなわちAIでIT運用データの分析と対応を支援するアプローチです。アラートをまとめ、原因候補を探したり、定められた処置を実行したりするのに活用できます。ただし、「異常に見える」「これが原因かもしれない」「今変更しても問題ない」はそれぞれ異なる判断です。
ショッピングモールのAPIが遅くなり、データベースの接続使用率も上昇したと仮定しましょう。AIがこれら二つを結びつけて説明することは有用ですが、その説明だけでDBを再起動したり、アプリケーションを無条件に増強したりすると、問題が拡大する可能性があります。必要なのは、観測を根拠と結びつけ、実行可能な処置を別途の承認・権限・復旧条件で制限する運用設計です。
本稿は、2026年10月15日に確認したAWSのAIOps説明とGoogle SREのモニタリング原則に基づき、その境界を整理します。ショッピングモールおよびすべての指標・時刻・設定は説明用の合成例であり、実際の導入経験や障害復旧実績ではありません。
代表画像：AI生成の概念図。実際のダッシュボードやサービス構成を再現したものではありません。
1. まず、観測、原因候補、実行決定を分ける
AWSはAIOpsを、複数のソースのデータを分析して運用効率を高めるアプローチと説明し、観測・専門家の判断と協力・処置という流れを紹介しています。機械学習や自然言語処理などを活用できるため、必ずしも対話型言語モデルを一つだけ組み込む方式を意味するわけではありません。AWS AIOps概要
運用に適用する際は、この流れを権限の異なる三段階として捉えるのが良いでしょう。第一段階は、今何が起こっているのかを集めることです。第二段階は、どの説明が観測を最もよく説明しているかを比較することです。第三段階は、その説明を根拠に実際のシステムを変更することです。
例えば、「商品検索のP95遅延が増加した」は観測です。P95は、リクエスト遅延を小さい順に並べたときのおよそ95%地点の値で、遅い側のリクエストの状態を見る指標です。「DB接続競合が遅延に関与した可能性がある」は原因候補です。「直前の変更を元に戻す」は処置提案です。観測が正しくても候補が間違っている可能性があり、候補が正しくてもその処置が安全であるという結論は別途確認する必要があります。
既存のOTelとLGTMの記事がデータをどのように繋げて見るかを説明したとすれば、ここでは繋げて見た情報をどのような根拠で行動に繋げるかに焦点を当てます。収集構造を再構築するよりも、判断が移行する地点を明確にすることが出発点です。
図1. 観測・候補検討・処置を権限の異なる段階に区分した概念図。AWS AIOps概要とGoogle SREモニタリングなどの公式文書に基づいて再構成しました。原因候補が自動的に実行承認されるわけではありません。
2. ログ・メトリック・トレースはそれぞれ異なる質問に答える
ログは特定の時点の事象、メトリックは一定期間の数値と分布、トレースはリクエストが複数の処理段階を経る経路を示します。これら三つのデータを一緒に見ると、同じ時間帯の変化がどのリクエストと構成要素に繋がっているかを絞り込むことができます。しかし、データごとに集計時間、標本範囲、記録の欠落が異なります。
架空の商品検索APIで以下の変化が観測されたと仮定します。各数値は同じ長さの比較区間を対象に作成されており、特定のサービスの推奨しきい値を意味するものではありません。
| 確認項目 | 以前の区間 | 遅延が増加した区間 | 次の質問 |
|---|---|---|---|
| 成功リクエストP95遅延 | 180ms | 900ms | どの経路とデプロイバージョンで増加したか？ |
| 外部APIリクエスト量 | 秒間300件 | 秒間310件 | ユーザー需要だけで変化を説明できるか？ |
| DB接続使用率 | 45% | 90% | 接続の上限・測定対象は同じか？ |
| 接続取得待機 | ほぼなし | 待機増加 | どのアプリインスタンスで待機しているか？ |
| DB CPU使用率 | 35% | 40% | CPU以外にロック・I/O・接続制約があるか？ |
| 変更履歴 | リトライ1回設定 | リトライ3回設定デプロイ | その経路のDB呼び出し試行が増加したか？ |
DB接続使用率は、分母が何であるかを確認する必要があります。DBサーバーの許容接続数を基準とした値なのか、アプリケーション接続プールの上限を基準とした値なのかによって意味が異なります。サービス全体の平均だけを見ると、特定のインスタンスの待機を見落とす可能性もあります。
この例では、トレースは商品検索が接続を待機する区間とクエリを実行する区間を分けて見るために使用します。ログでは、同じデプロイバージョンのリトライ・接続待機関連の事象を探します。モデルに実際の生ログを丸ごと送るのではなく、識別情報を除去した集計と必要な区間のみを提供するようにデータ範囲を定めます。
Google SREは、ユーザー視点での遅延・トラフィック・エラー・飽和度を重要なシグナルとして提示しています。平均遅延だけを見るのではなく、成功と失敗リクエストの遅延を区別し、リソースがどれだけ埋まっているかも一緒に見るべきです。症状と原因の区別
合成例では、可能な説明は複数あります。リトライ増加がDBリクエスト量を増やした可能性もあれば、長いトランザクションが接続を長く占有した可能性もあります。接続返却の問題やネットワーク遅延が同時に発生している可能性もあります。DB CPUが大きく上昇しなかったという観測は、CPU不足の説明を弱めるだけであり、DB全体が正常であるという証拠ではありません。
AIには、結論の一行よりも候補ごとの根拠を整理させる方が有用です。例えば、次のように要求できます。以下の文章は合成データを分析するための作成例であり、実際の運用ツールに実行権限を与える指示ではありません。
제공한 합성 지표와 변경 이력만 사용해 원인 후보를 정리해 주세요.
각 후보마다 지지하는 관측, 아직 없는 근거, 반대 근거,
추가로 읽기 전용 확인할 항목을 구분해 주세요.
상관관계를 원인 확정으로 쓰지 말고 확인되지 않은 값은 만들지 마세요.
설정 변경이나 재시작은 실행하지 말고 별도 조치 제안으로만 남겨 주세요.リトライ候補であれば、同じ時間帯にそのコード経路のDB呼び出し試行が実際に増加したかを確認できます。長いトランザクション候補であれば、ロック待機やトランザクション継続時間など、他の観測が必要です。どの資料でどの候補を絞り込むかを記録すれば、AIの説明を人が検討しやすくなります。
モデルが付与した高い確信度も、それ自体が検証結果ではありません。必要な指標が欠落している状況では、文章が断定的に見えることがあります。根拠が不足している場合は、実行レベルを高めるのではなく、追加観測や担当者レビューに移行するように設計します。
4. 変更履歴は同じ時間軸に置き、範囲まで合わせる
変更直後に障害が始まったという事実は重要な手がかりです。ただし、最近のデプロイであるという理由だけで原因と断定することはできません。デプロイ時刻と指標収集時刻が異なる場合があり、段階的デプロイ中は新バージョンと旧バージョンが同時に動作することもあります。
合成例では、リトライ設定が変更されたバージョンのリクエストのみを分離して確認します。同じAPIの他の経路でも遅延が発生したか、変更を受けていないインスタンスでも接続待機が増加したかを比較します。需要増加やDBメンテナンスのように、同じ時刻に重なった変化があるかも確認します。
変更履歴をAIに伝える際も、「今日デプロイがあった」よりも対象サービス・バージョン・設定項目・適用範囲を具体的に伝える必要があります。どの観測が変更前後を指しているのか、時刻と集計区間が合っているかを確認しないと、異なる事象を一つの話にまとめてしまう可能性があります。
運用要約には、事実と解釈を分けて記載します。「新バージョン区間で接続待機が増加した」は確認された比較結果であり、「リトライ増加が影響を与えた可能性がある」は解釈です。検討が終わっていない候補がレポートを経て確定原因に変わらないように、この区分を維持します。
5. 自動処置には対象・条件・制限を付与する
以下は、公式文書の運用・権限原則をこの例に適用した設計提案です。特定のAIOps製品がこれらすべての機能を自動的に提供するという意味ではありません。読み取り専用の要約、変更案の作成、制限された実行をそれぞれ異なる機能として分け、それぞれの許容範囲を定めます。
例えば、接続待機が増加したという理由でアプリインスタンスを継続的に追加すると、各インスタンスが作成する接続によってDBの負荷が増大する可能性があります。「拡張」という処置名よりも、変更する対象、一度の変更幅、全体の接続予算、そして次の判断まで待つ時間を一緒に定める必要があります。
許可された作業も同じ対象に重複して実行される可能性があります。一つの障害に複数のアラートがまとめられたり、リトライが続いたりする際に、同じ設定変更を繰り返さないように実行IDと進行状態を確認する必要があります。中間失敗後にリトライする際は、既に変更された状態をまず読み取ります。
権限は、このような条件を実際に制限できる実行階層に置きます。モデルが自由に作成したシェルコマンドを管理者権限で実行するよりも、検討済みの作業手順に許可された入力のみを渡すように設計できます。AWS IAMも、作業に必要な動作・リソース・条件で権限を絞る最小権限の原則を説明しています。IAMセキュリティの推奨事項
レビュー記録を読み取る役割とサービスを変更する役割も分離します。要約機能が原因候補を提示できるからといって、DB設定変更やアカウント権限修正まで実行する理由はありません。読み取れるデータと変更できるリソースをそれぞれ定義する必要があります。
6. 承認は処置内容に紐付け、実行直前に再度確認する
人が承認するという言葉だけで実行境界が完成するわけではありません。「問題を解決してもよい」という広範な承認は、対象や方法が変わっても有効であると誤解される可能性があります。承認画面には、対象バージョンとリソース、変更前後の値、予想される影響、確認根拠、復旧方法を表示する方が良いでしょう。
承認はその変更案のバージョンに紐付けます。承認後に対象やパラメータが変更されたり、根拠が古くなったりした場合は、新たに検討する必要があります。待機中に他の運用者が既に処置している可能性もあるため、実行直前に現在の状態と進行中の変更も確認します。
AWS Systems Manager Automationのaws:approveは、指定した承認主体の応答を待つ段階を作業手順に含めることができる事例です。このような承認段階があるからといって、原因判断や実行権限検証まで自動的に正確になるわけではありません。承認・ポリシー検査・実行ロールの権限はそれぞれ確認する必要があります。Automation承認アクション
図2. 承認された変更案と実行前の状態確認、制限された実行、結果観測を連結した運用設計。Automation承認ドキュメント、IAM権限原則、AWSデプロイリスク軽減などの公式文書に基づいて再構成しました。未承認・状態不一致・観測不可の状況では実行を保留します。
7. 成功基準とロールバック基準は変更前に定める
処置の成功は、コマンドがエラーなく終了したという事実とは異なります。合成例でリトライ設定を以前の値に戻す変更案を検討する場合、商品検索の遅延とエラー率、DB接続待機・使用率を一緒に観測する計画が必要です。遅延だけが減ってエラーが増加した場合は、望ましい結果とは言えません。
判定区間と最小リクエスト量も事前に定める必要があります。変更直後の短い静かな区間だけを見たり、リクエストがほとんどない区間を根拠に復旧を宣言したりしてはいけません。数値は該当サービスの負荷特性と目標に基づいて定め、本稿の例示数値を運用しきい値としてコピーしないでください。
ロールバックは以前の状態に戻す手順です。変更前の値と復旧可能なバージョンを確保し、どのような失敗シグナルで新しい処置を中断するかを定めておきます。AWS Well-Architectedも、変更結果の迅速なフィードバックと望ましくない結果からの回復、テスト・安全なデプロイ・ロールバックを一緒に扱っています。デプロイリスクの軽減
ただし、すべての行動を同じ方法で元に戻すことはできません。既に処理された注文、外部に送信されたメッセージやデータ変更は、設定ファイルを復旧するだけでは取り消されません。影響の大きい非可逆的な作業は、自動化範囲をさらに狭め、別途確認を設けるべきです。復旧中に観測自体が途切れた場合、追加の自動変更を繰り返すよりも担当者に引き継ぐ条件も必要です。
8. 導入順序は読み取り専用比較から始める
最初から自動復旧を目標とするよりも、過去に検討を終えた事象や合成状況でAIが何をまとめ、何を見落とすのかを調べることができます。原因候補に根拠が付いているか、無関係な変更を引き込んでいるか、知らない情報を知らないと表示しているかを確認します。
次に、AIが提案を作成し、既存の運用判断と比較する形で範囲を広げます。処置を評価する際は、候補を多く作成したという量よりも、不要な変更、誤検知対応、担当者レビューの負担、そして復旧可能な失敗であるかが重要です。効果を測定する資料がない場合、運用コスト削減や復旧時間短縮を実績として使用しないでください。
既存のエージェント安全装置試験は、実際のツール呼び出しを停止する境界の検証を扱いました。AIOpsでは、その境界の前に今この処置を選択する根拠が十分かという運用判断が追加されます。実行をうまく阻止するツールであっても、誤った処置選択まで代わりに解決してくれるわけではありません。
9. 任せる範囲はモデルの弁舌よりも運用契約で定める
AIOpsの価値は、散らばったシグナルをまとめ、人が確認する原因候補と根拠を整理するところから始まります。自動処置まで連結するには、根拠の範囲、対象・権限・制限、承認された変更案、結果判定と復旧方法が繋がっている必要があります。
ショッピングモールのAPIが遅く、DB接続が増加したという観測は出発点です。次の段階は、DBを再起動するコマンドを得ることではなく、どの候補をどの観測で絞り込み、どのような条件で何を変更できるかを決定することです。観測を信頼すること、原因を判断すること、変更を許可することを分けて管理するとき、自動化の範囲も説明できます。
参考文献
公式資料確認日：2026年10月15日。合成指標と運用設計例は、本稿の説明のために構成しました。
コメントを残す