/sp_config のホームはウィジェット1個：6枚のカードは中で描かれている

2026年7月12日 08:18

ServiceNow のポータルというと、社員が申請やナレッジ検索に使う「セルフサービス画面」を思い浮かべる方が多いと思います。ですが、同じポータルの仕組み（sp_portal）の上には、利用者向けではないポータルも載っています。

その一つが SP Configuration（/sp_config） です。これは利用者が開く画面ではなく、ほかのポータルを設計・構築するための管理者用ツールの入口にあたります。

この記事は /sp_config の開発者向けリファレンスです。PDI（個人用の検証インスタンス）の初期状態で実際に開きます。sp_portal の全設定・テーマ・上部メニュー・6カード・ホームのウィジェット・裏側で動くコードまでを、REST と実画面で読み解きます。前半で「開くと何が出て、どういう画面なのか」を押さえ、後半で「その見た目を裏で決めている設定値・テーマ・ウィジェットの周辺機能」を実測ベースで並べます。この記事だけを見れば /sp_config を『読み解ける』レベルまで把握できる、というのがゴールです。各エディタ（Branding Editor / Designer など）を開いた先の実際の編集操作そのものは範囲を分け、末尾で公式ドキュメントへ案内します。

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

このポータルは何か

/sp_config はエンドユーザーが日常的に開く画面ではありません。ロゴや配色を変えたり、ページに部品を並べたり、新しいポータルを作ったりする、管理者・開発者向けの設計ツールの入口です。

登録としては、ほかのポータルと同じく sp_portal テーブルの1レコードにすぎません。REST で定義を読むと、url_suffix は sp_config でした。つまり /sp_config でアクセスします。default は false で、この環境の既定ポータルは Employee Center です。homepage は sp_config_homepage、theme は La Jolla でした。特別なシステム画面という扱いではなく、あくまで「1つのポータル」として登録されています。

これはセルフサービス画面ではなく、ポータルを作る側の管理者・開発者が使う画面です。Employee Center（/esc）や Service Portal（/sp）とは、設定値の中身が明確に違いました。カタログもナレッジも紐づかず、AI Search も無効です。「申請・検索の入口」を構成する要素が、そもそも設定されていません。同じ sp_portal のレコードでありながら、値の入れ方で性格がまったく変わる、という例になっています。

見方を変えると、/sp_config はポータルの仕組み（sp_portal / sp_page / sp_widget など）を編集するための画面です。それらを1つのポータルとしてまとめてあります。

用語メモ

sp_portal … ポータル（入口）の定義テーブル。url_suffix や homepage、theme を持つ。/sp_config もこのテーブルの1レコードです。
sp_page … ポータル内の1ページの定義。id（index / login など）で識別され、URL は ?id=<id> で開きます。
sp_widget … 再利用可能な部品。HTML / CSS / Server / Client スクリプトを1レコードに持ちます。
sp_instance … ウィジェットをページのどこに、どのオプションで置くかという「配置」の情報です。
sp_admin … Service Portal の管理者ロール。/sp_config の上部メニューはこのロールを表示条件にしていました。

ポータルは1枚のHTMLではなく、複数テーブルのレコードの組み合わせでできています。この内部構造はポータル1画面は複数テーブルの組み合わせ（sp_portal）で扱っています。本記事はその枠組みを前提に、/sp_config の設定値・テーマ・ウィジェットと、それぞれがどの編集対象につながるかを並べます。

見た目：ホームは編集入口のカード集

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

この画面の中身は、上部メニュー・見出しの一文・6枚のカードの3つでした。

上部メニュー：ヘッダに Branding Editor・Designer・Portals・Pages・Widgets・Portal Tables・Tours が並びます。使う側ポータルの Knowledge / Catalog といった利用導線ではなく、すべてエディタ用の入口です。
見出しの一文：本文の先頭に「Service Portal — Create rich, engaging and modern experiences」とあります。この画面がポータルの見た目や中身を作るための場所だと示す一文です。
6枚のカード：本文に Branding Editor・Designer・Page Editor・Widget Editor・New Portal・Get Help の6カードが並びます。利用者向けポータルにある検索ボックスやカタログ導線、お知らせウィジェットの類はありません。

/sp_config の入口は「一覧」でも「検索」でもなく、編集入口のカード集です。利用者が手続きを進める画面ではなく、作り手がどのエディタに入るかを選ぶ画面になっています。後述のとおり、この6カードは1つのウィジェットが内部で描いたものでした。

基本設定：セルフサービス要素は空

ここからがリファレンス部分です。/sp_config の性格を決めているのは sp_portal レコードの設定値です。REST で読み取った項目（空欄のフィールドは省略）を、意味とあわせて並べます。

押さえどころは次のとおりです。

入口とページ：homepage＝sp_config_homepage（最初に開く設定ツールのホーム）、login_page＝login（未ログイン時）。使う側の /sp が homepage＝index、login_page＝landing を指すのと同じ仕組みで、指す先だけが管理ツール用のページになっています。ページを丸ごと差し替えたいときはここを変えます。
見た目：theme＝La Jolla。ロゴ（logo）とアイコン（icon）は画像レコード（*.iix）への参照でした。hide_portal_name は false です。テーマの中身は次節のデザイン設定で掘り下げます。
メニュー：sp_rectangle_menu＝SP Config Menu。使う側ポータルのヘッダナビにあたる位置に、エディタ用のメニューが入っています。

使う側ポータルとの設定差（enable_ais=false・カタログ/KB未設定）

/sp_config の設定では、利用者向けポータルが持っている項目が軒並み無効か未設定でした。

enable_ais＝false（AI Search を使わない）。使う側の /sp は true でした。検索を主役に置くポータルではない、という差がそのまま出ています。
sc_catalog / kb_knowledge_base などのカタログ・ナレッジ参照は未設定（空欄）でした。申請やナレッジ検索の導線を持たないためです。
enable_favorites＝false、rtl_enabled＝false、enable_embeddables＝false。お気に入り・右横書き・埋め込みといった、エンドユーザー体験まわりの機能はいずれも無効でした。

表で「未設定」と書いた項目は、REST で空だったものです。空でも動くのは、ServiceNow 側が既定の挙動へフォールバックするためで、明示したいときにだけ値を入れる位置づけになります。つまり /sp_config は、利用者向けの機能を積むのではなく、編集画面をまとめることに振り切った sp_portal だと読めます。

画面遷移：6カードは何を編集する入口か

/sp_config は、sp_portal の設定を通じて数ページへ枝分かれし、ホームの6カードと上部メニューは、最終的に3つの編集対象テーブルへ集約されます。どの設定・どのカードが、どのページ・どのテーブルへ到達するかを一枚にまとめました。

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

ポータル本体（sp_portal）が直接指すページは2つです。homepage＝sp_config_homepage（設定ツールのホーム）と、login_page＝login（ログイン）です。加えて sp_rectangle_menu＝SP Config Menu が上部メニューの定義を担います。
ホーム（sp_config_homepage）は、Service Portal Config Overview という1つのウィジェットで描かれています。6枚のカードは、この単一ウィジェットが内部で描いた見た目です。
各カードと上部メニューの行き先は、最終的に3つの編集対象テーブルに集約されます。ポータルの入口・見た目は sp_portal、ページの配置やプロパティは sp_page、部品本体は sp_widget です。この「入口 → 編集対象テーブル」の対応が、/sp_config を読むうえでの軸になります。

Service Portal 系のページ遷移は、URL でいうと /sp_config?id=<ページのid> の形をとります。上部メニューの Portals は ?id=portal_edit、Pages は ?id=page_edit、Widgets は ?id=widget_editor を開きます。メニュー項目は「どの id のページを開くか」を指定しているわけです。

6カードと上部メニューの入口一覧

上部メニューと6カードが、それぞれ何を編集する入口なのかを、REST で読んだメニュー定義（sp_rectangle_menu_item）と突き合わせて表にしました。

6カードの役割分担を補足します。

Branding Editor … ロゴや配色といった、ポータル全体の見た目を変える画面です。編集対象は sp_portal（と sp_theme）にあたります。メニュー定義では遷移先が branding_editor ページで、公式ドキュメントでも「ポータルのホームページの要素や、ポータル全体に効く色を設定する」ツールとして説明されています。
Designer … ページに部品（ウィジェット）を配置してレイアウトを組む画面（Service Portal Designer）です。編集対象は sp_page とその配置（sp_instance）です。メニューの Designer は $spd.do を開きます。
Page Editor … 個々のページ（sp_page）のプロパティ（ID・タイトル・公開範囲など）を編集する入口です。
Widget Editor … 部品本体（sp_widget）を作成・編集する画面です。ウィジェットは HTML / CSS / Server / Client スクリプトを1レコードに持つ再利用部品で、その中身を編集します。
New Portal … 新しいポータル（sp_portal の新規レコード）を作る導線です。
Get Help … ドキュメントやヘルプへの導線で、これだけは編集対象を持ちません。

上部メニューの Portals / Pages / Widgets / Portal Tables は、それぞれ該当テーブルの一覧に入る入口です。カードが「作る・編集する」入口だとすれば、こちらは「一覧から探して開く」入口にあたります。この上部メニューの表示条件は次々節で掘り下げます。

デザイン設定の詳細（La Jolla テーマ）

/sp_config の見た目を担っているのは、sp_portal の theme が指す La Jolla（sp_theme の1レコード）です。設定表の1行で終わらせず、テーマ側の項目を REST で開いて中身を並べます。

読みどころは次の3点です。

ヘッダは標準・固定：header＝Stock Header で、ヘッダは標準ヘッダウィジェットを流用しています。navbar_fixed＝true なのでスクロールしてもヘッダが上部に貼り付きます。footer_fixed＝true でフッター位置も固定する指定でしたが、footer 自体は未設定でフッターウィジェットは持ちません。
配色は SCSS 変数で決まる：css_variables の中身を読むと、先頭は // Grays $gray-base: #000000 から始まるグレースケール定義でした。$gray-dark / $gray-darker / $gray-light / $gray-lighter を lighten() で派生させる形です。配色を変えたいときに触るのは、ポータル設定ではなくこのテーマの変数側になります。なお portal 側の css_variables（ポータル個別の上書き）は空で、テーマの変数がそのまま効く状態でした。
ダーク非対応・Now Experience 未連携：dark_theme は未設定、matching_now_experience_theme も未設定でした。ダークモードや Next Experience テーマとの対応づけは、このPDIの初期状態では入っていません。logo と icon はどちらも紐づいており、ヘッダのロゴとブラウザタブのアイコンに使われます。

テーマの各 SCSS 変数が最終的にどの要素へ効くか（コンパイル後のCSS）や、css_variables の全量は今回の読み取りの範囲外です。ここでは「先頭がグレースケール定義から始まる SCSS 変数群」という外形と、dark_theme 未設定・Now Experience 未連携という対応関係を実測しました。

ヘッダメニュー等の設定（上部メニュー8定義・sp_admin ロール防御）

上部メニューは sp_rectangle_menu（SP Config Menu）で定義され、各項目は sp_rectangle_menu_item に入ります。order 順に読み取ると、定義項目は Branding Editor から Table List まで8つあり、うち実際に表示されるのは6つでした。先ほどの入口一覧表（tbl-02）の上部メニュー行が、この8定義にあたります。

表示の可否まで制御されていた点が読みどころです。

Branding Editor / Designer / Portals は、いずれも表示条件が gs.hasRole("sp_admin") でした。Pages / Widgets / Portal Tables も同じ条件です。Service Portal 管理者ロールを持つユーザーにだけ見える設計です。編集入口そのものがロールで守られているため、sp_admin を持たないユーザーには設計ツールの導線が見えません。
一方で Themes（?id=sp_theme）と Table List（?id=lf）は、条件が false に固定されており、既定では上部バーに出ません。定義としては存在するものの、初期状態では非表示という位置づけです。メニュー定義の項目数（8）と、実際に見える数（6）はここでずれます。
画面上部に見えていた Tours は、このメニュー定義（sp_rectangle_menu_item）には含まれておらず、テーマ側が提供する共通要素と読めます。

つまり /sp_config の入口は、「ロールで見せる/隠す」ことと「定義はあるが既定で非表示」ことの2段構えで制御されていました。上部メニューの項目を足し引きしたいときは、この SP Config Menu が指す sp_rectangle_menu_item を編集します。表示条件（gs.hasRole("sp_admin") など）もそこで決めます。

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

見た目の裏側で動くコードへ進みます。/sp_config の周辺機能は、ほぼホームを描く Service Portal Config Overview ウィジェットの内部処理に集約されます。このウィジェットがどんな公開範囲とコードを持つかを実測しました。

公開範囲：public＝false で、未ログインでは表示されません。roles は空で、部品自体に特定ロールへの制限はなく、ログインすれば表示される設定でした。ただし、各エディタへの導線（上部メニュー）は前節のとおり gs.hasRole("sp_admin") で守られています。部品は見えても編集入口はロールで制御される、という二重構造です。
保持するコード：server（サーバスクリプト）・css・html を持ちます。CAB Workbench のカレンダーのような client / options は持たず、サーバ側で6カードの一覧を組み立て、HTML テンプレートで描画する構成と読めます。Service Portal のウィジェットでは、サーバスクリプトが data を介してクライアントへ値を渡します。この仕組みは GlideSPScriptable 系のサーバ API を使う作りが一般的です。必要に応じて Script Include も呼び出します。この Config Overview も server と html を軸にした作りでした。
依存（dependencies）：なしでした。Service Portal の依存レコードは、Angular の Provider や Template・追加の JS/CSS を束ねる仕組みです。このウィジェットは追加の依存を読み込まず、自身の server / css / html だけで完結していました。カレンダーのような外部部品を必要としない、一覧描画だけの作りだからだと読み取れます。

サーバスクリプトが具体的にどのテーブルへどんなクエリを投げるか、6カードの生成ロジック、参照する Script Include の中身までは今回の読み取りの範囲外です。ここでは「public/roles・保持するコードの種類（server/css/html）・依存の有無（なし）」という外形を実測した、という整理にとどめます。/sp_config にはこの管理ホーム部品以外の独自ビジネスルールは今回確認しておらず、周辺機能はこの1ウィジェットに集約されていました。

開発者の勘所とまとめ

扱う対象の規模と各エディタの対応

この管理ツールが相手にする対象が、この環境にどれくらいあるのかを件数で見ておきます。各エディタが何を編集するかとあわせて整理しました。

REST で件数を数えると、sp_portal が9件、sp_page が116件、sp_widget が290件でした。ポータル9件は、この記事シリーズで1つずつ見ている対象そのものです。ページ116件は9ポータルが平均して十数ページを抱える規模感を示し、ウィジェット290件は同じ部品が複数ページで使い回されるためページ数を上回ります。1つのポータルの裏に多数のページや部品がぶら下がる構造なので、こうした専用の設計ツールがまとめ役として用意されている、と読めます。

開発者の勘所

/sp_config を「ポータルを作る側」から使うときに、迷いにくくなるポイントを挙げます。

入口は編集対象テーブルで見分ける。カードもメニューも、最終的には sp_portal / sp_page / sp_widget のどれを触るかで整理できます。見た目を変えたいなら sp_portal（Branding Editor）です。ページの並びを変えたいなら sp_page（Designer / Page Editor）、部品の中身を変えたいなら sp_widget（Widget Editor）を触ります。
配色はテーマの SCSS 変数。管理ホームの見た目は theme（La Jolla）の css_variables が決めています。ダーク対応を足すなら dark_theme（このPDIは未設定）に別テーマを割り当てる形です。
管理ホームは単一ウィジェットで組まれている。カードを直したいときにページ上の配置を探しても見つかりません。ホームを描く実体は Service Portal Config Overview の1部品（public=false・roles空・server/css/html・依存なし）です。
メニューはロールで守られている。上部メニューの主要項目は gs.hasRole("sp_admin") が条件でした。sp_admin を持たないユーザーには編集入口が見えない設計です。
定義があっても非表示の項目がある。Themes と Table List は条件 false で初期非表示でした。メニュー定義の項目数（8）と、実際に見える数（6）はずれます。

各テーブルがどう参照でつながって1画面になるかという構造そのものは、ポータル1画面は複数テーブルの組み合わせ（sp_portal）で扱っています。その構造は sp_portal → sp_page → レイアウト → sp_widget という流れです。そちらでは参照フィールドの向きや件数まで見ています。「どのテーブルのどのレコードを直すか」を突き詰めたいときはそちらが土台になります。

まとめ

/sp_config（SP Configuration）は、利用者向けではなく、ポータルを設計・構築する管理者向けツールの入口でした。登録上はほかのポータルと同じ sp_portal の1レコード（url_suffix=sp_config / default=false）ですが、性格がまったく違います。
sp_portal の設定は homepage=sp_config_homepage / login_page=login です。theme=La Jolla / sp_rectangle_menu=SP Config Menu でした。enable_ais・enable_favorites・rtl_enabled・enable_embeddables はいずれも無効で、カタログ・ナレッジ参照も未設定です。
デザインは La Jolla テーマが担います。中身は Stock Header・navbar_fixed＝true・グレースケール中心の css_variables・dark_theme 未設定でした。
上部メニュー（8定義／表示6）と本文6カードは、編集対象で整理できました。見た目は Branding Editor（sp_portal）、レイアウトは Designer（sp_page＋配置）です。ページのプロパティは Page Editor（sp_page）、部品本体は Widget Editor（sp_widget）、新規は New Portal（sp_portal）が担当します。上部メニューの主要項目は gs.hasRole("sp_admin") で守られていました。
管理ホーム（sp_config_homepage）は、Service Portal Config Overview という1つのウィジェットで6カードごと描かれていました。構成は public=false・roles空・server/css/html・依存なしです。
この管理ツールが扱う対象は、この環境でポータル9件・ページ116件・ウィジェット290件でした。

Employee Center（/esc）や Service Portal（/sp）は「社員が申請・検索・状況確認をする」セルフサービスでした。同じ sp_portal の仕組みの上に載っていても、/sp_config は「作り手が他ポータルを設計・構築する」画面です。だから見た目にも検索やカタログがなく、代わりにエディタへのカードが並んでいました。

ServiceNow Service Portalはどこを直せば画面が変わる？構成7テーブルを実機で追う — 他のポータルを設計するsp_config自身も、この7テーブル構造の1レコードです

検証範囲とおことわり

撮影・確認はすべて System Administrator（管理者）ログインでの見た目です。ロールやライセンスが異なるユーザーでは、表示や件数が変わる可能性があります。
各エディタ（Branding Editor / Designer / Page Editor / Widget Editor）を開いた先の実際の編集操作は、本記事の検証範囲外です。ここでは入口の見た目と、それぞれが何を編集する画面かまでを整理しました。
Service Portal Config Overview ウィジェットのサーバスクリプトが内部で何をするか、6カードの生成ロジック、参照する Script Include の中身は範囲外です。public/roles・保持するコードの種類（server/css/html）・依存の有無（なし）という外形のみ実測しました。
テーマの SCSS 変数がコンパイル後にどの要素へ効くか、css_variables の全量は範囲外です。先頭がグレースケール定義から始まる点、dark_theme 未設定・Now Experience 未連携までを確認しています。
カード（Page Editor / Widget Editor / New Portal / Get Help）の個別の遷移先URLは取得していません。ホームの単一ウィジェットが内部で描くためです。上部メニュー項目の遷移先は sp_rectangle_menu_item から実測しています。
数値・状態はこのPDIの実測値であり、環境によって異なります。

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

/sp_config が編集する対象テーブル（sp_portal → sp_page → sp_widget）のつながりを内部から見たい場合は、上の構造記事とあわせて読んでください。6カードが「どのテーブルを直す入口か」をつかめます。