検索

ia

ディープダイブ:AIエージェントとDraw.io MCPでAWSダイアグラムを生成する

ディープダイブ:AIエージェントとDraw.io MCPでAWSダイアグラムを生成する

インフラを見通すには、良い図があるといつも助かります。しかし手作業で作ると時間がかかります:適切なアイコンを探したり、要素を配置したり、接続を描いたり…。私が今夢中になっているのは、これらをすべてAIで自動化することです。

この記事では、Draw.io MCPとAIエージェントを使ってAWSアーキテクチャ図を自動生成する方法をお見せします。私は自分の環境でClaude Codeを使っていますが、この手法はMCP互換の任意のエージェントで機能します。

Claude CodeとDraw.io MCPによるAWSダイアグラムの自動生成

出発点:古い図を更新する

2018年に作成したこのブログのインフラに関する記事には、Draw.ioで手作りした図がありました。インフラ自体は大きく変わっていません — 主にOAC(Origin Access Control)とCloudFront Functionを追加した程度 — ですが、AWSのアイコンは進化しているので、最新バージョンに合わせて図を更新したかったのです。

自動化の方法を探していると、Chrome拡張付きのDraw.io MCP Serverを見つけました。試してみたらとても面白くて、情報を共有するためにこの記事を書くことにしました!

MCP Draw.io:Draw.ioをAIで制御する

Ladislav(lgazo)作成のDraw.io MCP Serverは、Draw.ioをプログラムから制御できるMCP(Model Context Protocol)サーバーです。要するに、AIエージェントがDraw.ioの図面を作成、変更、整理できるということです。

利用可能なツール

カテゴリツール用途
検査get-selected-cell, list-paged-modelキャンバスの状態を読む
作成add-rectangle, add-edge, add-cell-of-shape要素を追加する
変更edit-cell, edit-edge, set-cell-data既存の要素を修正する
ライブラリget-shape-categories, get-shapes-in-category利用可能なシェイプを参照する

必要な構成

AIエージェントがDraw.ioと通信できるように、プロジェクトのドキュメントに記載されているように、次の2つを設定する必要があります:

  1. ローカルのMCPサーバー — エージェントの設定ファイルに(例:Claude Code用の .mcp.json
  2. Draw.io MCP Chrome拡張 — MCPサーバーとブラウザのDraw.ioアプリの橋渡しをする

これらを用意すれば、エージェントはDraw.ioのキャンバスを直接操作できます:シェイプを作成し、位置を決め、接続線を引くといった操作をプログラムから行えます。

MCP Draw.ioを試してみると、きれいな結果を得るにはエージェントをうまく導く必要があると分かりました:リソースをでっち上げない、正しいAWSアイコンを使う、位置取りを一貫させる、カテゴリごとに色を適用する、テキストにHTMLを使わない…。そこで、これらルールをエンコードしたClaude Codeのskillを作成しました。

スキル /aws-diagram の作成

Claude Codeのスキルは、ワークフローとルールを定義するMarkdownファイルです。/aws-diagram を呼び出すと、Claude Codeはこれらの指示を読み込み、自動的に適用します。

ワークフロー

スキルは4ステップのプロセスに従います:

  1. インフラコードを読む(Terraform、CloudFormation)
  2. AWSリソースとその関係を抽出する
  3. 公式のAWSアイコンで図を構築する
  4. 説明ラベル付きで接続を追加する
📄 スキル抜粋:ワークフロー
## Workflow

1. **Read infrastructure code** (Terraform, CloudFormation, etc.)
2. **Extract AWS resources** and their relationships
3. **Build diagram** with official AWS icons
4. **Add connections** with descriptive labels

重要なルール

スキルにはいくつかの重要ルールを組み込みました:

1. リソースを決してでっち上げない

これが最大の罠でした。LLMは論理的に「補完」してしまう傾向があります。「CloudFrontがあるならLambda@Edgeもあるはずだ…」 — そうではありません!図はコードに存在するものだけを正確に表すべきで、余計なものは表示してはいけません。

📄 スキル抜粋:でっち上げ禁止
### NEVER invent resources

**Only diagram what actually exists in the infrastructure code.**

| Situation                  | Wrong                                         | Correct                                      |
| -------------------------- | --------------------------------------------- | -------------------------------------------- |
| No Lambda in Terraform     | Add Lambda@Edge because "it would make sense" | Don't add Lambda                             |
| CloudFront Function exists | Use Lambda icon                               | Use CloudFront icon with "CF Function" label |
| No WAF configured          | Add WAF for "security"                        | Don't add WAF                                |

2. ユーザーは外部とする

「Users」はAWSリソースではありません。AWSクラウドの外側に表示する必要があります。

📄 スキル抜粋:ユーザーは外部
### Users OUTSIDE the AWS Cloud

**Users are NOT AWS resources.** They represent external actors.

WRONG:
┌─────────────────────────────────┐
│ AWS Cloud │
│ [Users] → [Route53] → [CF] │ ❌ Users inside cloud
└─────────────────────────────────┘

CORRECT:
[Users] → ┌─────────────────────────┐
│ AWS Cloud │
│ [Route53] → [CF] → [S3] │ ✅ Users outside
└─────────────────────────┘

3. テキストにHTMLを使わないこと

Draw.ioはHTMLをレンダリングしません。text: "S3<br>Private" のように書くと、図中にそのまま <br> と表示されます。

📄 スキル抜粋:HTML禁止
### NEVER use HTML in text parameters

Draw.io does NOT render HTML tags in text fields. They display as raw text.

**FORBIDDEN (will show ugly raw HTML):**

text: "S3 Bucket<br>Private" ❌ Shows "<br>" literally
text: "Route 53&nbsp;DNS" ❌ Shows "&nbsp;" literally
text: "<font color='red'>ACM</font>" ❌ Shows raw HTML tags

**CORRECT (clean text):**

text: "S3 Bucket" ✅ Single line, clean
text: "Route 53" ✅ Service name only
text: "ACM" ✅ Simple label

4. レイアウトを計画して衝突を避ける

交差するエッジは図を読みにくくします。スキルでは主要なフローを水平線上に配置し、補助サービスをその上または下に配置することを推奨しています。

📄 スキル抜粋:レイアウトと衝突回避
### Rule 1: Main Flow on a Horizontal Line

Place the primary data flow (request path) on a single horizontal row:

[Entry] → [Service A] → [Service B] → [Service C]
y=300 y=300 y=300 y=300

### Rule 2: Auxiliary Services Above or Below

Services that connect TO a main service (not part of the flow) go above or below:

        [Auth]     [Edge Logic]     ← Auxiliary row (y=150)
           \           /
            \         /
             ↓       ↓

[Entry] → [Gateway] → [Compute] → [Storage] ← Main flow (y=300)

5. 注釈は下ではなく右に配置する

AWSアイコンはラベルが自動的に下に配置されます。注釈を下に追加すると次の行と重なります。アイコンの右に配置してください。

📄 スキル抜粋:注釈の配置
### Annotation Placement Rules

**CRITICAL: Place annotations to the RIGHT of icons, not below.**

**WRONG - Annotations below icons:**

[CloudFront] [S3]
|
"Cache Policies" ← Overlaps with next row!
"Security Headers"
|
[CloudFront Preview] ← Collision!

**CORRECT - Annotations to the RIGHT:**

[CloudFront] ── "Cache Policies: HTML 0s | Assets 1y"
| "Security: CSP | HSTS"

[CloudFront Preview] ← No collision

カラースキーム

AWSの慣習に合わせた一貫したパレットを定義しました:

カテゴリサービス例
Networking#8C4FFF(紫)Route53、CloudFront、VPC
Storage#7AA116(緑)S3、EFS
Security#DD344C(赤)ACM、IAM、WAF
Compute#ED7100(オレンジ)Lambda、EC2

データフローには環境別の色を使います:

  • Production:緑 #4CAF50
  • Preview:オレンジ #FF9800
  • Configuration:灰色 #AAAAAA(破線)
📄 スキル抜粋:色とスタイル
### Colors by Category

| Category       | Color               | Services                                   |
| -------------- | ------------------- | ------------------------------------------ |
| **Networking** | `#8C4FFF` (violet)  | Route53, CloudFront, VPC, ELB, API Gateway |
| **Compute**    | `#ED7100` (orange)  | Lambda, EC2, ECS, Fargate                  |
| **Storage**    | `#7AA116` (green)   | S3, EFS, EBS                               |
| **Database**   | `#C925D1` (magenta) | RDS, DynamoDB, ElastiCache                 |
| **Security**   | `#DD344C` (red)     | ACM, IAM, WAF, Cognito                     |
| **General**    | `#232F3D` (gray)    | Users, Generic                             |

### AWS Icon Style Template

sketch=0;outlineConnect=0;fontColor=#232F3E;fillColor=<COLOR>;strokeColor=#ffffff;
dashed=0;verticalLabelPosition=bottom;verticalAlign=top;align=center;html=1;
fontSize=12;fontStyle=0;aspect=fixed;shape=mxgraph.aws4.resourceIcon;
resIcon=mxgraph.aws4.<SERVICE>;

### Edge Colors by Environment

| Environment   | Color     | Usage                  |
| ------------- | --------- | ---------------------- |
| Production    | `#4CAF50` | Main production flow   |
| Preview       | `#FF9800` | Staging environments   |
| Configuration | `#AAAAAA` | Dashed, non-data links |

実例:jls42.org のインフラ

テストとして、このブログのインフラにスキルを適用しました。

解析したTerraformコード

terraform/
├── cloudfront-astro.tf    # Distribution CloudFront prod
├── s3-astro.tf            # Bucket S3 privé avec OAC
├── acm-astro.tf           # Certificat SSL
├── route53.tf             # DNS
└── variables.tf           # Variables

抽出されたアーキテクチャ

コンポーネントAWSサービス設定
DNSRoute 53jls42.orgのゾーン、3つのドメイン
CDNCloudFrontOAC、CF Function、キャッシュポリシー
ストレージS3プライベートバケット、AES256、OACのみ
TLSACMus-east-1の証明書、DNS検証

生成された図

最終的な結果は次のとおりです:

自動生成された jls42.org の AWS アーキテクチャ 自動生成された jls42.org の AWS アーキテクチャ

単純な自然言語プロンプトから:

«Analyse en profondeur l’infrastructure de ce projet puis réalise un super schéma de l’architecture AWS comme un pro. Juste l’infra de prod, pas preview ni legacy.»

🇯🇵 「このプロジェクトのインフラを深く解析して、プロのようなAWSアーキテクチャのすばらしい図を作成してください。プロダクションのインフラのみで、プレビューやレガシーは含めないでください。」

Claude CodeはまずTerraformファイルを解析してインフラを特定し、次にスキル /aws-diagram を読み込んで以下を行いました:

  1. 主要コンポーネント(Users、Route53、CloudFront、S3、ACM)を作成
  2. 詳細な注釈(キャッシュポリシー、セキュリティヘッダ、バケット設定など)を追加
  3. 接続線にラベル(HTTPS、DNS Alias、OAC、TLS証明書など)を付与
  4. 外部サービス(Plausible Analytics、Gandiのメールなど)を追加
  5. カテゴリ別の凡例を生成

すべてきれいなレイアウトで:

  • AWSクラウド領域を自動的にサイズ調整(900×420px)
  • Usersはクラウドの左側
  • 外部サービスは右側
  • 図の下に凡例

完全なワークフロー:Terraformから動画へ

この体験をさらに進め、デモ動画も作成しました。

録画

図の生成をリアルタイムで録画しました:Claude CodeがTerraformを読み、要素を一つずつ作成して図を構築する様子を4分10秒収録しました。

FFmpegでのポストプロダクション

4分はデモとして長いので、FFmpegで可変スピードを使って短縮しました:

セグメント内容速度
0:00-0:10Claudeに図を生成するよう要求1x
0:10-0:32Terraformコードの解析15x
0:32-0:35スキル /aws-diagram が検出され自動で起動1x
0:35-3:46ブラウザ内での図の生成15x
3:46-3:56見栄えを良くするためのラベル再配置1x

結果:4分の映像が42秒に短縮され、重要な瞬間は通常速度のまま残しました。

HeyGenでのナレーション

ナレーションを追加するために、スクリプトを書き、ビデオを30秒ごとのセグメント(HeyGenの制限)に分割してフランス語の音声を生成しました。基本の音声が気に入らなかったので、彼らの「ボイスデザイン」機能を使い、プロンプトを調整しながら即席で声を作成しました。

最終的なビデオはこの記事上部でご覧いただけます。

2つ目の例:高可用性EKSアーキテクチャ

MCP Draw.ioの性能を示すため、もう一つ複雑な例として高可用性のEKSアーキテクチャを作成しました。MCPがDraw.ioでの作成作業をすべて行い、私は詳細なプロンプトを提供しただけです。

今回は望むアーキテクチャを詳細に記述したプロンプトを与えました:

📋 EKSアーキテクチャ用の完全プロンプト
Architecture EKS Hautement Disponible

Génère un diagramme d'architecture AWS EKS avec les composants suivants :

## Services AWS à inclure

### Externes (gauche du cloud)

- Users (icône utilisateurs générique)

### Networking

- Route 53 (DNS)
- Application Load Balancer (ALB) - dans les subnets publics
- NAT Gateway (3x, un par AZ)
- VPC avec 3 AZ

### Compute (subnets privés)

- EKS Control Plane (géré par AWS - représenter séparément)
- 3 Node Groups (un par AZ) avec pods à l'intérieur

### Storage

- EFS (stockage partagé cross-AZ)

### Security

- ACM (Certificate Manager)
- IAM (pour Pod Identity / IRSA)

### Observability

- CloudWatch (logs et métriques)

## Connexions à tracer

| Source            | Target      | Label               | Style       |
| ----------------- | ----------- | ------------------- | ----------- |
| Users             | Route 53    | HTTPS               | Solid green |
| Route 53          | ALB         | DNS Alias           | Solid green |
| ALB               | Node Groups | Traffic             | Solid green |
| ACM               | ALB         | TLS                 | Dashed gray |
| Node Groups       | EFS         | NFS Mount           | Solid green |
| EKS Control Plane | Node Groups | kubectl API         | Solid green |
| EKS Control Plane | IAM         | IRSA / Pod Identity | Dashed gray |
| Node Groups       | CloudWatch  | Logs / Metrics      | Dashed gray |

生成結果

自動生成された高可用性EKSアーキテクチャ 自動生成された高可用性EKSアーキテクチャ

この図は本番環境向けのKubernetesアーキテクチャを表しており、以下を示しています:

  • 3つのアベイラビリティゾーンによる高可用性
  • 各AZごとの冗長なNAT Gatewayによるインターネットアクセス
  • AZごとに分散したNode Groupと各AZのPod配置
  • クロスAZに対応するEFSによる永続共有ストレージ
  • 視覚的に分離されたAWS管理のControl Plane
  • **IRSA(IAM Roles for Service Accounts)**によるPodのセキュリティ

MCP Draw.ioはVPCとAZのグループを正しく解釈し、NAT Gatewayをパブリックサブネットに、Node Groupをプライベートサブネットに配置しました。結果はレイアウトの基礎として非常に良い出発点を提供し、見た目の好みに応じて微調整したり、必要に応じて誤りを修正したりできます — ゼロから作るよりずっと速いです。

このプロジェクトが示すこと

この体験から、私のワークスタイルのいくつかの側面が明らかになりました:

  • ドキュメントの自動化:コードが単一の真実の源であり、図はそこから自動的に生成されるべき
  • 適切なツールを使うこと:MCP Draw.ioはまさに求めていたもので、車輪の再発明は不要だった
  • ルールのエンコード:スキルは専門知識をキャプチャし、一般的なミスを防ぐ — これはAWSだけでなく任意のDraw.io図に応用可能
  • 実践でテストする:自身のインフラを実験場として使った
  • 探究を進める:自動生成からナレーション付き動画まで、各ステップが学びの機会になった

このスキルは現在ワークフローに組み込まれています。次にインフラを変更したら、単一のプロンプトで図を再生成できます。

リソース


MCP対応のコーディングエージェントを使い、ドキュメント化すべきインフラをお持ちなら、この手法をぜひ試してみてください。きれいな図が自動で組み上がっていくのを見るのはとても満足感があります。

お読みいただきありがとうございました。この記事が皆さんの実験欲を刺激することを願っています!

この文書は gpt-5-mini モデルを使用して、fr版からja版へ翻訳されました。翻訳プロセスの詳細については、https://gitlab.com/jls42/ai-powered-markdown-translator を参照してください。