ServiceNowのAI Searchで検索ソースとインデックスの数が合わないのはなぜ？ 役割の違いを実機で確認
ServiceNowのAI Search設定画面を開くと、検索ソースの一覧とインデックス定義（Indexed Source）の一覧で件数が違います。同じ検索の設定のはずなのに数が合わないため、どちらを直せばよいのか迷う担当者は少なくありません。結論は、検索ソースが画面側の論理定義、インデックス定義が実インデックス側の物理定義という役割の違いにあります。1つのインデックス定義を複数の検索ソースが条件を変えて使い回すため、数は一致しません。Zurich PDIで実際のつながりを1件ずつ確認しました。
AI Searchの全体像（3階層の構成・関連テーブルの数・エンジンの起動状態）は、別記事にまとめました。位置づけを先につかみたい方はServiceNow AI Searchはどう組み立てられている？ プロファイル・ソース・インデックスを実機で追うをご覧ください。この記事では、そのうち「検索ソースとインデックス定義の数がなぜ合わないのか」だけを掘り下げます。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：検索ソースとインデックス定義は役割が違う
先に全体像です。
検索ソース（ais_search_source）は、検索画面から見た「何を検索対象にするか」を決める論理定義です。実測すると43件でした。
インデックス定義／Indexed Source（ais_datasource）は、実際に索引を張る物理定義です。実測すると27件でした。
43件のソースが参照しているインデックス定義は22種類にとどまり、残り5件はどのソースからも参照されていません。1つのインデックス定義を複数のソースが条件違いで使い回すため、数は一致しません。
この環境では検索エンジン本体（glide.ais.enabled）がまだ起動していません。設定の構造はすべて読めますが、検索を実行した挙動は検証範囲外です。
図の色は4種類の意味に固定しています。濃紺は起点の検索ソース、橙は参照が集中しているインデックス定義、水色はほぼ1対1で参照される通常のインデックス定義、灰色はどのソースからも参照されていないインデックス定義です。
Knowledge Table（kb_knowledge）を参照する検索ソースは11件、Catalog Item Table（sc_cat_item）を参照する検索ソースは7件でした。この2つだけで43件中18件を占めます。残り25件のソースは、20種類のインデックス定義に1〜3件ずつ分散して対応していました。
なぜ同じインデックスを複数のソースが使い回すのか
検索ソースの主なフィールドは、参照先のインデックス定義（datasource）と、絞り込み条件のconditionです。同じインデックス定義を参照しながら、conditionだけを変えたソースを複数作れる構造になっています。
たとえばKnowledge Tableを参照するソースには、「全ナレッジ記事」「ナレッジポータル向け記事」といった複数の名前が並びます。参照先のインデックス定義は同じKnowledge Tableでも、conditionにWorkflow=PublishedやActive=trueといった条件が入り、返す結果の範囲が変わります。
上の画面のIndexed Source列とConditions列に注目してください。「All Knowledge Articles」と「Articles」はどちらも同じKnowledge Tableを指しています。違うのはConditions列だけです。同じインデックスを条件違いで使い回す実例が、この1画面に出ています。
これは公式ドキュメントでもはっきり書かれた設計です。顧客向けポータルのナレッジと従業員向けポータルのナレッジは対象条件が別物なので、同じIndexed Sourceを土台に2つの検索ソースを作る、という例が挙げられています。インデックスを二重に持たず、条件だけを分けて見せ方を切り替える設計です。
参照されていないインデックス定義も一定数ある
インデックス定義27件のうち、検索ソースから一度も参照されていないものが5件ありました。
Activity Definitions（sys_pd_activity_definition）… active=false
Flow（sys_hub_flow）… active=false
Action（sys_hub_action_type_definition）… active=false
Location Table（cmn_location）… active=true
ACE Content Block Index（sn_ace_content_block）… active=true
前半3件はactive=falseなので、無効化されていて参照もされていないという分かりやすい状態です。一方でLocation TableとACE Content Block Indexはactive=trueのまま、どの検索ソースからも参照されていませんでした。インデックス定義を作ることと、検索ソースから使うことは別の作業だと分かります。
検索プロファイル：画面ごとの検索窓を束ねる入れ物
検索ソースの上位には、検索プロファイル（ais_search_profile）があります。実測15件、すべてactiveでした。対象はService Portal・Next Experience・SOW・Employee Center・Now Mobile・Knowledgeポータルなどです。画面ごとに1つずつ用意されており、検索窓がある画面の数だけプロファイルがある、と考えると腑に落ちます。
具体例を1つ挙げます。SOW（Service Operations Workspace）のプロファイル（service_operations_workspace_search_config）です。辞書のdata_sourceをたどると10テーブルを横断する構成でした。対象はincident・problem・problem_task・change_request・change_taskです。ほかにsc_task・sc_request・sc_cat_item・kb_knowledge・sys_userも含みます。ワークスペースで何を検索しても横断でヒットするのは、この設計の結果です。プロファイル自体が持つフィールドはnameとactiveくらいで、実体は検索ソースや辞書との紐付けに宿ります。
上部の注意書きに「このアイコンのプロファイルは未公開」とあります。State列を見るとDraft・New・Publishedが混在しています。レコードは存在するが、まだ公開（有効化）されていないものがあるという状態です。冒頭で触れた「エンジン未起動」が、画面の上でもこうして裏付けられます。
インデックス定義が対象にしているテーブルは何か
インデックス定義（ais_datasource）が指す対象テーブルは、業務テーブルがひととおり並びます。主な対象はincident・kb_knowledge・sc_cat_item・sys_user・change_requestです。ほかにproblem・sc_req_item・core_company・sys_user_group・cmn_locationも含みます。さらにダッシュボード（par_dashboard）やKPI（pa_indicators）、埋め込みヘルプ（sys_embedded_help_content）まで対象に含まれています。
全27件はtype=internalで、この環境に外部ソースはありません。逆にFlow（sys_hub_flow）とAction（sys_hub_action_type_definition）は定義こそあるものの、active=falseでした。標準では検索対象に含めていない、という判断が見えます。
この一覧を開くだけで、その環境の検索が「どのテーブルを見ているか」の全体像がつかめるはずです。上部には「未処理のIndexed Sourceがある」という注意書きも出ています。まだインデックスは作られていません。
インデックス対象フィールド：どの項目を検索対象にするか
インデックス定義が「どのテーブルを引くか」なら、ais_datasource_field_attribute（190件）は「そのテーブルのどの項目を検索対象にするか」を決めます。27のインデックス定義に対して190件なので、1定義あたり平均7項目ほどです。Incidentならshort_descriptionやdescription、Knowledgeならtextやkeywordsといった、検索して意味のある項目が選ばれます。
補助的な設定としてais_configuration_attribute（12件）も存在します。検索の当たり方を細かく調整する土台が、テーブルの形で全部見える状態でした。全文検索の設定は、テーブルに書き出されたレコードの集合として組み立てられています。
Genius Results：結果の上に出る回答カード
普通の検索は一覧を返します。Genius Resultsは、その上に直接の答えをカードで出す仕組みです。ais_genius_result_configurationは実測4件。中身のスクリプトまで読むと、それぞれ性格が違いました。
Catalog Item（active=true / Always）… カタログ品目を最大3件、タイトル検索で回答。名前・価格・説明・アイコンを返す。標準変更のレコードプロデューサーは除外する
Q&A（active=true / Always）… 長いナレッジ記事の中から、質問に対する該当箇所のスニペットを抜き出す
NLQ（active=true / Always）… 自然言語クエリ。「先月オープンしたインシデントは？」のような文をクエリに変換する。LLM（OneExtend capability）を経由し、英語のみ・CMDB向けという制限つき
People（active=false / NLU）… 人物検索。NLU（自然言語理解）が人名・部署・役職・勤務地を推定してクエリを組む。ただし当環境ではactive=falseでした
公式ドキュメントではCatalog Item／People／Q&Aの3種が「設定不要のOOTB」とされています。当PDIではNLQを加えた4件が存在し、うち有効は3件でした。もし結果が出ないときはglide.ais.genius_result.enabledプロパティを確認する、といった実務の勘所も公式ドキュメントに記載されています。
辞書：表記ゆれと同義語を吸収する仕組み
検索精度を地味に支えるのが辞書です。ais_dictionaryは17件。種別の内訳は、スペルチェックが13件、同義語（シノニム）が3件、ストップワードが1件でした。
Language列がすべてEnglishなのも、この環境の素の状態を表しています。実際の語彙ais_dictionary_termは932件で、スペル訂正や同義語の実データがすでに投入されていました。公式FAQによれば、AI Searchは機械学習を使ってもなお同義語を自動推論しません。「incidentと障害は同じ意味」といった対応は、辞書に人が登録する必要があります。すべてをMLに任せられるわけではない、という設計上の勘所です。
Relevancy：プロファイルごとに学習するML関連度
関連度の学習はais_relevancy_solution_definition（5件）で定義されます。名前を見るとml_sn_global_global_ais_relevancy_<プロファイルのsys_id>という形で、末尾が検索プロファイルのIDと一致していました。プロファイルごとに1つのML関連度ソリューションを持てる設計です。
ただし当PDIでは学習の実行実績はゼロでした（ais_relevancy_autotrain_solution=0件）。枠は用意されているが、まだ回していない状態です。実運用では、利用者の検索とクリックが溜まってから学習が効き始めます。
結果改善ルール（ais_rule）も実測0件でした。これは意図した仕様です。検索結果を上げる・下げる・固定表示する・隠すためのルールは、OOTBでは空にしてあります。管理者が必要に応じて足す枠として用意されているためです。動作は3種類あり、boost（関連度を上げる）は並び順だけを動かし、promote（ピン留め）は特定の結果を先頭に固定し、blockはその結果を隠します。ルールはプロファイル単位で持つため、画面ごとに違う調整ができます。
検索エンジン全体を制御するプロパティ
エンジンの挙動を左右するプロパティも、いくつか読めました。
glide.ais.enabled = false（エンジン本体のスイッチ。当PDIでは未起動）
glide.search.max_search_results = 100（返す最大件数）
glide.ais.query.search_operator = AND_OR_ENHANCED（語の結合方法）
glide.ais.query.hybrid_allowed_tables = kb_knowledge, sc_cat_item, sys_gen_ai_skill（ハイブリッド検索を許すテーブル）
glide.ais.security.force_late_binding = false（ACLの評価方式）
hybrid_allowed_tablesにsys_gen_ai_skillが入っているあたりに、生成AIとの接続を見越した設計がうかがえます。移行系のテーブル（zing_to_ais_configurationなど）も配備されており、前身のZingからAI Searchへ切り替える枠組みはすでに用意されていました。Zing側の実測は別記事にまとめています。
プロファイルと構成のつながりをM2Mで見る
プロファイルと脇役たちをつなぐ多対多テーブルの実測です。
ais_search_profile_ais_search_source_m2m = 51件（プロファイル→検索ソース）
ais_search_profile_ais_dictionary_m2m = 39件（プロファイル→辞書）
ais_search_profile_ais_genius_result_configuration_m2m = 13件（プロファイル→Genius）
15個のプロファイルに対して、ソースの割り当てが51本です。1プロファイルあたり平均3〜4本のソースがぶら下がる計算になります。辞書は39本なので、多くのプロファイルが専用のスペルチェック辞書を持っていることになります。
検索結果とアクセス権をどう両立させるか
検索エンジンで見落としがちなのが、見えてはいけない結果が混ざらないかという点です。AI Searchはインデックスを事前に作る方式なので、ここは設計上の要点になります。実機にはais_acl_overridesというテーブルがあり、検索時のACL（アクセス制御）の扱いを上書きする枠が用意されていました。
関連するプロパティがglide.ais.security.force_late_bindingです。当PDIではfalseでした。late binding（遅延評価）を強制すると、検索のたびに1件ずつ権限を確かめるため正確さは上がりますが、速度は落ちます。falseはその強制をしない設定です。正確さと速度のどちらを取るかで決める設定だと考えられます。
実機で気づいたこと
43件のソースを22種類のインデックス定義が受け止めている図を最初に見たとき、残り16件分がどこかで消えているように感じました。実機で内訳まで数え直すと、そうではありませんでした。27件のうち5件は最初からどのソースからも参照されていないだけで、数が減っているわけではありません。
その5件の内訳を見ると、Flow・Action・Activity Definitionsの3件はactive=falseなので分かりやすい状態でした。一方でLocation TableとACE Content Block Indexの2件は、active=trueのまま参照ゼロでした。無効化されているから参照されないのではなく、有効なインデックス定義でも検索ソース側で使われていないケースがあります。この違いは実機で確かめて初めて分かりました。
Knowledge TableとCatalog Item Tableの2つだけで、43件中18件の検索ソースを引き受けています。同じインデックスを条件違いで何度も検索対象にする設計は、インデックスを重複して作らずに済む一方で、条件を1つ足すたびにソースのレコードが増えていく設計でもあります。検索結果を調整したいとき、新しいソースを作る前に既存のconditionを見直す方が早いケースは多いはずです。
実務では何に使えるか：検索結果を調べるときの見る順番
「特定のテーブルが検索結果に出ない、あるいは出過ぎる」という相談を受けたとき、自分は次の順で当たりを付けます。
まず検索ソース側を疑う。対象のテーブルを指すソースが複数あれば、そのうちどのconditionに引っかかっているかを確認する
ソース側で説明がつかないなら、参照先のインデックス定義を疑う。対象テーブルの指定やactiveの状態を確認する
それでも解決しないなら、インデックス対象フィールド（ais_datasource_field_attribute）まで下りて、検索対象になっている項目そのものを確認する
検索ソースとインデックス定義は役割が違うため、症状によってどちらを見るべきかが変わります。「出るはずの結果が出ない」ときは、conditionの絞り込みすぎが怪しいところです。「同じ結果が複数の見え方で出る」ときは、同じインデックス定義を参照する検索ソースが複数ある可能性を疑うと早く絞り込めます。
さらに詳しく知りたい人へ
ServiceNow AI Searchはどう組み立てられている？ プロファイル・ソース・インデックスを実機で追う — 検索プロファイル・検索ソース・インデックス定義の全体像をまとめた記事
ServiceNowの検索は2階層：エンジン（Zing / AI Search）と、その上に乗る機能 — AI SearchとZingという2つのエンジン、その上に乗る機能の位置づけを整理した記事
Now Assist in Search が動かないのは AI Search が止まっているから（glide.ais.enabled） — glide.ais.enabledが業務にどう影響するかの実例
まとめ
検索ソースとインデックス定義の数が合わないのは、役割が違うためでした。検索ソースは画面側の論理定義、インデックス定義は実インデックス側の物理定義です。43件のソースは22種類のインデックス定義に分かれて対応し、Knowledge TableとCatalog Item Tableの2つに参照が集中していました。残る27件中5件のインデックス定義は、どのソースからも参照されていません。
今回のPDIはエンジン未起動だったので、扱えたのは設定の構造までです。ですがこの構造が読めれば、検索結果を調整したいときにソース側とインデックス側のどちらを見るべきかを、自分の環境のais_*テーブルから判断できます。
用語
検索ソース（ais_search_source）… 検索画面から見た「何を検索対象にするか」の論理定義
インデックス定義／Indexed Source（ais_datasource）… 実際に索引を張る物理定義
検索プロファイル（ais_search_profile）… どの画面の検索かを束ねる設定コンテナ
Genius Results … 一覧の上に出す直接回答のカード。ais_genius_result_configuration
Relevancy … 関連度。AI Searchはクリック行動から機械学習で調整する
自分の環境で確認するときのURL
/ais_search_source_list.do（検索ソース一覧）
/ais_datasource_list.do（インデックス定義一覧）
/ais_search_source_list.do?sysparm_query=GROUPBYdatasource（検索ソースを参照先別に集計）
/ais_search_profile_list.do（検索プロファイル一覧）
/ais_genius_result_configuration_list.do（Genius Results一覧）
/ais_dictionary_list.do・/ais_dictionary_term_list.do（辞書と語彙）
/sys_properties_list.do（glide.ais.*を絞り込み）
参考リンク
検証範囲とおことわり
この記事の件数・状態・プロパティ値・辞書種別内訳は、PDI（Zurich / OOTB）の実測です。
エンジンが未起動のため、実インデックスの生成・検索クエリの実行・関連度の学習挙動・Geniusカードの実描画は未確認（検証範囲外）です。
プロファイルの用途分類（Service Portal／SOW／ESCなど）はnameからの推測（命名規約ベース）です。
本番やカスタマイズ済み環境では、数・設定・有効状態が異なります。
