コネクティビティ図とは何か：種類・重要性・実務作成ステップと活用ガイド
エバープレイ編集部コネクティビティ図とは何か — 概念と位置づけ
コネクティビティ図（Connectivity Diagram）は、システムやネットワーク内の「要素間の接続関係」を視覚的に表現する図の総称です。厳密に定義された単一の標準図ではなく、目的に応じて「物理的接続」「論理的接続」「データフロー」「サービス依存関係」など異なる観点で作られる図を含みます。IT設計・運用の現場ではネットワークの配線図、トポロジ図、アプリケーション間の通信経路図、ラック配線図、クラウドのサービス接続図などが「コネクティビティ図」と呼ばれることが多いです。
なぜコネクティビティ図が重要か
可視化による理解促進：設計や障害対応時に、接続関係が一目で分かるため意思決定が速くなります。
トラブルシューティング：物理層からアプリケーション層まで接続経路を辿れることで、原因切り分けの精度が上がります。
セキュリティ設計：信頼境界、ゾーニング、フィルタリング箇所を明示することで脆弱性評価やアクセス制御の設計が容易になります。
運用・変更管理：構成管理（CMDB）や変更作業の前に接続関係の影響範囲を評価できます。
コンプライアンスと監査：外部監査や規制対応時に、ネットワーク分離やログ送信経路などの証跡として有用です。
コネクティビティ図の主な種類
用途や対象レイヤーに応じて、以下のような図が代表的です。
物理接続図（Physical Connectivity / Wiring Diagram）：ケーブル、ポート、ラック、スイッチの物理的な配線を示す図。データセンターやオンプレミス設備の配線管理に使われます。
ネットワークトポロジ図（Network Topology Diagram）：ルーター、スイッチ、ファイアウォール、サブネットやVLANの構成を示す論理的図。経路や冗長化、帯域に注目します。
アプリケーション・サービス接続図（Application/Service Connectivity）：マイクロサービスやアプリケーション間のAPI呼び出し、メッセージング経路、データベース接続などを示します。
データフロー図（DFD／Data Flow Diagram）：データの流れ（どこからどこへ、どのプロセスを経由するか）に注目した図。セキュリティ、プライバシー影響評価で重要です。
クラウド接続図（Cloud Connectivity Diagram）：クラウドサービス（VPC、サブネット、サービスエンドポイント、オンプレミスとのVPN/Direct Connectなど）の接続関係を表現します。
依存関係図（Dependency/Service Map）：サーバーやサービスの依存関係を示し、可観測性ツールやAIOpsで自動生成されることもあります。
関連する標準と注意点
「コネクティビティ図」は汎用的な呼称であり、UMLの正式なダイアグラム名ではありません。UMLでは配置図（Deployment Diagram）やコンポーネント図（Component Diagram）などが接続関係の記述に使われます。また、システムアーキテクチャの記述に関する国際規格としてはISO/IEC 42010（以前のIEEE 1471）などがあり、利害関係者ごとの「ビューとビューのモデル」を作ることを推奨しています。これらの考え方を踏まえて、誰向けに何を伝える図か（スコープと表現レベル）を明確にすることが重要です。
コネクティビティ図の作り方（実務的ステップ）
以下は実務で使えるステップです。
目的とスコープを決める：誰が使うのか（ネットワーク運用、アプリ開発、セキュリティ）、どのレイヤーを対象にするか（物理／論理／アプリ）を定義します。
資産のインベントリを取る：機器、VM、コンテナ、サービス、サブネット、ケーブルなど接続対象を一覧化します。自動取得可能ならAPI/ツールで取得するのが望ましいです。
接続情報の収集：ポート、IPアドレス、VLAN、プロトコル、使用帯域、冗長経路などを収集します。ログやフロー（NetFlow、sFlow）、サービスディスカバリを活用します。
レイヤー分離と抽象化：複雑にならないようレイヤーごとに図を分け、必要に応じてドリルダウン方式（概要図→詳細図）を採用します。
表記ルールと凡例の明示：色、線種、アイコン、ラベルのルールを決め、図ごとに凡例を付けます。
ツールで作図：Visio、diagrams.net（旧 draw.io）、Lucidchart、PlantUML（テキストベース）、クラウドベンダーの図形セットなどを利用します。
検証とレビュー：現場の運用者や開発者にレビューしてもらい、設計や運用の視点で齟齬がないか確認します。
運用と更新プロセスを決める：図は陳腐化しやすいので、更新の担当者、トリガ（変更管理のフロー、CI/CDのイベント等）、保存場所を定めます。
現場で気をつけるべきポイント（チェックリスト）
誰のための図かを常に明確にする（例：ネットワークエンジニア向けは物理・VLAN情報を重視）。
機密情報の扱いに注意する（図に乗せるIP、認証情報はマスクする）。
過度な詳細を避ける：図が煩雑になれば本来の目的を失う。階層化を検討する。
自動化と手動メンテのバランス：自動更新可能な部分はツールで自動化し、手動でしか得られない情報は明示する。
バージョン管理を行う：変更履歴や差分が追えるようにする（Git、ドキュメント管理システム等）。
ツールと自動化の例
近年は手描きや手作業の図に加え、自動でコネクティビティを抽出して図にする仕組みが広がっています。代表的なツールと用途は次の通りです。
diagrams.net（旧 draw.io）/Visio/Lucidchart：手動作図に強く、テンプレートやクラウドアイコンも豊富。
NetBox：ネットワークの「ソース・オブ・トゥルース（Source of Truth）」としてIPAM／DCIM情報を管理し、接続情報と連携して図を生成できます。
監視・可観測性ツール（Grafana、Datadog、New Relic等）：サービス間の通信やトレーシング情報をもとに依存関係図を動的に表示します。
自動化ツール（Ansible、Terraform）：インフラ定義と図を連携させることで、インフラの状態と図の整合性を保てます。
セキュリティ設計への活用法
コネクティビティ図はセキュリティ設計で非常に有用です。以下の観点で活用できます。
信頼境界（Trust Boundaries）：社内/外部、DMZ、VPC間などの境界を明示し、どこでどのようなアクセス制御を行うかを定義します。
最小権限とアクセス経路：不要な経路（経由点）を可視化して遮断し、攻撃面を削減します。
監査ポイントの設置：ログ集約ポイントや監視エンドポイントを図に示し、監査やフォレンジックの準備を行います。
可用性と耐障害性の評価：冗長経路やフォールトドメインを図にして設計ミスを防ぎます。
実務での活用事例（簡単なケース）
例：オンプレミスとクラウドを組み合わせたハイブリッド構成では、以下のようなコネクティビティ図を用意すると効果的です。
概要図：オンプレミスデータセンター ⇄ VPN/Direct Connect ⇄ クラウドVPC の高レベル接続。主要サービスの位置を示す。
ネットワーク図（詳細）：サブネット、ルート、NAT、ファイアウォールルール、VLAN、IPレンジを明示。
アプリ接続図：フロントエンド → APIゲートウェイ → マイクロサービス → データストア の通信経路、認証方式（OAuth、mTLS等）を記載。
物理配線図：データセンター内のラック配置とケーブル経路（運用側向け）。
まとめ — 良いコネクティビティ図の条件
良いコネクティビティ図は「伝えたい相手にとって必要十分な情報を、誤解なく、継続的に保てる形で示す」ことです。目的とスコープを明確にし、レイヤー分離、凡例の整備、自動化による更新性の担保、そして運用フローとの連携を重視してください。これらを実践することで、設計の質が向上し、運用コストや障害対応時間の削減に直結します。
参考文献
- Network diagram — Wikipedia
- Unified Modeling Language — Wikipedia (Deployment/Component diagrams)
- ISO/IEC 42010 — Systems and software engineering — Architecture description — Wikipedia
- NetBox — Documentation
- diagrams.net (draw.io)
- Microsoft Azure Architecture Center — Microsoft Docs
- AWS Architecture Center — Amazon Web Services
- Network Diagram Resources — SolarWinds
投稿者プロフィール
