はじめに
前回の記事から約2か月は経過したでしょうか。
ずっと書こうとしていたネタ？を公開できる日がやってきました。
そうそう、最初に言っておきますが、作文にはAIの力を借りてます( ｰ`дｰ´)ｷﾘｯ
背景
ここ最近、エンジニアや開発者のタイムラインで「draw.io（diagrams.net）のMCPサーバー」がやたらと話題になっています。
Model Context Protocol（MCP）の登場によって、LLMが生成したXMLデータを直接draw.ioに投げ、ブラウザ上で即座に視覚化できるURLを発行するフローが確立されたことが発端です。X（旧Twitter）を眺めていても、「業務レベルで実用できる！」「神ツールが来た」といった興奮気味のポストが目立ちます。
これまではLLMにコードを書かせて、それをコピペして描画ツールに貼り付ける…という地味な手間がありましたが、それが自動化されたインパクトは確かに大きいでしょう。あるユーザーが「試作段階でここまで出来るなら本番投入も近い」と評価するように、ワークフローの効率化に対する期待値は最高潮に達しています。
しかし、この熱狂を一歩引いて観察すると、ある奇妙な現象が見えてきます。
その元となったXのポストはこちらです。
概要
結論から言うと、現在起きている絶賛の嵐の一部は、技術的な実態を伴わない「プラセボ効果」に近いものではないかと感じています。
実はこのMCPそのものは、あくまでデータを圧縮して受け渡すためのプロトコル（通信規約）に過ぎません。MCPサーバー自体が、図のレイアウトを美しくしたり、構成図の正確性を高めたりしているわけではないのです。描画のクオリティを決定づけているのは、あくまでその裏側にいるClaudeやGPTといったLLMの能力です。
それなのに、なぜ多くのユーザーが「MCPを導入したら図の作成能力が劇的に上がった」と錯覚するのでしょうか？
これは、MCPという「新しいツール」への期待値バイアスと、ユーザーがAIでの作図から離れていた期間の技術進化が偶然重なったことで生まれた、集団的な思い込みである可能性が高いのです。
内容
1. コードレベルでの確認
実際のdraw.io MCPサーバー（@drawio/mcp v1.1.0）のコードを確認してみましょう。
公式説明文の問題点
npmパッケージの説明文自体が誤解を招く表現になっています。
Import CSV data: Convert tabular data to diagrams
Render Mermaid.js: Transform Mermaid syntax into editable draw.io diagrams
これらの表現は、あたかもMCPサーバー自体が「変換」や「レンダリング」を行っているかのように読めますし、この公式文書の曖昧さが、ユーザーの誤解を助長している可能性がありそうです。
依存関係の分析
json{
"dependencies": {
"@modelcontextprotocol/sdk": "^1.0.4",
"pako": "^2.1.0"
}
}
依存関係を調べてみると、グラフレイアウトや最適化を行うライブラリ（graphlib、dagre、elk等）が一切含まれていないという点です。存在するのは以下のようなライブラリのみです。
- @modelcontextprotocol/sdk: MCPプロトコルの通信のみを担当
- pako: zlibベースのデータ圧縮ライブラリ
実際の処理フロー
公式ドキュメントに明記されている通り、MCPサーバーが行う処理は以下の通りです。
- The MCP server receives diagram content (XML, CSV, or Mermaid)
- Content is compressed using pako deflateRaw and encoded as base64
- A draw.io URL is generated with the #create hash parameter
ここを見る限りでもMCPサーバーは図のクオリティに一切関与していません。単純なデータ圧縮と転送を行うだけのユーティリティであることが分かります。
2. 「空白期間」に起きていたLLMの進化
ユーザーが「MCPのおかげで図が良くなった」と感じる最大の要因は、 「かつてLLMで作図を試みて挫折し、離れていた期間」 にあると考えています。
多くの人は、過去（例えばGPT-4初期やそれ以前）に構成図を書かせようとして、崩れたレイアウトや謎の構文エラーに直面し、「まだ実用的じゃないな」と見切りをつけた経験があるはずです。この「諦めムード」が漂い、構成図の生成から離れていた期間から、draw.io MCPが登場した最近までの間に、水面下でLLMの基礎能力は飛躍的に向上していました。
Opus 4.6 や ChatGPT 5.2 のようなモデルに進化したことが本質であり、MCPはその進化した出力を、久しぶりにユーザーの目の前に「手軽に」差し出したに過ぎないのです。
3. 「自動化」が生む心理的バイアス
人は「手間が省かれて結果が即座に表示される」と、その成果物の質まで高く評価してしまう傾向があるのではないでしょうか。
「テキストで指示→即座に綺麗な図が表示される」という体験は、まさに魔法のような快感を与えます。このUXの良さが、図の内容そのものの評価を底上げしてしまっているのです。医療におけるプラセボ効果と同様に、「最新のMCP環境を使っているのだから、良い結果が出るはずだ」という期待が、目の前の図を実際以上に良く見せている側面は否定できません。
終わりに
もちろん、MCPが無意味だと言いたいわけではありません。ワークフローを効率化し、思考を止めることなく試行錯誤できる環境を提供してくれる点は、間違いなく素晴らしい技術進歩です。
ただ、私たちが意識すべきなのは、「魔法の杖」の正体を正しく理解することです。
新しい技術トレンドに乗る楽しさを味わいつつも、「これはツールの力か？ それともモデルの進化か？」と冷静に問いかける視点を持つこと。それこそが、プラセボに惑わされずにAIを実務で使いこなすための第一歩になるはずです。
一言
MCPは単なる受け渡しですが、CSV形式だけはdraw.ioのサーバーサイド処理に依存する場合があるため、XMLやMermaidと同じ扱いとは言い切れないという補足も念の為ここでしておきますね。
最後に、AIを活用してガンガン業務をこなす日々を過ごしていると、AIという名の武器のブラッシュアップが難しくなってきます。少しでも新しい情報をキャッチアップしながら自己を磨いていきたいものです。