技術

draw.ioのMCPサーバを使ってAWSの構成図を作成してみる

はじめに

AWSのインフラ構成図を作成する際、手動でdraw.ioを使って描くことが多いが、MCPサーバを使えばLLMに指示するだけで構成図を生成できるようになる。

今回は、draw.ioの公式MCPサーバである@drawio/mcpを使って、以下の3つのアプローチでAWSの構成図作成を試してみる。

  • 自然言語での指示
    テキストで構成を伝えて構成図を描かせる

  • Terraformコードの読み込み
    .tfファイルを渡して構成図を自動生成する

  • kiro CLIでの既存リソース解析
    kiroのCLIを使って既存AWSリソースのリージョンを解析し、構成図を作成する

環境

VS Code: 1.109.0
GitHub Copilot
Node.js: v22.x
@drawio/mcp: 1.1.0
Terraform: 1.10.x
kiro CLI

draw.io MCPサーバとは

draw.ioの公式MCPサーバで、LLMからdraw.ioの図を作成・表示できるようにするものである。

以下の3つのツールが用意されている。

ツール名説明
open_drawio_xmldraw.ioのXMLコンテンツでエディタを開く
open_drawio_csvCSVデータを図に変換して開く
open_drawio_mermaidMermaid.js記法の図を変換して開く

仕組みとしては、MCPサーバがコンテンツ（XML/CSV/Mermaid）を受け取り、pakoで圧縮してbase64エンコードし、draw.ioのURLを生成してブラウザで開くという流れとなる。

MCPサーバのセットアップ

VS Codeでの設定

VS Codeのsettings.json（またはワークスペースの.vscode/mcp.json）に以下を追加する。

{
  "mcp": {
    "servers": {
      "drawio": {
        "command": "npx",
        "args": ["@drawio/mcp"]
      }
    }
  }
}

設定後、MCPサーバがrunningになっていることを確認する。

Claude Desktopでの設定

Claude Desktopを使う場合は、claude_desktop_config.jsonに以下を追加する。

{
  "mcpServers": {
    "drawio": {
      "command": "npx",
      "args": ["@drawio/mcp"]
    }
  }
}

実践1: 自然言語の指示で構成図を作成する

まずは、テキストで構成を伝えて構成図を作成できるか試してみる。

以下のようなプロンプトで指示を出す。

open_drawio_xmlを使って、以下のAWS構成図を作成してください。

- VPC (10.0.0.0/16)
  - パブリックサブネット x2 (ap-northeast-1a, 1c)
    - ALB
  - プライベートサブネット x2 (ap-northeast-1a, 1c)
    - EC2 x2 (Auto Scaling Group)
  - プライベートサブネット x2 (ap-northeast-1a, 1c)
    - RDS (Multi-AZ)
- Route 53
- CloudFront
- S3 (静的コンテンツ)

LLMがopen_drawio_xmlツールを呼び出し、AWSのアイコンを配置したXMLを生成する。
生成されたURLをブラウザで開くと、draw.ioのエディタ上に構成図が表示される。

結果

指示した通りの構成が描画されるかを確認する。ポイントは以下の通り。

  • VPCの中にサブネットが正しくネストされているか
  • AZが分かれて配置されているか
  • ALB → EC2 → RDSの接続が正しいか
  • AWSの公式アイコンが使われている

以下のようになった。

自然言語の指示だけでも、基本的な構成図は生成できる。
ただ、レイアウトの細かい調整や、アイコンの正確性については手動で修正が必要になる場合がある。

実践2: Terraformコードから構成図を作成する

次に、Terraformの.tfファイルを読み込ませて構成図を作成できるか試してみる。

サンプルのTerraformコード

以下のようなmain.tfを用意する。

# VPC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "main-vpc"
  }
}

# Public Subnets
resource "aws_subnet" "public_1a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-1a"

  tags = {
    Name = "public-subnet-1a"
  }
}

resource "aws_subnet" "public_1c" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.2.0/24"
  availability_zone = "ap-northeast-1c"

  tags = {
    Name = "public-subnet-1c"
  }
}

# Private Subnets
resource "aws_subnet" "private_1a" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.10.0/24"
  availability_zone = "ap-northeast-1a"

  tags = {
    Name = "private-subnet-1a"
  }
}

resource "aws_subnet" "private_1c" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.11.0/24"
  availability_zone = "ap-northeast-1c"

  tags = {
    Name = "private-subnet-1c"
  }
}

# ALB
resource "aws_lb" "main" {
  name               = "main-alb"
  internal           = false
  load_balancer_type = "application"
  subnets            = [aws_subnet.public_1a.id, aws_subnet.public_1c.id]
}

# EC2 Instances
resource "aws_instance" "app_1a" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"
  subnet_id     = aws_subnet.private_1a.id

  tags = {
    Name = "app-server-1a"
  }
}

resource "aws_instance" "app_1c" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"
  subnet_id     = aws_subnet.private_1c.id

  tags = {
    Name = "app-server-1c"
  }
}

# RDS
resource "aws_db_instance" "main" {
  identifier        = "main-db"
  engine            = "mysql"
  engine_version    = "8.0"
  instance_class    = "db.t3.medium"
  allocated_storage = 20
  multi_az          = true

  db_subnet_group_name = aws_db_subnet_group.main.name

  tags = {
    Name = "main-db"
  }
}

resource "aws_db_subnet_group" "main" {
  name       = "main-db-subnet-group"
  subnet_ids = [aws_subnet.private_1a.id, aws_subnet.private_1c.id]
}

プロンプト

以下のTerraformコードを読み込んで、open_drawio_xmlを使ってAWS構成図を作成してください。
リソース間の依存関係を矢印で表現し、VPCやサブネットは入れ子構造で描いてください。

[main.tfの内容を貼り付け or ファイルパスを指定]

結果

Terraformのリソース定義から以下の要素が読み取られ、構成図に反映される。

  • aws_vpc → VPCの枠
  • aws_subnet → サブネットの枠（AZ情報付き）
  • aws_lb → ALBのアイコン
  • aws_instance → EC2のアイコン
  • aws_db_instance → RDSのアイコン
  • multi_az = true → Multi-AZ構成の表現
  • サブネットの紐づけ → 正しいサブネット内にリソースを配置

以下のようになった。

Terraformコードでリソース間の依存関係が明示されているため、自然言語よりも正確な構成図が生成される傾向にある。
ただし、セキュリティグループのルールなど、ネットワーク的なフローまでは自動的に矢印にならないことがあるので、必要に応じて追記する。

実践3: kiro CLIで既存リソースを解析して構成図を作成する

最後に、kiroのCLIを使って既存のAWSリソースを解析し、構成図を作成してみる。

kiroとは

kiroはAWSが提供するAIを活用した開発ツールで、CLIモード（kiro-cli）でも利用できる。
既存AWSアカウントのリソースをスキャンし、構成情報を取得することができる。

手順

1. kiro CLIのセットアップ

kiroのCLIをインストールし、AWSの認証情報を設定する。

# AWSの認証情報が設定済みであること
aws sts get-caller-identity

2. 既存リソースの解析

kiro-cliを使って対象リージョンのリソースを解析する。

kiro-cli analyze --region ap-northeast-1

これにより、指定リージョンの既存リソース（VPC、サブネット、EC2、RDS、ALBなど）の一覧と依存関係が取得できる。

3. 解析結果をもとに構成図を作成

解析結果をLLMに渡し、draw.ioのMCPサーバで構成図を生成する。

以下のAWSリソースの解析結果をもとに、open_drawio_xmlを使ってAWS構成図を作成してください。
リージョンはap-northeast-1です。

結果

既存環境の実際のリソースから構成図を生成できるため、ドキュメントが追いついていない環境の可視化に有用そうだ。

ポイントとしては以下の通り。

  • 実際に稼働しているリソースが正確に反映される
  • リソース間のネットワーク的な依存関係も含まれる
  • タグ情報なども構成図のラベルに活用できる

ただし、リソース数が多い場合は構成図が大きくなるため、サービス単位やVPC単位でフィルタリングして描くのがよいと思われる。

参考

おわりに

draw.ioのMCPサーバを使って、3つのアプローチでAWSの構成図作成を試してみた。

自然言語での指示は手軽だが、正確性にはやや欠ける。
Terraformコードからの生成はリソース定義が明確なため比較的正確な構成図が得られる。
kiroのCLIを使った既存リソースの解析は、ドキュメントが追いついていない環境の可視化に特に有効だと感じた。

いずれのアプローチでも、生成後にdraw.io上で微調整は必要になるが、ゼロから手動で構成図を描くよりも大幅に時間を短縮できる。
以前もやってみたが、今度はdraw.ioのMCPサーバを活用することで、よりスムーズに構成図作成ができるようになったと感じた。

© 2020 - 2026 kbushi
Hugo で構築されています。
テーマ Stack は Jimmy によって設計されています。