アプリケーションサービス

リリースバージョン: Zurich

更新日 2025年07月31日

所要時間：17分

アプリケーションサービスについて理解し、さまざまなアプリケーションサービスタイプと、複数の ServiceNow® 事業部門や製品での使用方法について学びます。

アプリケーションサービスとは

サービスインスタンスは、組織にサービスを提供するように構成されている、相互接続された一連のアプリケーションとホストです。サービスインスタンスは、組織のメールシステムのような内部向けにすることも、組織の Web サイトのような顧客向けにすることもできます。たとえば、Web ベースのアプリケーションを使用して財務報告を作成するには、コンピューター、Web サーバー、アプリケーションサーバー、データベース、ミドルウェア、ネットワークインフラストラクチャーが必要です。これらのアプリケーションとホストはすべて、財務報告サービスを提供するように構成されています。開発環境において、アプリケーションサービスはビジネスアプリケーションやシステムのインスタンスを表します。

ServiceNow アプリケーションは、構成アイテム (CI) としてアプリケーションサービスを構成するデバイスおよびアプリケーションを参照します。アプリケーションサービスを構成するさまざまな CI およびその関係は、構成管理データベース (CMDB) に格納されます。

各アプリケーションサービスには、トップレベル CI としてエントリポイントが含まれています。エントリーポイントは、クライアントがサービスインスタンスにアクセスするポイントです。通常、これは URL、またはエンタープライズ展開のアプリケーションサービスの IP アドレスとポートの組み合わせです。クラウドベースの展開では、エントリポイントを AWS ゲートウェイのようなクラウドリソースへの URL にすることができます。

共通サービスデータモデル (CSDM) (CSDM) は、サービスタイプとサービスオファリングの簡素化に役立ちます。CSDM 内で、アプリケーションサービスと他のサービス関連オブジェクトの間の関係を追加できます (ビジネスアプリケーション、テクニカルサービスオファリング、またはビジネスサービスオファリング)。

アプリケーションサービスには次のタイプがあります。

検出済み

サービスマッピングは、パターンを使用し、トラフィック接続を追跡することによって、アプリケーションサービスを検出します。

パターンベースディスカバリーでは、IT インフラストラクチャのサービス中心型ビューを確実に表す、正確で完全なアプリケーションサービスが作成されます。ミッションクリティカルなアプリケーションサービスの管理に適した、忠実度の高いマップを作成します。

さらに、コンピューティング、ロードバランサー、API ゲートウェイなどのクラウドネイティブサービスの可視化を提供します。AWS S3 バケット、AWS および Microsoft Azure API ゲートウェイ、AWS Lambda 関数、Microsoft Azure 関数などのサービスエントリポイントを使用して、サービスをマップできます。また、Lambda から Lambda の呼び出し、および Lambda から RDS への接続を検出して、動的サービスマップを構築することもできます。

トップダウン方式では、オンプレミスおよびパブリッククラウドの VM をマッピングします。ただし、VM 内で実行されているアプリケーションを特定するには、これらの VM をトップダウンディスカバリーで完全に検出する必要があります。VM の検出が完全でない場合は、タグベース方式を使用してギャップを埋めます (このドキュメントの後半を参照)。タグベースのマッピングでは、トップダウンディスカバリーを使用してマッピングできないコンテナーもマッピングされます。

検出されたアプリケーションサービスには、アプリケーションサービスのサービス分類があります。これらはマップ済みアプリケーションサービス [cmdb_ci_service_discovered] テーブルに格納されています。

ダイナミック CI グループ

アプリケーションサービスとして動作するダイナミック CI グループです。ダイナミック CI グループに関連付けられている CMDB グループのメンバーが、アプリケーションサービスに入力されます。ダイナミック CI グループは、デトロイトのすべての Web サーバーの場所やボストンのすべての Oracle データベースの場所など、いくつかの共通基準に基づいて CI を動的にグループ化します。ダイナミック CI グループを作成すると、IT Service Management でグループオファリングとして使用できます。

アプリケーションサービスウィザードから作成された場合、サービス分類はアプリケーションサービスであり、従来のイベント管理 UI またはサービスマッピング UI から作成された場合、分類はテクニカルサービスです。ダイナミック CI グループタイプのアプリケーションサービスは、ダイナミック CI グループ [cmdb_ci_query_based_service] テーブルに保存されます。

タグベース

タグは、キーと値のペアで構成されるラベルです。組織はタグを使用して資産を分類し、クエリおよびレポート機能を強化することができます。ディスカバリーとクラウドプロビジョニングとガバナンスは、すべての主要クラウドプロバイダーとコンテナーのエコシステムで使用されるタグを検出できます。タグが検出されると、サービスマッピングこれらのタグに基づいてサービスインスタンスを作成できます。たとえば、タグを使用して、組織が EMEA 地域の本番環境で使用するすべてのアプリケーションサービスをマップすることができます。

タグベースのアプリケーションサービスには、アプリケーションサービスのサービス分類があります。これらはタグベースのアプリケーションサービス [cmdb_ci_service_by_tags] テーブルに格納されています。

手動作成

手動マッピングを使用すると、アプリケーションオーナーは、各アプリケーションサービスをサポートするアプリケーション、IT インフラストラクチャ、および関係を手動で文書化できます。この方法は、セキュリティアクセスの問題のために完全な検出が不可能な構成アイテムに最適です。たとえば、セキュリティ事業部門の侵入防止サービスをサポートする IPS デバイスが挙げられます。

可能な限り手動でのマッピングは避けてください。サービスを手動でマッピングするには非常に時間がかかります。また、テクノロジーの進化や、アプリケーションコンテキストに必要なインフラストラクチャの依存関係を追跡および文書化するプロセスがないことにより、マッピングに必要な情報が入手できないことがよくあります。さらに、その後もアプリケーションサービストポロジに変更が加えられるたびに、サービスマップを手動で更新する必要があります。

手動で作成されたアプリケーションサービスには、アプリケーションサービスのサービス分類があります。手動で作成されたアプリケーションサービスは、マップ済みアプリケーションサービス [cmdb_ci_service_discovered] テーブルに格納されます。

ダイナミック

動的アプリケーションサービスには、CMDB CI 関係 [cmdb_rel_ci] テーブルに格納されている CI 関係の一部である CI のみが含まれます。

CI を直接追加または削除して、動的アプリケーションサービスを編集することはできません。動的アプリケーションサービスは、CMDB CI 関係 [cmdb_rel_ci] テーブルの CI 関係の変更を反映して自動的に更新されます。動的アプリケーションサービスに含まれる CI にリレーションシップを追加すると、そのサービスは自動的に更新され、リレーションシップおよび関連付けられた新しい CI の追加を反映します。同様の方法で、リレーションシップと関連 CI をサービス内の CI から削除したときに、動的アプリケーションサービスが自動的に更新されます。

動的アプリケーションサービスを作成する 1 つの方法は、従来のビジネスサービスまたは従来の手動サービス (イベント管理での作成など) を動的タイプのアプリケーションサービスに変換することです。

動的アプリケーションサービスには、アプリケーションサービスのサービス分類があります。動的アプリケーションサービスは、計算されたアプリケーションサービス [cmdb_ci_service_calculated] テーブルに格納されます。

アプリケーションサービスのユーザー

アプリケーションサービスは、次の事業部門と ServiceNow AI Platform の製品の運用基盤となります。

ITOM ヘルスは、サードパーティのモニタリングツールによってキャプチャされたインフラストラクチャイベントからアラートを収集します。次に、ディスカバリーによって収集された IT 関連情報を使用して、アラートを構成アイテムにマップします。収集された情報に基づいて、はすべてのサービス影響度イベントの統合ビューを表示するダッシュボードを提供します。
ITOM 最適化により、プライベートとパブリックのクラウドインフラストラクチャおよびサービスをプロビジョニングし、一貫した管理とコストの可視化を実現するツールが提供されます。クラウドコスト管理アプリケーションは ServiceNow Store で入手可能で、コストを削減し運用を最適化する機会を特定してアクションを実行できるように、クラウド資産に関連するすべてのコストを分析するのに役立ちます。
IT Service Management を使用すると、IT インフラストラクチャを反映したアプリケーションサービスを利用して、顧客へのサービスを管理および提供できます。
カスタマーサービス管理 (CSM) を使用すると、アプリケーションサービスのコンテキストで IT インフラストラクチャに関連する問題を効率的に診断して解決できます。
ソフトウェア資産管理を使用すると、IT 環境で実行されているソフトウェアを把握し、IT 環境とデータセンター全体のソフトウェアライセンス消費に影響を与える構成を追跡できます。
戦略的ポートフォリオ管理 (SPM) を使用すると、アプリケーションサービス用に収集されたデータを利用して、組織で使用されているアプリケーションを包括的に把握できます。

アプリケーションサービスの作成方法

組織のニーズに応じて、アプリケーションサービスを作成および設定するさまざまな方法を展開できます。

重要:

同じアプリケーションサービスに対してトップダウン方式と手動方式を使用できます。同じアプリケーションサービスの作成または設定に、他の方式を組み合わせることはできません。

組織内の IT インフラストラクチャおよびサービス展開を分析し、アプリケーションサービスを作成して設定する最適な方法を選択します。

表 : 1. 展開に適した方法の選択
手法	使用するタイミング	その他考慮事項
トップダウンディスカバリーサービスマッピングはアプリケーションサービスのトップダウンディスカバリーを実行します。サービスマッピングはパターンを使用して CI を検出およびマッピングします。パターンとは、CI の属性とその送信接続を検出することを目的とした一連のステップです。この方式では、組織の IT インフラストラクチャのサービス認識型ビューを確実に表す、正確で完全なアプリケーションサービスが作成されますのタグベースのディスカバリーサービスマッピングは、トップダウンディスカバリーの結果を充実させる補完的な方法です。	この方式を使用して、業界で認められている、またはカスタマイズされた第 2 層および第 3 層のアプリケーションを検出します。このようなアプリケーションには、負荷分散ソリューション、アプリケーション、またはデータベース接続を備えた Web サーバーが含まれます。	パターンベースのマッピングでは、組織のプライベートネットワーク内のアプリケーションにサービスマッピングがアクセスできるようにするために、認証情報、ユーザー、およびユーザー権限を設定する必要があります。このプロセスには時間と労力がかかる場合があります。
タグベース組織で資産管理にタグを使用している場合は、これらのタグを使用してアプリケーションサービスをマッピングできます。ディスカバリーおよびクラウドプロビジョニングとガバナンスは CI に割り当てられたタグを検出し、CMDB にこのデータを入力します。サービスマッピングは CMDB のタグ関連データを使用してサービスをマッピングします。タグベースのサービスマッピングは、トップダウンのサービスマッピングを補完します。コンテナーを可視化し、トップダウンのサービスマッピングでは実行できない、完全には検出されていない VM をマッピングします。ただし、タグベースのマッピングはタグ付けされたコンポーネントを特定のアプリケーションサービスに関連付けますが、これらのコンポーネント間の接続はマッピングしません。これが、タグベースのマッピングがトップダウンサービスマッピングに置き換わるものではなく補完するものである、もう 1 つの理由です。	Kubernetes、OpenShift、または AWS ECS を使用して、IaaS/Paas/FaaS/CaaS などのクラウドワークロードおよびコンテナーワークロードのリソースをマッピングします。また、サイト信頼性エンジニアリング (SRE) または顧客信頼性エンジニアリング (CRE) 展開のリソースをマッピングします。タグベースの方式を使用すると、展開内のコンテナーリソースをマッピングできます。通常、この方式を使用して、クラウド仮想化または PaaS 展開のアプリケーションを検出します。	他のマッピング方式とは異なり、タグベースのマッピングでは認証情報を構成したり適切な権限をユーザーに与えたりする必要はありません。これらの CI に適切なタグがアサインされていない場合、関連 CI がタグベースのアプリケーションサービスに含まれない可能性があります。
統合された Dynatrace または AppDynamics 展開からのアプリケーションパフォーマンス管理 (APM) マップの取り込み ServiceNow Store で利用可能な AppDynamics アプリケーションモデルおよび Dynatrace モニタリングプラットフォームとのデータ連携を使用して、アプリケーションサービスを作成します。	このデータ連携を使用して、Dynatrace または AppDynamics の APM マップに基づいてアプリケーションサービスを作成します。この方式で作成されたアプリケーションサービスを使用して、健全性をモニタリングできます。	サードパーティから取り込む前に CMDB で検出されたリソースを分析して、重複 CI が作成されないようにします。
ダイナミック CI グループメソッドを使用したアプリケーションサービスの設定 CMDB グループに基づき、そのメンバーがアプリケーションサービスに設定されます。	これは、Microsoft Active Directory、Microsoft Exchange、またはその他の DNS 関連サービスを含む展開用のダイナミック CI グループを作成する簡単かつ迅速な方法として使用されます。ダイナミック CI グループは、構成の詳細や認証情報がわからず、リソースのリストのみが利用可能な場合に特に役立ちます。 CMDB グループを使用すると、CMDB 健全性を使用して健全性をモニタリングし、CMDB クエリビルダー保存済みクエリーを使用して、アプリケーションサービスに含まれる CI をフィルタリングできます。	この方式を使用して作成されたアプリケーションサービスのマップビューはありません。このようなアプリケーションサービスに属する CI のみをリストとして表示できます。アプリケーションサービスに含める必要がある CI を CMDB グループが正確にフィルタリングしていることを確認する必要があります。
アプリケーションサービス API アプリケーションサービスを一括で作成するための自動化を作成します。この方法は、組織が組織をまたがるマッピングと分析を行い、サービスに関する情報を収集している場合に使用します。手動タイプに属する API を使用して作成されたアプリケーションサービスは、マップ済みアプリケーションサービス [cmdb_ci_service_discovered] テーブルに格納されます。	この方法は、DevOps 継続的インテグレーション/継続的デプロイメント (CI/CD) プロセスを追跡する必要がある環境に使用します。サードパーティのサービスマップは、手動アプリケーションサービスに個別にインポートすることも、一括でインポートすることもできます。たとえば、「デジタルガイドブック：サードパーティサービスマップの ServiceNow サービスマッピングへのインポート」を参照してください。	正確なサービス構造 (サービスを構成する各 CI の sys_id および CI が形成する階層) をよく理解している必要があります。この方法では、組織で使用するスクリプティングインフラストラクチャに関する知識が必要です。
手動でアプリケーションサービスを設定するエントリポイントという 1 つの CI のみを使用して、手動アプリケーションサービスを作成します。手動で作成されたアプリケーションサービスを設定するには、「アプリケーションサービスに CI を手動で追加する」で説明されているように他の CI を手動で追加します。または、CMDB で作成され [cmdb_ci_service] に格納されているビジネスサービスを変換して、手動アプリケーションサービスを作成して設定します。	アプリケーションサービスを作成または設定する他の方法を使用できない場合は、手動での方法を使用します。侵入防止のため、アプリケーションサービスを手動で作成します。	この方法には、既存のセットアップやオブジェクト構成は必要ありません。手動で作成されたアプリケーションサービスには、任意のクラスの CI を含めることができます。手動で作成されたアプリケーションサービスには、CI 属性など CI への一部の変更が反映されます。ただし、CI 関係の変更は自動的には反映されません。
動的サービスメソッドを使用したアプリケーションサービスの設定 CMDB CI 関係 [cmdb_rel_ci] テーブルの CI 関係の変更を反映して自動的に更新されるアプリケーションサービス。共通サービスデータモデル (CSDM) に準拠するために、従来のサービスを動的アプリケーションサービスに変換することもできます。これらの従来のサービスは、[cmdb_ci_service] または [cmdb_ci_service_manual] CMDB テーブルに保存されます。ビジネスサービスのアプリケーションサービスへの変換従来の手動サービスを動的アプリケーションサービスに変換する	この方法を使用して、従来のビジネスサービスを他の ServiceNow 製品が利用できるアプリケーションサービスに変換します。たとえば、動的アプリケーションサービスはサービスの監視と変更管理に使用できます。	CI を追加または削除して、動的アプリケーションサービスを編集することはできません。動的タイプのアプリケーションサービスは、そのアプリケーションサービスの一部となっている CI の該当する関係を変更すると、自動的に変更されます。
CSV ファイルからサービスマッピングは、このファイルから情報を抽出し、サービス候補として参照される可能性があるアプリケーションサービスを作成します。この方法は、組織が組織をまたがるマッピングと分析を行い、サービスに関する情報を収集している場合に使用します。	必要に応じて、複数の CSV ファイルからサービス候補をインポートできます。	ドキュメントの記載どおりに、収集したすべての情報を特定の順序で CSV ファイルに整理します。

CSDM に準拠するには、「手動サービスのアプリケーションサービスへの変換」または「API を使用した手動サービスのアプリケーションサービスへの変換」で説明されているように、IT Operations Management (ITOM) イベント管理を使用して作成され、[cmdb_ci_service_manual] に保存されている手動サービスを変換します。変換されたサービスは、マップ済みアプリケーションサービス [cmdb_ci_service_discovered] テーブルに格納される手動アプリケーションサービスになります。

ドメインセパレーション

展開されている場合、ドメインセパレーションは次のようにサービスインスタンスに影響を与えます。

サービスインスタンスの作成時に、サービスインスタンスがユーザーのドメインに割り当てられます。
サービスインスタンスに手動で CI を追加する場合は、サービスドメインに属する CI のみを選択できます。
アプリケーションサービスを作成または更新するために createOrUpdateService - POST REST API を使用する場合は、API で参照される CI のいずれかがアプリケーションサービスとは異なるドメインに属していると、プロセスが停止します。
ビジネスサービスをアプリケーションサービスに変換する場合、新しく作成されるアプリケーションサービスは、元のビジネスサービスと同じドメインに属します。アプリケーションサービスは、アプリケーションサービス自体と同じドメインに属する CI のみから構成されます。