フィールドの「型」の正体（sys_glide_object）
ServiceNow でフィールドを作るとき、必ず「Type（型）」を選びます。String・Integer・True/False・Reference・Date/Time。この選択肢は、どこから来ているのでしょうか。実は、これらの型は sys_glide_object という1つのテーブルに、レコードとして並んでいます。画面上の名前は「Field classes（フィールドクラス）」です。
型は、コードの中に隠れているわけではありません。テーブルの行として、誰でも一覧で見られる形で置かれています。だから「このプラットフォームには、どんな型が、いくつあるのか」を、実機で数えられます。今回はその中身を開いて、型がどう定義され、辞書のどの欄とつながっているのかを確かめました。
型を理解すると、フィールド設計の見通しが良くなります。「Reference は内部で何を持っているのか」「Choice の実体は文字列なのか」といった疑問に、推測ではなく実測で答えられるようになる。データ設計の土台が、一段しっかりします。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-20）。本番環境では設定が異なります。
フィールドの「型」はどこに定義されているか
ServiceNow のあらゆるフィールドは、データ辞書（sys_dictionary）に1行ずつ登録されています。そのフィールドが文字列なのか数値なのか参照なのか、という「型」も、辞書エントリの1項目です。項目名は internal_type、画面上のラベルは「Type」。
この Type は自由記述ではありません。あらかじめ用意された型の一覧から、1つを選ぶ仕組みになっています。その一覧の正体が sys_glide_object です。つまり sys_glide_object は、プラットフォームが持つ全フィールド型の「カタログ」だと考えると分かりやすい。
カタログですから、中身は有限で、数えられます。実機で件数を取ると、ちょうど 160 件 ありました。String や Integer のような素朴なものから、Journal や Currency のような専用の型まで、160 種類がここに登録されています。フィールドを作るときは、この 160 件のどれかを必ず指し示している、というわけです。
sys_glide_object を開くと何が見えるか
実際に一覧を開くと、こう並んでいます。
列は Name / Label / Class name / Length / Extends / Visible の6つ。先頭には approval_rules・audio・auto_increment・boolean・breakdown_element などが並んでいます。一覧の総数は、ここでも 160 件でした。さきほど数えた型の総数と、当然ながら一致します。
1行ずつが1つの型です。たとえば boolean 行は、Label が「True/False」、Extends が「Boolean」。auto_increment 行は Extends が「Longint」。breakdown_element 行は、Class name に com.snc.pa.dc.GlideElementBreakdownElement という長いクラス名が入ります。Length は 32 です。名前だけの素朴な型もあれば、専用のクラスと長さを持つ型もある。この差が、型ごとの性格を表しています。
一覧の各列が何を意味するのか。ここを押さえると、型の正体がほどけていきます。次の節で1列ずつ確かめます。
型の正体は「名前・土台・実装クラス」の3層
型のレコードは、大きく3つの層でできています。
1層目は name です。これが型の内部名で、辞書の Type が指す値そのものです。string・integer・reference・glide_date_time といった、開発者がよく目にする名前が入ります。
2層目は Extends（scalar_type）です。その型が、DB の基本型のうちどれに乗っているかを表します。たとえば glide_date_time の Extends は「Date/Time」、currency の Extends は「Decimal」。多くの専用型は、素朴な基本型の上に作られています。
3層目は Class name です。挙動を担う Java の実装クラスです。glide_date_time なら GlideDateTime、html なら GlideHTML。ここが空の型は、基本型そのままの素朴な振る舞いをします。名前で呼ばれ、基本型の上に乗り、必要なら実装クラスで味付けされる。この3層が「型の正体」です。
Extends 列の意味：どの基本型に乗るか
「Extends（拡張）」という列名は、少し身構えます。でも意味はシンプルで、「この型は、どのDB基本型の上に成り立っているか」を示すだけです。フィールドの値は最終的に、データベースの列に保存されます。そのときの実体が、この Extends の型です。
実機で Extends（scalar_type）別に件数を数えると、こうなりました。
String … 119 件。
Integer … 10 件。
Date/Time … 9 件。
Sys ID … 7 件。
Float … 5 件。
Decimal … 4 件。
Date … 2 件。
Longint … 2 件。
Boolean … 1 件。
Time … 1 件。
合計はちょうど 160 件です。目を引くのは String の多さで、160 型のうち 119 型が String を土台にしています。Journal も Choice も HTML も URL も、DB の中では文字列として保存される。見た目や入力画面は型ごとに違っても、実体は文字列、というものが大半でした。専用型の多くは「文字列に、特別な入力補助と表示ルールを足したもの」だと捉えると腑に落ちます。
reference 型はなぜ「Sys ID」なのか
Extends が Sys ID の型は7件ありました。その代表が reference です。参照フィールドは、他のテーブルのレコードを指すために使います。画面では「Abel Tuter」のような名前が見えますが、DB が実際に保存しているのは、その人のレコードの sys_id（32桁の識別子）です。
だから reference の Extends は Sys ID になっています。実機で reference レコードの属性を見ると、encode_utf8=false という既定が付いていました。中身が sys_id という機械的な識別子なので、文字コード変換をしない、という設計です。画面の見た目は人間向けの表示名、DB の実体は sys_id。この二層構造を知っておくと、「参照フィールドをエクスポートしたら sys_id が並んで戸惑った」という場面でも慌てません。
char や breakdown_element も Extends が Sys ID で、Length は 32 でした。32 という長さは、sys_id の桁数そのものです。Sys ID を土台にする型は、この32桁を格納する箱として設計されている、と読み取れます。
この二層構造は、データ移行のときに効いてきます。あるインスタンスから別のインスタンスへレコードを移すとき、参照フィールドが指す相手も一緒に移せば、sys_id が保たれてリンクが切れません。逆に相手を先に用意しないまま参照だけ移すと、指し先を失った sys_id が宙に浮きます。参照フィールドの中身が表示名ではなく sys_id だと知っていれば、こうした移行の順番も自然と読めます。型の実体を理解することは、地味ですが移行の事故を減らす近道です。
辞書の「Type」欄が、このカタログを指している
型カタログと辞書のつながりを確かめます。辞書（sys_dictionary）の internal_type、つまり画面の「Type」欄は、ただの文字列ではありません。実機で internal_type フィールドの定義を確認すると、型は reference、参照先テーブルは sys_glide_object でした。ラベルは「Type」です。
言い換えると、辞書の1項目が「型」を選ぶという行為は、sys_glide_object の 160 件から1レコードを参照する、という参照関係そのものです。フィールドと型は、参照でつながっている。だから型の一覧を書き換えれば、選べる型が変わる。逆に、存在しない型名は選べません。
この関係が分かると、プラットフォームの見え方が変わります。「フィールドの型」は特別な組み込み概念に見えて、その実体はテーブル同士の参照でした。ServiceNow がいたるところで使う参照の仕組みが、ここでも使われているだけです。辞書というメタデータのテーブルが、型カタログというもう1つのテーブルを参照している。メタデータもまた、ふつうのデータとして扱われています。
どの型が一番使われているか（実測ランキング）
型カタログが 160 件あるとして、実際にはどれがよく使われているのか。辞書の全行を型別に集計しました。辞書の総行数は 152,748 行、そのうち使われている型は 156 種でした。160 種のうち、ほぼすべてが実際に使われています。
使用数の上位はこうでした。
string … 56,060。
reference … 25,556。
glide_date_time … 15,090。
integer … 12,023。
boolean … 11,308。
GUID … 6,258。
collection … 6,158。
choice … 1,829。
やはり string が突出して多い。次いで reference が多いのは、ServiceNow が「レコード同士をつなぐ」ことを重視する設計だからだと読めます。担当者・依頼者・CI・変更元。業務データの多くは、他のレコードへの参照で成り立っています。日時（glide_date_time）や真偽（boolean）が続くのも、業務システムらしい並びでした。ランキングを見るだけで、このプラットフォームが何を中心に組み立てられているかが透けて見えます。
ここで collection という見慣れない型が上位に入っている点にも触れておきます。これは個々のフィールドに付く型というより、テーブルそのものを表す辞書行に付く型でした。辞書には「このテーブルは何か」を表す行（element が空の行）があり、そこに collection が使われます。実機で数えると、collection の 6,158 行はすべて element が空の行、つまりテーブル定義の行でした。テーブルの登録数（約6,193）とほぼ一致します。だから collection の件数は、おおよそテーブルの数に近い値になります。型のランキングを眺めると、こうした「フィールド以外の使われ方」まで見えてきます。型は、単なる入力欄の種類にとどまらず、テーブル定義そのものにも顔を出しています。
代表的な型の早見表
よく使う型を、名前・ラベル・Extends・実装クラスで並べると、性格の違いが一目で分かります。
string や integer や boolean は、実装クラスを持たない素朴な型です。値をそのまま基本型に保存します。一方 glide_date_time や currency や html は、専用の実装クラスを持ちます。日時の計算、通貨の丸め、リッチテキストの整形。こうした「その型らしい振る舞い」を、実装クラスが担当します。reference が Sys ID を土台にすること、choice の実体が String であることも、この表を見れば迷いません。
型レコードの主要項目
型そのものを定義する sys_glide_object のレコードは、どんな項目でできているか。主要な項目を整理しました。
name は辞書が参照する内部名、label は画面表示名、scalar_type は一覧の Extends 列、scalar_length は既定の長さ。class_name が実装クラスで、attributes は既定の属性を持ちます。たとえば html の Length は 65536、currency の Length は 20。reference の attributes には encode_utf8=false。こうした細かな既定が、型ごとにあらかじめ決められています。フィールドを作るとき、私たちはこの既定を土台に、必要なら上書きしている、という関係です。
とくに Length の既定は、覚えておくと役立ちます。string を選んで長さを指定しなければ、既定の長さが使われます。ログのような長い本文を string の短い既定長に入れようとして、途中で切れて困る、という場面は珍しくありません。型ごとの既定長を一度眺めておくと、こうした取りこぼしを事前に避けられます。型の主要項目を知ることは、フィールド1つを丁寧に設計する力に直結します。
Visible：型ドロップダウンに出る56件
最後に Visible 列です。これは「新しいフィールドを作るときの Type ドロップダウンに、この型を出すかどうか」のスイッチでした。実機で数えると、visible=true は 56 件。残りの 104 件は非表示です。
つまり 160 の型がすべて選べるわけではありません。日常的に選べるのは 56 種で、残りは内部用途や特殊用途のために隠されています。approval_rules や auto_increment のような型が Visible=false なのは、人が手で選ぶものではなく、システムが内部で使う型だからです。「型は 160 あるのに、作成画面ではそんなに見かけない」という感覚のズレは、この Visible の仕組みで説明がつきます。
型カタログは書き換えられるのか
型がテーブルの1行なら、その行を編集して型を増やしたり変えたりできるのか。気になるところです。原則として、ここは触りません。sys_glide_object のレコードは OOTB（初期提供）のもので、プラットフォームの土台に直結します。うかつに書き換えると、影響が読み切れません。
実際、コミュニティでも「Field Class のレコードが編集できない」という質問が出ています。既定では保護が効いていて、簡単には変更させない作りになっている、ということです。これは安全側の設計だと受け取れます。型はデータ構造の根っこですから、誰でも自由に足したり消したりできると、プラットフォームの整合性が崩れかねません。
だから実務では、既存の 160 型から適切なものを選ぶ、というのが基本の姿勢になります。「専用の型が欲しい」と感じたときも、まずは近い既存型と属性（attributes）の組み合わせで表現できないかを考える。型そのものを増やす前に、既存の型でどこまで表せるかを確かめるほうが、後々の保守で楽になります。カタログを眺める意味は、ここにもあります。何が用意されているかを知っていれば、無理に新しい型を作らずに済む場面が多いからです。
まとめ
フィールドの「型」は、sys_glide_object（Field classes）というテーブルに、160 件のレコードとして並んでいました。各型は、内部名（name）・土台のDB基本型（Extends）・実装クラス（Class name）の3層でできています。160 型のうち 119 型が String を土台にし、reference は Sys ID を土台に sys_id を格納します。
そして辞書の「Type」欄は、この型カタログを指す参照でした。フィールドと型は、テーブル同士の参照でつながっている。実測では、辞書 152,748 行で 156 種の型が稼働し、作成画面に出る型は 56 件でした。型を「組み込みの魔法」ではなく「テーブルの1行」として見られるようになると、フィールド設計もデータ移行も、地に足のついた話として扱えます。
その他、実機で確認した記録
用語
sys_glide_object（Field classes） … フィールド型のカタログ。実測で160件。
internal_type（Type） … 辞書の型欄。sys_glide_object を指す参照フィールド。
scalar_type（Extends） … その型が乗るDBの基本型（String / Sys ID / Date/Time など）。
class_name … 型の挙動を担う実装Javaクラス（空なら基本型のまま）。
visible … 型ドロップダウンに出すか。true は56件。
調べるときの入口URL（先頭に自分のインスタンスを付ける）
/sys_glide_object_list.do?sysparm_query=ORDERBYname（型カタログの一覧）。
/sys_glide_object_list.do?sysparm_query=visible=true（作成画面に出る56件）。
/sys_dictionary_list.do?sysparm_query=element=internal_type（型を指す辞書項目の定義）。
実測の要点（再掲）
sys_glide_object は160件。Extends別で String が119件と最多。
辞書の internal_type は sys_glide_object への参照（ラベル「Type」）。
辞書152,748行のうち156種の型が使用中。上位は string / reference / glide_date_time。
reference の Extends は Sys ID。DBには sys_id（32桁）を格納。
visible=true は56件（作成時の型ドロップダウンに出る）。
検証範囲とおことわり
件数・型の分布・参照関係・使用数上位は PDI（Zurich / OOTB）の REST 実測です。
実装クラスの内部挙動そのものはコード非公開のため、構造の確認までにとどめます。
型ドロップダウンから新規フィールドを作る操作は行っていません（読み取りのみ）。
型はプラグイン構成で増減しうるため、本番の件数は環境ごとに確認してください。
