構成図が伝わらないのは、絵が下手だからではありません。描き始める前に決めておくことを決めていないからです。
この記事のために、同じ構成を2回描きました。1枚目は「思いついた順に置いて、関係を線で結んだ図」、2枚目は「先にルールを決めてから描いた図」です。何が違うのかを具体的に見ていきます。
まず、伝わらない図を見る
この図に間違いは一つもありません。サービス名は正しく、線で結ばれた関係も実際に存在します。それでも、この図を見せられた人は「で、リクエストはどこから来てどこへ行くのか」を答えられません。
問題は4つあります。
1. 読む順番が決まっていない
どこから見ればいいのか分かりません。ユーザーが左下にいて、入口であるRoute 53が右上にあります。視線は左上から右下へ動くのに、処理の流れがそれと一致していないので、目が図の上を往復することになります。
2. 粒度が混ざっている
「EC2」「RDS」はAWSのサービス名です。一方で「アプリ」「バッチ処理」はその上で動いているものの名前で、レイヤーが違います。同じ大きさの四角に入れて並べた瞬間、読み手は両者を同列のものとして扱おうとして混乱します。
これは実際の現場でいちばん多いパターンです。頭の中にあるものを片っ端から四角にすると、必ずこうなります。
3. 線が何を意味するのか分からない
13本の線が引かれていますが、それがHTTPリクエストなのか、DBへの接続なのか、非同期のメッセージなのか、単なる「関連がある」なのかが区別できません。線の意味が定義されていない図は、線の数だけ解釈の余地を生みます。
4. 境界が描かれていない
どこまでがVPCの中で、どれがインターネットに面していて、どのリソースがどのアベイラビリティゾーンにあるのかが分かりません。クラウドの構成図で本当に重要なのは、箱そのものより箱を囲む境界線です。セキュリティも可用性も、境界の引き方で決まります。
描く前に決める3つのこと
ツールを開く前に、この3つを言葉にします。ここが曖昧なまま描き始めると、必ず図1になります。
- 目的
提案・設計レビュー・運用引き継ぎ・障害対応のどれか - 読み手
意思決定者・開発者・運用者・顧客のどれに向けるか - 粒度
サービス単位か、サブネットやセキュリティグループまで描くか
この3つが決まると、「描かないもの」が決まります。営業資料ならサブネットは不要ですし、運用引き継ぎならAZとセキュリティグループまで描かないと現場が困ります。同じシステムでも、目的が違えば正解の図は違います。
図1の本当の問題は「全部描いてしまったこと」です。構成図は情報を足す作業ではなく、目的に対して要らないものを落とす作業です。
同じ構成を描き直す
構成要素はほぼ同じです。変えたのは配置のルールだけで、やったことは5つです。
レイヤーで縦に切り、左から右へ流す
クライアント → エッジ → アプリケーション → データ、の順に列を作ります。視線の向きと処理の流れを一致させると、矢印を追わなくても大まかな構造が読めます。列の見出しを図の上に置いておくと、読み手は自分がどの層を見ているかを見失いません。
監視やログは、どの層にも関わるので列に押し込まず下に帯として置くと収まります。無理に主フローの中に入れると線が交差します。
境界を先に描く
VPCを破線の枠で囲み、その中にアベイラビリティゾーンの枠を2つ置きます。枠を先に置いてから中身を配置すると、リソースの置き場所が自動的に決まり、「これはどこにあるんだっけ」という問いが消えます。
この枠があるだけで、ALBがパブリックサブネットにあること、ECSタスクがプライベートサブネットにあること、DBが2つのAZに分かれていることが、文章なしで伝わります。
線にラベルを付ける
矢印に「DNS」「HTTPS」「GET/PUT」と書き添えるだけで、線が何を運んでいるかが確定します。線の種類を変えるのも有効で、この図では同期レプリケーションだけ青い点線にしています。
そして線を減らします。図1の13本に対して図2は9本です。減った分は境界の枠が表現しています。枠で表せる関係を線で描かないのがコツです。
粒度をそろえる
「アプリ」「バッチ処理」という抽象度の違う箱をやめ、すべてAWSのサービス単位にそろえました。アプリケーションの中身を見せたいなら、それは構成図ではなく別の図（シーケンス図やコンポーネント図）の仕事です。1枚に2種類の図を混ぜないことです。
凡例を付ける
色でカテゴリを区別したなら、その対応を図の中に書きます。凡例のない色分けは、描いた本人にしか読めません。線種を使い分けた場合も同じで、破線と点線の意味を明示します。
公式アイコンを使うかどうか
AWSは公式のアーキテクチャアイコンセットを無償で配布しています。使えるなら使うべきで、理由は色と形状の意味が業界で共有されているからです。独自アイコンより誤読が減ります。
- サービスカテゴリごとに色が決まっている（コンピュート＝橙、データベース＝青、ストレージ＝緑、ネットワーク＝紫など）
- 四角＝サービス、丸＝リソース、といった形状の使い分けがある
- デザインが更新されるので、社内テンプレートは年1回は見直す
この記事の図2はアイコンを使わず、枠線の色だけでカテゴリを示しています。凡例さえあればこれでも読めることは、図を見てもらえば分かるはずです。アイコンは目的ではなく手段です。
ツールの選び方
| ツール | 向いている場面 |
|---|---|
| draw.io（diagrams.net） | 無料・公式アイコン同梱・ファイル保存できる。迷ったらこれ |
| Cloudcraft | 3D表現。経営層向けの提案資料 |
| Excalidraw | 手書き風。議論しながら描くホワイトボード用途 |
| Mermaid / PlantUML / d2 | コードで書く。Pull Requestで差分レビューできる |
| Lucidchart / Miro | 複数人での同時編集が必要な場合 |
万能なツールはありません。選ぶ基準は「その図が誰にどう更新されるか」です。一度きりの提案資料と、半年ごとに更新される運用ドキュメントでは、最適なツールが違います。
AIに描かせるという選択肢
最近はAIに描かせる手もあります。AWS公式のものとしては、Agent Plugins for AWS（awslabs/agent-plugins）の deploy-on-aws プラグインに入っている aws-architecture-diagram スキルがあります。「サーバーレスのREST APIの構成図を描いて」のように頼むと、公式のAWS4アイコンを使った draw.io のファイル（.drawio）を作ってくれます。CloudFormation・CDK・Terraform のコードを読ませて、既存の構成から描かせることもできます。
Claude Code なら、次の2行で入ります（Codex 用の設定も同梱されています）。
/plugin marketplace add awslabs/agent-plugins
/plugin install deploy-on-aws@agent-plugins-for-aws出てくるのが .drawio なので、前の表で「迷ったらこれ」と書いた draw.io でそのまま開いて手直しできます。PNG や SVG に書き出すには draw.io のデスクトップ版が必要で、XML の検証には Python の defusedxml を使います。
以前の「AWS Diagram MCP Server」は使えません
Python の diagrams パッケージで図を描く MCP サーバー awslabs.aws-diagram-mcp-server は、2026年3月9日に非推奨になり、4月15日にリポジトリから削除されました。PyPI の全32バージョンも取り下げ（yanked）られていて、pip で普通に指定しても「No matching distribution found」になります（2026年9月23日に確認）。バージョンを完全に固定すれば入ることはありますが、更新は止まっています。ネットで見かける設定例をそのまま使わず、上のスキルを使ってください。
そして、AIが出した図も、この記事の4つの条件を満たしているかは人が見る必要があります。読む順番・粒度・線の意味・境界は、生成の時点では揃わないことがあります。.drawio の中身は XML のテキストなので、リポジトリに置けば次の節のとおり差分もレビューできます。
更新される図はコードで持つ
構成が頻繁に変わるシステムでは、図をコードで書いてリポジトリに置くと維持できます。テキストなので差分が読め、レビューの対象にできるのが最大の利点です。
flowchart LR
U((ユーザー)) -->|DNS| R53[Route 53]
U -->|HTTPS| CF[CloudFront + WAF]
CF --> ALB[ALB]
subgraph VPC[VPC 10.0.0.0/16]
subgraph AZ1[ap-northeast-1a]
ALB --> T1[ECS Fargate]
T1 --> DB1[(RDS primary)]
end
subgraph AZ2[ap-northeast-1c]
ALB --> T2[ECS Fargate]
T2 --> DB2[(RDS standby)]
end
end
DB1 -.同期.- DB2
T1 -->|GET/PUT| S3[(S3)]ただし、コードで書ける図には限界があります。レイアウトを自動生成に任せる以上、「ここは離して見せたい」といった意図は表現しきれません。提案資料のように見せ方が重要な図は、手で描いたほうが速く、伝わります。
実務では併用が現実的です。運用ドキュメントの図はコードで持って自動更新し、提案や説明用の図は別に手で作る、という使い分けになります。
1枚に収まらないときは分ける
構成が大きくなると、1枚にすべてを収めようとして図1に逆戻りします。避けるには、最初から目的の違う複数枚に分けると決めておくことです。実務では次の3種類あれば足ります。
- 全体像
箱は10個以内。1画面で読み切れることを最優先にし、細部は捨てる。提案や説明はこれ1枚で足りる - 詳細図
サブネット・セキュリティグループ・ポート番号まで描く。運用引き継ぎと障害対応で使う - データフロー図
個人情報や決済データがどこを通り、どこに保存されるかだけを描く。セキュリティレビューと監査で必要になる
1枚で全部を賄おうとすると、全体像としては細かすぎ、詳細図としては足りない、という中途半端な図になります。1枚に1つの目的と決めるほうが、結果的に描く手間も減ります。
そして、図で表現しきれないことは無理に描かず、文章で補います。フェイルオーバーの手順や、なぜこの構成を選んだかという設計判断は、図の仕事ではありません。図は「何がどこにあるか」を担当し、「なぜ・どうやって」は文章が担当すると切り分けると、どちらも読みやすくなります。
出す前のチェックリスト
- この図の目的と読み手を、一文で言えるか
- 左上から右下へ、処理の流れどおりに読めるか
- 箱の粒度がそろっているか（サービスと処理を混ぜていないか）
- 線が何を表しているか、ラベルか凡例で分かるか
- VPCやAZの境界が描かれているか
- 色や線種を使い分けたなら、凡例があるか
- 目的に対して不要な要素を落としたか
- この図を初めて見る人に、説明なしで渡せるか
最後の項目がいちばん大事です。口頭の補足がないと成立しない図は、まだ完成していません。構成図はプレゼンの小道具ではなく、単体で読まれるドキュメントだからです。
まとめ
図1と図2の違いは、作図スキルではありません。描く前に目的・読み手・粒度を決めたかどうか、それだけです。
決めてしまえば、あとは機械的な作業になります。レイヤーで列を作り、境界を先に描き、線にラベルを付け、粒度をそろえ、凡例を付ける。この5つを順にやるだけで、図1は図2になります。
次に読む記事
