draw.io公式MCP Serverがリリース！Kiro CLIで試してみつつ、AWS Diagram MCP Serverとの比較もやってみた

160

Last updated at 2026-02-12Posted at 2026-02-11

はじめに

2026年2月、draw.ioの公式MCP（Model Context Protocol）Serverがリリースされました。

MCP Serverの登場が相次いでいますが、作図ツールとして広く使われている（と思っている）draw.ioからも公式のMCP Serverが出てきました。これまで私はLLMで作図をさせる場合は、AWS Diagram MCP Serverを使ってPNG形式で出力させるか、LLMに依頼してdrawio形式で出力させていました。新たに登場したdraw.io MCP Serverを試しつつ、既存のAWS Diagram MCP Serverとの比較もやってみることにしました。

今回は、以下の流れで進めていきます。

draw.ioとdraw.io MCP Serverの紹介
Kiro CLIでのセットアップ
過去の記事で作成したAWS構成図をLLMに解析させて文章化してみる
draw.io MCP ServerとAWS Diagram MCP Serverで同じ構成図を作図して比較してみる

1. draw.ioとは

draw.ioは、無料で使えるオープンソースの作図ツールです。ブラウザ上で動作し、デスクトップ版も提供されています。AWS、Azure、GCPなどのクラウドアイコンが標準搭載されていて、フローチャート、ネットワーク図、ER図など幅広い図に対応しています。XML形式で保存されるため、Git管理との相性も良いと感じています。私は数年前に知って以来、人手での作図はほとんどdraw.ioを使っていました。

draw.io MCP Serverとは

draw.ioの開発元が公式にリリースしたMCP Serverです。LLMから直接draw.ioの図を作成・編集できるようになりました。

npm パッケージ: @drawio/mcp
GitHub: jgraph/drawio-mcp

提供されるツール

現時点では3つのツールが搭載されています。

ツール名	説明
open_drawio_xml	draw.ioネイティブのXML形式で図を開く
open_drawio_csv	CSVデータを図に変換して開く（組織図、フローチャートなど）
open_drawio_mermaid	Mermaid.js記法を変換してdraw.ioで開く

Mermaid形式の図もopen_drawio_mermaidでお任せです。

仕組み

LLMが図の内容（XML / CSV / Mermaid）を生成
※作図自体はLLMの処理になります。draw.io MCP Server自体の処理ではありません。
MCP Serverがコンテンツをpako deflateRaw（zlibをJavaScriptに移植した高速圧縮ライブラリ）で圧縮 → base64エンコード
#create ハッシュパラメータ付きのdraw.io URLを生成
ブラウザでURLを開くと、draw.ioエディタ上で図が表示・編集可能

生成されたURLのハッシュフラグメント（#create=...）はブラウザ内に留まり、外部に送信されないため、セキュリティ面でも安心だと考えます。

2. Kiro CLIでのセットアップ

それでは、早速Kiro CLIで使っていきます。

draw.io MCP Serverの設定

~/.kiro/settings/mcp.json に以下を追加します。

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

前提として、Node.js（npxが使える状態）が必要です。設定後、Kiro CLIを再起動すれば準備完了です。

AWS Diagram MCP Serverの設定

比較対象として使用するAWS Diagram MCP Serverも合わせて設定しておきます。

{
  "mcpServers": {
    "awslabs.aws-diagram-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.aws-diagram-mcp-server"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "autoApprove": [],
      "disabled": false
    }
  }
}

AWS Diagram MCP Serverの前提条件は以下になります。

Python 3.12以上
uv
GraphViz

GraphVizのインストールがまだの方は、macOSの場合は以下で導入できます。

brew install graphviz

3. 事前準備：過去に作成したAWS構成図をLLMに解析させて文章化する

まずは、過去にdraw.ioで作成したAWS構成図をLLMに読み込ませて、構成内容を文章化してもらいます。

解析対象の構成図

以下は、AWS Fault Injection ServiceでECS on FargateのAZ障害にトライ！で使用したマルチAZ構成のAWS構成図です。

LLMに解析させてみる

Kiro CLIで画像を渡して「この構成図の内容を説明してください」と指示してみました。
結果、以下のような文章が生成されました。

画像を渡すだけで、構成の意図まで含めて正確に読み取ってくれました。自分で作った図なので正確性の判断ができますが、他の方が作成した図の理解にも活用できるのではないかと感じました。

4. draw.io MCP ServerとAWS Diagram MCP Serverで同じ構成図を作図して比較

draw.io MCP Serverで構成図を作図する

先ほどLLMが解析した構成を、draw.io MCP Serverで再現してみます。MCP Serverによって選択されるモデルが変わらないように、modelはclaude-opus-4.6に固定しました。

プロンプト

それでは先ほど生成された文章を使用して、以下のように指示を与えてきます。

draw.io MCPのopen_drawio_xmlを使って、以下のAWS構成図を作成してください。AWSの公式アイコンスタイルを使用してください。

## 全体構成

AWS Cloud 内の単一 VPC (Virtual Private Cloud) に、マルチAZ（Availability Zone）構成で高可用性を実現したアーキテクチャです。

## ネットワーク構成

- Public subnet: Internet Gateway に接続された外部向けのサブネット。ALB（Application Load Balancer）が配置されています。
- Private subnet（アプリケーション層）: Fargate タスクが稼働するサブネット。外部から直接アクセスできません。
- Private subnet（データベース層）: Amazon Aurora が配置されるサブネット。

各サブネットは2つの Availability Zone にまたがって冗長化されています。

## リクエストの流れ

1. Internet Gateway → 外部からのトラフィックがVPCに入る入口
2. ALB（1つ目）→ フロントエンド用のロードバランサー。トラフィックを2つのAZに分散
3. Fargate - Front End Task（×2）→ 各AZに1つずつ配置されたフロントエンドコンテナ
4. ALB（2つ目）→ バックエンド用の内部ロードバランサー。フロントエンドからのリクエストをバックエンドに分散
5. Fargate - Back End Task（×2）→ 各AZに1つずつ配置されたバックエンドコンテナ
6. Amazon Aurora → Writer（書き込み用）と Reader（読み取り用）のエンドポイントを持つデータベースクラスター

## 設計上のポイント

- 高可用性: 全レイヤーが2つのAZに分散されており、片方のAZが障害を起こしてもサービスが継続可能です
- セキュリティ: パブリックサブネットにはALBのみを配置し、アプリケーションとDBはプライベートサブネットに隔離しています。各サブネ
ットにはセキュリティグループ（鍵アイコン）が設定されています
- サーバーレスコンテナ: ECS on Fargate を使用しており、EC2インスタンスの管理が不要です
- データベースの読み書き分離: Aurora の Writer/Reader エンドポイントを分けることで、読み取り負荷を分散しています

## 使用AWSサービスまとめ

| サービス | 役割 |
|---|---|
| VPC | ネットワーク分離 |
| Internet Gateway | インターネット接続 |
| ALB (×2) | トラフィック分散 |
| ECS on Fargate | コンテナ実行基盤 |
| Amazon Aurora | リレーショナルデータベース |

典型的なプロダクション向けの堅牢な構成で、スケーラビリティ・可用性・セキュリティのバランスが取れた設計です。

結果

実行結果はこちらになります。

作成された図がこちら。LLMの力任せですが、いい感じに作っています。強いていうならBackend Taskのアクセス先はAZ1のAuroraになっていてくれると嬉しかったというくらいです。（曖昧な指示なので書けなくて当然）

作成されたファイルはdraw.io MCP Serverの機能でブラウザが自動的に起動し、draw.ioエディタ上に構成図が表示されました。生成された図はそのまま編集可能なので、文字が被っていたり、レイアウトが気になる部分は手動で微調整できます。もちろんPNG、SVG、PDFなどへのエクスポートも可能です。

AWS Diagram MCP Serverで同じ構成図を作図する

続いて、AWSが提供するAWS Diagram MCP Serverでも同じ構成を作図してみます。

AWS Diagram MCP Serverとは

AWSLabsが提供する公式MCP Serverです。Pythonのdiagramsパッケージを使用して図を生成します。AWS構成図、シーケンス図、フロー図、クラス図に対応しています。

プロンプト

AWS Diagram MCP Serverにはdrawio形式で出力するtoolはありませんので、draw.io MCP Serverが使われないよう、mcp.jsonで"disabled": trueに設定した上で実施しました。

AWS Diagram MCP Serverを使って、以下のAWS構成図を作成してください。AWSの公式アイコンスタイルを使用してください。
作図したものはdrawio形式で出力してください。

## 全体構成

AWS Cloud 内の単一 VPC (Virtual Private Cloud) に、マルチAZ（Availability Zone）構成で高可用性を実現したアーキテクチャです。

## ネットワーク構成

- Public subnet: Internet Gateway に接続された外部向けのサブネット。ALB（Application Load Balancer）が配置されています。
- Private subnet（アプリケーション層）: Fargate タスクが稼働するサブネット。外部から直接アクセスできません。
- Private subnet（データベース層）: Amazon Aurora が配置されるサブネット。

各サブネットは2つの Availability Zone にまたがって冗長化されています。

## リクエストの流れ

1. Internet Gateway → 外部からのトラフィックがVPCに入る入口
2. ALB（1つ目）→ フロントエンド用のロードバランサー。トラフィックを2つのAZに分散
3. Fargate - Front End Task（×2）→ 各AZに1つずつ配置されたフロントエンドコンテナ
4. ALB（2つ目）→ バックエンド用の内部ロードバランサー。フロントエンドからのリクエストをバックエンドに分散
5. Fargate - Back End Task（×2）→ 各AZに1つずつ配置されたバックエンドコンテナ
6. Amazon Aurora → Writer（書き込み用）と Reader（読み取り用）のエンドポイントを持つデータベースクラスター

## 設計上のポイント

- 高可用性: 全レイヤーが2つのAZに分散されており、片方のAZが障害を起こしてもサービスが継続可能です
- セキュリティ: パブリックサブネットにはALBのみを配置し、アプリケーションとDBはプライベートサブネットに隔離しています。各サブネ
ットにはセキュリティグループ（鍵アイコン）が設定されています
- サーバーレスコンテナ: ECS on Fargate を使用しており、EC2インスタンスの管理が不要です
- データベースの読み書き分離: Aurora の Writer/Reader エンドポイントを分けることで、読み取り負荷を分散しています

## 使用AWSサービスまとめ

| サービス | 役割 |
|---|---|
| VPC | ネットワーク分離 |
| Internet Gateway | インターネット接続 |
| ALB (×2) | トラフィック分散 |
| ECS on Fargate | コンテナ実行基盤 |
| Amazon Aurora | リレーショナルデータベース |

典型的なプロダクション向けの堅牢な構成で、スケーラビリティ・可用性・セキュリティのバランスが取れた設計です。

結果

得られた回答はこちらです。

そして、作図された結果が以下になります。
うーん。先ほどの精度を見るとちょっと物足りなくなってしまいました。

ちなみに出力するために使用されたコードはこちら

with Diagram("AWS Multi-AZ Architecture", show=False, direction="TB", filename="aws_multi_az_architecture"):
    igw = IGW("Internet Gateway")

    with Cluster("AWS Cloud"):
        with Cluster("VPC"):
            # Public Subnet - ALB (Frontend)
            with Cluster("Public Subnet"):
                alb_front = ALB("ALB\n(Frontend)")

            # Internal ALB
            with Cluster("Private Subnet (App)"):
                with Cluster("AZ-1"):
                    front1 = Fargate("Front End\nTask")
                    back1 = Fargate("Back End\nTask")
                with Cluster("AZ-2"):
                    front2 = Fargate("Front End\nTask")
                    back2 = Fargate("Back End\nTask")
                alb_back = ALB("ALB\n(Backend)")

            with Cluster("Private Subnet (DB)"):
                with Cluster("Aurora Cluster"):
                    writer = Aurora("Writer")
                    reader = Aurora("Reader")

    igw >> alb_front
    alb_front >> front1
    alb_front >> front2
    front1 >> alb_back
    front2 >> alb_back
    alb_back >> back1
    alb_back >> back2
    back1 >> writer
    back2 >> writer
    back1 >> reader
    back2 >> reader
    writer - reader

さらにLLMの力によって、XML形式で出力したものが以下になります。
よく上記のPNGの状態からこのdrawio形式まで持っていったなと感心します。
なお、drawio形式で作図されていますが、ローカルにファイルが出力されるのみでdraw.ioでファイルが開かれることはありません。
作図された内容ですが、元の画像を縦書きにした形になっています。ECSからAuroraの線がちょっと惜しいところです。

比較してみる

同じコンテキストで、それぞれ構成図を作図してみた結果を踏まえつつ、比較していきます。

観点	draw.io MCP Server	AWS Diagram MCP Server
提供元	JGraph（draw.io開発元）	AWS Labs
入力形式	XML / CSV / Mermaid	Python（diagrams DSL）
出力形式	draw.ioエディタ（ブラウザ）	PNG画像ファイル
編集性	◎ 生成後すぐにGUIで編集可能	▲ PythonでのPNG修正のため難解
前提ツール	Node.js（npx）	Python 3.12+, uv, GraphViz
手軽さ	◎ npxだけで即利用可能	△ Python環境 + GraphVizが必要

個人的に感じた点は以下です。

draw.io MCP Server

生成後にブラウザが起動して、GUIでサッと微調整できて便利

AWS Diagram MCP Server

PNGだけならシンプルに出力
Pythonコードで環境の構成図の管理ができるのが強み

まとめ

draw.io MCP Serverのリリースにより、LLMを使った作図のワークフローがかなり便利になったと感じます。

今回試してみて感じたことは、3つあります。

まず、画像解析から文章化について、既存の構成図をLLMに渡すだけで、正確なドキュメントが生成できました。構成図のドキュメント化や、他の方が作成して遺した図（≒負の遺産）の理解にも活用できそうです。また、開発フェーズに限らず、運用フェーズで新規参画したメンバーの既存環境の理解を深めるためにも活用できそうです。

次にdraw.io MCP Serverについてですが、生成後にそのままdraw.ioで編集できる手軽さが非常に魅力です。npxだけで動くので導入のハードルも低いと感じました。作図の際の私のMCP Serverのスタメン入り確定です。

最後にAWS Diagram MCP Serverについて、AWS公式アイコンをしっかり使いPythonコードでの管理の親和性が強みと感じました。Pythonコード化されるので、CI/CDパイプライン上で作図することなども可能なのかな、とふと思いました。

個人的には、今後はdraw.io MCP Serverを多用すると思います。LLMの作図に100%の完成度を求めていないのと、自動でブラウザを開いてくれてスタートラインが大きく前進するので、使わない理由はないなと感じています。MCP Serverの登場が相次いでいますが、作図の領域でもAIとの連携が進んでいることを実感しました。

なお、Githubの記載では、MCP Serverを使わずに、Claudeのプロジェクト設定に指示文を追加するだけで同様のことができる旨も記載されていました。そちらもどこかで試してみようと思います。

この記事の内容が、draw.io MCP ServerやAWS Diagram MCP Serverを試してみようとされるどなたかの参考になれば幸いです。

160

131

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up