Service Portal（/sp）のトップは16個の部品でできている（sp_instance）

2026年7月12日 08:14

ServiceNow を触っていると、利用者（社員やエンドユーザー）が申請やナレッジ検索に使う「ポータル画面」が何種類か出てきます。この記事では、そのうち従来からある標準のセルフサービスポータル、URL でいうと /sp で開く Service Portal を扱います。PDI（個人用の検証インスタンス）の初期状態で開き、設定値・デザイン・メニュー・ウィジェット、そしてウィジェットが持つスクリプトや依存まで、REST と実画面で読み解きます。

この記事だけを見れば、/sp を「設定・開発できる」レベルまで、どのレコードのどのフィールドが何を決めているかを順に把握できることを目標にしたリファレンスです。テーブル同士のつながり方（sp_portal → sp_page → sp_widget の参照構造）そのものは別記事に譲り、本記事は「どの設定が画面のどこに効くか」に焦点を当てます。

確認した環境：ServiceNow PDI（Personal Developer Instance）／ Zurich（ズーリッヒ）リリース／ OOTB（初期設定のまま）／確認日 2026-07-11。本番環境やカスタマイズ済みの環境では、見た目・メニュー・表示される項目が異なる場合があります。ここに書いた数値・状態は、このPDIで実際に見えた・REST で読み取れたものだけを記載しています。

このポータルは何か

Service Portal は、ServiceNow の利用者向け画面を提供する仕組みの一つです。ポータルの定義は sp_portal というテーブルに入っています。今回のPDIでは Service Portal のほかに、Employee Center や Knowledge Portal など複数のポータルが登録されていました。

その中で /sp の Service Portal は、従来型の標準セルフサービスポータルにあたります。default は false でした。このPDIで既定（利用者が最初に案内される想定）のポータルは Service Portal ではなく Employee Center のほうでした。つまり /sp の Service Portal は、既定ではないものの併存している位置づけになります。

ポータルは1枚のHTMLではなく、複数テーブルのレコードの組み合わせでできています。その内部構造はポータル1画面は複数テーブルの組み合わせ（sp_portal）で扱っています。本記事はその構造を前提に、/sp に実際に入っている設定値を1項目ずつ並べます。

見た目

実際に /sp を開くと、次の画面が表示されました。

この画面は、赤いバナー・ヘッダ・ヒーローの検索ボックス・3つの導線・6枚の情報パネルで構成されていました。

上部の赤バナーには「Employee Center is available to you（Employee Center が使えます）」という案内が出ていました。これは新しいポータルへの誘導で、Service Portal 自体の機能ではありません。

ヘッダは、左に servicenow ロゴ、右寄りに Knowledge・Catalog・Requests・System Status・Cart（カートのアイコン）・Tours が並びます。そこにログインユーザー（このPDIでは System Administrator）の表示が続きます。ヘッダの並びはテーマ（Coral）とメニュー定義で決まっていました。

中央のヒーロー部分は、淡いグラデーションの背景に大きく「How can we help?」と検索ボックスを置いています。Service Portal を代表する部分で、利用者はまずここから検索します。

ヒーローの下には、次の3つの入口が横並びになっていました。

Request Something … カタログを見て、必要なサービスや物品を申請する
Knowledge Base … 記事を検索・閲覧し、評価やフィードバックを送る
Get Help … サポートに連絡して依頼や問題報告をする

さらに下は、いくつかの情報パネル（ウィジェット）が段組みで並びます。見えたのは Current Status（障害報告なし）、My Assessments and Surveys（対象なし）、My Approvals（保留なし）です。さらに Announcements（Employee Center の案内）、My Open Incidents（自分の起票中インシデント）、Top Rated Articles（高評価ナレッジ）も並んでいました。

My Open Incidents には、このPDIの実データとして次の2件が表示されていました。

INC0010021「担当割り当て運用の実機確認用のインシデント」
INC0010020「メールサーバに接続できない（SLA運用の実機確認）」

いずれも別の検証で作ったレコードです。ログインユーザーに紐づく実データが、そのままウィジェットに出てくることの確認材料になります。件数や内容はこのPDI固有のもので、環境によって変わります。

ポータルの基本設定

/sp の見た目と挙動を決めているのは sp_portal レコードの設定値です。REST で読み取った全項目を、意味とあわせて並べます。

押さえどころは次の6点です。

入口とページ差し替え：homepage（最初に開くページ）、login_page（未ログイン時）、notfound_page（404）。いずれも別々の sp_page を指します。ページを丸ごと差し替えたいときはここを変えます。
カタログとナレッジ：sc_catalog＝Service Catalog、kb_knowledge_base＝IT。カタログやナレッジを別のものに切り替えたいなら、この2つが対応します。kb_knowledge_page＝kb_view2 は、ナレッジ記事を表示するページの指定です。
見た目：theme＝Coral が配色・ヘッダ/フッタの枠を担い、dark_theme は未設定でした。css_variables にはこのポータル単位で上書きする SCSS 変数（$grid-gutter-width: 15px !default;）が入っていました。ここは次章でテーマ側とあわせて詳しく見ます。
検索：enable_ais＝true（AI Search を使う）。search_application＝Service Portal Default Search Application、search_results_configuration＝Service Portal Search。検索の対象と結果表示はこの3つで決まります。
メニュー：sp_rectangle_menu＝SP Header Menu。ヘッダのメインメニュー定義への参照で、後半で中身を読みます。
その他：enable_favorites＝false（お気に入り無効）、rtl_enabled＝true（右横書き対応）、hide_portal_name＝false。sc_catalog_page / sc_category_page は未設定で、カタログ側は既定のページにフォールバックします。

表で「未設定」と書いた項目は、REST で空だったものです。空でも動くのは、ServiceNow 側が既定のページや挙動にフォールバックするためで、明示的に指定したいときにだけ値を入れる、という位置づけになります。

画面遷移：/sp からどこへ行けるか

/sp の Service Portal は、sp_portal の設定とヘッダメニューを通じて、いくつものページへ枝分かれします。どの設定・どのメニューから、どのページへ到達するかを一枚にまとめました。

読み方は次のとおりです。

ポータル本体（sp_portal）が直接指すページは3つ。homepage＝index（ホーム）、login_page＝landing（ログイン）、notfound_page＝404（Not Found）です。
それ以外の遷移先は、ヘッダの sp_rectangle_menu（SP Header Menu）から枝分かれします。Knowledge はナレッジ表示ページ（kb_view2）へ、Catalog はサービスカタログへ向かいます。Requests は申請状況ページ（my_requests）、My Favorites はお気に入りページ（favorites_list）が行き先です。
ホーム（index）自身も、ヒーローの検索と3導線からナレッジ・カタログへ利用者を送ります（図の点線）。

Service Portal のページ遷移は、URL でいうと /sp?id=<ページのid> という形をとります。たとえばホームは /sp?id=index、ナレッジは /sp?id=kb_view2 です。この id が sp_page レコードの識別子で、ポータル設定やメニューは「どの id のページを開くか」を指定している、という関係になります。

デザイン設定の詳細

前章で theme＝Coral・css_variables・logo・icon・dark_theme といった見た目まわりの項目が出てきました。ここでは Coral テーマ本体（sp_theme）まで踏み込み、/sp の外観を決めている値を並べます。

Coral テーマの固定挙動とヘッダ

Coral テーマは、navbar_fixed＝true・footer_fixed＝true を持っていました。ヘッダ（ナビバー）を画面上部に、フッタを下部に固定する設定で、スクロールしてもヘッダが追従する挙動につながります。使うヘッダ定義は header＝Stock Header、フッタ定義（footer）は未設定でテーマ既定のままでした。matching_now_experience_theme は Coral で、Next Experience（プラットフォーム標準UI）側のテーマと対応づけられていました。

css_variables は二層で効く

配色や余白を上書きする css_variables（SCSS 変数）は、テーマ側とポータル側の二層に分かれていました。テーマ側（sp_theme）の css_variables には、$gray-base から始まる now-color トークンの SCSS が入っていました。sp-rgb(--now-color--neutral-16, #1D272B ) のような色定義です。ここが配色トークンの土台です。一方でポータル側（sp_portal）の css_variables は $grid-gutter-width: 15px !default; の1行だけ。このポータルに限ってグリッドの余白を調整する上書きでした。共通の配色はテーマで、ポータル固有の微調整はポータルで、という住み分けが読み取れます。

logo・icon・dark_theme

ヘッダ左の logo とブラウザタブの icon は、いずれも画像レコード（*.iix）が設定されていました。dark_theme は未設定で、ダーク表示への切り替えは持っていません。配色を変えたいなら theme（Coral）、ダーク対応を足したいなら dark_theme を見ます。余白などをこのポータルだけ調整したいなら css_variables です。テーマそのものの作り方（sp_theme レコードやカスタム CSS の当て方）は公式ドキュメントの手順に沿うのが確実です。

ヘッダーメニューなどの設定

ヘッダに並ぶメニューは sp_rectangle_menu（SP Header Menu）で定義され、各項目は sp_rectangle_menu_item に入っています。ラベル・リンク種別・遷移先・並び順・表示条件を、order 順に読み取りました。

type（リンク種別）は、そのメニューが何につながるかを表します。Knowledge はナレッジベース、Catalog はサービスカタログへ直接つながります。Requests と My Favorites は特定のページ、Approvals はスクリプトで生成される一覧（Scripted List）、System Status は URL へのリンクでした。ここから、Service Portal が「ナレッジ」「カタログ」「申請状況」を主要な導線として組み立てられていることが読み取れます。

表示条件（condition）にも触れておきます。多くの項目は GlideSPScriptable.canSeePage(...) を条件に持っていました。これは「そのユーザーが遷移先ページを見られるか」を判定するサーバ側の関数で、ページの public / roles 設定に照らして表示可否を返します。Approvals の条件は gs.isLoggedIn()（ログイン中のみ）でした。My Favorites は $sp.getValue('enable_favorites')（お気に入り機能が有効なポータルのときだけ）が条件です。enable_favorites はこのPDIでは false なので、My Favorites は条件的に表示対象から外れます。

メニュー定義は6項目ありましたが、実際に上部バーへ見えていたのは Knowledge・Catalog・Requests・System Status でした（加えて Cart・Tours）。Approvals・My Favorites が出ていなかった理由は2つ考えられます。いま見た表示条件（Approvals はログイン状態、My Favorites は enable_favorites=false）と、レスポンシブでの折りたたみです。厳密な判定はこのPDIの見た目だけでは確定できず、検証範囲外とします。

ビジネスルール・スクリプト等の周辺機能

ウィジェットは「置いてある部品」であると同時に、内部にサーバ／クライアントのスクリプトを抱えた小さなアプリでもあります。ここでは、ホームに載っていたウィジェット本体（sp_widget）が持つコードと依存を、重複を除いた12種で並べます。

ウィジェットが持つコード

ほとんどのウィジェットは server ／ client ／ option_schema ／ css ／ html を一通り備えていました。server はサーバスクリプト、client はクライアントスクリプト、option_schema はオプション定義です。差が出たのは主に link と一部の欠落です。

link（Link function） を持っていたのは Homepage Search と Typeahead Search の2つだけでした。link は DOM を直接触るための関数で、検索ボックスまわりのウィジェットだけが必要としていた形です。
client を持たないのは Homepage Search・KB News・KB Top Rated。サーバ側でHTMLを組み立てて出すだけの、表示寄りのウィジェットです。
KB News はさらに css を持たず、server・option_schema・html の最小構成でした。

サーバスクリプトの中で使われるのが、前章の condition にも出た GlideSPScriptable（$sp）というサーバ側APIです。ページ情報の取得やウィジェットの埋め込みなどを担い、ウィジェットからテーブルのデータを読むときの入口になります。個々のスクリプトの中身（どのGlideRecordを回しているか等）は、今回は本体の有無までの確認にとどめ、検証範囲外とします。

option_schema でウィジェットに設定欄を持たせる

option_schema は、そのウィジェットに「配置ごとに変えられる設定欄」を持たせる定義です。表のとおり12種すべてが option_schema を持っていました。3導線の Icon Link は、同じ本体のまま Request Something / Knowledge Base / Get Help と違うタイトル・違うリンク先で置けました。option_schema で配置ごとの値（タイトルやアイコン、リンク先）を受け取れるからです。ウィジェットを1つ作れば、配置を変えるだけで複数の使い方に展開できる、という Service Portal の再利用性がここに現れています。

依存（sp_dependency）と Angular Provider / Template

ウィジェットは、追加のライブラリを依存（sp_dependency）として宣言できます。今回の12種のうち依存を持っていたのは2つでした。

My Surveys … RetinaIconsCSS（高解像度アイコン用のCSS）
Announcements … angular-ellipsis（長い文章を省略表示する Angular ディレクティブ）

依存は、そのウィジェットが描画されるときに一緒に読み込まれる CSS / JS をまとめる宣言で、ウィジェット単位で必要なものだけを足せる点が特徴です。関連して、クライアント側で共通ロジックを再利用したいときは Angular Provider（sp_angular_provider）に切り出せます。繰り返し使うHTML断片は Angular ng-template（sp_ng_template）が受け皿です。今回のホーム16配置ではこの2つを直接持つウィジェットは対象に含まれていませんでしたが、ウィジェットを自作・拡張するときの受け皿として押さえておくと、コードの置き場所に迷いにくくなります。

開発者の勘所・まとめ・検証範囲

開発者の勘所

/sp を設定・開発するときに、押さえておくと迷いにくい点を並べます。

ページ遷移は ?id=<page> 形式。ポータル設定やメニューが指しているのは sp_page の id です。index / landing / 404 / kb_view2 / my_requests / favorites_list などが入ります。URL を組み立てるときも /sp?id=... になります。
見た目はテーマとポータルの二層。共通の配色は sp_theme の css_variables（now-color トークン）です。このポータル限定の微調整は sp_portal の css_variables に入ります。ヘッダ固定などの挙動はテーマ側（navbar_fixed など）が持ちます。
ウィジェットはインスタンスとして配置される。同じ本体を、option_schema を通じて配置ごとに別のタイトル・別のオプションで何度でも置けます（Icon Link ×3、Simple List ×2 がその例）。
公開範囲は public / roles で決まる。未ログインのトップに出せるもの（Homepage Search・Login など）は public=true でした。ログインやロールが要るもの（My Surveys・Typeahead Search など）は public=false です。
周辺コードは本体に同梱。server / client / link / option_schema と、必要なら依存（sp_dependency）・Angular Provider・ng-template。ウィジェット1つがどこまで抱えているかは、この表の粒度で見当がつきます。

まとめ

今回の確認で分かったことは次のとおりです。

/sp の Service Portal は、sp_portal に登録された従来型の標準セルフサービスポータル。このPDIでは default=false で、既定は Employee Center でした。theme=Coral、homepage=index、login_page=landing、notfound_page=404 です。
デザインは Coral テーマが担います。navbar_fixed / footer_fixed=true・header=Stock Header・matching_now_experience_theme=Coral でした。css_variables はテーマ側（now-color トークン）とポータル側（grid-gutter-width）の二層。dark_theme は未設定でした。
ヘッダメニュー（SP Header Menu）は6項目です。Knowledge / Catalog / Requests / Approvals / System Status / My Favorites が並びます。type・遷移先・order・condition まで定義され、表示は canSeePage / isLoggedIn / enable_favorites などの条件で制御されていました。
ホーム（index）は16配置のウィジェットで構成され、Simple List にはログインユーザー基準の実データ（INC0010021・INC0010020）が出ました。ウィジェット本体は、ほぼ全てが server / client / option_schema / css / html を備えていました。依存を持つのは My Surveys（RetinaIconsCSS）と Announcements（angular-ellipsis）だけです。

用語

sp_portal / sp_page / sp_widget：ポータル・ページ・ウィジェットの定義テーブル。ポータルがページを、ページ（の配置）がウィジェットを参照します。
sp_instance：ウィジェットの「配置」。同じ sp_widget を複数の配置で使い回せます。
sp_theme：配色やヘッダ固定などの見た目を束ねるテーマ定義。
GlideSPScriptable（$sp）：ウィジェットのサーバスクリプトから使う、ページ情報取得などのサーバ側API。
option_schema / sp_dependency / sp_angular_provider / sp_ng_template：ウィジェットの設定欄・依存ライブラリ・共通プロバイダ・共通HTML断片の置き場所。

ServiceNow Service Portalはどこを直せば画面が変わる？構成7テーブルを実機で追う — 本記事の16配置の土台になっているsp_portalの構造を、7テーブルで俯瞰できます

検証範囲とおことわり

撮影・確認はすべて System Administrator（管理者）ログインでの見た目です。ロールやライセンスが異なる一般ユーザーでは、表示されるメニュー・ウィジェット・件数が変わる可能性があります。
メニュー6項目のうち一部が上部バーに見えていなかった理由（表示条件・ロール・レスポンシブ折りたたみ）の厳密な切り分けはしていません。
ウィジェットが持つコードは「有無」までの確認です。個々のスクリプトの中身、実行時の描画順、テーマの SCSS コンパイル結果、Employee Center 側の詳細は本記事の範囲外です。
各ウィジェットの description は今回対象分がすべて空でした。役割は名称と実描画からの読み取りで、公式の説明文ではありません。
数値・状態はこのPDIの実測値であり、環境によって異なります。

自分の環境で確認するときのURL

ServiceNow 公式ドキュメント：Service Portal（Zurich）
ServiceNow 公式ドキュメント：Configuring Service Portal（Zurich）
ServiceNow 公式ドキュメント：Create a portal theme（Zurich）
ServiceNow 公式ドキュメント：Configure a portal header menu（Zurich）
ServiceNow 公式ドキュメント：Service Portal configuration page widgets（Zurich）
ServiceNow 公式ドキュメント：Service Portal widgets（Using portal widgets）（Zurich）
ServiceNow 公式ドキュメント：Clone a widget（Zurich）
ServiceNow 公式ドキュメント：Reuse components with Angular Providers（Zurich）
ServiceNow 公式ドキュメント：Enable and configure AI Search in Service Portal（Zurich）
ServiceNow 公式ドキュメント：Theming for AI Search in Service Portal（Zurich）
ServiceNow 公式API リファレンス：GlideSPScriptable（Scoped）（Zurich）

Service Portal を内部のテーブル（sp_portal → sp_page → sp_widget）の観点から見たい場合は、ポータル1画面は複数テーブルの組み合わせ（sp_portal）で、ポータル・ページ・ウィジェットのつながりを整理しています。