doocs/md を採用する前に見るべき5つの判断軸
✍ WeChat Markdown Editor | 一款高度简洁的微信 Markdown 编辑器：支持 Markdown 语法、自定义主题样式、内容管理、多图床、AI 助手等特性
ひと目でわかる
- これは何？
- 微信公衆号向けの Markdown エディタ doocs/md について、README とリポジトリ構成から読み取れる仕組み、導入方法、そして採用すべきでないケースを整理する。
- 誰に向いている？
- 微信公衆号の記事を Markdown で書き、貼り付け時のスタイル崩れに悩んでいる個人や小規模チームには向いている。逆に、複数人での同時編集や承認フロー、CMS との連携を前提とする編集部には機能が足りない。
- 商用利用できる？
- できます。WTFPL は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
微信公衆号のエディタが抱える「貼り付けで崩れる」問題
微信公衆号の管理画面には独自のリッチテキストエディタがあり、外部で書いた HTML を貼り付けるとスタイルが意図せず変わる。doocs/md が解いているのはこの一点に絞った問題だ。README には「Markdown 文档自动即时渲染为微信图文」とあり、Markdown を書くと微信向けのインラインスタイル付き HTML に変換し、そのまま貼り付けられる形にする。対象読者は、公衆号を運用する個人の書き手と、数人で記事を回している小規模な編集チームである。汎用の Markdown エディタではない。出力先が微信公衆号に固定されている点が、他のエディタとの決定的な違いになる。
Vue 3 と Vite で組まれた変換パイプライン
リポジトリのトピックには vue、vue3、vite、tailwindcss が並び、主言語は TypeScript とされている。README が挙げる機能から、入力から出力までの流れはおおよそ次のように読める。左側で Markdown を書くと、KaTeX による数式、Mermaid と PlantUML による図、GFM の警告ブロック、`[文字]{注音}` 形式の Ruby 注音がそれぞれ変換され、テーマの CSS を反映した HTML になる。テーマは切り替え可能で、コードブロックのハイライトテーマも複数用意されている。画像は指定した図床へアップロードされ、本文にはその URL が埋め込まれる。編集内容はブラウザ内のローカル草稿として自動保存され、ログイン時は設定がクラウド同期される。同期の詳細は docs/cloud-sync.md に分離されている。
図床は13種類、設定キーはサービスごとに異なる
README の表には13の選択肢が並ぶ。デフォルトは設定不要。GitHub は Repo と Token、阿里云 OSS は AccessKey ID、AccessKey Secret、Bucket、Region、腾讯云 COS は SecretId、SecretKey、Bucket、Region といった具合に、必要なキーがサービスごとに違う。S3 プロトコル対応の項目では AWS S3 のほか Oracle、DigitalOcean など互換ストレージが使えると説明されている。MinIO は Endpoint、Port、UseSSL、Bucket、AccessKey、SecretKey を要求する。13番目の「自定义上传」だけは設定が必要と明記され、docs/custom-upload.md に手順が置かれている。注目したいのは、これらの認証情報がブラウザ側の設定として入力される形式だという点で、サーバ側に秘密情報を集約する設計ではない。チームで共有する場合、誰がどのキーを持つかを別途決めておく必要がある。
起動方法：オンライン、CLI、Docker の3経路
最も簡単なのは https://md.doocs.org を開く方法で、README は Chrome の利用を推奨している。手元で動かす場合、リポジトリには npm パッケージ @doocs/md-cli と Docker イメージ doocs/md が用意されていることがバッジから読み取れる。CLI は npm 経由で導入する形になり、Docker は docker イメージを取得して起動する。いずれも Node.js 22 以上が前提とされている点に注意したい。ソースからビルドする場合は TypeScript と Vite の構成なので、依存をインストールしてビルドコマンドを実行することになるが、README の抜粋にはそのコマンド列までは含まれていない。正確なコマンドはリポジトリの package.json と docs を確認してほしい。
AI 連携は「補助」であって校閲ではない
DeepSeek、OpenAI、通義千問、騰訊混元、火山方舟、302.AI といったモデルが統合されていると README は述べる。ただし書き方は「辅助内容创作」であり、生成した文章をそのまま公開する用途を想定した表現ではない。API キーの管理方法やプロンプトの送信範囲について README の抜粋には説明がない。社内の未公開原稿を扱う場合、どのモデルに何が送られるのかを自分で確かめる必要がある。ここは採用判断で最も情報が薄い部分だ。
向かないケース：共同編集とワークフロー管理
doocs/md は編集者一人が原稿を仕上げて貼り付ける流れに最適化されている。複数人での同時編集、変更履歴の比較、承認フロー、公開予約といった編集部向けの機能は README に記載がない。クラウド同期はあくまで「编辑器偏好」の同期であり、原稿そのものの共有機能ではない。したがって、複数ライターが同一記事を並行して直す運用や、誰がいつ何を変えたかを追跡する必要がある現場では、この道具は荷が重い。原稿管理は Git や別のドキュメント基盤に任せ、doocs/md は最終的な整形と貼り付けだけに使う、という切り分けが現実的だ。
代替としての WeChat Markdown Editor 系と汎用ツール
README 自身が「现有的开源微信 Markdown 编辑器普遍存在样式繁杂、排版需反复调整的问题」と書いており、既存の微信向け Markdown エディタ群が比較対象として存在することを認めている。doocs/md の立場は、テーマを絞って調整の手間を減らす側にある。一方、微信に特化しない汎用の Markdown ツールと比べると、違いは出力形式にある。汎用ツールは PDF や静的サイト、GitHub 向けの HTML を出す。doocs/md は微信の管理画面に貼り付けても崩れないインラインスタイルを出すことに機能を寄せている。逆に、微信以外が主な出力先なら、この特化は制約にしかならない。
WTFPL というライセンス表記の扱い
ライセンスは WTFPL と表示されている。これは Do What The Fuck You Want To Public License の略で、事実上あらゆる利用を許す条項だが、条文に保証の否否認が含まれるかどうかは版によって異なる。社内の法務チェックでは、OSI 承認ライセンスではないため自動承認の対象外になることが多い。ここで法的助言はできないが、ライセンス名がそのまま通らない組織では、MIT や Apache-2.0 のプロジェクトと比べて説明コストが増える点を織り込んでおきたい。
メンテナンスとアップグレードの実際
直近のリリースは v2.1.0 が 2025-10-17、v2.0.4 が 2025-06-19、v2.0.3 が 2025-05-25 で、リポジトリはアーカイブされていない。パッチとマイナーの刻みで更新が続いている。自前でホストする場合、追従コストは npm パッケージ @doocs/md-cli か Docker イメージ doocs/md の更新に集約される。ブラウザのローカル草稿に依存する以上、環境を移行すると草稿は引き継がれない。ログインによる同期の対象はあくまで設定であり、原稿のバックアップ手段は別に用意する必要がある。
編集部の結論
微信公衆号の記事を Markdown で書き、貼り付け時のスタイル崩れに悩んでいる個人や小規模チームには向いている。逆に、複数人での同時編集や承認フロー、CMS との連携を前提とする編集部には機能が足りない。導入前に確認すべきは3点。Node.js が 22 以上であること、使用する図床の認証情報がブラウザに保存される前提でよいこと、そして WTFPL というライセンス表記が社内の法務チェックを通るかどうかである。
コミュニティノート