URLでリストの条件と表示を指定する方法（sysparm_query）
ServiceNow の一覧画面の URL は、こんな形をしています。
https://<YourInstance>/incident_list.doここに ?sysparm_query=active=true を足すと、有効なインシデントだけに絞られた状態で開きます。フィルタを画面で組む代わりに、URL に書いてしまうということです。
この「URL に足すだけ」の小ワザは、一度覚えると調べ物の速度が変わります。条件付きのリンクを人に渡せますし、同じ確認を毎回クリックで再現しなくて済みます。エクスポートや初期値入りのフォームまで含めると、覚える価値のあるパラメータは全部で10個です。
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich リリースの OOTB（初期設定）で確認しています。実環境では権限やカスタマイズにより結果が変わります。
この記事のURLは、実際に打てる形で書いています。差し替える箇所は次の2つです。
<YourInstance> … 自分のインスタンス名。ブラウザのアドレスバーに出ているものに置き換えます
incident … 対象のテーブル名。sys_user や change_request など、調べたいテーブルに置き換えます
条件や件数を指定する部分も、そのまま書き換えて使えます。
この記事で分かること
URL に書ける絞り込み条件の形（sysparm_query）と、そこで使える演算子
巨大なテーブルを開くときに待たされない方法
画面を経由せず XML / CSV / XLS / PDF でデータを取り出す方法
インスタンスの状態を見る診断用の画面
URL エンコードやフィックスドクエリまわりで、つまずきやすい点とその対処
1. sysparm_query で条件を URL に書く
一覧の URL に条件を直接書けます。区切りは ^（AND）です。
https://<YourInstance>.service-now.com/incident_list.do?sysparm_query=active=true^priority=1この active=true^priority=1 のような文字列は、正式にはエンコードクエリ文字列と呼ばれます。一覧のフィルタ条件を1本のテキストへ畳んだもので、URL のパラメータとしても、スクリプトの検索条件としても、同じ書式のまま使い回せます。仕様の詳細は Encoded query strings（ServiceNow Docs） を参照してください。
演算子の一覧
^（AND）と =（等しい）だけでも実用になりますが、覚えておくと絞り込みの幅がぐっと広がる演算子がほかにもあります。よく使うものを一覧にしました。
LIKE は画面のフィルタ条件で「contains」を選んだときに、内部的に使われている演算子です。short_descriptionLIKEemail と書けば、説明に email を含むレコードを部分一致で拾えます。^NQ はやや特殊な演算子で、そこから後ろを独立した条件のかたまりとして扱い、それより前の条件全体との OR として結びつく仕組みです。複雑な「これか、あれの組み合わせ」を1本の URL で表したいときに使います。演算子ごとの動きを実機の件数で確かめた記事を、開発ハンズオンシリーズの一本として別にまとめました（エンコードクエリ演算子図鑑）。
Copy Query で取り出し、スクリプトに流用する
演算子の綴りや ^ の位置を手で組み立てる必要はありません。画面でフィルタを組んだあと、条件が並ぶ帯（パンくず）を右クリックし、Copy Query を選べば、この形の文字列がそのままコピーできます。手順は フィルタからエンコードクエリ文字列を生成する（ServiceNow Docs） に載っています。
コピーしたクエリは、URL に貼るだけでなく、サーバサイドスクリプトの GlideRecord.addEncodedQuery() にもそのまま渡せます。詳しいメソッドの仕様は GlideRecord - Scoped（API リファレンス、ServiceNow Docs） で確認できます。画面で条件を組み、コピーして、URL かスクリプトに貼る。この流れが一番早く、打ち間違いも起きません。
2. sysparm_filter_only=true で行を読まずに開く
大きなテーブルを開くと、一覧が出るまで待たされます。先に条件だけ組みたいときは、これを足します。
https://<YourInstance>.service-now.com/incident_list.do?sysparm_filter_only=truePDI で実際に叩いたところ、件数表示は 0 of 0、本文は「No records to display」でした。レコードを1件も読まずに、フィルタの画面だけが出ている状態です。
システムログ（syslog）のように数十万行あるテーブルでは、この差がそのまま待ち時間の差になります。PDI の syslog は約79万件ありました。条件を組み終えてから Run を押せば、最初から絞り込んだ状態の一覧が返ります。何度も同じ大テーブルを開いて試行錯誤するときほど、効果を実感しやすいパラメータです。
3. sysparm_view で表示するビューを切り替える
同じテーブルでも、ビューを変えると出る項目が変わります。
https://<YourInstance>.service-now.com/incident_list.do?sysparm_view=ess実機で叩くと、画面のタイトルが「Incidents View: Self Service」に変わりました。セルフサービス向けの見え方に切り替わっています。PDI にはビュー定義が 707 件ありました。ビューをいつ・誰に見せるかは管理者側でも制御でき、詳細は 表示するビューを制御する（ServiceNow Docs） にまとまっています。
sysparm_view_forced=true を足すと、ユーザー側でビューを切り替えられなくなります。誰かに「この見え方で見てほしい」リンクを渡すときに使えます。あるビューにだけ存在する項目を確かめたいときも、sysparm_view を切り替えて開き直すのが最短です。
4. ?XML を足して、レコードの中身を全部見る
一覧やレコードの URL の末尾に ?XML を足すと、画面ではなく XML が返ります。
https://<YourInstance>.service-now.com/incident_list.do?XML&sysparm_record_count=2フォームに出ていない項目も含めて出力されるのが利点です。画面のレイアウトに載っていない列、参照先が消えている項目、内部的な値。これらを確認するとき、XML が一番早い方法です。件数を絞りたいときは sysparm_record_count=2 のように添えます。
レコード1件なら、フォーム画面のヘッダを右クリックして Show XML でも同じものが見られます。レコード単位のエクスポートの手順は、レコードからのデータエクスポート（ServiceNow Docs） のとおりです。画面のレイアウトを疑うとき、たとえば「この項目、どのビューにも出てこないけど値は入っているのか」を確かめたいときは、XML 出力を挟むとレイアウトの都合とデータの実体を切り分けやすくなります。
5. ?CSV ?XLS ?PDF でそのままエクスポートする
出力形式を変えるだけです。
https://<YourInstance>.service-now.com/incident_list.do?CSV
https://<YourInstance>.service-now.com/incident_list.do?XLS
https://<YourInstance>.service-now.com/incident_list.do?PDFURL を叩くとファイルのダウンロードが始まります。画面のメニューからエクスポートを選ぶのと同じ結果ですが、条件付き URL と組み合わせられるのが利点です。「この条件の一覧を毎週 CSV で」という用途なら、URL を1本作っておけば済みます。手順の全体像は URLから直接エクスポートする（ServiceNow Docs） にまとまっています。
この方式は、あくまでブラウザにログインした状態でのアクセスが前提です。認証なしで叩ける公開エンドポイントではないので、URL を共有しても、開いた相手の権限を超えてデータが見えるわけではありません。相手がそのテーブルを読む権限を持っていなければ、同じ URL でも空の結果か権限エラーになります。
6. sysparm_default_export_fields=all で非表示の列も出す
エクスポートは、既定では画面に出ている列だけが対象です。sys_id のような普段は隠れている項目は入りません。
これを足すと全項目が出ます。
https://<YourInstance>.service-now.com/incident_list.do?XML&sysparm_default_export_fields=all実機で叩いたところ、出力に sys_id が含まれることを確認しました。他システムへデータを渡すとき、突き合わせのキーとして sys_id が要ることは多いので、覚えておくと手戻りが減ります。どの列が対象になるかの仕様は リストからのデータエクスポート（ServiceNow Docs） に載っています。
件数を絞りたいときは sysparm_record_count=100 のように添えます。列を絞りたい既存のエクスポートに sysparm_default_export_fields=all を後付けするだけで、わざわざ画面側の列構成を変更せずに済むのも扱いやすい点です。
7. 新規フォームを開いた時点で項目を埋めておく
新規作成フォームに初期値を入れた状態で開けます。
https://<YourInstance>.service-now.com/incident.do?sys_id=-1&sysparm_query=short_description=テスト起票^priority=1sys_id=-1 が「新規」を意味し、sysparm_query に書いた内容がそのまま初期値になります。この動き方については、URLを使ってレコードやモジュールに移動する（ServiceNow Docs） が参照先です。URL経由で値を入れる方法をさらに知りたい場合は、URL経由で値を入れる3つの方法（ServiceNow Developer Blog） が参考になります。
実機で incident.do?sys_id=-1 を開いたとき、画面のタイトルは「Create INC0010026」でした。保存前の時点ですでに番号が採番されています。
決まった内容で起票してもらいたいとき、このリンクを渡せば入力の手間と間違いが減ります。ただし、選択肢（choice）や参照（reference）項目は、URL の値がその項目の実際の選択肢や sys_id と一致しないと反映されません。文字列としてそれらしい値を書いても、テーブル側に該当データがなければ空欄のまま開きます。事前に選択肢一覧や対象レコードの値を確認してから URL を組み立てるのが安全です。
8. /stats.do でインスタンスの状態を見る
stats.do
実機で叩くと「Servlet statistics」というページが返り、サイズは 28KB でした。接続しているノードの名前、システム構成、メモリの状況などが並びます。
接続中のノードを確認したいときや、動作が重い原因を切り分けたいときに使います。stats.do と xmlstats.do は docs.servicenow.com のバンドル文書には見当たりません。ただし以前から知られた診断用エンドポイントで、stats.do・xmlstats.doの解説（ServiceNow Community） にも使い方がまとまっています。
XML で欲しいときは xmlstats.do です。ただし実機で取得したところ 17.7MB ありました。丸ごと取ると大きいので、?include= でセクションを絞るのが現実的です。
9. /cancel_my_transaction.do で自分の重い処理を止める
重いクエリを流してしまって画面が返ってこない、ということがあります。
cancel_my_transaction.do実機で叩くと「Cancel Notification」というページが返りました。自分のセッションで実行中の処理を中断するためのものです。
インスタンス全体ではなく自分の分だけを止めるので、他の人の作業を巻き込みません。ブラウザのタブを閉じても処理はサーバ側で走り続けるので、止めたいときはこちらを使います。管理者権限で他人の処理を止める仕組みとは別物で、あくまで自分が動かした処理専用と考えておくのが安全です。
10. /nav_to.do?uri= で、枠付きの画面として開く
incident_list.do を直接叩くと、左メニューやヘッダのない素の画面が出ます。普段の見た目で開きたいときは、こう包みます。
https://<YourInstance>.service-now.com/nav_to.do?uri=incident_list.do条件付きの URL を人に渡すときは、この形にしておくと親切です。渡された側が、そこから普通に操作を続けられます。用例は URLナビゲーションの例（ServiceNow Docs） にもいくつか載っています。
uri= のうしろには、sysparm_query を含めた完全な URL をそのまま書けます。nav_to.do?uri=incident_list.do?sysparm_query=active=true のように、これまで紹介したパラメータと組み合わせても崩れません。素の画面のまま共有するか、枠付きで共有するかは、渡す相手が ServiceNow の操作に慣れているかどうかで選ぶとよいと考えられます。
覚えておくと便利な直行 URL
パラメータではありませんが、よく使う入口をまとめておきます。いずれも実機で開けることを確認しました。
sys_dictionary_list.do や sys_choice_list.do は、これまでのパラメータと組み合わせるとさらに強くなります。たとえば sys_dictionary_list.do?sysparm_query=name=incident^elementLIKEpriority のように書けば、sysparm_query の中でさらに LIKE を使い、incident テーブルの priority に関係する項目定義だけに絞り込めるという具合です。表を眺めるだけでなく、実際に組み合わせて試すと、パラメータ同士がどうつながるかが体感できます。
つまずきやすい点
ここまでのパラメータは、そのまま貼れば動くものがほとんどです。ただし、いくつか事前に知っておかないと「なぜか動かない」に当たる箇所があります。
URLエンコードが必要な文字
sysparm_query の値にスペースや ^、=、日本語などの記号・多バイト文字を含める場合は、URL エンコードが必要です。ブラウザのアドレスバーに直接入力するときはブラウザ側が自動でエンコードしてくれますが、リンクをスクリプトやメールの文面として組み立てるときは自分でエンコードしなければなりません。スペースは %20、^ を値として含めたい場合は %5E のように、JavaScript なら encodeURIComponent() に通してから URL に組み込みます。エンコードを忘れると、値の途中にある ^ や = が区切り文字として解釈され、意図と違う条件で開いてしまいます。
sysparm_query と sysparm_fixed_query の違い
sysparm_query は、開いたあとに画面上で条件を足したり外したりできます。一方の sysparm_fixed_query は、常に適用され続ける固定条件として働き、パンくずから取り除けません。モジュールのリンク先に固定条件を仕込んで「このモジュールでは常にこの絞り込みを外させない」という使い方をする場合に向いています。両者は同じ URL に併記でき、sysparm_fixed_query の条件と sysparm_query の条件は AND で重なります。
Next Experience Workspace では効かない
ここで紹介したパラメータは、incident_list.do のようなクラシックな一覧・レコード URL 向けです。Next Experience の Workspace 画面は /now/ から始まる別の URL 構造を使っており、リストの絞り込みも list-id や tiny-id といった識別子で管理されています。同じ sysparm_query を Workspace の URL に付け足しても、期待した絞り込みにはなりません。Workspace 側で条件を保存し、それを開き直す形が基本になります。
インスタンスがどちらの画面を主に使っているかは、URL を見れば判別できます。アドレスバーが .do で終わっていればクラシックな一覧・フォームで、この記事のパラメータがそのまま有効です。/now/ から始まっていれば Workspace で、絞り込みは画面側の保存機能に頼ることになります。両方が併存しているインスタンスも珍しくないので、リンクを渡す前にどちらの画面のURLかを確かめておくと、相手を迷わせずに済むはずです。
よくある質問
sysparm_query に日本語を含む条件を書くとき、注意することは
先に触れたとおり、URL エンコードが必要です。ブラウザに直接入力する分には自動でエンコードされるので気にせず打てますが、<a href> やスクリプトで URL を組み立てるときは encodeURIComponent() などで値部分だけをエンコードしてから連結します。sysparm_query= の右側全体をまとめてエンコードすると、区切り文字の ^ まで変換されてしまうので、値ごとに分けてエンコードするのが安全です。
この URL を他の人に送っても大丈夫ですか
条件付きの URL 自体は、開いた人の ACL（アクセス権限）を上書きしません。送った相手がそのテーブルを読む権限を持っていなければ、URL を踏んでも空の一覧か権限エラーになります。URL に条件を書くことと、権限を緩めることはまったく別の話だと考えておくと安心です。
保存フィルタと URL 直書きは、どちらを使うべきですか
繰り返し使う定番の絞り込みは、画面の Personalize > Filter で保存フィルタにしておくほうが、モジュール化されて再利用しやすくなります。URL に直書きするのは、その場限りの調査や外部ツール・チャットへのリンク共有、スクリプトからの自動アクセスなど、条件を都度組み替えたい場面に向いています。両方を排他で選ぶ必要はなく、保存フィルタを一度作ってから、その条件を Copy Query で URL 用に取り出す、という併用が実務では扱いやすいはずです。
sysparm_query が長くなりすぎたときは、どうすればよいですか
条件が増えるほど URL は長くなり、ブラウザや経由するプロキシによっては数千文字を超えたあたりで扱いにくくなることがあります。長大化してきたら、条件をいったん保存フィルタに落としてモジュール化するか、URL 直書きをやめて Table API（REST）の POST ベースの絞り込みに切り替えるのが現実的な対処です。
一覧の URL パラメータは UI16 でも Next Experience でも同じように使えますか
いいえ。ここで紹介したパラメータは .do で終わるクラシックな一覧・フォーム URL 向けのものです。Next Experience の Workspace では URL の構造自体が異なるため、そのままでは効きません。運用しているインスタンスがどちらの画面をメインにしているかで、使える範囲が変わる点に注意してください。
用語
sysparm_query … 一覧の絞り込み条件を1本の文字列で表すURLパラメータ。中身はエンコードクエリ文字列
エンコードクエリ文字列 … フィルタ条件を ^（AND）や ^OR などでつないだ、機械可読な条件の書式
Copy Query … 画面で組んだフィルタ条件を、エンコードクエリ文字列としてコピーする操作
sysparm_fixed_query … 常に適用され、画面上から外せない固定条件のパラメータ
sysparm_view … 表示するビュー（画面の見え方）を切り替えるパラメータ
sys_id … レコードを一意に識別する内部キー。既定のエクスポートには含まれない
ACL … テーブルやレコードへのアクセス権限を定義する仕組み。URL の条件では上書きされない
Next Experience Workspace … /now/ から始まる新しいUI体系。クラシックなURLパラメータの一部が効かない
検証範囲外のこと
?JSONv2 は実機で応答（2.5KB）を確認しました。仕様自体は JSONv2 web service（ServiceNow Docs） に載っていますが、認証方式や利用可否は環境設定に依存します
sysparm_userpref.〜 でユーザー設定を上書きする方法は、今回は確認していません
権限が足りない場合、これらの URL は権限エラーになるか、ログイン画面へ戻されます。管理者以外では結果が変わります
Next Experience Workspace 側の URL 構造（list-id / tiny-id など）そのものは、この記事の検証範囲外です
まとめ
条件は画面で組んで Copy Query でコピーする。これが一番早くて確実です。手で書くのは、コピーが使えない場面だけで足ります。エンコードが要る文字、フィックスドクエリとの違い、Workspace では効かないという3点さえ押さえておけば、URL 直書きの落とし穴はほぼ避けられます。
検索欄に打つだけの小ワザ、調査とデバッグ用の画面については、それぞれ別の記事にまとめています。無料の検証環境（PDI）をまだお持ちでない場合は、先に developer.servicenow.com のデベロッパーサイトで登録してから、この記事のURLを試してみてください。
