NetBox DCIMとは?データセンター構成をラック・機器・配線・電源で台帳化する
NetBoxのDCIM(Data Center Infrastructure Management)は、サイト・ラック・機器・ケーブル・電源といったデータセンターの物理構成を、正確な「台帳(Source of Truth)」として記録するための仕組みです。NetBoxはIPアドレス管理(IPAM)とDCIMを1つのデータモデルで統合しており、この記事ではそのうちDCIM側、つまり物理インフラを構造化して管理する設計に絞って解説します。開発元はNetBox Labs、ライセンスはApache 2.0のオープンソースで、2026年6月末時点の安定版はv4.6系です(最新は公式リリースで確認してください)。
扱う範囲は、DCIMのデータモデル階層(リージョン・サイト・ロケーション・テナント)、ラックと機器のモデリング、ケーブル配線と電源系統のドキュメント化、そしてExcel台帳からの移行やAPI連携による運用までです。NetBoxの全体像・IPAMの基礎・インストール手順はNetBoxとは?IPAM・DCIMを一元管理するOSSの機能と使い方で扱っているため、本記事はDCIMの構成管理そのものを深掘りします。
まとめ
- DCIMはデータセンターの物理インフラ(設置場所・ラック・機器・配線・電源)を管理する領域で、NetBoxはこれをIPAMと同じ台帳の中で扱う。
- 組織モデルはリージョン→サイト→ロケーション→ラックの階層で場所を表し(リージョンとサイトグループは並行してサイトを束ねる別軸)、テナントで利用組織・部門を横断的に割り当てる。
- 機器はデバイスタイプ(メーカー+型番)でテンプレート化し、ラックのU位置・前面/背面に配置する。ポートや電源ポートはテンプレートから自動生成される。
- ケーブルは2つの終端を結び、パッチパネルをまたいだ配線経路をトレースできる。電源はパワーパネル→パワーフィード→機器の電源ポートという流れで容量まで追える。
- 価値の本質は「信頼できる唯一の台帳」を作ること。APIでAnsibleやZabbixと連携し、NetBoxを正として構成・監視を自動化する使い方が中心になる。
以下では、DCIMの定義から組織モデル・ラック・配線・電源・運用までを順に見ていきます。
NetBox DCIMとは:データセンターの物理構成を台帳化する領域
DCIM(Data Center Infrastructure Management)は、サーバーやネットワーク機器がどこに・どのラックの何Uに設置され、どのケーブルと電源につながっているかといった物理インフラの情報を管理する領域を指します。NetBoxはこのDCIMと、IPアドレスやVLANを扱うIPAMを1つのデータモデルの上で統合している点が特徴です。両者が同じ台帳にあることで、「この機器のこのインターフェースに、このIPアドレスが割り当たっている」という物理と論理のつながりを1箇所でたどれます。
DCIM(データセンターインフラ管理)が扱う対象
DCIMが記録するのは、設置場所(データセンターやサーバールーム)、ラックとその中の機器、機器同士をつなぐケーブル、そして電源系統です。監視ツールが「今どう動いているか」を追うのに対し、DCIMは「どこに何が、どうつながって存在するか」という構成の事実を正確に保つことに主眼があります。稼働状態のリアルタイム監視はZabbixやPrometheusの担当で、DCIMはその前提となる構成台帳を提供する役割だと整理すると混同しません。
NetBoxのDCIMがカバーする4層
NetBoxのDCIMは、本記事では次の4種類のモデルに整理すると見通せます(公式が「4層」と呼ぶわけではなく、理解のための整理です)。この分類を押さえると、後述の各機能がどこに属するのかが分かります。
| 層 | 代表オブジェクト | 役割 |
|---|---|---|
| 組織モデル | リージョン/サイト/ロケーション/テナント | 場所と所有者の階層 |
| 物理資産モデル | ラック/デバイス/モジュール/ケーブル | 実機とその設置 |
| コンポーネントモデル | インターフェース/コンソールポート/電源ポート | 機器の各ポート |
| 接続モデル | ケーブル接続/電源フィード | 物理・論理のつながり |
組織モデルで「どこ」を、物理資産とコンポーネントで「何が」を、接続モデルで「どうつながっているか」を表す構造です。
IPAMとDCIMを1つの台帳で統合する意味
NetBoxではDCIMで登録した機器のインターフェースに、IPAMで管理するIPアドレスを直接ひも付けられます。これにより、ラック内の物理機器から、そのポート、割り当てIP、所属VRFやVLANまでを一続きでたどれます。IPAM側の詳細(VRF・VLAN・プレフィックス設計など)はNetBoxの総合解説に譲りますが、DCIMを使う際は「物理の台帳と論理の台帳が地続きである」ことがNetBoxを選ぶ理由になります。
DCIMの組織モデル:リージョン・サイト・ロケーション・テナントの階層
機器を登録する前に、まず「どこに置くか」を表す器を設計します。NetBoxは場所を階層で表現し、さらに利用組織を横断的に割り当てるテナントの仕組みを持ちます。ここを最初に固めておくと、機器が増えても台帳が散らかりません。
リージョン・サイトグループ・サイト・ロケーションの使い分け
場所の階層は、リージョン(国・地域)→サイトグループ(用途などのグループ)→サイト(データセンターやオフィスの物理拠点)→ロケーション(サイト内の部屋・列・ゾーン)→ラックの順に細かくなります。リージョンとサイトグループは並行してサイトを束ねる仕組みで、リージョンは地理、サイトグループは所有形態や用途といった別軸でまとめたいときに使い分けます。ロケーションは入れ子にできるため、「3F→A列」のように多段で表現できます。作り込みすぎないこと。拠点が2〜3箇所ならリージョンを省いてサイトから始めるなど、規模に見合った深さで十分です。
テナントによる利用組織・部門の割当
テナントは、そのリソースを「誰が使っているか」を表す軸です。サイト・ラック・機器・IPアドレスなど多くのオブジェクトにテナントを割り当てられ、部門ごと・顧客ごとにリソースを横断的に絞り込めます。マルチテナントのデータセンターや、社内を部署単位で管理したい場合に効きます。場所の階層(サイト)が物理の器であるのに対し、テナントは論理的な所有者を表すため、両者を混同せず別軸として設計するのがポイントです。
ラックと機器のモデリング:NetBox DCIMの中核
組織モデルという器ができたら、その中にラックと機器を配置します。DCIMで最も日常的に触れる部分であり、テンプレート化をどこまで作り込むかが台帳の精度と入力コストを左右します。
ラックとエレベーション:U位置・幅・前面と背面
ラックはロケーション(またはサイト)に属し、高さをU(ラックユニット、例:42U)で持ちます。幅は10・19・21・23インチなどから選べ、ユニット番号を下から昇順にするか上から降順にするかも設定できます。機器はラックの特定のUに、前面(front)か背面(rear)かの向きを含めて配置します。NetBoxはこのエレベーション(ラック正面図)を画面上に描画するため、空きUの把握や増設計画に使えます。奥行きや外形寸法(mm)も持てるので、物理スペースの管理にも展開できます。
デバイスタイプとモジュールでテンプレート化する
機器(デバイス)は、メーカーと型番をまとめたデバイスタイプに基づいて登録します。デバイスタイプにあらかじめインターフェースや電源ポートのテンプレートを定義しておくと、同じ型番の機器を追加したときにポート類が自動生成され、1台ごとに手入力する必要がなくなります。ラインカードのように交換可能な部品はモジュール/モジュールタイプで表現でき、シャーシ型のスイッチやサーバーの構成変更を台帳に反映できます。よく使う型番はコミュニティのnetbox-community/devicetype-libraryから定義を取り込めるため、ゼロから作らずに済みます。
インターフェースとコンポーネントの管理
1台の機器は、インターフェース(LANポートなど)、コンソールポート、電源ポート、パッチパネルなら前面・背面ポートといったコンポーネントの集合として表現されます。これらは配線や電源、IPアドレス割り当ての終端になる要素です。コンポーネントを正確に持たせておくことが、後述のケーブルトレースや電源容量計算の前提になります。逆に言えば、ポートの粒度をいい加減にすると配線図も電源図も崩れるため、テンプレート設計の段階で機器の実物に合わせておくことが重要です。
ケーブル配線と電源系統のドキュメント化
機器を置いたら、それらがどうつながっているかを記録します。NetBoxの強みは、配線と電源をポート単位で結び、経路や容量までたどれる点にあります。ここが表計算による台帳では再現しにくい領域です。
ケーブル接続と配線トレース
ケーブルは2つの終端(機器のインターフェース同士、あるいはパッチパネルの前面/背面ポートや電源ポート)を結ぶオブジェクトです。種別・長さ・色・状態(接続済み/計画中など)を持たせられます。NetBoxはパッチパネルをまたいだ配線でも、始点から終点までの経路をケーブルトレースとして一続きで表示します。「このサーバーのポートは、どのパッチパネルを経由して、どのスイッチのどのポートに届いているか」を追えるため、障害切り分けや移設時の影響範囲の確認に役立ちます。
電源モデル:パワーパネル・パワーフィード・電源ポート
電源は、サイトやロケーションに置くパワーパネル(分電盤)を起点に、パワーフィード(ラックへの給電系統。電圧・電流・相・供給元を持つ)を経て、機器の電源ポートへつながります。機器側は電源ポート(入力)と電源アウトレット(PDUなどが配る出力)で表現します。これらを登録しておくと、フィードの定格に対して機器がどれだけ電力を引いているかを積み上げて把握でき、ラックの電源容量の逼迫を事前に見つけられます。配線と同じく、電源も「つながり」を台帳に落とすことで、増設や冗長構成の検討材料になります。
近年追加されたモデル(CableBundle・VirtualMachineType)
NetBoxはバージョンごとにデータモデルが拡張されています。近年の4.6系では、複数の個別ケーブルを1本の物理的なケーブル束として束ねて扱うCableBundleや、仮想マシンを種別で分類するVirtualMachineTypeといったモデルが追加されました。DCIMの表現力は版を追うごとに増えているため、導入時は自社の管理対象に対応するモデルがあるかを公式ドキュメントで確認するとよいでしょう。バージョン固有の仕様は変わりうるので、最新は公式リリースノートで確かめてください。
Source of Truthとしての運用:移行・API連携・向かない場面
DCIMの機能を一通り押さえたら、最後は運用です。NetBoxの価値は台帳を「正しく保ち続ける」ことにあり、そのためのデータ投入と自動化、そして適用範囲の見極めが実務の勘所になります。
Excel・スプレッドシート台帳から移行する考え方
多くの現場はサーバー管理台帳をスプレッドシートで運用しており、NetBoxはその置き換え先として選ばれます。移行では、いきなり全項目を作り込まず、まずサイト・ラック・デバイスタイプという「器とテンプレート」を整えてから機器を流し込むのが定石です。CSVインポートやAPIで一括投入でき、既存台帳の列をNetBoxのフィールドに対応づける設計を先に決めておくと、二重管理の期間を短くできます。表計算では表現しづらかった配線・電源のつながりは、移行後に段階的に肉付けしていくと負担が分散します。
APIとインポートで台帳を最新に保つ
NetBoxはREST APIとGraphQL APIを備え、台帳の登録・更新・参照をプログラムから行えます。たとえばラック一覧をサイトで絞り込んで取得するリクエストは次のように書けます。
curl -H "Authorization: Token <your-token>" \
"https://netbox.example.com/api/dcim/racks/?site=tokyo-dc1"
この仕組みを使い、AnsibleのインベントリをNetBoxから動的に生成したり、Zabbixの監視対象をNetBoxの機器情報から自動登録したりできます。NetBoxを構成の「正」に据え、変更があればまず台帳を更新し、そこから各ツールへ最新状態を配る運用にすると、台帳と現場のズレが起きにくくなります。監視側の詳細はPrometheusやZabbixの記事も参照してください。
NetBoxのDCIMが向かない場面・注意点
NetBoxはあくまで「意図した構成の台帳」であり、機器を自動で発見して現状を書き込むツールではありません。ネットワークを自動スキャンして実機の状態をそのまま台帳化したい、という用途には単体では合わず、別の収集の仕組みと組み合わせる前提になります。また、リアルタイムの障害監視やメトリクス収集はDCIMの守備範囲外で、そこを期待すると失敗します。小規模で機器が数台、変更もまれといった環境では、台帳を作り込む手間に見合わないこともあります。逆に、機器・配線・電源が増え続け、複数人で構成情報を共有する必要が出てきた段階こそ、NetBoxのDCIMが効いてきます。
NetBox DCIMに関するよくある質問(FAQ)
NetBoxのDCIMではラックのどんな情報を管理できますか?
ラックの高さ(U数)、幅(10/19/21/23インチなど)、ユニットの昇順・降順、外形寸法や設置場所(サイト・ロケーション)を管理できます。さらに、どの機器が何Uに前面・背面どちら向きで載っているかをエレベーション(正面図)として表示でき、空きUの把握や増設計画に使えます。
NetBoxのDCIMとIPAMは何が違いますか?
DCIMはラック・機器・ケーブル・電源といった物理インフラを、IPAMはIPアドレス・VRF・VLANといった論理的なアドレス空間を管理します。NetBoxは両者を同じデータモデルで統合しているため、物理機器のインターフェースにIPアドレスを直接ひも付けて、物理と論理を一続きでたどれます。IPAMの詳しい機能はNetBoxの総合解説を参照してください。
NetBoxのDCIM情報をZabbixやAnsibleと連携できますか?
できます。NetBoxのREST API/GraphQL APIから機器やIPの情報を取り出し、Zabbixの監視対象へ自動登録したり、Ansibleの動的インベントリとして利用したりできます。NetBoxを構成の「正」として、そこから各ツールへ最新状態を配る使い方が一般的です。
NetBoxのDCIM台帳はAPIで自動更新できますか?
REST APIで機器・ラック・ケーブル・IPアドレスなどを作成・更新でき、CSVインポートでの一括投入にも対応します。既存のスプレッドシート台帳から移行する際も、列をNetBoxのフィールドに対応づけてまとめて取り込めます。参照の絞り込みにはGraphQL APIが便利です。
NetBoxのDCIMはWindowsで構築できますか?
NetBoxはPostgreSQLとRedis、Python環境を前提とし、本番運用はLinuxが標準です。Windows上で試す場合はDockerやWSLを使う形が現実的です。構築の前提条件や手順はNetBoxとは?IPAM・DCIMを一元管理するOSSの機能と使い方で解説しているので、そちらを参照してください。