Contextual Search：入力中に「似た答え」を出して重複起票を防ぐ
検索シリーズの4本目です。①AI Search、②Zing、③Now Assist は、いずれも「検索窓に語を打って探す」機能でした。今回の Contextual Search は毛色が違います。検索窓を開くのではなく、フォームに入力している最中に、その内容に合う答えを横から出す機能です。
たとえば、担当者がインシデントの「Short description（概要）」に「VPNにつながらない」と打ち始めると、その場で関連するナレッジ記事や過去の類似インシデントが候補として現れます。起票する前に「それ、もう答えがありますよ」と気づかせる。重複起票を減らす（Incident Deflection）ための仕組みです。地味ですが、標準で用意された機能です。今回は、その設定を cxs_* テーブルから読み解きます。
4つの検索機能（AI Search / Zing / Now Assist / Contextual Search）の全体像と比較は ServiceNowの検索は2階層：エンジン（Zing / AI Search）と、その上に乗る機能 にまとめました。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・状態はすべて REST で取得しました（確認日 2026-07-12）。本番環境やカスタマイズ済み環境では設定が異なります。
Contextual Search とは何をする機能か
動きを見てみます。利用者がフォームのテキスト欄に文字を入れると、Contextual Search はその文字列を検索クエリとして扱います。あらかじめ決めた対象（ナレッジ、カタログ、類似レコードなど）を検索します。結果は、フォームの近くに一覧で提示されます。担当者はそれを見て、「既存の記事で解決する」「同じインシデントが既にある」と判断できるわけです。
狙いは大きく2つです。1つは重複起票の抑制。同じ問い合わせが何件も上がるのを、起票前の気づきで減らします。もう1つは解決の高速化。過去の似た事例やナレッジに、わざわざ別画面で検索しなくてもたどり着けます。公式ドキュメントでは、この既定の使い方が「Incident Deflection（インシデントの抑制）」という名前で用意されています。
似た機能に「Agent Assist」があります。こちらは、担当者がインシデントを開いている最中に、サイドパネルで関連ナレッジや類似インシデントを出す仕組みです。実は Agent Assist も、この Contextual Search の設定（cxs_table_config）の上に成り立っています。あとで一覧を見ると、レコード名が「Agent Assist [incident]」のようになっているのはそのためです。起票フォームでの気づきも、作業中のサイドパネルも、裏側は同じ Contextual Search の設定でまかなわれている、と捉えると全体が見通せます。
全体像：3つのテーブルで決まる
Contextual Search の設定は、大きく3つのテーブルに分かれています。関係を1枚にします。
テーブル構成（cxs_table_config） … どのテーブルの、どの UI で Contextual Search を効かせるか。中核の設定
検索コンテキスト（cxs_context_config） … 「Incident Deflection」「Problem Solving」といった、名前の付いた検索のまとまり
サーチャー構成（cxs_searcher_config） … 何を検索対象にするか（ナレッジ、カタログ、ピン留め、ディスカッションの組み合わせ）
テーブル構成が検索コンテキストを指し、検索コンテキストがサーチャー（検索対象）を持つ、という3段構造です。「incident フォームで、Incident Deflection というコンテキストを使い、ナレッジとカタログを検索する」といった設定が、この3枚のつながりで表現されます。
テーブル構成（cxs_table_config）：どこで効くか
まず中核の cxs_table_config。実測15件です。
一覧を見ると、Name が「Agent Assist [incident]」「Agent Assist [problem]」のように並びます。それぞれに UI type と Search context が結びついています。incident には「Incident Deflection」、problem には「Problem Solving」が対応していました。problem_task には「Problem Analyzing」というコンテキストが対応していました。UI type の列には「Workspace」と「Platform」の2種類があります。同じ incident でも、従来UI（Platform）とワークスペース（Workspace）で別々のレコードとして設定される作りです。
OOTB で有効な対象は、実測で次のとおりでした。
対象は incident・problem・problem_task・change_request・change_task・kb_knowledge・interaction です。そしてメール下書き（sys_email_draft）にも及びます。タスク系だけでなく、ナレッジ記事の作成画面やメール作成にも Contextual Search が効くよう設定されていました。Limit 列（1回に出す件数の上限）は多くが 10、ナレッジのワークスペース検索だけ 100 と、対象によって差がつけてあります。
テーブル構成の主なフィールド
1レコードを開くと、Contextual Search の勘所となるフィールドが並びます。実測で確認できた主なものです。
table / ui_type … 対象テーブルと UI（Platform / Workspace）
cxs_context_config … どの検索コンテキストを使うか
match_condition … どんな条件のときに有効化するか
results_per_page / limit … 出す件数
related_search_active … 類似レコード検索を出すか
enable_source_selector … 利用者が検索対象（ソース）を切り替えるUIを出すか
search_as_active / search_as_field / search_as_script … 「何を検索キーにするか」の制御
required_roles … 表示に必要なロール
公式ドキュメントによれば、enable_source_selector をオンにすると、フォーム上で利用者が検索対象を選べるようになります。また、各テーブル構成の関連リスト「Search Action Configurations」で個々の検索アクションを Active=false にすれば、その動作だけ無効化できます。細かく出し分けられる設計です。
検索コンテキスト（cxs_context_config）：名前付きのまとまり
次に cxs_context_config。実測16件で、すべて active でした。
こういう名前が並びます：Knowledge Base Search / Knowledge Search / Incident Deflection / Incident Deflection (SOW)。ほかに Problem Solving / Problem Analyzing / Email Client Templates / FAQ Knowledge Articles もあります。Virtual Agent（VA）向けのコンテキスト（ITSM VA Catalog Item Search など）も含まれていました。コンテキストは「この場面ではこう検索する」というプリセットで、テーブル構成から参照されて使われます。同じ incident でも、通常の Platform 画面とワークスペース（SOW）で別のコンテキストが割り当てられているのが実測から読み取れます。
サーチャー構成（cxs_searcher_config）：何を検索するか
「何を検索対象にするか」を決めるのが cxs_searcher_config。実測9件でした。
中身は、検索対象の組み合わせです。Knowledge only（ナレッジのみ）／Catalog only（カタログのみ）／Knowledge and catalog（ナレッジ＋カタログ）などです。ほかに Knowledge, Pinned（ナレッジ＋ピン留め）／Knowledge, Pinned & Discussions（ナレッジ＋ピン留め＋ディスカッション）もあります。「ナレッジだけ出したい」「カタログも混ぜたい」「ピン留めした重要記事を優先したい」といった要望を、この9通りの組み合わせから選んでコンテキストに割り当てます。
具体的な場面で考えると分かりやすいはずです。社内ヘルプデスクの起票フォームなら、まずは公式ナレッジで自己解決してほしいので「Knowledge only」。IT サービスの申請フォームなら、記事だけでなく申請できるカタログ品目も見せたいので「Knowledge and catalog」。運用が成熟して、社内の議論スレッドにも有用な情報が溜まってきたら「Knowledge, Pinned & Discussions」まで広げる。同じ Contextual Search でも、どの組み合わせを選ぶかで、利用者に見せる「答えの引き出し」が変わります。ピン留め（Pinned）は、特に読ませたい記事を上位に固定する仕組みで、繁忙期の告知などを確実に目に入れたいときに役立ちます。一覧の Short description 列には、各サーチャーが何を返すかが1行で書かれている。たとえば「Knowledge, Pinned & Discussions」の説明は「ナレッジ記事・ピン留め記事・コミュニティから結果を返す」。ここでいう Discussions は Community（社内の議論）を指す、と説明文から読み取れました。名前だけでは分かりにくい対象範囲を、この説明列で確かめられます。
結果の中身：リソースと表示項目
検索結果として何を引き、どの項目を見せるかも、テーブルで決まっていました。cxs_search_res_config（検索リソース構成）が実測34件、cxs_search_result_fields（結果に出す項目）が13件です。
リソース構成は「どのソースから、どういう条件で引くか」を、結果項目は「一覧に番号・タイトル・状態などのどれを並べるか」を決めます。ここを調整すると、たとえば類似インシデントの一覧に「状態」や「担当グループ」を出す、といった見せ方の変更ができます。
どこから設定を開くか
実機で確認するときの入口です（URL形式は list.do 規約に基づきます。実クリック確認は今回の範囲外です）。
テーブル構成 … cxs_table_config_list.do（どのテーブル・UIで有効か）
検索コンテキスト … cxs_context_config_list.do
サーチャー構成 … cxs_searcher_config_list.do
検索リソース構成 … cxs_search_res_config_list.do
アプリケーションメニュー「Contextual Search」
Record Producer での注意点
Contextual Search は、サービスカタログの Record Producer（申請フォームからレコードを作る仕組み）でもよく使われます。ここに実務上の落とし穴が1つあります。公式ドキュメントやコミュニティの指摘によれば、Contextual Search はテキスト入力しか見ません。つまり、ドロップダウン（選択肢フィールド）で「VPN」を選んでも、それは検索キーになりません。検索のきっかけになるのは、あくまで自由記述の欄に打ち込んだ文字です。
だから「選択肢を選んだのに似た記事が出ない」という相談は、故障ではなく仕様であることが多いのです。重複起票を減らしたいなら、利用者が症状を自由記述する欄を用意し、その欄を検索キー（search_as_field）に設定するのが定石になります。また、利用者ごとに出す結果を変えたい場合は、スクリプトによるフィルタ設定で制御できる、とされています。match_condition や search_as_script は、そうした細かな出し分けのための入口です。
設定を追う道筋
3つのテーブルの関係が分かると、実機での追い方も見えてきます。公式ドキュメントが示す道筋はこうです。まず「Contextual Search → Search Contexts」を開き、たとえば「Incident Deflection」を選ぶ。そのレコードの関連リスト「Table Configurations」に、有効なテーブル（Incident など）が並んでいます。ここから、どのテーブルがこのコンテキストに紐づいているかを辿れます。
逆向きにも追えます。テーブル構成（cxs_table_config）の1レコードを開けば、そこから使っているコンテキストへ、さらにコンテキストからサーチャー（検索対象）へと降りていける。上から辿るか下から辿るか、どちらでも同じ3段構造に行き着きます。新しく対象を増やしたいときは、テーブル構成を1件足し、コンテキストとサーチャーを結びつける。この手順が土台になります。
フォーム上の見え方を調整したいときは、テーブル構成のフィールドが効きます。enable_source_selector をオンにすれば、利用者が検索対象を切り替えるプルダウンが出ます。related_search_active をオンにすれば、ナレッジだけでなく類似レコード（似たインシデントなど）も一緒に出る。出したくない検索アクションは、関連リストの「Search Action Configurations」で個別に止められます。派手さはありませんが、こうした細かなスイッチの積み重ねで、現場に合った気づきの出し方に寄せていきます。
他の検索機能との違い
このシリーズで見てきた検索と、Contextual Search はレイヤーが違います。AI Search や Zing は「検索エンジン」でした。Contextual Search は、そのエンジンをフォーム入力の文脈で呼び出す仕組みです。つまり Contextual Search は単独で動くのではなく、裏側で実際に検索を実行するエンジン（この PDI では Zing）に乗っています。
だから、Contextual Search の設定が正しくても、土台のエンジンやインデックスが弱ければ、出てくる候補の質は上がりません。逆にエンジンが良くても、cxs_table_config で対象テーブルが有効になっていなければ、フォームには何も出ません。設定とエンジンの両方がそろって、はじめて「入力中に似た答えが出る」体験になります。
この関係は、トラブル時の切り分けにも使えます。「候補がまったく出ない」なら、まず疑うのは cxs_table_config です。対象テーブルとその UI（Platform か Workspace か）が有効になっているか、match_condition で余計な条件がかかっていないかを見ます。一方「候補は出るが的外れ」なら、原因はエンジン側、つまりインデックスの内容や関連度に寄っています。②で見た Zing のインデックスの State や、①の AI Search の設定を確認する番です。出るか出ないかは Contextual Search の設定、質が良いか悪いかは検索エンジン。切り分けの軸を持っておくと、原因を素早く絞れます。
言い換えると、Contextual Search はエンジンの「呼び出し方」を決める層です。同じ Zing のインデックスでも、フォームのどの欄をきっかけに検索するかは、この層の設定しだいで変わります。何を対象に、何件出すかも、この層が決めます。エンジンを差し替えても（Zing から AI Search へ移行しても）、この呼び出し層の考え方は変わりません。だからこそ、検索を扱うなら、エンジンとこの文脈レイヤーを分けて理解しておくと応用が利きます。
まとめ
Contextual Search は、テーブル構成 → 検索コンテキスト → サーチャー構成の3段で決まる仕組みでした。「どのフォームで、どんな場面に、何を検索して見せるか」を決めます。実測では、テーブル構成15・コンテキスト16・サーチャー9が OOTB でそろい、incident や problem、ナレッジ作成やメール下書きまで対象になっていました。
検索窓を開く検索とは違い、利用者が起票しようとする流れの中に、そっと答えを差し込む。この「入力中の気づき」を設計するのが Contextual Search です。次回はいよいよ、ここまでの4つの検索機能を1枚の表で比較します。
その他、実機で確認した記録
用語
Contextual Search … フォーム入力中に、その内容に合う答え（ナレッジ・カタログ・類似レコード）を横に出す機能
Incident Deflection … 起票前の気づきで重複起票を減らす、既定の使い方
テーブル構成（cxs_table_config） … どのテーブル・UIで有効にするかの中核設定
検索コンテキスト（cxs_context_config） … 名前付きの検索プリセット
サーチャー構成（cxs_searcher_config） … 何を検索対象にするかの組み合わせ
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/cxs_table_config_list.do（テーブル構成15件・対象とUI）
/cxs_context_config_list.do（検索コンテキスト16件）
/cxs_searcher_config_list.do（サーチャー構成9件）
/cxs_search_res_config_list.do（検索リソース構成）
実測の要点（再掲）
テーブル構成 15／コンテキスト 16（全active）／サーチャー 9／リソース構成 34／結果項目 13
対象: incident / problem / problem_task / change_request
change_task / kb_knowledge / interaction / sys_email_draft
UI type は Platform（従来UI）と Workspace の2種類。同じテーブルでも UI ごとに別レコード
関連記事
ServiceNow AI Searchはどう組み立てられている？ プロファイル・ソース・インデックスを実機で追う — Contextual Searchが最終的に呼び出すAI Search本体を、プロファイル・ソース・インデックスの構成から確認した記事です
検証範囲とおことわり
この記事の件数・状態・対象テーブルは、PDI（Zurich / OOTB）の REST 実測です。
実際にフォームで文字を入れたときの検索結果パネルの見え方（候補が並ぶ様子）は、対象レコードでの入力操作が必要で、本記事は設定テーブルの実測に留めます（入力時の実挙動は検証範囲外）。
match_condition / search_as_script の具体的な条件式・スクリプト内容、Virtual Agent 連携の実挙動は検証範囲外です。
ui_type=Workspace の設定が実際にどのワークスペース画面で効くか（ライセンス/プラグイン前提）は個別環境によります。
