スキル割当はどこにあるか（cmn_skill）

2026年6月22日 21:23

ServiceNow には、担当者を「グループ」だけでなく「スキル（保有能力）」で決める スキルベース割当（Skill-based Assignment） という仕組みがあります。その中心になるのが、スキル定義テーブル cmn_skill と、ユーザー・グループ・タスクにスキルを結びつける中間表です。

この記事では、スキルベース割当を概念だけで説明しません。実際の PDI（Personal Developer Instance）で、cmn_skill 系テーブルとプラグインを確認しました。OOTB のままだと何が存在し、何が存在しないのかを切り分けます。今回の PDI（Zurich / OOTB）では、cmn_skill も AWA も「テーブルごと存在しない」状態でした。その事実と、有効化したときに現れる構造（公式ドキュメント）を並べます。

この記事が想定する読者は、ServiceNow の Incident は触ったことがある管理者・開発者です。「スキルで担当を決める仕組み」がどのテーブルで成り立つのか、なぜ自分の検証環境では見当たらないのか。そこを構造から理解したい方に向けています。

この記事で分かること

スキルベース割当の中心テーブル cmn_skill（Skill）と、その周りの多対多（中間表）の形
ユーザー・グループ・タスクが、それぞれ中間表で cmn_skill にぶら下がる「星形」の関係
Skill Determination（タスクに必要スキルを自動付与）と AWA（スキルで担当者を選ぶ）の役割分担
今回の PDI（Zurich / OOTB）では、これらのテーブルがプラグイン未有効で存在しなかったという実測事実
「ServiceNow のスキル」で検索すると Now Assist の生成AIスキルが多くヒットする、最近の用語の混同

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やプラグインを有効化した環境では、テーブルの有無・件数・内容が異なります。本文中で「公式ドキュメント」と明記した箇所は PDI 実測ではなく一般仕様です。

スキルベース割当とは

ServiceNow のスキルベース割当とは、「このタスクにはこのスキルが必要」「この担当者はこのスキルを持っている」を突き合わせて、最適な担当者を選ぶ仕組みです。グループベースの割当（Assignment Rule や Data Lookup が assignment_group をセットする）は、「どのグループか」までを決めます。スキルベース割当はその先へ進み、グループの中の「誰が一番適任か」までをスキルという軸で絞り込みます。

中心になるのが、スキルを1件1レコードで定義する cmn_skill（Skill） テーブルです。そして「誰が・どのグループが・どのタスクが」そのスキルに関わるかを、3つの多対多（中間表）で表現します。

cmn_skill を中心にした多対多の形

スキルベース割当のテーブル構造を関係図にすると、次のようになります。

スキルベース割当は、cmn_skill（スキル定義）を中心に、3方向の多対多が広がる星形になります（公式ドキュメントに基づく構造で、後述のとおり今回の PDI では未有効）。

ユーザーとスキル（sys_user_has_skill でつなぐ） … 誰がどのスキルを、どのレベルで持っているか
グループとスキル（グループスキル中間表でつなぐ） … グループ単位でどのスキルを扱うか
タスクとスキル（task_m2m_skill でつなぐ） … このタスクを処理するのに必要なスキルは何か

3つとも「多対多」なので、あいだに中間表（M2M）を1枚はさみます。1人が複数スキルを持ち、1スキルを複数人が持つ。1タスクに複数スキルが必要で、1スキルは複数タスクで必要になる。だから直接の参照ではなく、対応関係を1行ずつ持つ中間表で表現します。これは ServiceNow で「ユーザー↔グループ（sys_user_grmember）」「ユーザー↔ロール（sys_user_has_role）」を中間表で持つのと同じ考え方です。

クラス/テーブルの有無は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=nameLIKEskill

公式の Skills Management（Zurich）に、スキル定義とユーザースキルを管理する考え方が説明されています。

Skill Determination と AWA：必要スキルを決めて、担当者を選ぶ

スキルベース割当は、大きく2段階に分かれます。①タスクに必要スキルを付ける（Skill Determination）→ ②そのスキルを持つ担当者を選ぶ（AWA）です。

Skill Determination：タスクに必要なスキルを決める

Skill Determination（com.snc.skill_determination） … タスクに必要なスキルを決める仕組み。タスクの属性（例：Incident の location が France）から、必要スキルを自動で付与するルールです。結果はタスク↔必要スキルの中間表 task_m2m_skill に行として作られます（例：French を mandatory で付与）。

AWA：スキルを持つ担当者を選ぶ

AWA（Advanced Work Assignment / com.glide.awa） … スキルで担当者を選ぶ仕組み。キューに入ったタスクの必要スキルと、エージェント（ユーザー）の保有スキル（sys_user_has_skill）を突き合わせます。一致スキル数・一致レベル数・レベル差の合計をスキルギャップとして採点し、最適な担当者へ配ります。

つまり Skill Determination が「何が必要か」を決め、AWA が「誰に渡すか」を決めるという分業です。どちらも cmn_skill のスキル定義を共通の語彙として使います。

公式の Learn how Skill Determination works（Zurich）に、タスクへ必要スキルを付与する考え方がまとまっています。AWA 側でスキル判定を有効化する手順例は Enable skill determination（Zurich）にあります。

実機で確認したら、テーブルが「存在しなかった」

ここからが本記事の実測です。上の構造を PDI で確かめようとしたところ、cmn_skill にアクセスできませんでした。

Table API で「テーブルが無い」ことを確認

sys_db_object（テーブル定義の一覧）を name で検索してみます。cmn_skill / cmn_skill_role / cmn_skill_level / skill_role / task_skill は1件もヒットしません。Table API で直接アクセスすると、空（0件）ではなく 400「Invalid table」 が返ります。

count cmn_skill ""          -> HTTP 400: Invalid table cmn_skill
count sys_user_has_skill "" -> HTTP 400: Invalid table sys_user_has_skill

「テーブルが空」ではなく「テーブル定義そのものが無い」。これはプラグイン未有効の典型的な状態です。理由を Plugins で確認すると、関係するプラグインがすべて未有効（inactive）でした。

Plugins の一覧で inactive を確認

今回確認した PDI では、Skills Management（com.snc.skills_management）が inactive でした。Skill Determination（com.snc.skill_determination）、Skills seed data、AWA for Incidents も同じく inactive です。Advanced Work Assignment（com.glide.awa）も inactive でした。名前を skill で絞ると 4 件すべて inactive、Advanced Work Assignment で絞ると 10 件すべて inactive です。cmn_skill 系テーブルが無いのは、この Skills Management が未有効だからだと切り分けられます。

Skill Determination プラグインの詳細ページを開くと、未有効（Inactive）であることと、有効化に必要な依存関係が確認できます。

プラグインの状態は、次のURLで確認できます。

https://<YourInstance>/v_plugin_list.do?sysparm_query=nameLIKEskill^ORnameLIKEAdvanced Work Assignment

「ServiceNow のスキル」は今、別の意味になりつつある

調べていて分かったのは、name に "skill" を含むテーブル自体は PDI に多数あることです。ただしその大半は Now Assist（生成AI）の "skill"でした。

sys_db_object を skill で絞ると、sys_gen_ai_skill（Generative AI Skill）が並びます。sn_nowassist_skill_family（Now Assist Skill Family）なども同様です。

つまり「ServiceNow のスキル」という言葉は、いまや2系統に分かれています。①ITSM のスキルベース割当（cmn_skill）と、②生成AIの Now Assist スキル（sys_gen_ai_skill 等）です。今回の PDI では、①の cmn_skill は無く、②の生成AIスキルのテーブルだけが存在しました（ただし sys_gen_ai_skill も件数は 0）。日本語の解説記事を検索しても上位は Now Assist のスキル解説が多く、ここでも同じ傾向が見えます。

担当割当について「スキル」を調べるときは、まず "skill" テーブルが cmn_skill（割当用）なのか sys_gen_ai_skill（生成AI用）なのかを切り分けることが大事です。

スキルが無くても担当は決まる：実在する土台テーブル

スキルベース割当のプラグインが未有効でも、担当決定の土台になるテーブルは OOTB で実在します。

実在する3つの土台テーブル

今回の PDI でも、次のテーブルは実在していました。sys_user_group（Group）・sys_user_grmember（Group Member）・sys_user_has_role（User Role）です。

グループベース割当とスキルベース割当の関係

OOTB の自動割り当て（Assignment Rule や Data Lookup が assignment_group をセットする仕組み）は、これらだけで成立します。スキルベース割当は、この土台の上に「スキル」という軸を足して、グループ内の最適な担当者まで絞る上位レイヤーだと整理できます。

実機で気づいたこと

Table API から cmn_skill へアクセスしたとき、最初は「0件」が返ると予想していました。実際には 400「Invalid table」 で、テーブル定義そのものが存在しないという応答です。「空のテーブル」と「テーブルが無い」は結果画面が似ていても中身は別物で、0件表示と 400 エラーを取り違えると「スキルがまだ登録されていないだけ」と誤って原因を切り分けてしまいます。障害調査の初動では、まず Table API の応答が 400 か 200（0件）かを見分けるのが早いと感じました。同じ切り分け方は cmn_skill 以外のプラグイン依存テーブルでも使えるはずで、「テーブルが見当たらない」系の調査で真っ先に試したい手順だと思います。

もう一つ意外だったのは、プラグイン一覧に AWA for Incidents という Incident 専用のプラグインが存在したことです。Advanced Work Assignment はタスク全般に使える汎用の仕組みだと思い込んでいました。しかし Incident 向けに個別のプラグインが用意されているということは、ServiceNow 側もアプリケーションごとに AWA の適用範囲を分けて管理しているということです。Skills Management を有効化するときは、この個別プラグインの有無も合わせて確認したほうがよさそうです。

Skills seed data プラグインについても新しい発見がありました。公式ブログでは、有効化すると ITSM 向けサンプルスキルが約150件投入されると案内されています（この件数自体は PDI 未確認で、公式ドキュメント記載の一般仕様です）。cmn_skill が「テーブルごと存在しない」今回の環境から見ると、150件という数はかなり大きく感じます。実際に有効化してどんなスキルが入るのか、いつか確認する価値がありそうです。

「ServiceNow のスキル」という言葉は、cmn_skill と sys_gen_ai_skill の2系統に分かれています。この点は、実際にテーブル一覧を skill で絞ってみるまで気づきませんでした。検索エンジンで上位に出てくる解説記事の多くは Now Assist 側を指しています。そのため担当割当のスキル機能を調べているつもりで、生成AIの話にたどり着いてしまう、という遠回りが起きやすい状態だと感じます。

スキルベース割当のポイント

スキルベース割当の中心は cmn_skill（Skill）です。ユーザー・グループ・タスクは、それぞれ中間表で cmn_skill にぶら下がります。中間表は sys_user_has_skill / グループスキル中間表 / task_m2m_skill で、全体は多対多の星形です。
流れは2段階です。Skill Determination が「タスクに必要なスキル」を task_m2m_skill に付与します。AWA は保有スキル（sys_user_has_skill）と突き合わせて担当者を選びます。
今回確認した PDI（Zurich / OOTB）では、cmn_skill / sys_user_has_skill / task_m2m_skill は存在しませんでした。Table API は 0件ではなく 400「Invalid table」を返します。
原因は、Skills Management / Skill Determination / AWA のプラグインがすべて未有効（inactive）だったこと。有効化（＋ seed data）で初めてこれらのテーブルとサンプルスキルが現れます。
「ServiceNow のスキル」は、ITSM 割当の cmn_skill と、生成AIの sys_gen_ai_skill（Now Assist）の2系統に分かれつつあります。どちらの "skill" かを最初に切り分けることが出発点です。

スキルベース割当を調べるときは、まず「プラグインが有効か（cmn_skill が実在するか）」を確認します。有効ならスキル定義・3つの中間表・Skill Determination ルール・AWA のマッチをたどるのが確実です。未有効の検証環境で構造だけ学ぶなら、テーブルの有無を 400 応答で見分けるのが手早い方法です。

次に読むなら

次に確認するなら、プラグインを有効化したあとの AWA（Advanced Work Assignment）のキュー・割当ルールです。もう一つは、Skill Determination ルールの条件（属性→必要スキル）の書き方になります。特に知りたくなるのは、本記事で触れた「グループベース割当（Assignment Rule / Data Lookup）」と「スキルベース割当（AWA）」の使い分けです。両者をどう併用するかが割当設計の要になります。これらは本記事の「2系統」「2段階のフロー」で触れた仕組みの先にあたり、別記事で解説する予定です。

用語

本文で使ったテーブル名・用語をまとめます。

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
cmn_skill：スキルを1件1レコードで定義するテーブル（Skills Management プラグインで導入）
スキルベース割当：タスクの必要スキルと担当者の保有スキルを突き合わせて担当を決める仕組み
Skill Determination：タスクの属性から必要スキルを自動付与するルール（task_m2m_skill に作成）
AWA：Advanced Work Assignment。キューでスキルマッチして担当者へ配る仕組み
中間表（M2M）：多対多の対応関係を1行ずつ持つテーブル（例：sys_user_has_skill）

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

自分のインスタンス名を先頭に付けると、同じ画面が開けます。

skill テーブルの有無 : sys_db_object_list.do?sysparm_query=nameLIKEskill
プラグイン状態       : v_plugin_list.do?sysparm_query=nameLIKEskill^ORnameLIKEAdvanced Work Assignment
Skill Determination  : v_plugin.do?sys_id=com.snc.skill_determination
グループ系テーブル   : sys_db_object_list.do?sysparm_query=nameINsys_user_group,sys_user_grmember,sys_user_has_role

検証範囲とおことわり

確認した範囲：cmn_skill / cmn_skill_role / cmn_skill_level / skill_role / task_skill / sys_user_has_skill が sys_db_object に存在しないこと（あわせて Table API の 400 応答）、Skills Management / Skill Determination / Skills seed data / Advanced Work Assignment / AWA for Incidents プラグインがすべて inactive であること、sys_gen_ai_skill が実在し件数 0 であること、sys_user_group / sys_user_grmember / sys_user_has_role が実在すること。すべて PDI（Zurich / 2026-06-22 確認）の OOTB で取得しています。
確認していない範囲（断定しません・捏造しません）：cmn_skill / sys_user_has_skill / task_m2m_skill のレコード件数や固有フィールド数（テーブル自体が無いため取得不能＝検証範囲外）、プラグイン有効化後の実画面・実データ、Skill Determination ルールの実際の評価、AWA のスキルマッチ・アルゴリズムの実挙動。これらは本文中で「公式ドキュメント」と明記した一般仕様としてのみ言及しています。

今回は PDI の OOTB（初期設定）を前提に、スキルベース割当の「テーブルが存在するかどうか」から確認しました。プラグインを有効化した環境では、cmn_skill 以下のテーブルとサンプルスキルが導入され、件数や画面が本記事と異なります。