ポータルモジュールの設定
「ロゴを変えたい」「ホームの並びを変えたい」「検索が遅い」。ポータルの担当になると、こうした要望が同じ窓口に届きます。設定はテーブルとシステムプロパティに分かれ、変更の内容ごとに開く場所が違います。Australia版の検証環境で、テーブル・ロール・プロパティ・自動処理を実際に開いて確かめました。
設定を触る前に押さえること
画面は9つのテーブルの積み上げでできています。要望ごとに触る層が決まります。
ウィジェットは定義321件に対し、どこかの画面に置かれているのは181種類です。残りの140件は定義だけがあり、どこにも置かれていません。
挙動の調整は glide.service_portal.* のプロパティに集まっています。sp. で始まるプロパティは1件もありません。
検証環境：Australia PDI / OOTB / 2026-10-01 確認
調査の範囲と方法
この資料は、標準（OOTB）のポータル設定が今どうなっているかを記録した調査資料です。標準の10ポータルの外観と使い分けは、第1巻のポータルモジュールの概要にあります。設計の判断は第4巻で扱います。
環境：Australia PDI（リリースはAustralia。パッチレベルは記録していません）
確認日：2026-10-01
使ったロール：admin
確認方法：画面の一覧・フォーム・集計表示で、テーブルとフィールドの値を参照した
範囲：ポータルのテーブル・ロール・システムプロパティ・ビジネスルール・スケジュールジョブ・カタログ／ナレッジ／タクソノミーとの結び付き
範囲外：レコードの追加・変更、一般利用者のロールでの確認、カスタマイズ後の環境、本番環境の挙動
調査の結果は、章ごとに「その設定で何ができるか」を添えて書いています。レコードがあることと、それが動作することは別です。管理者の画面で見えたことと、一般利用者に同じ権限があることも別です。この資料は、画面で見えた値の記録を中心にしています。
モジュール構成
ポータルの設定は、管理者向けの設定画面と、システムプロパティに分かれています。次の図は、要望ごとに設定の置き場所が違うことを示したものです。
図の内容を文字でも書き出します。
ロゴ・色を変えたい：sp_theme と sp_header_footer
最初の画面を変えたい：sp_portal の homepage / login_page
部品を足したい：sp_instance で既存の sp_widget を選ぶ。足りないときは自作ウィジェット（sp_widget の新規作成）
速度・検索の挙動を変えたい：システムプロパティ glide.service_portal.*
SP Configuration の画面
SP Configuration（/sp_config）は、ポータルの設定画面を集めた専用のポータルです。Branding Editor では、タイトル・ロゴ・タグライン・背景色を画面上で編集できます。
Designer では、ページのカードがタイトルとIDで並び、選ぶとその画面のレイアウトを編集できます。
システムプロパティ
システムプロパティは、ポータル全体の挙動を外から切り替える設定値です。値を変えると、検索の候補表示やキャッシュなどの動作を切り替えられます。ポータルの設定は glide.service_portal.* の名前空間に集まっており、説明つきのものが32件あります。説明なしも含め com.snc.service_portal.* を加えると39件です。sp. で始まるプロパティは1件もありません。
①の glide.service_portal.default_404_page は既定値が404で、ページが見つからないときに開く画面のIDを指定する設定です。②の表示は、説明つきのプロパティが32件あることを示しています。以下に用途別の設定項目を示します。
検索
glide.service_portal.enable_typeahead（既定 true）：入力中の候補表示の有効・無効
glide.service_portal.typeahead.min_length（既定 3）：候補を出し始める文字数
glide.service_portal.typeahead.wait_ms（既定 1000）：入力してから候補を出すまでの待ち時間（ミリ秒）
glide.service_portal.search_as_you_type_behavior（既定 suggestions）：候補の出し方（Suggestions か Typeahead）
キャッシュと読み込み
glide.service_portal.sp_instance.cache_enabled（既定 true）：配置のキャッシュ
glide.service_portal.sp_announcement.cache_enabled（既定 true）：お知らせのキャッシュ
glide.service_portal.sp_user_criteria.cache_enabled（既定 true）：公開範囲の判定のキャッシュ
glide.service_portal.js_minify.enabled（既定 true）：JavaScriptの圧縮
glide.service_portal.load_ui_scripts_on_demand（既定 true）：UIスクリプトを必要になってから取得
表示とURL
glide.service_portal.default_404_page（既定 404）：見つからないときのページ
glide.service_portal.enable_human_readable_urls（既定 true）：読みやすいURLの有効化
glide.service_portal.persist_msgs_on_nav（既定 true）：ページ遷移後もメッセージを残す
glide.service_portal.disable_location_tracker（既定 true）：位置情報のポップアップと追跡を無効にする
認証
glide.service_portal.rotate.guest.usertoken（既定 true）：ゲストのセッショントークンの更新
検索の応答に関わる値は、typeahead.min_length（既定3文字）と typeahead.wait_ms（既定1000ミリ秒）です。キャッシュ関連の設定は、いずれも既定で有効です。値を変えた効果は、今回は確かめていません。
プロパティの説明文は、製品に同梱されています。次のURLを自分のインスタンスで開くと、同じ記述を確認できます。
/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.service_portal^descriptionISNOTEMPTY
データモデル
ポータル本体の定義は sp_portal が持ちます。画面は、ページ・コンテナ・行・列・部品の配置の階層で作られます。色を決めるテーマと、上下の枠を決めるヘッダー・フッターは、別のテーブルです。
画面を積み上げる9つのテーブル
sp_portal（ポータル本体）が、sp_theme（見た目）と sp_header_footer（ヘッダー・フッター）を参照する
homepage で sp_page（画面1枚）につながり、sp_container（大きな区画）→ sp_row（行）→ sp_column（列）→ sp_instance（部品の置き場所）→ sp_widget（部品の定義）の順に積み上がる
積み上げの順は、ページ・コンテナ・行・列・配置（sp_instance）です。配置が「どの列にどの部品を置くか」を持ち、部品そのものの定義は sp_widget にあります。この構造から、レイアウトの変更は行と列、部品の追加は配置のレコードで行えると分かります。件数は次のとおりです。
表の内容を文字でも書き出します。
sp_portal（ポータル本体）：10件。URLと既定の画面・テーマを持つ
sp_page（画面1枚）：128件。画面の単位
sp_container（大きな区画）：217件。ページ内の最上位の枠
sp_row（行）：274件。コンテナ内の横並びの帯
sp_column（列）：428件。行の中で幅を分ける単位
sp_instance（配置）：500件。どの列にどの部品を置くか
sp_widget（部品の定義）：321件。機能の部品そのもの
sp_theme（見た目）：19件。色・フォント・ナビバー
sp_header_footer（ヘッダー・フッター）：10件。全ページ共通の上下の枠
配置されているウィジェットと定義の差
sp_instance をウィジェット別に集計すると、配置の総数は500件で、置かれているウィジェットの種類は181です。一方、定義は321件あります。差の140件は、定義だけが存在してどの画面にも置かれていないウィジェットです。
①の総数500は配置の数で、②の表示は、その配置が181種類のウィジェットに振り分けられていることを示します。定義321件との差が、どの画面にも置かれていない分です。この一覧のWidget列には、名前が引けずにsys_idがそのまま出ている行があります。
定義側の内訳は、アプリケーション別の集計で確認できます。
①が定義の総数321件、②がGlobalスコープの159件です。製品が提供するウィジェット（servicenow=true）は191件でした。
配置の型ごとの追加項目
sp_instance は、継承先のテーブルを持ちます。メニュー付き（Instance with Menu）・リンク付き・テーブル参照付き・検索用（Instance with Search）・カルーセル用の配置が並びます。同じ「配置」でも、型ごとに追加の項目が変わる作りです。ヘッダーメニューの項目そのものは sp_rectangle_menu_item（Menu Item）に入っており、配置側のメニューは sp_instance_menu です。
ページとウィジェットの項目
フィールドの公式説明は、製品に同梱されたドキュメント（sys_documentation の hint）が出典です。sp_page には8項目、sp_instance には8項目、sp_widget には6項目の説明が入っています。ポータル本体（sp_portal）の20項目は、第4章で扱います。
sp_page は画面1枚の定義です。draft の公式説明は次のとおりです。
Draft pages are not visible to end users, but they will show for Service Portal admins
（訳: ドラフトのページは一般の利用者には見えず、Service Portalの管理者にだけ表示されます）
引用元：/sys_documentation_list.do?sysparm_query=name=sp_page^element=draft
ページ128件のうち、公開設定（public=true）は5件、内部用（internal=true）は11件、ドラフト（draft=true）は0件でした。draft を使うと、利用者に見せずに管理者だけがページを確認できます。内部用のページは、公式の説明では Service Portal のデザイナーで編集できないものです。
ページの一覧は、次のとおりです。
servicenow は、製品が提供・保守するウィジェットかを示す項目です。公式の説明は次のとおりです。
Widget provided and maintained by ServiceNow, most fields are not editable by admins
（訳: ServiceNowが提供・保守するウィジェット。ほとんどの項目は管理者が編集できません）
引用元：/sys_documentation_list.do?sysparm_query=name=sp_widget^element=servicenow
製品提供のウィジェットは191件で、ほとんどの項目は管理者が編集できません。public=true のウィジェットは98件でした。
画面
画面の見た目と最初に開く画面は、ポータル本体のレコード（sp_portal）の項目と、テーマ・ヘッダー・フッターで決まります。
ポータルフォームの項目
sp_portal の主な設定対象は、初期画面、見た目、検索と機能です。ここで指定した値で、利用者が最初に見る画面とヘッダーのメニューを切り替えられます。
画面の起点を決める項目：homepage（ページ指定がないときに開く画面）、login_page（認証させる画面）、notfound_page（見つからないときの画面）
見た目と枠を決める項目：logo、icon、title、logo_alt_text、hide_portal_name、rtl_enabled
検索と機能を決める項目：search_application、search_results_configuration、enable_favorites、enable_embeddables
各ポータルのフォームでは、ホームページ・ログインページ・メインメニュー・テーマが1画面に並びます。
①のHomepage（index）、KB home page（kb_view2）、Login page（landing）は、利用者が最初に見る画面の指定です。②のMain menuはヘッダーメニューの指定で、SP Header Menuが入っています。③のTheme（La Jolla）は見た目の指定です。①で最初の画面、②でヘッダーのメニュー構成、③でテーマを切り替えられます。
alternate_portal の公式説明は次のとおりです。
Users accessing the current portal will be redirected to the configured alternate portal
（訳: 現在のポータルにアクセスした利用者は、設定された代替ポータルへリダイレクトされます）
引用元：/sys_documentation_list.do?sysparm_query=name=sp_portal^element=alternate_portal
alternate_portal は、アクセスしてきた利用者を別のポータルへ転送する先を決める項目です。旧ポータルのレコードを残したまま、転送だけを行えます。
テーマ・ヘッダー・フッター・ホームページの指定
テーマは色・フォント・ナビバーなどの見た目の設定で、ヘッダー・フッターは全ページ共通の上下の枠です。ホームページは、ポータルを開いたときに最初に出るページです。この3つは sp_portal の項目として、ポータルごとに1つずつ指定します。
ポータルごとの指定は次のとおりです。
表の内容を文字でも書き出します。
Employee Center（esc）：EC Theme／ec_home。既定のポータル
Service Portal（sp）：La Jolla／index
SP Configuration（sp_config）：La Jolla／sp_config_homepage
Knowledge Portal（kb）：Portal Next Experience Theme／kb_home
Service Workspace Portal（swp）：Workspace EC Theme／sw_sc_category
Mobile Employee Service Portal（mesp）：Mobile Employee Next Experience Theme／mesp_index
Walk-up（walkup）：Walk-up Coral Theme／walkup_home
CAB Workbench（cab）：CAB Workbench - Default／cab_calendar
Benchmarks（benchmarks）：Benchmarks - Theme／bhome
Performance Analyzer（perf）：テーマもホームページも未設定
Performance Analyzer は、テーマもホームページも空の状態でした。標準のポータルにも、設定が空のまま提供されているものがあります。
テーマは19件、ヘッダー・フッターは10件あります。ヘッダー・フッターの例は Portal Polaris Header と Portal Coral Header です。Employee Center Header、Employee Center Footer、LegalFooter もあります。
ポータルのレコードから、それぞれ1つ選んで指定できます。
ロジックと自動化
ポータルのテーブルには、保存時や表示時に動くビジネスルールが用意されています。sp_ で始まるテーブルを対象とする有効なものは36件です。保存時の入力チェックと名前の自動設定が中心で、ポータルやページの作成・変更の際に値が自動で整えられます。代表的なものを、条件と動作で書き出します。
Unique URL Suffix（sp_portal・before・100）：URLサフィックスが変わったとき、CMSが同じ値を使っていれば、保存を中止する。エラーも表示する
Disallow Portal URL Suffix for SP（sp_portal・before・100）：②のルール。サフィックスが予約語の portal のとき、保存を中止する
Unique Default on Insert / Update（sp_portal・after・100）：③のルール。default が true になると、自分以外のポータルの default を false に更新する。既定のポータルは常に1つに保たれる
Config Portal（sp_portal・before・100）：旧サフィックスが sp_config で、変更または削除のとき、保存を中止する。設定画面の基盤となるポータルの削除を防ぐ
Page ID（sp_page・before・99）：①のルール。id が空でないときに動く。小文字にする。英数字と _ 以外は _ に置き換える。連続した _ は1つにまとめ、末尾の _ は除く
Page Title（sp_page・before・100）：title が空のとき、id を title に入れる
Container Name / Set Name（sp_page・sp_container・before・100）：コンテナ名を「ページのタイトル（なければid） - Container 順序」の形に自動設定する。ページのタイトルやIDが変わると、子のコンテナ名も更新する
Fixed Header / Footer validation（sp_theme・before・100）：ナビバーが固定されていないとき、フッターだけを固定すると通知を出す。フッターの固定の設定は false に戻す
Sync Insert（sp_css・after・100）：スタイルシートを新規作成すると、対になるCSS Include（source=local）を自動作成する。CSS Include のフォームから作った場合は作らない
ほかに、新しいポータルを作ったときの分析設定を作るルール（Create Analytics Settings for New Portal・after・200）があります。Usage Insights が有効で、Engagement Messenger 用でないポータルが対象です。
これらのルールにより、ポータルを追加するときのURLサフィックスには portal と CMS で使用中の名前を指定できません。既定のポータルは default を true にするだけで切り替えられ、既存の既定は自動で外れます。sp_config ポータルの変更・削除は、保存が中止されます。
スケジュールジョブは3件あります。
Portal Analyzer：有効。定期実行
Populate Suggestions to avoid Cold Start - Portals：無効。手動実行（On Demand）
Advanced Portal Navigation : Delete invalid records：有効。毎日実行
権限
ポータルの設定画面を触れる人は、ロールで決まります。今回の検索で見つかった関連ロールは6つで、sp_ で始まるのは2つです。
①sp_admin（Can manage the Service Portal）：ポータルの構成を管理するロール。保有者は20人
②sp_operator（Grants low-code access to customize and manage portal experiences without full administrative privileges）：管理者権限なしでポータルの画面を調整できるロール。保有者は0人
portal_analytics_viewer：ポータルの利用分析を見るロール。保有者は0人
portal_analytics_admin：分析の設定を管理するロール
portal_notification_pref_admin：通知の受信設定テーブルを扱うロール
sn_ex_emp_fd.portal_stats_manager：Employee Centerの統計を扱うロール
この環境の sp_admin は、7つのロールを含んでいました。公式ドキュメントの Service Portal roles が挙げるのは4つです。
実機で含まれていた7つ：taxonomy_admin、announcement_admin、service_status_subscriber、search_application_admin、log_debugger、evam_admin、notification_provider_admin
公式が挙げる4つ：evam_admin、taxonomy_admin、search_application_admin、announcement_admin
両方にある：evam_admin、taxonomy_admin、search_application_admin、announcement_admin
実機にだけある：service_status_subscriber、log_debugger、notification_provider_admin
sp_admin を付与すると、含まれるロールを通じて次の操作を行えるようになります。
トピックの管理
お知らせの投稿
検索アプリケーションの設定
ACL は名前が sp_ で始まるものが325件あり、うち sp_portal で始まるものは31件です。sp_operator が実際にどの操作までできるかは、ACLとの照合をしていないため確かめていません。
公開範囲の持ち方
コンテンツの出し分けは User Criteria（user_criteria・41件）で行えます。対象ごとに「Available for」と「Not Available for」のM2Mテーブルがあります。
カタログアイテム：sc_cat_item_user_criteria_mtom
カテゴリ：sc_category_user_criteria_mtom
Quick Link：sn_ex_sp_quick_link_user_criteria_mtom
連携
ポータルは、項目とM2Mテーブルを通じてカタログやナレッジを参照します。M2Mテーブルは、ポータルとコンテンツの対応を記録し、ポータルごとに出すカタログ・ナレッジ・タクソノミーはこの対応で切り替えられます。
カタログ（m2m_sp_portal_catalog）：sp、swp が Service Catalog を参照。ほかの8ポータルは sc_catalog が空
カタログ（sc_catalog_page）：Employee Center が esc_sc_category を参照
ナレッジベース（m2m_sp_portal_knowledge_base）：Service Portal が IT と Known Error の2つを参照
ナレッジのページ（kb_knowledge_page）：mesp と sp が kb_view2、esc が esc_knowledge_home
タクソノミー（m2m_sp_portal_taxonomy）：Employee Center と Mobile Employee Service Portal が Employee を参照。配下にトピック21件
カタログとナレッジの結び付き
sp_portal.sc_catalog は、Service Portal（sp）と Service Workspace Portal（swp）が「Service Catalog」を参照し、ほかの8ポータルは空です。Employee Center（esc）は sc_catalog_page に esc_sc_category を持ちます。
ナレッジは、sp_portal の kb_knowledge_page に、mesp と sp が kb_view2、esc が esc_knowledge_home を指定しています。ナレッジベースそのものは、sp_portal の項目ではなくM2Mテーブル（m2m_sp_portal_knowledge_base）が持ち、Service Portal には IT と Known Error の2つが結び付いています。カタログは m2m_sp_portal_catalog が持ち、sp と swp が Service Catalog を参照する形です。
カタログのカテゴリは、Service Portal の画面で確認できます。
①のHardwareカテゴリを開くと、商品の一覧に進みます。
タクソノミーとの結び付き
タクソノミーは、コンテンツをトピックで分類する仕組みです。Employee Center のメニュー階層は、タクソノミーとトピックで作られます。m2m_sp_portal_taxonomy は2件で、Employee Center と Mobile Employee Service Portal が、どちらもタクソノミー「Employee」を参照しています。
①の2行が、2つのポータルとタクソノミーの結び付きです。タクソノミーは「Employee」の1件で、配下にトピックが21件あります。最上位は Technology services と Risk and compliance の2つです。
所見と未確認事項
所見：実機で気づいたこと
定義した部品の44%が、どの画面にも置かれていない
ウィジェットは定義321件に対し、配置されているのは181種類でした。差の140件は、どの画面にも置かれていません。使うかどうかはポータルごとの配置が決めます。部品の候補を探すときは、sp_widget の定義の一覧を検索すると、既存の部品を確認できます。
プロパティは名前空間で探す
プロパティ名に service_portal を含む条件で検索します。設定値は glide.service_portal.* と com.snc.service_portal.* の2つの名前空間にあり、sp. で始まるものは1件もありません。
メニューの実体は名前が2つに割れている
ヘッダーメニューの項目は sp_rectangle_menu_item、配置側のメニューは sp_instance_menu です。ビジネスルールの対象テーブル名には sp_rectangle という表示も出ますが、このテーブルは直接開けませんでした。名前で検索して見つからないときは、継承先のテーブルから探せます。
カテゴリ経由では、目的の項目が1ページ目に出ないことがある
Hardwareカテゴリの商品一覧は、1ページ目に9件が並び、残りは Show More で追加読み込みされます。
①のDeveloper Laptop (Mac) は1ページ目に出ます。Standard Laptop は1ページ目になく、②のShow More Itemsを押すと表示されます。特定の商品を探すなら、検索を使うのが確実です。なお、ナレッジでカテゴリの行を押しても、記事の一覧は絞り込まれませんでした。
Cartとツアーはページを移動しない
ヘッダーのCartとToursは、ポップオーバーで開きます。独立したページとして画面遷移を追っても見つかりません。メニュー項目は sp_rectangle_menu_item に入っています。
未確認事項
ポータル別の sp_instance 配置数は取得できていません。sp_page にポータル項目がなく、ページからポータルへ辿れないためです。
sp_operator の保有者は0人でした。この操作でどの画面や項目に手が入るかは、ACLとの照合をしておらず確かめていません。
一般利用者のロールでの表示と操作は、確認していません。管理者の画面で見えた値の記録です。
sp_admin の保有者20人は、この環境の値です。運用の基準にはしません。
ビジネスルールの条件と処理は、代表的な10件について確認した範囲です。36件すべての中身までは確認していません。
未配置ウィジェット140件の内訳は確認していません。
Performance Analyzer が、テーマとホームページの指定なしで画面を出す仕組みは確認していません。
プロパティの値を変えた効果は確認していません。
スケジュールジョブ3件は、有効・無効と実行方式のみの確認です。
sp_row と sp_column は件数のみです。sp_instance は総数・ウィジェット別集計・継承構造を確認し、ポータル別の集計は取得していません。
タクソノミー配下のトピック21件の中身と、ポータル別のナレッジベースの結び付きは、今回は一部のみ確認しています。
プラグイン・スコープ・メニュー構成、フロー、通知、SLA、REST・インポート・メールとの連携は調べていません。
ウィジェット191件を製品提供、残り129件をそれ以外として数えました。それ以外の由来（環境で追加されたものか、他の製品アプリのものか）は区別していません。
本記事は標準（OOTB）の構成を対象とします。カスタマイズ後の環境や、本番環境の挙動は対象外です。設定は閲覧のみで、値の変更は行っていません。
公式ドキュメントの記述と実機が一致しない箇所（sp_admin が含むロール）は、実機の値を採用しています。
付録
用語集
sp_portal：ポータル本体の定義
sp_page：画面1枚の定義
sp_instance：列とウィジェットを結び付ける配置情報
sp_widget：画面に置く機能部品の定義
User Criteria：ユーザーなどの条件による公開範囲の制御
実機で確認するURL
/sys_documentation_list.do?sysparm_query=nameINsp_portal,sp_page,sp_instance,sp_widget^hintISNOTEMPTY — フィールドの公式説明
/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.service_portal^descriptionISNOTEMPTY — プロパティの公式説明
/sys_user_role_list.do?sysparm_query=nameSTARTSWITHsp_^ORnameLIKEportal — ポータル関連のロール
/sys_script_list.do?sysparm_query=collectionSTARTSWITHsp_^active=true — ポータル関連のビジネスルール
/m2m_sp_portal_taxonomy_list.do — ポータルとタクソノミーの結び付き
