クイックダウンロード
ITOps における AI 自動化は、実行によって意思決定のコンテキストが失われ、コンテキスト グラフによってインシデント履歴がシステムが実際に再利用できる耐久性のある実行メモリに変換されるため、失敗します。
ほとんどのITOpsシステムは記録します 何 措置は取られたが、 現在も将来も、 —決定を形作ったシグナル、制約、承認、失敗したパスを破棄します。
同様のインシデントが再発すると、自動化とエージェントはゼロから開始し、調査を繰り返し、失敗した修復を再試行し、人間がすでに理解している問題をエスカレーションします。
実行履歴を第一級データとして扱うと、このギャップが明らかになり、意思決定のコンテキストが保持されていないとスケールが失敗することが明らかになります。
ITOps の AI 自動化は、実行内容を記憶していても、その理由を記憶していないために失敗します。
問題の解決は、前回何が試されたか、何が失敗し、何がうまくいったか、どの例外が承認されたか、そしてどのような条件下で行われたかによって決まります。こうした情報はシステムに保存されることはほとんどありません。チケット、Slackのスレッド、エスカレーションコール、そして人々の頭の中に眠っているのです。
ほとんどの自動化は、サービスの再起動、アラートの抑制、インシデントのエスカレーションといった結果のみを記録します。その結果に至った意思決定のコンテキストは失われます。同様の問題が再び発生した場合、システムは以前の対応方法を記憶していません。
エージェント型ITOps この問題を可視化します。エージェントは、問題を検出し、原因を調査し、複数のステップにわたって対処することが期待されています。過去の決定や例外情報にアクセスできない場合、エージェントは失敗したアクションを繰り返したり、早期にエスカレーションしたり、コンテキストを手動で再構築する人間に委ねたりしてしまいます。
コンテキストグラフは、意思決定履歴をデータとして扱うことでこの問題を解決します。コンテキストグラフは、どのようなシグナルが見られ、どのようなアクションが実行され、どのような承認が与えられ、そしてなぜその選択が行われたかを記録します。この履歴が蓄積されることで、自動化は最初からやり直す必要がなくなり、過去の実行に基づいて構築を開始します。
コンテキストグラフとは何か（そしてそうでないもの） コンテキストグラフとは、時間の経過とともにどのように意思決定が行われたかを記録するものです。より具体的には、システムがアクションを実行するたびに更新されます。アラート、調査手順、修復の試み、そして結果は、インシデント記録の一部として追加されます。
グラフが便利なのは、記録が整理されている点です。グラフには、問題が発生する前に何が起こったか、どのような対策が講じられたか、どれが失敗し、どれが成功したか、そしてどのような状況でそれらの結果が生じたかが示されます。最終結果だけを保存するのではなく、そこに至るまでの一連の意思決定も記録されます。
これがコンテキストグラフを他のシステムと異なるものにしているのです。
モデルの思考の連鎖。 内部推論トレースは一時的なものであり、モデル固有のものです。実行後には消えてしまい、クエリ、再利用、監査を行うことはできません。静的なナレッジグラフ。 ナレッジ グラフはエンティティ間の関係を示しますが、特定の状況で特定の決定がどのように行われたか、またはその決定が次に起こったことにどのような影響を与えたかは記録しません。シンプルな検索レイヤー。 RAGシステムは、参照用に作成された文書や事実を抽出します。実行履歴や意思決定の系統は記録しません。 コンテキスト グラフは、別の質問に答えるために存在します。 前回何が起こりましたか、そしてなぜですか?
ITOpsでは、これにより実行履歴が利用可能なコンテキストに変換されます。インシデントは単発のイベントとして扱われなくなり、自動化はリセットされなくなります。エージェントはゼロから始めるのではなく、前例を参照できるようになります。時間の経過とともにシステムはメモリを獲得し、過去の実行内容を記憶することで自動化が向上します。
ITOpsにおけるコンテキストグラフと従来のRAGの比較 コンテキスト グラフは、検索強化生成と混同されることがよくありますが、異なる運用上のニーズに対応します。
RAG システムは次の質問に答えます: 私たちは何を知っているでしょうか? 現在のクエリに関連するドキュメント、ランブック、チケット、ナレッジベースの記事を取得します。ITOpsでは、手順、構成の詳細、または類似の問題の履歴を明らかにするのに役立ちます。
コンテキスト グラフは別の質問に答えます。 前回同様の状況で何が起こりましたか? 静的な情報を返すのではなく、過去の実行履歴を可視化します。どのようなシグナルが存在し、どのようなアクションが実行され、どのアクションが失敗し、どのアクションが解決に至ったのか、そしてその結果を形作った条件も示します。
両者の違いは機能的なものです。RAGは参照用に書かれた知識を取得します。コンテキストグラフは実行を通じて生成された前例を取得します。RAGは一般的に何をすべきかを説明します。一方は実際に何が、いつ、なぜうまくいったかを示します。
ITOpsにおいては、この違いが重要です。ドキュメントでは、エッジケース、例外、あるいは実際のインシデント発生時に行われたトレードオフはほとんど記録されません。前例がそれを証明します。自動化とエージェントがアクションを選択する際に最も有用な情報は、汎用的なランブックではなく、過去に同様の状況がどのように処理されたかを示す証拠です。
RAGはサポートレイヤーとして依然として価値があります。システムが自律的に動作することが期待される場合、コンテキストグラフは静的なガイダンスではなく運用履歴に基づいて意思決定を行うため、決定的な役割を果たします。
ITOpsにおける欠けているリンク ITOpsは、実行が既にシーケンスで行われているため、コンテキストグラフに最適です。可観測性プラットフォームは状況を検知し、シグナルを表面化させます。自動化プラットフォームはアクションを実行します。欠けているのは、これらのステップ間の連続性です。たとえシステムが既に検知、調査、または修正を試みたことのある問題に酷似していても、各インシデントは新たな問題として扱われます。
相関関係に過去の根拠がないため、アラートが急増します。以前の仮説や行き詰まりが維持されないため、調査は最初からやり直しになります。自動化システムでは、類似の状況で何が失敗したかの記録がないため、同じアクションを再試行します。時系列で状況を再構築できるのは人間だけであるため、エスカレーションが増加します。
ほとんどのITOpsシステムは記録します それ アラートが抑制されたり、サービスが再起動されたり、インシデントがエスカレートされたりしたが、 現在も将来も、 どのようなアクションが選択されたか、あるいはどのような代替案が除外されたか。その理由はダッシュボード、チケット、チャットスレッド、あるいはエスカレーションコールに一時的に残りますが、実行が完了すると消えてしまいます。
意思決定のコンテキストが保持されていないと、自動化は一般化できません。各アクションは独立しており、それが効果的かリスクがあるかを説明する過去の試みとは切り離されています。エージェントも同じ制限に直面します。システムの現在の状態を観察することはできますが、類似の状況が以前にどのように処理されたか、あるいはどの制約が実際に重要だったかを把握することはできません。
人間は、失われた記憶層の役割を担うことでそれを補います。過去の出来事を思い出し、パターンを認識し、既知の失敗の繰り返しを回避します。しかし、その知識が自動化やエージェントが再利用できる形でシステムに戻ってくることは稀です。
コンテキストグラフの仕組み：レイテンシスパイクの例 ITOpsでは、あらゆる問題を解決するための原材料は既に存在します。メトリクス、イベント、ログ、トレース、トポロジ、チケット、ランブック、自動化ツールなどです。欠けているのは、意思決定時にこれらの入力がどのように組み合わされ、その結果何が起こったかを記録するシステムです。コンテキストグラフは、実行をデータソースとして扱うことで形成されます。
一般的な ITOps シナリオ、つまりアプリケーションのレイテンシに関連したアラートのバーストについて考えてみましょう。
検出と相関関係の検討中 エージェントはアラートストリームを新たなシグナルとして扱いません。コンテキストグラフを照会し、類似した特性を持つ過去のインシデント（影響を受けたサービス、時間帯、最近の変更、依存関係のパターンなど）を検索します。これらの関連性は、時間枠、トリガー条件、そして過去に発生したインシデントとともにグラフに書き込まれます。指標のみに基づいて相関分析するのではなく、アラートを過去のコンテキストに紐付けることで、調査開始前に調査範囲を絞り込みます。グラフは、発生している事象だけでなく、システムがそれをどのように解釈したかを反映します。
調査中 グラフは拡大し、類似事例における過去の出来事が浮かび上がります。最近のデプロイメント、構成変更、失敗した修復の試み、そして既知の行き詰まりなどがすべて表示されます。エージェントは、どの仮説が以前にテストされ、どの仮説が除外されたかを把握できるため、冗長なチェックを減らし、考えられる原因への経路を短縮できます。各仮説と、それを検証するために実行されたすべてのアクションが記録されます。失敗したチェック、誤った手がかり、そして除外された原因は、成功したものと共に保存されます。つまり、将来の意思決定において、否定的なシグナルは肯定的な解決策と同じくらい重要なのです。
修復のため エージェントは過去の結果に基づいてランブックを選択または生成します。同様の状況で成功したアクションは優先されます。以前に失敗したアクションやエスカレーションが必要だったアクションは、優先順位が下げられるか、ゲートされます。その選択は、それを正当化したコンテキストとともに記録されます。アクションが成功した場合、グラフは修復とそれが機能した状況を関連付けます。アクションが失敗またはエスカレーションが必要になった場合は、その結果も記録され、オーバーライドやポリシーからの逸脱を承認した人物も記録されます。
アクションが完了すると、結果がグラフに書き戻されます。修復によって問題が解決されたか、部分的に軽減されたか、あるいは完全に失敗したかは、発生条件とともに実行記録に記録されます。承認、オーバーライド、例外も記録されます。
するとフィードバック ループが複雑化します。 次回同様のインシデントが発生した場合、エージェントはゼロから始めるのではなく、グラフを参照して類似の状況、過去の行動、観測された結果を照会します。修復パスは、静的なルールではなく、前例に基づいて選択されます。時間の経過とともに、頻繁に繰り返される決定はより高い自律性を持つ候補となり、まれなケースやリスクの高いケースはゲートされたままになります。
重要なのは、実行中にグラフが継続的に更新されることです。これはレポート用のアーティファクトやオフライン分析ツールではありません。実行パスに常駐し、意思決定前のコンテキストを読み取り、意思決定後に結果を書き込みます。調査が答えに近いところから開始されるため、平均解決時間は短縮されます。前例との相関関係が向上するため、アラートノイズは減少します。自動化は事後対応的ではなく選択的になり、履歴が裏付ける場合は自信を持って行動し、不確実性が残る場合はエスカレーションを行います。
Edwin AI: 生産 ITOps におけるコンテキスト グラフ Edwin AIは、エージェントと自動化の基盤となるITOpsコンテキストグラフを通じて、このアプローチを実践します。この設計は、シンプルな制約から始まります。ITOpsでは、実行は一度きりではありません。アラート、インシデント、調査、そして修復といった、時間とインフラが重なり合う複数のステップをまたいで、継続的に実行されます。各ステップを独立したものとして扱うと、すぐに破綻してしまいます。
Edwin AIの中核は、エージェントと自動化の基盤となるITOpsコンテキストグラフです。このグラフはレポートレイヤーでも静的なナレッジストアでもありません。可観測性シグナル、トポロジ、インシデント、アクション、そして発生した結果を結び付ける実行記録です。
問題が表面化しても、Edwin AI は白紙の状態から始めるわけではありません。受信したメトリクス、イベント、ログ、トレースをサービストポロジーや過去のインシデントと相関させます。その相関関係はグラフに書き込まれ、現在何が起こっているかだけでなく、システムが過去に同様の状況をどのように解釈したかを把握します。
調査中、Edwin AIのエージェントはグラフに対して過去の実行履歴を照会します。類似の状況下で特定された根本原因、試行された修復パス、そして成功または失敗したパスなどです。失敗したパスは成功したパスと並べて保存されるため、重複を防ぎ、時間の経過とともに検索範囲を絞り込むことができます。これにより、調査は再発見ではなく、過去の事例に基づいて進めることができます。
修復も同様に処理されます。Edwin AIは、次のような自動化プラットフォームと統合されています。 Red Hat Ansible 静的マッピングではなく、実行履歴に基づいてランブックを選択または生成します。アクションは、類似の条件下で以前に動作したために選択されるか、動作しなかったために明示的に回避されます。ポリシーのチェック、承認、オーバーライドは、帯域外で処理されるのではなく、実行記録の一部として記録されます。
重要なのは、結果がグラフに反映されることです。あるアクションによって問題が解決されたか、影響が軽減されたか、あるいはエスカレーションが必要だったかは、システムの記憶に残ります。時間の経過とともに、このフィードバックループは複雑化します。相関関係が改善されるにつれて、アラートのノイズは減少します。調査が答えに近づくにつれて、MTTRは短縮されます。自動化は選択的になり、前例がある場合は自信を持って行動し、リスクが残る場合は延期します。
ここでの価値は、Edwin AIが意思決定のコンテキストを第一級の状態として保持することです。この永続性により、エージェントはより適切なプロンプトを用いて同じ作業を繰り返すのではなく、実行ごとに改善していくことができます。
Edwin AIは、コンテキストグラフを分析アーティファクトではなく実行インフラストラクチャとして扱った場合の実際の様子を実証します。エージェントはグラフに基づいて推論を行い、オートメーションはそれに基づいて実行します。システムは実行によって痕跡が残るため、学習します。
コンテキストグラフは自律性を実際に拡張する方法です コンテキストグラフにより、エージェントは日常的なインシデントとエッジケース、安全なアクションと危険なアクション、自律性が求められる状況と人間の判断が求められる状況を区別できるようになります。自動化は網羅的ではなく選択的になり、履歴が裏付ける場合には確信度を適用し、不確実性が残る場合には抑制を適用します。
ルールを追加しても自律性は向上しません。プロンプトを追加しても信頼性は向上しません。自律性は、システムが実行コンテキストを時間の経過とともに保持し適用することで向上します。
コンテキストグラフはその基盤を提供します。コンテキストグラフは可観測性と自動化の中間に位置し、蓄積された経験を通じてシグナルをアクションに結び付けます。長期にわたるエージェントワークフローが一般的になるにつれて、このレイヤーは自動化が脆弱なままでいるか、それとも適応的になるかを決定します。
ITOpsにおいては、その違いは解決の高速化、ノイズの低減、そして繰り返し発生する障害の減少に現れます。さらに重要なのは、AIシステムが孤立した応答を超えて、継続的に改善する実行エンジンとして機能できるかどうかです。
Edwin AI を使用して、ITOps 自動化によってチームをリアクティブからプロアクティブにシフトする方法をご覧ください。
LogicMonitorでEdwin AIのコンテンツ戦略を率いるMargo Poda氏。エンタープライズテクノロジーとAIスタートアップの両方での経験を持つ彼女は、複雑なトピックを明確かつ関連性が高く、読む価値のあるものにすることに注力しています。特に、似たようなコンテンツが溢れている分野において、その重要性は増しています。彼女はAIを誇大宣伝するためではなく、AIが実際に何ができるのかを人々に理解してもらうためにここにいます。
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
