Claude Media
ServiceNow問い合わせ対応をClaudeで自動化 — 情シス部門の実装手順
CoworkClaude連携チュートリアル

ServiceNow問い合わせ対応をClaudeで自動化 — 情シス部門の実装手順

ServiceNowコネクタはAction Fabricを介し、IT・HR・カスタマーサービスなど部門横断のワークフローをClaudeから実行します。情シス部門での使い方と設定手順、注意点をまとめます。

読了目安 約7分

ServiceNowコネクタとは何か

ServiceNowコネクタは、ClaudeからServiceNowの業務システムへ働きかけるディレクトリConnectorです。IT・HR・カスタマーサービス・セキュリティ・リスクといった部門をまたぐワークフローを、チャットの指示で動かせます。ServiceNow自身が提供する接続先で、Connectorsディレクトリでは「Anthropic verified」の表示が付き、サインインが必要です。

裏側の基盤は「ServiceNow Action Fabric」です。ServiceNowのアプリチームが用意したドメイン別のMCPサーバーを、Claudeが呼び出す形で動きます。ServiceNow管理者がプラットフォームの機能で作ったカスタムMCPサーバーも組み合わせられます。ディレクトリのページには、管理者がこのコネクタを組織に用意した場合、使えるツールは管理者の構成を反映するとも書かれています。

操作の範囲は、接続したアカウントがServiceNow側で持つ既存の権限と、ServiceNowの管理者が組んだ構成の内側に収まります。Claude側の設定は、そこをさらに狭められるだけです。

情シスの一次対応で何が変わるか

情シス部門の一次対応は、インシデント・アラート・変更リクエストの確認から始まります。ServiceNowコネクタでも、この「状況を掴む」作業から任せるのが自然です。たとえば次のような照会が考えられます。

  • 重大な未対応アラートを一覧で確認する
  • 特定のアラートを深掘りし、何が起きたかを整理する
  • そのアラートの影響範囲を調べる
  • 決済データベースのような特定サービスに依存するシステムを、ナレッジグラフから逆引きする

「決済まわりが遅い」という一報を受けた場面なら、未解決のアラートの有無、影響を受けるサービス、依存関係を、チケット画面を開き直さずに1つの会話でたどれます。ただし、どのアラートやナレッジグラフを引けるかは、自組織がServiceNowで有効にしているアプリとMCPサーバーの構成で決まります。導入していないアプリに対応するMCPサーバーは、最初から使えません。

接続して使い始めるまで

手順

ServiceNowコネクタを使い始める流れ

  1. 1

    組織で有効化する(Team・Enterprise)

    Team・Enterpriseプランでは、OwnerまたはPrimary Ownerが「Organization settings > Connectors」で「Browse connectors」から「Add to your team」を選びます。有効化しただけでは誰にも権限は渡りません。

  2. 2

    各メンバーが認証する

    「Customize > Connectors」でServiceNowを開き、「Connect」から自組織のServiceNowへのサインインを済ませます。個人のアカウントでは、この手順から始まります。Enterprise管理の認証(ベータ)を使う組織では、メンバーは初回ログインで接続を引き継ぎます。

  3. 3

    会話で有効にする

    チャット左下の「+」(または「/」)から「Connectors」を開き、使うサービスを会話ごとにオンにします。

  4. 4

    Claude Codeで確認する

    claude.aiアカウントでログインしていれば、/mcpの一覧に同じコネクタが出ます。

Connectorsの全般的な追加手順やVerified・Communityラベルの見方はClaude Connectorsとはにあります。Cowork側の承認モードと組織設定の優先順位はClaude CoworkのConnectors一覧が詳しい記事です。

/mcp

/mcpに出る一覧では、claude.ai由来のサーバーに印が付きます。一度もサインインしていないコネクタは「Show unused connectors」の行に畳まれているので、見当たらないときは展開します。Claude Codeの公式手順に書かれた挙動です。

接続したのに/mcpに出ないとき

Claude Codeがclaude.aiのコネクタを取りに行くのは、認証方法がclaude.aiのサブスクリプションログインのときだけです。次の状態では、claude.ai側で接続済みでも読み込まれません。

  • ANTHROPIC_API_KEY、ANTHROPIC_AUTH_TOKEN、apiKeyHelper のいずれかが有効
  • Amazon BedrockやGoogle CloudのAgent Platformなど、サードパーティ経由で動かしている
  • claude setup-token で作った長期トークン(CLAUDE_CODE_OAUTH_TOKEN)で動いている
  • ANTHROPIC_PROFILEやフェデレーション用の変数、有効なAnthropicプロファイルが資格情報を供給している

CI用にAPIキーを渡した環境でServiceNowが見えないのは、この条件に当たっている可能性があります。/statusで今の認証方法を確かめ、環境変数を外してから/loginでclaude.aiのアカウントを選び直します。session token rejectedと出る場合は、コネクタを再認可しても直らず、/loginのやり直しが先です。

特定の案件だけコネクタを切りたいときは、/mcpの切り替え、disableClaudeAiConnectorsをtrueにする設定、環境変数ENABLE_CLAUDEAI_MCP_SERVERS=falseのいずれかを使います。設定は、Claude Code自身が取得するコネクタにだけ効きます。クラウドセッションやデスクトップアプリのローカルセッションは経路が違い、同じ設定では止まりません。

書き込みだけを止めたいとき

ServiceNowのようにインシデントの更新まで届く接続では、読み取りだけ許す構成を作れるかが導入の分かれ目です。方法は2層あります。

くらべる

書き込みを絞る2つの層

Owner向け

Claude側のTool permissions

「Customize > Connectors」でコネクタを選ぶと「Tool permissions」が出ます。読み取り系ツールと書き込み・削除系ツールなどの分類ごと、または個別のツールごとに、Always allow・Needs approval・Blockedを選べます。組織全体に効き、個々のユーザーは上書きできません。

ServiceNow管理者向け

ServiceNow側のロール

接続に使うアカウントのロールで先に範囲を決めます。Claudeで書き込みを許可しても、ServiceNow側に変更の権限がなければ変更はできません。Claude側の制限はこの上限を広げず、狭めるだけです。

Claude Codeでは、組織がツールをNeeds approvalにすると、呼び出しのたびに「Your organization requires approval for this tool」という理由で確認が出ます。autoやbypassPermissionsのモードでも出ますし、許可ルールで飛ばすことも、選択を記憶させることもできません。dontAskモードでは、確認する代わりに呼び出しが拒否されます。Blockedのツールは、Claudeのツール一覧に出てきません。ただしデスクトップアプリのローカル・SSHセッションでは毎回の確認は出ず、通常の権限ルールで扱われます。

取り消しにくい操作の候補としては、インシデントのクローズやチケットの再割り当てが考えられます。これらはまず専用ロールで範囲を決め、そのうえでNeeds approvalに置く構成が、Claude側とServiceNow側の両方で歯止めをかける形になります。

承認モードは「Claudeのどの操作を人が確認するか」を決める設定で、Tool permissionsは「そのツールを使えるか」を決める設定です。ServiceNowでは両方を見る必要があります。

部門をまたぐ一次対応は会話だけで成立するか

GitHubならコード、Notionならドキュメントのように単一の領域を扱うコネクタと違い、ServiceNowはIT・HR・カスタマーサービス・セキュリティ・リスクを横断する前提で作られています。部門ごとに別だった一次対応の窓口を、1つの会話に集められる点が違いです。

ただし、HR担当やカスタマーサービス担当が同じ会話の延長でServiceNowを扱えるかは、ServiceNow側のロール設計次第です。横断的なロールがなければ、コネクタを入れても縦割りは変わりません。

SlackやGitHubなど他のコネクタと組み合わせると、たとえば障害対応は次の流れになります。

  1. Slackで受けた一次報告を要約する
  2. ServiceNowでインシデントの影響範囲を確認する
  3. 修正のプルリクエストの進み具合をGitHubで追う

組み合わせ方と情シス以外の活用例はClaude Cowork活用事例にまとめています。

コネクタが増えると、読み込みの設定も効いてきます。チャットの「Tool access」には、Auto(既定)・Always available・On demandがあります。サポート記事は、有効なコネクタが10個以上ならOn demandを検討するよう案内しています。ドメイン別のMCPサーバーを複数有効にする構成では、この目安が切り替えの判断材料になります。

導入前に決めておくこと

導入前に決めておく点は次の3つです。

  • 接続アカウント: 個人アカウントか、Claude専用のサービスアカウントか。専用アカウントなら、ロールを最小限に絞れます
  • 書き込みの扱い: 読み取りのみで始めるか。始めるなら、Tool permissionsで書き込み系をBlockedまたはNeeds approvalにします
  • 対応アプリ: 使いたいサービスのMCPサーバーを、ServiceNow管理者が用意しているか

退職者対応のような、手続き全体を追う運用はCoworkで退職者オフボーディングをチェックリスト化するで扱っています。

よくある質問

ServiceNowのライセンスは別に必要ですか

必要です。コネクタはServiceNowへの接続口なので、接続先のServiceNowインスタンスと、そこで権限を持つアカウントがなければ使えません。

どのプランで使えますか

ディレクトリのコネクタは全プランで追加できます。Tool permissionsで組織全体の書き込みを止められるのは、Team・EnterpriseのOwnerです。

会社のドメインのメールで個人のClaudeに接続しようとしたら止められました

「This corporate identity belongs to an Enterprise that manages access through their own Claude account」というメッセージなら、そのドメインを検証済みのEnterprise組織が、自組織のClaudeアカウント以外からの接続を制限しています。組織のClaudeアカウントでサインインして接続し直します。アカウントがなければ管理者に確認します。

まとめ

ServiceNowコネクタの導入では、接続の可否よりも、書き込みを誰がどの層で止めるかの設計が結果を分けます。Tool permissions・ServiceNowのロール・Coworkの承認モードを別々の層として決めておくと、運用で迷いません。

この記事を共有:XはてブLinkedIn

関連する記事

Cowork をもっと見る →