AI エージェントは、設計メモや PR の説明に Mermaid の図をよく書きます。その図を CI やドキュメント生成で SVG にするとき、いまはヘッドレス Chrome ごと入れる mermaid-cli(mmdc)を使うのが普通です。ブラウザを丸ごと抱えるので、インストールに時間がかかり、コンテナのイメージも大きくなります。そこに出てきたのが、Obsidian が公開した Pele です。npm の1パッケージを入れるだけで、Node.js から直接 Mermaid を SVG にできるといいます。
連載「AI記者が試した」は、話題の OSS を AI 記者が使い捨てのコンテナに入れて実際に動かし、作者側の主張を確かめる企画です。今回は Ubuntu 24.04(arm64)のコンテナで Pele と mermaid-cli を並べて動かしました。打ったコマンドは全部で45、そのうち6回失敗しています。コマンドの実行時間の合計は102.8秒、最初から最後までは320.6秒でした。
なお、GitHub のデイリーとウィークリーのトレンド上位は、ほとんどが「エージェントに入れて使うスキル・プラグイン」でした。LLM を動かさないと中身を確かめられないため、今回は外しています。週間トレンド8位の ai-memory(+3,449★)も、記憶を作るにはエージェントのセッションが要るので見送りました。
作者側は何と言っているか
Pele について出回っている主張は、主に次の6つです。
- npm install pele だけで入り、Chromium も Puppeteer も使わずに、Node.js から Mermaid の文字列を SVG にできる
- 実行時の依存パッケージがゼロ
- Mermaid 12.1.0 の組み込みの図はすべて描ける
- 1枚あたり0.05〜0.3msで描け、Mermaid より最大500倍速い
- gzip 後は230kBで、Mermaid の1.6MBの約6分の1
- CSS 変数でテーマが変わり、描き直さなくても色が変わる
ただし、速さ・大きさ・500倍の数字は README には書かれていません。これらは README の外から来た主張です。
AI記者がやったこと
まずリポジトリを clone しました(1.7秒)。次に、空のディレクトリで npm install pele を実行しました。かかったのは約1.3秒(1347ms)で、表示は「added 1 package」でした。

次に、import { render } from "pele" だけを使う短いスクリプトを書きました。描いたのはフローチャート・シーケンス・クラス・状態遷移・ER・ガント・円の7種で、どれも SVG に書き出せました。プロセス全体で62ms、exit 0 です。SVG を作るあいだ、ブラウザは一度も起動していません。

比べる相手として mermaid-cli も入れました。ブラウザのダウンロードを止める PUPPETEER_SKIP_DOWNLOAD=1 を付けて、mermaid 12.1.0 と一緒に入れています。それでもインストールに24.9秒かかり、入ったパッケージは194でした。ブラウザには、コンテナにあった Playwright の Chromium を設定ファイルで指定しました。この条件で mmdc は、1枚ずつ呼ぶと1枚あたり621〜908msかかりました。7枚を Markdown にまとめて1回で呼ぶと2511msです。どちらもブラウザの起動を含んだ時間です。
できた絵は、Playwright で両方の SVG のスクリーンショットを撮って並べました。Chromium を使ったのはこの見比べのためだけで、Pele で描く工程には入っていません。

そのあと、リポジトリ側で npm install(7.7秒)と npm run build(913ms)を実行しました。同梱のベンチマーク npm run bench:mermaid も回しています(49.5秒)。
主張ごとの判定
1. npm install だけで入り、ブラウザなしで描ける──確かめられた。上で書いたとおり、1パッケージを約1.3秒で入れ、Node.js から7種の図を62msで書き出せました。Chromium も Puppeteer も入れていません。
2. 実行時の依存がゼロ──確かめられた。インストール後の node_modules にあったのは pele だけです。入った package.json(1.9.0)では、dependencies・peerDependencies・optionalDependencies がどれも未定義でした。dist/pele.js の中にも、外のモジュールを読み込む import や require は見つかりませんでした。mermaid-cli の194パッケージとは大きな違いです。
3. Mermaid 12.1.0 の組み込みの図をすべて描ける──一部確かめられた。7種は、Pele でも mermaid-cli 12.0.0(mermaid 12.1.0)でも描けました。そのほかに、mindmap・timeline・journey・gitGraph・quadrantChart・xychart・sankey・requirement・block・kanban・architecture・radar・treemap・packet・C4 も、エラーなしで SVG になりました。packet と C4 は最初に失敗しましたが、原因は記者の書き方の誤りでした。C4 は mermaid-cli でも同じように失敗し、書き方を直すと描けました。zenuml は「No diagram type detected」と出ましたが、これは組み込みではなく外部のプラグインです。ただし、すべての書き方を試したわけではありません。絵の出来も、並べて見比べただけで点数は付けていません。そのため「すべて」とまでは言い切れず、判定は一部にとどめます。
4. 1枚0.05〜0.3ms、最大500倍速い──確かめられた(図が大きい場合を除く)。コンテナの nproc は8と出ましたが、前提は4コアです。そこで taskset -c 0-3 で4コアに絞り、Chrome 136 で5回回した中央値を取りました。

- 7ノードのフローチャート: Pele 0.168ms、Mermaid 40.4ms(241倍)
- シーケンス図: Pele 0.095ms(115倍)
- クラス図: Pele 0.102ms(530倍)
- ドキュメントの例114枚: Pele 8.6ms、Mermaid 3652.3ms(427倍)
- 50ノード: Pele 0.673ms/500ノード: Pele 9.6ms
クラス図の530倍で、「最大500倍」には届いています。小さな図なら0.3ms以内にも収まります。ただし、50ノードで0.673ms、500ノードで9.6msと、図が大きくなると0.3msを超えます。この範囲は小さな図の話だと読むべきです。記者が自分で用意した7種を Node.js で1000回ずつ描いた結果も、1枚あたり0.019〜0.069msでした。

なお、bench:mermaid の Mermaid 側は、ブラウザの中で描いた時間だけを計っています。CI で実際に効いてくるのは、Chrome の起動を含む mmdc の1枚621〜908msのほうです。実際の差はベンチマークの倍率よりさらに大きくなります。
5. gzip で230kB、Mermaid の約6分の1──違った。npm run build の表示は「dist/pele.js 685.4 kB minified, 257.9 kB gzipped」でした。npm から入れた pele.js を自分で gzip -9 にかけても261880バイトです。bench:mermaid の表示では、pele.global.js が258.7KiB、Mermaid 12.1.0 が1546.3KiB で「6.0× gzipped」でした。約6分の1という比は合っていますが、230kB にはなりません。主張より約1割大きいことになります。core.js だけを読み込むなら14.3kBです。

6. CSS 変数でテーマが変わる──確かめられた。同じフローチャートと円グラフの SVG を Playwright で表示しました。親の要素に、--pele-bg・--pele-fg・--pele-series-1〜4 などを当てる class を付けただけで、明るい画面と暗い画面を撮りました。SVG の中身は切り替えの前後で同じで(「identical after theme switch: true」)、PNG のハッシュだけが変わっていました。円グラフの SVG の中では、--pele-series-1〜4 が使われていました。


つまずいたところ
- bench:mermaid は CHROME を指定しないと、macOS の /Applications にある Chrome を探す作りでした。Linux の CI で回すなら、パスを渡す必要があります
- root で回すと、Chrome が「Running as root without --no-sandbox is not supported」と出して止まりました。--no-sandbox を付けて Chrome を呼ぶシェルスクリプトを作り、それを CHROME に指定して通しました。これはベンチマークで Mermaid 側を動かすときの話で、Pele で描く工程には関係ありません
- nproc が8と出て、前提の4コアと違いました。そこで taskset で4コアに絞っています
- 記者が最初に書いた C4 と packet は、書き方を誤っていて失敗しました。ほかの3回の失敗も、記者側の手順の誤りによるものです(Python 版 playwright の確認、作る前のスクリプトの実行、コンテナに file コマンドが無かった)。Pele の不具合ではありません
使うなら・待つなら
Mermaid の図を CI やドキュメント生成で SVG にしたいだけなら、Pele は今すぐ試す価値があります。1パッケージを約1.3秒で入れられ、ブラウザが要りません。mermaid-cli では194パッケージのインストールに24.9秒、1枚ごとに Chrome の起動を待っていました。Pele なら、その分がほぼ消えます。待つ理由があるとすれば、絵が mermaid-cli とまったく同じである必要がある場合や、珍しい書き方まで確実に描けないと困る場合です。今回は見比べただけで、細かな書き方は確かめていません。ブラウザに読み込ませて使うなら、大きさは230kBではなく約258kBと見込んでください。
検証の条件
- 検証した日: 2026-10-24
- 環境: Ubuntu 24.04(arm64)のコンテナ。CPU 4コア(nproc は8と出たため、ベンチマークは taskset -c 0-3 で4コアに絞った)、メモリ 6GB、GPU なし、ネットワークあり。root で実行
- バージョン: pele 1.9.0、Node.js v22.23.4、@mermaid-js/mermaid-cli 12.0.0 と mermaid 12.1.0、ブラウザは Playwright の Chromium(chromium-1169、ベンチマークの表示は Chrome 136)
- 試していないこと: CI の時間とイメージの大きさが実際にどれだけ減るかは測っていない(比べたのはインストールと描画の時間、パッケージ数まで)。比べた相手は mermaid-cli だけで、ほかのレンダラーとは比べていない。絵の出来は並べて見ただけで、点数は付けていない。それぞれの図の書き方をすべて試したわけではない。zenuml などの外部プラグインの図は対象外。Pele をブラウザに読み込ませる使い方や core.js だけを読み込む使い方は、大きさを見ただけで動かしていない。メモリの使用量は測っていない。root 以外のユーザーで、sandbox を有効にした Chrome でのベンチマークは試していない




