Edwin AIは、ServiceNow Now Assistをリアルタイムのインシデントインテリジェンスで拡張し、可観測性データとServiceNowインシデント間のコンテキストブローカーとして機能します。レスポンダーは、既に使用しているIT運用ワークフロー内で必要なコンテキストを取得できます。Edwin AIの新機能：
ヘッドレスアーキテクチャとA2A統合をサポートしているため、チームはServiceNowで直接作業できます。
複数のサードパーティ製監視ツール間でイベントを自動的に相関付け、インシデントノイズを低減します。
Now AssistとWorkspaceで、根本原因、影響、推奨される次のステップを直接取得します。
Edwin AIのITOpsコンテキストグラフを使用して、メトリクス、イベント、トレース、ログから得られる詳細な可観測性コンテキストでチケットを充実させます。
L1チームがエスカレーションと対応を左右する回答に迅速にアクセスできるようにする
その エドウィン AI ServiceNow 用エージェントは、リアルタイムのインシデントインテリジェンスを 今すぐアシスト and これにより、IT運用チームはServiceNowのインシデント記録内で、根本原因、影響、推奨される次のステップを直接把握できます。
ServiceNowは、多くのチームがインシデントを管理し、作業を割り当て、対応を進めるためのプラットフォームです。しかし、これらのインシデントを理解するために必要な情報は、監視ツール、アラートストリーム、トポロジーデータ、調査ワークフローなど、本来アクションを実行するはずのシステム外にある様々なツールに分散していることがよくあります。
Edwin AIは、運用データとServiceNowのインシデント記録の間でコンテキスト仲介役として機能します。チケット自体に完全な可視性とITコンテキストをもたらし、生のシグナルを、インシデントワークフローから離れることなく対応者が利用できる、より明確なガイダンスに変換します。
その結果、作業の進捗状況を追跡するだけでなく、チームが何が起こっているのか、何が重要なのか、次に何をすべきかを理解するのに役立つ、より有用なインシデント記録が作成されます。
インシデントワークフローがコンテキストの段階で依然として破綻する理由 ほとんどのインシデントワークフローは、キューから担当者、そして解決へと作業を進めるのに十分な構造になっています。しかし、多くの場合、 コンテキスト 遅延による損失が最も大きい早期段階で、適切な意思決定を行うことが求められる。
不足しているコンテキストは通常、他のシステムに存在します。監視プラットフォームや可観測性プラットフォームには、アラート履歴、関連シグナル、トポロジー、調査の手がかりなどが含まれており、対応担当者は問題が単発的なものなのか、繰り返し発生しているのか、あるいはより広範なサービス障害の一部なのかを判断できます。エンジニアは、本来目の前の作業に付随しているはずの基本的な質問に答えるために、複数のツールを行き来することになります。
このプロセスが生み出す負担は、各ステップが個別に見ると小さく見えるため、過小評価されがちです。担当者はアラートの発生源を確認し、最近の履歴を調べ、関連するインシデントを比較し、想定される影響を追跡し、手作業で断片的な情報をつなぎ合わせてチケットに戻ります。このオーバーヘッドは、特に時間的プレッシャーの中で作業する現場チームにとって、すぐに積み重なります。トリアージは遅くなり、エスカレーションは混乱を招き、行動を促す記録が全体像を捉えた記録ではないため、信頼性が低下します。
ワークフローを変えるのは、プロセスを増やすことではありません。インシデント記録自体の中に適切なコンテキストへのアクセスを可能にすることです。コンテキストが作業と同時に提供されるようになれば、チームは背景情報を収集する時間を減らし、次に何をすべきかを決定する時間を増やすことができます。
Edwin AIがServiceNowのワークフローをどのように拡張するか Edwin AIはNow Assistを通じてServiceNowを拡張します エージェント2エージェント Edwin AIのエージェントとServiceNowのNow Assistを直接接続する（A2A）統合。この接続により、2つのプラットフォームは、インシデントワークフローの一環として、コンテキスト、インサイト、推奨アクションを交換できるようになり、これらの情報を別の調査経路に押し込む必要がなくなります。
これはServiceNowのより広範な アクションファブリックのビジョン AIエージェントは、コンテキストを取得し、ワークフロー、承認、および是正措置が安全に実行できる統制された行動システム内で動作できる必要がある。
実際には、これはエージェントが両方のプラットフォーム間でアラート、インシデント、および修復手順に関する情報を共有できることを意味し、チームがより多くの関連コンテキストを既に把握した上で、問題をより迅速に解決し、より良い意思決定を行うことを支援します。
例えば、ユーザーがNow Assistでより詳しい状況を尋ねた場合、アプリは定義されたやり取りに従います。
ServiceNowは、リクエストをNow Assist Orchestrator経由でルーティングします。
リクエストは Edwin AI オーケストレーター 対応策を計画する。
Edwin AIは、根本原因、影響、推奨される次のステップなどのコンテキストを含む、関連するアラート情報を返します。
ServiceNowは、Now AssistまたはWorkspaceに表示する前に、応答を再検証します。
ユーザーの視点から見ると、体験はインシデントワークフローの範囲内に留まります。調整は舞台裏で行われ、やり取りが構造化され、安全が確保されるよう、定められた手順が踏まれます。
この連携こそが、このアプリの価値を生み出す鍵です。重要なのは、あるシステムから別のシステムにデータをミラーリングすることではなく、インシデントに付随する運用上の推論をServiceNow内で利用できるようにすることです。そのためには、安全なOAuth 2.0ベースのAPIアクセスと、舞台裏で一貫したリクエスト/レスポンス構造が不可欠です。実際には、チームはNow AssistまたはWorkspace内に留まりながら、通常は別のツールと個別の調査経路が必要となるようなリアルタイムのアラートコンテキストを取得できます。
現場を離れることなく対応者が学べること ServiceNow内では、対応担当者はトリアージを形成する質問を行うことができます。
過去30日間で、この問題はどのくらいの頻度で発生しましたか？
この警報はどのような影響を与えているのか？
考えられる根本原因は何でしょうか？
および多く。
このアプリは、最前線のチームが最も必要とするNow AssistとWorkspaceに、これらの情報を直接表示します。レベル1の対応担当者は、問題が単発的なものか、繰り返し発生するものか、緊急なものか、エスカレーションが必要なものかを判断するために、十分なコンテキストを必要とします。
Edwin AIの分析結果をServiceNowのインシデント内で直接利用できるようにすることで、このアプリはユーザーが初期段階でトリアージの質を左右する回答に迅速にアクセスできるようにします。
Edwin AIがServiceNowのインシデント対応を変革する Edwin AIは、インシデントの背景にあるコンテキストをインシデントワークフロー自体に取り込みます。 ServiceNow 記録の保存場所として、また調査が行われる場所として、このアプリはこれら2つの機能を単一の作業環境内でより緊密に連携させます。
これにより、トリアージの質が向上します。対応者は、インシデントのレビュー、割り当て、エスカレーションの段階で、根本原因、影響、地形、爆発範囲、推奨される次のステップを評価できます。ワークフローには行動に必要な情報がより多く含まれるため、意思決定の段階での遅延が軽減されます。
ServiceNowのEdwin AIをご覧ください。
マルゴ・ポダは、LogicMonitorでEdwin AIのコンテンツ戦略を率いています。エンタープライズテクノロジーとAIスタートアップの両方で経験を積んだ彼女は、複雑なトピックを明確で、関連性があり、読む価値のあるものにすることに注力しています。特に、似たようなコンテンツが溢れている分野において、その重要性は増しています。彼女はAIを誇大宣伝するためにここにいるのではなく、AIが実際に何ができるのかを人々に理解してもらうためにここにいるのです。
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
