1. はじめに
ナレッジベースが手元にある。それをAIで検索して、回答まで返してほしい。この体験、実はServiceNowのOOTB機能だけで作れます。カスタム開発はゼロ、設定だけです。
完成形はこうなります。検索ボックスに自然文で質問を入れると、検索結果ページの上部に「Now Assist で生成された回答」カードが表示され、回答には引用番号（[1] など）が付きます。その下には、根拠になったナレッジ記事が一覧で並びます。「結果を探す」ではなく、「回答と根拠を同時に見る」検索です。
この記事では、AI Search の設定と Genius Results（Now Assist Multi-Content Response）の使い方を、設定手順として書きます。ナレッジベースの作り方は扱いません。すでにKBがある前提です。手元に適当なKBがなければ、環境に最初から入っているナレッジベースで検証しても構いません。
前提条件
機能・ライセンスの前提は以下です。
| 前提 | 確認方法 |
|---|---|
| AI Search が有効 | ais_search_profile.list が開ける |
| Now Assist Core が有効 | ナビゲーションに Now Assist Admin が出る |
| Now Assist in AI Search 関連機能が有効 | 後述の Now Assist セットアップ画面で確認 |
| Genius Result Configuration「Now Assist Multi-Content Response」が存在し Active | 同上 |
| 対象KBに Published / Active の記事が十分にある | kb_knowledge で確認 |
ロールは admin のほか、ais_admin・sn_nowassist_admin・knowledge_admin 相当の権限を使います。
⚠️ PDI では再現できません。Now Assist / Genius Results はライセンス前提の機能で、無償の開発者インスタンスには入っていません。このため、この記事にはスクリーンショットがありません。代わりに、すべての手順にナビゲーションパスと設定値の表を付けます。表の通りに進めば、同じ画面にたどり着けるはずです。
完成形の画面イメージは、ServiceNow 公式の動画「AI Search overview」が参考になります。
https://youtu.be/O7ifnuLXiIQ
なお、この記事の手順は、Zurich リリース（Patch 7a）の環境で、2026年6月時点で確認したものです。Now Assist 関連の機能はリリースや Patch によって変わることがあるため、お使いの環境のバージョン（System Diagnostics → Stats で確認できます）に合わせて読み替えてください。
全体像
先に、登場する部品の関係を示します。
| 部品 | 役割 | 一言でいうと |
|---|---|---|
| Search Source | どのテーブルの、どの条件のレコードを検索対象にするか | 検索対象の絞り込み |
| インデックス（セマンティック含む） | 対象レコードを語彙・意味の両面で索引化 | 検索の下ごしらえ |
| Search Profile | Source と Genius Results を束ねる検索体験の中心 | 検索体験の設定の束 |
| Genius Results | 検索結果の上に出る生成カード。回答生成は Now Assist Multi-Content Response が担う | AI回答カードの正体 |
| Search Application | どのポータルがどの Search Profile を使うかの紐付け | 入口と設定の接続 |
構築は、Source → Profile → 接続の順で進めます。
2. Step 1：対象KBを確認する
目的：検索対象にするナレッジベースの状態を確認します。
- ナビゲーションフィルタに「kb_knowledge.list」と入力し、ナレッジ記事一覧を開く。
- 対象KBに絞り込み、Workflow = Published かつ Active = true の記事が十分にあることを確認する。
| 確認項目 | 期待値 |
|---|---|
| Workflow | Published |
| Active | true |
| 記事数 | 検証に足る件数（数十件あれば十分） |
⚠️ ここがポイント：後述の Genius Results は、記事が Published であること、そしてユーザーに ACL 上のアクセス権があることを発動条件に含みます。下書き状態の記事や、権限で見えない記事は、いくら検索しても回答カードの根拠になりません。
もう一つ、作業を始める前に、専用の更新セットを作って切り替えておくことをおすすめします。あとで撤去したり、別環境に持っていったりするのが楽になります。
3. Step 2：Search Source を作成する
目的：AI Search の検索対象を、対象KBの公開記事だけに絞ります。
- ナビゲーションフィルタに「ais_search_source.list」と入力し、Search Source 一覧を開く。
- 「新規」をクリックする。
- 以下の設定値を入力して保存する。
- 保存後、初回の Index Now / Reindex を必ず実行する。
| 設定項目 | 値 | 理由 |
|---|---|---|
| Name | 任意（例：RAG検証 - ナレッジ） | 検証用と分かる名前にする |
| Source Table | kb_knowledge | ナレッジ記事を検索対象にする |
| Condition 1 | Knowledge Base = 対象のKB | 対象を限定する |
| Condition 2 | Workflow = Published | 公開済みのみ |
| Condition 3 | Active = true | 無効記事を除外 |
| Indexed Fields | short_description, text, kb_category 等 | タイトル・本文・カテゴリを索引化 |
| Active | true | Profile から利用可能にする |
⚠️ ここがポイント：Search Source は、作成しただけでは検索に出ません。初回の Index Now / Reindex を実行し、そのうえで次の Step で Search Profile に紐付けて、はじめて検索対象になります。「作ったのに出ない」の原因の第一位です。
4. Step 3：Search Profile を作成し、Genius Results を紐付ける
目的：検索対象（Source）とAI回答（Genius Results）を一つの検索体験に束ねます。ここがこの構成の中心です。
- ナビゲーションフィルタに「ais_search_profile.list」と入力し、Search Profile 一覧を開く。
- 「新規」をクリックし、以下を設定して保存する。
- 保存後、Sources 関連リストに Step 2 の Search Source を追加する。
- Genius Results 関連リストに、OOTB の「Now Assist Multi-Content Response」を追加する。
| 設定項目 | 値 | 注意点 |
|---|---|---|
| Name | 任意（例：RAG検証 Profile） | 検証用と分かる名前にする |
| Active | true | 無効だと検索で使われない |
| Public / Published | true | ポータルから参照するために必須 |
| Sources | Step 2 で作成した Source | 関連リストから追加 |
| Genius Results | Now Assist Multi-Content Response | OOTB をそのまま参照する。GR 自体は編集しない |
⚠️ 最頻ハマりポイント：Public / Published の付け忘れです。これを忘れると、後の Step で Search Application に正しく紐付けても、ポータル側でAI回答カードが出ません。筆者の環境でも、ここが原因の「出ない」が一番多く起きました。
Genius Results の発動条件も、ここで知っておくと後が楽です。以下がすべて満たされたときだけ、回答カードが生成されます。
- その Genius Result 設定が Search Profile で有効化されている
- 根拠になるKB記事が Published で、ユーザーにアクセス権がある
- KB記事に、質問への十分な解決策が含まれている
- 検索クエリが Genius Result 設定の条件に合致する
つまり、記事の中身が薄ければカードは出ません。これは不具合ではなく仕様です。出ない場合は通常の検索結果一覧だけが表示されます。
5. Step 4：セマンティックインデックスを確認する
目的：意味検索（セマンティック検索）側のインデックス設定を確認します。デフォルトのまま動くので、この Step は「確認して、触らない」が基本です。
場所：AI検索 > インデックス付きソース「Knowledge Table」> 関連リスト「セマンティックインデックス構成」> body / title のレコード。
現在のデフォルト値（確認時点）は以下です。
| 項目 | 値 |
|---|---|
| チャンク戦略 | パッセージ（Passage） |
| チャンク単位 | 単語（Words） |
| チャンクのサイズ | 250 |
| 文の重複（overlap） | 5 |
| 埋め込みモデル | ServiceNow Embedding（E5）。ロックされており変更不可 |
⚠️ ここがポイント（三つあります）：
- このレコードは「Now Assist in AI Search」というアプリケーションスコープに属しています。Global スコープのまま開くと読み取り専用に見えます。「設定できない」と思ったら、まず画面右上のスコープを Now Assist in AI Search に切り替えてください。筆者はここでしばらく悩みました。
- 近くに「[廃止]セマンティック構成」「[使用廃止]セマンティックフィールドのマッピング」という区画がありますが、どちらも旧機構です。現行の設定入口ではないので、触らないでください。
- この設定は kb_knowledge テーブル全体に効きます。KB単位では設定できません。レコードには「高リスク」の警告が付いており、変更するとインデックスの再作成が必要になります。検証の最初はデフォルトのままで十分です。
6. Step 5：検索ページに接続して動作確認する
目的：作った Search Profile を検索ページに接続し、AI回答カードが出ることを確認します。
- ナビゲーションフィルタに「sys_search_context_config.list」と入力し、Search Application 一覧を開く。
- 「新規」をクリックし、Portal に利用するポータル、Search Profile に Step 3 の Profile を指定して、Active = true で保存する。
- ブラウザで、そのポータルの検索ページ（例：/sp?id=search&q=パスワードのリセット方法）を開く。
| 確認観点 | 期待結果 |
|---|---|
| AI回答カード | 検索結果ページの上部に「Now Assist で生成された回答」が表示される |
| 回答本文 | クエリに対する手順や説明が表示される |
| 引用 | [1] または [1][2] が付く |
| 関連ナレッジ | 対象KBの記事が一覧表示される |
| クリック動線 | 引用またはリンクから根拠記事へ遷移できる |
⚠️ ここがポイント：
- 既存の検索体験に影響を与えたくない場合は、検証専用の Service Portal を一つ新規作成し（sp_portal.list から作成できます）、Search Application はそちらに紐付けてください。既存ポータルの設定には触らずに済みます。この記事ではポータル作成の詳細は扱いません。
- 初回のAI回答生成には15〜20秒ほどかかることがあります（筆者の検証時の実測です。環境や負荷によって変わります）。スケルトン表示（読み込み中の枠）が出ている間は、再読み込みしないでください。
- クエリは、記事が実際に答えられる内容で試してください。KBに書いていないことを聞いても、カードは出ません（前述の発動条件のとおりです）。
7. チューニングできること、できないこと
検証が動き始めると、次に気になるのは「どこを調整できるのか」です。実機で確認した範囲の一覧です。
| 工程 | パラメータ | 調整可否 | 場所 |
|---|---|---|---|
| インデックス（チャンク） | 戦略・サイズ・重複・単位 | ○ | セマンティックインデックス構成（スコープ切替が必要） |
| インデックス（モデル） | 埋め込みモデル | ×（E5固定） | 同上。ロック表示 |
| 検索 | 語彙検索と意味検索の混合比 | ×（設定として露出されていない） | なし |
| 回答生成の対象 | 検索対象の絞り込み | ○ | Search Source の Condition |
つまり、OOTBの範囲で検索の質に効かせられる主な手段は、検索対象の絞り込み（Source の条件設計）と、チャンク設定、そして何よりナレッジ記事そのものの品質です。モデルの差し替えや検索アルゴリズムの調整は、この構成ではできません。
日本語については、良い知らせがあります。AI Search の自然言語処理で日本語は第一優先グループに属していて、形態素解析によるトークナイゼーション、レンマ化、半角カタカナの正規化、同義語・ストップワード辞書まで対応しています。検索層の日本語精度は、身構えていたより心配いりませんでした。回答生成側の品質は、お使いの環境のLLM構成に依存するので、実際のKBで確認してください。
8. ハマりどころ集（出ないときに見る表）
| 症状 | 主な原因 | 確認・対応 |
|---|---|---|
| 検索結果がそもそも出ない | Source 未インデックス、Search Application の紐付けミス | Source の Index 状態、sys_search_context_config の Portal / Profile を確認 |
| 結果は出るがAI回答カードが出ない | Profile の Public/Published 忘れ、Genius Results 未紐付け | Profile の設定を確認。直っていれば少し待って再試行 |
| カードが出たり出なかったりする | 記事の解決策が薄い、クエリが曖昧 | クエリを具体化する。同一クエリを3回実行して出現率を見る |
| 引用が出ない | 引用できる根拠を特定できていない | 記事本文に答えが明記されているクエリで試す |
| スケルトン表示が長い | 生成の遅延、レート制限 | 15〜20秒待つ。改善しなければ時間を置いて再試行 |
| セマンティック設定が編集できない | Global スコープで開いている | Now Assist in AI Search スコープに切り替える |
AI回答カードが出ないときの確認順序は、上から順に「検索結果一覧は出ているか → Profile は Active かつ Public/Published か → Genius Results は紐付いているか → Search Application の紐付けは正しいか」です。いきなり OOTB の Genius Result 設定や内部しきい値を変えないでください。原因の切り分けができなくなります。
おわりに
ここまでで、「自然文で聞くと、AI回答カードと根拠ナレッジが返ってくる」検索が、設定だけで動きます。コードは一行も書いていません。
最後に一つだけ。この構成を動かしてみると分かりますが、回答の質の上限を決めるのは、検索の設定ではなくナレッジ記事そのものです。記事に答えが書かれていなければ、どんな設定でもカードは出ません。ナレッジベース側の品質をどう作り込み、どう検証するかは、別の記事で扱っています。
※ 参考：「LLMを組み込むETLパイプラインの設計：品質をどう証明し、欠陥をどう特定するか」（公開後にリンクを追記します）
検証がうまく動きますように。