ServiceNowの検索は2階層：エンジン（Zing / AI Search）と、その上に乗る機能
検索シリーズの最終回です。ここまで、①AI Search、②Zing、③Now Assist in Search、④Contextual Search を1本ずつ実機で見てきました。今回は、その4つを1枚の地図にまとめます。似た名前が並んで混乱しやすい領域ですが、「エンジンなのか、その上に乗る機能なのか」で整理すると、4つの関係は2階層に収まります。
結論を先に置きます。Zing と AI Search は検索エンジン（実際に索引を引く本体）。Now Assist と Contextual Search は、そのエンジンの上に乗る機能です。この2段階の構造が、今回いちばん持ち帰ってほしい見取り図になります。
シリーズ各記事（機能別の詳細）
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測に基づきます。件数・状態・プロパティ値はすべて REST で取得しました（確認日 2026-07-12）。本番環境やライセンス済み環境では状態が異なります。
4つを1枚で：比較表
まずは全体像を表で。細かい根拠は各回の記事にありますが、この1枚で違いの骨格はつかめます。
ポイントは2列目「レイヤー」です。Zing と AI Search は「エンジン」、Now Assist と Contextual Search は「エンジンの上の機能」。役割の階層が違うものを、同じ土俵で「どれが優れているか」と比べても意味がありません。まずこの区別が出発点です。
もう1つ目を引くのが「この環境の状態」の列です。4機能のうち、実際に動いていると言い切れるのは Zing だけでした。AI Search は設定のみ、Now Assist は器のみ、Contextual Search は Zing の上で設定済み。同じ OOTB の環境に、これだけ「起動状態の異なるもの」が同居しています。カタログ上は4つとも「使える機能」に見えますが、実機で確かめると温度差がはっきり出る、という点は、導入を検討する立場なら覚えておいて損はありません。
2段階の構成：エンジン層と、その上の機能
言葉より図が早いので、関係を1枚にします。
下の層に検索エンジンが2つ。従来の Zing と、次世代の AI Search です。どちらか一方が「実際に索引を引く本体」として働きます。その上の層に、エンジンを利用する機能が乗ります。Now Assist in Search は、エンジンが取ってきた記事を LLM に渡して「答え」を生成する機能。Contextual Search は、フォーム入力の文脈でエンジンを呼び出し、候補を横に出す機能です。
この見方の利点は、トラブルの切り分けが速くなることです。「検索が変だ」というとき、原因がエンジン層なのか、上の機能層なのかを分けて考えられます。たとえば「フォームに候補が出ない」なら上の層（Contextual Search の設定）、「候補は出るが的外れ」なら下の層（エンジンの索引や関連度）、と当たりをつけられます。
もう1つの利点は、機能を評価するときのブレが減ることです。「Now Assist を入れたのに答えが出ない」という相談は珍しくありません。2段階で考えれば、Now Assist（上の機能）は AI Search（下のエンジン）が動いていることが前提だ、とすぐ分かります。上の機能だけを見て「壊れている」と判断する前に、下の土台を確認する。この順番を持てるだけで、無用な回り道が減ります。逆に、エンジンを新しくしても、上の機能の設定（どのフォームで、何を、何件出すか）は引き継がれる、という安心材料にもなります。層を分けて考えるとは、責任の所在を分けて考えることでもあるわけです。
エンジンはどちらが動くのか：この環境の実測
エンジンが2つあるなら、実際に働いているのはどちらか。ここはプロパティで明確になります。
この PDI での実測はこうでした。
glide.ais.enabled = false（AI Search エンジンは未起動）
glide.ais.initialized = false（未初期化）
glide.ais.disabled.message = 「AI Search is not enabled」
glide.ts.query_mode = rdbms（Zing が rdbms モードで実行）
答えは Zing です。AI Search は設定こそ一式そろっているものの、エンジン本体は起動しておらず、実際に検索を返しているのは前身の Zing でした。②の記事では、Zing の索引が State=Ready で語数まで積み上がっているのに対し、①の AI Search では索引統計が0件、という対比も確認しています。「新しいものが入っている」ことと「いま動いている」ことは別だ、という教訓が、この4件のプロパティに凝縮されています。
エンジンの中身の違い：重み と 学習
同じ「エンジン」でも、Zing と AI Search は関連度の決め方が根本から違います。ここを押さえると、なぜ ServiceNow が新エンジンに移ろうとしているのかが腑に落ちます。
Zing は重み（weight）で関連度を決めます。②で見たとおり、フィールドごとに重要度の数値を振り、その通りに結果を並べます。タイトルは重く、添付本文は軽く（実測で 0.1）。挙動が読みやすく、調整の因果関係がはっきりしているのが長所です。反面、利用者がどの結果をよく開くか、といった行動は反映されません。改善は人の手作業になります。
AI Search は機械学習（ML）で関連度を決めます。①で見たとおり、既定の関連度モデルを持ち、利用者のクリックから並び順を学び直します。うまく回れば、手をかけずに精度が上がっていく。ただし学習にはデータが要ります。この環境では学習の実行実績が0件でした。データが溜まる前は、既定モデルの実力勝負になります。さらに AI Search は、語の意味を捉えるセマンティック（ベクトル）検索や、6言語の言語別処理も持ちます。Zing が「文字の一致」を軸にするのに対し、AI Search は「意味の近さ」まで踏み込む、という差です。
どちらが上、という単純な話ではありません。挙動を完全に制御したいなら重みの Zing、運用しながら育てたいなら学習の AI Search。多くの環境は、この2つの間で移行の途中にいます。
生成AI（Now Assist）は、どこに乗るのか
Now Assist in Search は、単独の検索エンジンではありません。③で見たとおり、RAG（検索拡張生成）という方式で、まずエンジンで関連記事を取得し、その内容を LLM に渡して答えを作ります。つまり土台に AI Search が要ります。
この PDI では、その土台（AI Search）が起動していません。加えて、生成スキルが0件、プロバイダ・マッピングも0件、実行ログも0件でした。capability（機能定義）は15件そろっていましたが、「器はあるが生成は動かない」状態です。Now Assist を評価するときは、capability の一覧を見て安心せず、土台のエンジンと LLM 接続、ライセンスまで下りて確認する必要がある、というのが実機からの結論でした。
順番で言えば、RAG は下から積み上がります。検索基盤がなければ関連記事を取れず、記事がなければ LLM に渡す材料がなく、材料がなければ答えは作れません。だから Now Assist の導入可否を判断するときは、いちばん派手な生成の部分よりも、いちばん地味な検索基盤の起動状態を先に見るのが近道です。この4機能の中で Now Assist だけが、他の3つ（エンジン2つ＋Contextual Search）が整った先にある、いわば最上段の機能だと捉えると位置づけがはっきりします。生成AIは魔法ではなく、検索という土台の上に積まれた1つの層にすぎない、というのが5本を通した実感でした。
文脈レイヤー（Contextual Search）は、エンジンを呼ぶ
Contextual Search も、それ自体はエンジンではありません。④で見たとおり、フォーム入力の文脈で、裏のエンジンを呼び出す層です。この PDI では、その裏で実際に検索するのは Zing になります。
だから Contextual Search の設定（cxs_table_config など）が正しくても、土台の索引が弱ければ候補の質は上がりません。逆に、エンジンが良くても対象テーブルが有効化されていなければ、フォームには何も出ません。設定とエンジンの両輪で「入力中に似た答えが出る」体験が成り立ちます。
ここで、4機能の関係が一段はっきりします。Contextual Search と Now Assist は、どちらも「エンジンの上の機能」でした。ただし乗り方が違います。Contextual Search は、エンジンが返した結果をフォームの文脈に差し込む層。Now Assist は、エンジンが返した結果をLLM に渡して要約・生成する層。同じ「上の機能」でも、片方は見せ方の工夫、もう片方は答えの作り込み、と役割が分かれています。そして両方とも、下のエンジンが動いていることが大前提です。この環境では、Contextual Search は実働中の Zing に乗れているので設定どおり動きうる一方、Now Assist は未起動の AI Search を前提にするため動けない。同じ「上の機能」でも、乗っている土台の状態しだいで、動くか動かないかが変わるわけです。
面白いのは、Zing と AI Search をつなぐ移行の仕組みまで用意されていたことです。zing_to_ais_configuration には、Zing の検索コンテキストと AI Search のコンテキストを対応づける移行マッピングが active で並んでいました（Next Experience Global Search、Global Search、Service Operations Workspace Search、Knowledge Center Global Search）。一覧の列を見ると、「AI Search Configuration」と「Zing Configuration」が横に並び、どの検索の見た目（アーティファクト）を、どちらのエンジンの設定に向けるかが1行ずつ対応づけられています。たとえば Global Search は、Zing 側の「Now Experience Search Configuration」から AI Search 側の「[AIS] Next Experience Search Configuration」へ、という具合です。準備は整っているが、まだエンジンのスイッチを入れていない。多くの環境がいる「移行の途中」を、この環境も体現していました。
名前が紛らわしいのは、なぜか
この領域が分かりにくいのは、機能どうしが重なり合い、名前を共有しているからです。いくつか実測で見えた重なりを挙げます。
「NLQ（自然言語クエリ）」は、AI Search の Genius Results にも、Now Assist の capability にも出てきました。実体は、AI Search の設定に置かれた Script Include（AISearchNLQUtils）で、自然言語をクエリに変換する部品です。同じ部品が、検索カードとしても、生成の前段としても使われます。
「Agent Assist」は、④で見たとおり Contextual Search の設定（cxs_table_config）の上に成り立っていました。作業中のサイドパネルに類似インシデントやナレッジを出す機能ですが、裏側は Contextual Search です。「Genius Results」は AI Search の回答カード、「Now Assist Panel」は生成AIのパネル。名前は別々でも、たどると同じテーブルや部品に行き着きます。
だから、名前を1つずつ暗記しようとすると混乱します。おすすめは、まず「エンジンか、その上の機能か」の2段階に置いてみること。次に「どのテーブルに設定があるか」で実体を確かめること。名前ではなく構造とテーブルで捉えると、新しい機能名が出てきても、どの層の話かを見抜けます。
どれを、いつ見るのか
役割で整理すると、確認する順番も決まってきます。
全社的な検索の土台を知りたい → まずエンジン（glide.ais.enabled と glide.ts.query_mode）。どちらが動いているかを最初に確定する
検索結果が的外れ → エンジン層。Zing なら索引の State と重み、AI Search なら検索ソースと関連度
フォームで候補が出ない／類似が出ない → Contextual Search（cxs_table_config）。対象テーブルと UI が有効か
生成AIの「答え」を使いたい → Now Assist。ただし AI Search 起動・LLM 接続・ライセンスが前提
シリーズ5本を振り返る
最後に、各回で実機から分かったことを1行ずつ振り返ります。詳しくは各記事にありますが、通して読むと1つの物語になります。
① AI Search（ais_*）… プロファイル15・ソース43・索引定義27・Genius 4・辞書17と、設計は一式そろっていた。だが索引統計は0件で、エンジンは glide.ais.enabled=false の未起動。設計図としては完全に読めるが、検索実行は検証範囲外だった
② Zing（ts_*）… 索引定義38がすべて State=Ready、語数も実数で積み上がっていた。glide.ts.query_mode=rdbms で、この環境の実働エンジンは Zing。同義語29やスペル補正は用意されているが無効化されていた
③ Now Assist in Search（sys_one_extend_*）… capability 15・NLQ/Q&A の Genius・Now LLM/Azure の定義と、器はそろっていた。だが土台の AI Search が未起動、生成スキル0・実行ログ0で、生成の稼働は確認できなかった
④ Contextual Search（cxs_*）… テーブル構成15・コンテキスト16・サーチャー9で、フォーム入力中に候補を出す設定が incident からメール下書きまで並んでいた。裏で実際に検索するのは Zing だった
関連記事
ServiceNow AI Searchはどう組み立てられている？ プロファイル・ソース・インデックスを実機で追う — この記事で「エンジン層」とまとめたAI Searchの内部構成を、プロファイル・ソース・インデックスまで分解して確認した記事です
こうして並べると、共通する教訓が浮かびます。「設定がそろっている」ことは「動いている」ことを意味しない。どの機能も、定義の一覧は立派でした。けれど実際に動くかは、エンジンの起動フラグ、索引の State、スキルや実行ログの件数まで下りて、はじめて分かります。この確認の癖こそ、5本で伝えたかった実務のコアです。
まとめ
ServiceNow の検索は、エンジン（Zing / AI Search）と、その上に乗る機能（Now Assist / Contextual Search）の2段階の構成でした。この環境の実測では、動いているエンジンは Zing、AI Search は設定のみ、Now Assist は器のみ、Contextual Search は Zing の上で設定済み、という状態です。
似た名前に惑わされず、「これはエンジンか、その上の機能か」「いま動いているのはどれか」を分けて見る。この2つの問いを持つだけで、検索まわりの調査は一気に速くなります。5本を通して伝えたかったのは、機能の名前より、この構造の見取り図でした。
もしあなたが自社の ServiceNow を触れる立場なら、この記事の後にぜひやってほしいことが1つあります。sys_properties で glide.ais.enabled と glide.ts.query_mode を開いてみることです。その2つの値だけで、あなたの環境が「まだ Zing なのか」「AI Search に移ったのか」が分かります。そこを起点に、ais_* や ts_*、cxs_* のテーブルへ降りていけば、この5本の地図がそのまま自分の環境の診断に使えるはずです。名前を覚えるより、この確認の一歩を踏み出すことのほうが、ずっと役に立ちます。
その他、実機で確認した記録
用語
検索エンジン … 実際に索引を引く本体。Zing（従来）と AI Search（次世代）
Zing … rdbms モードのテキスト検索。この環境の実働エンジン
AI Search … ML 関連度の次世代エンジン。この環境は設定のみ・未起動
Now Assist in Search … エンジンの上で答えを生成する RAG 機能
Contextual Search … フォーム入力の文脈でエンジンを呼ぶ機能
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/sys_properties_list.do?sysparm_query=name=glide.ais.enabled（どちらのエンジンか）
/ts_index_name_list.do（Zing 索引）／/ais_datasource_list.do（AI Search 索引定義）
/sys_one_extend_capability_list.do（Now Assist capability）
/cxs_table_config_list.do（Contextual Search 対象）
/zing_to_ais_configuration_list.do（移行マッピング）
実測の要点（再掲）
実働エンジン = Zing（glide.ts.query_mode=rdbms / glide.ais.enabled=false）
AI Search = 設定のみ（プロファイル15・ソース43・索引定義27、索引統計0）
Now Assist = 器のみ（capability 15、生成スキル0・実行ログ0）
Contextual Search = Zing の上で設定済み（table_config 15・context 16・searcher 9）
検証範囲とおことわり
この記事は①〜④の実測を統合したものです。件数・状態・プロパティ値は PDI（Zurich / OOTB）の REST 実測に基づきます。
AI Search の検索実行・関連度学習、Now Assist の生成、Contextual Search の入力時の実挙動は、いずれもこの環境では動かず未確認（検証範囲外）です。
プラグインの active 状態は REST（HTTP 403）で取得できず検証範囲外です。ライセンスが生成を許可する意味かも実測で裏が取れません。
本番やライセンス済み環境では、動作・設定・有効状態が異なります。
