Mermaidでインフラ構成図を書くと、テキストで管理できる一方で、最初は粒度に迷います。
VPC、Subnet、ALB、ECS、RDS、S3をすべて同じ階層に置くと読みづらくなり、逆に省略しすぎると構成の意味が伝わりません。

インフラ構成図ビルダーは、Mermaidの記法に慣れていない状態でも、構成のたたき台を作るために使えます。

まず決めること

最初に決めるのは「誰に見せる図か」です。
レビュー用なら接続関係を優先し、引き継ぎ用なら運用で見る単位を優先します。

flowchart LR
  User[User]
  ALB[ALB]
  App[ECS Service]
  DB[(RDS)]

  User --> ALB
  ALB --> App
  App --> DB

このくらいの粗い図から始めると、会話がしやすくなります。
最初からセキュリティグループや細かいサブネットまで入れると、図の目的がぼやけやすくなります。

実例：レビュー用と運用用を分ける

同じ構成でも、レビューで見たい図と運用で見たい図は違います。レビュー用なら通信の流れを優先します。

flowchart LR
  User --> CloudFront
  CloudFront --> ALB
  ALB --> App[ECS Service]
  App --> DB[(RDS)]
  App --> S3[(S3)]

一方、運用引き継ぎ用なら、監視やジョブも入れたくなります。

flowchart TB
  App[ECS Service]
  Worker[Batch Worker]
  DB[(RDS)]
  Logs[CloudWatch Logs]

  App --> DB
  Worker --> DB
  App --> Logs
  Worker --> Logs

この2つを1枚にまとめると読みづらくなるため、目的ごとに図を分けるのが現実的です。インフラ構成図ビルダーでたたき台を作るときも、最初に「この図で答えたい質問」を1つに絞るとまとまりやすくなります。

詰まりやすいポイント

  • ノード名が長すぎて図が読みにくい
  • 矢印の向きが通信方向と一致していない
  • AWSの正式名称とチーム内の呼び名が混ざる
  • 1枚の図にネットワーク、アプリ、データ層を詰め込みすぎる
  • Mermaidの構文エラーでプレビューが崩れる

まずは1枚で全体像を作り、必要ならネットワーク詳細、アプリ詳細、データ詳細に分けるのがおすすめです。

更新しやすい図にする

構成図は一度作って終わりではありません。
あとから人が直せるように、ノード名は短くし、コメントなしでも流れが分かる形にしておくと保守しやすくなります。

図が古くなる原因は、記法の難しさよりも「直す心理的コスト」です。
ブラウザでプレビューしながら直せる状態にしておくと、更新のハードルが下がります。

更新ルールを軽く決める

構成図を保守するなら、細かいルールを作りすぎるより、最低限のルールを残すほうが続きます。

ノード名: チーム内で通じる短い名前にする
矢印: リクエストまたは主要なデータの流れに合わせる
分割: 10ノードを超えたら詳細図に分ける
更新: インフラ変更PRで図も確認する

これだけでも、古い図が放置されにくくなります。

関連ツール