Now Assist in Search が動かないのは AI Search が止まっているから（glide.ais.enabled）
このシリーズの3本目です。①で AI Search の設計図、②で実際に有効化されている Zing を見ました。今回は、生成AIを使う検索、Now Assist in Search を扱います。
先に正直に書いておきます。この記事は「生成AIが答えを返す様子」をお見せするものではありません。なぜなら、今回の環境（PDI）では生成そのものが動かない状態だったからです。ではなぜ記事にするのか。動かない環境でも、どんな部品（設定・定義）が用意されているかは、テーブルからはっきり読めるからです。生成AI検索の骨格を、器の側から確かめます。
このシリーズのまとめとして、4つの検索機能（AI Search / Zing / Now Assist / Contextual Search）の全体像と比較を1本の記事にしました。
ServiceNowの検索は2階層：エンジン（Zing / AI Search）と、その上に乗る機能
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・状態・プロパティ値はすべて REST で取得しました（確認日 2026-07-12）。本番環境やライセンス済み環境では、動作も設定も異なります。
前提の確認：PDIでは機能はあるものの生成することはできない
この記事ではPDIで調査ができたものを中心に記載します。実測でこう分かれました。
在るもの（設定・定義）
OneExtend capability … 15件、すべて active。その中に「NLQ for AI Search」「Recursive Summarization（再帰要約）」など検索・要約向けの機能定義
Genius Results の NLQ・Q&A … active
要約の LLM 定義 … Now LLM と Azure Open AI の2系統
無い・OFF なもの（稼働の土台）
AI Search 基盤 … glide.ais.enabled = false（Now Assist in Search が使う検索エンジンが未起動）
生成スキル … sys_gen_ai_skill = 0件
プロバイダ・マッピング … sys_generative_ai_capability_definition = 0件
実行・利用ログ … sys_cs_one_extend_invocation = 0件 / sys_one_extend_usage = 0件
確認できなかったもの（検証範囲外）
プラグインの有効状態 … sys_plugins と sys_store_app は REST で HTTP 403（アクセス拒否）になりました。Now Assist 系プラグインが active かどうかは取得できません
ライセンスの意味 … sn_entitlement_genai_assist_analytics が 70件ありましたが、これが「生成を実際に呼べる」ことを意味するかは実測で裏が取れません
つまり、部品は揃っているが、火を入れる前の状態です。以降は capability・capability 定義・Genius・有効化プロパティ・LLM 定義の順に中身を並べます。
Now Assist in Search とは：RAG という仕組み
まず、動いたときに何が起きるのかを、公式ドキュメントの説明で押さえます。Now Assist in Search は RAG（Retrieval-Augmented Generation、検索拡張生成） という方式です。
利用者が質問を打つと、まず AI Search が裏で関連するナレッジ記事を取ってきます（Retrieval）。次に、その上位記事の内容を材料にして質問を膨らませ（Augmented）、それを LLM に渡します。最後に LLM が、社内の確かな情報にもとづいた文章の答えを作ります（Generation）。「リンクの一覧」ではなく「答えそのもの」を返すのが狙いです。
もう1つの柱がセマンティック検索です。従来の Zing は、打った単語がそのまま含まれる記事を探しました。セマンティック検索は、語の意味や意図を汲みます。「PCが立ち上がらない」と打っても、「起動しない」「電源が入らない」と書かれた記事を拾える、という考え方です。
具体例で考えてみましょう。利用者が「VPNにつながらない」と打ったとします。従来の検索なら、「VPN」「つながらない」という語を含む記事を並べるだけ。RAG は違う動きをします。まず AI Search が VPN 接続に関する上位のナレッジ記事を数本取得し、その本文を LLM に渡して「この記事群を踏まえ、質問に短く答えて」と指示する。返ってくるのは記事のリンク一覧ではありません。「まず社内VPNクライアントを再起動し、それでも駄目なら…」といった、要約された手順そのものです。答えの根拠として参照した記事も一緒に示されるので、生成AIにありがちな「もっともらしい嘘」も見抜きやすくなります。
大事な前提が1つ。Now Assist in Search は単体では入りません。公式ドキュメントによれば、Now Assist for HRSD / ITSM / CSM のいずれかの一部（依存アプリ）として導入する形になっています。検索機能だけを切り出して買う、という入れ方ではない、という点は設計を理解するうえで押さえておきたいところです。
全体像：質問から答えまで
RAG の流れと、それを支える部品を1枚にします。
土台は AI Search（②で見た検索基盤）。その上に OneExtend という枠組みが乗り、capability（機能定義）が「NLQ で質問を解釈する」「記事を要約する」といった役割を持ちます。生成の本体は LLM で、Now LLM か Azure Open AI に接続します。この鎖のどこか1つでも欠けると、答えは出ません。今回の環境は、いちばん下の AI Search がまだ起動していない、という状態でした。
OneExtend capability：15個の機能定義
Now Assist の機能は「OneExtend」という枠組みの上に、capability（ケイパビリティ＝機能定義）として並びます。実測は15件、すべて active。
検索・要約に関係するものを拾うと、次のとおり。
NLQ for AI Search … 自然言語やキーワードの質問を解釈する。説明にも「Parses a natural language or keyword query」とあります
Recursive Summarization … 長い文章を段階的に要約する
Natural Language Query Parser … 自然言語の発話を構文解析する
ServiceNow RAG (Deprecated) … RAG の旧定義（名称に Deprecated ＝非推奨の表示）
ほかにも Classification（分類）、Dynamic Translation（動的翻訳）などがあります。Form Autocomplete（フォーム入力補助）、Image Analysis（画像解析）も同様です。検索以外の Now Assist 機能も、同じ枠に同居しています。検索はこの大きな枠の一部、という位置づけです。
なぜ「OneExtend」という共通の枠にまとめてあるのか。理由は、生成AIを使う機能が、どれも似た土台を必要とするからです。質問や文章を LLM に渡し、結果を受け取り、タイムアウトやエラーを扱い、どのプロバイダに繋ぐかを選ぶ。この共通部分を1か所に集めておけば、要約でも翻訳でも分類でも、同じ仕組みを使い回せる。検索の NLQ もその1つとして、この枠に乗っています。逆に言えば、OneExtend の設定を一度つかんでおくと、Now Assist のほかの機能を調べるときにも同じ地図が使えます。
capability の実体は「スクリプトかサブフローの呼び出し」
capability の中身（定義）は sys_one_extend_capability_definition にあります。ここを開くと、抽象的に見えた「機能」が、具体的な処理の呼び出しだと分かります。
実測での要点です。「NLQ for AI Search」の定義は、api_type が Script Include、接続先が AISearchNLQUtils というスクリプトでした。要約系の定義は api_type が Flow Designer Subflow。つまり capability とは、その裏でどのスクリプトやサブフローを呼ぶかを束ねた設定です。魔法の類ではありません。追える処理の集合になっています。要約定義には「Now LLM」版と「Azure Open AI」版が別々に用意されています。Azure 版には Filter Properties に {"azure_openai":"true"} という目印が付いていました。どのプロバイダ向けの定義かを、こうしたフラグで切り替える作りです。「AI Search Definition」の定義は AISearchDefinitionUtil です。NLQ の解釈は「検索クエリをテーブルと項目に分解する」と説明されていて、生成の前段でクエリを構造化していることが読み取れます。
Genius の NLQ と Q&A
①の AI Search で見た Genius Results（結果の上に出す回答カード）にも、生成AIに寄った定義がありました。
実測4件のうち、NLQ と Q&A は active・トリガは Always。NLQ は自然言語をクエリに変換し、Q&A は長い記事から回答部分を抜き出します。ただし、これらが実際に働くには土台の AI Search が動いている必要があります。次に見るとおり、そこが止まっていました。
この環境では、なぜ生成が動かないのか
ここが今回いちばん確かめたかった点です。プロパティを見れば一目でした。
glide.ais.enabled = false（AI Search を有効化するプロパティ。説明は「Property to enable AIS.」）
glide.ais.disabled.message = 「AI Search is not enabled」（無効時に出すメッセージが、しっかり設定されている）
glide.service_portal.ais_nlq_enabled = false（ポータル検索での自然言語クエリも無効）
Now Assist in Search は AI Search を土台にします。その土台が false である以上、RAG の最初の一歩（関連記事の取得）が始まりません。さらに、生成の担い手であるスキルも空でした。
Generative AI Skills の一覧は「No records to display（表示するレコードがありません）」。生成スキルが0件です。プロバイダ・マッピングも0件、実行ログも0件。器は組み上がっているのに、動かすための最後の部品と接続が入っていない、という状態が、これらの画面から読み取れます。
セマンティック検索とハイブリッド検索の設定
生成は動かないものの、それを支える設定は読めました。プロパティにこうあります。
com.glide.genai.semantic_filter.enabled = true（セマンティックフィルタは有効化の設定）
glide.ais.query.hybrid_allowed_tables = kb_knowledge, sc_cat_item, sys_gen_ai_skill
glide.ais.query.allow_hybrid_search_for_external_content = true
「ハイブリッド検索」は、従来のキーワード一致と、意味を汲むベクトル検索を組み合わせる方式です。ベクトル検索とは、文章を「意味の座標」に変換して、近い意味のものを距離で探す考え方を指します。「起動しない」と「電源が入らない」は、字面は違っても座標が近い、というイメージです。キーワード一致だけでは取りこぼす言い換えを、この座標の近さで拾います。両者を混ぜるのがハイブリッドの狙いです。
許可テーブルに sys_gen_ai_skill（生成スキル）が含まれているのも目を引きます。生成スキルそのものを検索対象に組み込む設計思想が、設定の側から見えます。ただし、そのスキルは今 0件なので、実際には何も混ざりません。器の広さと、中身の空っぽさが、同じ画面に同居している状態でした。
LLM は何につなぐのか
生成の本体である LLM の接続先も、定義から読み取れました。要約 capability には Now LLM（ServiceNow 自前の LLM）と Azure Open AI の2系統があります。サポートモデルのプロパティには llm_generic_large llm_generic_small といった汎用モデル名が並んでいました。com.glide.one_extend.default_provider_sync は true、enforce_timeout_for_llm も true。LLM 呼び出しにタイムアウトをかける、といった運用上の配慮まで設定として存在します。接続そのものを有効化するには、別途プロバイダの登録とライセンスが要ります。そこは今回の環境では確認できませんでした。
何が揃えば動くのか
ここまでを整理すると、Now Assist in Search を動かすには、少なくとも次がそろう必要がある、と読めます（当環境で欠けていた順）。
AI Search 基盤の起動（glide.ais.enabled を true にし、インデックスを生成する）
生成スキルとプロバイダの登録（sys_gen_ai_skill とプロバイダ・マッピング）
LLM への接続とライセンス（Now LLM または Azure Open AI）
依存アプリとしての導入（Now Assist for ITSM / HRSD / CSM の一部として）
裏を返せば、capability や Genius の定義が並んでいるだけでは動きません。この記事で見た「器」と、実際の「稼働」は別物だ、というのが実機からの結論です。
この順番には理由があります。RAG は下から積み上がる仕組みだからです。検索基盤がなければ関連記事を取れず、記事を取れなければ LLM に渡す材料がなく、材料がなければ答えは作れません。だから最初に確認すべきは、いちばん派手な生成の部分よりも、いちばん地味な検索基盤の起動状態です。実機を触るときは、上から順に「capability はあるか」と辿るより、下から順に「AI Search は動いているか」を見るほうが、遠回りに見えて近道になります。この見立てさえ持っておけば、生成AI検索の導入状況を、テーブル数枚で診断できるようになります。
ライセンスと実行ログ：使われた形跡はあるか
「本当に動いていないのか」を、別の角度からも確かめました。実行の痕跡です。Now Assist が一度でも呼ばれていれば、実行ログにレコードが残ります。実測では、Virtual Agent 経由の実行を記録する sys_cs_one_extend_invocation が0件でした。利用状況を記録する sys_one_extend_usage も0件です。つまり、この環境で Now Assist の生成が呼ばれた形跡はありません。
ライセンス側も見ました。sn_entitlement_genai_assist_analytics というテーブルには70件のレコードがあります。数字だけ見ると「何か有効になっている」ように読めます。しかし、これがライセンス上「生成を実際に呼べる」ことを意味するのかは、今回の実測では確かめられませんでした。エンタイトルメントのメタ定義やカタログである可能性もあり、断定できないためです。一方で、作成者ユーザー数を示す sn_entitlement_genai_creator_users は0件でした。実行ログ0件と合わせると、少なくとも「積極的に動いている証拠」は見当たらない、というのが正直なところです。
ここは推測で埋めたくない部分です。「70件あるから使える」と書くのは簡単ですが、裏が取れていないことを断定するのは、この連載の趣旨に反します。分かったことと分からなかったことを、そのまま分けて記録します。
確認導線
実機で開くときの入口です（URL形式は list.do 規約に基づきます。実クリック確認は今回の範囲外です）。
OneExtend capability … sys_one_extend_capability_list.do
capability 定義 … sys_one_extend_capability_definition_list.do
Genius Results（NLQ / Q&A）… ais_genius_result_configuration_list.do
生成スキル … sys_gen_ai_skill_list.do
有効化プロパティ … sys_properties_list.do?sysparm_query=nameLIKEglide.ais
まとめ
Now Assist in Search は、AI Search を土台に、OneExtend の capability と LLM を組み合わせて「答え」を生成する RAG の仕組みでした。今回の環境では、capability 15件・Genius の NLQ/Q&A・LLM 定義といった器はそろっていました。一方で、AI Search 基盤が OFF、生成スキルもプロバイダも実行ログも 0件で、生成の稼働は確認できませんでした。
「新しい生成AI機能が入っている」ことと「いま生成が動く」ことは、やはり別の話です。capability の一覧を見て安心するのではなく、glide.ais.enabled とスキルの件数まで下りて確認する。このシリーズの3本を通して繰り返し出てきた教訓が、ここでも当てはまりました。
次回は、フォーム入力を助ける Contextual Search を扱い、最後にこの4つの検索機能を1枚で比較します。
その他、実機で確認した記録
用語
Now Assist in Search … 生成AIで「答え」を返す検索。RAG 方式
RAG（検索拡張生成） … 関連記事を検索で取得し、その内容で質問を増強して LLM に渡す方式
OneExtend / capability … Now Assist 機能を載せる枠組みと、その機能定義。sys_one_extend_capability
セマンティック検索 … 語の一致でなく意味・意図で拾う検索
生成スキル（sys_gen_ai_skill） … 生成の実行単位。当環境は0件
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/sys_one_extend_capability_list.do（capability 15件）
/sys_one_extend_capability_definition_list.do（定義の実体）
/ais_genius_result_configuration_list.do（NLQ / Q&A）
/sys_gen_ai_skill_list.do（生成スキル・0件）
/sys_properties_list.do?sysparm_query=nameLIKEglide.ais（有効化の確認）
実測の要点（再掲）
capability 15（全active）／capability 定義 15／Genius NLQ・Q&A active
glide.ais.enabled=false／生成スキル0／プロバイダ0／実行ログ0＝生成の稼働は未確認
プラグイン active 状態は HTTP 403 で取得不可（検証範囲外）
関連記事
ServiceNow AI Searchはどう組み立てられている？ プロファイル・ソース・インデックスを実機で追う — Now Assistが答えを生成する前提であるAI Search本体の構成を、プロファイル・ソース・インデックスから確認した記事です
検証範囲とおことわり
この記事の件数・状態・プロパティ値・定義の実体は、PDI（Zurich / OOTB）の REST 実測です。
生成の実挙動（RAG の回答生成・セマンティック検索の結果）は、AI Search が OFF・生成スキル 0件・実行ログ 0件のため、当環境では動かず未確認（検証範囲外）です。
プラグイン（Now Assist / Generative AI Controller）の active 状態は取得できませんでした。sys_plugins / sys_store_app が HTTP 403 を返すためです（検証範囲外）。
sn_entitlement_genai_assist_analytics=70 がライセンス的に生成を許可する意味かは、実測で裏が取れません（検証範囲外）。
本番やライセンス済み環境では、動作・設定・有効状態が異なります。
