
ServiceNow が実際に発表したこと
5か月の間隔をあけた2つの発表があり、これらは常に混同されている。
2026年1月28日、Anthropic と ServiceNow は、Claude が ServiceNow Build Agent を動かす標準モデルであり、ServiceNow AI Platform 全体における優先モデルであると発表した。ServiceNow はまた、Claude と Claude Code を社内で29,000人以上の従業員に展開し、営業担当者の商談準備時間を最大95%削減したと報告している。Bill McDermott はこれを、仕事のやり方そのものを再構築するものだと位置づけた。Dario Amodei の言葉は、AI が後付けされるのではなく、日々の仕事に織り込まれるというものだった。
続いて2026年5月5日、Knowledge 2026 において ServiceNow はAction Fabric を発表した。これは一般提供された MCP サーバーを通じて、あらゆる外部エージェントにプラットフォームを開放するものだ。Anthropic は最初のデザインパートナーとして名前が挙がり、Claude Cowork を ServiceNow が「システム・オブ・アクション」と呼ぶものに接続する。Anthropic の Claude Code 責任者である Boris Cherny は、何をすべきかを知ることと、それを実際に実行することとの間のギャップを埋めることについてコメントを引用されている。
この2つを合わせて読むと、話としては説得力がある。ServiceNow 自身の説明では、他のプラットフォームはエージェントにデータの読み書きを許すだけだが、ServiceNow はフロー、プレイブック、承認、カタログといった統制された業務の実行を許すのだという。
ここからが、プレスリリースが省いている部分だ。MCP サーバーは Now Assist と AI Native の SKU に含まれており、ヘッドレスなアクションは Now Assist や AI Agents と同じアシストという通貨を消費する。この一文は Action Fabric の投稿自体の、末尾近くにイタリック体で書かれている。これがこのインテグレーションの商業的な形のすべてであり、以下すべてはここから導かれる。
ドキュメントを読みに行くならもう1点触れておきたい。ServiceNow はリブランディングの真っ最中だ。ドキュメント全体にわたるバナーには、ServiceNow Otto が新しい AI エクスペリエンスのブランドだと記されており、コミュニティ記事の URL もすでに now-assist-articles から servicenow-otto-articles へと変わっている。製品は同じ、名前は新しい、ドキュメントは移行途中だ。
Claude が ServiceNow インスタンスに到達する4つの方法

ルートは4つあり、それぞれ同等ではない。
| ルート | 内容 | 利用できる対象 | コスト |
|---|---|---|---|
| MCP Server Console | ServiceNow 独自の MCP サーバー、2026年5月から一般提供 | Now Assist または AI Native の SKU が必要。AI 管理者が設定する | 呼び出しごとのアシスト、スキルごとにプラス1 |
| オープンソースの MCP サーバー | Table API にアクセスするコミュニティ製の Python または Go サーバー | インスタンスと認証情報を持つ誰でも | 自前のホスティング。アシストは不要 |
| Build Agent | アプリやフローを書くために ServiceNow の内部で動く Claude | Build Agent を利用する ServiceNow 顧客 | ServiceNow 製品として価格設定 |
| Action Fabric 経由の Claude Cowork | Cowork の内部から行う統制されたプラットフォームアクション | デザインパートナー・ロードマップの段階 | 広く提供されればアシスト課金 |
最初の2つは今日から使えるルートだ。3つ目は逆方向を向いていて、Claude があなたのキューの中ではなく ServiceNow の上で作業する。4つ目はプレスリリースが最も声高に語っているルートであり、今のところ最も信頼できる形では購入できないルートでもある。
公式ルート:MCP Server Console
MCP Server Console はサポートされている答えであり、ServiceNow のドキュメントは Microsoft Copilot と並んで Claude を明示的にクライアントとして挙げている。

4つの Quickstart ツール
始めるために何かを構築する必要はない。あらかじめ設定済みの Quickstart Server があり、それが公開する範囲はこれがすべてだ。
| ツール | 内容 |
|---|---|
| インシデントレコードの検索 | 要約できるようにインシデントを見つける |
| ケースレコードの検索 | 要約できるようにケースを見つける |
| インシデントの要約 | インシデントの Now Assist による要約を返す |
| ケースの要約 | ケースの Now Assist による要約を返す |
検索2つと要約2つ。ServiceNow における Claude の標準体験は「読んで要約する」ことであり、「行動する」ことではない。「未対応のインシデントをすべて取得して」や「今週クローズしたケースをすべて要約して」と頼めば、うまく機能する。しかし P1 の再割り当てや変更の承認、カタログアイテムの発行を頼んでも、誰かがツールを作るまではそのためのツールは存在しない。
これは、Atlassian の Rovo MCP サーバーで見つけた4つのオンコールツールよりも狭い標準構成であり、Claude for Confluenceの記事で紹介した12個の Confluence ツールよりもはるかに狭い。この違いは意図的なものだ。Atlassian は固定のツール一覧を提供し、ServiceNow はビルダーを提供する。
それ以上に構築できるもの
MCP Server Console のツールは5つのカテゴリから来ており、まさにここでプラットフォームの奥深さが実際に現れる。
- REST API は、Table API を含むインスタンス上の任意のエンドポイントをラップする。
- Action と Subflow が興味深いのは、単なるデータアクセスではなく統制された業務そのものだからだ。ServiceNow 自身のドキュメントは、subflow と action によってエージェントがクライアントを離れることなくリクエストを送信し、承認へルーティングし、結果を確認できると説明している。
- Knowledge Graph は、単純なレコードの読み取りではなく、稼働中のインスタンスデータに対する関係性を意識したクエリを提供する。
- Now Assist skill は、AI Skill Kitによるカスタムスキルを含め、既存のスキルを公開する。
ツールごとに、個々の入力項目をオフにしてクライアントに届かないようにできるが、必須の入力項目の一部はオフにできない。このフィールドレベルの制御こそ、この構成全体で最も優れたガバナンス機能であり、Table API を丸ごと公開するのではなくツールを構築すべき理由だ。
構築中に痛い目を見る、ドキュメントに書かれた2つの摩擦点がある。Now Assist スキルからツールを作った後にそのスキルへ入力項目を追加すると、既存のツールを編集するのではなく、代替ツールを新たに作ることになる。そしてツールの作成には最低でも Zurich patch 9 または Australia patch 2 が必要で、これは MCP サーバー自体を手に入れたパッチレベルよりも新しい。
Claude を ServiceNow に接続する方法
この接続はクリックするディレクトリ一覧ではなく、OAuth のハンドシェイクだ。Claude のコネクタディレクトリにワンクリックの ServiceNow エントリはなく、これがFront の公式 MCP サーバーのようなものとの主な実務的な違いだ。
- 要件を満たす SKU を用意する。 ServiceNow 自身の前提条件リストによれば、Now Assist(Pro Plus、Enterprise Plus)または AI 系の SKU が必要だ。同じリストには、Zurich Patch 4 以上、AI Agents ストアアプリの6.x以上、MCP Client ストアアプリの1.1以上も含まれる。
- サーバーを選ぶか作成する。
All > MCP Server Console > Configuration > Serversにある。まずは Quickstart Server を使い、IT 用と人事用のように限定したツールセットが欲しくなったら自分のサーバーを作成する。 - 必要なら自分でツールを作る。
Configuration > Tools > Create toolからカテゴリを選ぶ。必要なロールはsn_mcp_server.tools_admin、sn_mcp_server.admin、またはadminだ。すべてのサーバーには少なくとも1つのツールが必要になる。 - Claude 用の受信 OAuth インテグレーションを作成する。 クライアントごとに1つずつ。ここからクライアント ID とシークレットが得られる。
- Claude をサーバーに向ける。 URL のパターンは
https://<instance>.service-now.com/sncapps/mcp-server/mcp/<server-name>で、Quickstart Server の場合の名前はsn_mcp_server_defaultだ。認証タイプは汎用の OAuth 2 アイデンティティプロバイダーによる OAuth 2.0 で、認可は/oauth_auth.do、トークンは/oauth_token.do、失効は/oauth_revoke.do、コールバックは/oauth/callback、スコープはmcp_serverだ。 - プロンプトを送る。 Claude は
Authorization: Bearer <token>を送信し、サーバーはそれを検証してツール一覧を返す。結果は JSON として返り、クライアントがそれをテキストとして表示する。
インスタンスがすでにパッチ適用済みで、sn_mcp_server.admin を持つ人が同席していれば、1時間見ておけばよい。Now Assist の SKU がまだ契約されていないなら、調達サイクル分の時間を見込んでおく必要がある。
Claude の1回の呼び出しに実際いくらかかるのか

これが安いか高いかを決める一文が、ServiceNow 自身の MCP FAQ にそのまま書かれている。MCP サーバー経由でツールとして公開された Now Assist スキルは、呼び出されると通常のアシスト数にプラス1アシストを消費する。
この上乗せ分は定額であるため、スキルによって影響がまったく異なる。インシデント要約は1アシストのスキルなので、Claude から呼び出すと2アシストになり、最も安くやりたいことに100%のオーバーヘッドがかかることになる。250アシストの作業ノート分析であれば、同じ1アシストの上乗せを払っても、ほとんど気づかれない。公開されている料金表では、Virtual Agent のトピックとチケットアクションはそれぞれ10アシスト、エージェント型ワークフローは触れるツールの数に応じて25、50、150アシストとされている。
アシストはアカウントレベルでプールされ、本番インスタンスと非本番インスタンスの間で共有され、購入日の記念日にリセットされる。そのため、開発インスタンスで実験しているチームも、本番キューが引き出しているのと同じプールを消費していることになる。
ここから見えてくる形は直感に反する。MCP の上乗せ料金は、Claude にやってほしいと最も思うような安価で高頻度な読み取り作業をまさに罰する形になり、逆に高額なワークフローではノイズに埋もれてしまう。「IT 部門の全員が一日中 Claude でインシデントを要約する」という計画であれば、まさにその追加アシストが消費量を倍にするケースになる。
私は購入者がこの壁にぶつかるのを何度も見てきた。ある案件では、Freshdesk を使い年間2万件のチケットに向けて拡大しているメールセキュリティ企業が、たった1日のテストで200回分の従量課金インタラクションを消費し、実際の運用量になったときの数字をすぐに心配し始めた。別の案件では、非常に大規模な運用者が、インタラクション単位とチケット単位の違いを通話の途中で混同してしまい、誰かが計算を訂正する前に自社の月額コストを約3万ドルと見積もっていた。従量課金の AI 料金体系自体が間違っているわけではない。ただ、実際に運用してみるまで予測が非常に難しいのだ。だからこそ私は今、誰かが本番で有効化する前に、必ず顧客自身の過去のチケット履歴に対して eesel のロールアウトをシミュレートすることを徹底している。
公式ルートの限界
導入を決める前に知っておくべき6つの限界がある。どれも秘密にされているわけではなく、すべて ServiceNow のドキュメントと FAQ に記載されている。これは、多くのベンダーが公開している内容よりも多い。
リモートトランスポートのみ。 ストリーミング HTTP と SSE がサポートされている。stdio はサポートされておらず、ローカルの MCP サーバーはそもそもサポート対象外だ。Claude の MCP 設定について、JSON ファイル内のローカルコマンドというイメージを持っているなら、その形はここには当てはまらない。
MCP プロトコルは2025-06-18。 これがサポートされている仕様バージョンだ。MCP のリソースとプロンプトはまだサポートされていないが、ServiceNow によればセーフハーバーの下でロードマップに載っているという。
サーバーは GCC 非対応。 MCP クライアントと A2A は GCC 上で動作する。Zurich patch 4 の FAQ によれば、MCP サーバーは動作しない。米国連邦政府向けインスタンスにとっては、これで公式ルートは完全に閉ざされる。
データがインスタンスの外に出る。 MCP Server Console のドキュメントは、このアプリケーションが顧客インスタンスから集中管理された ServiceNow 環境へ、場合によっては異なるデータセンターのリージョンへ、そして場合によっては Microsoft Azure のようなサードパーティのクラウドプロバイダーへとデータを転送する必要があると明記している。データレジデンシーに関する自社のコミットメントを念頭に置いてこれを読んでほしい。
入力と出力はデフォルトでモデル開発に利用される。 同じドキュメントページには、ServiceNow が入力、出力、出力への編集内容を収集し、自社技術の開発と改善のために利用すると書かれており、Now Assist のオプトアウトページからオプトアウトできるとされている。オプトアウトするということは、実際に誰かがそれを実行しに行かなければならないということだ。
クライアントごとに1つの OAuth インテグレーション。 これが設計であり、合理的ではあるが、2つ目の AI アプリケーションをオンボードするには、チェックボックス1つではなく、また別の管理タスクが必要になるということだ。誰が何を呼び出したかを確認するには、AI Control Tower の AI Gateway を見に行くことになる。
それでもチームがオープンソースに手を伸ばす理由
コミュニティ製の MCP サーバーは、決してマイナーな存在ではない。最も有名なechelon-ai-labs/servicenow-mcpは、286個のスターと225個のフォークを持ち、MIT ライセンスで、インシデント、変更要求、サービスカタログ、ナレッジベース、ユーザーとグループ、ワークフロー、スクリプトインクルード、チェンジセット、アジャイルストーリーにまたがるツールを提供している。ベーシック認証、OAuth、API キーをサポートし、stdio または SSE 上で動作し、service_desk、change_coordinator、knowledge_author のようなロールベースのバンドルによるツールパッケージングの仕組みを備えており、公開するツール数を適切な範囲に保てる。
人々がこれらを使う正直な理由はライセンスであり、r/servicenow はそれをはっきりと口にしている。
"These open source ones that keep popping up are more-so alternatives if your company doesn't want to purchase now assist licensing."
同じスレッドには、ServiceNow が無料版を決して出さないだろうと予測する、もっと辛辣なコメントもある。
"ServiceNow most definitely won't give customers something for free when the alternative is to charge you in assists. If they could charge you assist to log in to your instance, they would."
この見方には少し異論を唱えたいし、それは公平に唱える価値がある。ServiceNow は実際に MCP サーバーを出荷し、それは確かに一般提供されており、ドキュメントは何をカバーし何をカバーしないかについて異例なほど具体的だ。ただ無料ではないというだけであり、無料であるふりもしていない。
とはいえ、オープンソースを選ぶことで失うものは実在する。より新しいコミュニティサーバーのメンテナーは、ガードレールについて直接尋ねられ、MCP 側はデフォルトでガードレールが組み込まれていない生のツール集合であり、それをどう使うかはクライアント側が決めることになると答えている。これがトレードオフだ。公式サーバーはフィールドレベルの入力制御、OAuth、AI Control Tower を通じた監査証跡、ツールごとの計測を提供する。生の Table API ラッパーは、サービスアカウントがアクセスできるものすべてを即座に与えてくれる。
こうしたスレッドには、そのどれも欲しくなかったという人による、真剣に受け止める価値のある第3の立場もある。
"Claude has built perfectly fine servicenow fluent code for me without any external tooling whatsoever."
スクリプティングや Fluent の作業については、それはしばしば当てはまる。MCP が真価を発揮するのは、Claude が稼働中のインスタンスの状態を必要とするときであって、すでに書き方を知っているコードを書く必要があるときではない。
自前でサーバーを構築したあるチームの、Australia patch 4 リリース時点での現場メモがある。唯一のつまずきは認証だった。現時点で CMDB Search は admin アカウントでは動作しないが、読み取り権限を持つ他のアカウントであれば問題なく動作するという。これは、誰も警告してくれなければ半日を無駄にする類の詳細だ。
Build Agent:逆方向を向いた Claude
これは切り分けて考える価値がある。「Claude for ServiceNow」という検索の意図が、実はこちらを指していることが多いからだ。
Build Agent は、アプリや自動化を構築するための ServiceNow のバイブコーディング製品であり、Claude は今やその裏側にある標準モデルだ。ServiceNow は今後12か月で Build Agent の利用が4倍になると見込んでおり、Claude をループに組み込んだ顧客の実装までの時間を50%削減することを目標にしている。これは、Claude がプラットフォームの上に何かを構築し、スコープの定まったアプリケーション、フロー、コンフィグレーションを生成するという話だ。
コミュニティが Build Agent と MCP ルートの間で行っている区別は有用だ。Build Agent は ServiceNow SDK と Fluent を中心に構築されており、承認済みの変更をそれぞれ独立した update set にデプロイし、新規のスコープ付きアプリケーション向けに設計されているため、アーティファクトをゼロから作る傾向がある。一方、Table API ベースの MCP サーバーはすでに存在するものに対して作業し、通常の手動変更と同じように現在の update set に変更を反映する。
あなたがServiceNow の開発者であれば、2つのうちおそらく Build Agent のほうが興味深いだろう。サービスデスクを運用しているなら、それはあなたが探していたツールではない。
誰もあなたのキューを見ていない
これは、展開に四半期をかける前に知っておきたい部分だ。
上記のルートはすべて人間が起点になる。人が Claude を開き、プロンプトを入力し、ツール呼び出しが発生する。MCP サーバーがITSM のキューに新しい P2 が着地したことに気づき、既知のパターンに一致すると判断し、返信を下書きして投稿する、といったモードは存在しない。Action Fabric 自身の例でも、プロダクトマネージャーが自分に足りないアクセス権について Claude に質問し、その後リストを確認して承認する、という流れになっている。統制されていて、監査可能で、有用ではあるが、それでもトリガーするのは人間だ。
このギャップの意味は、あなたが誰であるかによって変わってくる。
- ServiceNow の開発者や管理者は、ほとんど何も失わない。もともとタイプするのはあなただったからだ。
- IT 運用のリーダーは、インスタンスをはるかによく把握でき、より速いインシデント要約を得られる。これは実質的な価値だ。
- デフレクション率で評価されるサービスデスクマネージャーは、直接的には何も得られない。デフレクションには、人間が関わる前に回答する仕組みが必要であり、それこそVirtual Agentの役割だ。そして Virtual Agent 自体のエントリーティアの制限についてはまた別の話になる。
初回対応解決率を上げたり、社内ヘルプデスクのチケット量を減らしたりする目的でこれを検討しているなら、MCP サーバーは間違った道具だ。それは別の目的にはとても良い道具である。
Claude か Now Assist か:どちらがあなたのインスタンスに触れるべきか
実際には競争関係ではないが、私が使う使い分けを示す。
| やりたいこと | 使うもの | 理由 |
|---|---|---|
| チャットウィンドウからインスタンスのデータを読み取って要約したい | MCP Server Console 経由の Claude | 最良の読み取りモデルで、4つのツールがすぐに使える |
| アプリ、フロー、Fluent コードを構築したい | Build Agent | Claude はすでにそこでの標準モデルだ |
| ServiceNow のワークフロー内でスクリプト化されたスキルを実行したい | Now Assist スキルを直接使う | MCP を経由しなければ追加のアシストを避けられる |
| チャットツールから統制されたプラットフォームアクションを実行したい | Action Fabric | 承認とプレイブック、単なるレコードの書き込みだけではない |
| 人が先に指示しなくてもチケットを解決したい | どちらでもない | 上記のどれも無人運用ではない |
強調しておきたい一文がある。MCP 経由で Now Assist スキルを呼び出すのは、同じスキルをネイティブに呼び出すよりもコストが高くつく。あるスキルがどのみち ServiceNow のワークフロー内で実行されるのなら、形だけのために Claude 経由にする必要はない。
ServiceNow チームのための eesel AI
まず率直な答えから。eesel には ServiceNow ITSM とのネイティブなインテグレーションはない。3段落先で気づかせるより、はっきり最初に言っておきたい。
eesel がやっているのは、MCP Server Console が構造的にカバーしない無人運用の半分だ。ヘルプデスクとナレッジに接続し、自社の過去のチケットとドキュメントで学習し、誰かがチャットウィンドウを開いて質問するのを待つのではなく、自律的に会話を処理する。これこそ、サービスデスクマネージャーが「Claude for ServiceNow」と検索してたどり着いたときに、本当に探しているものであることが多い。

上のアシストの計算を読んだばかりなら重要になる、3つの違いがある。
- 本番稼働の前にシミュレーションする。 eesel は実際の過去のチケットに対してエージェントを動かし、本番のキューに触れる前に、エージェントが何を言い、何を解決していたはずかを見せてくれる。これが存在するのは、私が自信ありげに聞こえるボットが本番で間違った回答をするのを何度も見てきたからであり、実際の履歴に対するドライランこそが、それを事前に知る唯一の正直な方法だからだ。
- チケットごとにたった1つの数字。 対応したチケットまたはチャット1件につき0.40ドルであり、スキルごとに異なるレートと非公開の超過料金を持つアシストのプールではない。封筒の裏でざっくり見積もることができる。
- 社内デスクでも機能する。 eesel はSlack、Microsoft Teams、メールを通じて社内側の対応を処理する。Confluenceやその他の社内ソースから読み込み、実のところ ServiceNow に隣接するITSM 自動化の多くの作業はそこで行われている。
ServiceNow を運用していて、何かにコミットする前に、無人エージェントが自社のチケット履歴に対して何をするか見てみたいだろうか。そのためにデモがあり、トライアルは無料だ。
私の結論
すでに Now Assist の SKU を持っているなら、今週のうちに MCP Server Console 経由で Claude を接続しよう。管理作業は1時間程度で、Quickstart Server はすぐに役立つ読み取り・要約機能を提供してくれるし、フィールドレベルの入力制御は、どんなコミュニティサーバーが提供するものよりも優れたガバナンスだ。
Now Assist を持っておらず、これのためだけに購入するかどうかがそもそもの論点であるなら、冷静になったほうがいい。4つのツールとビルダーを手に入れるために、すでに安くはない ServiceNow のライセンスに加えて、プラットフォームの AI 層をライセンスすることになる。コミュニティ製の MCP サーバーは無料で、ほとんどの読み取りユースケースをカバーするが、その代償としてガードレールも計測もない。
そして、もしあなたが本当に欲しかったのがチケットについてのより良い回答ではなく、チケットの数そのものを減らすことだったなら、この4つのルートのどれもそこには連れて行ってくれない。それは別のツールの仕事であり、四半期が始まった後ではなく、始まる前にその違いを言葉にしておく価値がある。
よくある質問
Claude を ServiceNow に接続するには?
https://<instance>.service-now.com/sncapps/mcp-server/mcp/<server-name> に Claude を接続する。トークンが検証されると、Claude はサーバーのツール一覧を受け取る。より詳しい手順はServiceNow の MCP インテグレーションのガイドにまとめている。Claude for ServiceNow は無料か?
Claude は ServiceNow で実際に何ができるのか?
ServiceNow の MCP サーバーは Claude Desktop と Claude Code で使えるか?
ServiceNow は Claude の1回の呼び出しにいくら課金するのか?
Claude は ServiceNow のチケットに自律的に回答できるか?
ServiceNow を Claude に接続するのは安全か?
ServiceNow の業務では Claude は Now Assist より優れているか?

Article by
Kurnia Kharisma Agung Samiadjie
Kurnia is a software engineer and writer at eesel AI with two years of SEO experience, writing about AI tools, helpdesk software, and customer support. He pairs a developer's understanding of how these products are built with search-driven research into what actually ranks and resonates with the people searching for them.








