ServiceNow AI Searchはどう組み立てられている？ プロファイル・ソース・インデックスを実機で追う
ServiceNowの管理画面には、Search Profile・Search Source・Indexed Sourceという3つの検索設定の一覧があります。件数はプロファイル15・ソース43・インデックス定義27とバラバラで、最初はどれが何を指すのか判断がつきません。43と27はM2Mでつながっていて、数が一致しないのには理由があります。Zurich PDIで実際のつながりと件数を確認しました。
検証環境：Zurich PDI / OOTB / 2026-08-08 確認
結論：3階層と、43件が27件と一致しない理由
先に全体像です。
AI Searchの検索設定は3階層です（下図）。検索プロファイル（15件）が検索ソース（43件）を束ね、検索ソースがインデックス定義（27件）を参照します。プロファイルとソースはM2Mで51件、プロファイルと辞書はM2Mで39件つながっています。
43件のソースが参照しているインデックス定義は22種類にとどまり、27件のうち5件はどのソースからも参照されていません。Knowledge Tableだけで11件のソースを、Catalog Item Tableは7件のソースを束ねています。
素のPDIでは glide.ais.enabled が false のままで、検索エンジンとしては動いていません。プロファイル・ソース・インデックスの定義そのものは最初から入っていますが、ais_rule や ais_connection など運用にかかわるテーブルは軒並み0件でした。
縦に伸びる1本道がプロファイル→ソース→インデックス定義の主系統で、辞書だけはソースを介さずプロファイルから直接M2Mで枝分かれしています。
3階層の件数とつながりは上の表のとおりです。プロファイルからソースへ、ソースからインデックスへと辿ると、15→43→27という順に数が変わっていきます。43から27への減り方は、単純な引き算では説明できません。この点が、この記事でいちばん伝えたいところです。
上の画面は検索ソースの一覧を、参照先のインデックス定義でグループ化したものです。Knowledge Tableの行だけで11件、Catalog Item Tableの行で7件のソースがまとまっているのが分かります。①グループの見出しがインデックス定義の名前、②括弧内の数字が参照しているソース数、③1つのインデックス定義を複数のソースが共有している様子が、この1画面から読み取れます。43件のソースは27種類のインデックス定義に均等に振り分けられるわけではありません。少数のインデックス定義に参照が集中する構造でした。
AI Searchは1機能ではなく51個のテーブル群でできている
ais_ で始まるテーブルは51個ありました。検索プロファイル・検索ソース・インデックス定義という3階層はその中心にすぎません。残りには、インデックスの取り込み履歴・クエリの統計・関連性の学習・保持ポリシーなど、検索という言葉から連想しにくい領域が並びます。AI Searchという名前から検索窓1個の機能を想像すると、実態とは異なる印象を持ちやすいところです。呼び名と規模は別物でした。実際には2種類のテーブルが同居しています。1つは検索対象を定義する設定系、もう1つは検索エンジンが動いた後に記録が積み上がる運用系です。設定系はプロファイル・ソース・インデックス・辞書の4種類、運用系はルール・接続・公開履歴・クエリ統計などの記録用テーブルでした。件数だけ見ると多く感じますが、この2分類で見ると迷いにくくなります。管理者権限でログインすると、左メニューの AI Search アプリケーションから Search Profiles・Search Sources・Indexed Sources の各一覧にたどり着けます。
検索プロファイル：どの検索窓かを決める15件（ais_search_profile）
ais_search_profile は、どの画面のどの検索窓かを表すテーブルです。15件、すべてactiveでした。
Service Portal向け・Next Experienceのグローバル検索向け・ヘルプパネル向け・コラボチャット向けというように、1レコードが1つの検索窓に対応します。同じ「検索」という言葉でも、画面によって検索対象や見せ方が違うのは、この単位でプロファイルが分かれているためです。15件がすべてactiveだったという事実も見逃せません。無効化ゼロは意外でした。用意された検索窓は現時点でどれも使われる前提になっていると分かります。
フォームを開くと、どの検索ソースを含めるか、どの辞書を使うかをひもづける項目が並びます。ここでの関連付けが、先に見たM2M件数（プロファイル×ソース51件、プロファイル×辞書39件）の実体です。特定の検索窓だけ結果を絞りたい、除外したいという要望は、このプロファイルの設定が担当になります。単純に割ると1プロファイルあたり平均3件前後のソースがぶら下がる計算になり、検索窓ごとに対象範囲を絞り込む設計だと読み取れます。
検索ソース：検索対象を束ねる43件（ais_search_source）
ais_search_source は、検索プロファイルから見た検索対象を定義するテーブルです。43件ありました。
Incident・Change・Problem・Knowledgeといった業務テーブルごとにソースが用意され、検索条件や表示フィールドをここで設定します。1つのプロファイルが複数のソースを組み合わせて、1つの検索窓の結果を組み立てる仕組みです。ソースの側から見ると、自分がどのインデックス定義を参照しているかは1件の項目にすぎません。逆にインデックス定義の側から見ると、複数のソースから同時に参照される状態が起こります。管理画面では Search Sources の一覧を開けば、対象テーブルと参照先のインデックス定義を1件ずつ確認できます。件数の並びがそれを裏付ける結果でした。
内訳を数えると、Knowledge Tableを参照するソースが11件、Catalog Item Tableを参照するソースが7件で、この2つだけで43件中18件を占めます。User tableは3件、Incident・Change・Problemはそれぞれ2件でした。残る12種類のインデックス定義は、1件ずつのソースからだけ参照されている計算になります。多くの業務テーブルは1インデックスに1ソースの専用対応です。Knowledgeのような一部のテーブルだけが、例外的に多くのソースから使い回されている状態でした。
インデックス定義：実際に索引を張る単位は27件（ais_datasource）
ais_datasource（Indexed Source）は、実際にインデックスを構築する単位を表すテーブルです。27件ありました。
検索ソースが「検索画面から見た対象」という論理的な単位なのに対し、インデックス定義は「どのテーブルのどの項目を、どういう条件で索引化するか」という物理的な単位です。役割の違いが、43と27という数の違いに直結しています。数だけを見ても分かりません。
フォームでは、対象テーブル・インデックス化する属性・ACLの上書き設定などを扱います。属性設定（ais_datasource_attribute）は24件、ACLの上書き（ais_acl_overrides）は18件、保持ポリシー（ais_retention_policy）は4件登録されていました。検索結果に出てほしい項目や、権限周りの挙動を直接いじりたいときは、ソースではなくこのインデックス定義を開くことになります。数は少なめです。Indexed Sources の一覧はソースの一覧より数が少ない分、1件ずつの設定を見比べやすい画面でした。
辞書：17件の辞書に932語が登録されている（ais_dictionary）
ais_dictionary は検索語の言い換えや同義語をまとめるテーブルです。17件でした。
辞書そのものは17件と少数ですが、辞書に登録された語（ais_dictionary_term）は932件ありました。1つの辞書が数十から数百の語を抱える構成です。表記ゆれや業務用語の吸収は、ソースやインデックスではなく辞書の担当になります。検索結果の精度を上げたいときに真っ先に触るべき場所は、条件式より辞書であることが多いはずです。ちなみにGenius Resultの設定（ais_genius_result_configuration）は4件で、こちらは検索結果の見せ方を作る別系統の設定でした。辞書は件数こそ少ないものの、932語という登録数の多さから、実際の運用では地道に育てていく前提のテーブルだと考えられます。件数と登録語数は別物です。
検索エンジンとしては止まっている：glide.ais.enabledがfalse
ここまでのプロファイル・ソース・インデックスはすべて定義として存在していますが、Zurich PDIでは検索エンジンとして動いていません。
glide.ais.enabled は false でした。glide.ais.search.enabled・sn_ais.enabled・glide.ui.ais.enabled に至っては値そのものが未定義です。定義はOOTBで入っているものの、スイッチが入っていない状態だと理解しています。
この状態を裏付けるのが、運用系テーブルの件数です。検索結果の改善ルールを持つ ais_rule・外部接続を持つ ais_connection・インデックス公開履歴の ais_publish_history・クエリ統計の ais_query_statistics は、すべて0件でした。比較として、Zing側の ts_query（検索クエリ）は4件、sys_search_suggestion（検索候補）は0件です。検索という行為そのものが、この環境ではほとんど発生していないと分かります。ZingとAI Searchは世代の違う2つの検索エンジンですが、どちらも稼働の痕跡はわずかでした。
実機で気づいたこと
43件のソースに対してインデックス定義が27件しかない事実を最初に見たとき、単純に「16件分どこかで消えている」ように見えました。本当にそうでしょうか。実機で内訳まで数えると、そうではありませんでした。27件のうち5件は最初からどのソースからも参照されていません。残り22件のうち10件は、Knowledge・Catalog Item・User・Incident・Change・Problemなど複数ソースからの参照を集めていました。検索ソースは「検索画面側の論理的な対象」、インデックス定義は「実索引側の物理的な単位」です。この役割の違いが分かると、設定画面が急に読みやすくなりました。
もう1つ意外だったのは、glide.ais.enabled がfalseのまま定義だけが最初から入っている点です。プロファイル・ソース・インデックスという3階層の設定を眺めているうちに、AI Searchはすでに稼働中の機能だという前提で見ていました。実際には設定の骨組みだけが用意された、いわば据え付け済みで電源が入っていない状態でした。障害調査でAI Searchの検索結果がおかしいという相談を受けたら、自分ならまずこのプロパティの値を見に行きます。プロファイルやソースの条件式を疑う前に、エンジンが動いているかどうかを確認するほうがコストが低いためです。
インデックス定義側で参照0件が5件残っている点も、実務で気に留めておきたい数字です。プロファイル・ソース・辞書のように相互の関連付けが増えていくテーブルがある一方で、インデックス定義には作られたものの現時点で使われていない定義が一定数含まれています。将来の拡張に備えた予備なのか、過去に使われていた名残なのかは、この一覧だけでは判別できません。運用系テーブルが軒並み0件だという状態は、裏を返せば環境の健全性チェックにも使えます。本番導入前にこれらのテーブルへ意図せずレコードが増えていないか確認すれば、想定外の検索アクセスや設定ミスの早期発見につながると考えられます。
実務では何に使えるか：検索結果を変えたいときにどこを見るか
検索結果を直したいという依頼が来たとき、自分は次の順で当たりを付けます。
どの検索窓の話かをまずプロファイルで特定する。同じ「検索」でも画面によってプロファイルが違う
プロファイルに紐づく検索ソースを開き、対象テーブルと検索条件を確認する
そのソースが参照しているインデックス定義を開き、索引化されている属性とACLの上書きを確認する
表記ゆれや同義語がヒットしないなら辞書と辞書の語を疑う
そもそも検索結果自体が古い、あるいは0件続きなら glide.ais.enabled の値を確認する
上から下へ、論理的な設定から物理的な設定へ、最後にエンジンの稼働状態へと絞り込む順番です。いきなり辞書やエンジンの状態を疑うと遠回りになりやすく、プロファイルとソースの組み合わせを先に確認したほうが早く原因にたどり着けます。
たとえば「Incidentの検索結果に古いレコードばかり出る」という相談を受けたとします。最初に見るのは、どのプロファイルの画面で起きているかという特定です。そのプロファイルにIncident用のソースが正しく紐づいているかを確かめます。次にソースが参照しているインデックス定義を開き、対象条件やACLの上書きで古いレコードだけが残る設定になっていないかを見ます。ここまでで原因が見えないなら、辞書の同義語設定か、索引の更新自体が止まっていないかを疑う番です。上から下へ順番に消していくだけで、闇雲にテーブルを開くよりも早く絞り込めます。
さらに詳しく知りたい人へ
AI Searchの検索ソースが43でインデックス定義が27になる理由 — 43と27のずれをより詳しく掘り下げた記事
Zingの正体：いま実際に有効化されているテキスト検索エンジン — 素のPDIで実際に動いている検索エンジン側の実測
Now Assist in Search が動かないのは AI Search が止まっているから — glide.ais.enabledが業務にどう影響するかの実例
よくある質問
Q1. なぜ検索ソースが43件なのにインデックス定義は27件なのですか
検索ソースは検索画面から見た論理的な対象、インデックス定義は実際に索引を張る物理的な単位です。役割が違うため、件数は一致しません。43件のソースが参照しているインデックス定義は22種類でした。Knowledge Tableのように複数のソースから使い回されているものと、どのソースからも参照されていないものが混在しています。
Q2. glide.ais.enabledをtrueにすれば検索は動くようになりますか
この記事はプロパティを有効化した状態での挙動までは検証していません。プロファイル・ソース・インデックスの定義自体はOOTBで用意されているため、有効化後の索引構築や検索結果の精度については別途確認が要ると考えられます。
Q3. 検索プロファイルと検索ソースは何が違いますか
検索プロファイルは「どの検索窓か」を表す単位です。検索ソースは「その検索窓が対象にするテーブルや条件」を表す単位です。1つのプロファイルが複数のソースを組み合わせて1つの検索結果を組み立てます。プロファイルとソースのM2Mは51件でした。
Q4. ais_dictionaryとais_dictionary_termの違いは何ですか
ais_dictionaryは辞書そのもの、ais_dictionary_termはその辞書に登録された個々の語です。辞書は17件、登録された語は932件でした。差は大きいです。単純に割ると1辞書あたり約55語という計算になります。表記ゆれや同義語の吸収は、辞書ではなく語のレコードとして積み上がっていく仕組みです。辞書を新設するより、既存の辞書に語を足す運用のほうが自然だと考えられます。
Q5. ais_ruleやais_connectionが0件なのは壊れているからですか
壊れているわけではないと考えられます。このPDIで検索エンジンとして稼働させていないためです。件数がそれを裏付けています。glide.ais.enabledがfalseの状態では、検索結果の改善ルールや接続、公開履歴、クエリ統計といった運用系のレコードが生まれる機会自体がありません。
まとめ
ServiceNowのAI Search設定は、検索プロファイル15件・検索ソース43件・インデックス定義27件という3階層でできています。プロファイルとソースはM2Mで51件、プロファイルと辞書はM2Mで39件つながっていました。43件と27件が一致しないのは、検索ソースが論理的な対象、インデックス定義が物理的な索引単位という役割の違いによるものでした。
素のZurich PDIでは glide.ais.enabled がfalseのままで、検索エンジンとしては止まっています。プロファイル・ソース・インデックス・辞書という骨組みは最初から用意されているものの、ais_rule や ais_connection のような運用系テーブルは軒並み0件でした。実際に検索を動かした痕跡は見当たりませんでした。設定画面を開いただけで機能が使えると判断せず、プロパティの値まで確認する必要があると分かります。
検索結果を直したいときは、プロファイル→ソース→インデックス→辞書→エンジンの稼働状態という順で見ると、遠回りせずに原因へたどり着けます。理由は構造にありました。3階層それぞれの役割を切り分けておけば、AI Searchの設定画面は思ったより読みやすい構造でした。
用語
ais_search_profile … 検索プロファイル。どの検索窓かを表す単位
ais_search_source … 検索ソース。検索窓が対象にするテーブルや条件
ais_datasource … インデックス定義（Indexed Source）。実際に索引を張る単位
ais_dictionary / ais_dictionary_term … 辞書と、そこに登録された語
glide.ais.enabled … AI Search全体のオン・オフを切り替えるプロパティ
実機で確認した画面のURL
/ais_search_profile_list.do … 検索プロファイル一覧
/ais_search_source_list.do?sysparm_query=GROUPBYdatasource … 検索ソースをインデックス定義別に集計
/ais_datasource_list.do … インデックス定義一覧
/ais_dictionary_list.do … 辞書一覧
/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.ais … AI Search関連プロパティ
参考リンク
検証環境と未検証範囲
件数・画面はZurich PDI（OOTB）で2026-08-08に確認したものです。一覧画面の件数表示とレコードを突き合わせて数えており、推定やサンプリングではありません。本番環境やカスタマイズ済みの環境では数値が異なります。
AI Searchを有効化した状態での検索結果・精度・応答速度は、glide.ais.enabled がfalseのため今回は確認していません。インデックスの再構築（publish）にかかる時間と挙動、Genius Resultが実際に何を返すか、関連性モデル（ais_relevancy_*）が何を学習しているかも、検証範囲の外に置いています。ZingからAI Searchへ切り替えたときの差分についても、今回は扱っていません。
