ServiceNowのEmployee Centerでコンテンツはどう出し分けられる？ トピックへの紐付けとUser Criteriaを実機で確認
Employee Centerのトピックにカタログ項目やナレッジ記事を追加したいとき、どこで何を紐付ければよいのでしょうか。特定の部署だけに見せたいコンテンツがある場合はどうすればよいのでしょうか。ServiceNowはトピックとコンテンツを1つの中間テーブルで結び、表示可否をUser Criteriaという共通部品で判定する仕組みを持っています。Zurich PDIでトピックを開き、実際に紐づいたコンテンツと設定項目を確認しました。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
出し分けの結果が出るのはこの画面
先に、社員が実際に見る側を出しておきます。Employee Center のトップです。
上から検索欄、Quick links、Popular topics と続きます。右側には自分の Tasks・Requests・Surveys の件数が出ています。
この記事が扱うのは、ここに並ぶタイルがどこから来ているのかです。Popular topics の「Computers」「Email accounts」といったカードはトピック、その下にぶら下がるカタログ項目やナレッジ記事はコンテンツ。両者を結ぶのが中間テーブルです。
そして同じURLを別の社員が開くと、並ぶタイルが変わります。誰に見せるかを決めているのが User Criteria です。設定側のテーブルを追う前に、変わるのはこの画面だと押さえておくと、以降の項目名が何のためにあるのか分かりやすくなります。
ポータルで「人によって出し分けたい」と言われたら
社内ポータルを作ると、必ず出る要望があります。部署ごとに違うものを見せたい。 拠点ごとに違う案内を出したい。
素直に考えると、部署の数だけページを作ることになります。ただそれでは管理できません。1つのページで、見る人によって中身を変える必要があります。
そのとき知りたいのは3つです。何を出し分けられるのか。 誰に見せるかをどう指定するのか。そして条件を複数付けたとき、どう評価されるのか。
クイックリンクという部品
Employee Center のトップに並ぶ入口が Quick Link（sn_ex_sp_quick_link）です。
継承なしの基底テーブルでした。設定というより、その環境のコンテンツという位置づけになります。
公式説明を読むと、1つのリンクで指せる先が複数あると分かります。
content_type：
Defines the type of quick link content
中身の種類を決める項目です。この値によって、後続のどの項目を使うかが変わります。
page は「Opens the specific portal page you select」。選んだポータルページを開きます。
knowledge は「The relevant knowledge article for the quick link」。ナレッジ記事を指します。
catalog_item は「The relevant catalog item for the quick link」でした。
つまりポータルページ・ナレッジ記事・カタログ品目のどれでも指せるということです。利用者から見れば同じタイルですが、飛び先の種類が違います。
表示だけを差し替える項目
見た目を制御する項目も揃っていました。
override_title：
The title displayed instead of the default title given to the page, external link, catal...
リンク先が本来持っているタイトルの代わりに表示するもの、という説明です。override_short_desc も同じ形で、説明文を差し替えます。
ナレッジ記事の正式なタイトルが長いとき、ポータルでは短い言い方にする。そういう調整ができます。
additional_query_params：
Defines additional navigation criteria within a page
ページ内の追加の遷移条件です。同じページでも、パラメータを変えて別の表示にできます。1ページを使い回すときの鍵になります。
icon の説明には推奨サイズまで書かれていました。background_image も同様です。画像を用意する側にとって、ここは実務的な情報になります。
誰に見せるかを決める仕組み
出し分けを担当するのが User Criteria です。ロールとは別の仕組みで、部署・拠点・グループといった属性で対象を決められます。
公式説明でいちばん重要なのが次の項目でした。
user_criteria.match_all：
If set to true, only users who match an element of each condition are given access. If s...
true にすると、各条件のいずれかに一致する利用者だけがアクセスできる、という説明です。条件を複数並べたときの評価方法がここで決まります。
複数の条件を書いたのに想定より多くの人に見えている、という相談は、この項目が false になっている場合があります。設定を足す前に、まずここを確認することになります。
結論：紐付けは1テーブル、表示制御は二重構造
Employee Center（/esc）はService Portal（/sp）と別物ではありません。sp_portal・sp_page・sp_widgetという同じ土台の上で動きます。違うのは、/spがsc_catalog（単一カタログ）とkb_knowledge_base（単一KB）を1個ずつ固定するのに対し、/escはどちらも空で、個々のカタログ項目・ナレッジ記事・クイックリンクをトピック単位で紐付ける点です。
その紐付けを担うのがm2m_connected_contentという1つの中間テーブルです。カタログ項目(sc_cat_item)・ナレッジ記事(kb_knowledge)・クイックリンク(sn_ex_sp_quick_link)という3種類の別々のテーブルを、同じ形の行で束ねています。全161件のうちカタログ項目が117件、ナレッジが41件、クイックリンクが3件でした。
誰に見せるかは、トピック単位（enable_user_criteria_check）とコンテンツ単位という二重の入口でUser Criteria（42件登録）を参照します。ただしこのPDIでは、どのトピックもこのチェックがオフのままで、絞り込みは実際には使われていませんでした。
以下、この3点を実機の画面と件数で裏付けます。
Employee CenterはService Portalの外側にある別物ではない
sp_portalを全9件取得すると、/spと/escの設定差がはっきり出ます。
/sp（Service Portal）はsc_catalogにService Catalog、kb_knowledge_baseにITを指定していて、1つのカタログと1つのKBだけを画面にぶら下げる作りです。/esc（Employee Center）はこの2項目がどちらも空でした。単一のカタログ・KBを固定しない代わりに、sc_catalog_pageとkb_knowledge_pageという専用ページを経由し、そこから先はトピックが導線を担う設計です。この専用ページとタクソノミーの階層構造そのものは、別記事でsp_portal全設定値とテーマを実測しました。今回はその続きとして、トピックに実際のコンテンツがどう紐付くのかに絞って掘り下げます。
この設計の違いは、運用のしやすさにも直結します。/spでカタログを丸ごと差し替えたいなら、sc_catalog欄の参照先を1件書き換えるだけで済みます。一方の/escには、そのような一括の切り替え口がありません。トピックごとに、載せたいカタログ項目やナレッジ記事を1件ずつConnected Contentへ登録していく地道な作業になります。柔軟さと引き換えに、初期構築の手間は/escのほうが増えると考えたほうがよさそうです。
トピックの階層は21件、そこから先を今回は掘り下げる
ここが分かれ目。
topicテーブルをactive=trueで絞ると21件でした。親を持たないトップレベルは「Technology services」と「Risk and compliance」の2件だけで、残りはその配下に3階層で枝分かれしています。
一覧のParent topic列を見ると、業務のまとまりごとに分類されているのが分かります。Computers・Printers・AccessoriesはHardwareの子、WiFi・VPNはNetworkの子という並びです。この階層構造と、ホーム画面のPopular Topicsタイルとの対応関係は別記事で確認済みなので、ここでは繰り返しません。今回知りたいのは、この21個の箱それぞれに、実際どんなコンテンツが何件入っているかという中身の方です。
コンテンツはm2m_connected_contentという1テーブルで束ねられる
順に見る。
トピックとコンテンツを結ぶ実体をsys_db_objectから特定すると、m2m_connected_contentというテーブルに行き着きます。フィールドを見ると、topic（トピックへの参照）に加えてcatalog_item・knowledge・quick_linkという3つの参照列を持っていました。1レコードは1トピックと1コンテンツの組を表し、コンテンツの種類によって埋まる列が変わる設計です。種類そのものはtaxonomy_content_configurationという別テーブルに3件だけ登録されていました。
1つの中間テーブルにまとめた理由は、トピック側の実装をシンプルに保つためだと考えられます。カタログ用・ナレッジ用・クイックリンク用で別々の中間テーブルを用意していたら、トピックのフォームや関連リストもテーブルの数だけ増えていたはずです。content_typeという1列で種類を切り替える設計にしておけば、将来コンテンツの種類が増えても、既存のトピック側のロジックに手を入れずに済みます。
全161件の内訳と、後述する「Computers」トピック1件あたりの内訳を並べました。
カタログ項目が圧倒的多数です。全体の7割を占め、クイックリンクはわずか3件です。1つのポータルにコンテンツを増やしたいとき、まず候補に挙がるのはカタログ項目とナレッジ記事で、クイックリンクは限られた場面だけで使われている実態が件数から読み取れます。
具体例：Computersトピックには17件のコンテンツが紐付いていた
抽象的な話だけでは分かりにくいので、実際に1つのトピックを開いて中身を数えました。「Computers」トピック（Technology services / Hardware / Computers）には17件のコンテンツが紐付いています。内訳はカタログ項目13件、ナレッジ記事4件です。
Sales Laptop・Developer Laptop (Mac)・Office Desktopといった申請用のカタログ項目が並びます。そこにKB0000009・KB0000010といったナレッジ記事も、同じ一覧の中に区別なく混ざっています。管理画面の裏側だけでなく、実際に利用者が見る画面でも同じことが起きているか確かめたくなりました。そこでホームの「Computers」タイルをクリックし、遷移先を見ました。
カードの左上に付くラベルがRequest（カタログ項目）とArticle（ナレッジ記事）で種類を示すだけで、並び方や見た目に差はありません。利用者から見ると「Computersに関する情報と手続きがまとめて出てくる棚」であり、裏でどのテーブルから来ているかを意識する必要がない作りになっています。これがトピック方式の狙いだと分かります。
誰に見せるかはUser Criteriaが二重の入口で判定する
答えは単純だった。
コンテンツの紐付け先が分かったところで、次は表示制御です。「Computers」トピックのフォームを開くと、Topic manager・Topic contributorという2つの欄に加えて、Enable user criteria checkというチェックボックスがありました。
意外な作りでした。このチェックボックスはオフで、直下にServiceNow自身の説明文が出ていました。要約すると「オンにすると、ナビゲーションとPopular Topicsウィジェットでの、このトピックと配下のトピックの表示可否をUser Criteriaで判定する。子トピックにも適用される。オフのままでも、コンテンツ側に設定した条件は別に効く」という内容です。
この一文から、表示制御が2つの独立したスイッチでできていることが読み取れます。1つはトピックそのものをナビゲーションに出すかどうかの判定、もう1つはm2m_connected_content側の個々のコンテンツを出すかどうかの判定です。トピックのチェックをオフにしていても、コンテンツ単位の絞り込みだけは有効という設計になっています。
判定の材料になるのがuser_criteriaテーブルです。42件登録されていました。列を見ると、会社・部門・グループ・拠点・ユーザー個人・ロールという6系統の条件を組み合わせられる汎用部品だと分かります。
「All ACME Corporation employees」は会社で絞る条件です。「All users (delegation demo)」はLuke Wilson・Abel Tuterというユーザー個人を名指しで指定しています。「Any User」はどの列も空で、誰にでも当てはまる条件です。ロール1つだけでなく、部署や個人まで条件にできる作りは、Employee Centerが人事・総務まで含めた全社向けポータルであることと合っています。IT部門のロールだけでは、全社員向けコンテンツの出し分けをまかないきれません。
このユーザー基準はトピック（topic.available_for / not_available_for）だけでなく、クイックリンク・静的コンテンツ・外部リンクにもそれぞれ専用の中間テーブル（sn_ex_sp_quick_link_user_criteria_mtomなど）が用意されています。今回のPDIではどれも0件で、コンテンツの種類ごとに個別の絞り込みを設定できる仕組みだけが用意されている状態でした。
実機で気づいたこと
実物で確かめる。
トピック単位とコンテンツ単位で表示制御が分かれているとは、実物を見るまで想像していませんでした。てっきり「トピックを非公開にすればその中身も全部隠れる」という単純な親子関係だと思い込んでいたのです。ところが説明文を読むと、コンテンツ側の条件はトピックのチェック状態と関係なく独立して効くと明記されています。運用が別部門に分かれている大きな組織では、トピックの公開可否は情報システム部門が管理し、個々のカタログ項目の公開可否はその品目のオーナー部門が管理する、という役割分担を想定しているのだと考えられます。
もう1つ意外だったのが、enable_user_criteria_checkが21トピックすべてでオフになっていた点です。User Criteriaという絞り込みの仕組み自体はOOTBから用意されているのに、素の状態では誰にでも全トピックが見える設定になっています。これは裏を返すと、部署限定にしたいトピックも、導入直後は全員に見えてしまうということです。Risk and complianceのようなトピックが該当します。これはデモ環境固有の事情ではありません。製品の初期値としてそう作られている点は、導入時に必ず確認したほうがよい設定だと感じました。
トピックのフォームにはOutdated Connected Contentという関連リストタブもあり、Computersトピックでは4件が表示されていました。何を基準に「古い」と判定しているのかは今回追いきれていませんが、紐付けたコンテンツが失効・変更されたときに検知する仕組みがありそうだと分かっただけでも収穫でした。
実務では何に使えるか
設定は2か所ある。
新しいコンテンツをEmployee Centerに追加してほしいと頼まれたら、まず「どのトピックに紐付けるか」から考え始めます。カタログ項目を増やしたいだけなら、Service Catalog側にアイテムを作ったあと、対象トピックのConnected Content関連リストに1行追加するだけで済みます。sc_catalog自体を触る必要はありません。
新しいトピックそのものを1つ作るときの手順を整理すると、次の順番になります。まずタクソノミーの配下にtopicレコードを1件作り、親トピックと表示順を決めます。次に、載せたいカタログ項目やナレッジ記事をConnected Content関連リストへ登録する番です。最後に、社外秘の情報を含む場合だけEnable user criteria checkをオンにし、available_forまたはnot_available_forにUser Criteriaを設定します。この最後の一手を飛ばしても画面自体は完成して見えるため、公開範囲の確認を後回しにしがちな点は注意が必要です。
社外秘や特定部署向けの情報を載せたいときは、User Criteriaを先に用意しておく設計にするのが安全です。「経理部のみ」「マネージャーのみ」といった条件はuser_criteriaに1件作っておけば、トピック側のavailable_for／not_available_forと、コンテンツ側の各_user_criteria_mtomテーブルの両方から使い回せます。1回作れば複数箇所で再利用できる部品だと考えると、命名や粒度を最初にそろえておく価値があるはずです。
逆に、ある部署だけに公開されないという相談を受けたときは、まずトピックのEnable user criteria checkがオンかどうかを見ます。オフならトピック側は原因ではなく、コンテンツ側の_user_criteria_mtomを疑う、という順番で切り分けられます。
つまずきやすい点
ここでつまずく。
available_for・not_available_forにUser Criteriaを設定しても、Enable user criteria checkがオフのままだと反映されません（説明文からの解釈で、実際にPDI上でオンオフを切り替えて検証したものではありません）。値を入れたのに変化がないという相談を受けたら、まずこのチェックボックスの状態を確認する価値があります。
数字は正直です。クイックリンクは全体で3件しかなく、Computersトピックでは0件でした。カタログ項目やナレッジ記事に比べて使われる場面が少ない機能だと分かるので、「クイックリンクをたくさん登録するつもりで設計する」のは実態に合わない可能性があります。まずカタログ項目とナレッジ記事の紐付けを軸に設計したほうが、実際の使われ方に近くなりそうです。
content_display_valueは「Catalog Item: Sales Laptop」のように名称を含んだ表示用の文字列でした。参照先のカタログ項目名を変更した場合にこの文字列が自動で追随するのか、更新時にキャッシュされたままになるのかは今回確認していません。一覧をカタログ項目名で検索するときは、念のため参照先の現在の名称と食い違っていないか確かめたほうが安全です。
よくある質問
Q1. 新規プロジェクトはEmployee CenterとService Portalのどちらを使うべきですか
社員向けの総合窓口を作るなら、初期状態から既定ポータルに設定されているEmployee Centerが素直な選択です。カタログ・KB・クイックリンクをトピック単位で柔軟に組み合わせられ、User Criteriaによる出し分けも用意されています。逆に、特定の1業務（例えば単一の申請フォーム専用の画面）に絞った小さなポータルを作るなら、sc_catalogを1個だけ固定できるService Portal型のシンプルさが向いている場面もあります。
Q2. トピックに新しいカタログ項目を追加するにはどこを触りますか
m2m_connected_contentに1行追加します。実務ではトピックのフォームを開き、Connected Content関連リストからNewでカタログ項目・ナレッジ記事・クイックリンクのいずれかを選んで登録する操作になります。sc_catalog本体やkb_knowledge_base本体の設定を変える必要はありません。
Q3. User Criteriaを設定してもトピックに反映されません
Enable user criteria checkがオフになっていないか確認します。オフのままでは、トピック単位のavailable_for／not_available_forは判定に使われません（実際に切り替えて確かめてはおらず、フォーム上の説明文からの解釈です）。それでも解決しない場合は、コンテンツ単位の_user_criteria_mtom側の設定も合わせて確認します。
Q4. クイックリンクがほとんど使われていないのはなぜですか
このPDIの実測では、全体で3件、Computersトピックでは0件でした。カタログ項目・ナレッジ記事に比べて登録数が少ないのは事実ですが、理由そのものはOOTBデータからの推測の域を出ません。用途としては、外部サイトへのリンクや、カタログ・KB化するほどではない簡易な案内に向いていると考えられます。
Q5. Employee Center Proとの違いは何ですか
Employee Center Proは、この記事で扱った標準のEmployee Centerに、Curated Experiencesと呼ばれる上位機能を追加したエディションです。このPDIには標準版のみが入っており、Pro相当の機能範囲は検証していません。
まとめ
先に結論を出す。
Employee Centerは、Service Portalと同じsp_portal／sp_page／sp_widgetという土台の上に、トピックという分類の層を重ねたポータルです。コンテンツの紐付けはm2m_connected_contentという1つのテーブルが担い、カタログ項目・ナレッジ記事・クイックリンクという別々のテーブルを同じ形で束ねています。全161件のうち117件がカタログ項目でした。
表示制御はトピック単位（enable_user_criteria_check）とコンテンツ単位という二重の入口を持ち、どちらもuser_criteriaという共通部品（42件）を参照します。このPDIではどのトピックもチェックがオフのままで、絞り込みの仕組みは用意されているだけで使われていませんでした。導入直後にこの設定を確認しておくかどうかで、意図しない全社公開が起きるかどうかが変わってきます。
用語
topic … トピック本体。タクソノミーの下に階層を持ち、ナビゲーションとPopular Topicsの表示元になる
taxonomy … トピックをまとめる分類そのもの。このPDIでは「Employee」の1件のみ
m2m_connected_content … トピックとカタログ項目／ナレッジ記事／クイックリンクを結ぶ中間テーブル
taxonomy_content_configuration … m2m_connected_contentが扱えるコンテンツの種類（3種）を定義するマスタ
user_criteria … 会社・部門・グループ・拠点・ユーザー・ロールを組み合わせて表示対象を絞る共通部品
実機で調べるときに開いたURL
/topic_list.do … トピック一覧
/m2m_connected_content_list.do?sysparm_query=topic=<トピックのsys_id> … トピックに紐づくコンテンツ一覧
/user_criteria_list.do … User Criteria一覧
/taxonomy_content_configuration_list.do … コンテンツ種類のマスタ
参考リンク
関連記事
既定ポータル Employee Center（/esc）はカタログを持たない：導線はタクソノミーが作る — sp_portal全設定値・テーマ・トピック階層をさらに詳しく確認した前提記事
ServiceNow Service Portalはどこを直せば画面が変わる？ 構成7テーブルを実機で追う — sp_portal／sp_page／sp_widgetという土台構造そのものを扱う前提記事
ServiceNow サービスカタログ完全ガイド：申請フォーム1つが履行タスクに届くまで — 今回紐付けたカタログ項目側の申請フローを扱う実務編
引用した公式説明を自分で開く
この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールド／プロパティのドキュメントです。次のURLを自分のインスタンスで開けば、引用元の原文にあたれます。
フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINm2m_connected_content,not_available_for,available_for^hintISNOTEMPTY
検証環境と未検証範囲
件数はこの環境の実測です。フィールドの公式説明は、製品が持つフィールドドキュメント（sys_documentation）から 2026-08-11 に引用しました。
見落としやすい。
件数・画面はZurich PDI（OOTB）で確認したものです。REST（pdi_client相当の読み取り専用API）と実画面の両方で突き合わせており、推定やサンプリングではありません。本番環境やカスタマイズ済みの環境では数値・設定が異なります。
Enable user criteria checkをオンにした場合の実際の表示挙動は、PDIへの書き込みを避けたため検証していません。本文中の解釈はフォーム上の説明文に基づく推測にとどまります。topic_contributor・topic_managerが実際に設定されている例や、User Criteriaのcompany／department列の詳細条件も確認していません。Employee Center Pro相当の機能範囲とOutdated Connected Contentの判定条件も同様に検証範囲外です。ウィジェットのスクリプト中身やテーマのCSS詳細は、関連記事に譲ります。
