技術記事やスライド、社内ドキュメントを書く機会が増えるほど、「書く」こと自体より「整形して、図を入れて、どこかに載せる」までの手間が気になってきます。ここ最近ブックマークして何度か読み返している、文書づくりと発信まわりの道具を 7 本まとめました。リンク先はすべて個人サイト redreamality.com のノートで、元のリポジトリや記事の要点と出典が整理されています。
紹介しているのはいずれも第三者のプロジェクトや記事で、私が作ったものではありません。感想は個人的なものです。
1. スライドを Markdown で書く：Slidev
最初は Slidev を使った発表資料づくりのノート。社内の勉強会で PPT を作る必要に迫られた筆者が、PowerPoint ではなく Slidev を選んだ話です。slides.md に拡張 Markdown で書き、コードブロックはそのまま見せられ、ページごとの見た目は HTML と CSS で調整できる。Mermaid が組み込みなので図もコードで書けますし、アニメーション用のディレクティブや @vueuse/motion もあります。PDF / PNG への書き出しに加えて、SPA としてビルドして Cloudflare Pages に置けば URL ひとつで共有できる、という流れが実践的でした。PDF ダウンロードを有効にするには download: true と Playwright（playwright-chromium）が必要、という細かい注意点も載っています。
2. ドキュメント基盤を「エージェント向け」に寄せる：Mintlify
次は Mintlify のサービス紹介をまとめたメモ。最近の Mintlify は自らを「エージェント向けのドキュメント基盤」と位置づけ、自己更新されるドキュメントを前面に出しています。導入企業として Anthropic、Coinbase、AT&T などの事例が並び、デプロイ時間の短縮やビルドの高速化といった数字が紹介されています。数字はあくまでサービス側の発表ですが、ドキュメントを読む主体が人間だけでなく AI エージェントにも広がっている、という流れを感じられる資料です。
3. Markdown を各プラットフォーム向けに一括整形：文顔（wenyan）
中国語圏で記事を配信する人には 文顔（wenyan）の概要ノート が役に立つはずです。Markdown の描画エンジンを一本化して、デスクトップアプリ、Web 版、CLI、AI エージェント連携までを同じ見た目で扱える整形・公開ツール群です。WeChat 公式アカウント、知乎、今日頭条などへのコピーや公開、ロング画像の書き出しに対応し、開発者向けには CI で一括整形して自動公開する使い方も用意されています。
4. 同じ整形エンジンを MCP から呼ぶ：wenyan-mcp
その MCP サーバー版を扱ったのが caol64/wenyan-mcp の解説メモ。Claude Desktop などのクライアントから呼び出すと、AI が書いた Markdown を WeChat 用のリッチテキストに変換し、画像やカバーもアップロードして下書き箱まで届けてくれます。「テーマを変えて」と会話で頼めるのが面白いところ。一方で、WECHAT_APP_ID / WECHAT_APP_SECRET の設定や、実行マシンの IP をホワイトリストに入れないとアップロードが失敗するといった実運用上の落とし穴もきちんとまとまっています。
5. PDF の目次（しおり）を自動生成：pdf.tocgen
地味に助かるのが pdf.tocgen についてのノート。見出しのフォント属性と位置から PDF のアウトラインを推定し、目次を生成して埋め込む Python 製 CLI 群です。pdfxmeta で見出しのメタデータを拾ってレシピを作り、pdftocgen で目次を生成、pdftocio で PDF に書き戻す、という 3 段構成。pdflatex などで作った PDF と特に相性がよく、Word や InDesign 製でも使えますが、スキャン PDF は対象外です。ライセンスがコードは GPLv3、レシピは CC BY-NC-SA と分かれている点も覚えておきたいところ。
6. 自然言語から編集できる図を作る：smart-excalidraw-next
図を描くのが億劫な人向けには smart-excalidraw-next の紹介 を。文章で説明するだけで、フローチャート、アーキテクチャ図、シーケンス図、ER 図など 20 種類以上の図を Excalidraw 形式で生成してくれます。出力がそのままキャンバス上で編集できるので、AI が描いた 8 割を人間が仕上げる使い方にちょうどいい。矢印の接続点を計算して線の交差を減らす工夫や、サーバー側で LLM の設定とアクセスパスワードを一元管理できる点も、チームで使うときに効いてきます。
7. GitHub Issues をそのままブログのデータベースに
最後は GitHub をデータベース代わりにしてブログを作る方法のまとめ。記事 1 本を Issue 1 件に対応させ、GraphQL API で一覧と本文（bodyHTML）を取得、コメントは Gitalk、画像は別ブランチに置いて jsDelivr で配信、デプロイは Vercel、という構成です。サーバーを持たずに書く場所と表示する場所を分けられるのが魅力で、トークンをリポジトリに入れない、sitemap をビルド前に生成する、といった運用の注意点まで押さえられています。
並べてみると、どの道具も「Markdown などのプレーンテキストを正本にして、見た目や配信先は後から変換する」という同じ方向を向いています。書く場所を一つに保っておけば、スライドにも、PDF にも、各種プラットフォームにも流せる。次は図の生成とスライドを組み合わせた流れを試してみるつもりです。