Inventory（alm_stockroom）：在庫の置き場と移送を追う
「新しいPCを1台、大阪の拠点に送ってほしい」。この一言の裏で、資産管理は3つのことを同時に扱っています。今どこに何台あるか。どこからどこへ運ぶか。運び終わったあと、その1台の状態はどう変わるか。
ServiceNow の Inventory メニューは、この3つをそれぞれ別のテーブルで持っています。置き場（alm_stockroom）、移送オーダー（alm_transfer_order）、そして資産そのものの状態（alm_asset の install_status）。今回は実機のデータを追いながら、在庫が動くときに何がどう記録されるのかを確認します。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-26）。本番環境では設定が異なります。
在庫が動くときの登場人物
先に全体の流れを見ておきます。
左が補充ルール。在庫が下限を割ったら発注や移送のきっかけを作ります。真ん中が移送オーダーと明細で、「どこからどこへ、何を、何個」を持ちます。右が資産で、届いたあとに状態が変わる側です。
置き場：資産が「今いる場所」
実測9件
alm_stockroom は在庫の置き場を表すテーブルです。PDI には9件入っていました。
名前を見ると、San Diego 周辺の拠点が並びます。Pickup/Dropoff と付くものが5件、Warehouse と付くものが4件。San Francisco と Santa Monica の倉庫には Manager として Aileen Mottern が設定されていました。
持っているフィールドは素直です。name / type / location（→cmn_location）/ manager（→sys_user）/ assignment_group。加えて latitude と longitude があります。緯度経度を置き場自身が持つのは、配送距離や最寄り拠点の判定を想定した作りと読めます。
external という真偽フィールドもあり、実測では9件すべて false でした。社外の置き場を区別するための項目です。
置き場には6種類ある
type は alm_stockroom_type への参照で、実測6件でした。
説明が入っているのは3件だけです。On site は「顧客の敷地内の倉庫」、FSL は Forward Shipping Location、PUDO は Pick Up/Drop out location。Field Agent には「現場作業者と直接ひもづく仮想倉庫」という説明がありました。
現場作業者が持ち歩く部品を「仮想の倉庫」として扱うのは面白い割り切りです。作業車のトランクも在庫の一種、と考えれば、部品の所在をすべて同じ仕組みで追えます。
PUDO も現場感のある種類です。受け取りと引き渡しだけを行う窓口で、長く保管する場所ではありません。実データでも Pickup/Dropoff と名の付く拠点が5件あり、中央倉庫から送られた機器の受け渡し口として並んでいました。
種類を分ける意味は、在庫の見え方を変えられることにあります。中央倉庫の在庫は「まだ配れる数」、受け渡し拠点の在庫は「もう相手が決まっている数」。同じ100件でも、どの種類の置き場にあるかで意味が変わります。種類を持たせておけば、この区別を条件1つで取り出せます。
実データでは9件のうち7件が Warehouse、1件が Central Warehouse、残る1件は type が空でした。中央倉庫が1つあり、そこから各拠点へ配る形が読み取れます。
資産の状態：在庫なのか、使用中なのか
置き場の話をする前に、資産側の状態を数えておきます。alm_asset の install_status がそれです。
選択肢は9つ用意されていました。On order / In stock / In transit / In use / Consumed / In maintenance / Retired / Missing / Build。買う前から捨てたあとまで、資産の一生をひととおり表せます。
実データは4つの値に集中していました。Consumed が1,774件で最多、In use が944件、In stock が100件、Retired が1件。残る5つは0件です。
ここで在庫として扱えるのは In stock の100件だけになります。実際、置き場が入っている資産を数えると 99件 でした。内訳は Southern California Warehouse が70件、San Diego South Warehouse が28件、San Diego North の受け渡し拠点が1件。
使用中の資産は誰かの手元にあるので、置き場は空。消費済みの資産も同じです。置き場が入るのは「今、倉庫の棚にあるもの」だけ。この単純な規則が、2,819件と99件という数字の差に表れています。
資産テーブルは3つに枝分かれしている
在庫を数えるとき、どのテーブルを見ているかで数字が変わります。実測した件数はこうでした。
alm_asset（基底）… 2,819件
alm_consumable（消耗品）… 1,791件
alm_hardware（ハードウェア）… 904件
alm_license（ライセンス）… 77件
消耗品が1,791件で、資産全体の6割を超えます。ケーブルやトナーのように「1本ずつ資産タグを貼らないもの」が、まとめてここに入る形です。
消耗品の1行は「1個」ではなく「ある置き場にある、あるモデルのまとまり」を表します。だから置き場ごとに行が増え、件数が膨らみます。ハードウェアの904件は1台ずつの行なので、こちらは実際の台数に近い数字です。
在庫の会話で「資産は何件ありますか」と聞かれたら、この3つのどれを指しているかを確かめたほうが安全です。基底テーブルで答えると、消耗品の行が大量に混ざった数字になります。
置き場と住所は別のもの
置き場（alm_stockroom）は location で cmn_location を参照しています。この2つは似ていますが、粒度が違います。
住所（cmn_location）は建物や部屋の単位です。「615 North Bush Street, Santa Ana,CA」のような、地図で指せる場所を表します。置き場はその中にある棚やエリアの単位。同じ住所に「予備機の棚」と「返却待ちの棚」を別々に持つこともできます。
分けておく利点は、住所が変わっても置き場の名前が変わらないことです。オフィス移転で住所を差し替えても、「San Francisco Warehouse」という置き場の名前とそこに紐づく資産はそのまま残ります。
逆に、置き場を作らず住所だけで在庫を管理すると、棚の区別ができません。同じ建物の中で「使える在庫」と「修理待ち」を分けたくなったときに困ります。
補充ルール：下限を割ったら何個発注するか
alm_stock_rule は6件でした。
1行が「このモデルを、この置き場で、何個を切ったら、何個仕入れるか」を表します。Alienware M14x なら Southern California Warehouse で下限10、発注数40。ラック製品は下限5で発注数10や15。
補充元を表す restocking_option は、実測6件すべて Vendor でした。ベンダーから仕入れる設定です。公式ドキュメントによれば、別の置き場から移送して補う設定や、管理者へメールで知らせる設定も選べます。
下限と発注数の組み合わせは、そのまま在庫方針になります。下限10・発注数40なら、切れる前にまとめて仕入れる。下限5・発注数10なら、こまめに少しずつ。回転の速さと保管場所の広さで、この2つの数字が決まります。
自動実行の仕組みはこのPDIには入っていなかった
補充ルールを定期的に評価するジョブがあるはずだと考え、スケジュールジョブを探しました。sysauto（スケジュールジョブの基底テーブル）を「Stock」で検索したところ、該当は 0件。この PDI には、補充ルールを自動で走らせるジョブが入っていませんでした。
ルールの定義は入っているが、それを回す仕掛けは別に必要、ということです。実際の運用では、この部分がプラグインや追加設定で入ってきます。
移送オーダー：どこからどこへ運ぶか
alm_transfer_order は6件ありました。
番号は TO で始まります。TO0000002 から TO0000006、そして TO0010001。stage を見ると、Delivered が3件、Shipment Preparation が2件、Draft が1件。Delivered の3件には type として Procurement（調達）が入っていました。
From と To はどちらも置き場への参照です。実データの多くが「Southern California Warehouse から San Diego の各拠点へ」という向きで、中央倉庫から配る流れが見えます。
stage は8段階ある
stage は workflow 型のフィールドです。選択肢を実測すると8つありました。
順に Draft / Requested / Shipment Preparation / Partially Shipped / Fully Shipped。さらに Received / Delivered / Cancelled と続きます。Partially Shipped（一部出荷）があるのは、1つのオーダーに複数の明細がぶら下がるからです。3行のうち2行だけ出荷した状態を、オーダー全体としてどう呼ぶか。その答えが「一部出荷」になります。
明細側の stage は7つ。Partially / Fully Shipped の代わりに In Transit が入ります。1行ぶんの荷物は分割されないので、一部出荷という状態が要りません。オーダーと明細で段階の刻み方が違うのは、この事情によります。
1件開いてみる：TO0000004
Delivered になっている移送オーダーを開きます。
From stockroom は Southern California Warehouse。From location は 615 North Bush Street, Santa Ana,CA でした。To stockroom は San Diego Border - Pickup/Dropoff。To location は 4492 Camino De La Plaza, San Ysidro,CA です。Requested date は 2021-10-04 06:39:09 で、Delivery by date は空でした。
置き場と住所が両方ある点に注目してください。置き場は「棚の単位」、ロケーションは「住所の単位」。1つの住所に複数の置き場が入ることもあるので、両方を持っています。
Drop Off というチェックボックスもありました。置き配のように、受け取り手を待たずに置いてくる運びかたを表す項目です。受け渡し拠点（PUDO）と組み合わせると、「窓口に置いてくるだけ」という運用を1つのチェックで表せます。
Delivery by date が空だったのも見どころです。この移送には期限が設定されていませんでした。急ぎでない補充ならこれで足りますが、代替機の手配のように期限が要る移送では、ここに日付が入ります。入っていれば遅れの検出に使えます。
明細に並ぶ4つの数量
フォーム下部の Transfer Order Lines に、明細が1行ぶら下がっていました。TOL0000003、モデルは Asus G Series。数量の列が4つ並びます。Quantity requested が1、Quantity received が1、Quantity remaining が0、Quantity returned が0。
要求した1個が届き、残りは0、返却も0。この4つを並べておけば、どの段階でいくつ止まっているかが1行で分かります。
Stage の列はドットの並びで表示されていました。7つのうち6つめが緑になっており、Delivered まで進んだことを示します。明細の stage が7段階だったので、表示と選択肢の数が一致していました。
明細が持つ他のフィールド
辞書を見ると、明細には運用で効く項目がいくつも入っています。tracking_number（追跡番号）、ship_date（出荷日）、vendor（→core_company）、transferred_for（誰のための移送か）。返却まわりも return_from_tol と return_reason の2本があり、返す動きも記録できます。
そして request_line が sc_req_item を参照していました。サービスカタログの申請1行から移送が起きる導線です。「PCを1台ください」という申請が、そのまま「倉庫からこの拠点へ1台送る」という移送に繋がる。実データでは値が入っていませんでしたが、参照の口は用意されています。
返送も同じ仕組みで持つ
移送オーダーには return_from_transfer_order というフィールドがあります。参照先は移送オーダー自身。つまり「この移送は、あの移送の返送である」という関係を、同じテーブルの中で持てます。
明細側にも return_from_tol と return_reason の2本があり、返す理由まで残せます。行った先から戻ってくる動きを、別の仕組みではなく同じテーブルで扱う。往路と復路を同じ形で記録できるので、集計のときに特別扱いが要りません。
故障品を修理拠点へ送り返す、貸出機を返却する。こうした逆向きの動きも移送オーダーとして起票すれば、在庫の増減が自動的に辻褄の合う形になります。
数字で見たこの PDI の在庫
実測を並べると、この PDI の在庫はこういう状態でした。
置き場は9件。うち中央倉庫が1件、受け渡し拠点が5件
在庫として棚にあるのは100件（In stock）。置き場が入っているのは99件
補充ルールは6件で、すべてベンダーからの仕入れ
移送オーダーは6件。3件が完了、2件が出荷準備、1件が下書き
移送明細も6件。完了した3件は要求数と受領数が一致
資産2,819件のうち、在庫として動いているのは100件ほど。残りは使用中か消費済みです。台帳の大半は「動かないもの」で、在庫管理が扱うのはその一部だけ。この比率は実際の現場でも近い形になります。
実データを読むときに気をつける3点
在庫の数え方はテーブルで変わる
すでに触れたとおり、alm_asset と alm_hardware と alm_consumable では数字が違います。在庫を報告するときは、テーブル名と install_status の条件をセットで示すのが確実です。「In stock の hardware が何件」まで言えば誤解が起きません。
stage は自動では進まない
移送オーダーの stage は workflow 型で、8段階が定義されています。ただし段階を進めるのは、画面のボタンや裏側の処理です。レコードを直接書き換えて stage だけ変えると、関連する数量や資産の状態が置き去りになります。実データを触るときは、必ず画面の操作で進めるのが安全です。
数量の4本は役割が違う
quantity_requested は要求、quantity_received は受領、quantity_remaining は残り、quantity_returned は返却。この4本は独立した記録なので、足し引きの関係が常に成り立つとは限りません。返却が発生すると、受領と返却の両方に数字が入ります。「届いた数」を知りたいのか「今ある数」を知りたいのかで、見るべき列が変わります。
どこから触るか
/alm_stockroom_list.do … 置き場の一覧
/alm_stockroom_type_list.do … 置き場の種類
/alm_asset_list.do?sysparm_query=GROUPBYinstall_status … 資産を状態で数える
/alm_stock_rule_list.do … 補充ルール
/alm_transfer_order_list.do … 移送オーダー
/alm_transfer_order_line_list.do … 移送明細
資産の一覧で stockroom 列を出しておくと、在庫と使用中の違いが目で分かります。
まとめ
在庫管理は「場所」と「移動」と「状態」の3つに分かれていました。
置き場が場所を持ち、6種類のタイプで役割を分ける。移送オーダーと明細が移動を持ち、8段階と7段階の stage で進み具合を刻む。資産の install_status が状態を持ち、在庫か使用中か消費済みかを表す。補充ルールはその手前にあって、動き出すきっかけを作ります。
数量フィールドが4本に分かれている点と、オーダーと明細で段階の刻み方が違う点。この2つを押さえておくと、実データを見たときに迷いません。
用語
置き場（alm_stockroom） … 資産が今ある棚。住所（cmn_location）とは別の単位
置き場の種類（alm_stockroom_type） … Warehouse / Central Warehouse / On site / FSL / PUDO / Field Agent
install_status … 資産の状態。In stock のときだけ置き場を持つ
補充ルール（alm_stock_rule） … 下限（threshold）と発注数（order_size）と補充元
移送オーダー（alm_transfer_order） … どこからどこへ運ぶかの単位。stage は8段階
移送明細（alm_transfer_order_line） … 何を何個運ぶかの単位。stage は7段階、数量は4本
Drop Off … 受け取り手を待たずに置いてくる運びかたを表すチェック
自分の環境で確認するときのURL
/alm_stockroom_list.do?sysparm_query=ORDERBYname（置き場9件）
/alm_stockroom_type_list.do（種類6件）
/alm_asset_list.do?sysparm_query=GROUPBYinstall_status（状態別の内訳）
/alm_stock_rule_list.do（補充ルール6件）
/alm_transfer_order_list.do（移送オーダー6件）
/alm_transfer_order.do?sys_id=...（TO0000004 のフォームと明細）
実測の要点（再掲）
alm_stockroom 9件 / alm_stockroom_type 6件 / alm_stock_rule 6件 / alm_transfer_order 6件 / 明細6件
alm_asset 2,819件の内訳は Consumed 1,774 / In use 944 / In stock 100 / Retired 1
置き場が入っている資産は99件（Southern California 70 / San Diego South 28 / San Diego North 1）
補充ルールは6件すべて restocking_option=Vendor。threshold は5または10、order_size は10〜50
stage は移送オーダーが8段階、移送明細が7段階。TO0000004 は Delivered、明細は要求1・受領1
sysauto を「Stock」で検索した結果は0件。補充ルールを回すジョブはこの PDI に無い
検証範囲とおことわり
件数・項目・選択肢は PDI（Zurich / OOTB）の実測です。本番環境の設定・データとは異なります。
補充ルールが実際に発注や移送を起こす動作は未実行です。設定値の確認までにとどめました。
移送オーダーの stage を自分で進める操作も行っていません。既存データの値を読んだだけです。
request_line（sc_req_item 参照）によるカタログ申請との連携は、実データに値が無く未検証です。
Inventory 系はライセンスやプラグインの前提により、環境ごとに使える範囲が変わります。
