Now Assistのアシスト消費の数え方と確認場所（Otto・Brazil時点）

ServiceNow Otto（Now Assistを含むAI体験）の利用量は、契約したアシストの枠から消費されます。ServiceNowのAIを使い始めた管理者が最初に困るのは、何がどれだけ消費されるのか、どこで確かめるのかです。

Brazilのリリースが近づき、「Brazilで利用量の数え方は変わるのか」という疑問も出ています。結論から書くと、Brazilのリリースノートに、アシストの数え方を変える記載は見つかりませんでした。数え方、確認する画面、使いすぎを防ぐ設定は、ServiceNowの社員がコミュニティに書いた2026年6月から7月の資料が最も詳しいため、それをもとに整理します。この資料はAustralia Patch 3までのリリースを前提にしています。

「アシスト」は何を数えるのか#

Now Assistはトークンではなく、アシストという単位で消費を数えます。アシストはNow Assistのスキルやエージェント型のワークフローが実行されるたびに発生します。

• ケースの要約のような単純なスキルは、1アシストを消費する
• 複数のアクションを使うエージェント型のワークフローは、25アシスト以上を消費する

エージェント型のワークフローは、1回の実行で使ったツールの数で消費量が決まります。オーケストレーターとコミュニケーターのエージェントの動作は数えません。

1回の実行で使ったツールの数	区分	消費するアシスト
0〜4	Small	25
5〜8	Medium	50
9〜20	Large	150

ワークフローの中でツールとして動くスキル、Virtual Agentのトピック、会話型のカタログアイテムは、単独では追加のアシストを消費しません。請求の対象になるのは、エージェント型のワークフローの実行そのものです。この資料は、ツールを9個から8個に減らすと、1回あたりの消費が150から50に下がる例を挙げています。

契約したアシストの枠は、365日で使い切る形で管理され、契約の記念日に毎年リセットされます。本番環境だけでなく、本番以外の環境の利用と、AI Agent Studioでのテストも、同じ枠から消費されます。ただし、ServiceNowの公式資料は、デモインスタンスで使ったアシストは、使用済みの合計から除かれると説明しています。つまり、Brazilのアップグレードの検証で、本番以外のインスタンスでAI機能を試すと、その分は契約の枠から差し引かれます。デモインスタンスで試した分は差し引かれません。

Brazilで変わるか：確認できたこと#

ServiceNow Docsのリリースノートのうち、「New features and products in Brazil」「Changes to Brazil features and products」「Upgrade information for all Brazil features and products」の3つを調べました。検索にはassistなどの語を使いました。

アシストの数え方、1回あたりの消費量、契約の枠の大きさを変えるという記載は、見つかりませんでした。AIの利用量や権利に関係する記載は、次の6つです。

• Now AssistとMoveworksの体験は、ServiceNow Ottoという名称に変わる（変更点）。アップグレード情報のVulnerability Responseの項は、Ottoが新しいAI体験のブランドで、製品名に反映されると説明した上で、「製品の権利は変わらない。特定の機能へのアクセスは、権利を確認して判断する」と書いている
• AIのライセンスにFoundation、Advanced、Primeの3つの階層があり、ライセンスに応じて、使えるアプリの機能、生成AIのスキル、エージェント型のワークフロー、AIエージェントが変わる（新機能と変更点の両方）
• Security Incident Responseに、AI ROI Summaryのダッシュボードが加わり、指標に消費したアシストの合計と、解決したインシデント1件あたりのアシストが含まれる（新機能）
• 古いAIモデルは公開済みのスキル、エージェント、ワークフローでは使い続けられるが、新規の開発や設定では使えなくなる。詳細はNow Supportの知識ベースの記事（KB3066214）に案内されている。ログインが必要なため、この記事では読んでいない（変更点）
• AI Control Towerのセキュリティ設定（Settings > Rules and templates > Security）で、サンプリング率（Sampling rate）とスキル呼び出しの上限（Max skill calls）の既定値が変わり、アップグレードすると新しい既定値に更新される（変更点）。リリースノートはアシストとの関係に触れていない
• アプリの概要の生成（App summary generation）が、スキル方式からAIエージェントの方式に変わる。App summaryのプラグインを入れると、App Summary AI agentが付いてくるが、予期しない課金を避けるため、既定では無効になっている。利用者が概要を生成する前に、管理者がAI Agent Studioで有効にする（変更点）

ServiceNowは、コミュニティの告知でも、名称変更は「ライセンス、権利、既存のアクセスに影響しない」と説明しています。新たに購入する必要もないとされています。この告知はコミュニティの表記変更についての説明で、自社の契約の扱いは、ServiceNowの担当者に確認する必要があります。

AI Control Towerの2026年8月・9月のリリースには、ServiceNowのAI Assistの消費を含む、AIの消費コストを追跡・配賦する機能があります。部門とユーザーごとの集計は、ServiceNowのAIエージェントとAnthropicのAIに限られます。同じ記事は新機能の多くが新しい画面でだけ使えると書いています。

この確認は3つの一覧の範囲です。個別の製品のリリースノートと、契約上の取り決めまでは確認できていません。

利用量を確認する場所#

利用量は粒度の違う次の場所で確認できます。

1. Subscription Management（Subscription Management > Subscriptions > Now Assist usage）: 契約したアシストの合計、使用済み、残りがインスタンスをまたいで表示される。インスタンスごとの内訳もある
2. Account level entitlements（Subscription Managementのタブ）: スキルとエージェントの名前ごとに、アクションの回数、アシストの比率（assist ratio）、アシストの合計が表示される。公式資料によると、アシストの合計は、アクションの回数にアシストの比率を掛けて算出する
3. Now Assist Admin > Analytics: インスタンス単位のダッシュボード。利用状況、スキルの性能、自社で作ったスキルの実行結果などを見る。Storeのアプリで、Now Assistの契約以外の費用は不要とされている
4. AI Agent Studio > Analytics > Assist Consumption: AIエージェントのアシストの消費
5. AI Control Tower: 消費のダッシュボードがあり、先に書いたコストの配賦もここで行う

資料は、Account level entitlementsの内訳を見ると、枠を多く消費しているのが、よく使う軽いスキルではなく、あまり使わない複雑なエージェントだと分かることがあると説明しています。スキルごとの消費量を知りたいときは、ここで自社の値を確かめます。

消費の生データはテーブルに記録されます。sys_gen_ai_usage_logには呼び出しごとのアシスト数が入り、sys_generative_ai_logには、スキルを実行した元のケースやタスクへの参照が入ります。2つを結び付けると、ある消費をどのレコードが引き起こしたかをたどれます。エージェントの実行の区分はsn_aia_tool_execution_tierで確認します。

資料には運用で気を付けることも書かれています。アシストの計算に失敗すると、1時間ごとのジョブが再計算します。メータリングはインスタンスの外でまとめて処理されるため、記録に少し遅れが出ます。クローンで利用量のテーブルを本番から開発環境にコピーすると、分析が実態とずれるため、クローンの設定で対象外になっているかを確かめます。

使いすぎを防ぐ設定#

システムプロパティで、通知、停止、制限を設定できます。次のプロパティはZurich Patch 10とAustralia Patch 3（2026年6月）から使えるとされています。Brazilでの扱いは、読んだ資料に書かれていません。

急増の通知（sn_aia_propertyテーブル）

プロパティ	内容	既定値
alert.assist_spike_hours_to_check	急増を確認するジョブの間隔（時間）	3
alert.assist_spike_usage_percentage_threshold	前回から何割増えたら通知するか	0.5（50%）
alert.assist_spike_usage_threshold	通知が出る最小のアシスト数	5,000

暴走するトリガーの停止（kill_switch.*）

kill_switch.modeは、off、warn_only、enforceから選びます。既定値はwarn_onlyで、毎日警告を送ります。enforceにすると、1日目と2日目に警告を送り、3日目にトリガーを無効にします。判定の条件は同じレコードで1つの観測期間に起動した回数の上限（kill_switch.max_fires_per_window、既定値5）、その上限を超えたレコードの数（kill_switch.min_distinct_records、既定値25）、観測期間（kill_switch.window_size、既定値1440分）、さかのぼる期間（kill_switch.consecutive_windows_duration、既定値4320分）の4つで決まります。

再帰の防止（recursive_check.*）

同じ条件の実行がレコードを作る回数は、15分あたり50回まで（既定値）、更新する回数は15分あたり5回までです。「レコードの作成時」と「更新時」のトリガーを組み合わせるとループが起きるため、トリガーの設定を見直すよう資料は勧めています。

リクエスト数の制限

sys_one_extend_rate_limit_rulesで、生成AIの機能やLLMの提供元へのリクエスト数を、インスタンスまたはユーザーごとに制限できます。エージェントの実行を制限するときは、Capability DefinitionにAIA ReAct Engineを指定します。

資料は本番以外の環境でも消費に関する通知を切らないよう勧めています。開発やテストで予期しない急増が起きるためです。

チームや個人ごとに上限を決め、超えたら止めたい場合は、別の資料が標準の機能だけで作る方法を紹介しています。sys_gen_ai_usage_logをもとにレポートを作り、上限の50%、75%、90%で警告を送り、超えた人からスキルのロールを外します。期間が変わったときに、ロールを自動で戻します。個人単位で止めるには、そのロールを対象のユーザーに直接付与している必要があります。共有のロールやグループから継承している場合は、停止用のグループを、スキルのapplicability conditionで除外します。標準のスキルが参照するロールそのものは、書き換えないよう資料は勧めています。この資料は、Now Assistの分析やSubscription Managementで消費を報告する機能はあっても、チームや個人の消費が多いときに自動で動く機能はない、と説明しています。

アップグレードの前に確認すること#

Brazilのアップグレードと、アシストの消費の関係で、確認しておく項目をまとめます。

1. 検証用のインスタンスで、AI機能を試す前に、急増の通知が有効なことを確かめる。検証の消費も契約の枠から引かれる
2. AI Control Towerのセキュリティ設定のサンプリング率とスキル呼び出しの上限が、アップグレードで新しい既定値に更新されるため、アップグレード後に値を確認する
3. Subscription Managementで、今の消費をスキルごとに記録しておく。アップグレード後の変化を比べる基準になる
4. 新規に作るスキルやエージェントで使うAIモデルが、Brazilで使えるものかを確かめる

契約上の単価や、階層ごとの枠の大きさは、公式の資料では確認できませんでした。契約に関わる点はServiceNowの担当者に確認してください。

報道も契約の確認を勧めています。CIOの記事（2026年5月12日）は、契約に一定数のアシストが含まれ、必要なら顧客が追加分を購入できると伝えています。エージェント型のやり取り1回で使うアシストが変わるため、利用量や請求額は予測しにくいとも書いています。

Info-Tech Research Groupのアナリストは、契約で「メーターが動き始める境目」を確かめるよう助言しています。エージェントが再試行のループに入ると、アシストを消費し続ける恐れも挙げています。

TechTargetの記事（2026年4月10日）は、4月9日からFoundation、Advanced、Primeの階層で製品を提供すると伝えています。以前は別に購入していたAIの基盤の層も、この階層に含まれます。