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

アーキテクチャ図は、システムを構成する要素とそのつながりを、特定の読み手の問いに答える粒度で描いた図です。現場では「アーキ図」と略されることもあります。異なる読み手向けの詳細を1枚に詰め込むと、必要な要素や関係を追いにくくなります。この記事では、システム構成図やER図・シーケンス図との違いと唯一の正解が無い理由を整理したうえで、C4モデルの4階層、読み手を決めてから描く書き方の手順、AWS公式アイコンの規約、Structurizr DSLとMermaidでコードとして管理する方法、ツールの選び方、見積もりや審査の場面ごとにそろえる図の組み合わせを順に説明します。

まとめ：アーキテクチャ図の定義と書き方、場面別にそろえる図の要点

• アーキテクチャ図は、読み手（経営層・開発者・運用・セキュリティ審査）の問いに合わせて抽象度を選んで描く。1枚で全部を表そうとしない。
• 規格は記法を定めていないため、唯一の正解は無い。正しさは「読み手の問いに答えられるか」と「凡例どおりに読めるか」で判定する。
• 抽象度の段階はC4モデル（システムコンテキスト→コンテナー→コンポーネント→コード）が標準的な物差しになる。
• 書き方の基本は、単方向の矢印に必ずラベルを付ける、凡例を置く、タイトル・更新日・版を入れる、の3点。
• AWS構成図は公式アイコン（2026年7月31日公開のRelease 24）を使い、アイコンの切り抜き・反転・回転・サイズ変更をしない。
• 図を継続的に更新するなら、Structurizr DSLやMermaidでコード化し、ソースコードと同じリポジトリで版管理する。
• 見積もり依頼ならシステムコンテキスト図、AWS構築の発注ならデプロイ図、というように提出先で最低限の組み合わせが決まる。

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

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

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

アーキテクチャ図に唯一の正解が無い理由と、規格が記法を決めない背景

「正しいアーキテクチャ図の描き方」を探しても1つに定まらないのは、規格と主要な枠組みがそろって記法を決めていないためです。ISO/IEC/IEEE 42010 が定めるのは、関心事・ビュー・ビューポイントといった記述の構造であり、箱の形や矢印の種類ではありません。C4モデルも「記法に依存しない」と明言し、抽象度の段階だけを決めています。UMLは記法を厳密に定めていますが、アーキテクチャ図にUMLを使う義務はありません。

もう1つの理由は、同じシステムでも読み手が変われば答えるべき問いが変わることです。経営層は「何と連携し、どこにお金がかかるか」を知りたく、運用担当は「どこが止まると何が止まるか」を知りたい。この2つの問いに1枚で答えようとすると、どちらにとっても読みにくい図になります。したがって判定の基準は記法の正誤ではなく、次の3点に置きます。

• 図のタイトルに書いた問いに、図だけで答えられるか。
• 凡例に書いた意味どおりに、すべての形・色・線種が読めるか。
• チーム内の他の図と、同じ要素に同じ名前と同じ形を使っているか。

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

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

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

アーキテクチャ図の種類：読み手の関心に合わせた抽象度と視点による使い分け

C4モデルの4階層と3種類の補助図における描画対象と読み手の違い

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

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

呼び名で分かれるアーキテクチャ図の種類とC4モデルの階層との対応

「システムアーキテクチャ図」「アプリケーションアーキテクチャ図」のような呼び名は、厳密な定義を持つ用語ではありません。AWSの解説ページ「アーキテクチャダイアグラム作成とは」は、ソフトウェア・システム・アプリケーション・統合・デプロイ・DevOps・ウェブサイトの7種類を挙げています。実務での使われ方を、C4モデルの図に当てはめると次のようになります。

DevOpsとデータのアーキテクチャ図に当たる専用の図はC4にありません。C4でも関係線でデータの流れを、ダイナミック図で実行時の相互作用を表せますが、CI/CDの実行手順やデータの変換・来歴まで示す場合は、パイプライン図やデータフロー図を補います。

受け取った図がどの範囲を描いているかわからないときは、呼び名ではなくC4のどの階層にあたるかで確認すると話がかみ合います。三層構成やマイクロサービスといった構造の型そのものはシステムアーキテクチャの代表5方式と選び方で整理しているので、図に描く前に方式を決めたい場合は先に参照してください。

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の解説で扱っています。

ER図・シーケンス図・ユースケース図などの設計図とアーキテクチャ図の違い

システム開発では、アーキテクチャ図のほかにも多くの図が使われます。それぞれ答える問いが違うため、1枚に混ぜずに役割を分けます。

アーキテクチャ図が描くのは「何がどこにあり、何に依存するか」という構造です。処理の順序はシーケンス図に、データの持ち方はER図に任せると、アーキテクチャ図が細部で埋まりません。C4ではコンテキスト図を最上位の静的構造図として扱います。シーケンス図やER図も、設計上の関心事に応じてアーキテクチャの説明に組み合わせます。各図の書き方はユースケース図の書き方、ER図の書き方とカーディナリティ、シーケンス図の書き方とMermaid実装で解説しています。

アーキテクチャ図の書き方：読み手の決定から版管理までの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 はさらに、説明・最終更新日・作成者・版・参照先を入れ、読み手が図の鮮度を判断できるようにするよう求めています。質問に正確に答えられなくなった図は廃止する、というのも指針の1つです。古い図を残しておくと、現状と違う構成を前提にした議論が始まるためです。

AWS構成図の描き方：公式アイコンの表記とグループの配置に関する規約

AWS公式アイコンの入手先と更新の周期・配布形式による使い分け

AWSのアーキテクチャアイコンは、AWS Architecture Center の「AWS Architecture Icons」ページで、PowerPoint用のツールキットとアイコンパッケージ（SVG・PNG）の2形式で配布されています。2026年10月時点の最新は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構成図のアイコン・ラベル・矢印の禁止事項と表記を統一する規約

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

矢印は「Open Arrow」のサイズ4が既定です。処理の順序を示したい場合は、黒地に白の太字で書かれた番号付きの吹き出しを使います。構成そのものの良し悪しは、AWSが公開する設計原則のAWS Well-Architected Frameworkの6つの柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性）に沿ってレビューします。図はこのレビューの入力資料にもなるため、柱ごとの確認項目に答えられる粒度で描いておくと手戻りが減ります。

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

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

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

EC注文システムを2枚のC4図として定義するDSLと検証コマンド

次の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
            }
        }
    }
}

2026年10月18日時点の最新リリースである Structurizr 2026.09.19 の war ファイルと Java 25 で、次のコマンドの動作を確認しました（公式のバイナリ配布ページが示す要件は Java 21）。DSLをworkspace.dsl、公式配布のwarをstructurizr.warとして同じディレクトリに保存し、その場所で実行します。存在しない要素へ線を引くと、validate は「The destination element "apix" does not exist at line 17」のように行番号付きのエラーを出して終了コード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つで、中身は Mermaid のフローチャート（graph LR）形式です。GitHubのMarkdownでは、各ファイルの内容を言語名mermaidのフェンス付きコードブロックに貼り付けます。図の配置を手で調整しながら見たい場合は local コマンドを使います。

同じDSLから書き出した2枚を並べると、描く範囲の違いがわかります。システムコンテキスト図は購入者・EC注文システム・決済代行サービスの3つだけで、外部との関係を示します。

コンテナー図は同じシステムの枠を開き、Webアプリ・注文API・注文DBの分割と、それぞれの技術（Next.js・Spring Boot・PostgreSQL）を示します。

生成AIにDSLを書かせる場合は、公式のStructurizr MCPサーバー（無料・オープンソース）が、DSLの検証や Mermaid・PlantUML への書き出しをツールとして提供しています。

Mermaidのarchitecture-betaでAWS構成をテキストで描く書き方

C4の厳密さが要らず、クラウドの構成を手早くテキストにしたいだけなら、Mermaid の architecture-beta が手軽です。Mermaid の Architecture Diagrams によると対応はv11.1.0以降で、名前のとおりベータ扱いの記法です。要素は group（枠）・service（ノード）・辺が基本で、辺は「サービスID:接続する辺の向き（T・B・L・R）」同士を -- でつなぎ、矢印を付ける場合は --> と書きます。

次は、ALB・ECS on Fargate・Aurora PostgreSQLをVPCに、S3をVPCの外に置いた構成の例です。標準で使えるアイコンは cloud・database・disk・internet・server の5種類なので、AWS公式アイコンの代わりにこれらで種別を表しています。

architecture-beta
    group aws(cloud)[AWS Cloud]
    group vpc(cloud)[VPC] in aws

    service user(internet)[User]
    service alb(server)[ALB] in vpc
    service app(server)[ECS on Fargate] in vpc
    service db(database)[Aurora PostgreSQL] in vpc
    service s3(disk)[S3] in aws

    user:R -[HTTPS]-> L:alb
    alb:R -[HTTP]-> L:app
    app:R -[SQL]-> L:db
    app:B -[HTTPS]-> T:s3

線の上の「HTTPS」「SQL」は、-[ラベル]-> の形で書いた辺のラベルです。2026年10月時点の公式ドキュメントの構文説明にはこの書き方が載っていませんが、パーサーの文法定義（architecture.langium）は受け付けており、mermaid 12.2.0 と mermaid-cli 12.0.0 で線の上に描画されることを確認しました。縦の線のラベルは90度回転して描かれます。ドキュメントに無い構文なので、版を上げたら描画を確かめ直してください。

CIで図の構文を検査する場合は注意が必要です。mermaid-cli（mmdc）は構文エラーがあっても終了コード0を返し、「Syntax error in text」と書かれた画像を出力しました。判定には終了コードの確認に加え、今回の実行でSVGが生成されたことと、そのSVGに「Syntax error in text」が含まれないことを確認します。

AWSのサービスを区別して描きたい場合は、iconify のアイコンパックを登録すると logos:aws-lambda のような名前でアイコンを指定できます。Web三層構成の作例はシステム構成図の解説に、記法全般はMermaid記法の使い方ガイドにあります。UML寄りの記法を使いたい場合はPlantUMLの記法と使い方が選択肢です。

アーキテクチャ図作成ツールの比較と更新頻度・共同編集の相手による選び方

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

draw.io は無料で、Web版のライセンスはApache-2.0、デスクトップ版はGPL-3.0です。Structurizr の基本コマンドは無料でライセンスはApache-2.0ですが、配布済みserverは有料です。

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

提出先と工程で決めるアーキテクチャ図の組み合わせと省いてよい図

アーキテクチャ図を何枚そろえるかは、図を渡す相手と工程で決まります。描ける図をすべて描くのではなく、その場面の問いに答える最小の組み合わせから始めてください。

RFPや見積もり依頼の段階では、内部構造よりも「どの外部システムと何をやり取りするか」が見積もり額を左右します。コンテキスト図に連携先と方式（API・ファイル連携・手作業）を書き込むのは、ベンダー間で前提をそろえるためです。基本設計書のどこにアーキテクチャ図を置くかは基本設計の成果物と位置づけで、設計書や要件定義書との役割分担は仕様書と設計書・要件定義書の違いで整理しています。

図を足すかどうかは、更新の漏れが起きているかで判断します。同じ構成要素を複数の図に反映する更新で漏れが生じるなら、Structurizr などでモデルを共通化し、コードとして版管理する方法が有効です。逆に、構成がほぼ固定で、開発チームが確認する構造と依存関係を1枚で説明できるなら、draw.io の図とADRから始められます。AWSの構成をこれから決める段階で、デプロイ図の作成と設計レビューから構築までをまとめて任せたい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）で、構成図を含む設計資料の作成から対応しています。

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

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

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

図を更新する仕組みが無いチームで、図の数を増やすのは逆効果です。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回で、2026年10月時点の最新はRelease 24です。

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

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

関連記事

• システム構成図とは？書き方の手順と例・アーキテクチャ図との違いを図解
• システムアーキテクチャとは？意味と代表5方式の違い・選び方をわかりやすく解説
• UMLとは：仕様2.5.1の14種類の図と実務で使う4種類・PlantUMLとMermaidの書き方
• ADR（Architecture Decision Record）とは｜書き方・Markdownテンプレート・design docとの違い
• PlantUMLとは？使い方・記法・インストールと.puml拡張子【v1.2026.9】