【ServiceNow】これから始めるAI Control Tower実践：実画面で見る「何ができるのか」

はじめに

名称について：2026年10月下旬から、ServiceNowの製品サイトでは本製品の名称が「Super Intelligence Control Tower」になっています（製品ページ）。今回検証した画面や公式ドキュメントでは「AI Control Tower」のままなので、この記事でもAI Control Towerと表記します。

ServiceNowの AI Control Tower は、社内のAIを「台帳に載せ、承認し、動きを見て、必要なら止める」ためのワークスペースです。紹介資料を読むと何でもできそうに見えますが、実際に触ってみると「ここまではできる、ここから先は別の工夫が要る」という境界がはっきりあります。

この記事では、デモインスタンスでAI Control Towerを一通り触り、さらに Claude CodeをMCPクライアントにしてAI Gatewayの統制が実際に効くかを実測 した結果を、実画面と一緒に紹介します。

先に結論

• 台帳・承認・利用者ごとの権限は、実機でも説明どおりに動く
• AI Gatewayの「停止」は効くが、反映まで数分かかる（実測3分半〜6分弱）
• 直接URLを使うと、Gatewayの停止やPIIチェックを迂回できてしまう
• PIIチェックはメールや典型的なカード番号を止めるが、表記を崩すとすり抜けてしまう

対象読者

• これからAI Control Towerを触る、または提案・導入を検討するServiceNowの開発者・管理者
• 「外部のAIエージェントからServiceNowをMCPで使わせたいが、統制できるのか」が気になっている人

この記事で分かること

• AI Control Towerの画面構成と、それぞれでできること
• MCPサーバーを承認してAI Gatewayで統制するまでの流れ
• AI Gatewayの「停止」「PIIチェック」「利用者ごとの権限」がどこまで効くか（実測値つき）
• 外部のMCPクライアントをつなぐときのハマりどころ

検証環境

項目	内容
検証日	2026年10月28日〜30日
インスタンス	ServiceNowのデモインスタンス（デモデータ入り）
プラットフォーム	Australiaリリース（Patch 5系）
主なアプリ	AI Control Tower 5.0.0、AI Control Tower Core 7.0.1、AWH for AI Control Tower 3.0.1、Generative AI Controller 14.0.1
MCPクライアント	Claude Code v2.1.281（VS Codeのターミナル）

注意：画面と挙動は上記のバージョンのものです。AI Control Towerは更新が速く、バージョンや契約によって表示される機能が変わります。画面の数値はデモデータです。

AI Control Towerの全体像

AI Control Towerは、左端のアイコンで切り替える3つの画面でできています。まずこの役割分担を押さえると迷いません。

画面	役割	主な中身
Home	見る	ダッシュボード。9つのタブ（Overview、AI strategy、AI asset inventory、Value、Evaluation、Risk & compliance、Security & privacy、AI cases、AI Gateway）
AI assets	管理する	AI資産の台帳リスト。Managed／Unmanaged、ライフサイクル、申請、AI caseなど
Configurations	決める・止める	承認ルール、自動化ルール、外部AIとの接続、AI Gateway、データの扱い

HomeのOverviewでは、「期限切れのタスクがあるAIシステム」「失敗した検出ジョブ」など、対応が必要なものが上部にまとめて出ます。AIシステムはライフサイクル（New → Assess → Build and test → Deploy）とリスク分類で集計されます。

面白いのは、対象がServiceNowのAI（Now AssistやAIエージェント）に限られない点です。AWS BedrockやAzure AI Foundryなど外部のAI、MCPサーバーも同じ台帳で扱います。この記事では、このうち特に MCPサーバーをどう統制できるか に重点を置いています。

1. AI資産を台帳にする

AI Control Towerの出発点は台帳です。AI資産は「AI systems」「AI models」「Prompts」「Datasets」「MCP servers」の5種類で管理され、AI asset inventoryタブで内訳を確認できます。

ManagedとUnmanagedの違い

台帳は Managed（統制・監視の対象） と Unmanaged（検出されただけ） に分かれます。ServiceNow内のAIスキルやエージェント、MCPサーバーは自動でUnmanagedに載ります。今回のデモ環境では、ManagedのAIシステムが14件に対し、Unmanagedは1,147件ありました。

自分で作ったMCPサーバーも、何もしなくてもUnmanagedのMCP serversに表示されていました。

統制したいものだけを「Move to Managed」でManagedに移します。Configurations > Controls > Automation rulesで「生成AIはすべてManagedにする」のような自動昇格ルールも作れます（最大10件、同時に有効にできるのは5件。画面の説明と公式ドキュメントに記載があります）。

ポイント：公式のServiceNow Assist overviewには、AI Control TowerでAI資産（AIシステム、AIモデル、データセット、MCPサーバー）のmanagedフラグをオンにすると、月ごとに200 Assistかかると書かれています（Assistの単価は契約によります）。Unmanagedが1,000件を超えることもあるので、自動昇格ルールを安易に有効にしないようにしましょう。

外部AIの取り込み

Configurations > AI connectionsで、外部プラットフォームからAI資産（Discovery）と利用量（Usage）を取り込めます。今回の環境で選べたコネクタは、Microsoft、Amazon、Databricks、GCP Vertex AI、n8n、Salesforceの6種類でした。

2. 承認とライフサイクル

Configurations > Controls > Approvalsで、AIシステム／MCPサーバー／AIモデルごとに「AIスチュワード（AIの管理責任者）の承認を必須にするか」を切り替えられます。

実際に自作のMCPサーバーを1台、本番状態まで進めてみました。流れは次のとおりです。

1. Unmanagedの一覧で対象を選び「Move to Managed」（ライフサイクルは New・AI steward review に戻る）
2. レコードで「Start review」。AI Asset Onboardingのプレイブックが動き、Assess段階でArchitecture Review・Risk Assessment・Stakeholder Reviewの3タスクが自動で作られる
3. Assess → Build and test → Deployを「Mark as complete」で進める。ステータスは Approved for development → Ready for deployment → Approved for deployment → Deployed と変わる

Deployedになると、レコードに「AI Gateway setup」タブと「Activate PII check」「Create an offboarding request」ボタンが現れます。

ここが大事：サーバー単位の停止やPIIチェックは、承認を経てDeployedになるまで画面に出てきません。「統制の設定が見当たらない」ときは、まずライフサイクルを確認しましょう。

3. AI Gatewayで外部からのMCP通信を統制する

ここがこの記事の本題です。AI Gatewayは、MCPクライアントとMCPサーバーの間に入って通信を統制する仕組みです。外部のAI（今回はClaude Code）からServiceNowのMCPサーバーを呼ばせ、「止める」「個人情報を弾く」「使える人を絞る」が本当に効くのかを、時刻を記録しながら試しました。

先に結論を図にしました。Gateway用URLを通る通信には①〜④のすべてがかかり、直接URLでは④のロール判定だけがかかります。以下、この図の内容をひとつずつ実測していきます。

試験の構成

AI Gatewayを通すには、Gateway用のURLに接続します。同じMCPサーバーには元の「直接URL」もあるので、比較のためにClaude Codeに両方を登録しました。

名前	URL（インスタンス名は省略）	認可エンドポイント
snow-gw（Gateway経由）	/sncapps/awh/<サーバー名>/mcp	/mcp_auth.do
snow-direct（直接）	/sncapps/mcp-server/mcp/<サーバー名>	/oauth_auth.do（標準のOAuth）

claude mcp add --transport http --client-id <Gateway用のClient ID> --callback-port 8080 \
  snow-gw https://<instance>.service-now.com/sncapps/awh/<サーバー名>/mcp
claude mcp add --transport http --client-id <直接URL用のClient ID> --callback-port 8080 \
  snow-direct https://<instance>.service-now.com/sncapps/mcp-server/mcp/<サーバー名>

Gateway用URLや認可エンドポイントは、DeployedになったMCPサーバーの「AI Gateway setup」タブに表示されます。同じタブの「MCP Client Integration」で、接続を許すクライアントを登録します（後述のハマりどころ参照）。

なお、URLやサービスアカウント名に出てくる AWH は、AI Gateway関連のアプリやプラグインの名前に使われている略称です（AI Gatewayの設定は sn_awh_config プラグインに含まれます）。

各試験ではClaude Codeに次の指示を渡し、必ず1回だけ呼ばせました。エラーになると別の手段を試しに行くので、「代替しないで」と明記するのがコツです。

MCPサーバー snow-gw の look_up_incident_records を 1回だけ呼んで。
引数は priority=1, limit=3。
再試行・別ツール・別サーバーによる代替はしないで。
実行時刻（JST、秒まで）と、ツールの生の応答またはエラー全文をそのまま表示して。

試験1：サーバー単位で止める

AI Gateway setupタブの「Pause」を押すと確認画面が出ます。ここでもう一度Pauseを押さないと保存されません（実際に1回やらかしました）。

停止中はバナーが表示され、ボタンが「Resume」に変わります。

この状態でsnow-gwを呼ぶと、接続と認証は通りますが、ツール呼び出しで {"error":"tool not allowed by governance policy"} が返りました。次に「Resume」して、1分ごとに呼び続けた結果がこちらです。1分ごとの呼び出しには、Claude Codeのスケジュール実行で上の指示を繰り返させました。時刻は、Claude Codeが呼び出しと同じタイミングで date コマンドを実行して記録したものです。

14:18:17にResumeを確定したのに、14:22:25までは毎分失敗し、通ったのは14:23:25でした。逆に稼働中にPauseしたときも、止まるまで約5分50秒かかりました。

なぜすぐに効かないのか

ServiceNow側のアクセス記録を調べると理由が分かりました。AI Gatewayはインスタンスの外で動くサービスで、サービスアカウント（awh-service-account）が /api/sn_awh_config/awh_configs/servers を定期的に呼んで設定を取り込んでいます。その間隔が約5〜7分で、停止も再開も「次の取り込み」で切り替わっていました。

操作	確定	直前の取り込み	切り替わった取り込み	初めて結果が変わった呼び出し	所要
サーバー単位Resume	14:18:17	14:17:30	14:23:28	14:23:25 成功	約5分
サーバー単位Pause	14:46:40	14:46:32	14:52:31	14:52:30 失敗	約5分50秒
全体Pause	20:25:57	20:24:01	20:29:29	20:29:26 失敗	約3分30秒

※「初めて結果が変わった呼び出し」はClaude Code側（手元のPC）で記録した時刻、「取り込み」はServiceNow側のアクセス記録の時刻です。呼び出しのほうが数秒早く見えるのは、両者の時計のずれや記録するタイミングの違いによるものと考えられます。「取り込みの直後に結果が変わった」と読んでください。

公式FAQ（AI Gateway FAQ）にも「反映に最大10分」とあります。「押せば即座に止まる緊急停止」ではなく、「数分以内に止まる」 と理解しておくのが正確です。

試験2：全体を止める

Configurations > AI Gateway > Settingsには、Gateway全体を止める「Pause AI Gateway transactions」があります。

興味深いのは、中の仕組みがサーバー単位の停止と違う点です。

	サーバー単位Pause	全体Pause
内部で書き換わるもの	サーバーの接続設定に「Deny Access」ポリシー	システムプロパティ sn_awh_config.awh_enabled=false
利用者に返るエラー	tool not allowed by governance policy	同じ

利用者からは、どちらで止められたのか区別できません。障害対応では、管理者側で両方の設定を見る必要があります。

試験3：直接URLなら迂回できるか

Gateway側を止めたまま、snow-direct（直接URL）で同じツールを呼んでみました。

普通に通りました。 停止もPIIチェックもGatewayの機能なので、Gatewayを通らなければかかりません。統制したいなら、直接URL用のOAuthクライアントを発行しないなど、直接URLを使わせない設計とセットで考える必要があります。

試験4：PIIを含む呼び出しを止める

「Activate PII check」を押すと、次の説明が出ます。「このMCPサーバーを通る全トランザクションをPII検査し、検出したらそのトランザクションをブロックしてエラーを返す」。つまり 伏せ字にして通すのではなく、呼び出しごと止める 方式です。

架空のデータを引数に入れて試した結果です。

引数に入れた値	結果
[e-mail]	ブロック（PII detected: Email）
4111111111111111（空白なし）	ブロック（PII detected: Credit Card - Visa）
4111 1111 1111 1111（空白あり）	通過。そのままServiceNowの検索条件に入った

典型的な表記は止まりますが、表記を崩すとすり抜けてしまいます。「個人情報の送信を完全に防ぐもの」ではなく、補助的な安全策 として位置づけるのがよさそうです。PIIチェックを有効にしたままでも、PIIを含まない普通の呼び出しは問題なく通りました。

なお、Configurations > Data > Security & privacy にも個人情報の設定がありますが、こちらはNow Assist向けの匿名化で、GatewayのPIIチェックとは別物です。

試験5：利用者ごとに使える人を絞る

最後に、「Gateway経由だと全員が共通のアカウントにまとめられてしまうのでは」という疑問を確かめました。テストユーザーで認可し直して呼ぶと、ServiceNow本体から403が返りました。このユーザーにはMCPサーバーを使うためのロール sn_mcp_server.viewer がなかったためです。ロールを付けたあと、次の呼び出し（約1分後）では成功しました。

ServiceNowのトークン記録を見ると、テストユーザーが認可した直後に、Gatewayが そのユーザー本人のアクセストークン を取得していました。Gateway経由でも、ServiceNow側では利用者本人として扱われ、普段のロールやACLがそのまま効きます。成功時の検索条件には、adminのときにはなかった ^sys_class_nameNOT INsn_ot_incident が付いており、利用者によって返る結果も変わりうることが分かります。

可視化：ツール別の集計

GatewayやMCPサーバーの利用状況は、HomeのAI Gatewayタブと、MCPサーバーの「KPIs & metrics」で見られます。ツールごとに件数・成功率・応答時間（P50／P90／P95）が出ます。

※この画面は試験後（オフボーディング後）に撮影したため、ステータスがUnmanagedと表示されています。

ただし、ここで分かるのは集計値だけです。「誰がいつ何を呼んだか」という呼び出し単位の記録は、今回の環境ではインスタンスに残りませんでした（MCP Execution Logsは試験後も0件）。

Assistの消費は？

翌日にAssistの利用記録を確認したところ、Gateway経由の数十回の呼び出しは「AI gateway call」としては1件も計上されていませんでした。公式のServiceNow Assist overviewにある「AI gateway call（1回＝1 Assist）」は「第三者MCPサーバーへの呼び出し」の定義なので、ServiceNow自身のMCPサーバーを呼んだ今回は定義どおりの結果と読めます。第三者MCPの課金は、別途確かめる必要があります。

なお、同じ資料では「MCP server call」（ServiceNow自身のMCPサーバーへの1回の呼び出し）も1 Assistと定義されています。ServiceNowのMCPサーバーを外部から使う場合は、こちらの項目での計上もAssistの利用記録で確認しておくとよいでしょう。

4. 価値と利用状況を可視化する（Valueダッシュボード）

HomeのValueタブは、「AIで何時間浮いたか」を経営層に見せるためのダッシュボードです。個人的には、AI Control Towerでいちばん「かっこいい」画面だと思います。上段に全体の価値、下段に4つの切り口（Productivity／Engagement／Quality／Creator skills）が並びます。

Productivity：生産性

総生産性（16.3K時間）、価値の大きいAIシステムTop 5、タスク完了の効率化（55%）、Assistを多く消費しているAIシステムTop 10 などが一画面に出ます。下部の「System summary」では、AIシステムごとにペルソナ（Developer／Fulfiller／Requestor）別の利用回数と生産性を比べられます。

Engagement：利用状況

AIの操作回数（183.37K回）、部署別・国別の利用、部署ごとのAI資産の利用比較が見られます。Google AI StudioやMicrosoftのAIなど、外部のAIも同じ表で比べているのが特徴です。

Quality：品質

ポジティブなフィードバックの割合（80%）、AIで完了したタスクの割合（40%）、AIシステムごとの成功率が出ます。成功率の区分（Low／Average／High／Exceptional）は、システムプロパティ sn_value_engine.successful_completion_buckets で変えられます。

使うときの注意点

• このダッシュボードの対象は「ServiceNow AI」です。外部クライアントからMCP経由で使った分は、今回はどの指標にも現れませんでした。MCPの利用状況は前の章のAI Gatewayタブで見ます
• 画面の数値はデモデータです。実環境で同じように見せるには、価値テンプレート（何を何時間と数えるか）の設定と、部署・国など利用者情報の整備が必要です。今回の画面で「平均AI利用者が0」「部署がすべてOthers」になっているのは、そのためと考えられます

ハマりどころと対処

実際に試験していて詰まったところをまとめます。外部のMCPクライアントをつなぐときは、ほぼ確実にどれかに当たると思います。

1. Gateway経由の認可が unauthorized_client で弾かれる

Claude Codeに登録して認証すると、ブラウザに次のエラーが出ました。

unauthorized_client: The client credentials provided (those of the service you are using) are either not valid or not trusted

Gatewayの認可サーバーのメタデータ（/.well-known/oauth-authorization-server/awh/<サーバー名>）を見ると、動的クライアント登録（DCR）のエンドポイントがありません。今回の環境と手順では、Claude Codeが使うCIMD（Client ID Metadata Document）では通らず、クライアントを事前に登録する必要がありました。なお、AI Gateway FAQには、手動での登録のほかにCIMDによる登録にも対応していると書かれています。

対処：MCPサーバーの「AI Gateway setup」タブ > MCP Client Integration > New で、名前とRedirect URL（http://localhost:8080/callback）を入れて保存します。公開クライアント（Secretなし、PKCE必須）として作られるので、Client IDだけを --client-id で渡せば通ります。汎用のApplication Registryではなく、サーバーごとのこの画面で登録するのがポイントです。

2. 直接URLではトークンが取れるのに接続できない

直接URL側は標準のOAuth（oauth_auth.do）で、Claude Codeが送るClient ID Metadata DocumentのURLをclient_idとして受け付けませんでした。そこでApplication Registryにクライアントを登録したのですが、今度は次の状態になりました。

Got new credentials, but snow-direct rejected them on reconnect

動いている既存のクライアントと設定を全項目比べたところ、原因は トークン形式 でした。新規作成の既定値は「Opaque」ですが、直接URLのMCPサーバーは「JWT」を求めます。

対処：Application Registryのクライアントのトークン形式（token_format）をJWTにして、Claude Code側で認証情報を消し（/mcp → Clear authentication）、認証し直します。

3. テストユーザーで認証したのに、adminとして許可される

認可画面が開くブラウザがすでにServiceNowに管理者でログインしていると、ログイン画面が出ずにそのまま管理者として許可されます。利用者ごとの挙動を試すときは致命的です。

対処：認可画面のURLをシークレットウィンドウに貼り、テストユーザーでログインして許可します。誰として許可されたかは、ServiceNowの oauth_credential（トークンの発行記録）で確認できます。

4. Pause／Resumeを押したのに反映されない

確認画面でもう一度押さないと保存されません。さらに保存しても、Gatewayが次に設定を取り込むまで（約5〜7分）は効きません。「押したのに変わらない」ときは、画面のバナー表示を確認してから数分待ちましょう。

5. サーバー単位の統制設定が見当たらない

AI Gateway setupタブや「Activate PII check」は、MCPサーバーが Deployed になるまで表示されません。Unmanagedのままや、承認の途中では出てこないので、「2. 承認とライフサイクル」の手順で本番状態まで進めてください。

まとめ：できること、できないこと

今回の実機検証で確かめた範囲での結論です。

やりたいこと	結果	補足
社内のAIを台帳にする	◎ できる	ServiceNow内のAIとMCPサーバーは自動で載る。外部クラウドは接続設定が必要
AIの導入を承認制にする	◎ できる	評価→開発・テスト→本番の流れで、タスクも自動で作られる
外部AIからのMCP通信を止める	○ できる	全体とサーバー単位の2種類。ただし反映まで最大で数分（実測3分半〜6分弱）
個人情報を含む呼び出しを止める	△ 一部できる	メールやカード番号は止まるが、表記を崩すとすり抜けてしまう。伏せ字ではなくブロック
利用者ごとに使える人を絞る	◎ できる	Gateway経由でも利用者本人の権限で判定される。ロール付与後、約1分後の次の呼び出しでは反映済みだった
Gatewayを迂回させない	× そのままではできない	直接URLでは停止もPIIチェックも効かない。直接URLを使わせない設計が必要
利用状況を見る	○ 集計はできる	ツール別の件数・成功率・応答時間は見られる
「誰がいつ何を呼んだか」を追う	× 今回はできなかった	呼び出し単位の記録はインスタンスに残らなかった
AIの価値を可視化する	○ できる	対象はServiceNow AI。実データで見せるには価値テンプレートと利用者情報の整備が必要

まだ確かめていないこと

• 第三者のMCPサーバー（外部SaaSなど）をGatewayにつないだときの課金と、ツール単位の許可／拒否
• 応答側のPIIチェック
• Pauseより速く止める手段（トークンの失効や利用者の無効化）
• AWS Bedrockなど外部クラウドのAIの取り込み（今回のデモ環境では接続が失敗していた）

このあたりは、また検証したら続編で紹介します。なお、外部クラウドのAIを台帳に取り込む側（GCP Vertex AIのエージェントをService Graph ConnectorでCMDBに登録する手順）は、smuraさんの「ServiceNow AI Control TowerでVertex AIのAI資産をCMDBで管理・可視化する」が詳しいので、あわせて読むと、台帳化から実行時の統制までがつながります。

おわりに

AI Control Towerは、「AIを使いたい」と「管理したい」の両方に応えるための製品です。実際に触ってみると、台帳・承認・利用者ごとの権限は説明どおりに動きました。一方で、「止める」には数分の遅れがあり、直接URLという抜け道もあります。

「統制できます」と一言で説明するのではなく、どの経路の、どの操作を、どの粒度で、何分で止められるのか を押さえておくと、設計も説明もぐっと現実的になります。この記事が、これからAI Control Towerを触る方の地図になればうれしいです。

参考

• AI Control Tower：View the MCP server record（ServiceNow公式ドキュメント）
• AI Gateway FAQ（ServiceNow Community）
• AI Gateway Implementation Guide（ServiceNow Community）
• ServiceNow Assist overview（Assistの定義、PDF）
• Create an automation rule（ServiceNow公式ドキュメント）

• ServiceNow AI Control TowerでVertex AIのAI資産をCMDBで管理・可視化する（smuraさん、Zenn）：外部AIの取り込み（台帳化）側の実践記事