クイックダウンロード
ITOps 自動化の将来は、AI エージェントが何を表示し、共有し、実行できるかをより適切に制御できるようになります。
-
エージェント権限が設計されるのではなく想定されると、自己修復ワークフローは機能しなくなります。
-
ITOps におけるガバナンスは、統合設計、アクセス スコープ、実行境界を通じて実装されます。
-
ポリシー、承認、およびチェックは、自律性の動作方法を決定するランタイム制御として機能します。
-
データ交換とエージェントの相互作用を制御することで、自動化によって操作が安定するか、障害が伝播するかが決まります。
ITOpsにおけるAI自動化は、インシデントの解決、運用負荷の軽減、そして人的介入を最小限に抑えた運用を実現することが期待されています。これらの成果は、表面的な洞察だけでなく、実際に行動に移せるシステムに依存します。
エージェント型AIは、その変化を可能にします。AIエージェントは、ツール間のシグナルを相関させ、チケットを更新し、修復をトリガーし、指示を待たずにワークフローを調整できます。実行はデータに近づき、継続的に行われます。
この変化は制御モデルを変化させます。以前の自動化では、人が行動を起こす前に状況を確認し、リスクを吸収することを前提としていました。しかし、現在では、エージェントシステムは意思決定をワークフローの中に組み込んでいます。エラーはもはや単一のステップで止まらず、次の段階へと持ち越されます。
ガバナンスによって、どこまで実行できるかが決まります。
ITOpsでは、アクセス境界、実行制約、エスカレーションしきい値を通じてガバナンスが強化されます。これらの制御によって、エージェントが利用できるデータ、変更できるシステム、そして介入が必要なタイミングが定義されます。
これらの制限がシステムに組み込まれている場合、エージェントによる自動化は限定されたままです。一方、これらの制限が暗黙的である場合、実行は制御よりも速く拡張されます。
自律性は失敗の表面を変える
以前の自動化は、限定された方法で失敗していました。スクリプトは決定論的に実行され、ルールは固定された条件を評価していました。何か問題が発生した場合、原因は通常ローカルであり、影響は自動化自体と同じ境界に沿っていました。
エージェントシステムは様々な制約の下で動作します。評価は コンテキスト固定された閾値ではなく、確率と信頼度に基づいて行動を選択します。複数のシステムと順番に相互作用し、行動しながら状態を継承します。
このモデルでは、障害は時間の経過とともに発生します。エージェントは不完全なテレメトリから推論を導き出し、それを相関するシステム全体に適用し、単独では有効に見える下流のアクションをトリガーする場合があります。各ステップは基本的なチェックを通過することができます。エラーは、シーケンス全体を観察した場合にのみ発生します。
この行動は、エージェントが利用する入力から生じます。履歴データには、ギャップ、バイアス、時代遅れの仮定など、過去の意思決定が埋め込まれています。APIは、人間のオペレーターや単一目的のツール向けに設計されたアクセスモデルに従って機能を公開します。エージェントがドメインをまたいで推論を行う際、検証されていない信号を組み合わせます。これが発生するには、システムに不具合がある必要はありません。制約が不十分なだけで十分です。
実行権限が内部に委譲されるにつれ、従来のガバナンスメカニズムは解決能力を失います。ロールベースのアクセス制御では、エージェントに必要な権限よりも広範な権限が付与されることがよくあります。承認ワークフローは人間の意図とタイミングを前提としていますが、これは継続的な実行とは一致しません。変更管理プロセスは、行動を起こす前に行動を形成するのではなく、事後に結果を追跡します。
その結果、自律性の運用方法と制御の適用方法の間に不一致が生じます。障害領域が拡大するのは、エージェントが行動するからではなく、その動作境界が暗黙的であるからです。エージェント型ITOpsでは、データが消費され、アクションがトリガーされ、システム間で制御が引き渡される時点で、これらの境界を明示的に設定することが、封じ込めの鍵となります。
ITOpsにおけるガバナンスは構造的である必要がある
AIガバナンスは、倫理、公平性、透明性といった観点から捉えられることが多い。これらの側面は、モデルレベルと組織レベルで関連性を持つ。しかし、自動修復によって本番環境のインフラが安全に修正されるかどうかは、これらの要素によって決まるわけではない。
ITOpsにおいて、ガバナンスは実行の仕組みの中に存在します。それは、統合の定義方法、権限のスコープ設定方法、そして意思決定パスの終了方法に深く関わっています。これらの選択は、ポリシー文書を参照するずっと前から、エージェントの行動を形作ります。
その重荷の大部分を担っているのが、次の 3 つのメカニズムです。
- 許可されるアクションとデータ アクセスを定義するポリシー。 ポリシーは実行に対する厳格な制約として機能します。エージェントがどのシステムから読み取り、どのシステムに書き込み、どのような条件下で実行できるかを決定します。実際には、これはプラットフォーム全体にわたるアクセスを許可するのではなく、特定の機能にスコープを制限することを意味します。スコープが適切に設定されていないポリシーは、システムに意図しない副作用をもたらします。スコープが適切に設定されたポリシーは、自律性を損なうことなく影響範囲を縮小します。
- 影響が大きいアクションや曖昧なアクションを禁止する承認。 承認は普遍的な要件ではありません。信頼性が低い場合、影響範囲が広い場合、またはコンプライアンス義務が適用される場合に適用される、対象を絞った制御です。エージェント型ワークフローでは、承認は実行の境界として機能します。システムが事前定義されたしきい値を超えた場合にのみ、一時停止を導入します。
- 実行前に入力、信頼性、およびスコープを検証するチェック。 チェックは実行時の安全策として機能します。入力が最新のものであること、推論されたアクションが信頼度しきい値を満たしていること、そして実行が定義されたスコープ内に留まっていることを検証します。これらの検証は、アクションの直前、つまりコンテキストが最も新しく、可逆性が最も高いときに実行されます。
これら3つのメカニズムは、統合層、実行エンジン、オーケストレーションロジックに存在します。これらが欠如している場合、負荷がかかった際に自律性が低下します。これらが明示的に定義されている場合、自律性は予測可能になり、大規模な環境でも繰り返し実行できるようになります。
AIエージェントの障害の多くは、不適切なデータアクセスや過剰なデータアクセスから始まる。
エージェントシステムは、観察可能なものに基づいて行動します。障害は、エージェントがどのように行動するように指示されるかではなく、データの公開、フィルタリング、および結合方法に起因して発生する傾向があります。
ITOpsデータソースは、人間による使用と限定的な統合を目的として設計されています。API、ログ、メトリクス、構成ストア、チケットシステムは、断続的なアクセスと外部からの判断を前提としています。権限は、摩擦を軽減するために広く設定されていることがよくあります。コンテキストはツール間に分散されており、監査証跡は人間の行動に焦点を当てる傾向があります。
エージェントが運用データを継続的に消費し、それに基づいて直接アクションを起こすようになると、アクセスと監視に関する従来の想定は適用されなくなります。データはもはや受動的な入力ではなく、実行のトリガーとなります。アクセスのスコープ設定、コンテキストの組み立て、インターフェースの定義方法が、本番環境でのアクションの展開を決定づけるようになります。
リスクはいくつかの繰り返しパターンとして現れます。
過剰な権限アクセスにより意図しない変更が可能になる
エージェントは与えられたインターフェースのスコープ全体を継承します。権限が粗い場合、エージェントは本来の権限範囲を超えてシステムを変更する可能性があります。この問題は、指示ではなく、能力に起因します。
不完全なコンテキストは実行を歪める
可観測性データは設計上、断片化されています。メトリクスには遅延が生じ、ログはサンプリングされます。構成データは特定の時点を反映しています。部分的な入力に基づいて動作するエージェントは、ギャップを埋めるために推論に依存します。これらの推論から導き出されたアクションは、下流にまで持続します。
管理が不十分なAPIはセキュリティとコンプライアンスの危険をもたらす
多くの運用APIは、きめ細かなスコープ設定、明示的な契約、あるいは読み取りパスと書き込みパスの明確な分離が欠如しています。エージェントがこれらのインターフェースに依存すると、不要なデータアクセスや不十分なトレーサビリティといった制限も引き継いでしまいます。
モデルの行動レベルで適用される制御は、リスクがシステムに入り込んだ後に対処します。効果的なガバナンスは、データが利用可能になり、実行が可能になる時点よりも早い段階で介入します。この境界によって、エージェントがどの程度のエラーを繰り越せるかが決まります。
エージェントとシステムの相互作用の制御層としてのモデルコンテキストプロトコル（MCP）
上述のリスクは、エージェントが推論から実行へと移行する特定のポイントに集中しています。その境界は統合によって定義されます。エージェントがツールやデータソースに接続する方法によって、監視、変更、伝播できる内容が決まります。
MCPは、ツール、入力、出力、権限の明示的な記述を要求することで、エージェントと外部システムの相互作用方法を標準化し、その境界を形式化します。曖昧に定義されたAPIを介した暗黙的なアクセスではなく、相互作用は契約によって制約されます。データパスは宣言され、実行パスはスコープ指定されます。読み取り操作と書き込み操作は、デフォルトでバンドルされるのではなく、分離できます。
これは、エージェントが定義上安全になるわけではありません。しかし、安全性が強制される領域は変化します。アクセスが統合の拡散によって推測されるのではなく、明示的かつ検査可能であるため、安全でない動作をブロックしやすくなります。
エージェント型ITOpsソリューションでは、MCPは統合制御レイヤーとして機能します。ITSMなどの外部システムへの接続は、包括的なアクセス権限を付与することなく行えます。エージェントはタスクに必要なデータのみを取得できます。更新は特定のフィールドまたはアクションに限定できます。出力は、下流のワークフローや変更をトリガーする前に検証できます。
その結果、事後的なレビューではなく、インターフェース設計を通じてガバナンスが強化されます。制御は、システムの外部にあるポリシー文書ではなく、データ交換と実行の仕組みの中に存在します。
MCPはまだ初期段階であり、大規模な本番環境のパターンは出現しつつあります。しかし、その根底にある原則は分散システムにおいて確立されています。明示的な契約は、システムに許可される動作を限定し、違反を観測可能にすることで、意図しない動作を削減します。
エージェントの調整は第二のガバナンス問題を引き起こす
エージェントシステムが拡大するにつれて、責任は分散化します。分析、修復、検証、エスカレーション、学習は、 個別のAIエージェント 単一のワークフローではなく、複数のワークフロー間の連携が必須となります。
この調整面は、明確なガバナンス問題を引き起こします。エージェントが完全なコンテキストや内部状態を共有すると、境界が崩壊します。あるエージェントの想定が別のエージェントの入力になります。エラーは実行時に止まらず、横方向に広がります。内部推論、メモリ、ツールアクセスが、意図された範囲を超えて漏洩します。
Agent2Agent（A2A）プロトコルは、エージェントが内部状態を公開することなく情報を交換する方法を標準化することで、このサーフェスを制約します。通信はタスク、結果、そして構造化されたコンテキストに限定されます。エージェントはメモリ、推論パス、独自のロジックを共有しません。連携中でも、各エージェントは独立したシステムであり続けます。
運用面では、このアプローチにより、エージェントは互いの内部的な前提やアクセスモデルを継承することなく、作業を委任したり、結果を検証したり、エスカレーションを開始したりできるようになります。これにより、調整は暗黙的で不透明なものではなく、明示的で検査可能なものになります。
人間の承認は依然として必要な制御である
エージェントシステムは、日常的な運用業務の大部分を担います。チケット処理、基本的な修復作業、トリアージといった業務において、もはや人間による継続的な介入は不要です。残るのは、自動化の実行を許可する場所と停止させる場所の責任です。
ITOpsにおいて、人間による承認は、アクションが広範囲にわたる影響、信頼性の不確実性、または規制リスクを伴う場合に重要です。これらは頻繁に発生するものではなく、定義された運用境界の境界付近で発生します。承認は実行に対する制約として機能するものであり、すべてのアクションに対するチェックポイントとして機能するものではありません。
これは役割の変化を反映しています。L1実行が自動化されたため、人間のオペレーターはポリシーの定義、しきい値の設定、結果の確認、そしてシステムの動作の経時的な調整に集中するようになりました。介入に代わって監視が主要な責任となります。
選択的エスカレーションはこのモデルをサポートします。エージェントはスコープ内で継続的に業務を遂行します。人間による入力は、実行が事前に定義された制限を超えた場合にのみ必要となります。承認は責任の委譲を示すものであり、手作業への復帰を意味するものではありません。
エージェント型 ITOps では、制御はすべてのステップを監視することからではなく、自律性がどこで停止するかを決定することから生まれます。
エージェントによる自動化が成功するか失敗するか
AIエージェントは、かつてL1チームやNOCチームが担っていた業務を既に担っています。トリアージ、エンリッチメント、基本的な修復、そして調整といった業務は、ソフトウェアに移行しつつあります。この変化は、明確なガバナンスモデルの導入の有無に関わらず、起こりつつあります。
結果を決定づけるのは、AIエージェントの権限がいかに意図的に定義されているかです。自己修復ワークフロー向けに構築された専用エージェントには、継続的なデータ交換とシステム間での連携能力が求められます。MCPとA2Aは、このデータ交換を明示的かつ調整可能にするために存在します。これらにより、チームはシステムにどのようなデータを入力するか、どのようなアクションを許可するか、そしてどの程度まで連携させるかを決定できます。これらの選択をエージェント自体にハードコーディングする必要はありません。
ここでガバナンスは、要件が変わるたびに強制的に書き直すことなく自動化を拡張できるメカニズムになります。
残された課題は、エージェント型ITOpsが実現可能であることを証明することではありません。どれだけの権限を付与するか、その権限をどこに限定するか、そしてその境界を時間の経過とともにどのように変化させるかを決定することです。
これが、エージェントを実行することと、エージェント システムを操作することの違いです。実行が解決すべき問題となっているため、停滞が生じています。
Edwin AI を使用して、AI 自動化によってチームをリアクティブからプロアクティブに変化させる方法をご覧ください。
LogicMonitorでEdwin AIのコンテンツ戦略を率いるMargo Poda氏。エンタープライズテクノロジーとAIスタートアップの両方での経験を持つ彼女は、複雑なトピックを明確かつ関連性が高く、読む価値のあるものにすることに注力しています。特に、似たようなコンテンツが溢れている分野において、その重要性は増しています。彼女はAIを誇大宣伝するためではなく、AIが実際に何ができるのかを人々に理解してもらうためにここにいます。
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
