ServiceNow は外側から見るとシンプルに見えるプラットフォームの一つですが、組織がカスタマイズを始めると迷路のように複雑になります。サービスカタログや HR ポータルとして始まったものが、すぐにカスタムテーブル、UI ポリシー、ビジネスルール、Flow Designer のアクション、スクリプト化された REST エンドポイントの入り組んだ構造に発展します。これは決して悪いことではありません。実際、多くの企業が ServiceNow を選ぶ理由はまさにここにあり、何でも構築できるという点です。
しかしその柔軟性は脆弱性も伴います。特に他のロジックに依存するようなカスタムロジックを導入した瞬間、組み込みの監視では検出されず、ほとんどの内部ダッシュボードからは見えない障害モードが生まれます。ServiceNow インスタンスは書面上は健康に見えても、実際のユーザーにとってはポータルが完全に使えないことがあります。
そこで合成モニタリングの出番です。ServiceNow が内部で実行する軽量の「シンセティック」チェックではなく、外部から、ブラウザレベルで実際のユーザーがポータルとやり取りする様子をシミュレートする監視です。両者の違いは、サーバーの心拍を確認することと、人間が実際にチケットを提出できるかを確認することの違いと同じです。
外部のシンセティックは、カスタムテーブル、クライアントスクリプト、スクリプト化された API、そして最終的にはあなたの設計判断に起因する障害を検出します。可動部品の数が増えるにつれて、ServiceNow ポータルが正しく動作していることを確認する唯一の確実な方法は、インターネットからアクセスする実際の人のように振る舞うものを使うことです。
この記事の範囲はここにあります：なぜ ServiceNow のカスタマイズがほとんどの故障の根本原因になるのか、なぜネイティブツールではそれが見えないのか、そして合成モニタリングがどのようにそのギャップを埋めるか、です。
なぜ ServiceNow のカスタマイズがポータル体験を壊すのか
Now Platform は組織に膨大なカスタマイズ領域を提供します。基盤となる構造が非常にモジュール化されているため、ある箇所の小さな変更が他に影響を及ぼさないと考えがちです。
しかし現実には、ServiceNow のほとんどの要素はリレーショナルです — カスタムテーブルは他のテーブルを参照し、ルールは継承クラスに対して発火し、スクリプトは他のスクリプトが依存する状態を変化させます。ブラウザ上で単純に見える UI 要素でさえ、GlideRecord クエリのスタック、ACL チェック、サーバー側のビジネスルールによって駆動されていることがあります。
何かがうまくいかないとき、それは伝統的な「ダウンタイム」イベントのようには見えません。代わりにユーザーは次のような症状を目にします：
- ページが遅延して読み込みがタイムアウトする。
- 送信ボタンを押した後にカタログ項目がフリーズする。
- カスタム API が不完全な JSON を返し、ウィジェットが永遠に回り続ける。
- ルールが ACL の継承を調整したために検索結果が突然何も返さなくなる。
- 社内では動作するナレッジページが、SSO 経由でアクセスすると壊れる。
ServiceNow のインフラにとってはすべて「稼働中」かもしれません。しかし従業員や顧客にとっては、ポータルはオフラインと同じです。
これらの故障モードは基盤プラットフォームから発生するのではなく、どのようにカスタマイズされたかから生じます。テーブル、ルール、エンドポイント — それぞれが弱点を導入します。合成モニタリングが有効なのは、インスタンスの内部状態がどうであれ関係なく、ポータルが正しく動作しているかだけを重視するからです。
ServiceNow のネイティブ監視における盲点
ServiceNow にはプラットフォームに組み込まれた「合成」監視があります。しかしそれは内部合成監視です — インスタンス内部から実行され、ワークフローの実行、ビジネスロジック、基本的な SLA を検証するチェックです。
役に立ちますか？はい。十分ですか？決してそうではありません。
内部のシンセティックはポータルと同じ条件下で動作します。VPN、企業ファイアウォール、異なる地理的領域、サードパーティのアイデンティティプロバイダ、DNS レイヤー、CDN を横断することはありません。ブラウザをロードしたり、JavaScript を実行したり、実際のユーザー環境に近い形でポータルをレンダリングしたりしません。カタログや承認、スクリプト、バックエンド統合に跨るマルチステップのジャーニーにも追従しません。
そして最も重要なのは、最も壊れやすい部分──あなたのカスタムコード──に触れない点です。よくある事象は次のとおりです：
- エラーを投げるカスタムクライアントスクリプトが内部のシンセティックの失敗を引き起こさない。
- サードパーティ API が遅くて止まる Flow Designer のアクションが内部アラートを発しない。
- scoped アプリのエンドポイントが不正なペイロードを返しても、特別にテストしない限り不健康として記録されない。
- ウィジェットの変更によって発生するブラウザ側のパフォーマンス退行がサーバーログに現れない。
ネイティブ監視はプラットフォームを検証します。外部の合成モニタリングは体験を検証します。
ServiceNow の内部だけを見ているなら、常に半分は盲目のままです。
カスタムテーブルの監視：データアーキテクチャが UX を壊すとき
ServiceNow のすべてはテーブルの上に成り立っており、組織がカスタムテーブルを導入すると依存グラフは指数的に増加します。新しいインシデントのサブクラス、独自のスキーマを持つ record producer、カスタム CMDB 拡張 — それぞれが潜在的なドリフトの新たな原因になります。
最大の問題は、インスタンス側で気付かれる以前にポータル側で現れます。
- 一見無害な ACL 更新が突然参照フィールドの入力をブロックし、結果としてカタログ項目が「フリーズ」する。
- カスタムテーブルが時間をかけて変更された親から継承し、特定のフィールドに依存するルールが発火しなくなる。
- レコード数の増加に伴い GlideRecord クエリが遅くなり、インスタンスは正常な CPU を示していてもポータルがタイムアウトする。
- テーブル間の依存関係が静かに壊れ、ワークフローが「requested」に留まりエラーメッセージが出ない。
これらは従来の意味での障害ではありません。ワークフローの失敗です。そしてそれらは、これらのテーブルに依存する実際のポータルコンポーネントをテストしない限り見えません。
合成モニタリングは、カタログを開く > フィールドを入力する > 送信する > 状態変更を検証する、というようにテーブル依存のワークフロー全体を縫い合わせるため、これらを検出します。ServiceNow が正常だと考えている部分だけでなく、全経路が見えます。
ビジネスルール & クライアントスクリプトの監視
ルールは微妙に連鎖するため、ServiceNow の中で最も見落としやすく危険な部分です。あるビジネスルールが insert 後に発火し、それが Flow Designer のアクションをトリガーしてフィールドを更新し、さらに script include を発火させ、カスタム API を呼び出す──こうして単純なチケット提出が分散システムになってしまうことがあります。
クライアントスクリプトは別の種類の障害を生みます：条件の間違い、変数の欠如、新しい UI ポリシーが古いものと衝突するなどです。これらの障害はログ上で明白なエラーとして現れず、ブラウザ上での遅延、ボタンのフリーズ、フォームの挙動不一致として現れます。
ポータルは、ビジネスルール + クライアントスクリプトの組み合わせが露呈する場所です。
合成モニタリングは次を検出します：
- 送信時間を急上昇させる遅い Glide クエリを引き起こすビジネスルール。
- 特定フィールドが空のときに誤動作する UI ポリシー。
- Chrome のみで壊れ、Firefox では正常に動作するクライアントスクリプト。
- 継承ドリフトによりデータを誤ったテーブルにルーティングするルール。
ServiceNow の内部シンセティックは「すべてのシステムが正常」と報告している間に、ユーザーは回転するウィジェットのスクリーンショットでヘルプデスクを埋め尽くします。
外部からのテストこそ、ルールスタックが期待通り動作しているかを検出する唯一の確かな方法です。
カスタムエンドポイント & 統合の監視
カスタムエンドポイントは、ServiceNow ポータルが単なる Web インターフェースでなく実際のアプリケーションとして振る舞い始める地点です。組織は scripted REST API、統合レコード、外部システムを呼ぶ Flow Designer アクション、scoped app エンドポイント、入出力の webhook を組み合わせてプラットフォームを拡張します。各追加は依存チェーンを深め、その依存はコアの ServiceNow 環境の外側に故障点を導入します。
ここから多くのポータル障害が発生します。スクリプト化された REST API が不具合を起こすと、それに依存するウィジェットは永遠に回り続けます。外部統合が遅いと、カタログの送信が十分に長く保留され、ユーザーは失敗したと判断します。MuleSoft や Workato のようなミドルウェアはレート制限や間欠的なスロットリングを課す可能性があり、そうなると ServiceNow はしばしばユーザーに有用な手がかりを与えない漠然としたエラー状態で応答します。端点が不正あるいは部分的な JSON を返すだけでも、従来のエラーとしては表れない方法で UI コンポーネントを壊すには十分です。
これらの問題は ServiceNow のネイティブ監視には現れません。プラットフォームは自分自身のインフラだけを見ており、あなたのカスタマイズが依存する外部呼び出しまでは見えません。しかし合成テストはそれらの依存をワークフローの一級市民として扱います。ウィジェットをロードし、API 呼び出しをトリガーし、レスポンスを処理し、関連テーブルを更新し、最終状態をリアルユーザーと同様に検証します。ブラウザの挙動、ネットワーク条件、エンドポイント性能、プラットフォームロジックの組み合わせこそが、ポータルが実際に機能するかを決定します。
ワークフロー全体を継続的にテストしていなければ、検証ではなく「希望」に頼っていることになります。カスタマイズされた ServiceNow 環境では、希望は戦略にはなりません。
ServiceNow ポータル向けの Outside-In 合成モニタリング
ブラウザレベルの合成モニタリングは、内部ワークフローチェックとは本質的に異なります。それは実際のユーザーが行うのと同じ方法でポータルをロードします：実際のマシンから、実際のブラウザを動かして、パブリックインターネット経由で。
これにより完全な経路が再現されます：
- DNS 解決
- CDN ルーティング
- 企業またはクラウドゲートウェイ
- SSO や外部アイデンティティプロバイダ
- JavaScript 実行
- ウィジェットのレンダリング
- API 呼び出し
- テーブルの更新
- ポータルの応答
これは、エンジンが動くかどうかを確認するのと、車が実際に走るかどうかを確認する違いに相当します。
特に広範なカスタマイズが施された ServiceNow ポータルでは、これが現実を捉える唯一の方法です。
- ページの読み込みに 7 秒かかるなら、それが見える。
- ウィジェットがコンソールエラーを投げるなら、それが見える。
- カスタムエンドポイントが不正な JSON を返すなら、テストは実際のユーザーと同様に失敗する。
- リリースアップデートがスクリプトの挙動を変えれば、ステップのタイミングが急増する。
Outside-in のシンセティックはインスタンスが健康だと考えているかどうかを気にしません。人間がタスクを完了できるかを重視します。
実際の ServiceNow ポータルのジャーニーをモデリングする
ServiceNow ポータルは線形アプリケーションではなく、分岐するフローです。良い合成テストはこれを反映します。目的はランダムにページをクリックすることではなく、あなたの組織が作成したテーブル、ルール、エンドポイントに埋め込まれたビジネスロジックを検証することです。
適切なテストは実際のワークフローを再現します：
- 認証（多くは SSO 経由）。
- カスタムポータルまたはサービスカタログを開く。
- カスタムテーブルに依存するカタログ項目を検索する。
- クライアントスクリプトや UI ポリシーをトリガーするフィールドを入力する。
- 送信し、ビジネスルールやエンドポイント呼び出しをトリガーする。
- 正しいテーブルに結果レコードがあることを検証する。
- 後続の状態変更が伝播していることを確認する。
これにより、通常故障が発生するあらゆるステップが再現されます。
良い合成テストには次が含まれます：
- 非同期に読み込まれるウィジェットのための動的待機。
- 静的テキストではなく実際のデータ値に結びついたアサーション。
- チケットが正しい状態で正しいテーブルに到達することの検証。
- カスタムエンドポイントが期待されるオブジェクトを返すことのチェック。
- 遅いルール、スクリプト、統合を明らかにするタイミング分析。
これは軽量なヘルスチェックではありません。あなたのチームが ServiceNow 上に構築したカスタムアプリケーションに対するフルスタックの振る舞い検証です。
ServiceNow のアップグレード & リリースによる回帰を捉える
ServiceNow の年に二回のアップグレードは、予測可能な不可予測な障害の源です。プレプロダクションで注意深くテストしても、微妙な回帰は見逃されます。なぜならプラットフォームの振る舞いが変わると、それが完全にカスタマイズされた環境でしか可視化されないことがあるからです。あるリリースでは完全に動作していたクライアントスクリプトが、UI フレームワークの変更後に壊れることがあります。カスタムウィジェットは静かにリファクタされた依存関係に依存しているかもしれません。ビジネスルールが実行順序の変化で二重に発火するようになることもあります。Flow Designer のアクションがわずかに異なる出力構造を返すことがあり、GlideRecord クエリはインデックスやクエリ最適化の変更によって挙動が変わることがあります。
これらは劇的な障害ではなく、ポータル上で遅延、予期しないフォーム挙動、読み込みを拒否するコンポーネントとして表れる二次的な障害です。そして多くのカスタマイズが継承テーブルやプラットフォームレベルの抽象に依存しているため、小さな変更でも波及して何かが壊れます。
合成モニタリングは、ユーザーが影響を受ける前にこれらの問題を可視化する唯一の信頼できる方法です。手動のアップグレードテストが既知のパスに集中する一方で、シンセティックは生きているワークフローを検証します — カタログ項目、チケット作成、承認、検索挙動、統合依存コンポーネント。アップグレードの数時間後にユーザーが何が壊れたかを報告する代わりに、合成モニタリングは即座にその可視性を提供し、アップグレードの窓が終わった後もレグレッションの安全網を維持します。
Dotcom-Monitor の役割
Dotcom-Monitor は ServiceNow の内部ツールを置き換えるものではありません。それらを補完し、プラットフォームとユーザー体験の間の可視性ギャップを埋めます。
実際のブラウザ監視により、クライアント側のパフォーマンスを反映するステップごとのタイミングが取得でき、単なるサーバーステータス以上の情報が得られます。API 監視により、カスタムエンドポイントや統合を独立して検証できます。グローバルなロケーションにより、異なるネットワークや地域がポータルとどのように相互作用するかが見えます。マルチステップスクリプティングにより、カスタムテーブル、ルール、エンドポイントに依存する正確なワークフローをモデル化できます。
言い換えれば：内部監視はプラットフォームを正直に保ち、外部監視は体験を正直に保ちます。
結論
ServiceNow はカスタマイズによって強力になりますが、同じ理由で脆弱にもなります。各カスタムテーブル、各ルール、各エンドポイントはポータルが失敗する新たな方法を導入します — 多くは静かに、そしてしばしば ServiceNow のネイティブツールでは示されません。
合成モニタリングは、ユーザーの視点から完全なジャーニーを再現することで可視性のギャップを埋めます。カスタムデータ構造に依存するワークフローを検証します。スクリプトやルールによって導入された振る舞い上の問題を検出します。API 呼び出しや統合の裏に隠れた障害を明らかにします。そしてインスタンスがどれだけ健康だと考えていようと、これらを継続的に実行します。
ITSM、HR、カスタマーポータル、あるいはカスタムアプリケーションのために ServiceNow を入り口として利用している組織にとって、outside-in の検証は選択肢ではありません。ポータルが機能するかどうかを知るための唯一の信頼できる方法です。
テーブル。ルール。エンドポイント。これらはあなたの ServiceNow カスタマイズのコアであり、監視戦略のコアでもあります。外部のシンセティックは、それらがプラットフォームが報告する方法ではなく、あなたが意図した通りに動作することを保証します。