AsciiDocで図を描くたびにKrokiサーバーを立てるのは本当に必要か？

開発したもの

VSCode拡張機能

asciidoctor.js 拡張機能

AsciiDocで設計書や技術文書を書いていると、PlantUMLやMermaidなどの図表を使いたくなることがあります。

例えば PlantUML なら、

[plantuml]
----
Alice -> Bob : Hello
----

Mermaid なら、

[mermaid]
----
graph TD
A --> B
----

のように記述できます。

最近では Kroki を利用することで、PlantUML、Mermaid、Graphviz、D2 など様々な図表ツールを統一的に扱えるようになりました。

私も Kroki は素晴らしいプロジェクトだと思っています。

しかし使っているうちに、ある疑問を持つようになりました。

図を描くために、なぜサーバーが必要なのだろう？

---

Krokiはとても便利

まず誤解のないように言うと、私は Kroki が好きです。

Kroki の魅力は、

• PlantUML
• Mermaid
• Graphviz
• D2
• Vega
• Excalidraw

など多数の図表エンジンを、

統一されたインターフェースで扱えることです。

AsciiDoc 側から見ると、

[plantuml]
----
...
----

も

[mermaid]
----
...
----

も同じ感覚で扱えます。

これは非常に大きな価値です。

---

しかし、Krokiを使うとサーバーが登場する

Kroki の一般的な利用方法では、

AsciiDoc
 ↓
Kroki Server
 ↓
PlantUML / Mermaid
 ↓
SVG

という流れになります。

公開されている Kroki サーバーを利用する場合もありますし、

セキュリティ上の理由から Docker で自前の Kroki サーバーを立てる場合もあります。

どちらにしても、

図を描くためにサーバーが必要

になります。

---

社内文書では意外と面倒

業務で扱う文書は、

• システム構成図
• ネットワーク構成図
• アーキテクチャ図
• 顧客向け提案資料

などが含まれます。

そのため、

• 外部サーバーには送りたくない
• 社内ネットワークだけで完結させたい
• オフライン環境でも使いたい

という要求がよくあります。

その結果、

docker run ...

で Kroki サーバーを立てたり、

CI 用に Kroki コンテナを準備したりすることになります。

もちろん可能です。

しかし私は、

PlantUMLを描きたいだけなのに、なぜサーバー運用をしているのだろう？

と思うようになりました。

---

実はPlantUMLもMermaidもローカル実行できる

考えてみると、

PlantUML は単体で動きます。

Graphviz も動きます。

Mermaid CLI もあります。

D2 もあります。

つまり、

PlantUMLソース
 ↓
PlantUML
 ↓
SVG

は元々可能です。

レンダリングエンジン自体はサーバーを必要としていません。

---

Krokiの本質はHTTP APIではないと思う

ここで気付いたのですが、

私が Kroki に価値を感じているのは、

HTTP API ではありません。

価値を感じているのは、

多数の図表エンジンを統一的に扱えること

です。

AsciiDoc 側から見れば、

PlantUML でも Mermaid でも D2 でも、

同じように扱える。

これが Kroki の本質ではないかと思っています。

---

ならば、埋め込めるのでは？

そこで考えたのが、

Kroki の抽象化はそのままに、

サーバーだけなくせないか？

ということです。

つまり、

AsciiDoc
 ↓
Embedded Kroki
 ↓
Local Renderer
 ↓
SVG

という構成です。

サーバーはありません。

HTTP通信もありません。

しかし利用者から見ると、

Kroki を使っている時とほぼ同じ感覚で図表を扱えます。

---

asciidoctor-kroki-embedded を作っています

この考え方を形にしたくて、

を開発しています。

目標は、

「Kroki の利便性を維持したまま、サーバーを不要にすること」

です。

---

期待しているメリット

セットアップが簡単

Kroki サーバーを立てなくてよい。

Docker も不要。

---

オフラインで動く

飛行機の中でも動く。

閉域網でも動く。

---

CIがシンプルになる

追加サービスを起動する必要がない。

---

長期保守しやすい

外部サービスの停止や変更の影響を受けにくい。

---

まとめ

Kroki は非常に優れたプロジェクトです。

私は Kroki を置き換えたいわけではありません。

むしろ、

「様々な図表エンジンを統一的に扱う」

という Kroki の思想が好きです。

ただ、

AsciiDoc ユーザーとしては、

図を描くためにサーバーは本当に必要なのか？

という疑問もありました。

そこで、

Kroki の利便性は維持しつつ、

サーバーを不要にする方法を模索しています。

同じように

• AsciiDoc を使っている
• PlantUML や Mermaid を使っている
• Kroki は便利だと思う
• でもサーバー運用はしたくない

という方がいたら、ぜひ意見を聞かせてください。