NetBox DCIMとは？ラック・配線・電源・冷却を台帳化する設計とAPI実例【v4.7】

NetBoxのDCIM（Data Center Infrastructure Management）は、サイト・ラック・機器・ケーブル・電源をデータモデルとして持ち、データセンターの物理構成を「信頼できる唯一の台帳（Source of Truth）」として記録する機能群です。2026年10月17日時点の安定版は2026年10月13日公開のv4.7.3で、v4.7.0では冷却設備のモデルが加わりました。

この記事は、DCIM側のデータモデルと運用に絞っています。NetBox v4.7.3の公式Dockerイメージにサイト・ラック・サーバー・パッチパネル・PDUをAPIで登録し、ケーブルトレースや電源使用率がどう返るかを確かめた結果も載せました。NetBoxの全体像・IPAM・インストール手順はNetBoxとは？IPAM・DCIMを一元管理するOSSの機能と使い方【v4.7対応】で扱っています。

まとめ

• NetBoxのDCIM機能は「どこに何が、どうつながって存在するか」を記録する台帳で、稼働状態の監視はしない。NetBoxはこれをIPAMと同じデータベースで持ち、機器のポートとIPアドレスを直接結べる。
• 場所はリージョン→サイト→ロケーション→ラックの階層で表す。ラックの物理仕様はv4.7からラックタイプ側に寄せる流れで、v5.0ではラックタイプの割り当てが必須になる予定。
• 機器はデバイスタイプのテンプレートからポート類が自動生成される。0Uの機器はU位置を持てず、既に埋まったUへの配置はAPIが400で拒否する。
• パッチパネルは前面ポートと背面ポートの対応で表し、サーバーからパッチパネル2枚を経由したスイッチまでの経路をAPIの1リクエストで3区間として取得できる。
• 電源はパワーパネル→パワーフィード→PDU→機器の順に結び、フィードの供給可能量は「電圧×電流×最大使用率」で決まる。200V・30A・80%なら4,800VA。v4.7で冷却も同じ形でモデル化できるようになった。
• v4.7のAPIトークン（v2）は Authorization: Bearer nbt_<key>.<token> 形式で、従来の Token 形式で送ると403になる。

以下、データモデルの順に、ラック・配線・電源・冷却・APIでの登録・運用の判断を見ていきます。

NetBox DCIMの守備範囲：物理構成の台帳とIPAMとの接点

DCIMが記録するのは、設置場所、ラックとその中の機器、機器同士をつなぐケーブル、電源と冷却の系統です。ZabbixやPrometheusが「今どう動いているか」を集めるのに対し、NetBoxのDCIMは「本来どう設置され、どう配線されているべきか」という意図した構成を保持します。両者は競合せず、NetBoxが台帳、監視ツールがその台帳を読んで監視対象を決める、という分担になります。

DCIMのモデル群：場所・機器・コンポーネント・接続の4分類

公式が4分類と呼んでいるわけではありませんが、DCIMのモデルは次のように分けると見通しがよくなります。

入力の順番もこの表の上から下です。場所と機器の型を先に決めないと、機器もケーブルも登録できません。

IPAMと同じ台帳にあることの実利

NetBoxでは、DCIMで登録した機器のインターフェースに、IPAMのIPアドレスを直接割り当てます。障害対応で「このIPのサーバーはどのラックの何Uにあり、どのスイッチのどのポートにつながっているか」を1画面でたどれるのは、物理と論理が別々のツールに分かれていないからです。VRF・VLAN・プレフィックスの設計は総合解説の記事に譲ります。

場所の階層設計：リージョン・サイト・ロケーション・テナント

機器を登録する前に、置き場所の器を決めます。ここを後から組み替えると、配下のラックと機器の付け替えが発生するため、最初に規模に合った深さを決めておくのが安全です。

リージョン・サイトグループ・ロケーションの使い分け

サイトはデータセンターやオフィスといった物理拠点で、ラックは必ずいずれかのサイトに属します。リージョン（国・地域）とサイトグループ（自社所有・コロケーションなど用途別）は、どちらもサイトを束ねる仕組みで、地理と用途という別の軸です。サイトの中はロケーションで「3F→A列」のように入れ子にできます。

拠点が2〜3か所しかないなら、リージョンもサイトグループも作らずサイトから始めて構いません。逆に、ロケーションを部屋・列・ケージまで細かく切ると、ラックを移設するたびに登録の手間が増えます。

テナントによる利用部門・顧客の割り当て

テナントは、そのリソースを誰が使っているかを表す軸です。サイト・ラック・機器・IPアドレスなど多くのオブジェクトに付けられ、部門別・顧客別に横断して絞り込めます。サイトが物理の器、テナントが論理的な所有者なので、「顧客ごとにサイトを分ける」ような混同をしないことが設計上の要点です。

ラックと機器のモデリング：U位置・デバイスタイプ・モジュール

ラックの項目：幅・ユニット番号・v4.7の非推奨項目

ラックは高さをU数（例：42U）で持ちます。幅は10・19・21・23インチの4種類、形状は2ポスト・4ポストのフレームとキャビネット、壁掛けなど7種類から選びます。starting_unit は最下段のユニット番号（既定1）、desc_units をtrueにすると上から下へ番号を振ります。

注意したいのは、v4.7のラックの公式ドキュメントで、ラック本体の形状・幅・外形寸法の各項目が非推奨になり、v5.0で削除予定とされている点です。v5.0からはラックタイプ（RackType）の割り当てが必須になり、物理仕様はラックタイプから引き継ぎます。これから台帳を作るなら、同じ型のラックはラックタイプを1つ作り、物理仕様を定義して割り当てておくと、ラックタイプ必須化に伴う移行作業を減らせます。

デバイスタイプのテンプレートとdevicetype-library

機器はメーカー＋型番を表すデバイスタイプから作ります。デバイスタイプにインターフェースや電源ポートのテンプレートを定義しておくと、機器を追加した時点でポートが自動生成されます。手元のv4.7.3では、インターフェース2個・電源ポート2個のテンプレートを持つデバイスタイプから機器を作ると、作成直後にインターフェース2個・電源ポート2個が存在していました。

主要メーカーの型番は、コミュニティが管理するdevicetype-libraryにメーカー別のYAMLとして揃っています。ゼロから定義する前に、ここに自社の機種があるかを確かめるのが近道です。

U位置と前面・背面の配置ルール

機器はラックの特定のUに、前面（front）か背面（rear）かを指定して載せます。2U以上の機器は、占有する範囲のうち番号が最も小さいUを position に入れます。v4.7.3で、U10〜11に2Uのサーバーがあるラックへ、別の2Uサーバーを position: 11 で追加すると、APIは次のエラーで拒否しました。

HTTP 400
{"position":["U11.0 is already occupied or does not have sufficient space to accommodate this device type: Server-2U (2.0U)"]}

縦型PDUのような0Uの機器はUを消費せず、U位置も持てません。0UのPDUに position: 20 を指定すると「A 0U device type (PDU-8) cannot be assigned to a rack position.」で400になります。0U機器はラックに割り当てるだけにして、U位置は空のままにします。

モジュールとv4.7のModuleBayType・モジュール移設

ラインカードやトランシーバーのように差し替える部品は、モジュール（Module）とモジュールベイで表します。v4.7.0では、ベイが受け付けるモジュールの種類を示すModuleBayTypeが加わりました。ベイとモジュールタイプの両方に種類が設定されていて共通する種類が1つもないと、NetBoxは装着を拒否します。SFP28のケージにQSFPのモジュールを登録してしまう、といった誤入力を台帳の段階で防げます。

同じv4.7.0から、装着済みのモジュールを別のベイへ移せるようになりました。ただし、別の機器への移設は、移動するコンポーネントに有効な接続関係や機器に依存する設定がない場合に限られます。以前は削除して作り直す必要があり、そのたびに変更履歴が途切れていました。

ケーブル配線とパッチパネル：前面・背面ポートとトレース

表計算の台帳との最大の差は、配線を端点同士の関係として持ち、パッチパネルをまたいだ経路をたどれることです。

パッチパネルのモデル：前面ポートと背面ポートの対応

パッチパネルは、前面ポート（FrontPort）と背面ポート（RearPort）を持つ機器として登録します。前面ポートごとに、どの背面ポートのどの位置へ通じているかを対応付けます。1対1の通常のパッチパネルなら背面ポートの positions は1です。MPOのように1本の背面ケーブルに複数芯を通す場合は、背面ポートの positions を12などにし、複数の前面ポートを同じ背面ポートの別の位置へ対応付けます。

ケーブル（Cable）は両端（A端・B端）の終端を結ぶオブジェクトで、種別・長さ・色・ラベル・状態（接続済み・計画中など）を持ちます。v4.6.0で追加されたCableBundleを使うと、48本のCAT6をまとめた束のように物理的な配線群を1つにまとめられますが、束への所属はトレースや接続関係には影響しません。

サーバーからスイッチまでの経路をAPIでたどった結果

サーバー srv01 の eth0 → パッチパネル pp-a の前面 → pp-a の背面 ⇔ pp-b の背面（幹線ケーブル）→ pp-b の前面 → スイッチ sw01 の Te1/0/1、という配線をv4.7.3に登録し、GET /api/dcim/interfaces/<id>/trace/ を呼ぶと、次の3区間が返りました（応答のJSONから機器名・ポート名・ケーブルラベルだけを抜き出して整形）。

srv01:eth0  -- C-0001 -> pp-a:F1
pp-a:R1     -- C-0002 -> pp-b:R1
pp-b:F1     -- C-0003 -> sw01:Te1/0/1

あわせて、eth0 の connected_endpoints には sw01 の Te1/0/1 が入り、connected_endpoints_reachable はtrueでした。パッチパネルを何枚経由しても、最終的にどのスイッチのどのポートにつながっているかを1項目で取れるので、監視ツールやドキュメント生成から使うときはこの項目を読むのが手早い方法です。

ブレイクアウト配線のモデル：v4.7のチャネル化インターフェース

40GbEのポートを10GbE×4に分けるブレイクアウトは、v4.7.0から専用の表現ができました。親インターフェースの channels にチャネル数（この例では4）を入れ、各チャネルを種類 channel のサブインターフェースとして channel_id（1始まり）付きで作ります。ケーブルは親インターフェースに1本つなぎます。チャネルのサブインターフェースへは直接ケーブルをつなげず、接続は親から引き継ぎます。チャネルごとの経路をたどるには、ケーブルのprofile（Straight（multi-position）など）を指定して、コネクターの位置とチャネルを対応付ける必要があります。

v4.7.3では、インターフェーステンプレートに channels: 4 を設定して機器を作っても、チャネルのサブインターフェースまでは自動生成されませんでした（親1個だけ）。チャネル側は別途APIか画面で作る必要があります。

電源と冷却の系統：パワーパネルからPDU、v4.7の冷却モデル

電源の連鎖と使用率の計算式

電源は、分電盤を表すパワーパネル（PowerPanel）を起点に、ラックへの給電回路であるパワーフィード（PowerFeed）、PDUの入力の電源ポート（PowerPort）、PDUの出力の電源アウトレット（PowerOutlet）、機器の電源ポートの順にケーブルで結びます。パワーパネルより上流（受電設備など）はモデル化しません。

フィードの供給可能量は、power.pyの実装で「電圧×電流×最大使用率÷100」（三相ならさらに×1.732）と決まっています。機器の電源ポートには最大消費（maximum_draw）と割当（allocated_draw）を入れます。v4.7.3で次の構成を登録し、PDUの画面を確認しました。

700÷4800＝14.58%なので、この画面の使用率は割当値の合計をフィードの供給可能量で割った値です。画面はVA表示ですが、電源ポートの割当値はモデル上Wと説明されているため、表示値を実設備の容量判定に使う際は単位と力率を別途確認します。最大使用率はNetBoxの既定値も80%で、この値を100%に上げると余裕を過大に見積もります。なお、この計算に使われるのは登録した割当値で、実際の消費電力ではありません。実測値と突き合わせたいならPDUの計測値を監視ツールで集めて比べます。

v4.7の冷却モデル：CoolingSourceとCoolingFeed

v4.7.0で、電源モデルと対になる冷却のモデルが追加されました。CoolingSourceはチラーや冷却塔などの施設側の冷却源で、機器（Device）ではなく施設設備として扱います。CoolingFeedは冷却源からラックへ冷媒を届けるループ、CoolingIntakeは機器が冷媒を受け取る入口、CoolingOutflowはCDUやマニホールドから下流機器へ冷媒を供給する出口です。CoolingOutflowは温まった冷媒の戻り口を表しません。

v4.7.3のAPIで確認すると、CoolingSourceの種類（type）は必須で、選択肢は chiller・cooling-tower・dry-cooler・crac・crah の5つでした。ラックには cooling_capability（air-only・hybrid・liquid-only）と cooling_capacity（kW）が追加されています。GPUサーバーの液冷ラックのように、電力より先に冷却能力が上限になる構成を台帳で管理したい場合に使います。空冷だけのサーバールームなら、ラックの冷却能力を入れる程度で十分です。

NetBox DCIMをAPIで操作する手順：トークン・pynetbox・一括登録

構築スクリプトからAPIで登録すると、手入力の転記を減らせます。ただし、入力値の検証とAPI応答の確認を組み込む必要があります。以下はv4.7.3で動作を確認した書き方です。

v4.7のAPIトークンはBearer形式

NetBox v4.5からAPIトークンにv2が加わり、v1は非推奨になりました。REST APIの公式ドキュメントによると、v2トークンは接頭辞 nbt_・キー・平文トークンをピリオドでつなぎ、Bearer を付けて送ります。v4.7.3でv2トークンを従来の Token <平文> 形式で送ると403、Bearer形式なら200でした。

curl -H "Authorization: Bearer nbt_<key>.<token>" \
  "https://netbox.example.com/api/dcim/racks/?site=tokyo-dc1"

古いブログ記事の Authorization: Token ... をそのまま写して403になる場合は、まずトークンの版を確認してください。v4.7からは、APIでトークンを作るときにクライアント側で平文を指定することもできなくなっています。

pynetboxによるラック内機器一覧と配線経路の取得

Pythonから扱うなら、公式のクライアントライブラリ pynetbox が使えます。次のコードは pynetbox 7.8.0 と NetBox v4.7.3 で動作を確認したもので、U位置の降順で機器を並べ、サーバーのポートから対向スイッチまでの経路を表示します。実行前にpynetboxを導入し、NETBOX_TOKENにトークンを設定してください。接続先URLとサイト・ラック・機器・ポートの名前は、登録済みの環境に合わせて変更します。

import os
import pynetbox

# v4.7 の v2 トークンは "nbt_<key>.<token>" をそのまま渡す
nb = pynetbox.api("http://localhost:18000", token=os.environ["NETBOX_TOKEN"])

rack = nb.dcim.racks.get(name="A-01", site="tokyo-dc1")
print(rack.name, rack.u_height, "U")
for d in nb.dcim.devices.filter(rack_id=rack.id, ordering="-position"):
    pos = f"U{float(d.position):g}" if d.position is not None else "0U"  # 0U の PDU は position が None
    print(f"  {pos} {d.face} {d.name} ({d.device_type.model})")

# サーバーのポートから対向スイッチまで、パッチパネルをまたいでたどる
eth0 = nb.dcim.interfaces.get(device="srv01", name="eth0")
hops = eth0.trace()  # pynetbox は [A端, ケーブル, B端, A端, ...] の平たいリストで返す
for i in range(0, len(hops), 3):
    a_ends, cable, b_ends = hops[i:i + 3]
    print(" ", [f"{x.device.name}:{x.name}" for x in a_ends],
          "--", cable.label if cable else None, "->",
          [f"{x.device.name}:{x.name}" for x in b_ends])

実行結果は次のとおりです。

A-01 42 U
  0U None pdu-a (PDU-8)
  U40 Front sw01 (Switch-48)
  U38 Front pp-a (PP-24)
  U37 Front pp-b (PP-24)
  U10 Front srv01 (Server-2U)
  ['srv01:eth0'] -- C-0001 -> ['pp-a:F1']
  ['pp-a:R1'] -- C-0002 -> ['pp-b:R1']
  ['pp-b:F1'] -- C-0003 -> ['sw01:Te1/0/1']

つまずきやすいのは2点です。0Uの機器は position がNoneなので、そのまま数値に変換すると落ちます。また、REST APIの trace は「A端・ケーブル・B端」の3要素を1区間とする配列ですが、pynetboxの trace() はそれを平たく並べたリスト（この例では9要素）で返すため、3つずつ区切って読みます。

大量登録のバックグラウンド処理と失敗位置の確認

Excel台帳から数百台をまとめて流し込むときは、機器の配列をPOSTする一括作成を使います。v4.7.0からは、URLに ?background=true を付けるとバックグラウンドのジョブとして処理され、プロキシのタイムアウトを避けられます。v4.7.3では202とジョブのURLが返り、ジョブ完了後に3台が作成されていました。ただし、ワーカー（RQ worker）が動いていないと「RQ worker process not running.」で503になります。

一括作成は全件成功か全件失敗のどちらかです。v4.7.0からは、失敗時にどの要素が何で失敗したかが返るようになりました。2台のうち2台目のサイトを空にして送ると、次の応答でした。

HTTP 400
{"detail":"1 of 2 objects could not be created.","errors":[{"index":1,"errors":{"site":["This field is required."]}}]}

index は送った配列の何番目か（0始まり）を指すので、移行スクリプトではこの番号でExcelの行に戻って直せます。

ラック立面図のSVG取得とJSON形式の違い

GET /api/dcim/racks/<id>/elevation/?render=svg&face=front で、画面と同じラック立面図をSVGで取得できます。v4.7.3の42Uラックでは幅269×高さ928、約16KBのSVGが返りました。render を付けないとJSONになり、42Uのラックが0.5U刻みの84行で返るため、空きUの計算に使えます。

構成図・ネットワーク図の扱い：標準機能とプラグインの境界

NetBox本体で描けるのは、ラック立面図とケーブルトレースの経路表示までです。機器同士のつながりを俯瞰するネットワーク構成図（トポロジー図）は標準では出ません。トポロジー図が必要なら、コミュニティのプラグインnetbox-topology-viewsを入れます。2026年10月17日時点の安定版v4.7.0は、対応するNetBoxの最低版を4.7.0にしています。

プラグインの対応時期は製品ごとに異なるため、本体を上げる前に、導入済みプラグインの対応版が出ているかを確認します。構成図を手で描く場合の規約はアーキテクチャ図とは？書き方の手順とC4モデル・AWSアイコンの規約、作成ツールの選び方も参考になります。

Source of Truthとしての運用：Excel移行・Zabbix連携・向かない場面

Excel台帳からの移行順序

いきなり全項目を作り込まず、次の順で入れるのが手戻りの少ない進め方です。

1. サイト・ロケーション・ラックタイプ・ラック（器）
2. メーカー・デバイスタイプ（devicetype-libraryから取り込み）
3. 機器（Excelの行をAPIの一括作成で投入）
4. IPアドレス（機器のインターフェースへ割り当て）
5. ケーブル・電源（変更が多いラックから段階的に）

表計算では表しにくい配線と電源は最後に回し、移行後の作業で肉付けします。CMDBとの違いや、ITIL上の構成管理との関係はCMDBとは？構成管理データベースの仕組み・ITILとの関係・導入判断を解説で整理しています。

Zabbix・Ansible連携とv4.7への対応状況

NetBoxを正にして、AnsibleのインベントリやZabbixの監視対象をNetBoxから作るのが定番の使い方です。Ansibleは公式コレクション netbox.netbox の動的インベントリでNetBoxの機器を読み込めます（Ansible自体の仕組みはAnsibleとは？エージェントレスの仕組みとメリット・デメリット、Red Hat AAPの制約を参照）。

Zabbix連携は版の組み合わせに注意が要ります。NetBoxプラグインのnbxsyncは、1.0.5の互換表が示す対応範囲がNetBox 4.2.6〜4.6.xで、v4.7は含まれていません。NetBoxの機器と仮想マシンからZabbixのホストを作る外部スクリプトnetbox-zabbix-syncもありますが、v4.7での動作を明示した記載は確認できませんでした。Zabbix連携を前提にv4.7へ上げる場合は、検証環境で同期を一度通してから本番を上げてください。Zabbixの概要はZabbixとは？仕組み・監視できること・他ツールとの違いをわかりやすく解説にまとめています。

自動取り込みはDiode、採用を見送る条件

NetBoxは意図した構成の台帳で、機器を自動で発見して書き込むツールではありません。ネットワークをスキャンして台帳に反映したい場合は、NetBox Labsの取り込みサービスDiodeを組み合わせます。自動ディスカバリはNetBox DiscoveryのOrbエージェントが担い、独自の取り込みはDiodeのSDKで書きます。

次のどれかに当てはまるなら、NetBoxのDCIMは導入しない方がよい判断になります。

• 機器が数台で配線変更が年に数回しかなく、台帳を更新する担当者もいない（入力の手間が台帳の価値を上回る）
• 求めているのが稼働監視やアラートで、構成の記録ではない（ZabbixやPrometheusの領域）
• 台帳を更新する運用ルールを決められない（古い情報が監視対象の生成や構築の自動化に使われると、誤設定が広がる）

反対に、機器・配線・電源が増え続け、複数人が同じ構成情報を参照する段階では、Excelより先にNetBoxを置く価値があります。台帳をもとに構築・自動化の基盤ごと整えたい場合は、インフラ構築（AWS・Google Cloud・Azure）の支援もご相談いただけます。監視側の設計はPrometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積りが参考になります。

NetBox DCIMに関するよくある質問

NetBoxのDCIMとIPAMは何が違いますか？

DCIMはラック・機器・ケーブル・電源・冷却といった物理インフラを、IPAMはIPアドレス・プレフィックス・VRF・VLANといった論理的なアドレス空間を管理します。NetBoxは両者を1つのデータベースで持つため、機器のインターフェースにIPアドレスを直接割り当てられ、「このIPの機器はどのラックの何Uにあるか」をたどれます。IPAMの使い方はNetBoxの総合解説記事で扱っています。

NetBoxのAPIで認証が403になるのはなぜですか？

v4.5以降のv2トークンを、v1と同じ Authorization: Token <平文> 形式で送っている可能性があります。v2トークンは Authorization: Bearer nbt_<key>.<token> の形式です。v4.7.3でv2トークンをToken形式で送ると403、Bearer形式で送ると200になることを確認しています。v1トークンは非推奨なので、新しく発行するならv2にします。

NetBoxでPDUやパッチパネルはどう登録しますか？

どちらも機器（Device）として登録します。PDUは電源ポート（入力）と電源アウトレット（出力）を持つデバイスタイプにし、縦型なら0Uにします。0UはU位置を持てないため、ラックへの割り当てだけ行います。パッチパネルは前面ポートと背面ポートを持つデバイスタイプにし、前面ポートごとに対応する背面ポートと位置を設定すると、パネルをまたいだケーブルトレースができます。

NetBoxでネットワーク構成図は作れますか？

本体で描けるのはラック立面図とケーブルトレースの経路までで、トポロジー図は標準機能にありません。netbox-topology-viewsプラグインを入れると、登録したケーブルからトポロジー図を表示できます。2026年10月時点の安定版v4.7.0はNetBox 4.7.0以上に対応しています。プラグインの対応時期は製品ごとに異なるので、本体の更新前に対応版を確認してください。

NetBoxはWindowsやPodmanで動かせますか？

v4.7の動作要件はPython 3.12〜3.14、PostgreSQL 15以上、Redis 6.0以上で、公式のインストール手順はUbuntu 24.04で動作確認されたLinux向けの内容です。Windowsで試すならWSL2上のLinuxかDockerを使い、公式のnetbox-docker（5.1.1はNetBox v4.7.x以降に対応）で起動するのが早い方法です。netbox-dockerはComposeファイルなので、Podman環境ではpodman composeなどで動かす形になります。

関連記事

• NetBoxとは？IPAM・DCIMを一元管理するOSSの機能と使い方【v4.7対応】
• CMDBとは？構成管理データベースの仕組み・ITILとの関係・導入判断を解説
• Ansibleとは？エージェントレスの仕組みとメリット・デメリット、Red Hat AAPの制約
• Zabbixとは？仕組み・監視できること・他ツールとの違いをわかりやすく解説
• Batfishとは？ネットワーク設定を本番前に検証するOSSの仕組みと使い方