(本稿は、こちらのBlog記事の翻訳です)
午前2時、何かがおかしい。アラートが発報し、スマートフォンの通知に叩き起こされ、画面を見つめながら、その「おかしい」が具体的に何を指すのかを必死に探る。そんな場面を、多くの方が経験されているはずです。
最初の数分間は、いつものパターンをたどります。サービスオブザーバビリティ (Service Observability) のダッシュボードを開き、アプリケーションのメトリクスを確認する。レイテンシは上昇しているが、致命的というほどではない。エラー率はじわじわと増えている。インフラを見ても、決定打にはならない。そこで通話に参加している誰かが、その後の40分間を狂わせる問いを投げかけます。「これはネットワークの問題なのか?」と。
アプリケーションチームは「アプリ側は問題ない」と言う。ネットワークチームは「ネットワークは正常だ」と言う。その間にもインシデントは時間を重ね、エラーバジェットは消費され、オンコール中のSREは5つの別々のダッシュボードを手作業で行き来しながら、どのツール単体でも描けない全体像をなんとか組み立てようとしている。
AustraliaリリースにおけるServiceNow® のサービスリライアビリティ管理 (Service Reliability Management、SRM) の新機能は、まさにこのような事態に照準を合わせています。
すべてを横断する、ひとつのビュー
今四半期に向けてお客様から最も多く寄せられた要望は、カバレッジの拡大でした。サービスオブザーバビリティがすでに可視化しているアプリケーションパフォーマンスのデータに加えて、ビジネスのコンテキストとネットワークの可視性も同じ場所で見たい、という声です。
Splunkのログ取り込みにより、ビジネスメトリクスがサービスオブザーバビリティのダッシュボードへ直接取り込まれるようになりました。インシデントが発生した際、チームは別のツールに切り替えることなく、アプリケーションパフォーマンスを顧客体験のメトリクスやKPIと突き合わせられます。ネットワーク側では、SolarWinds NPM、Zabbix、Cisco ThousandEyesとの連携により、ファイアウォール、ルーター、スイッチのテレメトリが既存のインフラシグナルと並んで表示されます。ネットワークに関する問いは、同じワークスペースの中で、同じ調査の流れのまま、引き継ぎなしで答えが得られます。
ネットワークが原因かどうかを、数時間ではなく数分で切り分けられます。そして本当に必要なときにだけ、ネットワーク運用チームへエスカレーションすればよくなります。
午前2時の問いに、自動で答える
データが統合されても、それを誰かが読み解かなければなりません。そして午前2時、その「誰か」はたいてい疲れ切っていて、複数のチャートの間で頭を切り替えながら、不完全な情報をもとに判断を下しています。
Gen AI Health Analysisは、その状況を変えます。Now Assistがオブザーバビリティのダッシュボードを自動的に横断して読み解き、本当に対応が必要な異常を特定し、推奨される次のアクションとともに提示します。CPU使用率82%、ネットワーク68%、概要ダッシュボードとホストダッシュボードにまたがって4件の異常を検出。こうした分析にかかる時間はおよそ30秒です。得られたインサイトはプラットフォームのワークフローに直接つながっているため、観測結果をその場でインシデントやアラートに変換できます。
これは単なるレポート機能ではありません。専門家が40分かけて全体像を組み立てるのか、それともサービスを開いた瞬間にその全体像がすでに用意されているのか。その差を生む機能です。
ユーザーの既存資産を活かす
Dynatraceは、ClassicからGrailへという大きなプラットフォーム移行の渦中にあり、多くのエンタープライズユーザーは今なおDynatrace Managedをオンプレミスで運用しています。これまでは、ユーザーがどのデプロイメントモデルを採用しているかによって、ServiceNowが参照できる範囲が決まっていました。今回のリリースは、この3つのギャップを同時に解消します。
Classic、Grail、そしてオンプレミスのDynatrace Managed。これらすべてがサービスオブザーバビリティの中でサポートされるようになりました。移行も回避策も不要です。
ポストインシデント処理の盲点を解決する
多くの組織のポストインシデントのワークフローに共通して見られる、とあるプロセス上の盲点があります。チームは問題を修復し、チケットをクローズするものの、次回それを検知するための監視の仕組みを追加しないまま次へ進んでしまうのです。誰も、「やらない」と決めたわけではありません。ただ、Synthetic Monitoringによるカバレッジの追加は手作業で、インシデント対応のフローの外にあるためです。そして、何と言っても、もっと急ぎの要件に移らなければならないためです。
Synthetic Monitoringに新たに搭載されたポストインシデントのモニター自動作成機能は、このギャップを埋めるために設計されたものです。インシデントがHTTPエンドポイントとの関係を持つサービスを参照している場合、システムが適切な外形監視を提案し、関連するエンドポイントをあらかじめ選択し、それらをサービスへ自動的にマッピングします。このアクションはインシデントの推奨アクションに直接組み込まれており、アラートはオペレーターがすでに作業しているExpress Listとサービスオペレーションワークスペースに表示されます。
数百のエンドポイントを管理するチームのために、新たな外部API対応が同じ機能をエンタープライズ規模へと広げます。合成モニターの作成、タグ付け、更新、廃止をプログラムから実行でき、CI/CDやサービス登録のワークフローと連携するため、サービスの変化に合わせてカバレッジが常に同期された状態を保てます。
設定いらずのエラーバジェット
SLOは、サービスが信頼性のコミットメントの範囲内で動作しているかどうかを示し、エラーバジェットはその許容量がどれだけ消費されたかを追跡します。どちらもSRMの根幹をなす要素です。そして同時に、設定が非常に手間のかかることでも知られています。すべてのサービスに目標値、指標、しきい値を設定する必要があり、数十から数百のサービスを管理するチームにとっては、このセットアップこそがSRM導入の足を止める原因になりがちでした。
Autonomous SLO Creator Agentは、その障壁を取り払います。アラート履歴、インシデントのパターン、深刻度の分布、ビジネス上の重要度といった、観測されたサービスの挙動を分析し、手動入力を一切必要とせずにベストプラクティスに沿ったSLO設定を生成します。SRMを有効にすると、デフォルトで2週間サイクルで動作し、サービスカタログ全体にわたってSLOのカバレッジを継続的に生成・維持します。
その実際的な効果は、すべてのサービスにエラーバジェットが行き渡るということです。誰かが設定する時間を確保できた一部のサービスだけ、ではありません。
再び、午前2時へ
午前2時の問いは、ツールが優れているからといって消えてなくなるわけではありません。けれども、その答えはより速く得られるようになります。さらに、インシデントが明らかにしたギャップを埋めるSynthetic Monitoringのカバレッジと、サービスの実際の挙動を反映したSLOがあれば、そもそも午前2時まで尾を引くインシデント自体が減っていきます。
何が起きているかをより広く可視化する。AIが全体像を読み解き、ゼロから始めなくて済むようにする。変化し続けるサービスカタログに追随する監視。ポートフォリオ全体をカバーする信頼性目標。
目指すのは、完璧なインシデント対応ではありません。インシデントの影響をより小さくする、そしていずれは怒らないようにするための対応なのです。
© 2026 ServiceNow, Inc. All rights reserved. ServiceNow, ServiceNow のロゴ、Now、その他の ServiceNow マークは米国および/またはその他の国における ServiceNow, Inc.の商標または登録商標です。その他の会社名と製品名は、関連する各会社の商標である可能性があります。
