Claude ServiceNow連携の使い方 — 接続の前提と実行例

Claude ServiceNow連携とは何をするコネクタか

ClaudeからServiceNowの業務ワークフローを実行するコネクタです。公式ページの説明は、ServiceNow Action Fabric経由でClaudeに接続する、というものです。IT・HR・カスタマーサービス・セキュリティ・リスクなどの部門横断ワークフローを、既存のServiceNowの権限とセキュリティ制御を守ったまま実行できます。コネクタ一覧には「Sign-in Required」と表示され、ServiceNowの管理者が組織向けに用意している場合は、使えるツールがその設定を反映します。

土台はServiceNowの「MCP Server Console」です。ServiceNowのコミュニティ記事によると、管理者がServiceNowの機能をMCPツールとして公開します。Moveworks・Copilot Studio・Claude・AWS Bedrockなど、MCP対応のクライアントが接続して使います。Claudeだけの専用口ではなく、クライアントごとの個別開発なしで共通の窓口を使う設計です。

この記事のServiceNow側の仕様(版の要件・公開できるツール・提供時期・認証方式)は、ServiceNow社員がServiceNow Communityに書いた解説記事とFAQが出典です。製品ドキュメントの記載とは、導入前に管理者側で突き合わせてください。

Claude側の入口はClaudeやClaude Desktopです。claude.aiのコネクタはClaude Codeにも取り込まれる仕組みが、Claude CodeのMCPドキュメントに書かれています。ただしServiceNowのツールが実際に出るかは確認できていません。接続の可否を決めるのはServiceNow側の準備です。コネクタ全般の仕組みはClaude Connectorsとはで扱っています。

何を頼めるのか — 公開できるツールの種類

コミュニティ記事は、接続したAIクライアントから呼べるツールを4種類挙げています。表の依頼文はそれぞれの記事内の例です。

コミュニティ記事は、読み取りだけでなく申請・承認・確認までを通して実行できる点を、「質問に答える」から「タスクを完了する」への変化と位置づけています。

ただし同じ著者がコミュニティに載せたFAQ(MCP Server Console FAQ)は、承認ステップや待機を含むフローはツールにできないとしています。フローは既定でAIから呼べず、invoke_from_aiのACLが要ります。承認まで任せたい場合は、どのフローが公開できるかを管理者に確認します。

Scripted REST APIにも食い違いが1点あります。コミュニティ記事の表は「全CRUD」ですが、コメント欄でServiceNow社員の投稿者が、削除操作が使えないように見えると確認を求めています。同じ著者のFAQは、Scripted RESTで使えるのはGET・POST・PUTとしています。削除はこの経路では使えない前提で考えます。

アプリ側のトレースまで遡る調査はHoneycomb MCPのような別系統のコネクタと組み合わせる選択肢があります。

自社で使えるか — 管理者側に要る準備

ServiceNow連携は、個人の判断だけでは有効化できません。コミュニティ記事の「受信側(外部クライアントがServiceNowを使う)」の要件は次の4点です。

前提

ServiceNow側で先に要るもの

• MCP Server Consoleのストアアプリ

  ServiceNowのインスタンスに、MCP Server Consoleのストアアプリを入れておきます。

• プラットフォームの版

  MCP Server Consoleの最小要件は、Zurich Patch 9またはAustralia Patch 2です。インスタンスの版を先に確かめます。

• Now AssistのSKU

  ITSMやITOMなど、使う領域のNow Assist SKUが要ります。

• OAuthクライアント

  MCPクライアント用に、OAuthクライアントを管理者が手動で登録しておきます。MCP Server ConsoleはDynamic Client Registration(DCR)に対応していないため、クライアント側での自動登録は使えません。

AI Control Tower(AICT)は、この4点に入りません。FAQが本番運用で併用を推奨している統制層です。ただし必須要件ではありません。AICTで接続を管理する場合に限り、AICTのプラグインと、審査を担う「AI Steward」ロールの割り当てが要ります。最短の試し方として、記事は「Quickstart MCP Server」の有効化を挙げています。インシデントとケースの要約ツールが最初から入っているため、ツールを自作せずに動作を試せます。

接続までの流れ — ServiceNow側とClaude側は別々の操作

ClaudeがServiceNowを使うのは「受信」の方向です。逆に、ServiceNow内のAIエージェントがJiraやSalesforceなどの外部MCPサーバーを呼ぶ「送信」の方向もあり、こちらはMCP Clientという別の仕組みです。このコネクタが扱うのは受信側だけです。

接続には、ServiceNow側の公開準備(AICTを使う場合はその承認も)と、Claude側の有効化という、別系統の関門があります。

手順

接続が使えるようになるまで

1. 1

   ServiceNow管理者が公開を準備する

   MCP Server Consoleのストアアプリを入れ、Quickstart MCP Serverなどのツールを公開します。

2. 2

   AICTで管理している場合はAI Stewardが審査する

   AICT管理下の接続は「In Review」「Assess」「Approved」「Active」と進み、廃止時は「Deprecated」になります。この場合はActiveになるまで使えません。AICTを使わない構成では、この手順は発生しません。

3. 3

   Claudeの組織でコネクタを有効にする

   TeamとEnterpriseでは、OwnerかPrimary Ownerが「Organization settings」→「Connectors」から組織向けに有効化します。有効化しても、全員に権限が付くわけではありません。

4. 4

   各自がサインインする

   メンバーは「Customize」→「Connectors」から追加し、ServiceNowのアカウントで認証します。Enterprise-managed authを使う組織(TeamとEnterpriseのベータ)では、組織全体で1回認可する方式もあります。

Claude側の手順は、サポート記事によれば、設定の「Customize」→「Connectors」を開き、「+」から一覧を探す流れです。公式のコネクタ一覧のページにある「Add to Claude」から入ることもできます。サインイン後、公開されていないツールは見えません。期待する操作が出ない場合は、その操作が管理者の公開範囲に入っているかが最初の確認点です。

接続後は、同じ「Customize」→「Connectors」でコネクタを選ぶと、ツールの権限をタイプ別に確認できます。読み取り専用のツールと、書き込み・削除を伴うツールが分類されています。TeamとEnterpriseのOwnerは、この画面でツールの種類ごとに「Always allow」「Needs approval」「Blocked」を選べます。設定は組織全体に効き、各メンバーは上書きできません。なおTeamとEnterpriseでは、コネクタが使えるのはプライベートなプロジェクトに限られ、同期した内容を含むチャットは共有できません。

ガバナンスと監査 — Claudeからの呼び出しはどう見えるか

ServiceNowの「AI Gateway」は、AI Control Towerの中でMCP通信を管理する機能です。コミュニティ記事は、役割を3つに分けています。

• Govern(登録と審査): 外部クライアントと外部サーバーを台帳に載せます。AI Stewardの承認がなければActiveになりません
• Control(実行時の制御): 全接続でOAuth 2.1を強制し、機微データの遮断を設定できます。クライアントやサーバーは、コードの変更なしにAICTから即時に一時停止できます
• Observe(観測): ツールごとに、利用状況・遅延・成功率・エラー内訳を記録します。Assistの消費量はサブスクリプション管理と結びつきます

権限の考え方は、公式ページの「既存のServiceNowの権限に従う」に尽きます。コミュニティ記事も、ACLがデータ層で効く点を前提にしています。同時に、自作のMCPサーバーでは、ツール単位のアクセス制御・PII(個人を特定できる情報)の除去・即時の取り消しが付かないと整理しています。

読むときの注意が2点あります。1点目は、OAuthのバージョン表記が揺れている点です。コミュニティ記事は、MCPの説明では「OAuth 2.0」、ガバナンスの節では「OAuth 2.1を全接続で強制」と書いています。FAQは、MCP Server Consoleの認証を認可コードグラントのOAuth 2.0としています。これが唯一の対応フローで、クライアント認証情報グラントは未対応です。クライアントは管理者が手動で登録します。

2点目は、AI Gatewayの対象範囲です。強制が常時かかるのはUniversal MCP Client側で、AI Agent Studioが使うAIAS MCP Clientは「設定可能だが既定ではない」とされます。A2A(エージェント間の通信)も対象外です。Claudeからの受信側の呼び出しの扱いとは別の話ですが、社内の他のAIエージェント連携まで一括で統制されているとは限りません。

よくあるつまずきと切り分け

ServiceNowの設定だけを直しても、Claude側のOwnerによる有効化が無ければ使えません。逆も同じです。症状がどちら側の関門かを、上の表で先に切り分けます。

ITサービスデスクにFreshserviceを使っている場合の接続はFreshservice連携にまとめています。

自作のMCPサーバーでは足りない部分

ServiceNowのTable APIを包んで自作のMCPサーバーを立てることは、技術的には可能です。コミュニティ記事も、試作としては妥当だと認めています。そのうえで、本番運用で自前になる部分を次のように挙げています。

• ACLはデータ層で効くが、ツール単位のアクセス制御はない。接続したエージェントは、公開された任意のツールを呼べる
• PIIの除去、OAuthの設定と資格情報の管理、承認の流れ、監査ログを自前で作る
• 問題のあるクライアントを止めるには、コード変更と再デプロイが要る
• ServiceNowのサポート対象外で、MCP仕様の更新も自分で追う

Table APIの包み込みでは、ナレッジグラフを辿った関係検索や、Now Assistの事前構築スキル(記事は50以上と記載)も使えません。Claudeに接続する窓口を社内で選ぶ場面では、この差が判断材料になります。

他のMCPクライアントや連携方式との使い分け

コミュニティ記事は、REST API・Spokes・MCP・A2Aは競合せず、同じワークフローで併用されます。

くらべる

MCPで任せる作業と、決まった連携で任せる作業

状況に応じて判断させたい

MCP(Claudeなど)

AIがツールを実行時に探して選びます。パラメーターを事前に決めなくてよい一方、記事は「決定性が低く、LLMとプロンプトの質に左右される」と弱みを挙げています。

手順が決まっている

REST API・Spokes

開発者が呼び出しを固定します。ServiceNowのSpokesはSalesforceやJira、Workdayなど200以上の外部システム向けに用意されています。AIの判断は入りません。

迷ったときの目安は、AIの推論が要らない定型処理はREST APIかSpokes、複数のクライアントから統制付きで使わせたいならMCP Server Console、という分け方です。他社のAIエージェントとの協調が目的なら、MCPではなくA2Aの領域になります。

導入前に管理者へ確認する質問

組織でServiceNow連携を提案するときは、次の4点を管理者に渡せば、話が早く進みます。

• プラットフォームの版は、Zurich Patch 9かAustralia Patch 2以降か
• 使う領域(ITSM・ITOMなど)のNow Assist SKUは契約済みか
• OAuthクライアントを管理者が登録できるか。AI Control Towerで管理するなら、AI Stewardが決まり、接続をActiveにする運用があるか
• 公開するツールは読み取りだけか、書き込み(作成・更新)まで含めるか

外部サービス接続のセキュリティ設計を広く見たいときはMCPセキュリティガイド、組織のデータの置き場所はCoworkセキュリティ — データはどこに置かれ誰が触れるかが参考になります。

まとめ

導入の成否を決めるのは、Claude側のボタン操作ではありません。ServiceNow側の版・SKU・OAuthクライアントの登録(AI Control Towerを使う場合はその承認)と、Claude組織側のOwnerによる有効化。この2系統の関門を越えられるかです。症状が出たら、どちらの系統かを切り分けてから該当する管理者に聞きます。