Build Agent（Trial）はインスタンスに何を入れるか
Build Agent は、チャットで指示するとアプリケーションやメタデータを作ってくれる ServiceNow のエージェント型開発機能です。その Trial 版はスコープ sn_try_build_agent の Store アプリとして、テーブル 6 個・Script Include 12 個・REST API 1 本の構成でインスタンスに入ります。話題の機能ですが、「インスタンスの中に何が追加されるのか」「無料枠の制限はどこで管理されるのか」を書いた日本語の情報はまだ少ないです。そこで、PDI に入っていた Build Agent (Trial) の中身をテーブル単位で確認しました。
対象読者は、ServiceNow のテーブルや Scoped App の仕組みをある程度知っていて、Build Agent を試す前に「入れると何が起きるのか」を把握しておきたい管理者・開発者です。生成される成果物の品質評価はこの記事の範囲に含めません。
この記事で分かること
Build Agent と Now Assist for Creator・ServiceNow IDE・ServiceNow Studio の関係（公式ドキュメントの整理）
公式・コミュニティの実例から見る「どんな指示でどんなアプリができるか」
公式ドキュメントに書かれている正式版（Now Assist for Creator ライセンス）の機能一覧
Build Agent (Trial) がスコープアプリとして持ち込む 259 個の構成ファイルの内訳
会話を保存する conversation / message テーブルの構造と親子関係
エージェントの知識源 knowledge_source に Fluent のドキュメントが 34 件入っていること
テレメトリと利用ログの 3 テーブルが admin でも REST で読めないこと
フリーミアム制限に関わるシステムプロパティの実測値と、公式ドキュメント記載との差
この記事の内容は PDI（Personal Developer Instance）の Zurich リリース（OOTB ＋ Store の Build Agent (Trial) v1.3.17）で確認した個人メモです。Trial アプリは更新が速く、バージョンや本番のライセンス形態によって構成・制限値が異なる場合があります。
Build Agent とは
公式ドキュメントの Exploring Build Agent によると、Build Agent は「Agentic development on the ServiceNow AI Platform」に位置づけられる開発支援機能で、新規アプリの作成、既存アプリの編集、app file の追加・更新、ドキュメント生成などを会話形式で行います。リリースノートでは "create, edit, and deploy full-stack applications and metadata through a conversational interface" と説明されています。
どんな指示ができるかは公式の Example prompts に例があり、扱えるメタデータの範囲は Supported metadata と Supported file types にまとまっています。
指示するとどうなるか：プロンプト例
今回の PDI では conversation テーブルが 0 件（後述）で、Build Agent を自分ではまだ起動していません。ここでは公式の Example prompts と ServiceNow Community の実例を、docs・コミュニティ記載の結果とあわせてそのまま引用します。
プロンプト（原文） 記載されている結果
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"Help me brainstorm a ServiceNow app for managing office supplies. I want employees to request supplies and managers to approve them." アプリの概要・想定テーブル・ユーザーストーリー・技術要件をテキストで提案（この段階ではまだメタデータは作らない）
"Build me a simple task tracking app so I can learn how ServiceNow tables, forms, and business rules work together." テーブル・フォーム・Business Rule が連携して動くタスク管理アプリを実装
"Create a Storeroom Asset tracking application. It should have a display that shows me all the storerooms, how many items are in each storeroom, items that are low in stock, and any other useful features you can think of." テーブル・Business Rule・UI ページ・サンプルデータの構成を作成（ビルド時にエラーが出て修正が必要だったとの報告あり）
"Create a comprehensive incident management enhancement with custom fields, automated notifications, and a modern dashboard - then deploy it so I can test it." カスタムフィールド・自動通知・ダッシュボードを備えた拡張機能を作成し、デプロイまで実行
"Create some tests to ensure this app works when we do system changes or upgrades." フォーム・サーバサイド・API・画面遷移・E2E を含む ATF テストスイートを生成指示の粒度は「構想の壁打ち」から「デプロイまで任せる」まで幅があり、Supported metadata の範囲であれば会話の中でテーブル・フォーム・スクリプトがまとめて生成される、という位置づけでした。Storeroom アプリの例は Community のブログ記事 に、他の例は Vibe coding 紹介記事 に載っています。
正式版（Now Assist for Creator ライセンス）でできること
ここまでの例は Trial 版が前提でした。有償の正式版について、公式ドキュメントの Exploring Build Agent には、次の機能が章立てで説明されています（この PDI では正式版は確認しておらず、docs の記載をそのまま整理したものです）。
アプリケーションの新規作成（Create an application）
既存アプリケーションの編集（Edit an existing application using Build Agent）
アプリファイルの追加・更新（Adding or updating app files）
ワークフロー・エージェント・スキルの作成（Create workflows, agents, and skills）
作成したものをテストする（Testing what you built）
アプリケーションのドキュメント生成（Document an application）
アプリへの変更を取り消す（Revert app changes）・変更ログの参照（Conversation change log）
Update Set との連携（Update sets）
デプロイ（Deploying）
Trial 版で確認した会話（conversation/message）・知識源（knowledge_source）・REST API という骨格は、正式版でも同じ土台の上に機能が積まれていると考えられます。ただし、この対応関係自体は docs に明記がなく未確認です。
Now Assist for Creator・ServiceNow IDE との関係
Build Agent を取り巻く用語を、Now Assist for Creator・ServiceNow IDE・ServiceNow Studio の docs をもとに整理すると次のようになります。
要素 種別 役割 利用に必要なもの
-------------------------------------------------------------------------------------------------------------------------------------------------
Now Assist for Creator ライセンス体系 Build Agent 正式版が属するライセンス 契約（リリースノートには "You must have a Now Assist for Creator license for the new button to appear" とある）
Build Agent (Trial) Store アプリ ライセンスなしで試せる無料版。今回の PDI に入っていたのはこちら ServiceNow Store からのインストールのみ（回数制限つき）
ServiceNow IDE 開発環境（VS Code for the Web ベース） Build Agent とチャットする場所の1つ プラグイン `com.glide.ide_platform`（この PDI では active）
ServiceNow Studio 開発環境 もう一つのチャット画面 Now Assist for Creator ライセンス側の対応状況に依存（docs 記載）docs では、Build Agent との対話で作ったアプリを IDE で仕上げる Vibe code with Build Agent という使い方も紹介されています。
今回の PDI に入っていたもの
今回の PDI では、プラグイン com.glide.ide_platform（ServiceNow IDE Platform, v1.0.0）と com.now_assist_core（Now Assist Core v28.6.6）が active でした。一方で com.glide.cs.genai（v1.0.0）は inactive のまま、Now Assist for Creator に対応するプラグイン id も v_plugin には見当たりません。Now Assist for Creator のライセンスや専用プラグインがなくても、Trial アプリだけで Build Agent を試せる構成になっていました。
Now Assist 側を見ると、sn_nowassist_skill_family テーブル（32 件）に「Creator」というスキルファミリのレコードが OOTB で存在します。ただし Creator ファミリに属するスキル設定（sn_nowassist_skill_config）は 0 件で、この PDI では器だけがある状態でした。
https://<YourInstance>/v_plugin_list.do?sysparm_query=idINcom.glide.ide_platform,com.now_assist_core,com.glide.cs.genai
Build Agent (Trial) の実体はスコープアプリ
Trial 版の Build Agent は ServiceNow Store から入手する Store アプリで、インストールすると sn_try_build_agent というスコープが追加されます。
sys_scope で見るアプリの素性
sys_scope を scope=sn_try_build_agent で引くと、name は Build Agent (Trial)、version は 1.3.17、クラスは sys_store_app（Store Application）でした。sys_store_app テーブルを直接 REST で読むと 403 が返りますが、親クラスにあたる sys_scope 経由なら同じレコードを参照できます。
https://<YourInstance>/sys_scope_list.do?sysparm_query=scope=sn_try_build_agent
構成ファイルは 259 個
このスコープに属する sys_metadata（Application File）をクラス別に数えると、合計 259 件でした。内訳は次のとおりです。
クラス 件数 中身
-------------------------------------------------------
sys_db_object 6 テーブル定義
sys_dictionary / sys_documentation 54 / 54 フィールド定義とラベル
sys_choice_set 4 選択肢セット
sys_script_include 12 サーバロジック本体
sys_script 4 Business Rule
sys_ws_definition / sys_ws_operation 1 / 14 Scripted REST API
sys_properties 6 動作設定・制限値
sys_security_acl / sys_security_acl_role 50 / 52 アクセス制御
sys_module / sys_number 1 / 1 EcmaScript Module・採番定義6 テーブルはいずれも継承なし（super_class 空）・拡張不可（is_extendable=false）という設計でした。フィールド定義（sys_dictionary）の件数は task_telemetry が 16 件と6テーブル中もっとも多く、conversation・message はそれぞれ 6 件です。
Flow や UI ページは含まれず、テーブル・Script Include・REST API・ACL でほぼ全部という、サーバサイドに寄った構成です。全体の関係を図にすると次のようになります。
左メニューに入口はない
アプリケーションナビゲーターのモジュール（sys_app_module）は sn_try_build_agent スコープに 1 件もありません。スコープ内の sys_module 1 件も EcmaScript Module（ES モジュール）で、メニューとは別物でした。実際の入口は ServiceNow IDE 本体（スコープ sn_glider）が持つ「ServiceNow IDE」モジュールで、リンク先は sn_glider_app/ide.do です。docs の Accessing Build Agent が案内している経路も IDE / Studio からの起動でした。
https://<YourInstance>/sn_glider_app/ide.do
会話を保存する 2 テーブル
エージェントとのやり取りは conversation → message の親子で保存される設計です。今回の PDI ではまだ Build Agent を起動していないため、両テーブルとも 0 件でした。フィールド構成は sys_dictionary から確認できます。
sn_try_build_agent_conversation
会話 1 スレッドが 1 レコードです。固有フィールドは title、user（sys_user への参照）、application_id、last_message_at、active の 5 つだけでした。application_id は参照型ではなく string 型（32 桁）で、どのレコードの ID を入れるのかは 0 件のため確認できていません。
sn_try_build_agent_message
発言 1 件が 1 レコードで、conversation フィールドが親スレッドを参照します。本文は content という json 型フィールド（最大 50,000 文字）に入り、並び順は sequence（整数）が持つ構造でした。プレーンテキストではなく json 型なので、役割やツール呼び出しのような構造化データを 1 メッセージに収める前提の設計だと分かります。採番定義（sys_number）も message 用に 1 件（prefix なし・10 桁）割り当てられていました。
https://<YourInstance>/sn_try_build_agent_conversation_list.do
チャットからアプリができるまで
conversation・message はあくまで Build Agent (Trial) 自身のスコープ（sn_try_build_agent）に属する、チャットの記録用テーブルです。指示で作られるアプリ本体はそこには入らず、ServiceNow の Scoped Application の仕組みに沿って別の新しいスコープ（sys_scope）にテーブルや Business Rule として作られる、という理解になります（一般的な Scoped App のメタデータ構造から推測した流れで、Build Agent の docs にこの対応関係の明記はありません）。conversation の application_id は文字列型のフィールドで、この新しいスコープの sys_id を指すと考えられますが、0 件のため実際の値は確認できていません。
利用の流れを図にすると次のようになります。
エージェントの知識源：knowledge_source に Fluent ドキュメントが 34 件
6 テーブルの中で唯一、最初からデータが入っているのが sn_try_build_agent_knowledge_source です。34 件のレコードはすべて document_type=Documentation でした。plugin フィールドには TABLE、BUSINESS_RULE、CLIENT_SCRIPT、ACL、ATF_FORM といったメタデータ種別名が入っています。
これは ServiceNow Fluent（TypeScript 仕様ベースの DSL で、コンパイルするとプラットフォームのメタデータになる言語）の種別ごとのドキュメントです。内容を持つ content フィールド（最大 8,192 文字）と、fluent_version（3.0.0 が 26 件、4.0.0 が 8 件）を持ちます。4.0.0 で入っているのは FORM / GENERAL / LIST / ROLE / SCHEDULED_SCRIPT / SCRIPT_INCLUDE / UI_ACTION / UI_PAGE の 8 種でした。
つまり Build Agent は、Fluent API リファレンスに相当する知識をテーブルとしてアプリ内に同梱し、メタデータ生成の参照元にしている、という構造が読み取れます。後述の REST API にも、この知識を種別・バージョン指定で取り出す getFluentKS というオペレーションがあります。
https://<YourInstance>/sn_try_build_agent_knowledge_source_list.do?sysparm_query=ORDERBYplugin
admin でも読めない 3 テーブル：テレメトリと利用ログ
残る 3 テーブル（task_telemetry / event_telemetry / freemium_usage_log）は、admin 資格の REST でも読み取りが 403（Failed API level ACL Validation）になりました。フィールド定義（sys_dictionary）は読めるので、構造だけ確認しています。
テーブル Label レコード件数 admin の REST 読み取り
---------------------------------------------------------------------------------------------------------
sn_try_build_agent_conversation Build Agent Conversation 0 可
sn_try_build_agent_message Build Agent Message 0 可
sn_try_build_agent_knowledge_source Build Agent Knowledge Source 34 可
sn_try_build_agent_task_telemetry Task telemetry 取得不可 403
sn_try_build_agent_event_telemetry Event telemetry 取得不可 403
sn_try_build_agent_freemium_usage_log Freemium Usage Log 取得不可 403https://<YourInstance>/sys_db_object_list.do?sysparm_query=nameSTARTSWITHsn_try_build_agent
task_telemetry：1 タスクの作業量を記録する器
task_telemetry には request（依頼文、最大 100,000 文字）、task_type（create / edit）、status（start / complete / in-progress / aborted / error）に加えて、lines_added・lines_deleted・lines_edited（変更行数）、metadata_types（扱ったメタデータ種別数）、build_fix_cycles（ビルド修正の往復回数）、rollbacks（巻き戻し回数）という整数フィールドが並びます。エージェントがコードを何行書き、何回ビルドをやり直したかを数える構造です。
agent_status の選択肢は SUCCESS / FAILURE_GAVE_UP / ERROR_INTERNAL の 3 つ（内部値はすべて小文字）でした。「諦めた」を表す値が最初から定義されている点に、エージェントの実行が失敗し得る前提の設計が見えます。
event_telemetry と freemium_usage_log
event_telemetry は event_id フィールドで task_telemetry を参照する子テーブルで、name・status（Success / Failure）・total_time・errors を持ちます。タスクの中の個々のイベントを記録する粒度です。
freemium_usage_log は LLM 呼び出しの記録です。prompt と response（各最大 60,000 文字）、model（ラベルは LLM Model）、input_token_count / output_token_count、request_latency_ms を持ちます。無料枠の消費を数える根拠になるテーブルとみられますが、実データは読めないため、実際に何が書かれるかは検証範囲外です。
ACL は admin_overrides=false
この 3 テーブルの ACL を見ると、read / write / delete の大半が admin_overrides=false でした。admin_overrides が false の ACL は admin ロールでも素通りできないため、REST が 403 になった観察結果と整合します。スコープ内の ACL は 50 件、ロール割り当ては 52 件で、割り当て先の 44 件が admin、残りは REST から名前を解決できないロールでした。Governance のページが用意されていることも合わせると、利用記録の保全側に倒した設計です。
フリーミアム制限の観察
プロパティに見える上限値
スコープ内の sys_properties は 6 件で、名前から役割が読み取れます。
プロパティ 値
-------------------------------------------------
sn_try_build_agent.user_prompt_limit 25
sn_try_build_agent.user_prompt_limit_pdi 10
sn_try_build_agent.prompt_limit_period_days 30
sn_try_build_agent.tool.execution.timeouts run_query 120000 / get_knowledge_source 120000 / create_new_servicenow_app 300000 / default 240000（ms）
sn_try_build_agent.disable.stream.by.provider sys_id 2 件
sn_try_build_agent.error_recovery.config messageRecovery ＋ exponentialBackoff（5s/30s/60s）プロンプト上限 25（PDI 向けは 10）を 30 日周期で数える、という組み合わせです。タイムアウト設定からは、アプリ新規作成に 300 秒、その他ツールに 240 秒という時間感覚も読み取れます。
https://<YourInstance>/sys_properties_list.do?sysparm_query=nameSTARTSWITHsn_try_build_agent
docs の記載との違い
一方、公式の Limitations とリリースノート（2026-07-04 参照時点・最新ファミリー版の表示）には、Trial は 100 プロンプト、PDI は 25 プロンプト（いずれも per instance・30 日周期、"Limits are per-instance, not per-user"）とあります。今回の Trial v1.3.17 のプロパティ値（25 / 10）とは食い違っており、プロパティ名には user_ という接頭辞も付いています。どちらの値がどの単位（インスタンスかユーザーか）で効くのかは、実際に上限まで使っていないため検証範囲外です。数値を根拠に計画を立てる場合は、自分の環境のプロパティ値と docs の両方を見る必要があります。
消費を数えるのは Business Rule
スコープ内の Business Rule は 4 件でした。うち「Charge assists when using Build Agent」は message テーブルの after insert で動く構成です。名前から、メッセージ 1 件の作成を契機に利用量を消費させる役割と推測できます（script 本体は REST で取得できず、内部処理は検証範囲外）。ほかは last_message_at を更新する「Calculate latest message」と、テレメトリ 2 テーブルの「Calculate duration」です。Script Include 側にも PromptLimitChecker という名前のクラスがあり、上限判定のロジックがサーバ側に実装されていることが分かります。
Build Agent API：14 オペレーションの Scripted REST API
このアプリの外部との接点は「Build Agent API」という Scripted REST API（ベースパス /api/sn_try_build_agent/build_agent_api）1 本です。オペレーションは 14 個あります。conversations の作成・取得・無効化、messages の追加・取得のほか、目を引くものを挙げます。
POST /conversations/{id}/messages/revert_to_checkpoint … 会話をチェックポイントまで巻き戻す
GET /getFluentKS/{apiType}/{fluentVersion} … knowledge_source から Fluent ドキュメントを取り出す
GET /getTableSchema/{table} ／ GET /runQuery/table/{table}/query/{encoded_query} … テーブル定義と実データをエージェントが読む
GET /providerConfig … LLM プロバイダ設定の取得
POST /send ／ POST /telemetry … メッセージ送信とテレメトリ記録
getTableSchema や runQuery の存在から、エージェントがインスタンスのスキーマや実データを参照しながら生成を進める構造が読み取れます。チェックポイント巻き戻しの API がテーブル側の rollbacks フィールドと対応している点も、作っては戻す試行錯誤を前提にした作りです。
https://<YourInstance>/sys_ws_operation_list.do?sysparm_query=sys_scope.scope=sn_try_build_agent^ORDERBYname
Script Include に見える 3 系統のシステムプロンプト
Script Include は 12 件で、名前だけでも役割の見当が付きます。BaseSystemPrompt を筆頭に、ClaudeSystemPrompt・GeminiSystemPrompt・GPTSystemPrompt という 3 つのクラスが並んでおり、LLM プロバイダごとにシステムプロンプトを切り替える構造です。プロパティ側にも disable.stream.by.provider（プロバイダ単位でストリーミングを無効化する設定）があり、REST API の getAvailableAPITypes / providerConfig と合わせて、複数モデルを前提とした作りになっています。
ほかに SendMessage と SendMessageFreemium が分かれている点も特徴で、無料枠とライセンス版で送信経路が分岐する構成が名前から読み取れます。残る BuildAgentLogger・BuildAgentSystemPrompt・BuildAgentUtil・RestValidator・TelemetryManagement の5件は、ログ・システムプロンプトの共通処理・共通ユーティリティ・入力検証・テレメトリ集計を担うとみられる名前でした。いずれも script 本体は REST では取得できず、実装の中身は確認できていません。
ポイント
Build Agent (Trial) はスコープ sn_try_build_agent の Store アプリ（今回確認したのは v1.3.17）で、構成ファイルは 259 件。テーブル 6・Script Include 12・Business Rule 4・Scripted REST API 1 本（14 オペレーション）・プロパティ 6・ACL 50 という、サーバサイド中心の構成でした。
会話は conversation → message の親子で保存され、message.content は json 型（最大 50,000 文字）です。
knowledge_source には Fluent のメタデータ種別ごとのドキュメントが 34 件（v3.0.0×26 ／ v4.0.0×8）同梱されていました。
テレメトリ 2 テーブルと freemium_usage_log は admin_overrides=false の ACL で守られ、admin の REST でも 403 になります。
フリーミアムの上限はプロパティでは 25（PDI 10）／30 日周期、docs 記載は 100（PDI 25）／30 日周期・インスタンス単位。実際に効く値と単位は未検証です。
Build Agent (Trial) 自体はメニューを持ちません。入口は ServiceNow IDE（sn_glider_app/ide.do）と ServiceNow Studio 側にあります。
次に読むなら
[ServiceNow のアプリとスコープを実機で確認する：Global と Scoped、sys_app / sys_scope / sys_metadata の関係] … Build Agent (Trial) のような Store アプリが「スコープ＋sys_metadata の集合」である仕組みを、基礎から確認しています。
[ServiceNow の REST 連携を実機で読み解く：Scripted REST API（sys_ws_definition / sys_ws_operation）の構造] … Build Agent API と同じ仕組み（Scripted REST API）の定義とオペレーションの読み方です。
プラグイン（v_plugin/sys_plugins）の有効・無効と依存 … 今回 ide_platform や now_assist_core の状態確認に使った v_plugin の見方です。
用語
Build Agent：会話形式でアプリ・メタデータを作成/編集するエージェント型開発機能
Now Assist for Creator：開発者向け Now Assist のライセンス体系。正式版 Build Agent の前提
ServiceNow IDE：sn_glider_app/ide.do で開く Web ベースの開発環境（VS Code for the Web ベース）
Fluent：TypeScript 仕様ベースの DSL。コンパイルするとインスタンスのメタデータになる
フリーミアム：無料枠つきの提供形態。Trial アプリはプロンプト数の上限つき
PDI：Personal Developer Instance（無料の検証用インスタンス）
自分の環境で確認するときのURL
先頭に自分のインスタンスのホスト名を付けると、同じ画面を自分の環境でも開けます。
アプリ実体 : sys_scope_list.do?sysparm_query=scope=sn_try_build_agent
構成ファイル : sys_metadata_list.do?sysparm_query=sys_scope.scope=sn_try_build_agent
テーブル定義 : sys_db_object_list.do?sysparm_query=nameSTARTSWITHsn_try_build_agent
会話一覧 : sn_try_build_agent_conversation_list.do
知識源一覧 : sn_try_build_agent_knowledge_source_list.do?sysparm_query=ORDERBYplugin
プロパティ : sys_properties_list.do?sysparm_query=nameSTARTSWITHsn_try_build_agent
REST API : sys_ws_operation_list.do?sysparm_query=sys_scope.scope=sn_try_build_agent
プラグイン : v_plugin_list.do?sysparm_query=idINcom.glide.ide_platform,com.now_assist_core
ServiceNow IDE : sn_glider_app/ide.do検証範囲とおことわり
確認した範囲：sys_scope に見える Build Agent (Trial) の実体（v1.3.17・sys_store_app）、スコープ内メタデータ 259 件の内訳、6 テーブルのフィールド定義と選択肢、読み取れた 3 テーブルの件数（conversation 0 ／ message 0 ／ knowledge_source 34）、システムプロパティ 6 件の値、Script Include・Business Rule・REST オペレーションの一覧、ACL の admin_overrides、関連プラグインの active 状態。すべて PDI（Zurich / 2026-07-04 確認）で取得しています。
確認していない範囲（断定しません）：Build Agent を実際に動かしたときの会話・テレメトリ・利用ログの中身、Script Include や Business Rule の script 本体、プロンプト上限が実際に効く値と単位（プロパティの 25/10 と docs の 100/25 の関係）、conversation.application_id の格納内容、生成されるアプリの品質、Now Assist for Creator ライセンスが有効な環境での挙動差。
docs の記載（プロンプト上限・ライセンス要件など）は 2026-07-04 参照時点のものです。リリースノートは最新ファミリー版の内容が表示されるため、Zurich 時点の仕様と異なる可能性があります。
今回は PDI に入っていた Trial アプリの構成をテーブル側から確認しました。Trial アプリは更新が速いので、試すときは自分の環境の sys_scope でバージョンを、sys_properties で制限値を確かめてから使うのが安全です。
