組織テーブル：会社・部署・原価の3枚（core_company）

2026年6月28日 10:33

ServiceNow でユーザーを登録すると、フォームに「Company（会社）」「Department（部署）」「Cost center（コストセンター）」という欄が並びます。CI（構成アイテム）を作っても「Company」「Manufacturer」「Vendor」が出てきます。これらの選択肢の正体が、組織を表す3つのマスタテーブル core_company・cmn_department・cmn_cost_center です。普段は脇役ですが、人とモノを「どの会社の、どの部署の、どの費用単位か」で括る土台になっています。

この記事は、ServiceNow の画面操作には慣れたが、組織まわりのテーブルがどう分かれていて、どう参照で繋がっているのかはこれから確認したい管理者・開発者を想定しています。PDI（Zurich / OOTB）で3つのテーブルを実際に開き、件数・主要フィールド・代表レコードを確かめます。そのうえでユーザー・グループ・ロールや CI とどう参照で結ばれるのかまで追います。

この記事で分かること

組織が core_company（会社）/ cmn_department（部署）/ cmn_cost_center（コストセンター）の3テーブルに分かれていること
3つとも継承元のない独立ルートテーブルで、PDI では会社177件・部署7件・コストセンター8件だったこと
core_company が customer / vendor / manufacturer / primary のフラグで取引先も自社も1テーブルで表すこと
部署・コストセンターが parent による自己参照で階層を持てること
sys_user が company / department / cost_center を参照すること。CI は company / manufacturer / vendor を参照し、参照先はどれも同じ会社マスタであること

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、件数・レコード・参照の紐付け状況が異なります。

組織は3つのテーブルに分かれている

ServiceNow では、組織の情報を1つの大きなテーブルにまとめず、会社・部署・コストセンターの3つに分けて管理します。アプリナビゲーターで「Organization」を開くと、Companies / Departments / Cost Centers というメニューがそれぞれ別々に並びます。

下の画面は、PDI（Zurich / OOTB）の core_company（会社）の一覧です。ACME 系のグループ会社や、取引先のベンダー・製造元がずらりと並んでいます。

この3つのテーブルは、互いに参照で繋がりつつも、それぞれ独立した役割を持っています。全体像を先に図で押さえておきます。

3テーブルの違いは次のとおりです。

3つとも super_class（継承元）が空の独立ルートテーブルです。Incident のように task を継承することも、CI のように cmdb を継承することもありません。組織マスタ専用の器として、独立して用意されています。

core_company：取引先も自社も入る会社テーブル

core_company は「会社」を表すテーブルですが、ここに入るのは自社だけではありません。顧客・ベンダー・製造元といった取引先も、すべて同じ core_company に入ります。区別しているのは、レコードが持つ 真偽値のフラグです。

下の画面は、PDI で primary=true（自社フラグ）が立った1件のフォームです。OOTB では「Your name here」という名前で、導入時に自社名へ置き換える前提のプレースホルダになっています。

会社の種類を分けるフラグは次の4つです。

PDI 実機で件数を数えると、全177件のうち customer=true が17件、vendor=true が78件でした。manufacturer=true は151件、primary=true は1件です。これらのフラグは排他ではありません。実際、vendor=true の会社（SAP America や Macromedia など）はほとんどが manufacturer=true も併せ持っていました。1社が「ベンダーでもあり製造元でもある」という状態を、フラグの組み合わせで自然に表せます。

主なフィールドは次のとおりです。住所や株式情報まで持てる、かなり大きなテーブルです。

中心になるのは name と4つのフラグ、そして parent です。parent は core_company 自身への参照（自己参照）で、これにより会社グループの親子階層を表せます。PDI では parent が設定済みの会社が16件あり、グループ内の階層が一部組まれていました。

cmn_department：部署テーブル

cmn_department は「部署」を表すテーブルです。PDI では7件が登録されていました。内訳は Sales / Development / IT / Customer Support / HR / Product Management / Finance です。

部署フォームを開くと、他の組織テーブルやユーザーへの参照フィールドが並びます。下は IT 部署のフォームです。

cmn_department が持つ主な参照は次のとおりです。

dept_head … 部門長。sys_user を参照
company … 所属会社。core_company を参照
parent … 親部署。cmn_department 自身への自己参照（部署階層）
cost_center … 部署に紐づくコストセンター。cmn_cost_center を参照
primary_contact … 主担当。sys_user を参照

ここで実機ならではの発見があります。PDI の7部署は dept_head（部門長）がすべて設定済みでした。一方で company / cost_center / parent / head_count はいずれも未設定（空）です。OOTB は「部署と部門長」の関係だけを用意し、会社やコストセンターとの紐付けは導入側が行う前提になっています。参照フィールドが用意されていることと、実データが入っていることは別問題だと分かります。

cmn_cost_center：コストセンター（費用集計の単位）

cmn_cost_center は「コストセンター」、つまり費用を集計するための会計上の単位を表すテーブルです。PDI では8件が登録されていました。

8件はすべて account_number（ACN0000x）と manager（管理者）が設定済みでした。中身を表にすると次のとおりです。

コストセンターのフォームを開くと、会計向けらしいフィールドが見えます。下は IT コストセンター（ACN00005）のフォームです。

cmn_cost_center の特徴は次の3点です。

account_number … 会計コード（ACN0000x）。費用を突き合わせるときの手がかりになる
parent … 親コストセンター。自己参照で階層を組める（PDI では未使用＝全件空）
manager / location / valid_from / valid_to … 管理者・場所・有効期間

部署（cmn_department）が「組織図上の固まり」だとすれば、コストセンターは「お金を集計する固まり」です。両者は似ていますが別テーブルで、部署からコストセンターを参照する形で結びつけます。なお cmn_cost_center は sys_domain（ドメイン）フィールドを持つ点が会社・部署と違い、会計データのドメイン分離を意識した作りになっています。

sys_user / CI から組織テーブルへ繋がる

3つの組織テーブルは、それ単体ではなく他のテーブルから参照されて初めて意味を持ちます。代表がユーザー（sys_user）です。1人のユーザーは、会社・部署・コストセンター・場所をそれぞれ独立した参照として持ちます。

下の画面は、PDI の実ユーザー Mildred Gallegas のフォームです。Company=ACME Italy、Department=IT、Cost center=IT がそれぞれ別の参照欄に入っているのが分かります。

この4つの参照は連動しません。部署で IT を選んだからといって、会社やコストセンターが自動で入るわけではありません。それぞれを個別に指定する必要があります（必要なら Business Rule やリファレンス絞り込みで連動させるのは導入側の設計です）。

そして、同じ core_company は CI（cmdb_ci）からも参照されます。CI は company（所有会社）/ manufacturer（製造元）/ vendor（ベンダー）の3つを、いずれも core_company を参照して持っています。1つの会社マスタを、「人（sys_user）」と「モノ（CI）」の両方が共有しているわけです。会社情報を1か所にまとめておく意味が、ここにあります。

実機で確認するときに見るべきURL

最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

# 会社の一覧
https://<YourInstance>/core_company_list.do

# 自社（primary=true）だけ絞る
https://<YourInstance>/core_company_list.do?sysparm_query=primary=true

# 部署の一覧
https://<YourInstance>/cmn_department_list.do

# コストセンターの一覧
https://<YourInstance>/cmn_cost_center_list.do

まとめ

組織は core_company（会社）/ cmn_department（部署）/ cmn_cost_center（コストセンター）の3テーブルに分かれる。3つとも独立ルートテーブルで、PDI では 177 / 7 / 8 件。
core_company は customer / vendor / manufacturer / primary のフラグで取引先も自社も1テーブルで表す。フラグは排他ではなく併用できる。
部署・コストセンターは parent の自己参照で階層を持てる。PDI の部署は dept_head だけ設定済みで、company / cost_center は空だった。
コストセンターは account_number を手がかりに費用を集計する単位で、sys_domain を持つ点が会社・部署と違う。
sys_user は company / department / cost_center を、CI は company / manufacturer / vendor を参照する。参照先はいずれも同じ会社マスタで、会社情報は人とモノの両方から共有される。

組織テーブルが分かると、ユーザー・グループ・ロール（sys_user_grmember / sys_user_has_role）で「人の構造」が読めます。CMDB の cmdb_ci では「モノの構造」が読めます。どちらも「どの会社・部署・費用単位に属するのか」という横串でつながり、ServiceNow のデータ構造が立体的に見えてきます。

ServiceNowのデータはどこに溜まっていつ消える？添付・履歴・ログ・アーカイブを実機で確認 — 会社・部署のマスタも蓄積されるデータの1つ。添付・履歴・ログがどこにどれだけ溜まるかを合わせて確認すると、ServiceNowのデータ全体の置き場所がつながって見える。