はじめに
ある日、Telegram で OpenClaw にこうお願いしました。
「このシステムの構成図を作って」
返ってきたのはこれ。
[User] → [Gateway] → [Agent]
├── [MCP-1]
└── [MCP-2]
...うん、正確なんだけど。会議で使える図がほしいんですよね。
AI アシスタントを日常的に使っていると、テキストの壁にぶつかる瞬間があります。情報は正確だけど、見せる力が足りない。プレゼンに貼れない。あとから編集できない。
この課題を解決するために、draw.io MCP Server を OpenClaw に統合しました。自然言語で頼むだけで、本格的なダイアグラムが出てくるようになった話です。
何が変わったのか
統合前の2つから、3つの MCP サーバー体制へ。黄色が今回追加した draw.io MCP。
Before: 「構成図を作って」→ ASCII アート（編集不可、見栄え△）
After: 「構成図を作って」→ draw.io で開ける本物の図（編集可能、プレゼン品質）
Telegram/Slack → Gateway → Agent → MCP Adapter → draw.io MCP → draw.io Web。破線は Browser Tool からのスクリーンショットパイプライン。
しかも、「画像で見せて」と一言添えると、チャットに図の画像が直接届きます。URL を開く手間すらない。
draw.io MCP って何？
draw.io MCP Server は、おなじみの無料ダイアグラムツール draw.io を AI から操作できるようにする仕組みです。npm パッケージ @drawio/mcp として提供されていて、サイズはたったの 13.3kB。
できることは3つ：
| ツール | 一言で言うと | 例 |
|---|---|---|
| Mermaid | テキストから図を生成 | シーケンス図、フローチャート |
| CSV | データから図を生成 | 組織図、ツリー構造 |
| XML | draw.io ネイティブで精密に | AWS 構成図、複雑なアーキテクチャ |
面白いのは URL の仕組みです。ダイアグラムの全データが pako で圧縮 → base64 エンコード → URL に埋め込み されるので、URL を開くだけで即座に図が表示されます。ファイル共有もアカウント作成も不要。URL がそのまま図のバックアップになる。
実際にやってみた
① Mermaid でシーケンス図
「OAuth2 認証フローのシーケンス図を作って」と頼むだけ。
Mermaid.js のテキストから自動変換。draw.io 上で矢印の追加や編集も自由自在。
② CSV で組織図
「CEO → CTO/CFO、CTO → エンジニア3名の組織図を作って」
自然言語の指示だけで、CSV データが生成されて階層構造に。
③ XML でアーキテクチャ図
「AWS の3層アーキテクチャ図を作って」
XML 形式なら色分け、グルーピング、スタイルまで全部コントロールできる。
3つとも 10秒以内で URL が返ってきます。そこから draw.io エディタで自由に編集できるので、AI が生成した図を叩き台にして仕上げる、というワークフローが自然にできました。
デプロイの全体像
統合作業は5フェーズ・11タスクで実施しました。前回の Sysdig MCP 統合が29タスクだったので、62% の効率化です。
Phase A（基盤検証）→ B（統合）→ C（動作検証）→ D（影響テスト）→ E（スクリーンショット）
ここからは各フェーズのハイライトを、ハマったポイントや意外な発見を交えて紹介します。
Phase A: これ、ブラウザ勝手に開くんですけど
パッケージの検証は順調でした。13.3kB という軽さ、起動時間5秒。問題なし。
MCP プロトコルの接続テストも一発成功。tools/list で3つのツールが返ってきて、「お、いい感じ」。
...と思ったら、ツールを呼ぶたびにブラウザが開く。
ソースコードを見ると、macOS では open コマンドで URL を必ず開く設計でした。最初は「これ問題じゃない？」と思いましたが、考えてみれば draw.io MCP の目的は「ユーザーがブラウザで図を編集する」こと。開くのが正解なんです。
browser tool（profile=openclaw）は別の Chrome インスタンスなので干渉しないし、URL テキストも別途返ってくる。ということで「許容」という判断。無理に抑制せず、設計思想を尊重しました。
Phase B: 設定追加、たった1エントリ
openclaw.json に追加する設定はこれだけ：
{
"name": "drawio",
"transport": "stdio",
"command": "npx",
"args": ["-y", "@drawio/mcp@1.1.2"]
}
-y は npx の確認プロンプトを自動承認するフラグで、stdio トランスポートでは必須です（プロンプトが JSON-RPC を壊すため）。@1.1.2 のバージョン固定は、Sysdig MCP で学んだ教訓そのまま。
Gateway を launchctl stop/start で再起動して30秒待つと、3つの新しいツールが認識されました。
drawio_open_drawio_xml / drawio_open_drawio_csv / drawio_open_drawio_mermaid
名前が冗長なのは toolPrefix をデフォルト（true）にしたから。既存の sysdig_* や serena_* と同じパターンで統一性を優先しました。
Phase C: 3形式とも一発成功
Mermaid、CSV、XML の3ツール全部 PASS。lightbox モードもダークモードも動作確認。レスポンスは全部10秒以内。
ここで密かに嬉しかったのは、CSV のフォーマット検証です。draw.io の CSV インポートは独自仕様（ヘッダ行でスタイル定義、parent カラムで階層定義）なのですが、OpenClaw の AI が正しいフォーマットを生成できることを確認できました。
Phase D: まさかのメモリ改善
新しいサーバーを追加すると、普通はリソース消費が増えます。Sysdig MCP（Docker、211MB イメージ）のときはメモリ制限の設定が必要でした。
draw.io MCP の統合後にメモリを確認すると...
| 統合前 | 統合後 | |
|---|---|---|
| メモリ | ~408MB | 343.5MB |
65MB 減ってる。13.3kB の npm パッケージを追加して、全体のメモリが減るとは思わなかった。軽量な MCP サーバーの追加が、OpenClaw の他コンポーネントの効率化にも寄与したと推測しています。
障害分離テストも完璧。draw.io MCP のプロセスを kill しても、Telegram の会話、Sysdig MCP、Serena MCP は全く影響なし。次にツールを呼ぶと npx が自動で再起動。
Phase E: スクリーンショットパイプライン
一番やりがいのあったフェーズです。draw.io が生成した URL を、OpenClaw の browser tool で開いてスクリーンショットを撮り、チャットに画像を送る。
7ステップで完結。エラー時は URL のみ返却にフォールバック。
ポイントは3つ：
-
profile=openclawの明示的指定が必須（targetId だけでは動かない） - レンダリング待機は6秒（draw.io の JavaScript 初期化 + ダイアグラム描画の完了を待つ）
- 使用後はタブを閉じる（Chrome のメモリリーク防止）
結果、「図を作って画像で見せて」と言うだけで、約20秒で画像がチャットに届くようになりました。
リハーサルで見つけた落とし穴
実は、本番デプロイの前に2回のリハーサルを実施しています。タスク定義書の手順を実環境で読み取り専用で検証したところ、5つの問題が見つかりました。
**一番痛かったのは「openclaw コマンドが PATH にない」**という発見。タスク定義書の9箇所で使っていたコマンドが、実環境では動かない。代わりに launchctl stop/start ai.openclaw.gateway を使う必要がありました。
macOS の timeout コマンドも未インストール。gtimeout も入ってない。background + sleep + kill という泥臭い代替手段に書き換えました。
これらは机上レビューでは絶対に見つからない問題です。「手順書を書いたから大丈夫」ではなく、「手順書を実環境で試したから大丈夫」。この差は大きい。
5つの発見事項の詳細
| ID | 重大度 | 内容 | 修正 |
|---|---|---|---|
| FINDING-001 | 🔴 重大 |
openclaw CLI が PATH にない |
launchctl 経由に全9箇所修正 |
| FINDING-002 | 🔴 重大 | Gateway 再起動コマンド未対応 |
launchctl stop/start に変更 |
| FINDING-003 | 🟡 中程度 | macOS で timeout 未インストール |
background + sleep + kill に代替 |
| FINDING-004 | 🟢 軽微 | ブラウザ自動オープンの検証方法不十分 | 定量的判定基準を追加 |
| FINDING-005 | 🟢 軽微 | ログファイル名パターン不一致 | 実環境の値に修正 |
5回のレビューで44件の指摘を潰した話
タスク定義書は v1.0 から v1.5 まで、5回の改版を重ねました。
レビューで見つかった指摘は合計44件。うち重大（CRITICAL）が4件、メジャーが16件。「toolPrefix のデフォルト値が間違ってる」「openclaw.json の entries キーが README と実環境で違う」みたいな、本番で確実にハマるやつです。
最終的に、タスク定義書は約1,400行の詳細仕様に育ち、実装フェーズでは手順書通りに実行するだけで全タスクが成功しました。
正直、「レビューとリハーサルに時間をかけすぎでは？」と途中で思ったこともあります。でも結果を見ると、デプロイ当日のトラブルがゼロ。品質を前倒しする価値はあった。
レビューサイクルの詳細
| バージョン | 指摘件数 | 主な内容 |
|---|---|---|
| v1.1→v1.2 | 21件 | toolPrefix 修正、フォーマット統一、チェックリスト追加 |
| v1.2→v1.3 | 13件 | 同時実行テスト追加、CSV フォーマット検証追加 |
| v1.3→v1.4 | 4件 | 要件トレーサビリティの補完 |
| v1.4→v1.5 | 5件 | 実環境対応（launchctl、timeout 代替） |
| 合計 | 44件 |
全テスト結果
11のテストシナリオを実施し、全テスト合格。
テスト結果の詳細
| ID | テスト | 結果 |
|---|---|---|
| T-DIO-01 | MCP Server 接続 | ✅ |
| T-DIO-02 | ツール認識 | ✅ |
| T-DIO-03 | Mermaid 生成 | ✅ |
| T-DIO-04 | XML 生成 | ✅ |
| T-DIO-05 | CSV 生成 | ✅ |
| T-DIO-06 | lightbox モード | ✅ |
| T-DIO-07 | ダークモード | ✅ |
| T-DIO-08 | 既存機能影響なし | ✅ |
| T-DIO-09 | 障害分離 | ✅ |
| T-DIO-10 | スクリーンショット | ✅ |
| T-DIO-11 | 大規模ダイアグラム | ✅ |
要件定義書の成功基準もすべてクリア：
- ツール認識数 = 3 ✅
- 呼び出し成功率 = 100% ✅
- 既存機能への影響 = 0 ✅
- スクリーンショット ≤30秒 → ~20秒 ✅
- URL 生成 ≤10秒 → ~3秒 ✅
- メモリ増加 ≤100MB → -65MB（改善） ✅
これからやりたいこと
すぐできそうなもの：
- 「見せて」「表示して」で自動的に画像送信する判定の高度化
- レンダリング完了を DOM 要素で正確に検知（現在は固定6秒待機）
- 外部 URL の Mermaid ファイルを直接ダイアグラム化
もう少し先：
- Sysdig MCP → クラスター情報取得 → draw.io MCP で構成図を自動生成
- Serena MCP → コード分析 → draw.io MCP でアーキテクチャ図を自動生成
- 生成した図の URL を自動保存して「前回の図を修正して」に対応
まとめ
draw.io MCP Server を OpenClaw に統合して、Telegram から自然言語で図を生成できるようになりました。
数字で振り返ると：
- 5フェーズ・11タスクで完了（Sysdig の29タスクから62%削減）
- 5回のレビュー・44件の指摘を反映したタスク定義書
- 2回のリハーサルで5つの落とし穴を事前に発見
- 全11テスト合格、既存機能への影響ゼロ
- メモリは増えるどころか 65MB 改善
そして、この記事の図は実際に統合した draw.io MCP で作っています。「draw.io MCP について書く記事を、draw.io MCP で作った図で飾る」というメタ構造。AI 時代のドキュメント作成、ちょっと面白くないですか？