ServiceNowチケッティングシステム: 仕組みと費用

ServiceNowチケッティングシステムの正体

まずは一番下から見ていきましょう。土台を理解すれば、その上にあるものすべてがわかります。

ServiceNowのすべてのチケットは、単一の親テーブルを継承したテーブルに存在します。同社自身のドキュメントもその点をはっきりと述べています。Taskテーブルは「Incident、Problem、Change Managementなど中核となるITSMアプリケーションにフィールドを提供するベースクラスである。Taskテーブルを継承するすべてのアプリケーションは、これらのフィールドを共通して持つ」とされています。

taskに直接書き込むことはできません。試みても、Task Interceptorがそれを止め、先に子テーブルを選ばせます。どの子テーブルを選んだかは、sys_class_nameフィールドに記録され、それは永久に残ります。

テーブル名こそが挙動を決めるため、正確なテーブル名とともにファミリー全体を示します。

プレフィックスもハードコードされているわけではありません。これらはSystem Definition配下のsys_numberテーブルの行として存在し、ServiceNowのレコード番号付けドキュメントによれば、管理者なら誰でも変更できます。Zendeskのようなフラットなツールから移ってきた場合、これが最初に感じる本当の違いです。ここではレコードタイプはフォーム上のドロップダウンではなく、スキーマ設計上の判断なのです。

この継承構造がもたらす恩恵は本物であり、あら探しを始める前にきちんと評価しておくべきです。承認、割り当てルール、SLA、非アクティブ監視、フローはすべてtaskを継承するものすべてで動作するため、一度作れば済みます。これは小規模なヘルプデスクツールには真似できない部分であり、プラットフォームと自動化されたチケッティングシステムを分ける違いでもあります。レビュアーもこの点に気づいています。

"Keeping requests, incidents, and changes connected is the core of this platform, which I really appreciate. Plus, finding related knowledge without leaving the ticket open. And lastly, bringing different IT tools together through integrations."

Louis B., G2

これは実際にレコードを開いたときの見た目です。ルーティングを担うAssigned toとAssignment groupのフィールドに注目してください。どちらもtaskからそのまま継承されています。

1件のリクエストが生む3つのチケット番号

ほぼ全員がここでつまずきます、しかも初日に。

誰かがノートパソコンを申請したとします。通常のチケッティングシステムであればそれは1件のチケットで、ほとんどの社内チケッティングシステムでは納品まで1件のチケットのままです。ServiceNowではこれが3種類のレコードになります。Request Managementが、依頼、アイテム、作業をあえて別々のものとしてモデル化しているためです。

1. REQ（sc_request）: カートレベルのコンテナ。1回のチェックアウトにつき1つのREQが生成されます。
2. RITM（sc_req_item）: カタログアイテムごとに1つ。同じチェックアウトでノートパソコンとモニターを申請すれば、1つのREQに2つのRITMが紐づきます。
3. SCTASK（sc_task）: 履行作業そのもので、RITMのフローによって発行されます。調達、イメージング、発送という3つのステップなら、1つのRITMから3つのSCTASKが生まれます。

つまり、1人が1つのものを申請するだけで、3つの番号体系にまたがる5つのレコードが生まれ、ステータスを確認する場所も3か所に分かれることになります。これはバグではありません。カート、アイテム、作業を分離するという意図的な設計です。そして新しいエージェントが決まってつまずくポイントでもあります。

"At times, especially as a beginner, it may be hard to navigate with all the various levels of a customer ticket--Interactions, Requests, RITMs, SCTasks etc. And then there's the occasional what seems like a bug."

Andrei F., Knowledge Specialist, Capterra

この量のほとんどを生み出しているカタログアイテムは、地味なものばかりです。アクセス申請は単独で最大のカテゴリであり、自動化する価値が最も高い部分です。備品や機器の申請がそれに僅差で続き、ハードウェア申請については別のガイドで詳しく解説しています。

カタログを構築する立場なら知っておくべき落とし穴があります。変数はsc_req_itemにしか存在しません。ServiceNowは「変数は拡張テーブルではサポートされていない」と明言しています。つまりユーザーがカタログフォームに入力したものはすべてRITMに残り、フルフィラーが実際に見るSCTASKへそれを渡すには、意図的な設定作業が必要になります。フルフィラーが「モニターのサイズは何インチだったか」と繰り返し尋ねてくるなら、それがその理由です。

インシデントのライフサイクル: 状態ごとの解説

インシデントはよりシンプルな側です。状態モデルは全体が公開されています。

お読みの通り、4と5は存在しません。これはHelsinki以前のモデルが残した「焼け跡」で、当時は3つの別々の待機状態があったのが、今では1つのOn Holdにまとめられています。ServiceNow自身のナレッジ記事KB0564465がそのマッピングを公開しており、何が壊れるのかを正確に説明しています。「ステート5でトリガーされるワークフローがあった場合、それをステート3、理由コード2でトリガーされるように修正する必要がある」とのことです。

ここがドキュメントの中で私が一番驚いた部分です。ServiceNowはアップグレードされたインスタンスに対して、新しい状態モデルの導入を推奨していません。つまり、長く運用されている多くの本番インスタンスは、現代的なインターフェースの裏で、今も旧来の5状態の形をそのまま使い続けているということです。生の状態番号を前提に書かれたレポートやワークフローは、リリースに依存するため、誰かのインスタンスを引き継ぐ前に必ず確認すべき点です。

見落としがちな3つの挙動

優先度はエージェントが決めるものではありません。 ImpactとUrgencyの3×3のグリッドから自動計算され、このフィールドは読み取り専用として提供されます。ServiceNowはpriority lookup rulesページで直接そう述べています。「個々のインシデント対応者は優先度ルックアップルールを変更できない」。全員がP1にすべきだと合意しているP3も、ドロップダウンではなく管理者との話し合いが必要になります。

自動クローズはレコード上のタイマーではなく、スケジュールされたジョブです。 ここから2つの結果が生じます。第一に、監査証跡が実態と食い違います。「Autoclose Incidentsジョブが実行された際にログインしていた管理者の名前が、Updated byフィールドに記録される」ためです。第二に、非アクティブ監視は「トリガーされるたびにこの自動クローズのタイマーをリセットする」ため、両方の機能が動いているインスタンスでは、決してクローズされないResolvedインシデントが静かに積み上がっていき、その矛盾は表面化しません。ServiceNowのドキュメントによると、対処法はリセット条件を[Incident state] [is not] [Resolved]にすることです。

親をクローズしても子はクローズされません。 Resolveすればクローズされますが、Closeしてもされません。ネットワーク障害の親インシデントの下に100件の子インシデントがある場合、親子同期テーブルによれば、親をクローズしても100件のResolvedレコードが個別の発信者からの対応待ちのまま残ります。この非対称性が、実際以上にダッシュボード上で悪く見えるチケットバックログの一因になっています。

チケットが実際にルーティングされる仕組み

ルーティングは継承された2つのフィールド、assigned_toとassignment_groupの上で動作しており、これがすべてのレコードタイプで同じように振る舞う理由です。割り当てルールは条件が一致すると自動的にこれらを設定します。

この割り当てルールに関する1つのルールは、ポスターにして貼っておく価値があります。assignment rulesのドキュメントには次のようにあります。「割り当てルールは、既存の割り当て（デフォルト値や過去に実行された割り当てルールによって設定されたものも含む）を上書きできない」。つまり、assignment_groupに設定した親切なデフォルト値が、その後に書いたすべてのルーティングルールを静かに無効化してしまいます。そして複数のルールが一致した場合、常にorder値が最も小さいものだけが実行されます。例外はありません。

権限まわりの罠もあります。初めて遭遇したときはバグのように見えます。itilロールを持つユーザーは、adminまたはsecurity_adminロールを持つグループにインシデントを割り当てることができず、それらのロールを持つ親グループを持つグループにも割り当てられません。

この層を正しく設計する方法についてさらに深く知りたい方は、AIチケットルーティングのガイドがここより詳しく解説しており、AIによるチケットのタグ付けの記事は分類の側面をカバーしています。より広いカテゴリの全体像は自動化されたITチケッティングのガイドにまとめています。

SLAと、何も機能しないフィールド

ServiceNowのService Level Managementは強力で、1つのtaskが複数のSLAを同時に抱えることができ、それぞれが専用のtask_slaレコードで追跡されます。レビュアーからの評価も高い部分です。

"The SLA tracking feature is another aspect I like, as it helps our team assess the performance of the person resolving issues."

vignesh m., admin, G2

契約を設計する前に知っておくべきことが2つあります。

1つ目。ITILの講座であれば1時間かけて説明するようなSLA／OLA／Underpinning Contractの区別も、製品内部では単なるラベルにすぎません。TypeフィールドについてのServiceNowの注記は一文だけです。「Typeはレポート作成の目的にのみ使用される」。エンジンも条件も計算式も同じです。ResponseとResolutionのTargetフィールドも同様で、「フィルタリング、検索、レポート作成の目的にのみ」存在しています。

2つ目、「日」は営業日ではありません。ドキュメントはこの罠をはっきり説明しています。「このフィールドで指定された日数は24時間単位のブロックに変換される。Scheduleフィールドが1日8時間のスケジュールを指定している場合、1日の期間は3営業日後にSLA違反となるよう設定される」。合理的な設計ではありますが、誰も気づかないまま1年間誤作動し続けるSLAを出荷してしまう、非常に簡単な原因でもあります。

もう1つ知っておくべきこと。現代のインスタンスでは、Breachedはそもそもtask_slaのステージではありません。ステージはIn progress、Cancelled、Paused、Completedです。Breachedが残っているのは「2010年版のSLAエンジンを使用しているか、互換モードで動作しているシステム」のみですが、ビジュアルタイマーウィジェットは今でもそれを表示するため、2つの語彙が食い違います。この上にSLAレポーティングを構築すれば、この不一致が必ずどこかで表面化します。

セルフサービスと、Virtual Agentが実際に減らしているもの

チケット量の話の核心はセルフサービスにあり、ここから各ティアの違いが重要になってきます。

フル版のVirtual Agentは有能です。ServiceNowは実際に機能する事前構築済みのITSMトピックを提供しています。Check IT Ticket Statusは、ステージと最終更新日時とともにユーザーのアクティブなチケットを一覧表示します。Escalate IT Ticketは緊急度を1段階引き上げますが、理由の入力が必須です。会議室の予約や割り当て機器についてのトピックもあります。デフレクション自体は「チケットや人によるサポートにつながらずにユーザーの質問やリクエストが解決されること」と厳密に定義されています。

下位ティアの顧客が手にするVirtual Agent Liteは、まったく別物です。付属するトピックはCheck Ticket StatusとReport an Issueの2つだけ。NLUはまったくなく、キーワードマッチングのみです。トピックやチャネルを追加することもできません。そして決定的なのは、分析ダッシュボードが存在しないため、どれだけデフレクションできたかを測定するサポートされた方法がないことです。Liteのデフレクションを評価するというのは、測定できないものを評価するということであり、解決率をきちんと報告するサービスデスクチャットボットと比較する前に知っておく価値があります。この壁にぶつかったチームは、たいていVirtual Agentの代替製品を検討することになります。

もう1つの制約が本番環境で牙をむきます。人へのハンドオフには人が必要です。「Virtual Agentから転送する際には、少なくとも1人のライブエージェントが対応可能でなければならず、そうでない場合、エンドユーザーにはno agents availableというメッセージが表示され、会話は転送されない」。このパスにはドキュメント化されたチケットへのフォールバックが存在しません。これこそ優れたAIハンドオフ設計が最も重要になる瞬間です。

メールでの受付にも独自の問題があります。転送の判定はウォーターマークより優先されるため、ServiceNowは「これらの条件を満たすメールは、たとえ本来は返信と判定されるはずのウォーターマークやレコード番号が含まれていても、転送として分類する」としています。平たく言えば、メールスレッドをServiceNowに転送すると、常に重複チケットが作成されるということです。

2026年のServiceNowチケッティングシステムの費用

ここからが、皆さんが本当に知りたかった部分です。

ServiceNowは価格を公開していません。だからこそ私たちのServiceNow料金ガイドが存在しています。この記事を書いている当日にもITSM料金ページを改めて確認しました。パッケージはFoundation、Advanced、Primeの3つ。ボタンは「Get Custom Quote」の1つだけ。ページ内のどこにも通貨記号はありません。比較表全体で唯一の数字は、App Engine Starterのテーブル数とProcess Miningのレコード数の上限だけです。

2026年4月9日以降、旧来のStandard、Pro、Pro Plus、Enterprise、Enterprise Plusの各ティアは廃止され、レガシーSKUは2026年7月1日に販売終了を迎えました。新規の購入者が目にする構成は、今やFoundation、Advanced、Primeのみです。

AIの行は二度読む価値があります。これがパッケージ全体を1行で表しているからです。人の手を介さずにチケットを実際にクローズできるAIは、Prime限定です。 FoundationとAdvancedが得られるのはあくまで補助的なAI、つまり要約、下書き、チャットボットです。あるServiceNow MVPもコミュニティ上で、カスタム構築について同じ趣旨のことを述べており、Primeは「プラットフォーム上で新規のカスタムAIスキルやAIエージェントを構築できる唯一のティアである」としています。つまりAI Agent Studioはプラットフォーム全体の機能ではなく、最上位ティアの機能であり、より詳細な費用の全体像はServiceNow AI料金の内訳にまとめています。

この区分はServiceNow自身のマーケットプレイスにも表れており、L1 IT Service Desk AI Specialistは、Fulfillerを独自のライセンスクラスとして名指しするペルソナフィルターと並んで表示されています。

実際に課金対象となるのは誰か

「ServiceNowの費用はいくらか」という問いに答えを出せる唯一の事実がこれです。ITSMでは、Fulfillerロールに基づいて課金されます。ライセンスガイドを書いたあるServiceNowの社員は、これを「コアとなるサービスデスクエージェント、ケースマネージャー、ワークフローの担当者。実際に業務を行い、レコードを解決する人」と定義しており、過去365日以内にログインしたアクティブユーザーとしてカウントされます。

リクエスター、つまりチケットを起票する側の従業員はカウントされません。これは座席単位課金のツールに対する実質的なメリットであり、サポート用途においてJira Service Managementが通常のJiraより安くなるのと同じ種類の節約です。

ここで2つの例外が登場します。

承認のみを行うマネージャーは無料ユーザーではなく、別途メーターされるBusiness Stakeholderとしてカウントされます。また一部の製品はUnrestricted Userモデルで課金され、インスタンス上のアクティブユーザー全員がカウント対象になります。HRSDとEmployee Center Proは、いずれもこのグループに属します。つまり「リクエスターは無料」という節約は、良いポータルを購入した日、あるいはHRが参加を望んだ日に消え去ります。

この判断の重みは決して小さくありません。あるServiceNow認定テクニカルアーキテクトは、公開の場でこう書いています。

"In the world of ServiceNow platform governance, one decision stands above the rest in terms of financial impact: choosing between the Fulfiller (Named User) and the Unrestricted User model. As a ServiceNow Certified Technical Architect (CTA), I've seen this single choice result in a $780,000 variance in spend over a standard 3-year contract."

Bill Martin, ServiceNow Community

すると、コメント欄にServiceNowの社員が現れ、もう一方のモデルについてよくある誤解を訂正しています。

"One quick correction though: Unrestricted Users (UU) aren't actually flat fee. They're still user-based. The "unrestricted" part means unlimited roles within the module, but if the customer's sys_user table grows, they're buying more UU licenses."

Lenny Leppers, ServiceNow Community

同じアーキテクトが指摘する、どの料金ページにも載っていない罠がさらに2つあります。ライセンスはインスタンス単位であるため、北米とEMEAで別のインスタンスを持てば請求額は2倍になります。また同氏は、大企業においてゴーストユーザーが「ServiceNowライセンスの20〜25%」を占めると指摘しており、これは年7〜12%の値上げと合わせて考える必要があります。交渉の最中であれば、ライセンスタイプガイドで全体像を確認してください。

公開されたアシストメーター

ここからが新しい話です。2026年7月23日、ServiceNowはNow Assist Overviewを法的文書として公開し、アクションごとのレートカードも同時に公開されました。この記事を書く8日前まで、これらの数字はどれも公開されていませんでした。

アシストとは「実行されたスキルアクションを通じてNow Assistスキルの利用状況を測定する単位」であり、「本番環境かサブ本番環境かを問わず」消費されます。エンタイトルメントはアカウント単位でプールされ、暦年ではなく購入契約の記念日にリセットされます。それを超過すると、「ServiceNowは超過分の利用について顧客に請求することがある」とされています。

3桁にわたる開きこそが、この話の核心です。

「エージェント型ワークフロー」は、完了時、20アクションに達した時点、または1時間の非アクティブ状態のいずれかで終了します。その20アクションを超えると、新たな課金対象のワークフローが開始されます。つまり1件のチケットが、実質2件分のコストになることもあります。

何度も立ち返ってしまう一節が、あるServiceNow実践者向けガイドにあります。「ほとんどのチームにとって驚きなのは、最も消費量が大きいのがプロンプトを入力するユーザーではないという点だ。バックグラウンドで動いている自動化こそが、その正体である」。そこでは静かに消費を積み上げる4つの原因が挙げられています。一致するトピックがない場合にVirtual AgentがNow Assistへフォールバックすること、ケースを開いた際に発火するワークスペースの要約、カスタムのSkill Kitスキル、そしてサブ本番インスタンスです。ServiceNowは2026年6月にこれらを抑えるためのキルスイッチとスパイクアラートを提供し、「サブ本番環境もアシストを消費する！」という理由で通知を無効化しないようドキュメントで明記しています。

ServiceNowは新しいティアについてプールサイズを公開していないため、最後に公開された割り当て、レガシーのPro Plusモデルにおけるフルフィラー1人あたり年間6,000アシスト、を基準に自分たちの数字を当てはめてみてください。

自律エージェントのスライダーを5%から15%に動かして、何が起きるか見てみてください。この1つの操作だけで、補助的なAIと、Primeを購入した理由である自律AIとの違いがすべて表れます。だからこそ私は、契約の会話の後ではなく最中に、書面でのアシスト予測を求めたいのです。

実際に使っている人たちの声

ここは公平でありたいと思います。不満を探し集めて糾弾記事を作るのは簡単です。

しかしレビュー全体を見ると、そうはなりません。ServiceNow ITSMは**G2上の1,915件のレビューで5点満点中4.5**を獲得しており、そのうち70%が5つ星、そして注目すべきは1つ星が0%であることです。Capterraでも352件のレビューで4.5を獲得しています。インシデント、変更、CMDBのモデルそのものが間違っていると本気で主張する人はいません。

彼らが口にするのは「重い」ということです。G2自身のタグ集計では、Ease of Useが最も多く称賛される属性として168件のメンションを集めていますが、そのすぐ後ろにはLearning Curve（72件）、Expensive（60件）、Complexity（56件）が続きます。この緊張関係こそが、この製品を正直に要約したものです。

日々の使い勝手について。

"There's a lot of clicks which takes a long time"

Chris C., G2

立ち上がりの早さについて、それでも5点満点中4.5点をつけた開発者の声。

"ServiceNow IT Service Management is huge, and when I started as a developer, it took months to really understand how everything connects like tables, scripts, workflows, ACLs. The documentation exists but is scattered, and half the time, you end up finding answers in community forums instead of official docs."

Shruti C., Developer, G2

そしてこの中で最も鋭い比喩、明らかにうまくいかなかった導入からの声です。

"Imagine you go to a car dealer to buy a new car. You pay the money and you get the keys. When you get outside to pick your new car you see a bunch of parts in a pile. So if you want to drive your car you need to put it together."

Verified User in Insurance, G2

その一方で、これはこの中で最も真実に近い指摘だと思います。ServiceNowについてのほとんどの人の意見は、実際にはその「誰かの導入」についての意見だということです。あるHacker Newsのコメント投稿者は「うまく管理されたインスタンスは飛ぶように動く」と表現し、悪い体験の多くは「ひどいコードと出来の悪いLCNCアプリを引きずっている」顧客側の問題だとしています。これは私が見てきたものとも一致します。プラットフォーム自体が問題であることはめったになく、たいていはその上に誰かが作った400フィールドのフォームの方が問題なのです。

適した場面と、私なら使わない場面

ServiceNowが正しい選択となるのは、チケットそのものが本質ではない場合です。CMDBと紐づいたインシデント、本物のCAB承認を伴う変更管理、それを引き起こしたインシデントより長く残る問題レコード、さらにITとHRサポート、施設管理を横断する1つのワークフローエンジンが必要なら、ミッドマーケットにこれに匹敵するものはありません。Freshserviceと正面から比較しても、この幅広さこそがすべての論拠です。その規模であれば、その金額を払う価値があります。

私ならキューを回すためだけにこれを買うことはありません。 チケットを受けてさばくことだけが仕事のすべてなら、プラットフォームのごく一部しか使わないのにエンタープライズプラットフォームの価格を払うことになり、高価なチケッティングツールという不満は自然と出てきます。あるHacker Newsのコメント投稿者は、まさにそれをやったCIOについて語っていました。CMDBも変更管理もない、たった2つのキューのために既存のトラッカーを置き換えて「年間128k」を払っていたというのです。もしあなたのニーズがそういう形なら、小規模チーム向けまとめやオープンソースの選択肢の方が正直な答えです。

3つ目のケースこそが興味深く、この記事を読んでいるほとんどの方が実際に置かれている状況でしょう。ServiceNowはすでに導入済みで、どこにも行かず、キューは今も増え続けている。 撤去するという選択肢はテーブルに乗っていません。AIスペシャリストがティア1のチケットをクローズできるようPrimeティアを追加するのは、非公開のメーターがついてくる予算の話です。そうなると残るレバーは1つ、あらゆるITヘルプデスクAIプロジェクトが最終的に行き着く、受付時点でのデフレクションです。

ServiceNowのキューの手前にeeselを置く

ここで何を提供していて、何を提供していないのか、率直にお伝えします。そのほうが結局は役に立つはずです。

eeselはServiceNowのプラグインではありません。 私たちのインテグレーションページにServiceNow連携は掲載されていません。トライアルの途中で気づかせるより、ここではっきり伝えておきたいと思います。

eeselが行っているのは、ITに関する質問が実際に発生する場所の1歩手前に立つことです。誰かがフォームを開く前に、Slack、Microsoft Teams、メール上で回答します。回答の元になるのは、すでに書かれているドキュメントで、それが今どこにあっても構いません。Confluence、Google Docs、Notion、ヘルプセンターなどです。

私自身がこの仕組みを作るエージェント開発者なので、その中身にこだわりがあります。エージェントは実際のドキュメントを検索し、根拠があるときにだけ回答し、根拠がなければ黙ります。この最後の部分こそがすべてです。自信満々に聞こえるボットが本番のキューで誤った回答をするのを見てきたからこそ、今では実際の人に触れる前にすべてのロールアウトを過去のチケットに対してシミュレーションし、確信度の基準を下回るものは推測するのではなくエスカレーションします。

私が示したい数字は、私たち自身のものではありません。InDebted社のHead of ITであるJason Loyola氏は、社内ITデスクの一次対応としてeeselを運用しており、その成果は公開されています。現在、受信した問題の15%が完全にデフレクトされており、解決済みチケットからナレッジが書き戻されるにつれて、目標は55%とされています。同氏はこの仕組みについて「実質的に、まるでエージェントのように機能している」と述べています。

試す前に知っておくべき制約があと2つあります。ドキュメントの問題そのものは解決しません。「新しいノートパソコンはどうやって手に入れるか」という質問への答えが社内ナレッジベースのどこにも書かれていなければ、どんなAIもそれを作り出すことはできません。そしてこれは置き換えではなくレイヤーであるため、インシデントや変更、CMDBのモデルはそのまま残ります。料金は座席単位ではなく処理したチケット単位で発生するため、少なくともITチームが人を増やすたびに請求額が跳ね上がることはありません。

無料で試すことができます。サービスデスクが月に50回も答えているような質問を投げかけて、そもそもチケットを必要としたものがどれだけあったか確かめてみてください。