【AWS】Mermaid構成図の作り方：3つの視点と題目サンプルで設計意図まで言語化する

読者が欲しいのは、Mermaid構成図の「概念説明」ではなく、すぐ再現できる「作成手順」です。

特にAWSの学習や設計レビューでは、図を作れるだけでなく、構成意図まで説明できることが目的になります。

本記事では、AWSを題材に、Mermaid構成図を実務レベルで作るための手順を 3つの視点で整理します。

単なる図の描き方ではなく、要件読解・責務分離・説明可能性まで含めて、専門職のレビューに通る粒度を目指します。

視点1: 要件をノードへ分解する（題目: IAM・VPC・EC2の責務関係）

最初の視点は、文章要件をそのまま図にしないことです。

Mermaid構成図の品質は、描画前の「分解精度」でほぼ決まります。

題目として「IAM・VPC・EC2の責務関係」を設定し、要件をノードに切り出します。

次の題目を、Mermaid図にする前処理として分解してください。
題目: IAM・VPC・EC2の責務関係

要件:
- IAMはアクセス制御ポリシーを管理
- VPCはネットワーク分離境界を提供
- EC2はワークロード実行基盤

出力形式:
1) ノード一覧（責務つき）
2) エッジ一覧（依存関係つき）
3) graph TD向け草案

この段階で重要なのは、サービス名ではなく責務名でラベルを置くことです。

「どれが何を担当するか」を明確にすると、後工程でレビュー指摘が激減します。

視点2: 通信経路と境界を明示する（題目: Public/Private Subnetの経路設計）

2つ目の視点は、通信可否を図から一目で判断できる状態にすることです。

題目は「Public/Private Subnetの経路設計」です。

以下の要件をMermaidのgraph TDで図示してください。
題目: Public/Private Subnetの経路設計

要件:
- Public Subnet: ALB配置、Internet Gatewayに接続
- Private Subnet: EC2配置、NAT Gateway経由で外向き通信のみ許可
- DB Subnet: RDS配置、EC2からのみ到達可

制約:
- 境界(Subnet/VPC)をサブグラフで表現
- 許可通信のみ実線、禁止・非直結は注記

この視点では、境界と 経路 を分けて設計するのがコツです。

構成要素を増やすより、通信ルールを明確にしたほうが図の価値は上がります。

視点3: 設計判断の理由を図に埋め込む（題目: マルチAZ高可用構成）

3つ目の視点は、構成図を「見た目」ではなく「意思決定ドキュメント」にすることです。

題目として「マルチAZ高可用構成」を扱う場合、可用性設計の理由まで図に残します。

題目: マルチAZ高可用構成
Mermaid graph TDで、次の方針を満たす図を作成してください。

- AZ-A / AZ-C にそれぞれEC2とRDS(standby)を配置
- ALBは両AZへ分散
- 単一障害点を避けるため、各コンポーネントの冗長化理由を注記

要件:
1) 通常時の通信経路
2) 障害時のフェイルオーバー経路
3) なぜこの構成なのかの補足コメント

注記を入れるだけで、レビュー時の「この設計にした根拠は？」への回答コストが大幅に下がります。

専門的な読者ほど、図の美しさより 説明責任のトレーサビリティ を評価します。

実務で使える運用テンプレート

3視点を毎回ぶらさず回すために、以下の順でプロンプトを固定すると安定します。

手順1: 要件分解（視点1）
手順2: 境界と経路の描画（視点2）
手順3: 設計理由と障害時挙動を注記（視点3）
手順4: graph TDを出力し、レビュー観点で自己採点

この運用にすると、試験対策だけでなく、社内設計レビューや顧客説明にもそのまま転用できます。

まとめ：クラウドは「イメージ」できれば勝てる

Mermaid構成図は、単なる図解ツールではありません。

要件を分解し、境界と経路を示し、設計理由まで残すことで、図がそのまま設計説明になります。

AIと Mermaid を組み合わせ、3つの視点で題目を回すだけで、AWSの抽象概念は実務で使える知識に変わります。

「読むだけでわかる記事」から「再現して使える記事」へ。ここが、クリック後の価値を最大化する分岐点です。