金額は本体の列に入らない（fx_currency_instance）

2026年6月25日 00:47

ServiceNow の資産（Asset）や契約（Contract）、カタログ（Catalog Item）には Cost や Price といった金額の項目があります。この金額は「いくら」だけでなく「どの通貨で」を併せて持ち、別の通貨へ換算されます。それを支えるのが、通貨マスタ（fx_currency）と為替レート（fx_rate）、そして金額の実値を保存するテーブル（fx_currency_instance / fx_price）です。

PDI（Zurich / OOTB）で fx_currency / fx_rate / fx_currency_instance / fx_price の4テーブルを開きました。有効な通貨とレート、そして金額フィールドが入力通貨と参照通貨をどう持つかを実機で確認した記録です。Incident や CMDB は触ったことがあるが、金額項目の裏側は見たことがない、という方に向いています。

この記事で分かること

通貨は fx_currency にマスタとして登録され、OOTB で有効なのは5通貨だったこと
為替レートは fx_rate に通貨ごと1行で保存されること
Cost / Price のような金額項目の値は、本体テーブルではなく fx_currency_instance / fx_price に1行ずつ保存されること
その実値が amount（入力）と reference_amount（換算後）を両方持つこと
金額フィールドの型に Currency / Price / FX Currency があり、どれが実値テーブルを使うか
実機で確認するときに開く一覧URL

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、有効な通貨・レート・フィールド構成が異なる場合があります。

通貨と為替に関わるテーブルの全体像

ServiceNow の多通貨は、1つのテーブルではなく役割の違う複数テーブルで成り立ちます。登場するのは次の4種類です。

fx_currency … 通貨そのものを定義する
fx_rate … レートを持つ
fx_currency_instance / fx_price … 金額項目の実値を持つ
fx_configuration … 換算の設定を持つ

今回確認した PDI（Zurich / OOTB）での件数は次のとおりです。

fx_currency_instance が 8,180 件、fx_price が 5,922 件と多いのは、資産や契約の金額項目1つにつき1行が作られるためです。なぜ本体テーブルの列に直接入れず別テーブルに置くかというと、金額を「入力値」と「換算後の値」の2組で保持し、通貨参照も持たせる必要があるからです。

fx_configuration（FX Currency Configuration）は換算の設定を入れる場所ですが、この PDI の OOTB ではレコードが0件でした。換算設定を自分で作るまでは空、という状態です。このテーブルだけ super_class を持たず Application File 系として定義されており、他の4テーブルとは作りが異なります。

通貨マスタ（fx_currency）

通貨は fx_currency に登録されます。持つのは code（USD など）・name・symbol（$ / ¥ など）・numeric_code（ISO の数値コード）で、構造としてはただのマスタテーブルです。

今回の PDI では fx_currency に138通貨が登録されていましたが、active=true で有効なのは5通貨だけでした。残りの133通貨は無効（active=false）のまま台帳に残っています。つまり導入直後は「通貨を1つずつ作る」のではなく「あらかじめ世界中の通貨が用意されていて、使う通貨だけ有効化する」状態です。

有効な5通貨の内訳

有効な5通貨は次のとおりです。

CHF（Switzerland Francs、記号 CHF、ISO数値コード756）
EUR（Euro、記号 €、978）
GBP（United Kingdom Pounds、記号 £、826）
JPY（Japan Yen、記号 ¥、392）
USD（United States Dollars、記号 $、840）

通貨を増やしたいときは、対象通貨の active を true にするか新規登録します。

通貨マスタに紐づく設定

通貨マスタ自体には、今回確認した範囲で Business Rule・Access Control・Choice・UI Action がいずれも0件でした。マスタは値を持つだけで、換算の処理は金額フィールドの型の側にあります。値を持つテーブルと処理を持つ仕組みは、別になっていました。通貨の挙動をカスタマイズしたいときは、fx_currency のスクリプトではなく対象フィールドの型（Currency / Price / FX Currency）側を確認します。そのほうが目的の場所に早くたどり着けます。

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

https://<YourInstance>/fx_currency_list.do?sysparm_query=active=true^ORDERBYcode

公式の FX Currency fields（Zurich）に、通貨フィールドと参照通貨・換算の考え方が説明されています。

為替レート（fx_rate）

レートは fx_rate に、通貨ごと1行で保存されます。固有フィールドは8個ありますが、中心となるのは currency（→ fx_currency）と rate の2つです。

基準通貨に対する各通貨のレート

今回の PDI では fx_rate が1,973件ありました。currency 列で通貨を指し、rate 列にその通貨のレート値が入ります。サンプルでは USD=1.1595、CNY=7.8367、INR=110.9585 のような値が並んでいました。レートは「USD→JPY」のような通貨ペアの組み合わせでは持たず、「ある基準に対する各通貨の値」として1通貨1行で持ちます。2通貨間の換算が必要になったときは、この基準値どうしを組み合わせて計算する仕組みです。

レートをどこから更新するか（手動入力か外部連携か）は、この記事の検証範囲外です。今回は fx_rate に通貨別レートが保存されているという構造の確認にとどめます。

レートの一覧は、次のURLで確認できます。

https://<YourInstance>/fx_rate_list.do?sysparm_query=ORDERBYcurrency

金額フィールドの実値はどこに入るか（fx_currency_instance）

資産の Cost や契約の Monthly cost のような金額項目に値を入れると、その値は本体レコードの列ではなく fx_currency_instance に1行として保存されます。その1行は、どのテーブルのどのフィールドの値かを table / field / id で指し、金額と通貨を入力側と換算側の2組で持ちます。

fx_currency_instance の主なフィールド

fx_currency_instance は固有フィールドを13個持ち、主なものは次のとおりです。

実レコードを開くと、入力した通貨での amount と、参照通貨に換算した reference_amount が並んで保存されているのが見えます。今回の PDI では入力通貨も参照通貨も USD でした。そのため amount と reference_amount は同じ値（例: 1,799.99 USD → 1,799.99 USD）です。入力通貨と参照通貨が違うときに、この reference 側へレートでの換算結果が入ります。

実際に値を持っていたテーブル.フィールド

今回 fx_currency_instance が指していたのは、資産・契約・カタログの金額項目でした。

alm_hardware.cost / alm_hardware.residual / alm_hardware.depreciated_amount / alm_hardware.salvage_value
alm_consumable.cost / pc_vendor_cat_item.list_price / sc_cat_item.list_price
ast_contract.monthly_cost / ast_contract.yearly_cost

alm_hardware だけで4つの金額フィールドを持つのに対し、ast_contract は2つでした。ハードウェア資産は取得原価・残存簿価・減価償却後の価格・処分価格まで別々に持ちます。契約は月額と年額の2軸で足りるので、この管理粒度の違いがそのままフィールド数に表れていました。また pc_vendor_cat_item.list_price と sc_cat_item.list_price のように、仕入れ側（ベンダーカタログ）と販売側（サービスカタログ）の両方に list_price が存在していました。これも金額1つにつき1行という設計を裏付けています。金額を持つレコードを保存するたびに、対応する1行がここに作られます。

fx_price との違い

なお価格（Price）型のフィールドは、同じ構造の専用テーブル fx_price に保存されます。fx_price は fx_currency_instance のフィールドに加えて parent / type を持ち、固有フィールドは合計15個です。これで繰り返し課金（Recurring price）のような価格の親子関係を表せます。今回の PDI では fx_price が5,922件ありました。

金額の実値は、次のURLで確認できます。

https://<YourInstance>/fx_currency_instance_list.do?sysparm_query=ORDERBYtable

公式の Understanding how FX Currency field conversions work（Zurich）に、入力値が参照通貨へ換算されて保存される流れが説明されています。

金額フィールドの型（Currency / Price / FX Currency）

金額項目がどのテーブルに値を持つかは、フィールドの型で決まります。今回の PDI で確認できた型は3つです。

OOTBでの型別フィールド数

Currency 型（internal_type=currency）… 今回の PDI で31フィールドが使用。値は fx_currency_instance に入る。例: ast_contract.total_cost / core_company.market_cap / alm_asset.depreciated_amount。
Price 型（internal_type=price）… 13フィールドが使用。値は fx_price に入る。例: sc_cat_item.price / cmdb_model.cost / service_offering.price。
FX Currency 型（internal_type=currency2）… 新しい FX 通貨型。型は存在しますが、この PDI の OOTB では使用フィールドが0件でした。利用するには FX Currency フィールドと換算設定（fx_configuration）を自分で作る必要があります。

同じ「金額」でも、Currency 型と Price 型で保存先テーブルが分かれる点に注意します。どの型かは sys_dictionary の internal_type で確認できます。今回の例では、sc_cat_item.price や cmdb_model.cost のような「販売・提供する側の値付け」に Price 型が使われていました。一方 ast_contract.total_cost や alm_asset.depreciated_amount のような「保有資産・契約の金額管理」には Currency 型が使われていました。実務でフィールドを追加するときも、カタログ的に値付けするのか資産の金額を保管するのかで型の候補を絞り込めます。

固有フィールドは、次のURLで一覧できます。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=fx_currency^elementISNOTEMPTY

公式の Configuring FX Currency field behavior（Zurich）に、FX Currency フィールドの作成と表示パラメータの設定が説明されています。

通貨・為替まわりのポイント

通貨は fx_currency にマスタとして登録され、今回の PDI では138通貨のうち active な5通貨（CHF/EUR/GBP/JPY/USD）だけが有効でした。
レートは fx_rate に通貨ごと1行で保存され、currency（→fx_currency）と rate を持ちます。
Cost / Price のような金額項目の値は、本体テーブルの列には入りません。fx_currency_instance（Currency 型）または fx_price（Price 型）に1行ずつ保存されます。
実値の行は amount / currency（入力）と reference_amount / reference_currency（換算後）を両方持ちます。入力通貨と参照通貨が違うときに reference 側へ換算が入ります。
金額フィールドの型は Currency / Price / FX Currency の3つを確認しました。FX Currency 型（currency2）はこの PDI の OOTB では未使用で、利用には fx_configuration の作成が必要です。

金額項目を見るときは、本体レコードの値だけで判断しないほうが確実です。裏にある fx_currency_instance / fx_price の amount と reference の2組をセットで見ると、多通貨と換算の動きが追えます。

実機で気づいたこと

今回の確認でいちばん意外だったのは、fx_currency に登録済みの138通貨のうち、有効（active=true）なのはわずか5通貨だった点です。多通貨対応というと「使う分だけ足していく」イメージがありましたが、実際は先に世界中の通貨がマスタへ一括投入済みで、そこから使う通貨だけ active にする設計でした。導入時の作業は、通貨を新しく作るというより、無効化されている通貨を有効化することに近いと気づきます。

もう1つは、通貨マスタ（fx_currency）自体には Business Rule・Access Control・Choice・UI Action が1件も紐づいていなかったことです。一方で fx_rate には有効な Business Rule が1件ありました。マスタは値を持つだけの器で、換算のロジックはフィールド型（Currency / Price / FX Currency）側に実装されています。レート側だけに自動処理の入り口がある、という役割分担が実機を見て初めてはっきりしました。

fx_configuration（FX Currency Configuration）だけ super_class を持ちません。Application File 系のテーブルとして定義されていたのも目に留まりました。他の4テーブルと構造が違うのは、これが利用者側が明示的に作る「設定」だからでしょう。プラットフォームが最初から埋めておく「マスタ・実値データ」とは性質が異なります。

さらに fx_currency_instance が13フィールド、fx_price が15フィールドで、その差はちょうど今回追加された parent と type の2つでした。実値テーブルの拡張は、必要な差分だけに絞られている印象です。設計に一貫性を感じました。

次に読むなら

今回確認したのは、実値テーブルの構造までです。次に見たいのが、FX Currency Configuration（fx_configuration）を作成したときの実際の換算挙動。もう1つがセッション通貨やロケール（glide.system.locale）による表示換算です。換算設定を入れた状態での reference_amount の変化や、レポート集計時の通貨統一は別記事で扱います。今回無効のままだった133通貨のうち、実際に active にすると fx_rate 側の挙動がどう変わるのかも合わせて確認したいところです。

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
fx_currency：通貨マスタ（Currencies）
fx_rate：為替レート（Exchange Rates）
fx_currency_instance：Currency 型フィールドの実値（Currency Instances）
fx_price：Price 型フィールドの実値（Prices）
fx_configuration：換算の設定を持つテーブル（FX Currency Configuration）
amount／reference_amount：入力した通貨での金額と、参照通貨に換算した後の金額
reference_currency：換算先の参照通貨（保存される換算後の通貨）

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

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

有効な通貨   : fx_currency_list.do?sysparm_query=active=true^ORDERBYcode
為替レート   : fx_rate_list.do?sysparm_query=ORDERBYcurrency
金額の実値   : fx_currency_instance_list.do?sysparm_query=ORDERBYtable
通貨の固有項目: sys_dictionary_list.do?sysparm_query=name=fx_currency^elementISNOTEMPTY

ServiceNowのデータはどこに溜まっていつ消える？添付・履歴・ログ・アーカイブを実機で確認 — 通貨や為替の実値データも含め、ServiceNowのテーブルにデータがどう溜まりいつ消えるのかを横断的に確認できる

検証範囲とおことわり

確認した範囲（すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得）
fx_currency / fx_rate / fx_currency_instance / fx_price / fx_configuration の実在と件数、固有フィールド数
主要フィールドと参照先、active な通貨5件
金額フィールド型（currency2 / currency / price）の OOTB 利用状況
fx_currency_instance が指す table.field、周辺設定の件数
確認していない範囲（断定しません）。これらは別記事で扱います
FX Currency Configuration を作成したときの実換算挙動
入力通貨≠参照通貨でのレート換算の結果
セッション通貨やロケール（glide.system.locale）による表示換算
fx_rate の更新元（手動／外部連携）
レポート集計時の通貨統一の内部処理

今回は PDI の OOTB（初期設定）を前提に、通貨・為替テーブルの構造を確認しました。実環境では、有効な通貨やレート、金額フィールドの構成がカスタマイズによって変わります。