【検証】LLM時代に最適な作図ツールをトークン効率で考える

みんな何使ってる！？LLM時代の作図ツール戦争

僕らの共通のフラストレーション

ドキュメントに図を描く時、みんな正直どれ使ってる！？ Mermaid？ PlantUML？ それとも結局 draw.ioを起動してる？ なあ、正直に言ってくれ！教えてくれ！！ あ、使い分けつつやってる、そっか…。 で、話は終わりません。エンジニア(仮)たるもの。わからんけど、そういう気持ち大事なのかなって。

開発者が抱える共通の課題は、常に 「手軽さ」と「表現の自由度」 のトレードオフです。 良い楽をしたい、ですよね…。

• Mermaid.js: 手軽さは神。GitHubやZennでも使える。でも、複雑になると線がクロスする問題、ノード配置の自由度の低さにイライラしないでしょうか？私の気が短いだけですかね。
• draw.io (XML): 機能は最強。理想の図が描ける。でも、Gitに入れたら差分が地獄。何より起動が重い…。PCのスペックとかも多少はあると思いますが、そもそもの既存ファイルの場合、ものによっては、普通にトイレ行って戻って来てもまだ開くの頑張ってる…とかないです？

実際、Zennコミュニティでも、Mermaidで長い図表を書いた際に「テキストの折り返しやノードの位置調整ができない」といった、レイアウトの限界に関するお話が上がっています。

zenn.dev 長すぎるMermaidの図表を修正する方法

私もMermaidは好きですが、特有のあの 「線のクロス」 がマジで嫌で、何度も他のツールに迷走しつつ生きてます。 「線のクロス」って何を言ってるんだってなるかもなので、、、 ▼線のクロスサンプル画像

こういうのです。意図的に複雑にしていますし、まあって感じなんですけどね。 コードで反映にしようかなって最初コードで書いてたんですけど、私へのダメージがありましたので、画像で失礼します。 でもこうならざるを得ないって結構あるあるなんじゃないかなあ、書き方の工夫で補える部分もあるとは思いますが全体図とか、アーキテクチャが複雑になると避けにくいよなあ、と。

LLMに「優しい」図の言語を考えたい

しかし、まあ昨今のAIというかLLMを考えて少し立ち止まる。 この時代、本当に見るべきは「見た目の美しさ」とか「人間都合の使い勝手が良い」だけじゃないよなと。

作図ツールは、もはや人間が手で描くためのものだけでなくなってますし。AI（LLM）に指示して生成・編集させるためのインターフェースにもなってるんだよな、と。 AIワークフロー組んでやってもらう、とかも出来るでしょうし(これまだ実験してないけど多分出来るでしょっていう)

この視点に立つと、ツールの良し悪しを決める基準が変わります。大事なのは見栄えの良さ よりも、LLMにとっての『優しさ』、すなわち『効率性』 への意識も必要だよな、改めてと思った次第です。これからの時代考えるとどうしてもね。

本記事では、このLLM時代にどんだけ優秀なものが出ても選定基準の1つであるトークン効率というデータで、最適な作図ツールを探っていくことにします。

1. AI時代のコストとトークン効率

1-1. JSON/XMLの「冗長性」がLLMの敵である

なぜ、直感的に使いやすいExcalidraw（JSON）やdraw.io（XML）は、LLM時代に不利なのか？をまず考える。

結論から言えば、その冗長性です。 人間にとっては直感的なGUI操作でも、裏側のデータは非常に複雑で、無駄な情報が多い。リッチになるとそうなるのもわかる。

• XML（draw.ioなど）: 図の見た目に関係ないメタデータが膨大。LLMがこれを解釈・編集するのは効率が悪すぎます。やれなくはないんですけどね、全然。
• JSON（Excalidrawなど）: 要素の位置、サイズ、スタイルといった詳細な情報が大量に定義され、トークンを爆食いします。

1-2. データで見てみる作図形式別「推定トークン消費量」

単純なシーケンス図を各形式で表現した場合の推定トークン数を比較しました。これはそのままAI処理のコストと速度に直結しますしね。

あくまでも単純なシーケンス図での比較なので、トークン数は推定ってところですが結構露骨です。

わかること: XML/JSONはMarkdown-like形式に比べ、最大$24$倍以上のトークンを消費します。この圧倒的な効率差が、LLM時代の作図ツールの優劣を決定づけます。

実際、今年の頭のLLM研究の発表においても、Knowledge Graph（MermaidやPlantUMLのような構造化）を活用したRAG（検索拡張生成）システムは、従来のテキストベースのRAGに比べてトークン使用量を大幅に削減（例：80%減）できることが示されています。

aclanthology.org GraphRAG: Leveraging Graph-Based Efficiency to Minimize Hallucinations in LLM-Driven RAG for Finance Data

この研究は、「情報を構造化された簡潔な形式でLLMに与える」ことが、どれだけ効率とコスト改善に寄与するかを裏付けています。

2. 「効率」 vs. 「表現力」

2-1. LLM親和性 vs. 表現の自由度

結局、作図ツールは 「LLM親和性（効率）」 と 「表現の自由度（見た目の美しさ）」 の厳しい二者択一を迫られます。

• Mermaid/PlantUML（テキストベース）: 生成の容易さやトークン効率で高得点。
• Excalidraw/draw.io（構造化データ）: 表現の自由度では圧倒的。

両者のテキストベースツールにも違いがありますので、一概にこれが最強で安牌だとはならないことは理解しています。MermaidはJavaScriptベースでウェブブラウザでの利用が容易ですが、PlantUMLはUML図全般をカバーし、より複雑な図表を作成可能ですし。

ones.com MermaidとPlantUMLの対比：図表作成ツールの王者対決！どちらが開発効率を上げるか

つまり、 「迅速な情報共有が必要な場合はMermaidが、詳細なUML図が必要な場合はPlantUMLが適している」 という使い分けがZenn内でも言及されています。

zenn.dev Mermaid記法とPlantUMLを比較する、どちらを採用すべきか？

というか、GitHub上で、プレビュー・共有ができるので、Mermaid記法に軍配が上がりそう。ってのめっちゃわかります。私もそう思う。だがしかし、でもでもだってをしてしまう私もいる。

2-2. Mermaidの「線のクロス問題」はトレードオフ

私が最も個人的に不満に思っていたMermaidの欠点（線のクロス問題）を再評価します。 Mermaidのレイアウトの自由度が低いのは、Mermaidが　自動配置エンジンを採用しているから。

• メリット: 人間もLLMも、ノード間の関係性（エッジ）だけを記述すれば、自動で整頓してくれる。
• デメリット: 人間が理想とする「線がクロスしない」などの細かい意図を反映しにくい。

結論: Mermaidは、LLMにとって最も理解しやすい 「構造」を優先するために「見た目の美しさ」の一部を意図的に放棄しています。線のクロスは、AIによる効率的なドキュメント管理という大きなメリットと引き換えに、受け入れるべき最小のトレードオフなのかな、というのが個人的な落としどころです。 技術者同士だと、見慣れたもんだけど、顧客資料への理解の為で、全体図欲しいとか言われることもあるのでそうなると、いけるか…いけるのか？！って定期的に思います。 対非エンジニアだと大体「うわ」とかのリアクションが新鮮まであります。 「システムってこんなに複雑なんだね～」とか柔らかい感想？をくれる非エンジニアのえらい人は、優しさを感じます、勝手に。 そのままの柔らかい人でいてくれ…と思ったり。

3. LLM時代における作図ツールの最終結論

まとめると、LLM時代に最適な作図ツールは、目的によって明確に使い分ける、にはなってしまう。 適材適所のいつものですね。

今後、AIが生成するコードやドキュメントの中で、Mermaidのような トークン効率が良く、構造が単純な「図の言語」 が標準化していくのは必然です。というか多分そうなる。かもしれない、の域を出ませんが。世迷言かもしれないです。 各主流のAI達(ChatGPT、Gemini、Claude)に「それぞれの記法で出力してほしい」のような指示してもそこそこの打率のものを返してくれます。やっぱり完全に毎回OK!っていうものは出してくれませんが。 時折生成を頑張ってくれている間に重くて固まってるとか、それこそ書きたいものによって色々あったりしますけど。 LLMモデルの学習元の開示は基本されないので断定は出来ませんが、基本的にはやれている事を確認済みなので、めっちゃ自分で書くのは嫌だなって感じの複雑なやつはベースとして作ってもらって微修正しよ、くらいのは全然もう出来ますし最近そういう使い方をしてます。 ※複雑アーキテクチャ系はしんどいのは変わらなかったけど！！

今からAIにとっての優しいデータ形式に慣れておくこと、知っておくことは良いのかもな、と思います。 あなたのプロジェクトで最適なパレットを選ぶ際の参考になれば幸いです。