Knowledge Portal（/kb）の「45 Articles」はどこから来るか（kb_knowledge）

2026年7月12日 08:15

ServiceNow には、社員やエンドユーザーが使う「ポータル画面」が最初から複数入っています。代表格はカタログ申請が中心の Employee Center（/esc）と、汎用的な Service Portal（/sp）です。そのなかに、ナレッジ（社内の記事・手順・既知エラー）を読むことだけに特化したポータルが1つあります。それが Knowledge Portal（/kb）です。

この記事は /kb を PDI（個人用の検証インスタンス）の初期状態で実際に開いた、開発者向けリファレンスです。sp_portal の全設定・テーマ・メニュー・ページ・ウィジェット・裏側のコードまで、REST と実画面で読み解きます。前半で「開くと何が出て、どういう画面なのか」を押さえ、後半で「その見た目を裏で決めている設定値・テーマ・ウィジェットの周辺機能」を実測ベースで並べます。/kb を設定・開発する際に必要な情報を1本にまとめました。テーブルの内部構造（sp_portal → sp_page → sp_widget のつながり方）そのものは別記事に譲り、本記事は「どの設定がどの画面につながるか」に集中します。

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

この記事で分かること

Knowledge Portal（/kb）が、カタログや依頼機能を持たない「ナレッジ閲覧専用」のポータルであること
sp_portal の全設定値と、kb_knowledge_base / sc_catalog が空であることの設計上の意味
テーマ（Customer Experience Coral Theme）の header/footer・SCSS変数・dark_theme といったデザイン設定の中身
ホーム（kb_home）を構成する2つのウィジェットと、その public/roles・持つコード・依存
画面に出る「4 Knowledge Bases / 45 Articles」が、REST 実測の件数と一致すること

このポータルは何か

先に結論を書くと、Knowledge Portal は ナレッジベースを読むこと（検索・閲覧・購読）だけに絞った入口 です。Service Portal のように「カタログから申請」「インシデントを起票」といった導線を持たず、社内の記事を探して読むことに画面全体が使われています。

ポータルの定義は sp_portal テーブルの1レコードで、/kb でアクセスします。このPDIには sp_portal が全9件登録されていて、そのうち default=true（利用者が最初に案内される既定）だったのは Employee Center でした。/kb の Knowledge Portal は default=false、つまり既定ではないものの併存している位置づけです。

押さえたいのは、これがカタログや依頼機能を持たない閲覧特化のポータルという点です。sc_catalog（カタログ）が空で申請の受け皿を持たず、kb_knowledge_base（特定のナレッジベース）も空で1つの KB に固定していません。そのため複数のナレッジベースを横断して一覧・検索できる作りです。入口ページは homepage=kb_home（sp_page）、見た目は theme=Customer Experience Coral Theme（sp_theme）が描きます。この設定値の中身は、後半のリファレンス部分で1項目ずつ掘り下げます。

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

用語メモ

sp_portal：ポータルの定義テーブル。1レコードが1ポータルで、url_suffix・homepage・theme・各種参照を持ちます。
sp_page：ポータル内の1ページを表すテーブル。id で識別され、URL の ?id= に対応します。
kb_knowledge_base / kb_knowledge：ナレッジベース定義と記事のテーブル。記事は workflow_state（Draft〜Retired）を通って公開されます。

見た目：ホーム画面の実際

まず、/kb を開いた画面を確認します。次が実際のホーム（admin＝System Administrator でログインした状態）です。

上から順に、役割がはっきり分かれています。ヘッダは servicenow ロゴと右上のユーザー名だけで、Catalog や Cart は出ていません。中央のヒーローに大きく「Welcome to Knowledge」と検索ボックスがあり、すぐ下に「4 Knowledge Bases / 45 Articles」というサマリが出ます。その下が「Explore our Knowledge Bases」で、4つのナレッジベースがカードで並び、各カードに記事数と Subscribe（購読）リンク、右上に「Actions ▾」が付きます。最下段は Featured（注目記事）／ Most Useful（役立つ記事）／ Most Viewed（閲覧数の多い記事）の3カラムで、各記事に著者・閲覧数・投稿時期・星の評価が表示されました。

この画面で押さえておきたいのは、/kb の入口が「メニュー」でも「フォーム」でもなく、中央の検索とその下の KB 一覧である点です。読むことに視線を集めるため、余計な導線を置かない作りになっています。

ナレッジベースの一覧と記事数

ヒーローの「4 Knowledge Bases / 45 Articles」が実際のデータと合っているかを、REST で裏取りしました。kb_knowledge_base（ナレッジベース定義）で active=true が4件です。各 KB の公開記事（kb_knowledge の workflow_state=published）を数えると次のとおりです。

合計 45 件は画面の「45 Articles」と一致し、内訳も各カードの記事数（IT=36 / KCS=4 / Known Error=4 / Knowledge=1）と一致していました。画面に出る数字が、KB 定義と記事のワークフロー状態から積み上がっていることが確認できます。

なお kb_knowledge テーブル全体は58件です。内訳は公開（published）が45件、下書き（draft）が6件でした。ホームに出てくるのは公開状態の記事だけで、下書きや退役（retired）などは含まれません。ワークフロー状態の選択肢は7つです。内訳は Draft / Review / Scheduled for publish / Published / Pending retirement / Retired / Outdated です。このうち Published のものだけが閲覧側に見えます。

Featured / Most Useful / Most Viewed の出どころ

下段の3カラムは、記事レコードの属性から自動で並びます。Most Viewed は記事の閲覧数（Views）順です。Featured は「注目」として設定された記事、Most Useful は評価（星の数）に基づく並びです。このPDIの Featured には「Email Interruption Tonight at 11:00 PM Eastern」が並びました。もう一件は「Sales Force Automation is DOWN」です。いずれも Wayne Webb・0 Views・4年前の記事です。Most Viewed には「What are phishing scams and how can I avoid them?」（90 Views）が出ていました。もう一件は「Automatic Replies (Out Of Office)」（85 Views）です。どちらも Ron Kettering の記事です。Most Useful は「No content to display」でした。評価が集まっていないと空になることが読み取れます。コンテンツやその属性がそろって初めて各枠が埋まる、という挙動を実機の空表示が示していました。件数や記事名はこのPDI固有のもので、環境によって変わります。

基本設定：カタログもKBも空の閲覧特化

ここからがリファレンス部分です。/kb の見た目と挙動を決めているのは sp_portal レコードの設定値です。REST で読み取った全項目を、意味とあわせて並べます。空欄が多いのがこのポータルの性格そのものを表しています。

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

入口とページ差し替え：homepage＝kb_home（最初に開くページ）、login_page＝login（未ログイン時）を指します。notfound_page は空で、404 は既定にフォールバックしていました。ページを丸ごと差し替えたいときはここを変えます。
カタログを持たない：sc_catalog / sc_catalog_page / sc_category_page はすべて空。カタログ関連が一切紐づいていないので、/kb には申請・カートの導線が現れません。
全KB横断の設計：kb_knowledge_base が空です。特定の1 KB に固定していないため、ホームの一覧も検索も、有効な複数の KB を横断して対象にします。kb_knowledge_page（記事表示ページ）も空で、記事詳細は既定のページにフォールバックします。
メニューを持たない：sp_rectangle_menu が空。/sp の SP Header Menu（Knowledge / Catalog / Requests など6項目）にあたる定義が無く、ヘッダは項目バーを持ちません。
検索：enable_ais＝false（AI Search を使わない）です。search_application＝Knowledge Portal Search Configuration が指定されています。search_results_configuration＝Knowledge Portal Search も指定されています。同じ Coral 系でも /sp は enable_ais=true だったので、検索基盤の選択はポータルごとに違うことが読み取れます。
その他：enable_favorites＝false（お気に入り無効）、rtl_enabled＝false（右横書き非対応）、enable_embeddables＝false。quick_start_config には tagline や hero_background など、ガイド付き設定でつなぐ要素が JSON で入っていました。

表で「（空）」と書いた項目は、REST で空だったものです。空でも動くのは、ServiceNow 側が既定のページや挙動にフォールバックするためで、明示的に指定したいときにだけ値を入れる、という位置づけになります。配色を担う theme の中身は、後述のデザイン設定で掘り下げます。

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

/kb の Knowledge Portal が、どの設定からどのページへつながるかを一枚にまとめました。

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

ポータル本体（sp_portal）が直接指すページは実質2つ。homepage＝kb_home（ホーム）、login_page＝login（ログイン）です。notfound_page は未設定のため、専用の404ページを持たずプラットフォーム既定にフォールバックします。
/sp にあったヘッダメニュー（sp_rectangle_menu）は、このポータルでは 未設定 でした。したがってメニューから枝分かれする遷移先はありません。ナビゲーションの主役は、ホームに置かれた2つのウィジェットです。
ホーム（kb_home）上の検索ウィジェットと KB 一覧ウィジェットが、検索やカード選択をきっかけに記事・KB閲覧ページへ利用者を送ります（図の点線）。

ページ遷移は URL でいうと /kb?id=<ページのid> という形をとります。ホームは /kb?id=kb_home に相当し、この id が sp_page レコードの識別子です。ポータル設定やウィジェットは「どの id のページを開くか」を指定している、という関係になります。

デザイン設定の詳細（Customer Experience Coral Theme）

/kb の配色とヘッダ/フッタの枠は sp_portal の theme が担います。ここが指すのは Customer Experience Coral Theme（sp_theme の1レコード）です。設定表の1行で終わらせず、テーマ側の項目を REST で開いて中身を並べます。

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

ヘッダは Coral・固定、フッタは Next Experience 系：header＝Portal Coral Header で、Coral 系のヘッダウィジェットを使います。navbar_fixed＝true なのでスクロールしてもヘッダが上部に貼り付きます。footer＝Portal Next Experience Footer、footer_fixed＝false で、フッタは持つものの固定はしません。CAB Workbench がフッタ未設定だったのと対照的に、/kb はフッタを備えています。
配色は SCSS 変数で決まる：テーマの css_variables にはテキスト配色の変数群が入っています。$text-primary:#10171A / $text-secondary:#29353B / $text-tertiary:#4F5C62 などが定義されていました。加えてポータル側の css_variables に $sp-tagline-color:#000000; があり、こちらは /kb だけに効く上書きです。テーマ全体の配色はテーマ側、このポータル固有の微調整はポータル側、という二段構えです。
ダーク非対応・Now Experience 未連携：dark_theme は未設定、matching_now_experience_theme も未設定でした。ダークモードや Next Experience テーマとの対応づけは、このPDIの初期状態では入っていません。icon（ファビコン等）も未設定で、logo だけが紐づいていました。

テーマの各 SCSS 変数が最終的にどの要素へ効くか（コンパイル後のCSS）までは今回の読み取りの範囲外です。「配色はテーマの css_variables、tagline の色だけポータル側で上書き」という対応が実測できた、という整理にとどめます。ダーク対応を足したいなら dark_theme に別テーマを割り当て、微調整はポータルの css_variables を触る、という手順になります。

ヘッダメニュー等の設定（メニュー未設計）

ヘッダに並ぶメニューは sp_rectangle_menu で定義されます。/sp ではヘッダに Knowledge・Catalog・Requests などのメニューが並んでいましたが、/kb の sp_rectangle_menu は空でした。ヘッダに項目バーを持たない、というのがこのポータルの特徴になります。実際のヘッダとナビゲーションの構成を整理しました。

ヘッダに載るのは、左の servicenow ロゴ（logo 画像）と、右のログインユーザー名くらいです。カタログもカートも無く、お気に入りも無効なので、利用者の視線は自然と中央のヒーロー検索と、その下の KB 一覧へ向かいます。つまり 「メニューで機能を選ばせる」のではなく、「検索と一覧で記事へ誘導する」 という導線設計になっています。これは、読むことに集中させたい閲覧専用ポータルとして筋の通った作りです。

/sp は同じ位置に SP Header Menu（6項目）を持っていました。/kb にそれが無いのは、そもそもメニュー定義への参照すら設定されていないためです。CAB Workbench がメニュー定義への参照だけ持って項目0件だったのに対し、/kb は参照自体が空という違いがあります。導線を足したい場合は、メニュー項目を増やすのではなく、sp_rectangle_menu にメニュー定義を割り当てるか、ページ上のウィジェット配置を検討することになります。

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

見た目の裏側で動くコードへ進みます。/kb の周辺機能は、ほぼホームの2ウィジェットの内部処理に集約されます。ホーム以外のページ（login・404）は OOTB 共通の最小構成で、独自のスクリプトを持ちません。

ホーム2ウィジェットの周辺機能

先ほどの kb-homepage-search / kb-bases-browse が、どんなコードと依存を持つかを実測しました。

公開範囲：両ウィジェットとも public＝true で、未ログインでも動きます。roles は空で、特定ロールへの制限はありません。ホームの検索と一覧が匿名でも表示できる作りで、閲覧専用ポータルの性格と合っています。ログイン後に見せたい要素があれば、そのウィジェットの public / roles を確認する、という順で調べます。
保持するコード：両方とも server（サーバスクリプト）・client（クライアントスクリプト）・link（リンク関数）を持ちます。加えて options（オプションスキーマ）・css・html もそろい、フル構成のウィジェットです。Service Portal のウィジェットは、サーバスクリプトが data / input を介してクライアントへ値を渡す作りが基本です。その受け渡しには GlideSPScriptable（サーバ側の SP 用 API）や Script Include を使います。KB 閲覧ウィジェットも、この server ↔ client のモデルに沿って検索クエリや KB 件数を組み立てていると読み取れます。
依存（dependencies）：両ウィジェットとも dependencies はなしでした。CAB Workbench のカレンダーウィジェットは専用の依存（Angular の Provider・Template をまとめた sp_dependency）を2つ読み込んでいました。これに対し KB のホームウィジェットは追加の依存を持ちません。ウィジェット単体の client（Angular コントローラ）と html テンプレートだけで完結する構成です。

サーバスクリプトが具体的にどのテーブルへどんなクエリを投げるか、クライアント側の Angular コントローラが何をするか、options のスキーマの中身までは今回の読み取りの範囲外です。ここでは「public/roles・保持するコードの種類・依存の本数」という外形を実測しました。KB 一覧の件数や検索の対象 KB は、kb_knowledge_base と記事の workflow_state から積み上がります（「見た目」節で 45 件を裏取り済み）。ウィジェットのサーバ側は、そのデータを読んで描いています。

開発者の勘所・まとめ

開発者の勘所

/kb を設定・開発する観点で、押さえておくと迷いにくいポイントをまとめます。

ページ遷移は ?id=<page> 形式。ポータル設定が指しているのは sp_page の id（kb_home / login など）です。記事や KB 一覧への遷移もウィジェットが /kb?id=... を組み立てます。
配色はテーマとポータルの二段構え。テーマ（Customer Experience Coral Theme）の css_variables が全体の配色を決めます。ポータルの css_variables（$sp-tagline-color:#000000;）は /kb だけの微調整を担います。ダーク対応を足すなら dark_theme（このPDIは未設定）に別テーマを割り当てます。
メニューではなくウィジェットが導線。sp_rectangle_menu が空なので、ナビゲーションはホームの2ウィジェット（検索・KB一覧）に集約されています。導線を足したい場合、メニュー項目を増やすのではなく、ページ上のウィジェット配置を検討することになります。
KB の束ね方は kb_knowledge_base の有無で決まる。空なら全KB横断、値を入れれば特定 KB 固定です。/sp は IT に固定していましたが、/kb は固定せず横断する設計でした。特定の KB だけに絞りたい場合は、公式の Configure knowledge bases for a portal の手順があります。この手順でポータル単位に対象 KB を指定します。
公開範囲は public / roles で決まる。ホームの2ウィジェットはいずれも public=true・roles空・依存なしで、未ログインでも検索と一覧が動きます。ログイン後に見せたい要素があれば、そのウィジェットの public / roles を確認します。

テーブルは sp_portal → sp_page → sp_container → sp_row → sp_column → sp_instance → sp_widget とつながっています。この内部構造そのものはポータル1画面は複数テーブルの組み合わせ（sp_portal）で扱いました。参照フィールドの向きや件数までそちらにまとめています。ナレッジベースと記事・カテゴリのテーブル構造（kb_knowledge_base / kb_knowledge / kb_category）を突き詰めたい場合は、別記事があります。ナレッジ管理のテーブル構造を扱った記事なので、そちらを参照してください。

他ポータルの Knowledge との違い

Service Portal（/sp）や Employee Center（/esc）にも「Knowledge」への入口はあります。では専用の Knowledge Portal を分けて持つ意味は何か。違いは、画面全体がナレッジ閲覧に最適化されているかどうかです。

Service Portal（/sp）：ヒーローは「How can we help?」です。Request Something（カタログ）／ Knowledge Base ／ Get Help の3導線が並ぶ総合窓口でした。ナレッジは複数機能のうちの1つで、ヘッダに6項目のメニューを持ちます。
Employee Center（/esc）：Quick links や Popular topics などトピック起点の社員向け総合ポータル。カタログ申請・タスク確認が主役で、ナレッジはその一部です。
Knowledge Portal（/kb）：カタログもカートもメニューもなく、ナレッジベースの一覧・検索・購読・閲覧ランキングだけで画面が構成されます。

したがって Knowledge Portal は、「申請導線を見せずに、社内の記事・手順・既知エラーを読ませたい」ケースに向いた設計です。ナレッジの閲覧だけを目的にしたリンクを社内に配る、記事の閲覧数や評価の傾向を関係者に見せる、といった使い方が考えられます。総合ポータルの一機能としての Knowledge と、専用ポータルとしての /kb を、目的に応じて使い分けることになります。

まとめ

/kb の Knowledge Portal は、sp_portal に登録されたナレッジ閲覧専用のポータル。このPDIでは default=false、theme=Customer Experience Coral Theme、homepage=kb_home、login_page=login。
sc_catalog が空でカタログ導線を持たず、kb_knowledge_base も空で特定 KB に固定せず全KBを横断する設計でした。sp_rectangle_menu も空で、ヘッダに項目バーを持ちません。
デザインは Customer Experience Coral Theme が担っています。中身は Portal Coral Header・Portal Next Experience Footer・navbar_fixed＝true でした。加えてテキスト配色の SCSS 変数群があり、dark_theme は未設定でした。tagline の色だけはポータル側の css_variables で上書きしています。
ホーム（kb_home）は2ウィジェット（knowledge Homepage Search / Knowledge Bases Browse）だけで構成。両方とも public=true・roles空・server/client/link/options/css/html を持ち、依存はなし。login は Login 1件、404 は専用ページを持たず既定にフォールバックしました。
画面の「4 Knowledge Bases / 45 Articles」は REST 実測と一致し、内訳は IT=36 / KCS=4 / Known Error=4 / Knowledge=1。表示されるのは公開（published）記事だけです。

ServiceNow Service Portalはどこを直せば画面が変わる？構成7テーブルを実機で追う — ナレッジ閲覧に特化したKnowledge Portalも、同じ7テーブル構造の上に成り立っています

検証範囲とおことわり

撮影・確認はすべて System Administrator（管理者）ログインでの見た目です。ロールやライセンスが異なる一般ユーザーでは、表示される KB・記事・件数が変わる可能性があります。
ホーム2ウィジェット（kb-homepage-search / kb-bases-browse）のサーバ/クライアントスクリプトが内部で何をするかは、本記事の範囲外です。options のスキーマ・検索クエリの組み立て・記事詳細や KB 一覧の具体的なページ id も同様に扱いません。持つコードの種類・依存の本数・public/roles という外形のみ実測しました。
テーマの SCSS 変数がコンパイル後にどの要素へ効くか、各変数の全量は範囲外です。header/footer・navbar_fixed・テキスト配色変数・tagline 色の上書き・dark_theme 未設定という対応のみ確認しています。
ウィジェットの description は今回対象分がすべて空でした。役割は名称と実描画からの読み取りで、公式の説明文ではありません。
数値・状態はこのPDI（Zurich / OOTB / 2026-07-11 確認）の実測値であり、環境によって異なります。モバイルでの見え方は本記事の範囲外です。

参考URL（ServiceNow 公式ドキュメント・Zurich）

Knowledge Portal を内部のテーブル（sp_portal → sp_page → sp_widget）の観点から見たい場合は、別記事を参照してください。つながりの詳細はポータル1画面は複数テーブルの組み合わせ（sp_portal）にまとめました。

#ServiceNow

#ServiceNow