レコード採番（sys_number）：INC番号の決まり方

2026年6月27日 09:29

ServiceNow を触っていると、レコードに必ず「番号」がついていることに気づきます。インシデントは INC0010001、変更は CHG0030024、カタログ申請は REQ や RITM といった具合です。この番号、誰がどうやって決めているのでしょうか。実はテーブルごとの採番ルールを1か所にまとめて持っているテーブルがあり、それが sys_number（Number Maintenance）です。

この記事は、ServiceNow の各レコードの番号が「どこで」「どんなルールで」作られるのかを確認したい管理者・開発者を想定しています。PDI（Zurich / OOTB）で sys_number を実際に開き、実機の数値で順に確認します。確認するのは、接頭辞（prefix）・次の番号（number）・桁数（maximum_digits） の3つで番号が組み立てられること、採番が テーブル単位 で定義されること、そして task を継承するテーブルの番号がどこで決まるかです。

この記事で分かること

レコード番号は sys_number の1行＝1テーブルの採番ルールから作られること
番号は prefix ＋ number をゼロ埋めして maximum_digits 桁にした文字列（例: INC＋7桁＝INC0000060）であること
採番ルールは category（→ sys_db_object）でテーブルに結びつく＝テーブル単位で定義されること
PDI 実機の sys_number は 144行あり、incident=INC・change_request=CHG・problem=PRB とそれぞれ自分の採番ルールを持つこと
桁数は既定7だが一律ではなく、テーブルによって 8・10 などに変わること
自分の採番ルールを持たない task 派生テーブルは、親（task）にさかのぼって TASK で採番されること

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、接頭辞・桁数・対象テーブルが異なる場合があります。

レコード番号はどこで決まるのか

ServiceNow のレコード番号は、レコード本体（incident など）に直接ルールが書かれているわけではありません。テーブルごとの採番ルールを集めた sys_number という1枚のテーブルが、「このテーブルにはこの接頭辞・この桁数で番号を振る」という設定を1行ずつ持っています。下の実画面は、incident の採番ルールを1件開いたものです。

このレコードは、Table（category）に Incident、Prefix に INC、Number of digits に 7 が入っています。つまり「incident テーブルのレコードには INC で始まる7桁の番号を振る」というルールです。番号のルールを CI 本体ではなく採番専用のテーブルに集約しているのが、この設計のポイントです。

PDI（Zurich / OOTB）の sys_number には、すでに 144件の採番ルールが入っていました。

sys_number はどんなテーブルか

sys_number の固有フィールドは、実機の辞書で確認すると 5つだけでした。中心になるのは次の4つです。

category（Table）… sys_db_object（テーブル定義）への参照。どのテーブルに採番するかを指す。
prefix（Prefix）… 番号の接頭辞。INC・CHG・PRB など。
number（Number）… 「次に振る番号」。レコードが1件できるたびに増える。
maximum_digits（Number of digits）… ゼロ埋めの桁数。既定は 7。

category は sys_db_object を参照しています。つまり、採番ルールは「テーブル単位」で結びついています。フィールドの一覧と既定値は次の表のとおりです。

辞書の実画面でも、固有フィールドが category / prefix / number / maximum_digits に絞られていることが確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_number^elementISNOTEMPTY

番号はどう組み立てられるか

では実際の番号はどう作られるのでしょうか。ルールはとてもシンプルで、prefix と、number をゼロ埋めして maximum_digits 桁にした文字列をつなげるだけです。

incident なら prefix=INC・桁数=7 なので、番号が60番目なら INC + 0000060 = INC0000060 になります。実際に PDI の incident レコードを開くと、番号は INC0000060 や INC0009002 のように、確かに INC ＋ 7桁で並んでいました。

number フィールドは「次に振る番号」を保持していて、レコードを作るたびに増えていきます。incident の sys_number では number=10000 でした。桁数は既定の7が多いものの、一律ではありません。実機では maximum_digits が 8（Scan Result=SR、Execution=EXE など）や 10（PLCEXEC）になっているテーブルもありました。代表的なテーブルの採番ルールを並べると次のとおりです。

INC・CHG・PRB・REQ・RITM・SCTASK といった見慣れた接頭辞が、すべて sys_number の1行ずつに対応しています。一覧は次のURLで確認できます。

https://<YourInstance>/sys_number_list.do?sysparm_query=ORDERBYcategory

task を継承するテーブルの番号はどこで決まるか

ServiceNow の incident / change_request / problem は、いずれも task テーブルを継承する「task 系」です。ここで疑問になるのが、「task 系の番号は task でまとめて振られるのか、テーブルごとに振られるのか」という点です。

実機で確認すると、incident・change_request・problem・problem_task・change_task・sc_req_item・sc_task は、それぞれ自分用の sys_number 行を持っていました。だから INC / CHG / PRB / PTASK / CTASK / RITM / SCTASK と、テーブルごとに違う接頭辞で採番されます。task 自身にも sys_number があり、こちらは prefix=TASK です。

では task の TASK 接頭辞はいつ使われるのでしょうか。それは、自分用の sys_number を持たない task 派生テーブルのときです。ServiceNow の採番は「そのテーブルに sys_number があればそれを使い、無ければ継承元（親）をさかのぼって最初に見つかった sys_number を使う」という階層フォールバックで決まります。実機で task テーブルの番号が TASK で始まるレコードを引くと、専用の採番ルールを持たない cert_follow_on_task（Follow On Task） のレコードが TASK0001001・TASK0001002… と並んでいました。

つまり cert_follow_on_task は自分の番号を持たないため、親である task の TASK 採番を継承しているわけです。採番の組み立てと、この継承フォールバックを整理すると次のとおりです。

別のテーブルでも仕組みは同じで、たとえば change_request の採番ルールを開くと prefix=CHG、桁数=7 になっています。

実機で確認するときに見るべきURL

最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

# 採番ルールの一覧（テーブル順）
https://<YourInstance>/sys_number_list.do?sysparm_query=ORDERBYcategory

# incident の採番ルール
https://<YourInstance>/sys_number.do?sys_id=3

# sys_number のフィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_number^elementISNOTEMPTY

採番ルールの考え方は ServiceNow 公式の Number maintenance（Zurich）でも説明されています。

まとめ

レコード番号は sys_number の1行＝1テーブルの採番ルールから作られる。
番号は prefix ＋ number をゼロ埋めして maximum_digits 桁にした文字列（例: INC0000060）。number は「次に振る番号」で作成のたびに増える。
採番ルールは category（→ sys_db_object）でテーブルに結びつく。incident=INC・change_request=CHG・problem=PRB のように、各テーブルが自分の sys_number を持つ。
桁数は既定 7 だが一律ではなく、テーブルによって 8・10 などに変わる（PDI 実機の sys_number は 144件）。
自分の採番ルールを持たない task 派生テーブルは、親（task）へさかのぼって TASK で採番される（実機では cert_follow_on_task が TASK0001001… で並んだ）。

レコード採番が分かると、テーブルとフィールド（sys_db_object / sys_dictionary）・Incident テーブルの task 継承・Service Catalog の3階層（REQ / RITM / SCTASK）・選択肢（sys_choice）といったプラットフォームの基礎が、「テーブル・継承・番号」という形でひとつにつながって見えてきます。

ServiceNowのデータはどこに溜まっていつ消える？添付・履歴・ログ・アーカイブを実機で確認 — 採番ルールもsys_numberという1テーブルに溜まるデータ。添付・履歴・ログの溜まり方と合わせて読むと、プラットフォーム全体のデータの置き場所がつながる。