AI の利用状況を管理する仕組み：Now Assist Analytics と AI Control Tower の定義の確認

Now Assist のスキルや AI エージェントを展開したあと、誰がどれだけ使い、何を止められるのか。管理者はどこで見ればよいのでしょうか。

ServiceNow で利用状況を見るのが AI Analytics（旧称 Now Assist Analytics）です。AI 資産を台帳にして承認や停止を扱うのが AI Control Tower です。2つの定義を管理者の視点で確認し、展開の前に決めておくことを整理します。

確認できたこと

• 標準で入っている管理の仕組みは、利用状況を見る AI Analytics と、資産・評価・安全・ゲートウェイを扱う AI Control Tower の系統

• 管理用のスキルは、Analytics が14件（有効10件）、AI Control Tower が14件（有効8件）

• 展開前の承認は、この環境では MCP サーバーだけが必須。AI システムとモデルは必須になっていない

• 「キルスイッチ」は同じ名前で2種類ある。暴走するトリガーの自動停止と、エージェントの隔離

• 暴走の自動停止に使う設定は、この環境では見つからなかった

確認の規模

1つのデモ環境で、テーブルの定義・件数・システムプロパティ・スキルの一覧を読みました。他のユーザーの情報は扱わず、集計だけを使っています。管理画面は表示して撮影しましたが、設定の変更や管理機能の実行はしていません。「できる」と書いた箇所は、公式ドキュメントとテーブルの定義にもとづく説明です。

標準で入っている管理の仕組み

利用状況の管理は、1つの製品では完結しません。デモ環境で定義を確認できたものを、1機能1行で並べます。

表の内容を文字でも書き出します。

• AI Analytics：利用・採用・性能の指標を見る。導入済みで、標準のダッシュボード構成は1件。定義とダッシュボードの表示を確認

• AI Control Tower の資産一覧：AI 資産を台帳にして承認と段階を管理する。導入済みで、承認の要否はプロパティで決まる。定義と設定値を確認

• AI Control Tower の評価：エージェントのセッションを採点する。導入済みだが、行は権限不足で読めなかった。定義と画面の表示を確認

• AI Security and Privacy：資産ごとの安全状態を見て、隔離を要求する。導入済みで、隔離要求は0件。定義と件数を確認

• AI Gateway：MCP の通信にポリシーとスキャンをかける。導入済みだが、画面表示は無効。定義と設定値を確認

• キルスイッチ（2種類）：暴走の自動停止と、エージェントの隔離。前者の設定は見つからなかった。定義のみ確認

どれも今回は動かしていません。代表して見たのは、利用状況を見る AI Analytics と、台帳と承認を持つ AI Control Tower の2つです。管理者が展開の前に判断する内容の大半は、この2つに集まっています。

データは複数のアプリに分かれている

AI の利用状況と管理のデータは、1つのテーブルにはまとまっていません。アプリのスコープごとに分かれています。

起点は Now Assist の利用と AI 資産の出どころ、緑は定義と行数を確認できた仕組み、赤は行を読めなかった仕組みです。矢印は公式ドキュメントとテーブルの定義から引いたもので、データが実際に流れる様子は追っていません。

図の内容を文字でも書き出します。

• Now Assist の利用（スキル・AI エージェントの実行）は AI Analytics（sn_na_analytics）に集まる。利用・採用・性能のダッシュボードを持つ

• AI 資産の出どころ（クラウドの AI・MCP サーバー）は AI Discovery（sn_ai_disc）で取り込まれ、AI Control Tower Core（sn_ai_governance）の資産一覧・ライフサイクル・承認につながる

• AI Control Tower Core からは、AI Security and Privacy（sn_ai_security、安全状態・脅威分析・隔離要求）と、評価・トレース収集（sn_ai_observe）へ進む

• AI Gateway（sn_awh_config、MCP のポリシーとスキャン）の情報も AI Control Tower Core に入る

• 緑は定義と行数を確認できた仕組み、赤は権限が足りず行を読めなかった仕組み（評価・トレース収集と AI Gateway）

Now Assist の利用回数そのものは、使用量ログに記録されます。数え方は別の記事「生成AI の利用量はどれだけ増えるか：要約・生成の回数と記録」（準備中）で扱う予定です。AI Analytics が、そのログを元データにしているかどうかは確認していません。

この図で見てほしいのは、AI Control Tower Core に資産一覧が集まる構造です。AI Gateway が持つ MCP サーバーの情報は、AI Control Tower Core との同期用のテーブルを通じて入ります。

AI Analytics で見られるもの

AI Analytics は、生成 AI の利用・採用・性能を、Platform Analytics の画面で見るための機能です。公式ドキュメントでは、使う人を AI Analytics Admin と AI Analytics Viewer の2つに分けています。Admin はスキルとダッシュボードの対応付けを設定し、Viewer は画面を閲覧します。

利用の件数は、Now Assist アドミンの概要画面にも出ます。①の Skill usage に並ぶのは、操作の回数と1日あたりの利用者数です。②の Needs Attention は、未導入のプラグインや未開始のスキルの数を示しています。AI Analytics は、これとは別のダッシュボード画面です。

AI Analytics のダッシュボードを開くと、左の①にメニューが並びます。Usage、Adoption & Engagement、Sentiment、Self Solved Performance、Assists、Voice の6つです。②の Overview には、AI が関わった操作の累計と、平均の利用者数が出ます。公式ドキュメントは、利用状況・スキルの性能・AI Guardian・コンテキストメニュー・ユーザー検索の分析を並べています。この画面で見えるのは、そのうちメニューに出ている範囲です。

デモ環境にも、公式と同じ名前の2つのロール（sn_na_analytics.admin と sn_na_analytics.viewer）がありました。ほかにエンゲージメント用の2つのロールがあります。アプリのテーブルは16個で、表示名には Now Assist Analytics が残っています。現在の公式名は AI Analytics です。

テーブルの一覧でも、その名残が見えます。①のラベル列は16個すべてが Now Assist Analytics で始まり、②のアプリケーション列は AI Analytics です。設定（Configuration）、指標（Metric）、価値（Value）、デフレクション（Deflection）の4系統に分かれています。

テーブルの中身を見ると、標準のダッシュボード構成は1件、指標の定義は1件でした。公式ドキュメントが並べる分析の種類に比べて、この環境で構成済みのものはごく一部です。

価値の指標は、AI Analytics の外に移っています。公式ドキュメントは、Value Insights のページを AI Analytics から外し、AI Control Tower の Value タブを使うよう案内しています。デモ環境にも、Value・Health・Engagement の3つのダッシュボード用アプリが別に入っていました。

管理用のスキル

AI Analytics に関連するスキルは14件あります。

• Query Generation（5件）：発言からのクエリ生成、フォローアップ質問、インサイト生成など

• AI Data Explorer（4件）：探索の要約、テキストの絞り込み、次の操作の提案

• Analytics Skills（4件）：ダッシュボードの要約、変更点の要約、エクスポート

• Analytics in NAP（1件）：データの可視化の生成

有効なのは10件です。残る4件は、定義はあるものの製品側で有効になっていません。

• Dashboard Facts Generator

• Dashboard Summarization

• Analytics hidden insight generation

• Analytics query generation for indicators

ダッシュボードの要約が画面にどう出るかは、要約を実行していないため確かめていません。

表の内容を文字でも書き出します。

• AI Analytics: Query Generation：5件、有効3件。発言からのクエリ生成、インサイト生成

• AI Analytics: AI Data Explorer：4件、有効4件。探索の要約、次の操作の提案

• AI Analytics: ダッシュボード系：5件、有効3件。要約、変更点の要約、可視化の生成

• AI Control Tower：14件、有効8件。優先順位付け、漏えい検出、タグ生成

AI Control Tower で決められるもの

AI Control Tower は、AI 資産の台帳です。公式ドキュメントでは、AI システム・AI モデル・プロンプト・データセット・MCP サーバーの5種類を資産として扱います。画面の見える範囲は、担当者の種類で変わります。AI steward、資産の担当者、ワークスペースの利用者、リスクとコンプライアンスの担当者の4種類です。AI steward は全体を、資産の担当者は自分の資産だけを見ます。

デモ環境のワークスペースは「AI Control Tower (Legacy)」という名前で開きます。①のタブは9つです。Overview・AI strategy・AI asset inventory・Value・Evaluation の5つのあとに、Risk & compliance・Business portfolio・Security & privacy・AI cases が続きます。②は、AI システムが段階ごとに何件あるかを示す4枚のタイルです。New、Assess、Build and test、Deploy の名前は、次の節で見るライフサイクルの定義と同じです。

デモ環境で確認できたのは、次の4点です。

ライフサイクルの定義

資産の段階を表す定義が10件ありました。親を持たない段階は New、Assess、Build and test、Deploy、Offboard の5つです。その下に、Build、Pre-deploy、Pre-offboarding、Assess offboarding、Offboard の5つが付きます。資産ごとに今どの段階にあるかを、台帳で管理する作りです。

一覧の Parent 列を見ると、Build and test の下には Build と Pre-deploy があります。Offboard の下には Pre-offboarding・Assess offboarding・Offboard の3つです。展開の前とオフボードの前に、確認の段階を挟む構成になっています。

承認の要否

システムプロパティで決まります。この環境の値は次のとおりでした。

• MCP サーバーの追加に AI steward の承認が必要：true

• AI 資産の展開前に AI steward の承認が必要：false

• AI システムによる AI モデルの使用に承認が必要：false

• 資産の承認を自動で起動する（approval_mandate）：true

MCP サーバーだけ承認が必須で、AI システムやモデルは必須になっていません。何を承認の対象にするかは、導入側が決める設定です。

システムプロパティの一覧でも、同じ値を確かめられます。画像の①は資産の展開前に AI スチュワードの承認を求めるプロパティで、値は false でした。②は AI システムによる AI モデルの使用に承認を求めるプロパティで、これも false になっています。③は MCP サーバーの追加に承認を求めるプロパティで、こちらだけ true です。画像上端の com.glide.aict.ai_gateway_enabled は false で、AI Gateway の画面表示が無効であることに対応します。

自動化ルール

資産を管理対象にするルールです。標準のものは次の3つで、すべて有効（Status が1）でした。

• すべての生成 AI システムを管理対象としてマーク

• すべての ServiceNow AI システムを管理対象としてマーク

• 過去3か月間に作成された AI モデルを管理対象としてマーク

一覧の Query condition 列を見ると、3件とも資産のクラス名（asset.sys_class_name）で対象を絞っています。対象テーブルは AI Asset Governance Details で、資産の管理情報の側に印を付ける作りです。有効なルールの数は、プロパティで上限が5件、全体で10件に決まっています。

管理用のスキル

AI Control Tower にもスキルが14件あり、有効は8件です。

• 分析・優先順位付け：Critical Issue Identifier、Lifecycle Task Health Prioritization、Score and Categorization Insight、Use and Purpose vs Intent Insight

• 検出・評価：Agent System Prompt Leakage、AICT Correctness Detection、AI Gateway MCP Tools Scan

• 生成：AI Asset Tag Generator

Use and Purpose vs Intent Insight は、登録した用途の宣言と、実際の使われ方を比べるスキルです。AI の利用が宣言から外れていないかを、AI で確認するスキルと読めます。

管理者向けの Now Assist アドミンで AI Control Tower のスキルを開くと、状態が一覧で見られます。画像の①AI Gateway MCP Tools Scan は「アクティブ」です。②の AICT Servicenow AI Dataset assets usage は、資産の利用状況を追跡するスキルで、「未開始」になっています。③の Use and Purpose vs Intent Insight は「アクティブ」です。

この一覧の件数表示は13件で、本文の14件より1件少なくなっています。足りない1件は AICT Servicenow AI Model assets usage です。このスキルだけ、スキル構成の状態が「ドラフト」（公開ではない）で、一覧には出ません。同じ種類の資産利用スキル5件（Dataset と System の各2件、Enterprise AI Model assets usage）は一覧に出ています。ドラフトの1件を除くと14−1＝13件で一致します。

無効の6件は、資産の利用状況を追跡するスキルです。AI システム・モデル・データセットのそれぞれで、ServiceNow 提供のものと企業独自のものに分かれていました。

セキュリティとゲートウェイ

セキュリティの側は、資産ごとの安全状態、脅威分析の構成、隔離の要求を別のテーブルで持ちます。

ワークスペースの Security & privacy タブを開くと、①に AI 資産のセキュリティスコアが出ます。この環境では Good でした。②の access と Guardrails の2つのタブで、エージェントのアクセスの問題と、ガードレールの状態を切り替えて見ます。

AI Gateway は、MCP の通信に対するポリシーとスキャンの結果を持ちます。画面表示を制御するプロパティ（com.glide.aict.ai_gateway_enabled）は false でした。使うには、まず表示を有効にします。

止める仕組みは2種類ある

ServiceNow のドキュメントには、キルスイッチという名前の機能が2つあります。

図の内容を文字でも書き出します。

• 暴走の自動停止：AI エージェントのトリガーが同じレコードで繰り返し起動するのを止める。目的は Now Assist のアシスト消費の抑制

• 既定の検出条件（公式）：1レコードで1日5回超・25件以上・3日連続。動作は warn_only で通知のみ。このデモ環境ではしきい値の5つのプロパティが見つからない

• 悪意のあるエージェントの隔離：AI Control Tower が資格情報の取り消しを連携先に要求する。目的は安全の確保

• 仕組み（公式）：各実施点の完了を確認してから隔離済みにする。記録は監査履歴に残る。このデモ環境では隔離要求のテーブルはあるが0件

1つ目は、AI エージェントのトリガーが暴走したときの自動停止です。同じレコードに対して同じエージェントが繰り返し起動すると、そのたびに Now Assist のアシストが消費されます。

公式ドキュメントによると、既定の検出条件は次の3つです。

• 1レコードあたり1日5回を超える

• そのレコードが25件以上ある

• 3日連続で続く

動作モードの既定は warn_only で、通知だけを送ります。しきい値は5つのシステムプロパティで変更できます。

2つ目は、悪意のある動きをしたエージェントの隔離です。AI Control Tower が、資格情報の取り消しを連携先（ポリシーの実施点）に要求します。

各実施点が完了したことを確認してから、隔離済みにする仕組みです。記録は監査用の履歴に残ります。

目的が違います。1つ目は消費の抑制、2つ目は安全の確保です。担当者や手順も別に決めます。

デモ環境では、1つ目のしきい値を調整する5つのプロパティが見つかりませんでした。名前に kill_switch を含むプロパティを検索すると、①の3件が該当します。いずれも名前に mid_skill_switch（スキルの途中切り替えの設定）を含み、その一部が一致しただけです。暴走の自動停止とは別の設定になります。

2つ目の隔離要求は、テーブル（AI Security Asset Containment Request）があるものの0件でした。①のとおり、一覧には1件も表示されません。列には Asset、Initiated By、Operation Type、Reason、Status が用意されており、誰が・どの資産を・なぜ隔離したかを記録する作りです。

エージェントの評価

評価は、AI Control Tower の Evaluation タブで扱います。公式ドキュメントでは、使うロールは sn_ai_governance.ai_steward です。使う前に、評価の有効化が要ります。対象にならない会話の条件もあり、HR に関する会話は自動評価から外れます。

ワークスペースの Evaluation タブを開くと、①に「このアプリは既定で無効で、有効化の手順はドキュメントを参照する」という案内が出ます。その下に並ぶのは、会話の自動評価の平均スコアと、人の評価の平均スコアです。この環境ではどちらも 0.00 でした。

デモ環境では、評価のテーブル（セッション・トレース・スパン）の行を読めませんでした。画面の案内と行数からは、この環境で評価が有効化済みかどうかを判断できません。

管理の担当を分ける考え方

確認したロールから、担当の分け方を候補として整理します。

• AI steward（sn_ai_governance.ai_steward）：承認と調整を担う。資産一覧と評価の画面を使う

• AI Analytics の閲覧者・管理者：利用状況を見る担当と、スキルとダッシュボードを対応付ける担当

• ワークスペースの利用者・管理者：AI Control Tower のワークスペースを開く。担当の資産だけを見る使い方

• リスクとコンプライアンス：AI Risk and Compliance 系の複数のロール（reader・business user・analyst・admin など）

• AI Gateway の管理者・閲覧者：awh_admin と awh_read の2つ。ほかに、データの読み取り用と REST 連携用のロールがある

ロールの一覧を名前で絞ると、4つのアプリで15件が該当しました。①の AI steward には、製品同梱の説明が付いています。

（訳: イノベーション、法務、セキュリティ、リスク、コンプライアンスの各チームの間で、ガバナンスの活動を促進し調整する）

引用元: /sys_user_role_list.do?sysparm_query=name=sn_ai_governance.ai_steward

②の AI Gateway のロール4件にも、設定用・読み取り専用・データ読み取り・REST 連携の違いが説明に書かれています。③の AI Analytics の4件は説明が空で、閲覧と管理の違いは名前（viewer と admin）で区別することになります。

候補の分け方は、見る人・決める人・止める人の3つです。見る人は AI Analytics の閲覧者、決める人は AI steward、止める人は AI Gateway とセキュリティの担当に割り当てる案になります。止める人は、2種類のキルスイッチのどちらを担当するかまで決めます。

人数の少ない組織では、1人が複数のロールを持ちます。その場合も、承認する人と、承認を求める人は分けておきます。同じ人が両方を持つと、承認が形だけになるためです。

実機で気づいたこと

管理の仕組みが多くのアプリに分かれている

AI Control Tower は1つの製品に見えます。実機では、資産一覧、評価、トレース収集、セキュリティ、ゲートウェイ、ダッシュボードが別々のアプリで、権限もそれぞれ別でした。たとえば評価のテーブルは、この環境の管理者アカウントでは行を読めません。

実務では、AI steward に割り当てるロールを、アプリごとに洗い出します。一覧の抜けは、展開後に画面が見えない問い合わせとして現れます。

管理側にも AI が動いている

AI Control Tower の有効なスキル8件は、すべて AI で動く機能です。採点、タグ付け、漏えい検出、優先順位付けを AI に任せています。

管理用のスキルが使用量に数えられるかは確認していません。展開前に確かめ、数えられる場合は評価の対象数を決めます。分析1回で評価するエージェントの上限は、プロパティで5件になっていました。

画面で見えるものと、設定値の初期状態がずれる

AI Gateway の画面は、プロパティが false のため表示されません。承認は MCP サーバーだけが必須です。評価のタブには「既定で無効」という案内が出たままでした。ドキュメントを読んで機能があると思っても、初期状態では動いていないことがあります。

実務では、展開前の確認リストに、機能の有無だけでなく初期値の確認を入れます。

展開前に決めること

次の表は、確認した範囲から導いた候補です。どれも、変更して試してはいません。

表の内容を文字でも書き出します。

• AI Analytics を見る人：ロールは viewer と admin の2種。閲覧は viewer、スキルとダッシュボードの対応付けは admin に分ける候補。ロールの存在のみ確認

• 展開前の承認：MCP サーバーだけが必須。危険度の高い資産種別から必須にする候補。値のみ確認

• AI Gateway：画面表示は無効。使うなら表示を有効にして、ポリシーを決める候補。値のみ確認

• 暴走の自動停止：設定が見つからない。公式の既定値（5回・25件・3日、warn_only）で始める候補だが、設定が存在するかを先に確認する。公式の記述のみ

• 管理用スキル：8件が有効。利用量に数えられるかを先に確認する。未確認

• 評価する範囲：1回の分析で5エージェントまで。対象を絞るか、上限を上げるか決める。値のみ確認

判断の順序は、先に見る人を決め、次に承認の対象を決め、最後に止める仕組みを決めます。見る人が決まっていないと、通知の送り先も決められません。

検証範囲とおことわり

• 1つのデモ環境で、読み取り専用の REST により、定義・件数・システムプロパティ・スキルの一覧を確認した

• 画面は、Now Assist アドミンの概要とスキル一覧、AI Analytics のダッシュボードの Overview、AI Control Tower ワークスペースの Overview・Evaluation・Security & privacy の各タブ、各テーブルとプロパティの一覧を表示して撮影した。設定の変更やボタンの実行はしていない

• 機能の動作、承認の流れ、隔離の実行、ダッシュボードの数字の算出方法は確かめていない。画面に出ている件数や指標はデモ環境のもので、運用の基準には使っていない

• 評価・トレース収集、AI Gateway のポリシー、アプリの一覧（ストアアプリのテーブル）は、使ったアカウントの権限では読めなかった。アプリの一覧は、スコープの定義から確認した

• 件数は定義とプロパティの確認にとどめた。デモ環境で後から追加された自動化ルール1件は、標準の構成ではないため除外した

• 暴走の自動停止の設定が見つからなかった理由は確かめていない。別の名前で存在する可能性や、まだ作成されていない可能性がある

• AI Analytics が使用量ログを元データにしているか、管理用スキルが使用量に数えられるかは未確認

• 「判断の候補」は試していない。変更して結果を確かめたものではない

• 契約や課金は扱っていない

用語

• AI steward：AI 資産の管理を担当し、承認と調整を行うロール

• AI 資産：AI システム・AI モデル・プロンプト・データセット・MCP サーバーの総称

• MCP サーバー：AI エージェントが使う外部の機能（ツール）を公開するサーバー

• ポリシーの実施点（PEP）：認証基盤やエージェントの実行基盤など、隔離を実際に実施する連携先

調べた公式ドキュメントのURL

• AI Control Tower dashboard：担当者ごとの画面の違い

• AI asset inventory：資産の5種類

• Exploring AI Analytics

• Value tab in AI Control Tower

• Kill Switch in Now Assist AI Agents：暴走トリガーの自動停止

• AI agent containment using kill switch protocol manually：エージェントの隔離

• AI Gateway

• Evaluation tab in AI Control Tower：評価のロールと対象外の条件