ServiceNow(サービスナウ)は、IT部門の問い合わせ・障害対応を起点に、人事・顧客対応・法務・財務などの申請から対応、記録までを1つのクラウド基盤で扱う業務プラットフォームです。この記事では、機能一覧と製品の区分、強みとデメリット、価格・ライセンスの考え方、導入の進め方を整理し、Xanadu〜Brazilのバージョン一覧とBrazil版の提供状況、Table APIでの連携方法まで、2026年10月29日時点の一次情報で確認した内容をまとめます。
まとめ:ServiceNowは部門をまたぐ業務を1つのデータで回すための基盤
ServiceNowの価値は機能の数ではなく、インシデントも人事の依頼も構成情報も、同じ仕組みのテーブルに記録される点にあります。部門ごとのツールやExcelに散らばった申請・承認・対応の流れを、共通のワークフローと権限、APIで扱えるようになります。
一方で価格は非公開の年間サブスクリプションで、初期設計と運用体制の負担も小さくありません。複数部門の業務を標準化したい中堅以上の企業に向き、目的がIT部門の問い合わせ管理だけなら専用ITSMツールのほうが早く安く済みます。バージョンは年2回のメジャーリリースで、2026年10月時点の一般向け最新はAustralia、次のBrazilは早期提供(Early Availability)の段階です。
ServiceNowの読み方と会社概要:本社・従業員数・2026年の業績
読み方は「サービスナウ」です。提供元のServiceNow, Inc.は米国カリフォルニア州サンタクララに本社を置き、ニューヨーク証券取引所にティッカー「NOW」で上場しています。Wikipediaの記述によると、2004年にPeregrine SystemsとRemedyでCTOを務めたFred Luddy氏が創業し、日本法人は2013年に設立されました。
規模は2025年度の年次報告書(Form 10-K)で確認できます。2025年12月31日時点のフルタイム従業員は29,187人(米国14,601人・米国外14,586人)です。直近の2026年第3四半期決算(2026年10月28日公表)では、サブスクリプション収益が39億8,800万ドル(前年同期比21%増)、年間契約額(ACV)500万ドル超の顧客が680社でした。10-Kでは同じ顧客数が2025年末に603社なので、大口顧客は9か月で77社増えています。
製品の土台は長く「Now Platform」と呼ばれてきましたが、10-Kや公式ドキュメントの現行表記は「ServiceNow AI Platform」です。古い資料でNow Platformと書かれていても同じ基盤を指します。
ServiceNowでできること:機能一覧と4つの製品区分
ServiceNowでできることは「IT運用の効率化」と「IT以外の業務への横展開」の2方向に分かれます。10-Kは製品群をTechnology、CRM and Industry、Core Business、Creator and Otherの4区分で説明しており、この区分で並べると機能一覧の全体像がつかみやすくなります。
製品区分ごとの代表的なモジュール一覧
| 製品区分 | 対象業務 | 代表的なモジュール |
|---|---|---|
| Technology | IT運用・資産・セキュリティ | ITSM・ITOM・資産管理・リスク管理 |
| CRM and Industry | 顧客対応・現場作業・業種別 | CSM(顧客サービス管理)・FSM |
| Core Business | 人事・法務・財務・調達・施設 | HRSD(人事サービス) |
| Creator and Other | 業務アプリ開発・データ保護 | App Engine(ローコード開発) |
最初はITSMだけで契約し、後からITOMやHRSDを足す段階導入ができます。どこから始めるかは、問い合わせの滞留や申請の紙運用など、課題が最も表に出ている部門から選ぶのが現実的です。
ITSMの中核:インシデント・問題・変更管理
ServiceNowが最初に普及したのはITサービス管理(ITSM)です。障害を記録・追跡するインシデント管理、根本原因を扱う問題管理、システム変更のリスクを事前に評価する変更管理が中核で、いずれもITILの考え方に沿っています。公式ドキュメントのIncident Managementは、業務への影響を抑えながら通常のサービス運用を回復させるプロセスと定義しています。
問い合わせはチケットとして記録され、定義したルールで通知・エスカレーションが走るため、誰が何を対応中かが見えるようになります。ITILのプロセスとツール実装の対応はITSMとITILの違い・管理プロセスを解説した記事で、監視やオンコールとつなぐ運用設計はITIL準拠のインシデント管理と監視・オンコールの実装で扱っています。
IT以外への展開:人事・顧客対応・社内申請
人事の入退社手続きや問い合わせ、顧客からの問い合わせ、法務・総務の各種申請も、同じチケットとワークフローの仕組みで扱えます。部門ごとに別ツールへ移らず、申請から承認、対応、記録までを同じ画面とデータで追える点が、単機能ツールとの差です。ITOMで使う構成管理データベース(CMDB)は「この変更がどのサービスに響くか」を判断する土台で、障害の予兆検知や相関分析の考え方はAIOpsの仕組みと主要機能を解説した記事と重なります。
ServiceNowの強み・メリット:データとワークフローが共通である効果
強みを実務で効く順に並べると、最も大きいのは全業務が共通のデータ構造に乗ることです。インシデント(incident)も変更要求(change_request)も共通の親テーブルtaskを継承しているため、担当者・状態・優先度といった項目、権限、通知、レポートを部門をまたいで同じ作法で扱えます。部門ごとにツールを入れた場合に起きる「集計の定義がツールごとに違う」問題が、構造的に起きにくくなります。
2つ目はワークフローの自動化です。承認・通知・エスカレーションをルール化すると、判断待ちで止まる時間を削れます。3つ目はローコード開発で、App Engineで作った業務アプリも裏側では新しいテーブルとして作られ、同じ権限・ワークフロー・APIの仕組みに乗ります。
4つ目はAI機能の統合です。2026年5月5日(米国時間)のKnowledge 2026で発表されたServiceNow Otto(公式の発表資料)は、Now Assist、Moveworks、AI Experienceの知能を組み合わせたAI体験と説明され、まずEmployeeWorksとAI Control Towerで提供し、1年かけて全製品へ広げる計画です。Australia版の公式ドキュメントでも、開発者向けの生成AI機能は「ServiceNow Otto for Creator」の名前で案内されています。メリットが出る大きさは「対応件数×またがる部門数」で決まると考えると、自社に当てはまるかを判断しやすくなります。
ServiceNowのデメリット:導入前に知っておくべき負担
デメリットは主に3つで、いずれも契約前に見積もれます。
- 価格が非公開で、見積もりを取るまで費用感がつかめない
- 業務プロセスの設計と社内の運用体制(管理者・開発者)が必要になる
- 独自改修を増やすと、年2回のアップグレードのたびに動作確認の工数が膨らむ
なかでも見落とされやすいのは3つ目です。ServiceNowは年2回のメジャーリリースが前提で、パッチ適用プログラム(Patching Program)の対象も直近の3ファミリーに絞られます(後述のバージョン一覧を参照)。古い版に留まり続ける運用はできないため、カスタマイズの量はそのまま保守費になります。
ServiceNowのデータ構造:テーブル・sys_id・CMDBの関係
ServiceNowを技術面から理解する近道は、画面ではなくデータの持ち方を見ることです。インシデントも人事の依頼も構成アイテムも、すべてテーブルの1レコードとして保存され、レコードは32桁のsys_idで一意に識別されます。後述のTable APIもこの「テーブル名+sys_id」で対象を指定するため、連携を設計する前にテーブル名を把握しておくと迷いません。
サーバーやアプリなどの構成アイテム(CI)はcmdb_ciを親とするテーブル群に入り、インシデントや変更のレコードから参照されます。どの障害がどのサービスに影響したかを追えるのは、この参照関係があるからです。CMDBの仕組みはCMDBとは何かを導入判断まで整理した記事、CIをどの粒度でサービスに束ねるかの公式データモデルはCSDM(共通サービスデータモデル)とCMDBの違いの解説が詳しいので、ITOMまで視野に入れる場合はあわせて確認してください。
Table APIでインシデントを取得・起票する手順
ServiceNowを既存システムとつなぐとき、最初に使うのがTable APIです。任意のテーブルに対してレコードの取得・作成・更新・削除ができ、監視ツールからの自動起票や、社内システムへのチケット状況の反映に使われます。
個人用開発者インスタンス(PDI)で検証環境を用意する
本番を触る前に、ServiceNow Developer Programへ登録して個人用開発者インスタンス(PDI)を申請します。公式のPDIガイドによると、PDIは無償で、管理者レベルの権限が付き、1人1インスタンスまでです。継続して使えば保持でき、使わないと休止(hibernation)します。業務・本番用途での利用は開発者プログラムの規約違反になるため、検証と学習に限って使います。
- Developer Programにアカウントを登録する
- インスタンスを申請し、URL(
https://devXXXXX.service-now.com形式)と管理者パスワードを控える - 連携用ユーザーを作り、
itilロールなど必要最小限のロールを付ける - REST API Explorerでリクエストを組み立てて試す
管理者アカウントのまま連携を作ると、本番で権限を絞った途端に動かなくなります。検証の段階から連携専用ユーザーで試すのが近道です。
curlでインシデントを検索する:sysparm_queryとsysparm_limit
有効かつ優先度1のインシデントを新しい順に5件、必要な項目だけ取得する例です。sysparm_queryはエンコード済みクエリで、条件のANDは^、ORは^ORでつなぎます。-Gと--data-urlencodeを使うと、^などの記号をcurl側でURLエンコードできます。
curl -s -G "https://devXXXXX.service-now.com/api/now/table/incident" \
--data-urlencode "sysparm_query=active=true^priority=1^ORDERBYDESCsys_created_on" \
--data-urlencode "sysparm_fields=number,short_description,state,sys_id" \
--data-urlencode "sysparm_limit=5" \
--data-urlencode "sysparm_display_value=true" \
--header "Accept: application/json" \
--user "api.user:パスワード"
公式リファレンスではsysparm_limitの既定値は10000で、超える件数はsysparm_offsetでページングします。注意したいのは、この上限がACL(アクセス制御)の評価より前に適用される点です。連携ユーザーが読めないレコードが先頭に並ぶと、指定した件数より少ない結果しか返らないことがあるため、並び順を読めるレコードが先に来るよう組み替えます。sysparm_display_valueの既定はfalse(データベース上の実値)で、trueにすると状態を「New」のような表示値で返します。
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}で状態を更新できます。同じアラートが再発したとき、保存済みのsys_idがあれば新規起票せず更新に回す分岐を入れると、二重起票も防げます。優先度はurgencyとimpactから算出する設定が一般的なので、priorityを直接書くより両者を渡すほうが運用ルールと食い違いません。
本番連携の認証方式とロール設計
上の例はベーシック認証ですが、本番の常時連携ではOAuth 2.0のトークン方式に切り替えます。パスワードを連携先に置かずに済み、トークンの失効で接続だけを止められます。トークン連携の流れはOAuth 2.0の仕組みと認可フローの解説を下敷きにすると整理しやすくなります。連携専用ユーザーにはACLで対象テーブルだけを開け、カスタマイズの回帰確認にはATF Test Generatorによるテスト自動生成が使えます。
ServiceNowと他のITSMツール・グループウェア・CRMの違い
本質的な差は、特定の部門・業務に閉じない全社横断型のプラットフォームである点です。代表的な比較対象との違いを整理します。
| 比較対象 | 主な守備範囲 | ServiceNowとの違い |
|---|---|---|
| 専用ITSMツール | IT部門の問い合わせ・障害 | 他部門の業務まで同じ基盤で扱える |
| グループウェア | 情報共有・スケジュール | 業務プロセス自体を自動化できる |
| CRM/SFA | 顧客情報・商談管理 | 顧客対応と社内業務を1つの流れにできる |
| ワークフローシステム | 稟議・申請の承認経路 | 承認後の対応・構成情報まで追える |
ServiceNowが優位になるのは、複数部門の業務をつなぎ直したいときです(単一業務だけなら後述の「採用しないほうがよい場面」を参照)。稟議・申請だけを電子化したい場合の選び方はワークフローシステムの機能・選び方と自社開発の判断基準で比較しています。
ServiceNowの価格とライセンスの考え方:見積もり前に決めること
ServiceNowは年間サブスクリプション型で、価格表は公開されていません。見積もりはServiceNow Japanか認定パートナー経由で取ります。課金の単位は製品ごとに異なり、利用ユーザー数で数えるもの、管理対象の資産・ノード数で数えるものなどがあります。
費用を左右するのは「誰が課金対象のユーザーか」です。公式ドキュメントのサブスクリプション種別では、ユーザー単位の課金(Rights-based user)が数えるのはチケットを処理する担当者などのFulfiller UserとBusiness Stakeholder Userで、申請やパスワードリセット依頼だけを行う一般社員(Requester)は含まれません。一方で、ロールに関係なく全アクティブユーザーを数えるUnrestricted Userという種別もあり、承認だけを行う人の扱いも契約によって変わるため、見積もりの前に「処理担当者・承認者・申請者がそれぞれ何人か」を部門別に数えておき、パートナーに区分を確認するのが確実です。社員数をそのまま掛けると費用を過大に見積もりがちです。
10-Kは主な販売先を大企業(enterprise customers)としており、2025年末の顧客約8,700社のうち年間契約額500万ドル超が603社です。数十人規模で1部門だけ使う用途は、価格面で不利になりやすいと考えてください。
ServiceNow導入の進め方:段階導入とOOTB、パートナー選定
導入の手順:1つの業務から始めて横に広げる
- 対象業務を1つに絞る(例:IT部門の問い合わせとインシデント)
- 現行の申請・承認・対応の流れと件数を棚卸しし、KPIを決める
- 標準機能で賄える範囲と、作り込みが要る範囲を線引きする
- 連携先システムとTable APIの認証方式・連携ユーザーを決める
- 小さく本番稼働させ、次の部門(人事・顧客対応など)へ広げる
要件整理を省いて画面から作り込むと、現場に合わないワークフローができ、一部の担当者しか使わない状態に陥りがちです。
OOTB(Out of the Box)を基準にカスタマイズを抑える
OOTBは、カスタマイズせずに標準機能のまま使う状態を指すServiceNowでよく使われる言葉です。まず標準機能で運用し、不足分だけをローコードで補うのが保守性の高い進め方です。ビジネスルールやスクリプトなど標準のレコードを改修していると、アップグレード時にスキップされたレコード(skipped records)として記録され、標準版との差分を1件ずつ確認して解消する必要があります。このため、「OOTBで業務を合わせるか、業務に合わせて改修するか」の判断が、導入費用と保守費用の両方を左右します。
導入支援パートナーの選び方
ServiceNowの導入は、ServiceNow Japanか認定パートナーが支援するのが一般的です。選定では、対象モジュール(ITSMかHRSDかなど)の導入実績、アップグレード時の保守まで請け負うか、社内に管理者を育てる支援があるかを確認します。ServiceNowのパートナープログラムには最上位の「Elite」などの区分があり、製品領域ごとの「Validated Practice」認定もあります。国内では、日立ソリューションズが2012年に日本初の販売代理店契約を結び、約140社の導入を支援したと公表しています。導入後に自社で運用できる体制を作れるかどうかで、数年後の保守費が変わります。
ServiceNowを採用しないほうがよい場面
目的がIT部門内の問い合わせ管理だけで、他部門へ広げる予定がない場合は、より安価で導入が早い専用ITSMツールのほうが費用対効果で勝ります。自動化したい業務が単一の申請フローで件数も少ないなら、ワークフロー専用の仕組みやRPAで足ります。この条件でServiceNowを入れるのは過剰投資です。
自社の承認経路や既存の基幹システムに合わせた申請フローだけが欲しいなら、ワークフローシステム開発で必要な範囲だけを作るほうが、ライセンスの固定費を抱えずに済みます。業務基盤としての位置づけを比較したいときは、オープンソースERPのOdooのような選択肢と並べると、ServiceNowが向く範囲が見えてきます。
ServiceNowのバージョン一覧:Xanadu〜Brazilの提供時期と現在の対象
ServiceNowは年2回メジャーリリース(ファミリー)を出し、名前はアルファベット順です。Zurichまでは主に都市名(UtahやFujiのような州名・山名も含む)で、2026年のAustraliaと次のBrazilは国名です。公式の「Available patches and hotfixes」(Xanadu・Yokohama・Zurich・Australia・Brazilの各版)に載っている日付は次のとおりです。
| ファミリー | 早期提供の開始 | Patch 1 | 2026年10月時点の扱い |
|---|---|---|---|
| Xanadu | 2024年8月1日 | 2024年9月10日 | Q4 2026パッチ対象外 |
| Yokohama | 2025年1月30日 | 2025年3月12日 | Q4 2026パッチ対象 |
| Zurich | 2025年7月31日 | 2025年9月10日 | Q4 2026パッチ対象 |
| Australia | 2026年3月12日 | 2026年4月3日 | Q4 2026パッチ対象 |
| Brazil | 2026年9月24日 | 2026年10月8日 | 早期提供の顧客のみ |
Q4 2026のパッチ適用プログラムの対象はAustralia・Zurich・Yokohamaの3ファミリーです。対象は直近3ファミリーで推移しているため、Brazilの一般提供後はYokohamaが対象から外れる見込みです(公式ページにも対象は変更されうると注記があります)。Yokohama以前に留まっている環境は、早めにアップグレードを計画してください。
Brazil版のリリース日と提供状況
Brazilは2026年9月24日に早期提供(Feature Early Availability)が始まり、10月8日にPatch 1、10月15日にPatch 1 Hotfix 1が出ています。ただし2026年10月29日時点で、公式の一覧ではいずれも「早期提供の顧客向け」か「Unavailable」の扱いで、一般の顧客がアップグレードできる版はまだありません。一般提供日は公式の一覧に載っていないため、計画を立てるときはこのページの更新を確認してください。
よくある質問
ServiceNowは無料で使えますか?
商用利用の無料プランはありません。検証や学習目的なら、Developer Programの個人用開発者インスタンス(PDI)を無償で使えます。本記事のTable APIの例もPDIで試せますが、業務・本番での利用は規約で禁止されています。
ServiceNowはSaaSですか?
基本はクラウドで提供されるSaaS/PaaSです。ただし10-Kは、顧客が自社環境にデプロイするセルフホスト型の提供もサブスクリプション収益に含むと記載しており、規制の厳しい市場向けの環境(Regulated Market environments)も用意されており、各ファミリーの公式リリース情報に提供状況が載っています。
ServiceNowの導入費用はどのくらいですか?
価格表は公開されておらず、製品・ユーザー区分・契約期間で変わるため、ServiceNow Japanかパートナーの見積もりが必要です。見積もり前に数えておくべき人数は、本文の価格の章にまとめています。
ServiceNowは他システムとAPIで連携できますか?
できます。代表的なのがTable APIで、/api/now/table/テーブル名に対するGET・POST・PATCH・PUT・DELETEでレコードを読み書きします。手順とコード例は本文のTable APIの章を参照してください。
ServiceNowは中小企業でも導入できますか?
モジュール単位で最小構成から始められるため、導入自体は可能です。効果が出るのは複数部門にまたがる業務を標準化したい場合で、単一部門・少件数なら本文の「採用しないほうがよい場面」に当たります。