ServiceNow Service Portalはどこを直せば画面が変わる？ 構成7テーブルを実機で追う
ポータルの画面を直したいとき、sp_portal・sp_page・sp_widgetのどれを開けば変わるのか、最初は見当がつきません。ServiceNowのポータルは7つのテーブルが入れ子になっていて、直したい対象によって触るテーブルが変わります。Zurich PDIで9ポータル・483件の配置・295件の定義を実機で数えました。
検証環境：Zurich PDI / OOTB / 2026-08-08 確認
結論：画面のどこを直せば何が変わるか
先に全体像です。
ポータル画面は7つのテーブルが入れ子になって1画面を作ります（下図）。上から下へ件数が増え、9→119→209→260→411→483→295と広がります。
「配置」と「定義」は別物です。画面に置かれた1枠がsp_instance（配置）、その枠が呼び出すロジックがsp_widget（定義）。同じ定義を何度も使い回す設計です。
帯や幅などレイアウトを直すならsp_container・sp_row・sp_column、部品の並びや増減ならsp_instance、部品の中身の挙動を直すならsp_widget。ポータルの入口や404ページの差し替えはsp_portalです。
sp_portalを起点に、page・container・row・columnと入れ子が進み、最後にinstance（配置）とwidget（定義）が対になります。instanceからwidgetへ向かう矢印が実線と点線の2本あるのは、1つの定義を複数の配置が呼び出す関係を表した部分です。
上の画面は/spのトップです。検索窓もタイルも「My Open Incidents」の一覧も、すべて1個ずつのウィジェット配置でできています。1枚のHTMLファイルではなく、部品を積み上げた構造です。
この入れ子構造を知っておく実務上の利点は、修正の見積もりが立てやすくなることです。依頼の言葉から触るテーブルがほぼ機械的に決まります。「検索窓の文言を変えたい」なら1個のsp_widgetの中身です。「タイルを1つ増やしたい」ならsp_instanceを1件追加します。「全体の余白を詰めたい」ならsp_container・sp_row・sp_columnのスタイルを調整します。
7テーブルの役割と件数は上の表のとおりです。portal→page→container→row→column→instance→widgetの順に辿ると、1つのポータルが最終的に483個のウィジェット配置に分解される流れが見えます。
ポータルの入口はここ：sp_portal（9件）
sp_portalはURLの入口を定義するテーブルです。9件登録されていました。
/spがService Portal、/escがEmployee Center、/kbがKnowledge Portalというように、URL suffixがそのままアドレスになります。残る6件は、/mesp・/perf・/swp・/cab・/benchmarks・/sp_configでした。正式なタイトルは、/mespがMobile Employee Service Portal、/perfがPerformance Analyzerです。/swpはService Workspace Portal、/cabはCAB Workbenchです。/benchmarksはBenchmarks、/sp_configはSP Configurationとなっています。用途はモバイル向け・パフォーマンス分析・ワークスペース・CAB会議・ベンチマーク・ポータル設定とそれぞれ専用で、1ポータル1目的に近い作りです。ここで設定できるのは、ホームページ・ログインページ・404ページ・テーマといった、ポータル全体に効く項目です。
フォームを開くと、Homepage・KB home page・Login page・404 pageのように、どのページを何用に使うかを紐付ける項目が並びます。ポータルを丸ごと差し替えたい、ログイン後の遷移先を変えたいという要望は、このテーブルの担当になります。
ポータルの中にページがある：sp_page（119件）
1つのポータルは複数のページを持ちます。sp_pageは119件でした。
404・approval・cab_workbenchのように、IDがそのままURLの一部になります。Package列を見ると、由来は1つではありません。Service Portal - Coreだけでなく、複数のアプリがそれぞれ自分のページを持ち込んでいました。例えばChange Management - CAB Workbench・Benchmark Clientなどです。ほかにもService Portal Announcements・Subscriptions and Activity Feed Frameworkが見つかりました。ポータルの画面は、Service Portal本体だけでなく他のアプリからも積み増される仕組みです。ページ単体では画面は完成しません。ページの中に帯（コンテナ）を置き、その中に部品を並べて初めて1つの画面になります。
ページを帯で区切る：sp_container（209件）
sp_containerはページを横方向の帯に区切るテーブルです。209件ありました。
同じページに複数のコンテナが並び、Order列で表示順が決まります。Widthの大半はFixedでした。名前の付け方にも特徴があります。「Kiosk Topic」のように、1つの機能が複数のコンテナ（Container 1〜3）に分かれている例がありました。Parent classにbreadcrumbs-containerのような値を持つ例もありました。ページの上から下へどんな帯を積むかは、このテーブルで決まる仕組みです。
帯の中の行と列：sp_row・sp_column
コンテナの中は、さらにsp_row（行）とsp_column（列）で区切られます。sp_rowが260件、sp_columnが411件でした。
列にはグリッドレイアウトの考え方で幅の比率が設定されます。横に3つ並べたい、スマホでは縦に積みたいといった調整は、この2テーブルの領域です。sp_container・sp_row・sp_columnの3つは入れ物の形を決めるテーブルで、中身そのものは持ちません。件数がcontainer 209・row 260・column 411と段階的に増える形からも、1つの帯が複数の行に、1つの行が複数の列に枝分かれしていく構造が読み取れます。
実際に画面に出ているのは配置：sp_instance（483件）
列の中に置かれる1個1個の部品がsp_instanceです。483件ありました。7テーブルの中で、いちばん現場に近い場所です。
ウィジェット別にグループ化すると、どの部品が何回使われているかが一目で分かります。breadcrumbsが45件、Quick Linksが50件というように、配置回数がそのまま画面に出ます。
上位を数えると、Quick Links 50・breadcrumbs 45・Typeahead Search 32の3つだけで127配置。483配置のおよそ26%です。少数の部品を使い回して画面を組み立てている実態が、この表から読み取れます。
件数どうしを割ってみると、画面の密度も見えてきます。483配置を119ページで割ると、1ページあたりおよそ4個。411列を260行で割ると、1行あたり1.6列ほどになります。1ページに部品がぎっしり並ぶ構成は少数派で、1段に1〜2列を置いた素直な構成が多数派でした。この平均値は、自分でページを新しく作るときの目安になります。凝った段組みは例外的な扱いでした。
実機で気づいたこと：配置と定義はまったく別の数字だった
sp_instance（配置）とsp_widget（定義）は、最初は近い数字になるだろうと思っていました。実際に確認すると、483件の配置で使われている定義の種類は162種類にとどまり、sp_widgetに登録された295件のうち133個は一度も配置されていませんでした。
定義だけ作られて画面には置かれていない部品が、全体の半分近く眠っている計算になります。過去のカスタマイズやバージョンアップで使われなくなった部品が、削除されずに残っているのだと考えられます。
もう1つ考えられる理由は、今回の環境が素のPDIだという点です。OOTBのウィジェットには、CAB WorkbenchやBenchmarksのような特定ポータル専用の部品も含まれます。そうした部品は、そのポータルを実際に使い込んでいない環境では配置数が伸びません。133個という数字を見て「無駄が多い」と決めつける前に、自分の環境でどのポータルを使っているかを確認したほうがよさそうです。
もう1つ意外だったのが、1回しか配置されていない定義が98種類もあった点です。配置済みの162種類のうち、6割は「1箇所でしか使われていない専用部品」でした。上位3つが127配置を占める一方で、大半の部品はほぼ1対1で特定の画面に紐付いています。
障害調査でウィジェットの表示がおかしいとき、自分ならまずこのグループ化画面を開きます。配置回数が多い部品なら影響範囲は広く、1回しか使われていない部品なら影響は1ページの中だけです。この違いは、画面を開いた瞬間に判断できます。数字は嘘をつきません。
配置される中身の定義：sp_widget（295件）
配置が呼び出す実体がsp_widgetです。295件登録されていました。
Nameが部品の名前、Packageがどのアプリに由来するかを示します。Employee Center由来、Service Portal - Core由来など、出どころが混在しているのが分かります。
編集フォームを開くと、4つの欄が並びます。見た目を作るBody HTML template、装飾を担うCSS、サーバー側で値を用意するServer script、画面の動きを作るClient controllerです。部品の見た目や挙動そのものを直したいときは、このテーブル側が担当します。
公開設定も合わせて見ておく価値があります。public=trueが95件、rolesが未設定のものが234件でした。ロールで絞り込まず誰でも読めるウィジェットのほうが、実測では多いことになります。
テーマ・CSSなど周辺のテーブルも実測した
7つの主要テーブルの外側にも、画面の見た目に関わるテーブルがあります。件数は、テーマ（sp_theme）17件・CSS（sp_css）54件でした。ヘッダー・フッター（sp_header_footer）は10件、Angular Provider（sp_angular_provider）は80件でした。
テーマはポータル単位で1つ選ぶ設定、CSSはテーマに追加で当てる部品です。sp_portalの一覧で見たCoralやLa Jollaといったテーマ名は、このsp_themeテーブルの1レコードを指しています。配色やフォントだけを変えたいなら、sp_widgetまで踏み込まずテーマかCSSの追加で足りることが多いはずです。
実務では何に使えるか：直したいものから逆算する
「画面のどこかを直したい」という依頼が来たとき、自分は上の表の順で当たりを付けます。
Webのレイアウト崩れを調べるとき、ブラウザの開発者ツールでDOMツリーを1段ずつ辿る作業に感覚は近いです。画面全体からいきなり原因を探すより、ポータル→ページ→コンテナ→行→列→配置→定義という順に1段ずつ絞り込むほうが早く辿り着けます。範囲を狭めてから読む。これに尽きます。
見た目の帯や幅を変えたいならsp_container・sp_row・sp_column。部品の並び順や増減ならsp_instance。部品そのものの表示内容や動作を直すならsp_widget。ポータルの入口・ログイン後の遷移・404ページならsp_portalです。この4分類さえ押さえておけば、いきなりスクリプトを読みに行かずに済みます。
同じ部品が複数画面で使われている場合は注意が要ります。sp_widgetを直接編集すると、その定義を使っている全配置に変更が及びます。1箇所だけ直したいなら、公式のClone a widgetの手順にあるとおり、複製してから編集する方法が安全です。
依頼を受けてから当たりを付けるまでの流れを手順にすると、次の4段になります。
どの見た目が対象かを確認する。帯全体か、部品1個かを切り分ける
部品1個の変更なら/sp_instance_list.doをウィジェット別にグループ化し、対象の配置回数を確認する
配置回数が2件以上なら、他画面への影響を先に洗い出す
影響範囲が固まってから、sp_widget（中身）かsp_instance（配置）のどちらを編集するかを決める
この順番を守ると、いきなり本体のsp_widgetを書き換えて他画面まで巻き込む事故を避けられます。
さらに詳しく知りたい人へ
ポータル1画面は複数テーブルの組み合わせ（sp_portal） — sp_portalの設定項目を詳しく見る前提知識
Service Portal（/sp）のトップは16個の部品でできている（sp_instance） — /spのトップ1画面をsp_instance単位で読む実例
既定ポータル Employee Center（/esc）はカタログを持たない：導線はタクソノミーが作る — 別ポータルでの導線の作られ方
よくある質問
Q1. sp_instanceとsp_widgetの違いが分かりません
sp_instanceは「どの列にどの部品を置くか」という配置の記録、sp_widgetは「その部品が何をするか」という定義そのものです。1つの定義を複数の配置から呼び出せるので、件数は一致しません。483配置に対して定義295件、実際に使われた定義は162種類でした。イメージとしては、sp_widgetが「関数の定義」、sp_instanceが「その関数を呼び出している箇所」に近い関係です。
Q2. どのテーブルから見始めればいいですか
画面を変えたい理由によって変わります。レイアウトの帯や幅ならsp_container、部品の増減ならsp_instance、部品の中身ならsp_widgetです。まず配置一覧をウィジェット別にグループ化して開くと、対象の部品が何回使われているかがすぐ分かります。
Q3. 一度も配置されていない133個の定義は削除してよいですか
配置が無いからといって、すぐ消してよいとは限りません。将来の配置に備えて残している定義や、他のアプリからスクリプトで呼び出されている定義が混ざっている可能性があります。削除する前に、参照元が本当に無いかを確認する手順が要ります。特にOOTBの部品は、自分たちが使っていないポータル（CAB WorkbenchやBenchmarksなど）専用に用意されているだけのことも多く、機能そのものが不要とは限りません。
Q4. Quick Linksやbreadcrumbsのような標準部品を直接編集してよいですか
直接編集すると、その定義を使っている全配置に変更が及びます。breadcrumbsのように45件で使われている部品を書き換えると、影響範囲が広がります。特定の画面だけ変えたいなら、複製してから編集するほうが安全です。
Q5. sp_rowとsp_columnは何が違いますか
sp_rowはコンテナの中の1段、sp_columnはその段を横に割った1マスです。sp_rowが260件、sp_columnが411件あり、1行に複数の列がある構成が多いことが件数差から読み取れます。
Q6. public=trueとrolesの設定は何が違いますか
publicはログイン前でも表示できるかどうかのスイッチ、rolesはログイン後にどのロールなら表示できるかの絞り込みです。public=trueが295件中95件、rolesを何も設定していない部品が234件でした。両方とも制限が緩い部品のほうが多く、表示制御の大半は置き場所であるページやポータル側のアクセス権で決まっていると考えられます。
まとめ
ServiceNowのポータル画面は、結論の図で示した7段のテーブルが入れ子になってできています。件数は9→119→209→260→411→483→295でした。
画面を直すときに大事なのは、配置(sp_instance)と定義(sp_widget)を分けて考えることです。483件の配置のうち実際に使われている定義は162種類、133個の定義は一度も配置されていませんでした。少数の部品（Quick Links・breadcrumbs・Typeahead Search）が全体の約26%を占め、残りの多くは1回しか使われていない専用部品でした。
直したい対象がレイアウトなのか、部品の並びなのか、部品の中身なのかを先に切り分ければ、7つのテーブルのどこを開くべきかは自然に決まります。テーマ・CSS・Angular Providerといった周辺テーブルも含めれば、ポータルの見た目と挙動はほぼすべてテーブルの中に収まっている状態でした。答えは、構造そのものの中にありました。
この対応関係は、チームに引き継ぐときにも使えます。「見た目を変えたいならこのテーブル」という言い方をするだけで、初めてポータルを触るメンバーでも迷わず該当テーブルにたどり着けるはずです。
用語
sp_portal … ポータルの入口。URL suffix・ホームページ・テーマなどを持つ
sp_page … ポータル内の1画面。IDがURLの一部になる
sp_container … ページを横方向に区切る帯
sp_row / sp_column … コンテナの中の行と列。レイアウトの格子を作る
sp_instance … 列に置かれた部品1個の配置記録
sp_widget … 部品の定義そのもの。Body HTML template・CSS・Server script・Client controllerを持つ
実機で調べるときに開いたURL
/sp_portal_list.do … ポータル一覧
/sp_page_list.do … ページ一覧
/sp_container_list.do … コンテナ一覧
/sp_instance_list.do?sysparm_query=GROUPBYsp_widget … 配置をウィジェット別に集計
/sp_widget_list.do … ウィジェット定義一覧
参考リンク
公式ドキュメントの中でも、ポータルの構造と運用に直結するものをまとめました。
検証環境と未検証範囲
件数・画面はZurich PDI（OOTB）で2026-08-08に確認したものです。一覧画面の件数表示と実レコードを突き合わせて数えており、推定やサンプリングではありません。本番環境やカスタマイズ済みの環境では数値が異なります。
各ウィジェットのServer script・Client controllerの中身までは読んでいません。名前・件数・公開設定までの確認にとどまります。sp_rectangleは件数を確認できなかったため、今回は扱っていません。ウィジェットのロール設定が実際の表示にどう効くかも、設定値の確認のみで、表示テストは行っていません。Employee Centerのタクソノミー由来の導線は別記事で扱っています。Next Experience・Workspace系UIとの関係も、今回は検証範囲の外に置いています。
