ServiceNowの導入を考えるとき、「何人で使うか」は大切な情報です。ただ、それだけでは必要なライセンスは決まりません。お問合せをする人、対応する人、部門の状況を確認する人では、必要な利用権が異なるためです。
見積もりを依頼する前に、誰が、どの製品で、どの操作を行うのかを整理しておくと、導入後の使い方と費用を具体的に検討できます。
Fulfiller・Requester・Business Stakeholderの違い
ServiceNowには複数の利用者区分があります。ITSMなどの利用権資料に登場する代表的な区分が、Requester、Fulfiller、Business Stakeholderです。
Requester（リクエスター）は、自分の依頼を登録・確認したり、ナレッジを検索したりする利用者です。
Fulfiller（フルフィラー）は、RequesterやBusiness Stakeholderに認められた範囲を超える操作を行う利用者です。例えば、サービスデスクで他の利用者からのお問合せに対応し、記録を更新する担当者が該当します。管理者や開発者だけを指す言葉ではありません。
Business Stakeholder（ビジネスステークホルダー）は、対象製品の契約範囲内で、承認やレコード・レポートの閲覧などを行う利用者です。実際に閲覧できる情報は、アクセス権の設定にも左右されます。
「閲覧だけ」「承認だけ」も、操作を具体的にする
同じ「状況を確認する」でも、自分のお問合せを見るのか、部署全体の案件を見るのか、レポートから個別の記録まで確認するのかで、必要な利用権は変わります。「更新しないからライセンスは不要」とは判断できません。
また、管理職だからBusiness Stakeholder、担当者だからFulfillerと、役職だけで決めることもできません。承認に加えて内容の修正や対応作業を行うなら、その操作まで含めた確認が必要です。利用頻度が低い人も含め、必要な権限と人数を洗い出しておきましょう。
利用者の区分と、製品の契約範囲は別に確認する
Fulfillerの利用権があっても、ServiceNowのすべての製品を使えるわけではありません。ITSMに加えてCSMを利用したり、App Engineで独自アプリを展開したりする場合は、それぞれの利用権を確認します。
契約には、権限に応じて利用者を数える方式のほか、全アクティブユーザーを対象とするUnrestricted Userなどもあります。選べる方式は製品や契約条件によって異なるため、全社人数だけでなく、利用者の役割と展開予定も伝えることが大切です。
なお、ロールを付与して操作できる状態になっても、必要な利用権を契約しているかは別に確認します。導入済みの場合は、契約数とロールの付与状況を照らし合わせることも必要です。
アプリの追加開発やAI活用も見据える
独自アプリの開発では、App Engineやカスタムテーブルの利用条件も確認します。契約にテーブル数の余裕があっても、どの業務にでも使えるとは限りません。既存製品の拡張なのか、新たな業務アプリなのかによって、確認すべき範囲が変わります。
生成AIやAI Agentの活用では、対象機能に加え、「Assist」などの利用量の単位、契約に含まれる量、超過時の条件も確認します。誰が使うかに加え、どんな処理をどれくらい実行するかが、費用を考える材料になります。
パッケージも更新されており、2026年11月時点の米国公式ITSMページでは、Foundation、Advanced、Primeが案内されています。既存契約の見直しでは、現在の注文書と利用権資料を確認したうえで、今後の選択肢を比較しましょう。
今の利用と、次の展開を一緒に考える
最初からすべての要件を決める必要はありません。まずは、対象業務、利用者ごとの操作と人数、追加したい機能を共有するところから始められます。
シスラボでは、ServiceNowのライセンス販売から導入・開発、運用改善までご相談いただけます。お客様の業務と今後の展開を伺い、必要な利用権と実装方法を一緒に検討します。
※2026年11月時点の公開資料に基づきます。実際の利用権・料金は、適用される注文書と契約条件をご確認ください。
