システム構成図とアーキテクチャ図の違い｜使い分け4つの基準

システム構成図は「どの機器やサービスがどこに置かれ、どうつながるか」を示す図で、アーキテクチャ図は「どんな役割の部品が、どんな方針で組み合わさっているか」を示す図です。この2つは目的と読み手、抽象度と粒度、描く対象の範囲、更新される頻度の4つの基準で見分けられます。

現場では両者が同じ意味で使われることもあり、定義は会社やプロジェクトで揺れます。そのため本記事では、資料を作る場面で迷わないよう、4つの基準と具体例で使い分けを整理します。提案書では何を描き、設計書では何を描くのか。描く順番や、混同で起きやすい誤解の直し方まで順に説明します。2026年10月時点の公開情報をもとにまとめており、個別のプロジェクトでは顧客やチームの用語定義を優先して判断してください。

システム構成図とアーキテクチャ図は何が違うか

違いを一言で言えば、システム構成図は「実際の配置と接続」、アーキテクチャ図は「構造と設計の考え方」を表します。

どちらもシステムの全体像を描く図ですが、答えている問いが異なります。構成図は「何が、どこで、どうつながって動くのか」に答え、アーキテクチャ図は「なぜその部品の分け方で、どんな役割を持たせたのか」に答えます。

システム構成図が示すもの

システム構成図とは、サーバー、ネットワーク機器、データベース、外部サービスなどの構成要素と、その接続関係を示した図です。

代表的な記載項目は、機器やサービスの名称、台数、ネットワークの区切り、通信の向き、利用するプロトコルやポート番号などです。クラウドであればリージョンやサブネット、仮想マシンやマネージドサービスの名前まで描くことがあります。UMLでいう配置図（Deployment Diagram）は、この構成図に近い表記の1つです。

つまり構成図は、構築担当者が環境を用意したり、運用担当者が障害時に切り分けたりするときに、そのまま作業の地図として使える図です。

アーキテクチャ図が示すもの

アーキテクチャ図とは、システムを構成する主要な部品の役割と、部品どうしの関係や設計の方針を抽象化して示した図です。

たとえば「画面を担当する層」「業務ルールを担当する層」「データを保管する層」のように、機能や責任の単位でブロックに分け、層の積み重ねや依存の向きを描きます。サーバーの台数やIPアドレスのような細部は描かず、構造の骨格だけを見せます。

ソフトウェア構造を段階的に描く表記としては、C4モデルが知られています。C4モデルは、ソフトウェアシステム、コンテナ、コンポーネント、コードという階層的な抽象度で図を描き分ける考え方です（C4モデル公式サイト、2026年10月12日参照）。アーキテクチャ図を描くときに、どの抽象度で止めるかを決める参考になります。

違いを見分ける4つの基準

2つの図を見分ける基準は、目的と読み手、抽象度と粒度、描く対象の範囲、更新される頻度の4つです。次の表に並べて整理します。

基準	システム構成図	アーキテクチャ図
目的と読み手	構築・運用の作業の根拠にする。読み手は開発者、インフラ担当、運用担当	設計の方針を伝え合意を取る。読み手は顧客の意思決定者、プロジェクトの関係者
抽象度と粒度	具体的。機器名、台数、接続、ポートまで描く	抽象的。役割、層、依存の向きを描く
描く対象の範囲	実際に動く環境（本番、開発など）ごとに描く	システム全体の構造。環境の違いは描き分けない
更新される頻度	機器やサービスの変更のたびに更新される	設計方針を変える大きな変更のときだけ更新される

目的と読み手

最初に見るべき基準は、その図を誰が何のために使うかです。

構成図の読み手は、手を動かして環境を作る人や、障害時に原因を探す人です。そのため「そのまま作業できる正確さ」が求められます。アーキテクチャ図の読み手は、設計の方向性を判断する顧客の担当者やプロジェクトの責任者です。細部よりも「この分け方で目的を満たせるか」を確認できることが大切です。

抽象度と粒度

抽象度は、1つのブロックにどこまで具体的な情報を載せるかで決まります。

構成図では、ブロックの名前は「Webサーバー（2台）」「データベース（主系と待機系）」のように具体的です。アーキテクチャ図では、同じ場所が「画面を担当する層」「データを保管する層」と、役割の名前になります。同じ部品でも、見せる解像度が異なるだけです。

描く対象の範囲

範囲は、図が表す対象が「ある環境」か「システム全体の構造」かで分かれます。

構成図は、本番環境と開発環境でサーバーの台数や接続先が変わるため、環境ごとに描き分けることが多くなります。アーキテクチャ図は環境が違っても共通する構造を描くので、通常は1枚で足ります。クラウドの公式ドキュメントでも、構成の良し悪しは機器の並びだけでなく、信頼性やコストなどの観点で意思決定を見直す対象として扱われています（AWS Well-Architected Framework、2026年10月12日参照）。構造の考え方を描く図の役割は、この点と重なります。

更新される頻度

更新頻度は、図が古くなる速さの違いで、運用の負担にも直結します。

構成図は、サーバーを増やす、接続先を変える、サービスを入れ替えるといった日常の変更のたびに内容が変わります。アーキテクチャ図は、層の分け方や使う方式を見直すような大きな変更がなければ変わりません。更新頻度が高い図ほど、実態とのずれが起きやすくなります。構成図は更新の担当者と更新するタイミングをあらかじめ決めておくと安心です。

使い分けの具体例

使い分けの目安は、提案段階ではアーキテクチャ図、設計・開発段階ではシステム構成図を主役にすることです。

ここでは、架空の「社内向け受注管理システム」を例に、同じシステムを2つの図でどう描き分けるかを示します。

提案段階ではアーキテクチャ図、設計・開発段階ではシステム構成図を使うという使い分けを示した2段の図解

提案段階で使う図

提案段階では、全体の骨格と設計の考え方が伝わるアーキテクチャ図を使います。

読み手は顧客の経営層や担当部門で、サーバーの台数よりも「どんな構造で目的を満たすか」に関心があります。受注管理システムの例では、次のように役割の単位で描きます。

層（役割）	担う内容	描く要素の例
画面の層	営業担当が受注を入力し、一覧を見る	受注入力画面、受注一覧画面
業務ルールの層	受注の承認や在庫の引き当てを判断する	承認ルール、在庫引当ロジック
データの層	受注と在庫の情報を保管する	受注データ、在庫データ
外部連携	会計システムへ売上を渡す	会計システム連携

この図では、サーバーの種類や台数、ネットワークの区切りは描きません。顧客が確認したいのは、機能をこの分け方にした理由と、将来の変更に耐えられるかどうかだからです。

設計・開発段階で使う図

設計・開発段階では、実際の配置と接続を示すシステム構成図を使います。

同じ受注管理システムを、構築担当者が環境を用意できる粒度で描くと、次のようになります。数値は説明用の架空の値です。

構成要素	配置と台数（架空）	接続の例
Webサーバー	社内ネットワーク内に2台	利用者のブラウザからHTTPSで接続
アプリケーションサーバー	2台（Webサーバーと同じ区切り）	Webサーバーから内部通信で接続
データベース	主系1台と待機系1台	アプリケーションサーバーからのみ接続を許可
会計システム連携	外部サービスに夜間バッチで接続	専用の通信経路で売上データを送信

このように、構成図は台数、接続元と接続先、通信の向きまで書き込みます。機器の名称や台数が空欄の構成図は、構築や運用の作業の根拠にならないため、設計段階で穴を残さないようにします。個別のネットワーク設計やセキュリティ要件は案件ごとに異なるので、実際の判断はプロジェクトの責任者や専門家と確認してください。

描く順番と両者をつなぐコツ

描く順番は、アーキテクチャ図で骨格を決めてから、システム構成図へ細部を展開する流れが基本です。

先に構成図から描き始めると、機器の配置にこだわるうちに「そもそもなぜこの構造なのか」が説明できなくなりがちです。次の4段階で進めると、両方の図が食い違いにくくなります。

目的と読み手を決める。入力は依頼内容と資料の使い道、出力は「誰に何を伝える図か」の一文です。例として「顧客の部門長に、受注管理を3つの層で作る方針を伝える」と書きます。
アーキテクチャ図で骨格を描く。入力は要件の一覧、出力は役割ごとのブロックと依存の向きです。ブロックは5〜7個程度に収めると読みやすくなります。
骨格の各ブロックを構成図へ展開する。入力は骨格のブロック、出力は機器名、台数、接続を書き込んだ図です。「画面の層」は「Webサーバー2台」のように置き換えます。
名前と番号で両図を対応づける。出力は、両方の図に同じ名前や番号が付いた状態です。アーキテクチャ図の「データの層」と、構成図の「データベース（主系・待機系）」を、同じ番号で結びます。

目的を決めてアーキテクチャ図で骨格を描き、構成図へ展開して両図を対応づける4段階の流れ

両者をつなぐコツは、ブロックの名前を図ごとに言い換えないことです。名前がそろっていれば、読み手は「この骨格が、この機器配置になっている」と追えます。構成図の描き方の手順はシステム構成図の書き方｜目的別の描き分けと記載のポイントで、種類と基本はシステム構成図とは？種類・書き方・ITコンサルが実務で使うベストプラクティス【最新版】で整理しています。

混同して起きる誤解と直し方

混同でいちばん多い失敗は、1枚の図に抽象度の違う情報を混ぜてしまい、誰にも使いにくい図になることです。

よくある誤解と直し方を、症状別に整理します。

よくある誤解	起きる問題	直し方
提案書の1枚目にサーバー台数まで書き込んだ構成図を載せる	顧客が設計の方針を読み取れず、細部の質問に会議の時間が使われる	提案書にはアーキテクチャ図を載せ、構成図は別紙にする
設計書にブロックだけのアーキテクチャ図しか載せない	構築担当者が機器の数や接続を読み取れず、確認の往復が増える	構成図を追加し、両図を名前と番号で対応づける
2つの図で同じ部品の名前が違う	読み手が別の部品と受け取り、認識の食い違いが起きる	用語をそろえ、用語の一覧を設計書の冒頭に置く
構成図を更新せず放置する	実際の環境と図が食い違い、障害対応の判断を誤る	変更の手順に「図の更新」を入れ、担当者を決める

もう1つの注意点は、用語の定義がプロジェクトごとに違うことです。顧客が「アーキテクチャ図」と呼んでいる資料が、実際には機器の配置を描いた構成図であることもあります。資料の名前ではなく、中に何が描かれているかで判断し、最初の打ち合わせで「この図は何を伝えるものか」を確認しておくと食い違いを防げます。

まとめ｜資料ごとに図を選ぶ判断基準

資料ごとに図を選ぶ判断基準は、「読み手が何を判断するのか」を先に決めることです。

方針に合意してほしい場面ではアーキテクチャ図、作業の根拠にしてほしい場面ではシステム構成図を選びます。迷ったときは、次の3点を確認してください。

読み手は意思決定者か、作業を担当する人か
伝えたいのは構造の考え方か、実際の配置と接続か
その図は、機器の変更のたびに更新される前提か

両方の図が必要な場面では、アーキテクチャ図で骨格を決め、構成図へ展開し、名前と番号で結ぶ順番を守ります。構成図とアーキテクチャ図を描き分けられると、提案から設計までの資料の説得力が上がり、ITコンサルタントとして任される範囲を広げる土台にもなります。

こうした設計資料の経験を活かして独立や案件探しを考える場合、大手企業の案件では、与信や購買規定の都合から、個人と直接契約せず法人を挟むケースが多いとされています。そのため案件の探し方はエージェント経由が基本になりやすく、ITコンサルタント・SIer系フリーランスエージェント比較5選【2026年版】やフリーランスコンサルタント向けエージェント完全比較【2026年版・全職種対応】が参考になります。独立の準備の順番はITコンサルタントが独立するには｜準備の順番と初年度の収支の組み立て方で整理しています。契約や条件は案件ごとに異なるため、最終的な判断は各社の情報や専門家への確認をおすすめします。

出典・参考情報

Object Management Group「About the Unified Modeling Language Specification Version 2.5.1」（2026-10-12参照）：UMLの図の種類（配置図を含む）
C4 model 公式サイト（c4model.com、2026-10-12参照）：ソフトウェアシステム、コンテナ、コンポーネント、コードの階層的な抽象度
Amazon Web Services「AWS Well-Architected Framework」（2026-10-12参照）：アーキテクチャの意思決定を見直す枠組み

最終更新日：2026年10月12日。本記事の内容は2026年10月時点の公開情報に基づきます。用語の定義や表記は組織やプロジェクトで異なるため、実務では顧客やチームの定義に合わせてご確認ください。