アーキテクチャ図とは？書き方の手順とC4モデル・AWSアイコンの規約、作成ツールの選び方

アーキテクチャ図は、システムを構成する要素とそのつながりを、特定の読み手の問いに答える粒度で描いた図です。異なる読み手向けの詳細を1枚に詰め込むと、必要な要素や関係を追いにくくなります。この記事では、システム構成図との違いを整理したうえで、C4モデルの4階層、読み手を決めてから描く書き方の手順、AWS公式アイコンの規約、Structurizr DSLでコードとして管理する方法、ツールの選び方を順に説明します。

まとめ｜アーキテクチャ図の定義と書き方の要点

• アーキテクチャ図は、読み手（経営層・開発者・運用・セキュリティ審査）の問いに合わせて抽象度を選んで描く。1枚で全部を表そうとしない。
• 抽象度の段階はC4モデル（システムコンテキスト→コンテナー→コンポーネント→コード）が標準的な物差しになる。
• 書き方の基本は、単方向の矢印に必ずラベルを付ける、凡例を置く、タイトル・更新日・版を入れる、の3点。
• AWS構成図は公式アイコン（2026年7月31日公開のRelease 24）を使い、アイコンの切り抜き・反転・回転・サイズ変更をしない。
• 図を継続的に更新するなら、Structurizr DSLやMermaidでコード化し、ソースコードと同じリポジトリで版管理する。

アーキテクチャ図とは：構造と設計判断を読み手の問いに合わせて描く図

アーキテクチャ記述の国際規格 ISO/IEC/IEEE 42010:2022 は、アーキテクチャを1つの図ではなく、利害関係者の関心事（concern）ごとの「ビュー（view）」の集まりとして記述する考え方を採っています。ビューの描き方の約束事を定めたものが「ビューポイント（viewpoint）」です。つまりアーキテクチャ図は、誰のどの関心事に答えるかを決めて初めて描ける図だといえます。

Microsoft の Azure Well-Architected Framework の解説「アーキテクチャ設計図を作成する」も同じ立場で、メッセージ・対象ユーザー・ライフサイクルの段階に合った図の種類を選び、重ねて使うよう求めています。構想、設計、脅威モデリング、実装、運用の各段階で複数の図を維持するのが前提です。

システム構成図・概要図・ネットワーク構成図との違い

これらの呼び名の範囲は組織によって異なります。ここでは、答える問いと抽象度を比較するため、次のように整理します。

システム概要図はC4モデルでいうシステムコンテキスト図に近く、システム構成図はデプロイ図に近い位置づけです。アーキテクチャ図はこれらを含む上位の呼び名として使われ、抽象度を切り替えた複数枚のセットを指すことが多くなります。システム構成図そのものの種類や書き方はシステム構成図の種類と書き方の解説で詳しく扱っています。

アーキテクチャ図の種類：抽象度と視点による使い分け

C4モデルの4階層と3種類の補助図

C4モデルは Simon Brown 氏が提唱した、ソフトウェアアーキテクチャを地図のように拡大・縮小して描くための枠組みです。記法は定めず、描く対象の抽象度だけを定めています。

補助図として、組織内の複数システムを並べるシステムランドスケープ図、特定の処理の流れを番号付きで示すダイナミック図、コンテナーをどのインフラに配置するかを示すデプロイ図があります。クラウドの構成図は、このデプロイ図にあたります。C4の「コンテナー」はDockerコンテナーを意味せず、アプリケーションまたはデータストアを指します。データベースのスキーマやファイルシステムも対象です。

4+1ビューモデルとAzure Well-Architectedの図の分類

C4以前から使われている整理に、Philippe Kruchten 氏が1995年に IEEE Software 誌で発表した4+1ビューモデルがあります。論理ビュー・プロセスビュー・開発ビュー・物理ビューの4つを描き分け、シナリオ（ユースケース）で4つのビューの整合を確かめる構成です。各ビューをUMLの図で描くことが多く、UMLの図の種類はUMLの14種類の図と実務で使う図の解説を参照してください。

Azure Well-Architected Framework はクラウドのワークロード向けに、コンテキスト図、システム（コンテナー）の概要図、ブロック図（機能図）、コンポーネント図、デプロイ図、データフロー図、シーケンス図、ネットワーク図、状態図などを挙げています。ブロック図は Azure Service Bus や Apache Kafka といった製品名の代わりに「注文キュー」のような機能名で描く図で、要件を固める段階の議論に向きます。データフロー図は脅威モデリングの入力にもなり、STRIDEでの使い方は脅威モデリングとSTRIDEの解説で扱っています。

アーキテクチャ図の書き方：読み手の決定から版管理までの6ステップ

ツールを開く前に、誰に何を伝える図かを決めるのが最初の手順です。C4モデルの考え方と Azure Well-Architected の推奨事項をまとめると、次の順で描くと手戻りが少なくなります。

1. 読み手と問いを決める：「外部サービスが止まったら何が影響を受けるか」のように、図が答える問いを1文で書く。
2. 抽象度とスコープを決める：C4のどの階層で描くかを決め、図の範囲（境界）を明示する。1枚の中で階層を混ぜない。
3. 要素を並べる：各要素に名前・種別・使用技術・1行の説明を付ける。
4. 関係線を引く：単方向の矢印に、動詞を含むラベルと通信方式（HTTPS、JDBCなど）を書く。
5. グループと凡例を加える：リージョン・VPC・チームなどの境界で囲み、色や線種の意味を凡例に書く。
6. メタデータを入れて保存する：タイトル・更新日・版・作成者を書き、図のソースをリポジトリで管理する。

矢印と線の決め方：単方向・ラベル・線種の意味

関係線の方向やラベルが曖昧だと、依存関係とデータの流れが混同されます。C4モデルの表記ガイドは、すべての線を単方向の関係として描き、方向と意図（依存関係なのかデータの流れなのか）に合うラベルを付けるよう求めています。「使う」のような1語のラベルは避け、コンテナー間の線には通信方式を明記します。

Azure Well-Architected も双方向矢印を使わないよう明記しています。双方向の通信がある場合は2本の矢印に分けるのが第一の選択肢で、1本で済ませるなら要求と応答の注記を付けます。実線を同期呼び出し、破線を非同期にするといった使い分けをする場合は、必ず凡例に書いてください。色だけで種類を区別すると、白黒印刷や色覚の違いで情報が失われます。

図に入れるメタデータ：タイトル・スコープ・更新日・版

C4モデルは、すべての図に種類とスコープがわかるタイトル（例：「EC注文システムのコンテナー図」）と凡例を付けるよう勧めています。Azure Well-Architected はさらに、説明・最終更新日・作成者・版・参照先を入れ、読み手が図の鮮度を判断できるようにするよう求めています。質問に正確に答えられなくなった図は廃止する、という指針もあります。古い図を残しておくと、現状と違う構成を前提にした議論が始まるためです。

AWS構成図の描き方：公式アイコンとグループの規約

公式アイコンの入手先と更新の周期

AWSのアーキテクチャアイコンは、AWS Architecture Center の「AWS Architecture Icons」ページで、PowerPoint用のツールキットとアイコンパッケージ（SVG・PNG）の2形式で配布されています。2026年9月時点の最新は2026年7月31日公開の Release 24 です。公開は1月末・4月末・7月末の年3回で、10〜12月の四半期には公開されません。

パッケージは、サービスアイコン（16・32・48・64pxの4サイズ）、リソースアイコン、カテゴリーアイコン、グループアイコンの4フォルダーに分かれています。サービスアイコンはAmazon EC2のようなサービスそのもの、リソースアイコンはEC2のインスタンスやNATゲートウェイのようなサービス内のリソースを表します。draw.io などのツールに組み込まれたライブラリは古いアイコンが混ざっていることがあるため、AWSは最新版を使っているか確認するよう注意書きしています。

Azure も「Azure アーキテクチャ アイコン」を Microsoft Learn で配布しています。利用はアーキテクチャ図・研修資料・文書に限られ、切り抜き・反転・回転・変形や、自社の製品・サービスを表す用途は禁止されています。Google Cloud も公式の Icon library で製品カテゴリーと主要製品のアイコンをSVG・PNGで配布しています。

グループの入れ子：AWS Cloud・リージョン・AZ・VPC・サブネット

AWSのツールキットは、最初にグループで図の骨組みを作り、次にサービスやリソースのアイコンを置き、最後に矢印でつなぐ順序を示しています。用意されているグループは AWS Cloud、Region、Availability Zone、Security group、Auto Scaling group、Virtual private cloud (VPC)、Private subnet、Public subnet、AWS account、Corporate data center などです。

典型的な入れ子は「AWS Cloud ＞ Region ＞ VPC ＞ Availability Zone ＞ サブネット」です。グループの中にグループを入れる場合、内側のグループの四辺に0.05インチ以上の余白を取るよう定められています。Auto Scaling group のように複数のAZをまたぐグループは、AZの枠を横切って描きます。東京リージョンのAZ構成はap-northeast-1のAZ構成の解説で確認できます。

アイコン・ラベル・矢印の禁止事項

AWS Architecture Icons で配布されている Release 24 のPowerPointツールキット（Guidelinesの章）が定める主な規約は次のとおりです。

矢印は「Open Arrow」のサイズ4が既定です。処理の順序を示したい場合は、黒地に白の太字で書かれた番号付きの吹き出しを使います。

コードで描くアーキテクチャ図：Structurizr DSLによるC4モデルの管理

構成変更を図に反映しなければ、図と現状にずれが生じます。図をテキストで書いてソースコードと同じリポジトリに置けば、変更がプルリクエストで差分としてレビューされます。C4モデルの考案者が作った Structurizr は、1つのモデルから複数の図を生成する「models as code」のツールです。

Structurizr は「Structurizr vNext」として提供形態が変わりました。従来の Structurizr CLI と Structurizr Lite は更新が止まり、1つのプログラムの local・export・validate などのコマンドに統合されています。クラウドサービスは2026年9月30日で提供終了です（Structurizr のコマンド一覧）。古い手順書で structurizr-cli を入れている場合は移行が必要です。

次のDSLは、購入者・Webアプリ・注文API・注文DB・外部の決済代行サービスからなるEC注文システムを、システムコンテキスト図とコンテナー図の2枚として定義する例です。関係線にはラベルと通信方式を必ず書いています。

workspace "EC注文システム" "C4モデルのサンプル" {

    model {
        customer = person "購入者" "Webで商品を注文する"
        ec = softwareSystem "EC注文システム" {
            web = container "Webアプリ" "画面を返す" "Next.js"
            api = container "注文API" "注文を受け付ける" "Spring Boot"
            db = container "注文DB" "注文と在庫を保存する" "PostgreSQL" {
                tags "Database"
            }
        }
        payment = softwareSystem "決済代行サービス" "カード決済を処理する外部サービス" {
            tags "External"
        }

        customer -> web "商品を選んで注文する" "HTTPS"
        web -> api "注文を送る" "JSON/HTTPS"
        api -> db "注文を書き込む" "JDBC"
        api -> payment "与信を依頼する" "HTTPS"
    }

    views {
        systemContext ec "SystemContext" {
            include *
            autoLayout lr
        }
        container ec "Containers" {
            include *
            autoLayout lr
        }
        styles {
            element "Database" {
                shape cylinder
            }
            element "External" {
                background #999999
            }
        }
    }
}

Structurizr 2026.09.19 の war ファイルと Java 25 で動作確認済みです。DSLをworkspace.dsl、公式配布のwarをstructurizr.warとして同じディレクトリに保存し、その場所で次のコマンドを実行します。存在しない要素へ線を引くと、validate は行番号付きのエラーを出して終了コード1で止まるため、CIに組み込めます。

java -jar structurizr.war validate -w workspace.dsl
java -jar structurizr.war export -w workspace.dsl -f mermaid -o out

書き出したファイルは structurizr-SystemContext.mmd と structurizr-Containers.mmd の2つです。GitHubのMarkdownでは、各ファイルの内容を言語名mermaidのフェンス付きコードブロックに貼り付けます。図の配置を手で調整しながら見たい場合は local コマンドを使います。

C4の厳密さが要らず、クラウドの構成を手早くテキストにしたいだけなら、Mermaid の architecture-beta（v11.1.0以降）が手軽です。グループ・サービス・線の3要素で描け、Web三層構成の作例はシステム構成図の解説に、記法全般はMermaid記法の使い方ガイドにあります。UML寄りの記法を使いたい場合はPlantUMLの記法と使い方が選択肢です。

アーキテクチャ図作成ツールの比較と選び方

ツールは、図を誰がどれだけの頻度で更新するかで選びます。AWSのアイコンページが紹介する作図ツールには Cacoo、Cloudcraft、Draw.io、Figma などが並んでいます。

draw.io はデスクトップ版があり、2026年9月26日時点の最新は v31.5.3 です。VS Code では非公式拡張の Draw.io Integration（hediet.vscode-drawio）を入れると、.drawio.svg や .drawio.png を編集できます。これらは通常のSVG・PNGとしてそのまま表示できるので、書き出し作業なしでREADMEに貼れるのが利点です。GUIで描きながらリポジトリで版管理したいチームには、この組み合わせが向きます。手書き風のラフから始めたい場合はExcalidrawの使い方も参考になります。

アーキテクチャ図が役に立たなくなる失敗パターンとレビュー観点

C4モデルの解説は、場当たり的に描かれた図に共通する問題として、表記の意味が説明されていない、関係線にラベルが無い、「ビジネスロジック」のような曖昧な語が使われる、技術の選択が書かれていない、抽象度が混ざっている、などを挙げています。レビューでは、次の4つを優先して確認してください。

• 抽象度が混ざっていないか：システムコンテキスト図にDBのテーブル名が出ていたら、図を分ける。
• 矢印の意味が1通りに読めるか：依存関係とデータの流れが同じ線種で混在していないか、双方向矢印が無いかを見る。
• 簡略化が不正確になっていないか：Azure Well-Architected は、プライベートエンドポイント経由でアクセスするPaaSをサブネット内に描くような簡略化を誤りの例に挙げている。
• いつの構成かわかるか：更新日と版が無い図は、現状を表しているか判断できない。

図を更新する仕組みが無いチームで、図の数を増やすのは逆効果です。C4モデル自身も4階層すべてを描く必要はなく、多くの開発チームにはシステムコンテキスト図とコンテナー図で足りるとしています。まずはこの2枚に絞り、設計判断の理由は図に書き込まずにADR（アーキテクチャ決定記録）へ分けて残すと、図が軽いまま保てます。逆に、1回限りの説明資料のために Structurizr のような仕組みを入れる必要はありません。Azure Well-Architected も、今の図のやり方で伝わっているなら、形式のためだけに仕様を採用しないよう述べています。

よくある質問

アーキテクチャ図とは何ですか？

システムを構成する要素とそのつながりを、読み手の関心事に合わせた抽象度で描いた図です。読み手の問いに1枚で答えられる場合は1枚で足ります。複数の抽象度が必要な場合は、C4モデルのように図を描き分けます。

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

システム構成図は、どのサーバーやクラウドサービスで動くかという物理・論理の配置を示す図です。アーキテクチャ図はそれを含む上位の呼び名で、外部との関係を示すコンテキスト図から部品の内部構造まで、抽象度を切り替えて描きます。

アーキテクチャ図は何で書けばいいですか？

AWSのアイコンを使ってGUIで描くなら draw.io が無料で始めやすく、図をコードと一緒に版管理するなら Structurizr DSL や Mermaid が向きます。非エンジニアと共同で編集するならSaaSの作図ツールが便利です。

AWSのアーキテクチャアイコンはどこで入手できますか？

AWS Architecture Center の「AWS Architecture Icons」ページから、PowerPoint用ツールキットとSVG・PNGのアイコンパッケージを無料でダウンロードできます。更新は1月末・4月末・7月末の年3回です。

アーキテクチャ図は英語で何と言いますか？

architecture diagram です。ソフトウェアの構造に限る場合は software architecture diagram、クラウドの構成を指す場合は cloud architecture diagram と呼ぶこともあります。

関連記事

• システム構成図とは：種類と書き方・Mermaidでの作例、発注者が確認すべき観点
• システムアーキテクチャとは？種類と選び方をわかりやすく解説
• UMLとは：仕様2.5.1の14種類の図と実務で使う4種類・PlantUMLとMermaidの書き方
• ADR（アーキテクチャ決定記録）とは｜書き方・テンプレート・design docとの違い
• PlantUMLとは？記法・使い方・インストールから.puml拡張子まで解説