ServiceNowにAIを追加する方法：2026年実践ガイド

まず、私の立場について

私は統合機能やAI機能を構築する仕事をしているため、「XにAIを追加する」というプロジェクトに対しては、デモを無視して、実際のチケットが流れ込んだときにそれが何をするのかを問う癖があります。自信満々に見えるAIが、実際のサポートキューで自信満々に間違った回答をする場面を何度も見てきました。だからこそ私たちのチームは、顧客に触れる前に必ず過去のチケットに対して展開をシミュレーションします。これを述べるのは、まさにServiceNow管理者がNow Assistで繰り返しぶつかっている失敗のパターンだからであり、以下のすべての推奨事項はこの視点に基づいています。

ServiceNowは優れたシステムオブレコードです。フォーチュン500の大部分でIT、HR、カスタマー向けワークフローを支えており、そのワークフローエンジンはGartner Magic Quadrant Leaderの評価に恥じない実力があります。以下の内容はそれを批判するものではありません。あくまで、そこにAIを組み込んだときに具体的に何が起きるかについての話です。

2026年における「ServiceNowにAIを追加する」の実際の意味

ServiceNowには単一のAIスイッチはありません。存在するのはスタックであり、何かを触る前にそのレイヤーを把握しておくと役立ちます。

基盤となるのは、すでに契約しているITSM、CSM、またはHRSDプロダクトであるプラットフォームライセンスです。そのワークフローの内側にあるのがNow Assist、つまりインシデントおよびケースの要約、解決メモの作成、返信の提案、ナレッジ生成といった生成AIスキル群です。その上にあるのが、より新しいAI Agentsレイヤーで、支援するのではなく自律的に行動するエージェントであり、AI Agent Orchestratorによって連携されます。全体を統括するのがAI Control Towerで、プラットフォーム上で動くすべてのAIを監視・統制する中心的なハブです。

2026年の大きな変化は、ServiceNowがNow Assistを再構築し、買収したMoveworksの会話型AI、そして「AI Experience」を、ServiceNow Ottoという一つの統合された体験にまとめようとしていることです。ServiceNowは、これは単なる名称変更以上のものだと明言しており、単に新しいラベルを付けたNow Assistではなく、"体験の根本的な転換"だと説明しています。現時点では両方の名前が使われているのを目にするでしょう。「Now Assist」は現行のITSMのパッケージングや価格表に今も登場しますが、「Otto」がこれからの方向性です。今日AIを追加するという目的においては、両者を同じものとして扱って構いません。

始める前に：誰も言わない3つの前提条件

1. 適切なライセンスティアが必要

Now Assistはこれまで単独のプロダクトとして存在したことはありません。ライセンスに関するServiceNow Communityの回答は率直です。"はい、Now Assistのライセンスは別途必要です"。そしてまず、基盤となるITSM、CSM、HRSD、またはCreatorのサブスクリプションが前提として必要になります。

必要なティアは、契約したタイミングによって異なります。旧モデルでは、Now Assistは「Plus」SKUへのアップグレードによって解放されました。Now Assist FAQは管理者に対して「インスタンスがPro Plus/Enterprise Plus SKUの権利を持っていることを確認してください」と案内しています。2026年4月、ServiceNowは"旧来のStandard、Professional、Enterprise構成を完全に廃止"し、それぞれにNow Assistがバンドルされた3つのAIネイティブなティアに切り替えました。

実務上の結論はこうです。誰もが本当に欲しがっている完全自律型のエージェントはPrimeティアにあります。要約やドラフト作成といった支援的なスキルは、それより下のティアに含まれます。

2. データがクリーンでなければならない

これが導入を頓挫させる最大の要因です。Now AssistはナレッジベースとCMDBに基づいて回答を生成するため、それらが乱雑であれば、AIもその乱雑さをそのまま引き継ぎます。これはServiceNow管理者の間で最も繰り返される話題であり、後述の「本音」セクションで実際に彼らの声を紹介します。ここでは一点だけ。良い出力を期待する前に、ナレッジベースの整理に実際の時間を確保してください。

3. 「assists」の予算を誰かが管理する必要がある

Now Assistは消費量に応じて課金されます。座席を買うだけでなく消費量そのものを買っているのであり、誰かがそれを監視する必要があります。仕組みの詳細は「コスト」セクションで説明します。

ServiceNowにAIを追加する方法：ステップバイステップ

ステップ1：権利を確認する

何より先に、インスタンスがNow Assistの権利を持っているかを確認してください。2026年以前の契約であればPro PlusまたはEnterprise Plus SKUを、現行モデルであれば必要なAI機能を含むティア（Foundation、Advanced、Prime）を意味します。それが無ければ、これは設定作業ではなく、アカウントマネージャーとの調達の話になります。ServiceNowはライセンスの詳細を公開サイトには載せていないためです。

ステップ2：Now Assistプラグインを有効化する

権利が確認できたら、管理者は該当するワークフロー向けのNow Assistプラグイン（Now Assist for ITSM、Now Assist for CSMなど）を有効化し、プラットフォームの生成AIバックエンドを接続します。ServiceNowはこの点でモデルに柔軟であり、単一モデルに縛られるのではなく、OpenAIやAnthropicといったプロバイダーの大規模言語モデルを利用することも、自社のモデルを持ち込むことも可能です。

ステップ3：スキルとガードレールを設定する

Now Assistはスキル群として提供され、ワークフローごとに必要なものを有効化し、範囲を設定します。ITSMでは、エージェント向けの中核スキルはインシデントの要約、解決策の提案、そして返信のドラフト作成です。どのロールがどのスキルを利用できるかも決める必要があり、Primeティアでは、AI Agent Studioを通じて自律エージェントのガードレールを設定します。実際のプロジェクト時間の大半はここに費やされます。

ステップ4：ナレッジとCMDBに基づいて動作させる

Now Assistをナレッジ記事に接続し、生成AIスキルが正しいソースから情報を取得できるようにAI Searchを連携させます。ITワークフローでは、ルーティングや解決ロジックが正確な構成データに依存するため、CMDBはヘルプセンターと同じくらい重要です。このステップで「クリーンなデータ」という前提条件が現実味を帯びます。これを省くと、要約や提案は一般的すぎる内容や誤った内容として返ってきます。

ステップ5：Virtual AgentまたはAI Agentsを展開し、監視する

スキルの基盤が整ったら、いよいよ入口を公開します。ポータル、Teams、SlackをまたいだセルフサービスチャットボットとしてのVirtual Agentかもしれませんし、Primeであれば定型インシデントをエンドツーエンドで解決することを目指す自律型のL1 Service Desk AI Specialistかもしれません。その後はAI Control Towerで監視します。ここではassistsの消費量やエージェントの振る舞いにも目を配ります。稼働開始をゴールとして扱わないでください。それはチューニングの始まりであり、初日の解決率が90日目の解決率と同じであることはほとんどありません。

ITSM対CSM：エンジンは同じ、入口が違う

本ガイドの内容の大半は、社内IT（ITSM）にAIを追加する場合でも、社外向けのカスタマーサービス（CSM）にAIを追加する場合でも当てはまります。どちらも同じNow Assistエンジンと同じFoundation/Advanced/Primeのパッケージング上で動作するためです。

違いは対象者とリスクの大きさです。ITSM側では、AIは従業員に回答しており、間違った回答のコストは不機嫌な同僚と再オープンされたITヘルプデスクのチケットです。CSM側では、AIは顧客に回答しており、間違った回答のコストは信頼の失墜や返金です。これは、カスタマー向けの何かを自律的に動かす前に、動作基盤とテストのハードルを上げることを意味し、結局は同じ教訓に戻ります。まず実際のチケットで検証すること。ServiceNowのITSM向けAIを他のツールと比較検討しているなら、ITSM向けAIツール比較でさらに詳しく掘り下げていますし、Jira Service ManagementのAIについても同様の視点で解説しています。

実際にかかるコスト

ここが多くの人を驚かせる部分です。ServiceNowはNow Assistの定価を一切公開していません。専用のNow Assist料金ページは現在「ページが見つかりません」を返しますし、プロダクトページは価格の自動取得をブロックしています。すべての数字はアカウントチームによる個別見積もりであり、通常はNDA（秘密保持契約）の下で提示されます。

ServiceNow自身のコミュニティドキュメントとユーザーの声から言えるのは、コストがどのように構成されているかです。

• フルフィラーごと、月ごとの基本プラットフォームライセンス。 ServiceNowはユーザータイプ別に価格を設定しており、チケッティングシステムを扱う「フルフィラー」に対して代表的な料率を課しています。r/servicenowの「Costs」スレッドのあるユーザーは、ITSM Standardの定価として「フルフィラー1ユーザーあたり月100ドル」を挙げ、開始時の最低契約額は「約3万米ドル前後」と報告しています。
• その上に乗るAIティアのバンドル。 Foundation、Advanced、Primeのいずれを選ぶかによって独自の価格が発生し、PrimeはAdvancedの消費割り当てをおおよそ2倍にします。
• さらにその上に乗る、消費量ベースの「assists」。 ここが最も理解しておくべき部分です。Now Assistの消費量はassistsという単位で計測され、アクションの種類によってコストは異なります。コスト見積もりスレッドによれば、「インシデント要約は1 assistを消費するのに対し、アプリ作成は20 assistを消費する」とされ、assistsは非本番環境も含むすべての環境で消費されます。エントリー向けの「AI Starter Pack」は、25名のPro Plusユーザーに対して各6,000 assists（合計15万assists）を含みます。プールを使い切れば、追加購入が必要です。
• 導入作業と管理者トレーニング。 ServiceNowはスイッチを入れるだけのプロダクトではなく、展開作業自体が独立したコスト項目になります。

これらを積み重ねると、総所有コストは個々のコンポーネントの提示価格を大きく超えていきます。そして重要なのは、支出が人数だけでなく利用量に応じて増えていくことです。これは、座席単位の固定料金ツールとは全く異なる予算モデルです。

本音の部分：実際の管理者たちが言うこと

マーケティングの話だけで終えるのは、あなたに対して不誠実です。ServiceNowのAIは要約や解決メモに関して実際にファンがおり、G2では6,000件以上のレビューで5点中4.4点という堅実な評価を得ています。しかし、r/servicenowのコミュニティは、どこが物足りないかについて驚くほど率直であり、予算を投じる前にそのパターンを知っておく価値があります。

最も多い不満は、ティア1の対応削減が売り文句に対して期待通りの成果を出さないという点です。

「私たちはチケッティング、CMDB、変更管理、SLAなど、すべてにServiceNowを使っています。その部分は堅実で、取り外す予定はありません。しかし私たちは、チームを疲弊させているティア1の業務を実際に処理してくれることを期待してNow Assistを購入しました……代わりに得られたのは、ほとんどのことを結局人間に投げてしまう、少しだけ賢くなったバーチャルエージェントでした。ナレッジベースの回答は、一般的すぎるか、完全に間違っているかのどちらかです。」

u/AndroidTechTweaks, r/servicenow

しかし、重要な反論もあり、私自身が最も同意するのはこちらです。多くの失望はデータの問題であり、モデルの問題ではないというものです。

「これはNow Assistの問題ではなく、90%の場合は悪いデータが原因です。LLMに悪いデータでうまく機能することを期待するのは無理があります……多くの場合、長年積み重なった悪いデータのせいで、LLMが何が何だか分からなくなっているだけなのです。」

u/markbodman, r/servicenow

そして、ライセンスの複雑さは単なる不満ではなく、実際の導入の壁になっています。

「私の顧客の誰もそれを使いたがりません。ライセンスモデルが理解するには複雑すぎるか、高すぎるかのいずれかで、同じことのために2つのプラットフォームを持つことになっても、何とか回避する方法を探しています。」

u/Charming_Version_260, r/servicenow

一貫して言えるのは、冒頭で述べたことです。プラットフォーム自体は強力ですが、AIが成果を出すのは、データがクリーンで、かつ現実に対してテストされている場合に限られます。だからこそ私は、実際の過去のチケットでシミュレーションを行わずに、AIをサポートキューに稼働させることは絶対にしません。

避けるべきよくある間違い

• データが整う前に有効化してしまう。 最も多く後悔されるポイントです。まずナレッジとCMDBの監査を行ってください。AIは質の悪いヘルプセンターを補いきれません。
• 支援的なティアに自律的な解決を期待してしまう。 要約やドラフトは、エンドツーエンドの解決とは異なります。実際に行動するエージェントが欲しいなら、Primeティアと実効性のあるガードレールが必要です。
• 請求が来るまでassistsの消費量を無視してしまう。 assistsは非本番環境でも消費されます。初日から担当者を割り当て、監視してください。
• シミュレーションを省いてしまう。 AIの回答の最初の本当のテストを顧客にさせてはいけません。公開する前に、過去のチケットでテストし、測定してください。

サポートが社内ITではない場合の、より軽量な代替手段

ここまで読んで、本当の目的が社内ITワークフローではなく、カスタマー向けサポートの自動化だと気づいたなら、率直に言っておく価値があります。ServiceNowはそこに到達するには重量級の手段であり、より軽量な選択肢も存在します。

最初にはっきりさせておきます。eesel AIはServiceNowのアドオンではありません。ServiceNowのインスタンスに接続できるかのように振る舞うつもりもありません。eesel AIが実際に行うのは、Zendesk、Freshdesk、Gorgiasなど、eeselがネイティブに接続できるヘルプデスク上でカスタマーサポートを運用しているチームのために、AIサポートエージェントとして機能することです。ServiceNowのNow Assistルートがティアのアップグレード、導入パートナー、消費量メーターを必要とするのに対し、eeselは異なる形を取ります。

• 数分で接続し、学習します。 過去のチケット、マクロ、ヘルプセンターから自動的に学習するため、数週間かけてスキルを手作業で配線する必要はありません。
• 稼働前に過去のチケットでシミュレーションを行います。 これはまさに、上記のServiceNowにまつわる失敗談に欠けていた「現実に対してテストする」というステップです。
• 座席やassist単位ではなく、チケット単位で課金します。 そのため予算は、やり取りが増えるたびに膨らむのではなく、予測可能な形になります。

サポートが本当にServiceNow ITSM上で運用されているなら、本ガイドのNow Assistルートを進み、データへの投資を行ってください。ヘルプデスク上で運用されていて、来四半期ではなく今週AIを実証したいなら、デモを予約するか、無料でeeselを試して自社のチケットでシミュレーションを実行してください。どちらの場合も教訓は同じです。モデルは簡単な部分であり、データとテストこそが、そのAIが投資に値するかどうかを決めるのです。