システム構成図の書き方｜目的別の描き分けと記載のポイント

システム構成図は、システムを構成する要素とそのつながりを一枚で示す図です。誰に何を伝える図なのかを決めずに描き始めると、情報が多すぎて読めない図か、足りなくて使えない図になりがちです。本記事では、目的の整理から描く前の準備、手順、読み手別の描き分け、ありがちな失敗、更新の運用までを順に解説します。システム開発やインフラの現場、PMOとして図を扱う方が、実務でそのまま使える書き方を押さえられる構成です。

システム構成図の目的

システム構成図の目的は、システムの全体像を関係者が同じ形で理解できるようにすることです。

構成図は、開発状況の明確化、エンジニア間の情報共有、問題発見や改善案検討の効率化、ユーザーやクライアントへの視覚的な説明といった場面で使われます。図の出来が悪いと、これらの場面ごとに口頭の補足が必要になり、認識のずれが生まれます。

誰に何を伝えるか

描き始める前に、読み手と伝えたい一点を決めます。この二つが決まらない図は、情報を足すほど読みにくくなります。

たとえば経営層には「どの業務がどのシステムで動くか」、開発者には「どのコンポーネントがどうつながるか」、運用者には「どの機器が稼働し、どこを監視するか」が伝われば十分です。同じシステムでも、伝えたい一点が違えば図の形も変わります。なお、構成図や設計の整理は上流寄りの工程で求められる仕事で、ドメイン知識ベースの整理でも、上流（戦略策定・要件定義）は運用・保守寄りより高単価の傾向があり、IT戦略が月150〜200万円に対し、運用・保守寄りは下限が月50〜60万円台とされています。

種類(論理・物理)

構成図は、役割のつながりを示す論理構成図と、実際の機器の配置を示す物理構成図に大別されます。

一般に、物理構成図は実際の機器配置を、論理構成図は仮想サーバーやIPアドレスなどの論理的な関係を示すものとして説明されます。次の表のとおり、使い分けは「何を確かめたいか」で決まります。

描く前の準備

描く前に、対象範囲と使う用語・記号を決めておくと、途中の描き直しがほとんど要らなくなります。

手を動かす前の準備に十分な時間を割くかどうかで、仕上がりの読みやすさと作業時間が大きく変わります。

対象範囲の確認

対象範囲は「どこまでを自分たちのシステムとみなすか」を、依頼元と合意してから決めます。

外部サービスや既存の基幹システムとの接続部分を、図に含めるのか、境界として点線で示すだけにするのかを先に決めます。範囲があいまいなまま描くと、レビューの場で「この連携は入っていないのですか」という指摘が出て、描き直しになります。あわせて、図の用途（提案資料、設計書、運用手順書など）と配布先も確認しておきます。

用語と記号の統一

同じものには同じ名前と同じ記号を使い、凡例を図の隅に置くのが基本です。

「DB」と「データベース」、「APサーバー」と「アプリケーションサーバー」が図の中で混在すると、別の要素に見えてしまいます。名称の表記を決め、実線は「データの流れ」、点線は「制御の流れ」のように線の意味を凡例に書きます。図を描くツールを変えても読み手が迷わないように、記号の意味は図の中で完結させます。

書き方の手順

書き方の手順は、要素を洗い出し、つながりを整理し、補足情報を足す三段階です。

全体像から先にまとめ、細部は後から足す順で進めると、情報の取りこぼしと詰め込みの両方を防げます。

要素の洗い出し

要素は、製品名ではなく役割で書き出すのがコツです。

「製品Aを使っている」という情報だけでは、製品を知らない読み手には何をする部品なのか伝わりません。「Webサーバー」「アプリケーションサーバー」「データベース」のように役割で書き、必要なら製品名を括弧で添えます。次の表は、架空の社内申請システムを例に、要素と役割を洗い出した記載例です。

つながりの整理

つながりは、データの流れと制御の流れを線の種類で書き分けて整理します。

一般に、わかりやすい構成図の工夫として、データと処理を形で書き分けること、データの流れと制御の流れを線で書き分けることが挙げられます。たとえばこの申請システムでは、アプリケーションサーバーからデータベースへの書き込みは実線、メールサーバーへの通知依頼は点線にする、といった決め方です。複雑さが増して一枚の構成図では表しきれない場合は、UMLなどの形式を検討する選択肢もあります。

補足情報の追加

補足情報は図に詰め込まず、別紙や注記に分けて載せます。

IPアドレス、ポート番号、台数、冗長構成の有無といった詳細は、一覧表として別紙に整理し、図には「詳細は別紙のサーバー一覧を参照」と一行添える程度にとどめます。図は全体像、別紙は詳細という役割分担にすると、図の見通しが保たれます。

読み手別の描き分け

同じシステムでも、読み手が変われば描くべき粒度と要素が変わるため、一枚で全員に対応しようとしないことが大切です。

ひとつの図を全員に見せようとすると情報が増え、誰にとっても読みにくい図になることがあります。読み手ごとに図を分け、元になる要素の名称だけは共通にしておくと、図同士の整合も保てます。

経営層向け

経営層向けは、業務とシステムの対応が一目で分かる大きな箱だけの図にします。

箱は多くても数個にとどめ、「受注管理」「在庫管理」「会計」のように業務の言葉で書きます。サーバーやネットワークの名称は出さず、外部サービスとの接続と、投資や変更の影響範囲が見えることを優先します。

開発者向け

開発者向けは、コンポーネント間のつながりとデータの受け渡しを細かく示す図にします。

通信の向き、プロトコル、データの流れと制御の流れの区別、外部システムとのインターフェースを明記します。実装に必要な粒度が求められるため、論理構成図を中心に、要素の役割と依存関係が読み取れることが条件です。

運用者向け

運用者向けは、実際の機器の配置と、監視・バックアップ・障害時の切り分けに必要な情報を載せる図にします。

物理構成図を中心に、機器名、設置場所、回線、冗長構成の有無を示します。障害が起きたときにどこから確認するかを追えることが、この図の使いどころです。編集部の実務の観点では、運用の引き継ぎ時に論理構成図しか無いと、機器の所在が分からず切り分けに時間がかかることがあります。そのため、運用者向けには物理構成図を必ず添えるようにしています。

ありがちな失敗

構成図の失敗は、情報の詰め込みすぎと、作った後に更新されないことの二つに集約されます。

情報過多

一枚の図に目的の異なる情報を混ぜると、どの読み手にも読みにくい図になります。

論理と物理を同じ図に重ねる、全サーバーのIPアドレスを図中に書く、といった描き方が典型です。対処は、伝えたい一点に関係しない要素を図から外し、別図や別紙に移すことです。迷ったときは「この要素が無いと、伝えたい一点が伝わらなくなるか」を基準に取捨選択します。

更新されない図

更新されない図は、現場の実態と食い違い、読む人を誤らせる点で、図が無い状態よりも危険です。

構成変更のたびに図を直す担当と手順が決まっていないと、初版のまま放置されます。古い図を信じて作業すると、存在しない機器を前提に判断することにもなります。更新対象の図が最新かどうかを、図自体に最終更新日と版数で示すことも有効です。

維持管理の運用

構成図は、変更時に必ず更新する決まりと、定期的に見直す機会を設けて維持します。

変更時の更新ルール

更新ルールは、「構成変更の作業完了条件に図の更新を含める」と決めるのが最も確実です。

変更の依頼書やチケットに「構成図の更新要否」の欄を設け、更新担当者と期限を明記します。図の保管場所は一か所に決め、版数と最終更新日を図の隅に記載します。ファイルが複数の場所に散らばると、どれが最新か分からなくなります。

レビューの機会

定期レビューでは、図と現場の実態を照合し、差異があればその場で直します。

四半期や半期ごとの運用会議、システム更改の前後など、決まったタイミングで構成図を見直す場を設けます。運用者と開発者が同席して図を読み合わせると、記載漏れや古い情報が見つかりやすくなります。なお、要件定義書やシステム開発の流れとあわせて整理しておくと、構成図の位置づけがより明確になります。関連する解説として、システム構成図の種類や実務での使い方、システム開発の流れ、要件定義書の書き方の具体例、システム開発の体制図の作り方、ER図の書き方もあわせてご覧ください。

システム構成図の書き方は、目的と読み手を決め、準備を整え、手順に沿って描き、運用で維持するという流れに集約できます。本記事は2026年10月時点の情報に基づいています。

出典・参考情報

1. Qiita「わかりやすいシステム構成図の書き方」（2026-10-07参照）
2. Udemy Benesse「システム構成図とは？構成図の種類や書き方・コツを解説」（2026-10-07参照）

本記事は2026年10月時点の情報に基づいています。最終更新日：2026年10月7日。