通知の宛先を持つ通知デバイス（cmn_notif_device）

2026年6月25日 00:33

ServiceNow で通知が「届く／届かない」を切り分けるとき、通知定義（Notification）だけ見ても答えが出ないことがあります。通知定義が「送る」と判定しても、受け取る相手側に宛先が登録されていなければ届きません。その宛先を持つのが通知デバイス（cmn_notif_device）です。ユーザーごとにメール・SMS・プッシュといった宛先を1行ずつ持ち、どの宛先でどの通知を受け取るかを購読（cmn_notif_message）でつなぎます。

この記事では、通知デバイスと購読を実際のテーブルから読み解きます。デバイスの種別（type）と宛先の持ち方、SMS をメール経由で送るための Service Provider（cmn_notif_service_provider）、そして「特定の人にだけ届かない」を切り分ける順番を、PDI（Zurich / OOTB）の実データで確認します。

ServiceNow の Incident は触ったことがあるが、通知が「相手のどこに届くのか」をこれから整理したい管理者・開発者を想定しています。通知定義そのもの（いつ・誰に・何を）は別記事で扱っているので、ここは受け取る側の宛先に絞ります。

この記事で分かること

通知デバイス（cmn_notif_device）が「ユーザーの宛先」を1行ずつ持つ構造と、type の5種別（Email / SMS / Push / Voice / Instant Message）
メールデバイスの primary_email（主メール）と secondary（副メール）の違い
SMS が「電話番号＋Service Provider の email_suffix」でメール宛先に変換されて送られる仕組み
通知の購読（cmn_notif_message）が user・device・notification をどう結ぶか
PDI の OOTB で各テーブルが何件あるか（デバイス 82 / SMS provider active 8 など）
「特定の人にだけ届かない」をデバイス側から切り分ける順番

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、デバイス・購読・件数・選択肢の内容が異なる場合があります。実際の SMS / プッシュ送信の成否や、メール→SMS ゲートウェイの実挙動には踏み込みません。

通知デバイス（cmn_notif_device）とは

通知デバイスは、1人のユーザーが持つ1つの宛先を表す行です。「System Administrator のメール宛先」「George Washington の SMS 宛先」のように、ユーザーと宛先の組を1行ずつ登録します。1人が複数のデバイス（主メール＋副メール、メール＋SMS）を持てます。

今回の PDI では cmn_notif_device は独立テーブル（super_class 空）で、固有フィールドは 18 でした。宛先として読むべき項目は限られていて、user（誰の）・type（種別）・email_address / phone_number（宛先の値）・primary_email（主メールか）・active（有効か）の5つを押さえれば、その行が「誰のどの宛先か」が分かります。SMS のときだけ service_provider（送信ゲートウェイ）が加わります。

通知定義（sysevent_email_action）は「いつ・誰に・何を」を決めますが、その「誰に」が実際にどの宛先へ届くかは、相手ユーザーのデバイスと購読で決まります。だから通知が届かないとき、定義側だけでなく受け取る側のデバイスが存在し有効かも見る必要があります。

ユーザーの宛先一覧は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/cmn_notif_device_list.do?sysparm_query=ORDERBYtype

デバイスの種別（type）と宛先の持ち方

デバイスの読み方は type から入ると速いです。type によって宛先に使う項目が変わるためです。今回の PDI で確認した type は5種別でした。

Email … email_address にメールアドレスを持ちます。primary_email で主メール（true）か副メール（false）かを区別します。
SMS … phone_number に電話番号を持ち、service_provider（送信ゲートウェイ）を指定します。
Push … push_app（sys_push_application）でモバイルアプリ向けのプッシュ宛先を指定します。
Voice … phone_number を音声通知の宛先に使います。
Instant Message … IM 連携用です。

PDI の OOTB では、82 件のデバイスのうち 80 件が Email、SMS が 2 件で、Push / Voice / Instant Message は 0 件でした。primary_email=true は 79 件です。つまり初期状態は「ユーザーごとに主メールのデバイスが1つ」が標準で、SMS やプッシュは使うときに追加する構成でした。メールデバイスの中には Beth Anglin の「Secondary Mail」のように primary_email=false の副メールもあり、1人が主メールと副メールを持てることが実データから読み取れます。

宛先がメールに偏っている理由は、OOTB の通知が基本メール配信を前提にしているためです。SMS やプッシュを実際に使うには、後述の Service Provider やプッシュアプリの設定が別途必要になります。

SMS は電話番号をメール宛先に変換して送る

SMS デバイスが他と違うのは、ServiceNow が SMS を直接送るのではなく、キャリアの「メール→SMS ゲートウェイ」宛てにメールを送る点です。その変換に使うのが Service Provider（cmn_notif_service_provider）です。

仕組みはシンプルです。SMS デバイスの phone_number に、Service Provider の email_suffix を後ろに付けたアドレスを宛先にします。Verizon なら 1234567890@vtext.com、AT&T なら 1234567890@txt.att.net です。このアドレスにメールを送ると、キャリア側のゲートウェイが SMS に変換して携帯に届けます。だから SMS が届かないときは、Service Provider が active か、email_suffix が正しいキャリアのものかを確認します。

今回の PDI では cmn_notif_service_provider は 232 件あり、そのうち active=true は 8 件でした。active な8件はすべて type=SMS のキャリア定義です。

有効な Service Provider の一覧は、次のURLで確認できます。

https://<YourInstance>/cmn_notif_service_provider_list.do?sysparm_query=active=true

active は8件ですが、テーブル全体には 232 件のキャリア定義が同梱されています。使いたいキャリアが active に無ければ、inactive の定義を有効化するか、新しい Service Provider を作って email_suffix を設定します。

通知の購読（cmn_notif_message）が宛先と通知を結ぶ

デバイス（宛先）があっても、それだけでは「どの通知をそのデバイスで受け取るか」は決まりません。その対応を1行ずつ持つのが購読（cmn_notif_message）です。テーブル名は Notification Messages ですが、ここに入るのは送られたメール本体ではなく、「誰が・どの通知を・どのデバイスで受け取るか」の購読です。送られた1通1通の実体は別テーブル（sys_email）で、本記事の範囲外です。

今回の PDI では独立テーブル（super_class 空）で、固有フィールドは 19 でした。読むべきは user・device・notification の3つで、これで「誰が・どのデバイスで・どの通知を」受け取るかが分かります。

cmn_notif_message は 51 件あり、全件で user と device が埋まっていました。collection（対象テーブル）が入っていたのは 9 件で、incident や problem に紐づく購読でした。group は 0 件で、OOTB の購読はすべてユーザー単位でした。

購読の一覧は、次のURLで確認できます。

https://<YourInstance>/cmn_notif_message_list.do?sysparm_query=ORDERBYuser

購読が device を参照している点が効いてきます。同じユーザーでも、ある通知は主メール、別の通知は SMS、と購読ごとに受け取るデバイスを変えられるためです。逆に、購読がそのデバイスを指していなければ、デバイスが有効でもその通知はそのデバイスに届きません。

「特定の人にだけ届かない」をどこで見るか

通知が全員に届かないなら定義側（sysevent_email_action）や送信側を疑いますが、特定の人にだけ届かないときはデバイス側を見ます。これまでのテーブルを使うと、次の順で切り分けられます。

まず cmn_notif_device にその人の宛先行があるかを見ます。新規ユーザーで主メールデバイスが作られていないと、ここで止まります。
行があれば active=true か、主メール宛なら primary_email=true かを確認します。無効や副メールだけだと、対象の通知に届きません。
email_address / phone_number の宛先の値が正しいかを確認します。
SMS なら service_provider が active か、email_suffix が利用キャリアと合っているかを見ます。ゲートウェイがずれていると、メールは出ても SMS に変換されません。
最後に cmn_notif_message に、その通知とデバイスを結ぶ購読の行があるかを確認します。

デバイスと購読を分けて見ることがポイントです。デバイスが無いのか、デバイスはあるが購読が無いのかで、直す場所が変わるためです。

通知デバイスまわりのテーブル件数

参考として、通知デバイスに関わる主要テーブルの件数を載せます。今回確認した PDI（Zurich / OOTB・2026-06-20確認）の値です。

OOTB の時点で 82 件のデバイスが登録済みで、その大半がデモユーザーの主メールでした。何も設定していないのにメール通知だけは飛ぶのは、各ユーザーに primary_email のデバイスが用意されているためです。SMS やプッシュを足したいときは、デバイス（cmn_notif_device）と、SMS なら Service Provider（cmn_notif_service_provider）の両方をそろえる必要があります。OOTB の通知デバイスの考え方は、公式の Add a new notification delivery channel（デバイス＝配信チャネルの追加手順）でも確認できます。

通知デバイスのポイント

通知デバイス（cmn_notif_device）は「ユーザーの1つの宛先」を1行で持ち、type は Email / SMS / Push / Voice / Instant Message の5種別です。OOTB は大半が Email でした。
メールデバイスは primary_email で主メールと副メールを区別します。今回の PDI では 82 件中 79 件が主メール指定でした。
SMS は電話番号に Service Provider の email_suffix を付けたメール宛先に変換して送ります。キャリアのゲートウェイが SMS に変換するため、Service Provider の active と email_suffix が要点です。
購読（cmn_notif_message）は「誰が・どの通知を・どのデバイスで受け取るか」をつなぎます。テーブル名に message とありますが、送られたメール実体（sys_email）ではありません。
特定の人にだけ届かないときは、デバイスの有無→active / primary_email→宛先の値→（SMSなら）Service Provider→購読の有無、の順で切り分けます。

通知を切り分けるときは、まず「定義側（誰に送るか）を見るのか、受け取る側のデバイス・購読を見るのか」を切り替えるのが近道です。全員に届かないなら定義側、特定の人だけなら受け取り側のデバイスから入ります。

実機で気づいたこと

デバイス全体は82件でしたが、そのうち active なのは49件でした。本文で触れた Email 80件・SMS 2件という内訳は全体の集計で、有効・無効までは踏み込んでいません。3割以上のデバイス行が無効になっている計算で、退職済みユーザーの宛先が消えずに残っている、あるいは重複登録されたデバイスが無効化だけされて放置されている、といった状態を想像させます。通知が届かない調査では、行の有無だけでなく active の値も必ず見る必要があると再確認しました。
購読（cmn_notif_message）のフィールドを辞書で数えていると、本文で扱った user / device / notification のほかに、condition・advanced・notification_filter という列も見つかりました。名前からすると、購読そのものにも条件による絞り込みを持てる作りに見えます。今回の OOTB データではこれらの値までは確認しておらず、どんな条件式が実際に入るのかは分からないままですが、「購読はあるのに来ない」ときは、この条件系フィールドが原因になっている場合も頭の片隅に置いておいたほうがよさそうです。
有効な SMS Service Provider の一覧に Nextel や Sprint が並んでいるのを見て、少し時代を感じました。どちらも今は単独のキャリアとして存在していません（Sprint は T-Mobile に統合、Nextel はサービス終了済み）。OOTB のデモデータは長期間更新されずに引き継がれている値だと分かる一例でした。実際に SMS 通知を設定するときは、この一覧をそのまま信じず、今使っているキャリアのゲートウェイアドレスを別途確認したほうが安全です。

次に読むなら

通知定義そのもの（いつ・誰に・何を、Send when の3種別、生成されるメール実体 sys_email）は、別記事「ServiceNow の Email Notification を実機で確認する」で扱っています。受け取り側を起点にした本記事と、定義側を起点にしたその記事を合わせると、通知が飛ぶまでの全体がつながります。

このあと確認するなら、Notification Preferences 画面でユーザー自身がデバイスと購読をどう編集するか、push_app を使ったプッシュ通知の登録、cmn_notif_message の condition / schedule による受信の絞り込み、そして OOTB で inactive になっている Service Provider の有効化です。これらは本記事で「検証範囲外」とした部分にあたります。

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
通知デバイス：cmn_notif_device テーブル（ユーザーの宛先＝メール/SMS等）
購読：cmn_notif_message テーブル（誰がどの通知をどのデバイスで受け取るか）
Service Provider：cmn_notif_service_provider テーブル（SMS のメール→SMS ゲートウェイ定義）
primary_email：cmn_notif_device の項目（主メールデバイスか）
email_suffix：Service Provider の項目（電話番号の後ろに付くキャリアのメールドメイン）

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

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

通知デバイス一覧      : cmn_notif_device_list.do?sysparm_query=ORDERBYtype
デバイス（種別で分類）  : cmn_notif_device_list.do?sysparm_query=GROUPBYtype
Service Provider(active): cmn_notif_service_provider_list.do?sysparm_query=active=true
通知の購読一覧        : cmn_notif_message_list.do?sysparm_query=ORDERBYuser
デバイスのフィールド    : sys_dictionary_list.do?sysparm_query=name=cmn_notif_device^elementISNOTEMPTY

公式ドキュメントでは次のページが対応します。

Email and SMS notification：メールと SMS の通知の概要。
Add a new notification delivery channel：ユーザーにデバイス（配信チャネル）を追加する手順。
Create a service provider：SMS の Service Provider を作る手順（電話番号＋email_suffix の宛先に触れています）。
Set notification preferences：ユーザーが通知の受け取り方を設定する手順。

テーブルの基本

通知デバイス：Name cmn_notif_device ／ Label Notification Device ／ super_class 空（独立）／固有フィールド 18
購読：Name cmn_notif_message ／ Label Notification Messages ／ super_class 空（独立）／固有フィールド 19
Service Provider：Name cmn_notif_service_provider ／ Label Notification Service Provider ／ super_class sys_metadata（Application File 系）／固有フィールド 11

cmn_notif_device.type の値（OOTBで確認）

Push / Email / SMS / Voice / Instant Message

テーブル件数（OOTB）

cmn_notif_device（全体）… 82（active 49）
cmn_notif_device（type=Email）… 80 ／ type=SMS … 2 ／ Push・Voice・Instant Message … 各 0
cmn_notif_device（primary_email=true）… 79
cmn_notif_message（購読）… 51（collection あり 9 ／ group あり 0）
cmn_notif_service_provider … 232（active 8・すべて SMS）

デバイスの主な固有フィールド（検索用）

user, type, name, email_address, phone_number, primary_email, active, order, service_provider, schedule, group, push_app

購読（cmn_notif_message）の主な固有フィールド（検索用）

user, device, notification, collection, condition, advanced, schedule, group, notification_filter, name

有効な SMS Service Provider の email_suffix（OOTB・active 8件）

AT&T=txt.att.net / Verizon=vtext.com / T-Mobile=tmomail.net / Sprint=messaging.sprintpcs.com / Bell South=sms.bellsouth.com / Cingular=mycingular.com / Nextel=messaging.nextel.com / Qwest=qwestmp.com

検証範囲とおことわり

確認した範囲：cmn_notif_device / cmn_notif_message / cmn_notif_service_provider の super_class（テーブルの位置づけ）、固有フィールド数（デバイス 18 / 購読 19 / provider 11）、cmn_notif_device.type の5種別、各テーブル件数（デバイス 82・active 49・Email 80・SMS 2・primary 79、購読 51・collection 9・group 0、provider 232・active 8）、有効な SMS provider 8件の email_suffix、デバイスと購読の実データ。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。
確認していない範囲：実際の SMS / プッシュ / 音声通知の送信成否、メール→SMS ゲートウェイの実挙動、Notification Preferences 画面での編集操作の反映、push_app によるプッシュ配信、cmn_notif_message の condition / schedule / notification_filter による受信抑制の動作、sys_email への実際の書き込みタイミング。これらは別記事で扱います。

今回は PDI の OOTB（初期設定）を前提に、通知の受け取り側（デバイスと購読）のテーブル構造を確認しました。実環境では、ユーザー登録や通知設計のカスタマイズによってデバイスや購読の数・内容が変わります。