公開2026.07.06更新2026.09.08 52 人が閲覧（直近 30 日） Webシステム

システム構成図とは：種類と書き方・Mermaidでの作例、発注者が確認すべき観点

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

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

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

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

書き方は、目的の明確化から始めて全体像を洗い出し、要素をアイコンにして関係を線でつなぎ、細部は別紙に逃がす、という流れが基本です。作図にはCacooやMiro、diagrams.netといったツールが使えます。ここ数年の現場では、図をGUIで描くだけでなくMermaidやPlantUMLのテキストで書き、ソースコードと同じリポジトリでレビューと版管理に載せる進め方も広がりました。本記事では後半でその記述例をそのまま載せています。

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

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

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

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

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

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

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

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

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

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

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

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

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

システム構成図とひとくちに言っても、描く対象によって複数の種類に分かれます。同じシステムでも、機器の配置を示す図と、データの流れを示す図はまったく別物です。システム間を流れる業務データの発生源と行き先を描く側の記法と粒度はデータ連携図の書き方で扱っています。ここを混同すると、読み手が知りたい情報が載っていない図になります。

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

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

観点	物理構成図	論理構成図
表す対象	機器・回線・設置場所	機能・データの流れ
主な読み手	インフラ担当・保守	設計者・発注者
使う場面	調達・ラック設計・保守	要件確認・全体設計

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

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

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

使い分けの目安はこうです。全体像を1枚で伝えたいならシステム構成図、通信の許可・遮断を設計するならネットワーク構成図、サーバーの台数や冗長化を詰めるならサーバー構成図。読み手が情シスかインフラ担当か発注者かで、出す図を変えると話が早くなります。クラウド上で描く場合は、VPC内・VPC間・オンプレとの接続のどれを表すのかで線の意味が変わるため、AWSのネットワーク接続方式の分類を先に押さえておくと、図の凡例が固まります。

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

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

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

C4モデルで抽象度を4段階に分けて構成図を描き分ける整理の手順

抽象度の揺れを組織のルールとして畳むなら、C4モデルの公式サイトが定義する4階層を採用する手があります。C4はシステムを Context（システムと外部利用者・外部システムの関係）、Container（Webアプリ・API・DBといった実行単位）、Component（コンテナ内部の部品）、Code（クラスなどの実装）の4段階に分け、1枚の図では1階層だけを描くという約束事を置いた記法です。

この考え方を借りると、発注者に見せる図は Context と Container、開発チームが実装で使う図は Component、と読み手ごとに層を割り当てられます。UMLのように図の種類が多い記法と併用する場合は、UMLの14種類の図と実務で使う4種類の整理と突き合わせ、社内で使う図の種類を先に絞っておくと、図の乱立を防げます。

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

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

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

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

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

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

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

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

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

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

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

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

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

公式アイコン集を入手して構成図の見た目を揃える手順とライセンス

クラウド上の構成を描くなら、各社が配布する公式アイコン集をそのまま使うのが早道です。AWS アーキテクチャアイコンは公式ページで配布され、同ページの案内では四半期ごと（1月末・4月末・7月末）に更新される旨が示されています。PowerPoint用のツールキットと汎用のアイコンパッケージが用意され、diagrams.netなど外部ツールからも参照できます。

Azureを描くならAzure アーキテクチャアイコン、Google CloudならGoogle Cloud のアイコン配布ページが同種の素材を配っています。いずれも利用条件が各ページに明記されているので、社外提出物や提案書に載せる前に、条項を読んでから使ってください。手順としては、（1）公式ページからアイコンパックをダウンロード、（2）作図ツールのライブラリに読み込み、（3）自社の構成に合わせて配置、という3ステップで揃います。見た目を公式アイコンに統一しておくと、読み手がサービス名を読まずにアイコンだけで構成を追えるようになります。

Mermaidで構成図を書き、Gitでレビューと版管理まで回す手順

構成図が古びる原因の多くは、図がGUIツールの中だけにあり、コード変更のレビュー経路から外れていることです。図をテキストで書けば、プルリクエストの差分に構成変更が乗り、レビューと版管理の対象になります。ここでは実際に動く記述をそのまま示します。

architecture-beta記法でWeb三層構成を描くコードと確認手順

Mermaid公式ドキュメントのArchitecture Diagramsによれば、クラウド・CI/CD系の構成を描く architecture-beta 記法は v11.1.0 以降で使えます。group でVPCなどの囲みを、service で個々の要素を宣言し、辺は方向指定つきで結びます。既定のアイコンは cloud・database・disk・internet・server の5種類。追加のアイコンパックを登録すれば任意の記号も差せます。

architecture-beta
    group vpc(cloud)[Production VPC]

    service alb(internet)[ALB] in vpc
    service web1(server)[Web Server 1] in vpc
    service web2(server)[Web Server 2] in vpc
    service db(database)[RDS Primary] in vpc
    service store(disk)[Object Storage] in vpc

    alb:R --> L:web1
    alb:R --> L:web2
    web1:B --> T:db
    web2:B --> T:db
    web1:R --> L:store

確認は公式のLive Editorに貼れば即座に描画されます。エディタ上で表示されない場合の切り分けはMermaid記法の使い方にまとめました。GitHubのMarkdownでも mermaid 指定のコードブロックとして書けば、リポジトリ上でそのまま図として表示されます。

flowchartで外部連携とデータの流れを線種で描き分ける記述例

外部サービスとの連携や、データの流れと制御の流れの描き分けを表したいときは、Mermaid公式のFlowchart構文のほうが自由度があります。実線（-->）を業務データの流れ、点線（-.->）を外部APIの呼び出しに割り当てると、前述の「線種で区別する」というコツをそのまま記述に落とせます。

flowchart LR
    user([利用者ブラウザ]) --> alb[ロードバランサー]
    alb --> app1[APサーバー 1]
    alb --> app2[APサーバー 2]
    app1 --> db[(業務DB)]
    app2 --> db
    app1 -.-> pay[外部決済API]
    app2 -.-> batch[夜間バッチ基盤]
    db --> bi[BI・分析基盤]

この記述をSVGやPNGとして書き出したいときは、コマンドラインから変換できます。Node.jsの環境で npm install -g @mermaid-js/mermaid-cli を入れ、mmdc -i system.mmd -o system.svg と打つのが最短の手順です。CIに載せておけば、リポジトリのmmdファイルが更新されるたびに図が再生成され、資料側の図だけ古いという事故を避けられます。時系列の処理順を描き分けたい場合はシーケンス図の書き方と役割を分けると、構成図が肥大化せずに済みます。

PlantUMLのコンポーネント図で物理配置まで落とす記述と出力手順

オンプレのデータセンターとクラウドをまたぐ物理配置まで描くなら、node や cloud といった配置要素を持つPlantUMLが向きます。PlantUML公式のコンポーネント図リファレンスに記法の一覧があります。

@startuml
node "自社データセンター" {
  [基幹システム] as core
  [ファイルサーバー] as fs
}
cloud "クラウド ap-northeast-1" {
  [ロードバランサー] as alb
  [アプリコンテナ] as app
  database "マネージドDB" as db
}
core --> alb : 専用線経由
alb --> app
app --> db
fs ..> app : 日次連携
@enduml

出力はJava実行環境と plantuml.jar があれば手元で完結し、VS Codeの拡張機能を入れればエディタ内でプレビューできます。導入から拡張子の扱いまではPlantUMLの記法・使い方で解説しています。テキストで書いた構成図は、ソースコードと同じブランチ運用に乗せられるため、「改修したのに図が古い」という状態を仕組みで防げるのが最大の利点です。

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

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

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

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

もう1つ見落とせない観点がデータの保管先です。個人情報や機密データがどのサーバー・どの地域（国内か海外か）に保管されるかは、構成図と論理構成図を突き合わせれば読み取れます。ここが曖昧な図は、セキュリティや法令対応の設計が詰まっていない兆候だと考えてよいでしょう。構成図と併せて提示される文書の粒度に不安があるなら、仕様書と設計書の違いを押さえたうえで、どの文書にどこまで書くのかを事前に取り決めておくと揉めにくくなります。

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

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

見抜き方は単純です。契約前に「構成図は成果物に含まれますか」「改修時に更新されますか」と尋ねること。ここで言葉を濁す、あるいは追加費用を強く求める会社は、設計の文書化を軽視している可能性があります。構成図を標準の成果物として扱う会社を選ぶだけで、保守フェーズのリスクは大きく下がります。前節で触れたテキスト記法を採用している会社なら、リポジトリの履歴を見せてもらうだけで更新の実態が読み取れるでしょう。

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

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

結局のところ、良い構成図は良い設計の副産物です。要件定義から設計、実装、保守までを一貫して任せられる開発会社なら、構成図は自然と成果物として出てきます。一創ではインフラ構築（AWS・Google Cloud・Azure）のご支援で、要件のヒアリング段階から物理・論理の構成図を提示し、改修のたびに更新した図をお渡しする形にしました。既存システムの構成図が手元にない、あるいは古いまま止まっているという状態からのご相談も承ります。工程ごとの成果物と体制を見極めたうえで委託先を選ぶ考え方はシステム開発の工程で整理しているので、外注先の比較検討の軸として使ってください。

よくある質問

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

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

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

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

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

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

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

システム構成図の例やテンプレートはどこで探せばよいですか？

作図ツールが備えるテンプレート集（「Webシステム構成」「AWS構成」など）が最も手早い出発点になります。加えて、AWS・Azure・Google Cloudの各社が公式のアーキテクチャアイコンを配布しているので、素材を揃えてから自社の構成に差し替えると見た目が整うはずです。本記事のMermaid・PlantUMLの記述例も、要素名を自社のサーバー名に置き換えればそのまま雛形として使えます。

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

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

構成図をコードで書くとGUIツールと比べて何が変わりますか？

差が出るのは更新の続き方です。テキストで書いた図はソースコードと同じリポジトリに置けるため、構成変更がプルリクエストの差分として現れ、レビューを経ないと取り込まれません。GUIツールは初回の作図が速い代わりに、更新がレビュー経路の外に出やすくなります。提案時や社外提出物はGUIツール、開発中の内部資料はテキスト記法、と使い分ける現場が多い印象です。