サーバーやルータの命名規則はどうする？付け方や注意点を解説！

サーバーやルータの名前は、一度決めてしまうとあとから直しにくい要素です。
命名規則をそろえておくと、一覧の可読性が上がり、障害時の切り分けも速くなります。
本記事では、社内で使える付け方の考え方と、決めるときの注意点、具体例をまとめます。

命名規則とは

命名規則とは、サーバーやルータなどの機器に、一貫したルールで名前を付けるための決まりのことです。

社内で管理するサーバーは数十台、大企業では数百台にのぼることもあります。
本社だけでなく支店や事業所にも機器がある場合、社内で統一した命名規則が必要になります。

ルールがない、または守られていないと、管理が煩雑になります。
資産管理が難しくなる、障害時にどの機器か特定しづらくなる、といった影響が出ます。

名前はアルファベット・数字・ハイフンで構成し、ひと目で意味が分かるように設計するのが基本です。

命名規則の付け方

まずは、名前の各要素（プレフィックス）の付け方を見ていきます。
環境・拠点・用途・連番を組み合わせるのが一般的です。

開発・本番環境で分ける

サーバーやルータは、開発環境と本番環境に分けて用意することが多いです。
名前の先頭に dev や prod などを付けると、環境の違いがすぐ分かります。

ステージング環境では stg を使うケースもあります。

【例】

dev-tky-sv-web-01

prod-tky-sv-web-01

地名で分ける

複数拠点に機器がある場合、地名（またはその略称）を入れると所属が分かりやすくなります。
一般的には、地名をアルファベットの略称で表します。

【例】

東京：TKY・tk

大阪：OSA・os

福岡：FKO・fk

社内で略称の一覧を決め、ドキュメントに残しておくと迷いが減ります。

プロジェクト・用途で分ける

特定のプロジェクトや用途に紐づく機器であれば、その情報を名前に含めます。

【例】

ルーター用途：rt

スイッチ用途：sw

サーバー用途：sv

コーポレートサイト：corp-hp

監視システム：kanshi

用途が違うのに同じ略称を使うと、あとから混乱しやすいです。
役割ごとに略称を分けておくと安全です。

1号機・2号機で分ける

同種の機器が複数あるときは、末尾に連番を付けて区別します。

【例】

webserver-01

webserver-02

webserver-03

webserver-04

ただし、01号機と02号機で中身や用途が違う場合は、別の命名ルールに分けた方がよいです。
「01はWeb、02はDB用」と頭の中で変換が必要になると、運用時のミスにつながります。

命名規則の注意点

ルールを決めるときは、次の3点を押さえておきましょう。

重複するパターンはないか

他の要素と重複しない略称を選ぶ必要があります。
一意性が保てれば、障害時や変更時に対象機器を素早く特定できます。

地名の略称では、2文字だけだと衝突しやすいです。
この場合は3文字に揃えるなど、桁数のルールを決めます。

【例】（2文字だと重複しやすい）

宮崎：MY

宮城：MY

---

【例】（3文字に揃える）

宮崎：MYA

宮城：MYG

可読性はあるか

他のメンバーが見ても、意味が伝わる名前にします。
長すぎる連結や、社内でしか分からない略語の多用は避けます。

devtokyowebserver01 のように繋げると読みにくいです。
ハイフンで区切り、略称をそろえると改善します。

【例】（改善前）

devtokyowebserver01

---

【例】（改善後）

dev-tky-sv-web-01

大文字・小文字の使い分けも、チーム内で統一しておくとよいです。

拡張性があるか

将来の台数増やサービス追加を見越して、ルールを設計します。
新しいサーバーやルータを追加するときも、同じ型で名前を付けられるようにしておきます。

AWSでは、サービスごとに命名の制約があります。
S3やRDSなど、小文字のみ許可されるリソースがあります。
S3バケット名は全世界で一意である必要があるため、会社名やアカウント識別子を含め、重複しない文字列を組み立てます。

役割の切り分けが粗いと、用途が違うのに同じ名前に見えるケースも出ます。
そのときのために、予備の命名ルール（例外時の付け方）もあらかじめ決めておくと安心です。

命名規則例

最後に、現場で使いやすい組み合わせの例を3パターン紹介します。

パターン①

【例】

形式：[環境]-[地名]-[プロジェクト]-[役割]-[番号]

prod-nyc-web-01

dev-tokyo-db-02

パターン②

【例】

形式：[地名]-[役割]-[番号]-[文字列（予備）]

OSA-rt-01

MYG-sw-02-yobi

パターン③（AWS向け）

【例】

形式：[環境]-[クラウド]-[会社名]-[役割]-[アカウント番号]-[文字列（予備）]

dev-aws-abc-s3-111222333-01

dev-aws-abc-ec2-111222333-01

いずれも、チームで「どの要素を必須にするか」を先に決めてから運用に載せると、ブレが少なくなります。
自社の拠点数やクラウドの有無に合わせて、要素の取捨選択をしてください。