はじめに：テーブル拡張は「便利」だけど、設計ミスが長く残る
ServiceNowで新しい業務データを持ちたいとき、真っ先に候補に上がるのが「既存テーブルの拡張（継承）」です。親テーブルの項目や挙動を引き継げるので、開発スピードが上がりやすい一方で、一度作った継承構造は運用・改修・アップグレードまで影響が広がりやすいのが特徴です。
特にCSAを目指して学習していると、Task・Incident・CMDBなど「親子テーブル」「クラス（class）」「sys_class_name」の話が頻繁に出てきます。暗記で乗り切るより、なぜそう動くのかを腹落ちさせたほうが、実務でも試験でも迷いが減ります。
この記事では、Zurich環境を前提に、公式ドキュメントの考え方を踏まえながら、テーブル拡張で起きやすい事故と回避策を「チェックリスト」として整理します。
（Table Builderの存在も含め、Zurichの“今の作り方”に寄せて書きます。）
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
テーブル拡張の基本を押さえる：親子テーブルとsys_class_nameがすべての起点
まず「拡張（extends）」は、ServiceNowではクラスの継承として扱われます。拡張する側が子（child class）、される側が親（parent class）。親もさらに別の親を持てます。
ここで重要なのが sys_class_name です。拡張可能なテーブルでは、このフィールドが「このレコードの実体がどの子テーブルなのか」を示します。たとえばTaskを親にしてIncidentやChangeがぶら下がっているなら、同じ“親の器”の中に、子クラスごとのレコードが混在する、というイメージになります。
ありがちな誤解：テーブルが増える＝DBテーブルも増える、とは限らない
継承モデルによって、保存のされ方が変わる点も見落としやすいです。ServiceNowには“テーブルごとに物理分割する”だけではない考え方があります（例：テーブル階層に応じたモデル）。この前提があるので、「子を作ったから性能が悪化する／しない」を短絡的に判断しないのが安全です。
CSA視点でのポイント
- 親子テーブルの関係は、ACL評価、レポート、検索、スクリプト条件（GlideRecord）に影響します
- sys_class_nameの意味を理解していると、**“同じ見た目の条件なのに結果が違う”**系の混乱が減ります
まず悩むのが「何を親にするか」：拡張の判断基準
テーブル拡張の設計でいちばん大事なのは、実は「フィールドを追加すること」よりも、親テーブルの選び方です。ここを間違えると、後から「運用ルール」「権限」「レポート」「自動処理」が全部噛み合わなくなります。
判断基準チェックリスト
親を選ぶ前に、次を言語化しておくのがおすすめです。
- このデータは“何の仲間”か？
例：作業の流れ（状態管理・割当・SLA）が必要ならTask系、構成アイテムの分類ならCMDB系、単なるマスタなら独立テーブル、など。 - 親の標準フィールドや標準ロジックを“使いたい”のか、“避けたい”のか？
親を選ぶ＝親の作法を採用する、ということです。 - 将来の拡張（子→孫）も見込むか？
「あとで似たデータを増やす」可能性があるなら、最初から“ベースクラス”を意識したほうが設計が安定します。
Taskを親にするときの注意
Taskは便利ですが、便利＝重い責務を背負っているでもあります。状態（state）、割当（assignment）、履歴、通知、レポート前提…など、影響範囲が広い。
だからこそ、
- “チケット運用（作業管理）”に寄せたいならTask拡張は強い
- “単にデータを保管したいだけ”ならTask拡張は過剰
という判断が必要になります。
ここで「なんとなくTaskに寄せる」と、後で「不要な項目が多い」「権限が複雑」「レポートが混ざる」など、地味に効くストレスが積み上がります。
辞書設計の落とし穴：継承フィールド、Dictionary Override、属性の扱い
拡張テーブルは親のフィールドを引き継ぎますが、現場でハマりやすいのが「辞書（Dictionary）の上書き」です。
Dictionary Overrideは“便利”だけど、万能ではない
拡張した子テーブルだけ挙動を変えたいときに使うのがDictionary Overrideです。親のフィールド定義を壊さずに、子だけ別設定にできる、という発想。
ただし、ここは注意点があります。
- 上書きできるもの／できないものがある
- “上書きできないのに、できると思い込んで時間を溶かす” が起きやすい
例としてよく話題になるのが「Unique（ユニーク制約）」です。継承フィールドを“子だけユニークにしたい”要件は現場にありますが、簡単に辞書上書きだけで終わらないケースが出ます（要件整理や代替策が必要になりがち）。
Dictionary Attributesの付け方で運用が変わる
辞書属性（Dictionary attributes）は地味ですが、運用に直撃します。たとえばテーブル側の属性として、親テーブルに「このテーブル自体に直接レコードを作らず、子に作る」前提を示すものがあります（例：extensions_only）。
この手の属性を理解していないと、
- 「親テーブルに直接入ってくるレコードを想定していなかった」
- 「フィルタやレポートが親に吸われて見づらい」
のような“設計ミスの連鎖”が起きやすいです。
具体例：子だけ入力必須にしたい、はどこでやる？
初心者が混乱しがちな問いです。
- 辞書でMandatoryにする（継承元に影響する？）
- Dictionary Overrideで子だけMandatoryにする
- UIポリシーやクライアントスクリプトで画面上だけ必須にする
ここは「何を保証したいか」で分けるのが安全です。
DBレベルでの整合性を持たせたいのか／画面入力だけを制御したいのか。この考え方ができると、試験でも実務でも迷いにくくなります。
実務で事故りやすい領域：ACL、レポート、参照、条件、スクリプト
テーブル拡張の事故は、作った直後より運用が回り始めてから出ます。代表例をまとめます。
ACL：親で許可したら子も全部OK、とは限らない
拡張テーブルは親子関係があるので、「親に権限があれば安心」と考えたくなりますが、実際にはテーブル・フィールド・条件・ロールの組み合わせで評価され、想定外の拒否や想定外の許可が起きえます。
特にZurichの各アプリでも「新しいテーブルが既存テーブルを拡張するので、適切なACL設定が必要」と明記されることがあります。拡張＝権限の再点検、はセットで覚えておくのが安全です。
チェックポイント
- 子テーブル固有フィールドのACLを忘れていないか
- 親のフィールドを子で“見せ方だけ”変えて、権限設計がズレていないか
- テーブルACLとフィールドACLの両方で整合しているか
レポート・リスト：親テーブルで見ると“混ざる”
親でレポートを作ると、子のデータが混在します。便利でもありますが、意図せず混ざると分析が壊れます。
このとき、sys_class_nameを条件に使う／INSTANCEOFで範囲を切る、といった考え方が役に立ちます。
参照（Reference）と選択肢（Choice）の地味な落とし穴
拡張テーブルでは、参照先や選択肢の設計が「親子のどこにぶら下がっているか」で挙動が変わります。
- Choiceは「Configure Choices」で管理できるが、標準の業務ロジックに影響しうるので変更は慎重に
- “従属フィールド（dependent）”の設定は、親子で意図しない表示になりうる（設定箇所と対象テーブルを明確に）
このあたりは、暗記よりも「どのテーブルの辞書を触っているのか」を常に意識するのが近道です。
Zurichで安全に進める実装手順：Table Builder＋アップグレード耐性の作り方
Zurichでは、テーブル作成や管理をより視覚的に扱えるTable Builderが用意されています。とはいえ、UIが楽になっても「設計で決めるべきこと」は減りません。
ここでは、拡張テーブルを“後戻りしない”ための進め方を、手順というより考える順番としてまとめます。
設計の順番
データの目的 → 親の選定 → 権限の方針 → 辞書とUI → 自動化 の順に考えます。
- データの目的：チケットか、マスタか、構成情報か
- 親の選定：引き継ぎたい標準フィールドとロジックを列挙して判断
- 権限の方針：誰が作成・参照・更新できるか（子固有も含む）
- 辞書とUI：必須、表示、参照、選択肢、依存関係
- 自動化：Flow/BR/通知は“どのテーブルをトリガにするか”を明確化
アップグレード耐性：標準を壊さず、差分を小さく
Zurichのリリースノートでも、プラットフォーム全体としてアップグレードの考え方が整理されています。カスタマイズは悪ではありませんが、標準の拡張点・設定で表現できるものは、まずそれを優先したほうが運用が安定します。
特にテーブル拡張は「標準テーブルに直接手を入れる」誘惑が出やすいので、次を意識すると安全です。
- 標準フィールドの変更は最小化（本当に必要か再確認）
- 可能なら子テーブル側に閉じる（辞書上書き・UI・自動化の配置）
- 参照先や選択肢は、標準の前提を崩さない（変更理由を残す）
学習者向け：理解を固めるUdemy活用のすすめ
テーブル拡張は、画面だけ追っていると“わかった気”になりやすい分野です。体系的に、
- 親子テーブルとsys_class_name
- 辞書とDictionary Override
- ACL評価の考え方
を一周できる教材で学ぶと、点が線でつながりやすくなります。
Udemyには、CSA学習者向けにプラットフォーム基礎（テーブル・辞書・権限・自動化）を流れで扱う講座もあります。公式ドキュメントを読みながら、「操作→なぜそうなる？」を補助する位置づけで使うと、理解が安定します（講座は“体系的に学べる教材の一例”としての選択肢です）。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ：テーブル拡張は「親の選び方」と「辞書・権限の整合」が勝負
Zurichでテーブル拡張を安全に進めるコツは、派手なテクニックよりも、基本を丁寧に踏むことです。
- 拡張はクラス継承。sys_class_nameが挙動の起点になる
- 親テーブルの選定で、運用の難易度がほぼ決まる
- Dictionary Overrideや辞書属性は便利だが、万能ではない（上書きの限界を意識）
- ACLとレポートは、拡張した瞬間に影響範囲が広がる（拡張＝再点検）
- Table Builderで作りやすくなっても、設計の順番は変わらない
もし今「どの親にするか」で迷っているなら、まずは “そのデータは何の仲間か” を言語化して、引き継ぎたい標準機能をリストにしてください。そこが決まると、辞書や権限の設計が一気にブレにくくなります。
