【完全体系図】ネットワーク設計書の書き方と必須項目一覧｜目次サンプル付

「案件でネットワーク設計書を書くことになったが、何から手をつければいいかわからない」
「前任者が残したドキュメントがバラバラで、標準的なフォーマットや作成項目がわからない」
「せっかく作った設計書が、構築後の運用フェーズで誰も見ない『置物』になっている……」

ネットワークの現場では、こうした悩みが後を絶ちません。

ネットワーク設計書は、単に「機器の設定値（Config）を並べただけの資料」ではありません。
システムの要件を満たすための「設計思想」をステークホルダーと合意し、構築者が迷わず作業を行い、数年後の運用者や障害対応者がシステムを安全に維持管理するための「生きた設計図」です。

この記事では、要件定義から運用保守、AWS/Azureなどのクラウド接続までを見据え、ネットワーク設計書の全体体系、必須ドキュメント一覧、基本設計・詳細設計の書き分け基準、そして現場で形骸化させないための設計原則を網羅して解説します。

ネットワーク設計プロセスの全体像｜基本設計と詳細設計の違い

ネットワーク設計を始めるにあたり、最初に押さえるべきは「いま自分がどの工程にいて、誰に向けて何を書いているのか」という全体像です。

V字モデルで見る「設計」と「試験・運用」の対応関係

インフラ・ネットワーク構築には、システム開発と同様の「V字モデル」が存在します。左側の上流工程（設計）で定義した内容は、右側の下流工程（試験・運用）と1対1で対応しています。

• 基本設計（Why / What）: どのような通信要件・可用性・セキュリティ基準を満たすかを定義します。対応する試験は「総合試験（機器停止時の自動フェイルオーバーや通信遅延の検証など）」です。
• 詳細設計（How）: 基本設計の方針を、具体的な機器設定値・ポート割り当て・IPアドレス・結線に落とし込みます。対応する試験は「単体・結合試験（ポート認識、ルーティングテーブル確認、個別セグメント間の疎通など）」です。

この対応関係が曖昧なまま書き始めると、「基本設計書に細かすぎるコマンドが記載されている」「詳細設計書に必要な情報が漏れていて試験項目が作れない」といった手戻りが発生します。

基本設計（Why/What）と詳細設計（How）の明確な境界線

現場で最も混乱しやすいのが、「基本設計書と詳細設計書で記載項目をどう切り分けるか」という境界線です。それぞれの役割と記載レベルの違いは以下の通りです。

比較項目	基本設計書（外部設計）	詳細設計書・パラメータシート（内部設計）
主な目的	方式の提示、顧客・他チーム（サーバ/アプリ）との合意形成	構築作業・設定投入のインプット、移行手順への落とし込み
想定読者	クライアント情シス、PM、サーバ/クラウド担当者	構築担当SE、保守ベンダー、現場運用担当者
記述内容	方式・選定理由・設計思想（Why / What）	具体的な数値・個別設定パラメータ（How）
扱う情報例	冗長化プロトコルの選定理由（VRRP vs スタック）、ルーティング方式、帯域設計、VLAN分離方針	ホスト名、VLAN ID、サブネットマスク、ポート収容位置、ACLのシーケンス番号と許可IP
主な成果物形式	Word、Wikiなどの「文書・構成図」中心	Excel、スプレッドシートなどの「一覧台帳・表」中心

ネットワーク構築の5大フェーズと成果物マップ

要件定義から運用開始までの各フェーズで作成される標準的なドキュメントの流れです。

1. 基本設計フェーズ
   • ネットワーク基本設計書
   • 物理ネットワーク構成図
   • 論理ネットワーク構成図
   • セキュリティ基本設計方針
2. 詳細設計フェーズ
   • 機器別パラメータシート
   • IPアドレス管理台帳
   • ラック搭載図・ポート収容表
   • ケーブル結線表
   • FWポリシー / ACL定義シート
3. クラウド連携設計（ハイブリッド環境）
   • ハイブリッドクラウド接続設計書（AWS Direct Connect / Azure ExpressRoute等）
   • クラウド側ルーティング・セキュリティグループ定義
4. 試験・移行フェーズ
   • 単体・結合・総合試験仕様書 / 結果報告書
   • ネットワーク移行計画書 / 切替当日のタイムチャート・手順書
5. 運用フェーズ
   • ネットワーク運用設計書（監視項目一覧、バックアップ手順、障害時エスカレーションフロー）

なぜ設計書は形骸化するのか？現場で活きる「3つの設計原則」

何十ページもの立派な設計書を作っても、半年後には誰も見なくなるケースは現場で頻発します。設計書を陳腐化させず、「生きたドキュメント」として機能させるための原則を解説します。

現場の3大失敗：Configコピペ・最新版迷子・Excel職人化

1. 「Configの貼り付け＝設計書」になっている機器の設定コマンド（show running-config）をそのまま貼り付けただけの資料。後から見返したエンジニアが「なぜこのタイマー値にしたのか」「なぜこのルーティング設計なのか」という設計意図を読み取れません。
2. 「作った瞬間が最新版」で更新が止まるカットオーバー後の運用フェーズで実施された緊急のルーティング変更やポート変更がドキュメントに反映されず、実機設定と設計書の内容が乖離していきます。
3. 「Excel方眼紙」の職人化セルの結合や複雑なマクロを多用した結果、作成した本人しか触れない「秘伝のタレ」と化し、メンテナンスが放棄されます。

原則①：「設計思想（変わらないもの）」と「パラメータ（変わるもの）」を分離する

設計書を長寿命にする最大のコツは、情報の更新頻度に応じてドキュメントを物理的に切り分けることです。

• 設計書本体（Word / Wikiなど）:「なぜその構成・プロトコルを採用したのか」「何を考慮して冗長化を組んだのか」といった設計思想・選定理由を書きます。システムの大規模刷新がない限り、この内容は頻繁には変わりません。
• 管理台帳・パラメータシート（Excel / スプレッドシートなど）:IPアドレスの割り当て、ポート収容位置、FWの許可ルールなど、日々の運用変更で増減・更新されるデータを集約します。

この2つを無理に1冊の文書にまとめようとすると、日常の小さな変更のたびに重たい設計書全体を改版することになり、結果として更新が放置されます。

原則②：深夜の障害対応で役立つ「逆引きトレーサビリティ」

ドキュメントの真の価値が問われるのは、平時ではなく「夜間の障害対応時」です。

アラートが発生した際、運用・保守担当者は次の順序で情報を辿ります。

1. アラート検知: 「どのホストの、どのポートがDownしたか」
2. 構成図で特定: 「そのポートの対向は何で、どのシステムに業務影響が出るか（影響範囲）」
3. 台帳で確認: 「物理的にどのラックの何段目にあり、何色のケーブルを抜けばいいか」

構成図の論理名、パラメータシートのポート番号、ラック搭載図の配置、実機のポートラベルが1対1で整合（トレーサビリティを確保）していなければ、迅速な障害切り分けは不可能です。

原則③：変更管理プロセス（ITIL）とドキュメント更新の連動

ドキュメントの更新を「エンジニアの善意」に頼ってはいけません。業務プロセスとして更新を義務付ける仕組みが必要です。

ITILベースの変更管理プロセスにおいて、「設計書・台帳の修正ドラフトが添付されていない変更申請は承認しない」、あるいは「作業完了報告のチェック項目に、ドキュメントの最新化を含める」といったルールを運用基準に組み込むことが最も確実な防止策です。

【一覧表】ネットワーク設計で作成する必須ドキュメント・記載項目まとめ

ネットワーク設計で作成する主要ドキュメントの一覧です。案件規模や要件に応じて必要なものを取捨選択するチェックリストとして活用してください。

分類	ドキュメント名	フェーズ	必須記載項目・主な役割	重要度
基本設計	ネットワーク基本設計書	基本	全体構成方針、冗長化方式、サイジング・帯域計算、命名規則	★★★
	論理ネットワーク構成図	基本	L2/L3トポロジ、VLAN境界、ルーティング、IP体系	★★★
	物理ネットワーク構成図	基本	機器設置拠点、物理結線、LAG構成、対向インターフェース	★★★
詳細・台帳	機器別パラメータシート	詳細	ホスト名、Management IP、NTP/DNS、SNMP、各IF詳細設定	★★★
	IPアドレス管理台帳	詳細	サブネット一覧、CIDR、NWアドレス、GW、固定割当一覧	★★★
	ラック搭載図・ポート収容表	詳細	ラック内U位置、電源容量、ポートごとの接続先機器・設定VLAN	★★☆
	ケーブル結線表	詳細	ケーブルタグID、端子種別（RJ45/LC/SC）、色分け、配線経路	★★☆
セキュリティ	FWポリシー / ACL定義書	詳細	送信元/宛先IP、プロトコル、ポート番号、アクション、通信理由	★★★
	VPN・外部接続設計書	詳細	IPsec（IKEフェーズ1/2）、暗号化アルゴリズム、NAT/NAPT変換	★★☆
クラウド	ハイブリッド接続設計書	詳細	Direct Connect / ExpressRoute、BGP設定、VPC/VNetルート	★★★
試験・運用	ネットワーク試験仕様書	試験	単体疎通、冗長化切替（抜線・電源断）、フェイルオーバー時間	★★★
	ネットワーク移行計画書	移行	切替当日のタイムチャート、手順、切り戻し基準・復旧手順	★★☆
	ネットワーク運用設計書	運用	監視設計（死活・リソース・SNMP）、Configバックアップ、連絡体制	★★★

【カテゴリ別】各設計書の作成ポイントと個別詳細ガイド

ここからは、各ドキュメントを作成する際に押さえておくべき実務上のポイントをカテゴリ別に解説します。各論のより踏み込んだ解説は、個別記事（クラスター記事）で詳しく掘り下げています。

物理・論理構成図：L1とL2/L3を1枚に混ぜない鉄則

ネットワーク構成図を作成する際、最も避けるべきは「物理配線と論理的なパケットの流れを1枚の図に混在させること」です。

• 物理構成図（L1視点）
  機器の物理的な配置と結線を描きます。スタック構成のスイッチであっても物理的には2台存在するため、2つの筐体として描き、物理ポート同士の結線やポートチャネルを表現します。
• 論理構成図（L2/L3視点）
  パケットが論理的にどう流れるかを描きます。スタック化されている機器は「1台の論理スイッチ」として描き、VLANの広がり、デフォルトゲートウェイの位置、ルーティングプロトコル（OSPFやBGP）の境界を明確にします。

「構成図を描いたものの、上司や顧客から『物理なのか論理なのかわからない』と指摘された……」という方は少なくありません。

現場作業員が迷わない物理図と、障害対応で即座に役立つ論理図をプロはどう描き分けているのか、その鉄則を以下の記事で徹底解説しています。

パラメータシート・管理台帳：DBとして扱えるフラットなExcel設計

パラメータシートや各種台帳をExcelで管理する場合、見た目の綺麗さよりも「データベース（表データ）としての扱いやすさ」を最優先にします。

• セルの結合を禁止する
  セル結合があると、オートフィルタや並び替え、Python等を使った自動チェック処理が破綻します。
• 対向関係を同一レコードに持たせる
  ポート収容表では、「自ポート番号」「対向機器名」「対向ポート番号」「設定VLAN」「ケーブルID」を1行に並べます。これにより、障害時に1行を見るだけで接続先と設定が特定できます。

セグメントの階層化ルールや、障害時に即座に追跡できるポート定義の書き方、さらにExcelからCLI設定コマンドを一括自動生成する実務テクニックについては、以下の個別記事で詳しく解説しています。

セキュリティ・通信ポリシー：Any乱用防止と変更申請の紐付け

ファイアウォール（FW）やルータのアクセス制御リスト（ACL）は、運用年数が経つにつれて肥大化し、「誰が何の目的で作ったかわからないルール」が蓄積しがちです。

• 「Any」を安易に使わない
  送信元やプロトコルをAnyにせず、業務要件に基づきIPレンジやポート番号を絞り込みます。
• ルールと申請情報の紐付け
  定義シートに「関連案件名/申請番号」「通信が必要な理由（例：給与計算システムとDBの連携）」「有効期限」を必須項目として持たせます。これがないと、サーバ撤去時に通信ルールを棚卸し・削除できなくなります。

ステートフルFWとステートレスACLの違い、必須の記載10項目、Egress統制、そして監査に耐えるオブジェクト管理や運用チェックリストについては、以下の個別記事で詳しく解説しています。

ハイブリッド・クラウド接続：オンプレとAWS/Azureの境界設計

オンプレミスネットワークとAWS（Direct Connect）やAzure（ExpressRoute）を接続する場合、クラウドアカウント特有の制約を意識した設計が不可欠です。

• IPアドレス空間の重複回避
  将来的なクラウド利用拡大を見据え、オンプレミスとクラウドアカウント群でCIDRが衝突しない体系を定義します。
• 非対称ルーティングの防止
  専用線とバックアップVPNの冗長構成をとる場合、往路と復路の経路が一致するよう、BGPの属性値（AS-Path Prepend、Local Preference）やルート集約を詳細設計に落とし込みます。
• MTUサイズとMSSの考慮
  VPN等のカプセル化によるオーバーヘッドを見越し、Path MTU DiscoveryやMSSクランプの調整要件を記載します。

オンプレミスとクラウドリソースの対照表や、実務でそのまま使えるパラメータシートの書き方は、以下の個別記事で詳しく解説しています。

試験・移行・運用設計：異常系試験と切り戻し基準の明確化

設計フェーズの最後には、下流工程で確実に稼働させるための試験仕様書と移行計画を策定します。

• 異常系試験（障害切替）の具体化
  ケーブル抜線、電源モジュール障害、プロセスクラッシュ時に、何秒でフェイルオーバーし、何パケットのドロップで収まるかをあらかじめ設計値として定義し、試験項目とします。
• ロールバック（切り戻し）判断基準
  移行当日のタイムチャートには、「何時何分までに疎通が確認できなければ切り戻しを開始するか」という判断限界時刻（デッドライン）と手順を必ず明記します。

手戻りやサービス停止事故を防ぐ鍵は、作業が破綻する前に撤退ラインを明確にする「ロールバック基準の事前合意」にあります。

以下の記事では、現場経験をもとに「切り戻し限界時刻の逆算設計」や「パケットロス許容時間による客観的な合否判定基準」を詳しく解説しています。

そのまま使える！ネットワーク設計書の標準目次サンプル（記載項目例）

新規でネットワーク設計書を作成する際に活用できる、実務標準の目次案です。各章に「具体的に何を記述すべきか」の要点を併記しています。

【基本設計書】標準章立て・項目一覧（解説付き）

Wordや社内Wiki（Confluence、Notion等）でまとめる際の標準的な目次構造です。

第1章 システム概要および設計方針
  1.1 本システムの目的と背景（※ネットワーク刷新の背景、ビジネス上の要件）
  1.2 全体基本方針（※可用性目標、将来拡張性、セキュリティレベル）
  1.3 前提条件および制約事項（※既存資産の流用、ラック空き状況、回線納期）
  1.4 命名規則（※ホスト名、VLAN名、インターフェース記述の命名ルール）

第2章 物理設計
  2.1 物理ネットワーク構成方針（※拠点間接続、データセンター配置）
  2.2 採用機器一覧およびハードウェア選定理由（※スループット、ポート密度）
  2.3 物理インターフェース収容・リンクアグリゲーション設計（※LAG構成、帯域計算）
  2.4 電源・耐震・ラック搭載要件（※冗長電源供給、消費電力、発熱量）

第3章 論理設計（L2/L3）
  3.1 論理ネットワーク構成方針（※パケットフローの全体像）
  3.2 VLAN設計およびセグメント分離方針（※業務別、管理別のゾーン分離基準）
  3.3 IPアドレス設計（※社内アドレス体系、サブネット分割基準、CIDR）
  3.4 ルーティング設計（※静的ルート、OSPF/BGPの採用理由と設計パラメータ）
  3.5 冗長化・高可用性設計（※FHRP方式、スタック、仮想シャーシの切替動作）

第4章 セキュリティ設計
  4.1 セキュリティゾーン区分（※Untrust、DMZ、Trust等のゾーン定義）
  4.2 通信制御方針（※原則拒否（Default Deny）方針、許可基準）
  4.3 リモートアクセス・拠点間接続設計（※VPN認証方式、暗号化方式）

第5章 ネットワークサービス・共通機能設計
  5.1 時刻同期（NTP）および名前解決（DNS）方針（※参照先サーバ、階層設計）
  5.2 アドレス自動割り当て（DHCP）方針（※スコープ設計、リース期間）
  5.3 QoS・帯域制御方針（※音声・基幹通信の優先制御基準）

第6章 運用・管理設計
  6.1 管理アクセス設計（※SSH制限、コンソール接続、管理VLAN定義）
  6.2 監視方針（※死活監視、SNMPポーリング、トラップ、Syslog送信先）
  6.3 コンフィグバックアップ方針（※世代管理、自動取得の仕組み）

【詳細設計・パラメータシート】標準シート構成と管理項目

Excelやスプレッドシートでパラメータを管理する際の標準的なシート分割と、各シートの管理項目です。

1. 表紙・改版履歴ドキュメント名、バージョン、改版日、作成者、承認者、改版内容サマリ。
2. 機器共通情報ホスト名、管理IPアドレス、デフォルトGW、DNS/NTP参照先、ドメイン名、OSバージョン、シリアル番号。
3. 物理ポート収容一覧（IFシート）ポート番号、接続先対向機器、対向ポート、リンク速度/Duplex、PortFast等の設定、適用VLAN。
4. VLAN・L3インターフェース一覧VLAN ID、VLAN名、IPアドレス/サブネットマスク、VRRP仮想IP、プライマリ/セカンダリ指定。
5. ルーティング設定一覧静的ルート（宛先NW、NextHop、メトリック）、ダイナミックルーティング設定（AS番号、Area、Neighbor IP）。
6. ACL・セキュリティポリシー一覧適用機器、適用IF/方向（In/Out）、シーケンス番号、送信元、宛先、プロトコル、ポート、アクション、申請理由。

フォーマットの使い分け（Excel vs Word/Wiki vs Markdown/Git）

「設計書は何のツールで書くのがベストか」という議論がありますが、実務における現実的な最適解は「特性に応じたハイブリッド運用」です。

• Word / Wiki（Confluence, Notion等）
  基本設計書、運用設計書向けです。「文章による設計意図の説明」や「構成図の配置」が主体のドキュメントに適しています。
• Excel / スプレッドシート
  パラメータシート、IP台帳、ポート収容表向け。行と列で構造化されたデータの一覧性、オートフィルタによる検索性において依然として実務上のデファクトスタンダードです。
• Markdown / Git（Docs as Code）
  クラウドネイティブ環境や自動化が進んだ現場向け。コード（IaC）と同様に差分管理（Git Diff）やプルリクエストによるレビューが回せるメリットがあります。

まとめ：設計書は「作って終わり」ではなく「運用し続けるための地図」

ネットワーク設計書の本質は、納品物として提出することではなく、システムが稼働し続ける限り「現場の誰もが迷わず運用・トラブルシューティングできる地図」であり続けることです。

• V字モデルを意識する: 上流の「基本設計（Why）」は総合試験・運用に、下流の「詳細設計（How）」は構築・単体試験に直結させる。
• 思想とパラメータを分ける: 不変の設計思想と、可変のパラメータ台帳を分離して形骸化を防ぐ。
• 物理と論理を混ぜない: 物理配線（L1）とパケット経路（L2/L3）は図面を明確に分ける。
• 障害対応の逆引き性を確保する: アラート検知から影響範囲と物理ポートが1本で繋がるトレーサビリティを持たせる。

これからプロジェクトを立ち上げる方は、まずは第3章の「ドキュメント一覧表」をチェックリストとして使い、自分たちのシステムに必要な設計ドキュメントを定義することから始めてみてください。