システム構成図とは？種類と書き方・例、発注者が確認すべき観点を解説

システム構成図とは、サーバーやネットワーク、ソフトウェア、データの流れといったシステムの構成要素を、全体像として1枚の図に描き起こしたものです。設計工程の成果物として作られ、開発チームの認識合わせだけでなく、障害対応や保守、発注者への説明にも使われます。この記事では、システム構成図の種類（物理・論理・ネットワーク・アプリケーション）と書き方の流れ、初心者でも破綻しない作図例、代表的な作成ツール、そして開発を外注する発注者がレビューで何を確認すべきかまでを、発注する側の視点で整理します。図を開発会社任せにせず、要所で読み解くための手引きとして読んでください。

まとめ｜システム構成図の役割と発注者が押さえる要点

システム構成図は、システムを構成するハードウェア・ソフトウェア・ネットワークと、その間を流れるデータの経路を一望できるようにした図です。目的は3つあります。開発チーム内で構成の認識を揃えること、障害時にどこが原因かを素早く切り分けること、そして発注者や運用担当に構成を説明することです。

種類は描く対象で分かれます。機器や回線の物理配置を示す物理構成図、機能とデータの流れを示す論理構成図、通信経路に絞ったネットワーク構成図、アプリケーションの層を示すアプリケーション構成図が代表的です。1枚に詰め込まず、読み手と目的に合わせて描き分けるのが実務の勘所になります。

書き方は、目的の明確化から始めて全体像を洗い出し、要素をアイコンにして関係を線でつなぎ、細部は別紙に逃がす、という流れが基本です。作図にはCacooやMiro、diagrams.netといったツールが使えます。

発注者にとって構成図は、開発会社の設計品質を見抜く材料です。単一障害点がないか、データがどこに保管されるか、外部サービスとどう連携するかは、構成図を1枚見れば判断できます。構成図を出さない、あるいは古いまま更新しない開発会社は、後工程で認識のズレを起こしやすいと考えてよいでしょう。上流の設計から成果物を示しながら伴走できる会社を選べるかどうかが、開発の成否を分けます。工程全体の中での位置づけはシステム開発の工程で確認できます。

システム構成図とは何か、システム全体の構造を可視化する図としての役割

システム構成図は、システムを形づくる要素と、その関係を1枚に描いた設計図です。文章で「Webサーバーとデータベースがあり、ロードバランサーで分散して……」と説明するより、図で示したほうが構造は一目で伝わります。

システム構成図の定義と、図が表すハードウェア・ソフトウェアの範囲

システム構成図とは、サーバー・ストレージ・ネットワーク機器といったハードウェアから、OS・ミドルウェア・アプリケーションといったソフトウェア、さらに外部サービスとの接続までを、要素とその関係として図示したものです。四角形や円で機器やサービスを表し、線や矢印でデータの経路や依存関係をつなぎます。

どこまで描くかは目的で変わります。インフラの調達が目的なら機器の型番や台数まで、業務の流れを共有したいなら画面と処理の関係まで、といった具合です。全要素を1枚に詰め込むと読めなくなるため、扱う層を決めてから描き始めるのが実務のやり方になります。

システム構成図を作る目的と、開発・運用・障害対応で果たす役目

構成図を作る目的は、大きく3つに整理できます。1つ目は開発チーム内の認識合わせです。誰がどのサーバーを触るか、どのAPIがどこを呼ぶかを図で固定すると、口頭説明の食い違いが減ります。2つ目は障害対応です。「注文が通らない」という報告があったとき、構成図があれば決済サービスとの連携部分をすぐ疑えます。図がないと、担当者の記憶を頼りに原因を探すことになります。

3つ目は説明の道具としての役目です。発注者への進捗報告、運用への引き継ぎ、監査でのシステム説明。いずれも構成図が1枚あるかどうかで、伝わる速度が変わります。可視化そのものが目的ではなく、その先の判断を速くするために描く、と捉えてください。

どの工程で誰が作成するか、設計工程の成果物としての作成タイミング

システム構成図が本格的に固まるのは、要件定義の次に来る外部設計（基本設計）の工程です。要件定義で「何を実現するか」を決め、その要求を「どんな機器・サービスの組み合わせで実現するか」に落とすのが設計であり、構成図はその成果物として描かれます。作成の主体は、システムエンジニアやインフラ設計担当です。

ただし初期の粗い構成案は、提案・見積の段階でも描かれます。発注側はこの早い段階の図からも、想定規模や外部サービスの使い方を読み取れるでしょう。構成図が成果物として位置づく外部設計の工程と、その前段であるシステム開発の工程全体をあわせて押さえると、いつ誰が構成図に責任を持つのかが掴めます。

システム構成図の種類と、物理・論理・ネットワークの描き分けの違い

システム構成図とひとくちに言っても、描く対象によって複数の種類に分かれます。同じシステムでも、機器の配置を示す図と、データの流れを示す図はまったく別物です。ここを混同すると、読み手が知りたい情報が載っていない図になります。

物理構成図と論理構成図の違いと、それぞれで表現する情報の範囲

物理構成図は、実際の機器・回線・設置場所を表します。どのラックにどのサーバーがあり、どのケーブルでつながっているかを描くため、調達や保守で読まれる図です。論理構成図は、機器の物理配置を捨象し、機能とデータの流れに絞って表します。発注者や設計者が「業務がどう回るか」を確認するのに向いています。

両者は排他ではなく、同じシステムを別の切り口で描いたものです。発注者がまず読むべきなのは論理構成図でしょう。機器の細部より、データがどこを通りどこに残るかのほうが、業務やセキュリティの判断に直結するからです。

ネットワーク構成図やサーバー構成図との関係と、図の使い分けの目安

ネットワーク構成図は、IPアドレスやセグメント、ファイアウォールといった通信経路に焦点を絞った図です。サーバー構成図は、サーバーの役割（Web・アプリ・DB）や冗長化の構成を示します。どちらもシステム構成図の一部を詳しく描いたもの、と捉えると関係が整理できます。

使い分けの目安はこうです。全体像を1枚で伝えたいならシステム構成図、通信の許可・遮断を設計するならネットワーク構成図、サーバーの台数や冗長化を詰めるならサーバー構成図。読み手が情シスかインフラ担当か発注者かで、出す図を変えると話が早くなります。

システム構成図とアーキテクチャ図の違い、抽象度による描き分け

システム構成図とアーキテクチャ図は、しばしば同じ意味で使われますが、抽象度に差があるのが実情です。アーキテクチャ図は「どんな設計思想でシステムを組むか」という構造の考え方を示すのに対し、システム構成図は「実際にどの機器・サービスをどうつなぐか」という具体の配置を示す傾向があります。設計思想の全体像はシステムアーキテクチャの考え方として別に整理できます。

この2つに厳密な線引きはなく、現場や文脈で呼び方が揺れます。図に唯一の正解の書式がない背景についてはアーキテクチャ図に正解がない理由で掘り下げています。呼称にこだわるより、「誰に何を伝える図か」を先に決めるほうが実益は大きいはずです。

システム構成図の書き方の流れと、初心者でも破綻しない作成手順

構成図を初めて描くと、要素を並べたものの線が交差して読めない、という失敗に陥りがちです。破綻を避けるには、いきなり描き始めず、順序を踏むことです。

作成の5ステップ、目的の明確化から全体像・要素・関係線・詳細まで

作図は次の順で進めると崩れにくくなります。

1. 目的と読み手を決める（発注者説明か、障害対応か、調達か）
2. 登場する要素を洗い出す（サーバー、DB、外部サービス、利用者）
3. 要素をアイコン化し、役割がわかる名前を添える
4. データの流れと制御の流れを線と矢印でつなぐ
5. 細かい設定値は図に載せず、別紙の一覧に逃がす

とくに5番目が効きます。IPアドレスやポート番号まで1枚に書き込むと、図は途端に読めなくなるのが常です。全体像は図、細部は表、と役割を分けると、初心者でも読める構成図に近づきます。

読み手が迷わない書き方のコツと、粒度・データの流れの描き分け

書き方のコツは3つに絞れます。粒度を1枚の中で揃えること。ある部分だけ配線レベルで細かく、別の部分はサービス名だけ、という図は読み手を混乱させます。次に、データの流れ（実線）と制御の流れ（点線）を線種で区別すること。最後に、凡例を必ず付けることです。矢印や色の意味を図の隅に書くだけで、初見の読み手の理解が変わります。

階層構造も意識したい観点です。利用者から近い層（画面）を上、遠い層（データベース）を下に置くと、視線の流れと処理の流れが揃い、読みやすくなります。

作成ツールの選び方と、テンプレートを使った作図例・サンプルの探し方

作図ツールは、共同編集のしやすさとアイコンの豊富さで選ぶと外しません。代表的なものを挙げます。

• Cacoo：日本語対応が手厚く、クラウド系アイコンやテンプレートが豊富
• Miro：複数人での同時編集とホワイトボード的な使い方に向く
• diagrams.net（旧draw.io）：無料で使え、多様な図形に対応

初心者は、白紙から描くよりテンプレートやサンプルを土台にするのが近道です。多くのツールが「Webシステム構成」「AWS構成」といったテンプレートを備えており、自社の構成に近い例を選んで要素を差し替えれば、破綻の少ない図が作れます。作図例を探すときは、目的（クラウド・オンプレ・Web）で絞ると自分の用途に合うものが見つかります。

発注者が構成図のレビューで確認すべき観点と、外注時の判断基準

ここが本記事の核心です。開発を外注する発注者にとって、システム構成図は「開発会社の設計力を測る診断書」になります。図の美しさではなく、リスクがどう扱われているかを読み取ってください。

外注時に構成図で確認したい単一障害点・外部連携・データ保管先

発注者が構成図で最初に見るべきは、単一障害点（そこが止まると全体が止まる箇所）の有無です。DBサーバーが1台だけ、ロードバランサーが1つだけ、という図なら、冗長化の方針を必ず質問してください。次に外部連携です。決済・地図・認証などの外部サービスとの接続が図に描かれているか、その障害時にどうなるかを確認します。

もう1つ見落とせない観点がデータの保管先です。個人情報や機密データがどのサーバー・どの地域（国内か海外か）に保管されるかは、構成図と論理構成図を突き合わせれば読み取れます。ここが曖昧な図は、セキュリティや法令対応の設計が詰まっていない兆候だと考えてよいでしょう。

構成図を出さない・更新しない開発会社に潜むリスクとその見抜き方

ここは言い切ります。設計工程を過ぎても構成図を提示しない開発会社、あるいは初回に出したきり改修のたびに更新しない会社は、避けたほうが安全です。図がないということは、構成が担当者の頭の中にしかない状態であり、その人が抜けた瞬間に保守が止まります。実際、引き継ぎのない現場では、障害時に「誰も全体像を知らない」事態が起こります。

見抜き方は単純です。契約前に「構成図は成果物に含まれますか」「改修時に更新されますか」と尋ねること。ここで言葉を濁す、あるいは追加費用を強く求める会社は、設計の文書化を軽視している可能性があります。構成図を標準の成果物として扱う会社を選ぶだけで、保守フェーズのリスクは大きく下がります。

保守・契約で構成図が効く場面と、上流から任せる開発会社の選び方

構成図が真価を発揮するのは、開発が終わった後です。障害対応、機能追加、担当者の交代、セキュリティ監査。いずれの場面でも、最新の構成図があれば状況把握が速くなり、なければ調査から始める羽目になります。契約書やRFPの成果物一覧に「構成図（物理・論理）」を明記しておくと、後々の揉め事を防げます。

結局のところ、良い構成図は良い設計の副産物です。要件定義から設計、実装、保守までを一貫して任せられる開発会社なら、構成図は自然と成果物として出てきます。工程ごとの成果物と体制を見極めたうえで委託先を選ぶ考え方はシステム開発の工程で整理しているので、外注先の比較検討の軸として使ってください。

よくある質問

システム構成図に関して、発注者や作図の初心者からよく寄せられる質問をまとめます。

システム構成図とアーキテクチャ図の違いは？

アーキテクチャ図は設計思想や構造の考え方を抽象的に示す図、システム構成図は実際の機器・サービスの配置を具体的に示す図、という傾向で使い分けられます。ただし現場によって呼び方は揺れ、厳密な線引きはありません。呼称を議論するより、その図が誰に何を伝えるためのものかを先に決めるほうが実務では役立ちます。

システム構成図は誰が作成するのですか？

本格的な構成図は、外部設計（基本設計）の工程でシステムエンジニアやインフラ設計担当が作成します。粗い構成案は提案・見積の段階でも描かれ、発注者はその図から想定規模や外部サービスの使い方を読み取れます。作成後は、改修のたびに更新するのが理想です。

システム構成図の作成に使えるツールは？

Cacoo、Miro、diagrams.net（旧draw.io）が代表的です。Cacooは日本語対応とクラウド系アイコンが手厚く、Miroは複数人での同時編集に向き、diagrams.netは無料で多様な図形に対応します。初心者は各ツールのテンプレートを土台にすると、白紙から描くより早く仕上がります。

システム構成図とネットワーク構成図はどう違う？

システム構成図がシステム全体（サーバー・ソフト・データの流れ）を1枚で示すのに対し、ネットワーク構成図はIPアドレスやセグメント、ファイアウォールなど通信経路に焦点を絞った図です。ネットワーク構成図はシステム構成図の一部を詳しく描いたもの、と捉えると関係が整理できます。

発注側は構成図をどこまで確認すべき？

機器の細部まで読み込む必要はありません。単一障害点の有無、データの保管先（国内か海外か）、外部サービスとの連携という3点を押さえれば十分です。この3つが図に明確に描かれていない場合は、設計の詰めが甘い兆候として、開発会社に質問してください。

関連記事

• システム開発の工程とは？7フェーズの成果物と工数比率：構成図がどの工程の成果物か、発注者目線で全体像を確認できます。
• 外部設計とは？内部設計との違いと成果物：システム構成図が成果物として固まる設計工程を詳しく解説しています。
• システムアーキテクチャとは？種類と選び方：構成図が可視化する対象である設計思想の全体像を整理しています。
• アーキテクチャ図に「正解」がない理由と背景：構成図・アーキテクチャ図に唯一の書式がない背景を掘り下げています。
• 要件定義とは？目的・進め方・成果物：構成図の前段で「何を作るか」を決める工程の手引きです。