一覧の検索欄で使える記号と絞り込みの書き方
ServiceNow の一覧画面には、列ヘッダのすぐ下に検索欄が並んでいます。ここに文字を打って Enter を押すと、その列だけで絞り込みがかかります。名前や番号の一部を打って探す、という使い方をしている人は多いはずです。
この検索欄には、記号を使った書き方が何種類も用意されています。前方一致や後方一致はもちろん、完全一致・除外・数値や日付の比較まで切り替え可能です。知らなくても検索欄は使えますが、知っていると絞り込みの精度が変わります。
もう一つ、見落としやすい前提があります。何も記号を付けずに Enter を押したときの既定の挙動です。多くの人は「前方一致だろう」と思っていますが、ServiceNow の公式ドキュメントが説明している実際の仕様は少し違います。この記事では、その既定挙動の正確な意味を最初に扱います。そのうえで記号ごとの書き方、右クリックメニューやパンくずの操作、選択肢・参照・日付フィールドでの違いへと話を進める構成です。
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich リリースの OOTB（初期設定）で確認し、記載した記号・挙動は ServiceNow 公式ドキュメントの内容とあわせて確認しています。実環境では権限やカスタマイズにより結果が変わります。
この記事で分かること
検索欄と、スクリプトで書くエンコードクエリが別の仕組みであること
何も記号を打たないときの既定の挙動は「前方一致」ではなく「値以上」であること
検索欄に打てる記号の一覧（前方一致・後方一致・部分一致・完全一致・否定・比較）
選択肢・参照・日付フィールドで検索欄の書き方がどう変わるか
列ヘッダの右クリックメニューと、値そのものを右クリックするメニューは別物であること
条件のパンくずを操作する方法と、Copy Query で条件を文字列として持ち出す方法
検索欄・フィルタ条件ビルダー・保存フィルタを実務でどう使い分けるか
検索欄とエンコードクエリは別物
ServiceNow で一覧を絞り込む方法は、実は2種類あります。
1つは、スクリプトや URL のパラメータで書くエンコードクエリです。sysparm_query に文字列を渡す方法や、GlideRecord の addEncodedQuery() がこれにあたります。演算子には ^OR や IN、LIKE、ISEMPTY などがあり、書式の詳細は エンコードクエリ文字列（ServiceNow Docs） にまとまっています。
もう1つが、今回のテーマである画面の検索欄です。列ヘッダの下の欄に、人が直接文字や記号を打ち込んで絞り込みます。裏側では最終的にどちらも同じクエリの仕組みに行き着きますが、打ち込む場所も書き方の作法も別物です。この2つを混同すると、「スクリプトで見た演算子が画面で通じない」と戸惑うことになります。
この検索欄は、特定の一覧だけの機能ではありません。PDI 実機で数えると、テーブルは全部で6,317件ありました。一覧の列構成を決めるリスト定義（sys_ui_list）は4,646件、テーブルごとの表示を分けるビュー定義（sys_ui_view）は707件です。テーブルとビューの組み合わせの数だけ、この検索欄に出会う場面があります。一覧そのものの基本構成は クラシック環境の一覧（Lists in the classic environment、ServiceNow Docs） にまとまっています。
検索欄の使い方 ― Go to と for text、列ごとの検索欄
一覧の上部には、実は検索の入り口が2か所あります。
タイトルバーの左側にある「項目名のプルダウン＋検索ボックス」は、公式ドキュメントで Go to と呼ばれる仕組みです。プルダウンで項目を選び、テキストを打って Enter を押すと、その項目で絞り込みます。プルダウンを for text に切り替えると Search という動きに変わり、一覧に含まれるすべての項目を対象に、入力した文字列を含むレコードを探します。関連リストの条件を追加している場合、この全文検索は関連テーブルのレコードまでは対象にしません。詳しい手順は 検索欄で一覧を絞り込む（Search a List、ServiceNow Docs） に載っています。
もう一つが、列ヘッダのすぐ下に並ぶ検索欄です。こちらはタイトルバーのプルダウンを操作しなくても、見えている列でそのまま条件を打ち込めます。実機で確認したところ、この列ごとの検索欄でも =1 - Critical のように Go to と同じ記号がそのまま通ります。タイトルバーの Go to と列の検索欄は入口が違うだけで、記号の書き方は共通と考えてよさそうです。
既定の挙動は「前方一致」ではなく「値以上」
ここが、この記事でいちばん誤解されやすい点です。検索欄に記号を付けずに文字だけ打つと、公式ドキュメントは「入力した値以上のレコードを検索する」と説明しています。テキスト型の項目では、まず選んだ項目で一覧を並び替えます。そのうえで、入力した文字列で始まる最初のレコードと、それより後ろに並ぶすべてのレコードを返す、という動き方です。
つまり、単純な前方一致ではありません。並び替えた結果として「その文字列で始まる行」と「並び順でそれより後ろの行」がまとめて表示されます。実務では前方一致に近い結果に見えることが多いものの、項目の値の分布によっては、狙っていたより広い範囲がヒットすることがあります。
さらにややこしいのが、項目名が number または u_number の項目です。ServiceNow はこの名前の項目を特別扱いし、値以上ではなく「入力した数字で終わるレコード」を返します。インシデント一覧で Number を選んで 4 と打つと、INC0000004 だけでなく INC0000014 のような番号も返ってくるのはこのためです。
既定の挙動を変える管理者向けプロパティ
この既定挙動は、システムプロパティで変更できます。glide.ui.goto_use_contains を true にすると部分一致、glide.ui.goto_use_starts_with を true にすると前方一致が、それぞれ既定になる仕組みです。項目単位で変えたい場合は、辞書（Dictionary）の属性に goto_use_starts_with=true を追加します。
公式ドキュメントは、この変更について明確に注意しています。部分一致・前方一致のどちらも、既定の「値以上」検索より多くのレコードを返しやすく、パフォーマンスに影響しうるという指摘です。大きなテーブルで既定挙動を変える前に、この点は把握しておく価値があります。
打てる記号（ワイルドカード）
記号なしの挙動を押さえたところで、明示的に記号を付ける書き方を見ていきます。全部で6つです。実機と公式ドキュメントの両方で確認した一覧です。
主役は % です。前後どちらに置くかで一致の範囲が変わります。うしろに置いた 文字列% は前方一致、前に置いた %文字列 は後方一致です。*文字列 あるいは %文字列% と書くと、文字列を含むレコードを部分一致で拾います。= を頭に付ければ、値以上の検索では拾えない「この値だけ」という絞り込みができます。!= は等しくない値を、!* は文字列を含まない値を返す、除外のための書き方です。
数値・日付の項目では > < >= <= がそのまま比較演算子として働き、期間や範囲を指定するときに使います。これらの記号は、タイトルバーの Go to 欄でも列ごとの検索欄でも同じように通ります。
選択肢・参照・日付フィールドでの書き方の違い
同じ検索欄でも、項目の型によって「何を打てば当たるか」が変わります。3つの型で確認したことをまとめます。
選択肢（choice）フィールド ― ラベルと内部値のどちらでも検索できる
選択肢の項目は、画面に出るラベルと、裏側に保持している内部値の2つの値を持っています。検索欄はどちらに反応するのでしょうか。インシデントの Priority で確認すると、内部値 1 に対してラベルは 1 - Critical でした。
この画面は URL の sysparm_query で priority=1 を渡して開いたものですが、Priority 列の検索欄には内部値の 1 ではなく =1 - Critical と、ラベルの側が表示されています。つまり検索欄は既定でラベルを検索対象にしており、= を付けてラベルの完全一致で絞り込んでいる状態です。State のようにラベル（New）と内部値（1）の見た目がまったく違う項目で試すと、この違いがより分かりやすくなります。ラベルの文言そのままか、その先頭部分を打てば選択肢は絞り込めます。
参照(reference)フィールド ― 表示値で検索される
Caller のような参照項目は、参照先テーブル（この場合は sys_user）の sys_id ではなく、画面に表示されている値、たとえば氏名の表示名で検索されます。sys_id を検索欄に打っても一致しません。
参照項目はオートコンプリートの候補を絞り込む専用のワイルドカードを別に持っており、ここまで説明してきた列検索の記号とは仕様が異なります。公式ドキュメントも参照項目については別項目として案内しており、本記事では検索欄の基本挙動という範囲にとどめます。
日付フィールド ― 相対指定は検索欄の役割ではない
日付・日時の項目にも、この記事で説明した記号はそのまま使えます。ただし「今週」「先月」のような相対的な指定は、検索欄ではなく列ヘッダの右クリックから開ける フィルタ条件ビルダー（Condition builder、ServiceNow Docs） の役割です。条件ビルダーの日付演算子には Today・This week・Last 3 months のようなプリセットがあり、実行した瞬間の日時を基準に範囲を計算します。詳細は 日付・日時項目の値（Values for date/time fields、ServiceNow Docs） にまとまっています。日付を絞り込みたいときは、検索欄で具体的な日付を打つか、相対指定が要るならフィルタ条件ビルダーに切り替える、と使い分けるのが実務的です。
右クリックでできること ― ヘッダと値は別のメニュー
検索欄の近くには、右クリックで開くメニューが2種類あります。対象が違います。見た目が近いので混同しやすいところです。
列ヘッダを右クリック ― 並び替え・グループ化・出力
列ヘッダそのものを右クリックすると、その列に対する操作メニューが開きます。
実機で開いたメニューには、Sort (a to z) / Sort (z to a) の並び替えが並んでいました。ほかにも Group By によるグループ化、Bar Chart / Pie Chart の可視化、Configure・Export・Import XML・Show XML があります。Configure と Export には、さらに先のサブメニューが用意されています。この右クリックメニューの定義は sys_ui_context_menu というテーブルに入っており、PDI 実機では86件の定義がありました。
グループ化で集計する（Group By）
列ヘッダのメニューにある Group By を選ぶと、その列の値ごとに一覧がまとまり、グループごとの件数が表示されます。
State でグループ化すると、New・In Progress・On Hold・Closed のグループがそれぞれの件数付きで並びました。グループ名の右にある矢印をクリックすると、そのグループだけを展開してレコードを確認できる仕組みです。解除するときは、同じメニューから Ungroup を選びます。仕様の詳細は グループ化した一覧（Grouped lists、ServiceNow Docs） にあります。
値を右クリック ― Show Matching / Filter Out
列ヘッダではなく、一覧の中の値そのものを右クリックすると、別のメニューが開きます。ここに出てくるのが Show Matching（その値と一致する条件を追加）と Filter Out（その値を除外する条件を追加）です。どちらも、いま効いている条件の右側に新しい条件を1つ足す動きをします。
公式ドキュメントには実務で見落としやすい注意点が書かれています。Filter Out である値を除外すると、その項目が空（未入力）のレコードは残る形で条件が組まれる仕組みです。フィルタ条件ビルダーで手動で「等しくない」条件を作った場合はこの自動追加が働かないため、Filter Out で除外したときとは結果の件数が変わることがあります。日付・日時の項目では、Show Matching / Filter Out に加えて Show Before / Show After という前後関係の絞り込みも選べます。詳細は 値を右クリックして絞り込む（Quick filters、ServiceNow Docs） を参照してください。
パンくずの操作とCopy Query
条件を1つ追加すると、一覧の上部に条件を表す帯が表示されます。この帯を、ここではパンくずと呼びます。
先ほどの画面例では、パンくずに All > Active = true > Priority = 1 - Critical と表示されていました。左から右に向かって、条件が一般的なものから具体的なものへと並ぶ構成です。詳しい仕様は フィルタとパンくず（Filters and breadcrumbs、ServiceNow Docs） にまとまっています。
条件を消す ― > と本体クリックの違い
パンくずのクリックする場所によって、消える条件の範囲が変わります。条件と条件の間にある > をクリックすると、その条件だけが消える仕組みです。一方、パンくずの条件名そのものをクリックすると、そこから右にある条件がまとめて消え、クリックした条件を基準にした状態で一覧が再表示されます。All をクリックすれば、すべての条件が外れる点も覚えておくと安心です。どちらを押すかで削る範囲がまったく違うので、操作前に意識しておく価値があります。
Copy Query で条件を持ち出す
パンくずを右クリックすると、Open new window・Copy URL・Copy query という項目が出ます。Copy query を選ぶと、いま効いている条件がエンコードクエリの文字列としてコピーされます。All の状態では条件がないため、この項目は使えません。
コピーした文字列は、ブラウザの URL の sysparm_query にも、GlideRecord の addEncodedQuery() にも、そのまま貼り付けられます。手順の詳細は フィルタからエンコードクエリ文字列を生成する（ServiceNow Docs） にまとまっています。GlideRecord 側のメソッド仕様は GlideRecord - Scoped（APIリファレンス、ServiceNow Docs） を参照してください。検索欄に記号を組み合わせ、値の右クリックで絞り、パンくずで不要な条件を削る。ここまで画面上で組み立てた結果を、Copy query で1回のコピーとして取り出せます。
実務での使い分け ― 検索欄・条件ビルダー・保存フィルタ
ここまでの機能は、それぞれ向いている場面が違います。使い分けの目安です。
さっと1列だけ絞りたいときは、列の検索欄が最短です。記号を覚えていれば、マウスに触れずキーボードだけで完結します。複数の項目を組み合わせたいときや、AND と OR を混在させたいとき、日付の相対指定をしたいときは、列ヘッダの右クリックから開くフィルタ条件ビルダーへの切り替えどきです。条件は項目・演算子・値の組み合わせで積み上げていく形で、ドット・ウォーク（関連テーブルの項目を辿る指定）にも対応しています。
同じ絞り込みを毎回作り直しているなら、フィルタを都度組むより保存しておくほうが早くなります。作った条件は Copy query でエンコードクエリとして書き出せるので、モジュールのリンクや URL に埋め込んで、次回から一発で同じ絞り込みを開けるようにしておくと手戻りが減ります。
大きなテーブルほど、この絞り込みの必要性が増します。
PDI 実機のシステムログ（syslog）は66万件を超えていました。これだけの規模のテーブルを条件なしで開くと、一覧が表示されるまで待たされます。sysparm_filter_only=true を付けて開くと、レコードを1件も読み込まずにフィルタ入力の画面だけが表示される、という動き方です。条件を組み終えてから実行すれば、最初から絞り込んだ状態の一覧が返ってきます。
つまずきやすい点
検索欄を使ってきて、実機で戸惑いやすかった点です。3つあります。
部分一致・前方一致を既定にする変更は重くなりやすいという点は、先に触れたとおりです。glide.ui.goto_use_contains や goto_use_starts_with を安易に有効化すると、既定の「値以上」検索より多くのレコードが対象になり、大きなテーブルほど応答が遅くなります。管理者権限で変更する前に、対象テーブルの件数を確認しておくと安心です。
パンくずは既定で表示できる条件数に上限があります。 システムプロパティ glide.ui.breadcrumb_max_entries の既定値は10件です。条件を積み重ねすぎると、それ以上はパンくずに表示されなくなります。込み入った条件を組むときは、途中で Copy query を使って文字列として控えておくと安全です。
スペースや記号を含む値は、そのままでは意図どおりに解釈されないことがあります。 記号自体を検索したい場合、たとえば = という文字そのものを含む値を探したい場合は、検索欄の記号と衝突するため注意が必要です。値に記号が混ざっているデータを検索するときは、部分一致（*文字列*）で試すか、フィルタ条件ビルダー側で明示的に演算子を選ぶほうが確実です。
よくある質問
検索欄に打った条件は、フィルタとして保存されますか
答えはノーです。検索欄に打った条件は、その場限りの絞り込みです。ページを離れると条件は残りません。繰り返し使う条件にしたい場合は、列ヘッダの右クリックからフィルタ条件ビルダーを開いて条件を組み直します。あるいは Copy query でエンコードクエリを控えておき、モジュールのリンクや URL として保存しておく方法もあります。
検索欄は大文字と小文字を区別しますか
多くの環境では区別しないことが一般的ですが、これはデータベース側の照合順序に依存する設定です。大文字・小文字を厳密に区別する必要がある場面では、検索欄の挙動をそのまま信用せず、対象データを確認してから判断するほうが安全です。
Caller のような参照項目に、対象レコードの sys_id を打っても検索できますか
検索できません。参照項目の検索欄は、参照先テーブルの表示値（氏名などの表示用の文字列）を対象にしています。sys_id で絞り込みたい場合は、フィルタ条件ビルダーで sys_id 項目を明示的に指定する必要があります。
日付項目に「今週」のような相対指定を打てますか
検索欄自体には打てません。相対的な日付指定は、列ヘッダの右クリックから開くフィルタ条件ビルダーの役割です。Today・This week・Last 3 months のような演算子が用意されています。
検索欄で複数の条件を OR でつなぐことはできますか
検索欄1つにつき打てるのは1つの条件です。OR で複数条件をつなぎたい場合は、エンコードクエリの ^OR を使うか、フィルタ条件ビルダーで OR 条件を組みます。検索欄だけで完結する機能ではありません。
自分の環境で確認するときのURL
この記事の記号・挙動の説明は、PDI での確認とあわせて、次の ServiceNow 公式ドキュメント（Zurich リリース）を根拠にしています。
用語
Go to … タイトルバーのプルダウンで項目を選び、テキストを打って絞り込む検索の入り口
for text / Search … Go to のプルダウンを切り替えたときの全項目対象の検索
ワイルドカード … 検索欄で前方一致・後方一致・部分一致などを指定する記号（% * = ! など）
エンコードクエリ文字列 … フィルタ条件を ^（AND）や ^OR などでつないだ、機械可読な条件の書式
パンくず … 一覧の上部に表示される、いま効いている条件を表す帯
Copy query … パンくずを右クリックして、条件をエンコードクエリ文字列としてコピーする操作
Quick filters … 一覧の値を右クリックして Show Matching / Filter Out を選ぶ絞り込み機能
条件ビルダー(Condition Builder) … 項目・演算子・値を組み合わせて条件を作る画面上のツール
検証範囲外のこと
検索欄で複数条件を OR でつなぐ専用の記法は見当たりませんでした。OR が必要な場合はエンコードクエリの ^OR か条件ビルダーを使う前提で扱っています
参照フィールド専用のオートコンプリートのワイルドカードは、公式ドキュメントで列検索とは別項目として案内されており、本記事の検証範囲には含めていません
大文字・小文字の区別は、データベースの照合順序に依存するため、本記事では一般的な傾向のみを扱い、個々の環境での挙動までは確認していません
Next Experience Workspace 側の一覧・検索欄の挙動は、この記事の検証範囲外です
まとめ
検索欄は文字を打つだけの欄に見えますが、記号と既定の挙動を知っているかどうかで、読める結果の精度が変わります。とくに「記号なしは前方一致」という思い込みは、値以上という実際の仕様とずれるため、意図しない件数を拾ってしまう原因になりやすいところです。列ヘッダの右クリック、値の右クリック、パンくずまで含めれば、画面の中だけで条件を組み立てて持ち出せる一式がそろいます。
