「ServiceNowとは結局のところ何のツールなのか」「自社で何ができるのか」を、読み方から全体像、APIでの連携方法まで一気につかめるよう整理しました。ServiceNow（サービスナウ）は、IT部門の運用管理を起点に、人事・カスタマーサービス・財務など全社の業務プロセスを1つの基盤でつなぐクラウド型の業務プラットフォームです。本質は、部門ごとにExcelやメールへ散らばった申請・承認・対応・記録の流れを共通基盤に集約し、横断で標準化・自動化する土台にあります。この記事では、機能とモジュール、データ構造とTable APIの使い方、他ツールとの違い、ライセンス、採用を見送る場面、2026年の最新動向までを実務目線で整理します。
まとめ：ServiceNowは部門横断で申請・対応・記録をつなぐ業務基盤
結論から言うと、ServiceNowはIT運用（ITSM）を入り口にしながら、その仕組みを人事・顧客対応・社内申請などへ横展開できる統合プラットフォームです。価値の中心は機能の多さではありません。バラバラのツールやExcelに散らばっていた業務フローを共通のルールで一元管理し、属人化を解消できる点にあります。
技術的には「すべての業務データがテーブルとレコードで表される」構造になっており、Table APIというREST APIで外部システムから読み書きできます。一方で、単機能のITSMツールやワークフローツールと比べて初期設計とライセンスの負担は大きく、「IT部門の問い合わせ管理だけ」を目的にするなら過剰になりがちです。全社的に業務を標準化したい中堅以上の企業に向き、用途が単一で小規模なら別ツールのほうが合います。
ServiceNowとは何か：読み方・提供元・AI Platformへの改称まで
ServiceNowは、業務の受付から対応・完了・記録までを単一のクラウド上で管理する業務プラットフォームです。読み方は「サービスナウ」。製品の中核となる開発・実行基盤は長く「Now Platform」と呼ばれてきましたが、2026年10月時点の公式リリースノートでは「ServiceNow AI Platform」上に新機能を構築すると書かれており、呼称がAI Platformへ移っています。その上にITSMやHRなどの業務アプリケーションが乗る構造は変わりません。
提供元の ServiceNow, Inc. は2004年にFred Luddy氏が設立し（前身のGlidesoftは2003年）、本社は米国カリフォルニア州サンタクララにあります。ニューヨーク証券取引所（NYSE）にティッカー「NOW」で上場しており、2026年7月22日公表のQ2 2026決算ではサブスクリプション収益が38億7,700万ドル（前年同期比24.5%増）、年間契約額500万ドル超の顧客が658社と開示されています。日本法人のServiceNow Japanは2013年に設立されました。導入や契約は、ServiceNow Japanまたは認定パートナー経由で行うのが一般的です。
ServiceNowの主な機能とできること：IT運用から人事・顧客対応まで
ServiceNowでできることは「IT運用の効率化」と「IT以外の業務への横展開」の2方向に分かれます。読者が探す論点が異なるため、ここを分けて整理します。
ITSMの中核機能：インシデント・問題・変更管理をITILに沿って回す
ServiceNowが最初に普及したのはITサービス管理（ITSM）の領域です。中核となるのは、障害対応を記録・追跡するインシデント管理、再発防止のために根本原因を扱う問題管理、システム変更のリスクを事前評価する変更管理の3つで、いずれもITILの考え方に沿っています。公式ドキュメントのIncident Managementは、業務への影響を抑えながら通常のサービス運用を回復させるプロセスと定義しています。
問い合わせはチケットとして自動記録され、あらかじめ定義したルールで通知・エスカレーションが走るため、「誰が何を対応中か」が可視化されます。ITILのプロセス全体とServiceNowでの実装の対応関係はITSMとITILの違い・管理プロセスを解説した記事で、監視やオンコールとつなぐ運用設計はITIL準拠のインシデント管理と監視・オンコールの実装で詳しく扱っています。
IT以外の業務領域への展開：人事・顧客対応・社内申請を同じ基盤で
人事・総務・法務でも同じチケット基盤を使う構成が標準になりつつあります。人事では入退社手続きや問い合わせ対応、カスタマーサービスでは顧客からの問い合わせの一元管理、総務・法務では各種申請ワークフローを、いずれもServiceNow上のチケットとワークフローとして扱えます。部門ごとに別ツールへ移らず、申請から承認・対応・記録までを同じ画面で処理できる点が、単機能ツールとの違いです。
ServiceNowの主要モジュール（ITSM／ITOM／HRSD／CSM）と導入順
構成は共通基盤の上に、業務領域ごとのモジュールを必要なだけ載せていく積み上げ型。最初はITSMだけで始め、後からITOMやHRSDを足す段階導入ができます。代表的な4モジュールは次のとおりです。
| モジュール | 領域 | 主な用途 |
|---|---|---|
| ITSM | ITサービス管理 | インシデント・問題・変更・要求管理 |
| ITOM | IT運用管理 | インフラ可視化・CMDB・障害予兆検知 |
| HRSD | 人事サービス | 入退社手続き・人事問い合わせの自動化 |
| CSM | 顧客サービス管理 | 問い合わせ一元化・セルフサービス対応 |
ITOMで使われる構成管理データベース（CMDB）は、サーバーやアプリの構成情報を一元管理し、「この変更がどこに影響するか」を判断する土台になります。ITSMが「起きたことへの対応」だとすれば、ITOM＋CMDBは「起きる前に影響を読む」ための仕組みで、両者の組み合わせによって運用の質を変えられる仕組みです。障害の予兆検知や相関分析の考え方はAIOpsの仕組みと主要機能を解説した記事と重なります。どのモジュールから入れるかは、自社の課題が顕在化している領域から選ぶのが定石です。
ServiceNowのデータ構造：テーブル・レコード・CMDBの関係を押さえる
ServiceNowを技術面から理解する近道は、画面ではなくデータの持ち方を見ることです。インシデントも人事の依頼も構成アイテムも、すべてテーブルの1レコードとして保存されます。
incidentテーブルとsys_idで読み解くレコードの基本単位と継承
インシデントはincidentテーブル、変更要求はchange_requestテーブルに入り、どちらも共通の親であるtaskテーブルを継承しています。担当者・状態・優先度といった項目が全業務で共通なのはこの継承のためで、レコードは32桁のsys_idで一意に識別されます。後述のTable APIもこの「テーブル名＋sys_id」で対象を指定するため、まずテーブル名を把握しておくと連携設計がぶれません。
アプリ開発基盤「App Engine」で業務アプリを作ると、裏側では新しいテーブルが作られ、同じ権限・ワークフロー・APIの仕組みに乗ります。
CMDBとCSDMで構成情報とサービスを結び付ける設計の勘所
サーバーやアプリなどの構成アイテム（CI）はcmdb_ciを親とするテーブル群に格納され、インシデントや変更のレコードから参照されます。どの障害がどのサービスに影響したかを追えるのは、この参照関係があるからです。CMDB自体の仕組みとITILとの関係はCMDBとは何かを導入判断まで整理した記事、CIをどの粒度でサービスに束ねるかの公式データモデルはCSDM（共通サービスデータモデル）とCMDBの違いの解説が詳しいので、ITOMまで視野に入れる場合はあわせて確認してください。
Table APIでインシデントを取得・起票する手順と検証環境の作り方
ServiceNowを既存システムとつなぐとき、最初に使うのがREST APIの一種であるTable APIです。任意のテーブルに対してレコードの取得・作成・更新・削除ができ、監視ツールからの自動起票や、社内システムへのチケット状況の反映に使われます。
開発者インスタンス（PDI）を無償で用意して検証環境を作る手順
本番インスタンスを触る前に、ServiceNow Developer Programへ登録して個人用開発者インスタンス（PDI）を申請します。発行は無償で、払い出されるのはhttps://devXXXXX.service-now.com形式のURLと管理者アカウントです。インスタンスの版は申請時点の現行リリースが選べ、デモ用のインシデントデータも最初から入っているため、以下のコマンドはそのまま試せます。
- Developer Programにアカウント登録する
- ダッシュボードからインスタンスを申請し、URLと管理者パスワードを控える
- 検証用ユーザーを作成し、
itilロールなど必要最小限のロールを付与する - REST API Explorer（System Web Services配下）でリクエストを組み立てて試す
管理者アカウントのまま連携を作ると、本番で権限を絞った途端に動かなくなります。
curlによるincident検索：sysparm_queryとfieldsの指定方法
有効かつ優先度1のインシデントを新しい順に5件、必要な項目だけ取得する例です。sysparm_queryはエンコード済みクエリで、条件のANDは^、ORは^ORでつなぎます。
curl -s "https://devXXXXX.service-now.com/api/now/table/incident?sysparm_query=active=true^priority=1^ORDERBYDESCsys_created_on&sysparm_fields=number,short_description,state,sys_id&sysparm_limit=5&sysparm_display_value=true" \
--header "Accept: application/json" \
--user "api.user:パスワード"sysparm_fieldsを省くと全項目が返り、応答が重くなります。sysparm_limitを付けない場合の既定上限は公式ドキュメント上10,000件なので、件数の多いテーブルではsysparm_offsetと組み合わせたページングが必須です。sysparm_display_value=trueは状態を「New」のような表示値で返す指定で、連携先で数値コードを解釈したいときはfalseにします。
PythonでインシデントをPOST起票し監視ツールと連携する実装例
監視ツールのアラートを受けてインシデントを自動起票する、最小構成のPythonコードです。requestsライブラリだけで動きます。
import os
import requests
INSTANCE = os.environ["SN_INSTANCE"] # 例: devXXXXX
URL = f"https://{INSTANCE}.service-now.com/api/now/table/incident"
payload = {
"short_description": "Webサーバー応答遅延（監視アラート）",
"urgency": "2",
"impact": "2",
"category": "network",
}
res = requests.post(
URL,
auth=(os.environ["SN_USER"], os.environ["SN_PASSWORD"]),
headers={"Accept": "application/json", "Content-Type": "application/json"},
json=payload,
timeout=30,
)
res.raise_for_status()
record = res.json()["result"]
print(record["number"], record["sys_id"])応答のresultに採番されたインシデント番号とsys_idが入ります。このsys_idを監視側に保存しておけば、復旧時にPATCH /api/now/table/incident/{sys_id}で状態を更新でき、二重起票も防げます。優先度はurgencyとimpactの組み合わせから自動算出される既定設定が多いため、priorityを直接書き込むより両者を渡すほうが運用ルールと食い違いません。
本番連携で押さえる認証方式とロール設計、OAuth 2.0の使いどころ
上の例はベーシック認証ですが、本番の常時連携ではOAuth 2.0のトークン方式に切り替えるのが一般的です。パスワードを連携先に置かずに済み、トークンの失効で接続だけを止められます。トークン連携の流れはOAuth 2.0の仕組みと実装メリットの解説を下敷きにすると、設計の流れを整理しやすいはずです。Table APIは呼び出しユーザーがそのテーブルを読み書きできる権限を持つことが前提なので、連携専用ユーザーにはアクセス制御（ACL）で対象テーブルだけを開けておきます。連携処理を含むカスタマイズの回帰確認にはATF Test Generatorによるテスト自動生成が使えます。
ServiceNowの強み・メリット：業務を点でなく流れで扱える理由
実務で効いてくる順に挙げます。最も大きいのは、部門ごとに分断された業務を共通基盤に集約できることです。問い合わせ経路がメールや電話に散らばり、対応履歴がExcelに点在する状態を解消し、対応漏れや重複対応、属人化を減らせます。
次に効くのが、ワークフローエンジンによる自動化です。通知・承認・エスカレーションをルール化することで、判断待ちで止まる時間を削れます。
ローコード／ノーコードでの拡張性も見逃せません。App Engineで自社の業務に合わせて画面やワークフローを作り込めます。同じローコード開発の発想はローコード開発プラットフォームのSPIRALでも採られており、両者を見比べるとServiceNowの拡張性の位置づけがつかみやすくなります。これにAI機能によるチケット分類や要約が加わり、一次対応の負担は着実に減ってきました（AI機能の名称と提供範囲は後述の最新動向を参照）。
単一部門・少件数の業務では、仕組みの恩恵より運用コストが上回ることがあります。導入効果は「対応件数×部門数」に比例すると考えると判断しやすくなります。
他のITSMツール・グループウェア・CRMとServiceNowの違い
本質的な差は、特定の部門・業務に閉じない全社横断型のプラットフォームである点です。代表的な比較対象との違いを整理します。
| 比較対象 | 主な守備範囲 | ServiceNowとの違い |
|---|---|---|
| 従来型ITSMツール | IT部門の問い合わせ・障害対応 | 部門横断のワークフロー設計を前提にできる |
| グループウェア | 情報共有・スケジュール | 業務プロセス自体の自動化・標準化が可能 |
| CRM／SFA | 顧客情報・商談管理 | 顧客対応と社内業務を1つの流れで設計できる |
| ワークフローシステム | 稟議・申請の承認経路 | 承認後の対応・記録・構成情報まで同じデータで追える |
つまりServiceNowは「IT部門の道具」ではなく、IT運用を起点に全社の業務を再設計するための基盤という位置づけです。単一業務の効率化だけが目的なら専用ツールのほうが安く早いことも多く、ServiceNowが優位になるのは複数部門の業務をつなぎ直したいときです。稟議・申請だけを電子化したい場合の選び方はワークフローシステムの機能・選び方と自社開発の判断基準で比較しています。比較検討では「何を効率化したいか」より「いくつの部門・業務をまたぐか」を軸に置くと判断を誤りにくくなります。
ServiceNowのライセンスと費用の考え方：課金ロールの切り分け方
ServiceNowは年間サブスクリプション型で、価格は公開されていません。見積もりはServiceNow Japanまたはパートナー経由で取得します。費用感を左右するのはライセンスの数え方で、主に次の方式があります。
- ユーザー単位：利用ユーザー数に応じた課金
- ノード単位：管理対象のIT資産数に応じた課金
- デバイス単位：管理対象デバイス数に応じた課金
- トランザクション単位：処理量に応じた課金
ユーザー単位で見落としやすいのは、全社員分のライセンスが必要なわけではない点です。チケットを処理する担当者（Fulfiller）など操作を行うロールは課金対象になりますが、申請やパスワードリセット依頼だけを行う一般社員（Requester）は課金対象外として扱われるのが通例です。「社員数＝ライセンス費用」と誤解してコストを過大に見積もるケースが多いため、誰が課金ロールに該当するかを先に切り分けると見積もりの精度が上がります。
Table APIの連携専用ユーザーも、持たせるロールで課金区分が変わることがあります。価格体系は改定されることがあるため、最新の条件は公式またはパートナーで確認してください。
ServiceNow導入の注意点と採用を見送るべき場面の具体的な条件
ServiceNowは柔軟性が高い反面、設計と定着のしかたで成果が大きく変わります。まず注意点として、導入は単なるツール設定ではなく業務プロセスの見直しを伴います。要件整理やKPI設計を省くと、現場に合わないワークフローを作り込んでしまい「一部の担当者しか使わない」状態に陥りがちです。過度なカスタマイズは年2回のバージョンアップ時の保守を重くするため、標準機能（OOTB＝Out of the Box）でどこまで賄うかを最初に線引きするのが定石です。
採用を見送るべきなのは、目的がIT部門内の問い合わせ管理だけに限られ、横展開の予定がない場合です。この用途であれば、より安価で導入が早い専用ITSMツールのほうが費用対効果で勝ります。自動化したい業務が単一フローで件数も少ないなら、ワークフロー専用の仕組みやRPAで足りることが多く、ServiceNowの導入は、この条件では過剰投資です。自社の承認経路や既存の基幹システムに合わせた申請フローだけが欲しいなら、ワークフローシステム開発で必要な範囲だけを作るほうが、ライセンスの固定費を抱えずに済みます。
外部システムとの連携を前提にする場合は、前述のTable APIと認証方式の設計を要件定義の段階で決めておきます。ERPと役割が重なる場面もあり、業務基盤としての位置づけを比較したいときはオープンソースERPのOdooのような選択肢と並べて検討すると、ServiceNowが向く範囲が見えてきます。
ServiceNowの更新動向：Australia版・Otto発表・次期Brazil版
ServiceNowは年2回のメジャーリリースを行い、これまで都市名をアルファベット順に付けてきました。Xanadu（2024年後半）、Yokohama（2025年前半）と続き、Zurich（2025年後半）がアルファベット都市名としては最後のリリースになりました。2026年以降は命名規則が国名へ切り替わっています。
国名の最初となるAustralia版は2026年前半に一般提供され、Australia版の公式リリースノート（2026年9月10日更新）はZurich・Yokohama・Xanaduの各版からのアップグレード向けノートを用意しています。2〜3世代前からでも直接上げられる前提で計画が立てられる、ということです。
AI機能の名称も変わりました。2026年5月5日のKnowledge 2026で発表されたServiceNow Ottoは、Now Assist・Moveworks・AI Experienceの知能を束ねたAI体験と説明され、まずEmployeeWorksとAI Control Towerから提供し、1年かけて全製品へ広げる計画です。
次のBrazil版は2026年後半の提供が予定されており、2026年10月時点では早期提供の段階にあるとコミュニティで案内されています。バージョン名と提供時期、搭載機能は変更されることがあるため、導入・更新の計画時は最新情報を公式リリースノートで確認してください。
よくある質問：ServiceNowの読み方・無料利用・API連携・規模感
ServiceNowを調べ始めた段階でよく出る疑問を5つまとめました。
ServiceNowの読み方は？
「サービスナウ」と読みます。英語表記は ServiceNow で、株式市場で知られる名称はNYSEのティッカー「NOW」です。日本では「サービスナウ」のほか「サービスNow」と表記されることもありますが、いずれも同じ製品を指します。製品の基盤はかつて「Now Platform」と呼ばれ、2026年時点の公式ドキュメントでは「ServiceNow AI Platform」と表記されています。
ServiceNowは無料で使えますか？
商用利用の無料プランはありません。年間サブスクリプション型で、価格は非公開のためServiceNow Japanまたはパートナーへの見積もり依頼が必要です。開発者向けには、機能を試せる無償の個人用開発者インスタンス（PDI）がDeveloper Programで提供されており、検証や学習目的であればこちらを使えます。本記事のTable APIのコード例もPDIで試せます。
OOTB（Out of the Box）とは何ですか？
OOTBは、カスタマイズせずに標準機能のまま使える状態を指す用語です。ServiceNowはOOTBの機能が豊富で、まず標準機能で運用し、不足分だけをローコードで補うのが保守性の高い進め方とされています。年2回のバージョンアップのたびに独自改修の動作確認が発生するため、OOTBでどこまで賄えるかの見極めが導入費用と保守費用の両方を左右します。
ServiceNowは他システムとAPIで連携できますか？
できます。代表的なのがTable APIで、/api/now/table/テーブル名に対するGET・POST・PATCH・PUT・DELETEでレコードを読み書きします。監視ツールからのインシデント自動起票、人事システムからの入退社情報の取り込み、チャットツールへの通知などが典型例です。本番ではベーシック認証ではなくOAuth 2.0を使い、連携専用ユーザーの権限を対象テーブルに絞るのが基本です。
ServiceNowは中小企業でも導入できますか？
導入自体は可能で、モジュール単位で最小構成から始められます。ただしライセンスと初期設計の負担があるため、効果が出るのは複数部門にまたがる業務を標準化したい場合です。単一部門・少件数の用途では、専用のITSMツールやワークフローシステムのほうが費用対効果で勝ることが多い点に注意してください。
関連記事
- ITSMとは？ITILとの違い・管理プロセス：ServiceNowが実装するITSMの全体像
- CMDBとは？構成管理データベースの仕組み：ITOMの土台
- CSDMとは？共通サービスデータモデル：CMDBの設計指針
- OAuth 2.0とは何か？概要と仕組み：API連携の認証設計
- インシデント管理とは？ITIL準拠のプロセス：監視・オンコールとの接続
