生成AI の利用量はどれだけ増えるか：要約・生成の回数と記録

Now Assist の利用量は、画面で押した回数どおりに数えられるのでしょうか。インシデントの要約、解決メモ、ナレッジ記事の生成を動かし、使用量のログの行数と突き合わせました。結果は、狙って実行した回数より記録の行のほうが多くなりました。レコードを開いただけで、要約が1行ずつ増えていたためです。

画面で確かめた要点

• 狙って実行したインシデント要約は33回、使用量ログの要約は72行。差の39行は、レコードを開いただけで自動生成された要約

• 解決メモは、使用量ログが37行で1回1行。ただし今回は解決メモの各回の直前に、要約が1行付いていた

• ナレッジ記事本文の生成は、1回で1行、1行あたり試用10アシスト。要約や解決メモの10倍の重さ

• Skill Kit のテスト実行は9回で9行。インシデント要約と違い、assists に1、trial assists に0が入っていた

• 申請・要求アイテム・カタログタスクの要約は、生成ボタンを押した回数と行数が一致した

試行の規模

2026年10月1日から3日に、筆者が同じ環境で動かした5系統の実行を数えました。デモレコードを使い、実行者は筆者1名です。ケーススタディであり、Now Assist 全体の利用量を評価するものではありません。請求額は扱わず、使用量のログに残った回数だけを扱います。

今回扱う記録と機能

利用量は、次の記録と画面で確認できます。

• sys_gen_ai_usage_log（Generative AI Usage Log）：有効。アシストの数を1行ずつ記録する。今回、該当する行をすべて読んだ

• sys_generative_ai_log（Generative AI Log）：有効。生成1回ごとの入力・出力・所要時間・元のレコードを記録する。今回、該当する行をすべて読んだ

• Subscription Management の Now Assist usage：契約全体の使用量を見る画面。管理者ロールが必要。今回は開いていない

• AI Analytics：スキルごとの利用状況を見るダッシュボード。今回は開いていない

契約の使用量の画面は開いていませんが、管理者向けの Now Assist アドミンにも、使用状況を見るパフォーマンスの画面があります。次の画像の①は期間中の Now Assist アクション総数、②は日ごとのアクション数の推移です。環境全体の集計であり、今回の実行だけの数ではありません。

数えられる側の機能は、起動のきっかけが違うものを選びました。

• Incident summarization（インシデント要約）：レコードを開くと自動で動く。今回動かした

• Resolution notes generation（解決メモ生成）：ボタンを押すと動く。今回動かした

• KB generation（ナレッジ記事本文の生成）：依頼文を送ると動く。今回動かした

• AI Skill Kit のテスト実行：開発者が試すときに動く。今回動かした

• Request summarization・Requested item summarization・Catalog task summarization（申請・要求アイテム・カタログタスクの要約）：生成ボタンを押すと動く。今回動かした

• Change の要約：今回の New 状態の変更では、要約が表示されなかった。原因は確かめていない

起点ごとに、どこへ記録が残るかを図にしました。起点は画面の操作、緑は実機で確認した記録先、橙は人が押さなくても動く箇所、灰色は今回開いていない画面です。

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

• 画面の操作は3種類。レコードを開く（要約が自動で生成される）／生成ボタンを押す・ナレッジ作成画面で依頼する／Skill Kit でテスト実行する（この2つは生成が実行される）

• どれも sys_generative_ai_log に生成1回につき1行が残り、元のレコードの sys_id も記録される

• 多くの行は sys_gen_ai_usage_log のアシスト数の記録に紐づく

• 集計の画面は Subscription Management の Now Assist usage と AI Analytics。今回は開いていない

5系統の実行

数え合わせた実行は、次の5系統です。

• 記録の厚さが違うインシデント3件で、要約を3回ずつと試験1回、解決メモを計29回

• 上のうち2件で要約を10回ずつ、うち1件で解決メモを5回

• 別のインシデント1件で、要約3回、解決メモ3回、ナレッジ記事本文の生成3回

• Skill Kit で複製したカスタムスキルのテスト実行9回

• 申請3回、要求アイテム4回（試験1回を含む）、カタログタスク3回の要約、要求アイテムの返信文の生成2回、変更の要約画面の確認

挿入・保存・解決・メール送信は実行していません。画面で実行した回数を手元の記録から集め、使用量ログと生成ログの行を、時刻とレコードで照らし合わせました。

Now Assist「Incident summarization」の検証

Incident summarization は、インシデントの問題と実行された主なアクションを要約するスキルです。このデモ環境では、レコードを開くと生成が始まります。

開き直した回数だけ、要約の行が増えた

同じ2件を10回ずつ開き直した要約は、20回で20行でした。1回開くと1行増えます。どの行も、assists は0、trial assists は1でした。

解決メモの直前に付いた要約の行

解決メモ欄を使うには、レコードを開く必要があります。開いた時点で要約が自動生成されるため、解決メモの37回すべての直前に、要約の行がありました。直前とは、数十秒から1分ほど前のことです。

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

• 要約（3件×3回＋試験1回）：狙って実行10回、ログ10行。差なし

• 要約（2件×10回）：狙って実行20回、ログ20行。差なし

• 解決メモ（3件、計29回）：狙って実行29回、ログ58行。レコードを開くたび、要約が1行増えた

• 解決メモ（1件、5回）：狙って実行5回、ログ10行。同上

• 要約3回・解決メモ3回（ナレッジ作成も実施）：狙って実行6回、ログ11行。解決メモ前に3行、ナレッジ作成前に2行増えた

5つの場面の合計は、狙って実行70回に対して、ログ109行です。差の39行は、要約を狙って実行していない場面で増えた行で、109行の36%にあたります。

狙って実行した回数と、ログの行数の差を図にしました。緑は狙って実行した要約、橙はレコードを開いただけで増えた要約、青は解決メモです。

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

• 狙って実行：要約33回＋解決メモ37回＝70回

• 使用量ログ：要約33行＋自動の要約39行＋解決メモ37行＝109行

• 差の39行は、解決メモやナレッジ作成のためにレコードを開いたときに自動で生成された要約

解決メモやナレッジ作成のためにレコードを開いた回数だけ、要約の利用量が積み上がりました。要約の生成ボタンは押していません。

数え合わせでは、行の数より先に列の値を見ました。assists が0で trial assists が1という組み合わせは、72行すべてで同じです。行ごとに違うのは、作成時刻と元のレコードだけでした。このため、要約の利用量は行数を数えるだけで出せます。

Now Assist「Resolution notes generation」の検証

Resolution notes generation は、解決メモ欄から問題・原因・解決手順を生成するスキルです。ボタンを押したときに動きます。

使用量ログの解決メモは37行で、1回の生成が1行に対応します。assists は0、trial assists は1です。手元の操作記録は、解決メモの回数を「25回前後」と概数で書いていました。そのため37行のうち、3件分の29回は、ログの行から回数を確定しています。操作記録と独立に照らし合わせた値とは言えません。

Now Assist「KB generation」の検証

KB generation は、解決したインシデントからナレッジ記事の本文を生成するスキルです。ナレッジ作成画面で依頼文を送ると動きます。

3回実行し、使用量ログには3行が残りました。1回で1行、1行あたり trial assists は10です。行は、依頼を送ってから数秒後に作られていました。生成が終わる前に記録されるため、記録の時刻は依頼の時刻とほぼ同じです。

このほかに、同じ種類の行が3行ありました。同じ環境で、別の作業として別のインシデントからナレッジ記事を生成した行です。この記事の数え合わせの対象ではないため、「狙って実行した回数」に入れていません。

AI Skill Kit のテスト実行の検証

AI Skill Kit は、スキルを自社用に作る機能です。複製したカスタムスキルを9回テスト実行しました。

使用量ログは9行で、どの行も execution type が「テスト」、assists が1、trial assists が0でした。インシデント要約は assists 0・trial assists 1でしたが、テスト実行は assists 1・trial assists 0という記録です。このデモ環境で、なぜ区別されるのかは確かめていません。

公式ドキュメントにも、管理コンソールでプロンプトの出力を試すたびに、1アシストとして追跡されると書かれています。

申請・要求アイテム・カタログタスクの要約の検証

Request summarization・Requested item summarization・Catalog task summarization は、申請系のレコードを要約するスキルです。レコードを開くと「AI サマリー」のカードが出て、生成ボタンを押すと動きます。

押した回数と、使用量ログの行は一致しました。

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

• Request summarization：3回、3行

• Requested item summarization：試験1回を含む4回、4行

• Catalog task summarization：3回、3行

• Requested item activity response generation（返信文の生成）：2回、2行

• 変更：今回の New 状態の変更では要約が表示されず、ログの行も確認できなかった。原因は未確認

どれも trial assists が1でした。インシデント要約と違って、開いただけでは行は増えません。同じ「要約」でも、自動で動くスキルと、押して動くスキルがあります。

AI エージェントや自動の機能は、1行の数が大きい

人が押さなくても、使用量ログの行は増えます。1行のアシスト数も、スキルによって違います。

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

• インシデント要約：狙って実行33回、ログ72行、1行あたり試用1

• 解決メモ生成：狙って実行37回、ログ37行、試用1

• ナレッジ記事本文の生成：狙って実行3回、ログ6行（うち3行は別の作業）、試用10

• Skill Kit のテスト実行：狙って実行9回、ログ9行、1（試用ではない）

• AI エージェントの呼び出し：回数は対応づけ不可、ログ3行、試用25

• スキル作成中の冗長性チェック：押していない、ログ1行、1

AI エージェントの呼び出しは、同じ環境で別の作業が動いた時間帯に3行ありました。1行に trial assists 25が入っていました。どの作業に対応するか特定できなかったため、回数は示せません。

システム自身が作った行もありました。10月1日以降、スマート優先度スコアの生成として30行が記録され、どれも assists が1です。起動のきっかけは確認していません。

筆者の対象6種類（表の6行）では、128行が記録され、assists の合計は10、trial assists の合計は244でした。申請系の12行とシステム作成の30行は、この集計に含めていません。要約と解決メモの109行は、アシスト数の合計254のうち約43%にあたります。

利用量の見張り方

見る場所は、使用量ログと生成ログの2つです。どちらも REST の集計で確認しました。画面のリストを開く操作は今回していません。

使用量ログのリストは、ナビゲーションに sys_gen_ai_usage_log.list と入力して開きます。公式ドキュメントにも同じ手順があります。

次のクエリで、使用量ログの自分の行をスキル別に集計できます。生成ログの条件はレコードの sys_id だけなので、そのレコードの全期間・全ユーザーの生成が対象です。今回と同じ範囲にするには、作成者と期間を別に絞ります。

# 使用量ログ：自分の直近2日分をスキル別に集計（REST の stats）
/api/now/stats/sys_gen_ai_usage_log
  ?sysparm_query=user=javascript:gs.getUserID()^sys_created_on>=javascript:gs.daysAgoStart(2)
  &sysparm_count=true
  &sysparm_group_by=skill_config_id
  &sysparm_sum_fields=assists,trial_assists

# 生成ログ：1件のレコードに対する生成の回数をスキル別に集計
/api/now/stats/sys_generative_ai_log
  ?sysparm_query=metadata_document=<レコードの sys_id>
  &sysparm_count=true
  &sysparm_group_by=skill_config_id

生成ログには、元のレコードの sys_id が記録されます。1件のインシデントに何回生成が動いたかを、これで調べられます。たとえば、実行を重ねたデモのインシデント1件には、要約が24行、解決メモが11行ありました。この件数は、その1件を開いた回数と解決メモを押した回数の合計に対応します。

数え合わせは、画面で実行した回数をメモしておき、使用量ログの行数と比べると確実です。

使用量ログの execution type を「テスト」で絞ると、開発者のテスト実行を本番の利用と分けて数えられます。ナレッジ記事の生成のように、生成ログと使用量ログが紐づかないスキルもありました。この場合は、時刻で照らし合わせます。

公式ドキュメントの説明

公式ドキュメントでは、使用量について3か所が参考になります。

Generative AI Controller tables は、使用量ログの列の一覧です。assists と trial assists の列があり、execution type の値は Test・Evaluation・Auto Prompt Tuning です。

Monitoring Now Assist usage in Subscription Management は、契約全体の使用量の見方を説明するページです。スキル別の合計は、実行回数に Assist ratio（アシストの換算比）を掛けて求めると書かれています。デモ環境の扱いについては、次の記述があります。

（訳：デモインスタンスで使ったアシストは、アシストの総使用量から除かれる）

このデモ環境で見た行が、契約の使用量にそのまま加算されるとは限りません。Assist ratio の画面は開いていないため、行数と請求の関係は扱いません。

Skill inputs and triggers for ServiceNow Otto for ITSM は、ITSM の各スキルの入力と起動のきっかけを説明しています。どのスキルが自動で動き、どのスキルが操作で動くかは、この表で先に確認できます。

Using ServiceNow Otto for ITSM Generative AI skills は、要約や解決メモの使い方の説明です。利用量の見積もりでは、担当者がどの画面でこれらを使うかを、先にここで洗い出します。

Custom skill details は、カスタムスキルが消費したアシスト数を、日付の範囲で見るダッシュボードの説明です。今回は開いていません。

Kill Switch in Now Assist AI Agents は、同じレコードで AI エージェントのトリガーが繰り返し動く場合を説明しています。トリガーが動くたびに会話が作られ、アシストが消費されると書かれています。今回は試していません。

実機で気づいたこと

要約の利用量は、レコードを開く回数で決まった

要約は、押していなくても開くたびに1行増えました。担当者が1件のインシデントを4回開けば、要約だけで4行です。1日20件を各4回開く運用なら、仮定の例ですが、要約だけで80行になります。

管理者向けの画面でも、スキルごとの利用回数の推移を見られます。画像の①は凡例にある Incident summarization と Resolution notes generation、②はスキルごとの利用回数の推移です。環境全体の傾向を見る画面であり、今回の行数との照らし合わせには使っていません。

見積もりは、生成を押す回数ではなく、レコードを開く回数で立てます。自動で動かない設定にできるかは確かめていません。

解決メモ1回につき、要約1行

解決メモを使うには、まずレコードを開きます。今回は解決メモを試すたびに開き直したため、要約が1行ずつ付きました。解決メモの利用量を見積もるときは、画面を開く回数に含まれる要約の分を、二重に数えないように足します。

1行のアシスト数はスキルで違う

行数だけを数えると、全体の利用量を見誤ります。今回の行では、要約・解決メモの trial assists が1、ナレッジ生成が10、AI エージェントの呼び出しが25でした。集計では、skill_config_id ごとに assists と trial assists を合計します。

ここから先には、自社の件数で利用量を見積もる手順と記入式、スキルごとの数え方と見積もりの単位をまとめた表、担当ごとの作業を置いています。分量は本文全体の約3割です。

💰 ここから先は有料エリア