draw.io MCPとは｜公式サーバーの7ツールと常駐24,665トークンを実測、図はURLで渡る

draw.io MCP は、AIエージェントに作図をさせるための draw.io 公式（jgraph）のMCPサーバーです。ただし「サーバーが図を描いて返してくれる」ツールだと思って導入すると動作モデルを見誤ります。実際に起動して確かめたところ、図のデータは圧縮されてブラウザのURLに載り、既定ブラウザが開かれるという作りでした。本記事では v1.5.0 を実際にインストールし、7つのツール定義を取得したうえでうち5つを実際に呼び出し、ツール定義だけで24,665トークンを消費すること、どのツールがヘッドレス環境で動くのかまでを確かめています。

MCPサーバーの仕組みそのものや自作の手順は、MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルにまとめてあります。本記事は「既にある公式サーバーを繋ぐ側」の話です。

draw.io MCPとは——公式が出しているMCPサーバー

draw.io MCP は、MCP（Model Context Protocol）クライアントから draw.io の作図機能を呼べるようにするサーバーです。実装は draw.io の開発元である jgraph が公開しており、非公式のサードパーティ実装ではありません。

依存が2つだけというのは、この種のツールとしてはかなり小さい部類です。ただし実際に npm install すると96パッケージ・28MBになります。差分は MCP SDK の推移的依存で、パッケージ本体（展開後744KB・ファイル17個）は非常に小さいままです。

「draw.io で作図する」という需要に対して、MCP以外の選択肢（Mermaid記法をそのまま書く、PlantUMLを使う）と比べたときの draw.io の強みは、出来上がった図を人間がGUIで手直しできることです。この点は後述する動作モデル（ブラウザで開く）と直結しています。

7つのツールの中身と、動作条件の分かれ目

サーバーを stdio で起動して tools/list を投げ、返ってきた定義を全部数えました。7ツールです。

※ 印の2つは呼び出しておらず、ソース読みからの判定です。 実際に呼んだのは open_drawio_mermaid / list_pages / get_page / set_page / search_shapes の5つで、open_drawio_xml と open_drawio_csv については「3つの open_ 系がソース上まったく同じ openBrowser(url) の呼び出しに合流している」ことを確認したうえでの推定です。実測と推定を混ぜないため明示しておきます。

この分割が実務上いちばん重要な情報です。 open_ で始まる3つは既定ブラウザを起動するので、GUIのないサーバーやCIコンテナでは機能しません。残り4つはファイルとローカルの図形ライブラリだけで完結するため、ヘッドレスでも動きます。

実際にブラウザなしの環境で list_pages / get_page / search_shapes / set_page を呼び、すべて正常に応答することを確認しました。search_shapes に database を投げると、ER図のエッジスタイル（edgeStyle=entityRelationEdgeStyle;...endArrow=ERzeroToOne; など）が実際の draw.io スタイル文字列として返ってきます。AIが「それらしいスタイル文字列」を捏造するのではなく、実在する図形定義を引けるのがこのツールの役目です。

常駐コストは24,665トークン

MCPサーバーの隠れたコストは、ツール定義がコンテキストを占有し続けることです。tools/list の応答本体を計測しました。

7ツールで24,665トークンは、ツール数に対してかなり大きい値です。理由は定義を読むとわかります。open_drawio_xml の引数説明には mxGraph のXML記法のガイドが、open_drawio_mermaid には Mermaid の構文ヒントが、それぞれ長文で埋め込まれています。とくに libavoid ルーティングのオプション説明は1つで数百文字あり、「障害物を避ける直交配線を行い、頂点の位置は保ったままコネクタだけ再計算する」といった使い分けまで書かれています。

LLMに正しい記法を書かせるための投資なので無駄ではありませんが、接続している間ずっと掛かる固定費であることは意識しておく必要があります。参考までに、同じ手法で計測した Notion MCPとは｜ホスト版とローカル版の違いを24ツール・21,831トークン実測で解説は24ツールで21,831トークン、Chrome DevTools MCPとは｜使い方と既定29ツールの中身・Playwright MCPとの違いは29ツールが既定です。draw.io MCPは「ツール数は少ないが1ツールあたりが重い」タイプだと言えます。

図はどこへ行くのか——URLフラグメントで渡る

open_drawio_mermaid を呼んだときに実際に何が起きるかを、open コマンドを差し替えて捕まえました。渡された引数はこれです。

https://app.diagrams.net/?grid=0&pv=0&border=10&edit=_blank#create=%7B%22type%22%3A%22mermaid%22%2C%22compressed%22%3Atrue%2C%22data%22%3A%22S8vJL0...%22%7D

3ノードのMermaidに対して280文字のURLでした。構造を分解すると次のようになります。

・ベースURL は既定で https://app.diagrams.net/。環境変数 DRAWIO_BASE_URL で差し替え可能
・図のデータは JSON にまとめ、pako で deflate 圧縮して Base64 化されている（"compressed":true）
・そのデータが置かれるのは # 以降のフラグメント部
・起動方法は macOS が open、Linux が xdg-open、Windows が cmd /c start

日本語の図はURLが17〜19%長くなる

ここに日本語固有の話が1つあります。ラベルが日本語だと、圧縮後のURLが英語より長くなります。同じ構造のフローチャートでラベルだけを入れ替えて実測しました。

これが効いてくるのは Windows です。ソースには次のコメントとともに定数が置かれています。

Longest URL the Windows shell opens reliably from a .url file: the InternetShortcut handler fails with Win32 error 122 beyond INTERNET_MAX_URL_LENGTH (2083), so stay under it with some headroom.

実際の閾値は 2,000文字で、これを超えると一時HTMLページ経由の代替経路に切り替わる作りになっています。上の実測を外挿すると、2,000文字に達するのは日本語で約110ノード、英語で約130ノードあたりです。日本語の図のほうが約15%早く代替経路に入る計算になりますが、どちらもフォールバックが用意されているので図が開けなくなるわけではありません。 挙動が変わるポイントとして把握しておけば十分です。

インストールと接続の手順

1. MCPクライアントに登録する

Claude Code なら次の1行で追加できます。パッケージを事前に入れる必要はありません。

claude mcp add drawio -- npx -y @drawio/mcp@latest

自社ホストの draw.io を使う場合は環境変数を添えます。

claude mcp add drawio --env DRAWIO_BASE_URL=https://drawio.example.com/ -- npx -y @drawio/mcp@latest

2. 接続できているかを確認する

登録後、ツールが実際に見えているかを確認します。7つ出れば成功です。

claude mcp list

3. ローカルファイルの読み書きを試す

ブラウザを開かずに動作確認したいときは、.drawio ファイルを対象にしたツールから試すのが確実です。実測では、ページ名を 工程図、ノードのラベルを 新しいラベル にした日本語入りのファイルで set_page → get_page の往復を行い、文字化けなく書き戻せることを確認しました。list_pages の応答にはページ名とおおよそのバイト数が含まれ、大きなファイルでも全体を読み込まずに構造を把握できます。

他の作図手段と比べてどこが違うのか

「AIに図を描かせる」手段はいくつかあります。draw.io MCP がどの位置にあるかを、実務上の判断軸で並べます。

draw.io MCP だけが「編集可能な図」を成果物にします。 Mermaid や PlantUML はテキストが正で、レイアウトの微調整は原理的にできません（エンジンの自動配置に従うしかない）。画像生成AIは見た目の自由度こそ高いものの、1ピクセルの修正もできず作り直しになります。

一方で、その柔軟性の対価が24,665トークンの常駐コストとブラウザ依存です。「READMEに載せる小さなフロー図」であれば Mermaid のほうが圧倒的に軽く、MCPを挟む理由がありません。当サイトが記事内の図に Mermaid を使い続けているのも同じ判断です。

判断の分かれ目は成果物を誰がどう引き継ぐかにあります。図が最終的に人間の手で更新され続けるなら draw.io、コードと一緒にバージョン管理されて機械的に再生成されるなら Mermaid、という切り分けが実態に合います。

.drawio 資産があるなら list_pages の設計が効いてくる

既存の .drawio ファイルを扱う場合、list_pages の応答設計が地味に効きます。実測した応答はこの形でした。

[
  {
    "index": 0,
    "id": "p1",
    "name": "ページ1",
    "approxSizeBytes": 314
  }
]

ページの中身ではなく、名前とおおよそのバイト数だけを返します。 数十ページある大きな構成図でも、まず一覧を取ってから必要なページだけ get_page で読めるので、コンテキストを無駄に埋めません。MCPサーバーの設計としては素直ですが、「ファイル全体を読ませてから考える」やり方に比べると差が出るところです。

なお、この一覧・読み取り・書き戻しの3ツールはブラウザを使いません。CIから構成図を機械的に更新するという使い方であれば、open_ 系を一度も呼ばずに完結します。

何に向いていて、何に向いていないか

実測を踏まえた使いどころの整理です。

向いている用途

・AIに下書きを描かせて人間が仕上げる。ブラウザで開いた時点で編集可能なので、GUIでの手直しが前提の運用に合う
・既存の .drawio ファイルを機械的に更新する。get_page / set_page はブラウザ不要で、CI から構成図を自動更新するような使い方ができる
・正しい図形スタイルを引く。search_shapes は実在する図形定義を返すので、AIが存在しないスタイル名を書く問題を避けられる

向いていない用途

・画像ファイルの生成。PNGやSVGを直接吐くツールは無く、あくまで「エディタを開く」までが担当範囲
・ヘッドレス環境での作図。open_ 系3ツールはブラウザが要る
・常時接続したい構成。24,665トークンの固定費は軽くない。作図するセッションでだけ有効にするほうが合理的

まとめ

・draw.io 公式のMCPサーバー（jgraph/drawio-mcp・★5,306・Apache-2.0）。npm は @drawio/mcp v1.5.0、直接依存はわずか2つ
・ツールは7つ。うち3つ（open_drawio_xml / csv / mermaid）はブラウザ必須、4つ（list_pages / get_page / set_page / search_shapes）はヘッドレスで動く
・常駐コストは24,665トークン（53,780バイト）。ツール数は少ないが定義に記法ガイドが長文で入るため重い
・図はURLのフラグメントに圧縮して載る。サーバーへは送信されないが、エディタ本体の取得通信は発生する。閉じた環境では DRAWIO_BASE_URL を使う
・日本語ラベルはURLが17〜19%長い。Windowsの2,000文字閾値には日本語で約110ノード、英語で約130ノードあたりで到達する（超えても代替経路あり）
・postinstall はCDNから配線用JSを取得するが、ブロックしても壊れない設計。取得時点では実行せず検査のみ

「AIが図を描く」と聞いて想像する挙動と、実際の動作モデルはかなり違います。サーバーは図を組み立ててURLに詰め、開くのはブラウザ——ここを掴んでおけば、動かない理由もデータの流れも自分で判断できます。

参照ソース

• jgraph/drawio-mcp — GitHub（公式リポジトリ。star数・ライセンス・更新状況は2026-08-29 にAPIで取得）
• @drawio/mcp — npm（バージョン履歴・依存関係。2026-08-29 確認）
• Model Context Protocol 公式サイト（tools/list などプロトコルの一次情報。2026-08-29 確認）
• 本記事の実測環境: @drawio/mcp v1.5.0 / Node.js v22.13.1 / npm 11.1.0 / macOS (Darwin 23.5.0, arm64)。ツール呼び出しは stdio 経由の JSON-RPC を直接送って計測