ServiceNowは何言語で使える？ core_languageの519件と実際に入っている1件を実機で数える

海外拠点にも同じシステムを使わせたい、という話が出たとき、まず「何語まで対応できるのか」を知りたくなります。ServiceNow はこの問いに2段構えで答える作りになっていました。世界の言語を並べたカタログと、この環境に実際に入っている言語。この2つが別のテーブルに分かれています。仕組みを押さえたうえで、素の環境がどうなっているかを数えました。

多言語対応で本当に知りたいこと

海外展開の相談を受けたとき、答えなければならないのは3つです。

この製品はその言語に対応しているのか。対応しているとして、国ごとの違いまで分けられるのか。そしていま自分たちの環境で使える状態なのか。

3つ目がいちばん見落とされます。製品として対応していることと、目の前のインスタンスで使えることは別だからです。この記事はその区別を扱います。

他の多言語機能との位置づけ

ServiceNow の多言語まわりには、役割の違うテーブルがいくつもあります。混同しやすいので先に整理します。

訳文を入れる場所が sys_translated_text や sys_ui_message です。「Incident」を「インシデント」と表示するための対応表がここに入ります。

その手前にあるのが言語そのものの定義です。そもそも「日本語」という言語をシステムが認識していなければ、訳文の置き場も作れません。core_language はこちらに属します。

翻訳の格納先については多言語・翻訳は種類ごとに別テーブル（sys_translated_text）で扱いました。この記事はその1段下、言語の定義そのものを見ます。

core_language は何のためのテーブルか

このテーブルは、世界にどんな言語があるかを標準規格で持っておくためのカタログです。

有益性は2つあります。ひとつは表記のゆれを防げること。「フランス語」と書く人と「French」と書く人がいても、fr-FR という識別子で揃います。

もうひとつは要件定義で具体的な選択肢を出せることです。「フランス語対応」と言われたとき、この表を開けば、フランスのフランス語なのかカナダのフランス語なのかを画面を見ながら決められます。

テーブルの性格は継承元に出る

core_language は他のテーブルを継承していない基底テーブルでした。更新セットで移送される種類のものではなく、製品が持っている純粋な参照データという位置づけです。

一方 sys_language は Application File を継承していました。こちらはアプリケーションの一部として扱われる側です。同じ「言語」でも、カタログと設定で性格が違うことが継承元から読み取れます。

公式は何と言っているか

ServiceNow 自身がフィールドに説明を付けています。sys_language の主要な項目を引くと、仕様がはっきりします。

id の説明は 「BCP-47 Language Tag (Example: de, es-MX)」。言語識別子の国際規格である BCP-47 に従うと明記されています。de や es-MX という例まで書かれていました。

name は「Language Label (Example: German, English UK)」。display_label は「How language will appear in language picker」で、利用者が言語を選ぶ画面での表示名だと分かります。

active は「Indicates whether the language will be available as a user preferred language」。利用者が自分の表示言語として選べるかどうかを決めるフラグです。

text_direction の説明がいちばん具体的でした。「文字・単語・語群が表示される視覚的な順序」と定義したうえで、英語をはじめ多くのヨーロッパ言語は左から右だと書いています。右から左に表示される言語として、ヘブライ語・アラビア語・ペルシア語・ウルドゥー語を名指ししていました。

fallback は「Fallback language」。訳が無いときに代わりに使う言語です。

言語を増やす手段はプラグイン

core_language にカタログがあっても、それだけでは使えません。言語ごとにプラグインが用意されています。

I18N: で始まるプラグインを数えると26件ありました。うち24件が「I18N: <言語名> Translations」という形です。並びはアラビア語・簡体字中国語・チェコ語・オランダ語から始まり、フィンランド語・フランス語・カナダのフランス語・ドイツ語と続きます。ヘブライ語・ハンガリー語・イタリア語・日本語もこの形で用意されていました。

26件すべてが Inactiveです。素の PDI では、言語の訳文が1つも入っていないことになります。

公式説明には実務的な注意まで書かれていました。有効化には20〜40分かかり、その間は他のプラグインやアプリケーションを入れられないとあります。導入計画を立てるときに効く情報です。

カタログを支えている Core i18n というプラグインは有効でした。公式説明は「Adds tables required to support multiple languages」。多言語対応に必要なテーブルを追加する、と書かれています。テーブルは入っているが訳文は別途入れるという構造がここに出ています。

プラグインの有効・無効の見方はプラグイン（v_plugin/sys_plugins）の有効・無効と依存にまとめました。

ここまでを踏まえて、実機はどうなっていたか

3点です。

core_language の519件は「言語と地域の組み合わせ」でした。言語そのものは172種類で、それが249の国・地域と掛け合わさっています。

sys_language は1件だけで、English が入っていました。定義があることと使えることは別です。使うには言語プラグインを入れる必要があります。

英語だけで104件の地域バリエーションがありました。米国英語、英国英語だけの話ではありません。

519件は何を並べたリストなのか

まずリストを開きます。

1行が1つの言語と地域の組み合わせでした。id が es-CU、name が Spanish (Cuba)。キューバのスペイン語だけで1行を占めます。この粒度で519件ぶん並んでいるので、言語そのものの数はもっと少ないと予想が付きます。

持っている列は7つ。それぞれの埋まり方に差がありました。

id と name と iso639_1 は全件埋まっています。iso639_3 が空なのは1件だけ、iso3166 が空なのは3件だけ。

目を引くのが iso639_2 です。519件すべてで空。列は用意されているのに、1件もデータが入っていませんでした。ISO639 という同じ規格ファミリーの列が3つ並んでいて、そのうち1つだけが完全に未使用という状態は、テーブルを開いた瞬間に違和感として目に入ります。

なぜ ISO639 のコードが3種類あるのか

言語コードの規格が複数あるためです。

iso639_1 は2文字のコードで、en、fr、ja のような見慣れた形です。iso639_2 と iso639_3 はどちらも3文字ですが、規格が別で、収録している言語の範囲も違います。

ServiceNow は3種類ぶんの列を用意しておいて、実際には2文字と3文字（639-3）の2つだけを使っていました。将来のために枠だけ残したのか、取り込んだ元データに639-2が含まれていなかったのかは分かりません。

こうした「あるのに使われていない列」は、テーブルを読むときの手がかりになります。フィールドの定義そのものはServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読むで扱いました。

172言語 × 249地域で519件になる

iso639_1 のユニーク数を数えると172。iso3166 のユニーク数は249でした。組み合わせの母数はこの2つで決まります。

単純な掛け算なら4万件を超えますが、実際は519件。存在する組み合わせだけが登録されているということです。

英語の地域バリエーションが104件ある

言語ごとの件数を数えると、偏りがはっきり出ました。

英語が104件。突出しています。フランス語47件。スペイン語29件。アラビア語28件と続きます。

英語104件の内訳を見ると、en-BZ（ベリーズ）、en-BW（ボツワナ）のように、公用語として英語を使う国が網羅されていました。米国と英国とオーストラリアだけではありません。

フランス語47件、アラビア語28件も同じ理由でしょう。旧宗主国の言語や、広い地域で話される言語ほど組み合わせが増えます。

上位4言語の合計は208件で、全体の4割を占めます。残る168言語が311件を分け合う形です。

平均すると1言語あたり2件に届きません。地域展開のある言語はごく一部で、大半は1件か2件だけということになります。

この形は要件確認のときに役立ちます。英語やフランス語なら「どの国か」を必ず聞く。それ以外の言語なら、選択肢がほぼ1つなので確認が要らない場面が多い。上位10言語を頭に入れておくと、確認の手間が減ります。

地域を持たない3件

iso3166 が空だったのは3件。aii と hmn と kar です。

いずれも特定の国に紐づけにくい言語です。国境をまたいで話される言語や、少数民族の言語がここに来ます。

kar（カレン語）はミャンマーとタイの国境地帯で話され、hmn（モン語）は中国・ベトナム・ラオス・タイにまたがります。どこか1つの国コードを付けると、かえって実態と合わなくなる。空にしておくほうが正確でした。

国コードが必須ではない作りになっているので、こうした例外が扱えます。全部を「言語-国」の形に押し込む設計だと、この3件は登録できません。

文字体系の列は30件だけ使われる

iso15924 は文字体系を表す列です。519件中30件だけ値が入っていました。

入っているのはセルビア語、ウズベク語、広東語、パンジャブ語などです。セルビア語は sr-Cyrl-RS（キリル文字）と sr-Latn-RS（ラテン文字）の両方が登録されていました。

同じ言語、同じ国なのに、書く文字が2種類ある。だから id が3つの部分に分かれます。広東語も yue-Hant-HK（繁体字）と yue-Hans-CN（簡体字）で分かれていました。

必要な場合だけ列を使う設計です。文字体系が1つに決まる言語では空のままで済みます。

30件という数も納得できます。同じ言語が複数の文字で書かれる例は、世界的にも多くありません。全件に文字体系を持たせると、ほとんどが同じ値の埋まった列になります。

このあたりは iso639_2 を空にした判断と同じ発想でしょう。必要なところだけ埋めるという方針が、列の使い方に一貫して出ています。

実際に使える言語は1件だけ

ここが本題です。sys_language を開きました。

1件だけでした。English、ID は en、active は true、テキストの向きは Left-to-Right です。

素の PDI に入っている言語は、これだけ。519件のカタログを見た直後にこの画面を開くと、落差が印象に残ります。カタログの豊富さと、実際に動く環境の質素さは、まったく別のものだと分かる場面でした。

519件あるのに、使えるのは1つ。この差が出発点です。

2つのテーブルの役割が違う

core_language は世界にどんな言語があるかのカタログです。ServiceNow が製品として持っている参照データで、この環境で使うかどうかとは関係ありません。

sys_language はこの環境にインストールされた言語です。ここに行が増えるのは、言語プラグインを入れたときになります。

同じ「言語」でも、参照用のマスタと、実際に使う設定は別のテーブルに分かれています。カタログを見て「519言語に対応している」と読むのは誤りです。

text_direction 列があることの意味

sys_language に text_direction という列がありました。値は Left-to-Right です。

この列があるということは、右から左に書く言語を想定しているという意味になります。アラビア語やヘブライ語を入れると、画面全体のレイアウトを反転させる必要が出てきます。

core_language にアラビア語が28件登録されているのも符合します。製品としては RTL を想定した作りになっています。

fallback 列は空だった

fallback という列もありました。この環境では空です。

翻訳が見つからないときに、どの言語で代替するかを指定する列でしょう。英語しか入っていない環境では使い道がありません。

複数言語を入れると意味が出てきます。たとえばカナダ英語を入れて、翻訳が無い文言は米国英語で表示する、といった設定です。

画面文言はどの言語で入っているか

sys_ui_message に8,065件の文言がありました。言語別に数えると偏りがはっきりします。

English が8,060件で、全体の99.9%を占めます。残りは fq が3件、fr が1件、言語が空のものが1件でした。

fr はフランス語ですが、1件しかありません。翻訳が入っているというより、何かの拍子に残ったレコードに見えます。

fq は ISO639-1 に無いコードでした。何を指すのかは特定できていません。テストデータの可能性もあり、ここは分からないままにしておきます。

3件という数から見て、翻訳として機能しているものではないでしょう。標準の環境にこうした断片が残っているのは、それ自体が観察できた事実です。

言語を1件に絞ったまま運用するとどうなるか

多くの日本企業の環境では、英語と日本語の2件になるでしょう。1件のまま使うケースもあります。

英語だけで運用すると、画面が全部英語になります。ServiceNow を触り慣れた担当者には問題ありませんが、申請する一般利用者には負担です。

セルフサービスの入口だけ日本語にして、管理側は英語のまま、という分け方をする現場もあります。利用者ごとに表示言語を持てるので、こうした運用が成り立ちます。

判断の材料は、誰がどの画面を使うかです。全員が同じ画面を使うわけではないので、対象を分けて考えると必要な言語が絞れます。

言語を増やすと何が起きるのか

この環境では English 1件のままですが、増やしたときに何が変わるかは構造から読めます。

sys_language に行が増えると、その言語がユーザー設定の選択肢に出るようになります。個人ごとの表示言語は利用者側の設定として保存されます。設定の持ち方はユーザー設定（sys_user_preference）の二層構造で扱いました。

言語を追加する手段はプラグインです。プラグインの有効・無効と依存関係の見方はプラグイン（v_plugin/sys_plugins）の有効・無効と依存にまとめています。

翻訳が無いところはどうなるか

言語を入れても、全部の文言が翻訳されるわけではありません。標準の画面文言は製品側が用意しますが、自分たちで作ったラベルや選択肢は対象外です。

そこで効いてくるのが fallback です。翻訳が見つからないときに代わりに使う言語を指定しておけば、空白のまま表示される事故を防げます。

英語1件の環境では設定する意味がないので空でした。2言語目を入れる段階で、この列の使い方を決めることになります。

日付や数値の表示も変わる

言語を切り替えると、文字だけでなく日付や数値の書き方も変わります。

同じ2026年8月10日でも、国によって 08/10/2026 と 10/08/2026 に分かれます。英語で104の地域バリエーションがあるのは、この違いを吸収するためでしょう。

日付の扱いはGlideDateTimeで日付と経過時間を扱うで書いたとおり、内部形式と表示形式が分かれています。表示の側が地域設定に従います。

519件のカタログをどう読むか

このテーブルは検索して使うものです。全件を眺める必要はありません。

言語コードで引く

fr で検索すれば、フランス語の47件が出ます。そこから対象の国を選びます。

id は 言語-国 の形なので、fr-CA のように直接指定しても引けます。要件で国が決まっているなら、こちらのほうが速いでしょう。

名前で引く

name は French (Canada) のような英語表記です。国名で検索すると、その国で使われる言語が一覧できます。

Belgium で引けば、オランダ語・フランス語・ドイツ語が出てきます。多言語国家では複数行が返ります。要件を詰めるときに使える引き方です。

存在しない組み合わせもある

519件は実在する組み合わせだけです。172言語と249地域の全掛け合わせではありません。

探して出てこない組み合わせは、このカタログに登録がないということになります。そのときは近い地域を選ぶか、標準に無いものとして扱う判断が要ります。

地域まで分ける設計が意味すること

519件という数を見て、最初は多すぎると感じました。読み進めるうちに、この粒度が必要な理由が見えてきます。

言語だけでは決まらないもの

言語が同じでも、国が変われば変わるものがあります。日付の並び順、小数点の記号、通貨の単位、週の始まり。どれも画面表示に直結します。

en-US と en-GB を分けるのは、綴りの違いだけが理由ではありません。表示形式の設定を別々に持つためです。

fr-FR と fr-CA も同じです。フランスとカナダでは数値の書き方が違います。言語コードだけで持つと、この差を表現できません。

拠点マスタとの関係

利用者がどの国にいるかは、別のテーブルで管理します。拠点の情報は cmn_location に入り、住所と階層を持ちます。構造は拠点マスタ（cmn_location）の住所と階層で扱いました。

拠点と言語は別々の情報です。ベルギーの拠点にいる人が、オランダ語を使うのかフランス語を使うのかは、拠点だけでは決まりません。だから利用者ごとの設定として持つ形になっています。

権限やドメインの分離とは別の話

多拠点展開の相談では、言語とあわせてデータの分離が話題になります。どの拠点のデータを誰が見られるか、という論点です。

担当するのは別の仕組みで、ドメイン分離がその役です。詳しくはドメイン分離は2つのフィールドで決まる（sys_domain）にまとめました。

言語は見え方。ドメインは見える範囲。混ぜて検討すると要件が絡まるので、分けて考えるほうが進みます。

画面文言8,065件の重さを見積もる

sys_ui_message の件数は、多言語化の作業量を測る材料になります。

8,065件のうち8,060件が英語でした。仮に日本語を入れると、対応するぶんのレコードが増えます。製品が用意する翻訳なら自動で入りますが、自分たちで追加した文言は自分たちで訳すことになります。

数字で見ると規模がつかめます。標準の文言が8,000件ある環境で、独自に足したものが数百件あるとします。その数百件が翻訳作業の対象です。

どれが独自の文言かを見分ける

標準か独自かは、更新者やパッケージの情報から判断できます。sys_created_by が admin のものは、後から人が作った可能性が高い。

厳密な区別が要るなら、更新セットに含まれているかを見ます。自分たちが作ったものは更新セットに乗っているはずです。

翻訳の入れ先は用途で分かれる

文言の種類ごとに入るテーブルが違います。画面のメッセージは sys_ui_message、フィールドのラベルは別、選択肢の表示名もまた別です。

sys_translated_text が728件、sys_translated が153件ありました。翻訳の対象になる項目の定義と、実際の訳文が分かれている構造です。

種類ごとに別テーブルという作りは、探すときに手間ですが、翻訳の抜けを潰すときには役立ちます。どの種類が未翻訳かを分けて数えられるためです。

この記事で見た5つのテーブル

5つの役割を整理しておきます。多言語化の検討では、この順番で見ていくことになります。

core_language はカタログで519件。世界の言語と地域の組み合わせです。

sys_language はインストール済みの言語で1件。ここが実際に使える言語を決めます。

sys_ui_message は画面文言で8,065件。うち英語が8,060件でした。

sys_translated_text は訳文で728件、sys_translated は翻訳対象の定義で153件です。

多言語化の話をするとき、この5つを順に見れば現状がつかめます。カタログと実体を混ぜないことが、いちばん大事な点でした。

英語だけを絞った画面です。104件が並びます。国コードの部分だけが違う行が延々と続くので、粒度の細かさが目で分かります。

用語

core_language：言語と地域の組み合わせを並べた参照データ。519件。使えるかどうかとは別。

sys_language：この環境にインストールされている言語。1件ならその言語しか使えない。

ISO639：言語を表すコードの規格。2文字（639-1）と3文字（639-2 / 639-3）があり、収録範囲が違う。

ISO3166：国・地域を表すコードの規格。US、JP のような2文字。

ISO15924：文字体系を表すコードの規格。Latn（ラテン）、Cyrl（キリル）、Hans（簡体字）など。

fallback：翻訳が見つからないときに代わりに使う言語の指定。

実機を見て気づいたこと

使われていない列が答えを教えてくれる

iso639_2 が519件すべて空だったのは、最初は取り込み漏れだと思いました。

調べていくと、639-2 と 639-3 は収録する言語の範囲が違う別規格です。639-3 のほうが網羅性が高い。両方を持つ意味は薄く、片方だけ埋めるのは合理的な判断に見えます。

列が空であること自体が設計の情報でした。テーブルを読むとき、埋まっている列だけでなく空の列も数えると、何を捨てたのかが分かります。

英語104件を見て前提が変わった

英語の地域バリエーションは、せいぜい10や20だと思っていました。104件は予想外です。

内訳を見ると、英語を公用語とする国がほぼ全部入っています。ここまで細かく分ける必要があるのかと最初は思いましたが、日付や通貨の表示形式は国ごとに違います。言語が同じでも地域を分ける理由があるわけです。

グローバル展開の要件を聞くとき「英語対応」で済ませると、この違いを取りこぼします。どの国の英語かまで確認する場面があるということです。

519件はインストールできる言語の数ではない

ここがいちばん間違えやすい。

core_language はカタログで、実際に翻訳が提供されている言語とは別のものです。519件のなかには、ServiceNow が翻訳を出していない言語も含まれているでしょう。

カタログの件数を対応言語数として説明すると、後で困ります。実際に何が入れられるかは、契約と提供状況を確認する話になります。

実務では何に使えるか

多言語化の見積もりで最初に見る場所

海外展開の相談を受けたとき、確認する順番があります。

まず sys_language で、いま何が入っているかを見ます。1件なら、そこから増やす作業が発生します。

次に必要な言語が core_language にあるかを確認します。id で検索すれば、fr-CA のような地域指定まで含めて存在するかが分かります。

最後に sys_ui_message の言語分布を見ます。文言の翻訳がどこまで入っているかの目安になります。翻訳の格納先そのものは多言語・翻訳は種類ごとに別テーブル（sys_translated_text）で扱いました。

地域指定を含めて要件を詰める

「フランス語対応」という要件が来たら、フランスのフランス語なのか、カナダのフランス語なのかを確認します。

core_language を見れば、フランス語だけで47件の選択肢があると示せます。要件定義の場で具体的な選択肢を出せるのは強みです。

画面を開いて一緒に見るのがいちばん速い。抽象的な議論が、リストを絞り込む作業に変わります。

同じことが英語にも当てはまります。104件から選ぶ話になるので、「英語」で止めずに国まで決めます。

独自の文言にも言語の指定が要る

自分たちで追加した画面文言やラベルには、言語を指定する列があります。

英語しか入っていない環境で作ると、言語欄が空のまま作られる場合があります。後から言語を追加したとき、この空欄が問題になります。

フォームのラベルがどこから来るかはフォームのラベルはどこから出るか（sys_documentation）にまとめました。選択肢の文言は別の場所なので、選択肢Choice（sys_choice）：ドロップダウンの中身もあわせて見ておくとよいでしょう。

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

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

• 言語と地域の一覧：/core_language_list.do?sysparm_query=ORDERBYid

• 言語コード別にまとめる：/core_language_list.do?sysparm_query=GROUPBYiso639_1

• 入っている言語：/sys_language_list.do

• 画面文言を言語別にまとめる：/sys_ui_message_list.do?sysparm_query=GROUPBYlanguage

• 翻訳テキスト：/sys_translated_text_list.do

引用した公式説明を自分で開く

この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールド／プロパティのドキュメントです。次のURLを自分のインスタンスで開けば、引用元の原文にあたれます。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINcore_language,sys_language,sys_ui_message^hintISNOTEMPTY

• プラグインの公式説明（引用元）：/v_plugin_list.do?sysparm_query=descriptionISNOTEMPTY

検証範囲とおことわり

Australia の PDI（OOTB）で 2026-08-10 に確認しました。件数はこの環境の実測値です。

確認していないことがあります。言語プラグインはインストールしていません。sys_language は1件のままで、複数言語を入れたときの挙動も見ていません。翻訳された画面が実際にどう表示されるかは未確認です。

sys_ui_message にあった fq というコードが何を指すかは特定できませんでした。分からないまま事実として書いています。

本番環境で入っている言語の数は、契約と導入経緯によって変わります。この記事の1件という数字は、素の PDI の状態です。

なお core_language の Asyrian (Neo-Aramahic) という表記は、OOTB のデータをそのまま引用しています。

関連記事

• 多言語・翻訳は種類ごとに別テーブル（sys_translated_text） — 翻訳がどこに入るか

• フォームのラベルはどこから出るか（sys_documentation） — 画面の文言を追う

• ServiceNowのフィールド設定はどこに保存される？ sys_dictionaryを実機で読む — 列の定義を読む方法