私はGitHub・npm (npmjs)・PyPIにソフト公開する都合からMarkdown形式での文書作成は必然的でしたが、そうだとしても文書作成の機能が優れているAsciiDocが普及していない(あるいは普及しなかった)ように見受けられるのは何故かなと、ふと感じたことがきっかけで本記事を作成しました。
ネットで検索すればMarkdownとAsciiDocを比較している記事は見つかりますが、普及の度合いという観点で比較している記事はすぐに見いだせなかったので、ChatGPT (GPT-5)にまとめてもらいました。単純に読み物として面白いと思いましたので、以下に転載します。誤認や事実と異なる記述があれば、ご指摘いただけると幸いです。
AsciiDocの普及の度合いについて
結論から言うと、Asciidocは機能的にはMarkdownより優れているものの、普及度ではMarkdownが圧倒的に優勢です。
以下で両者の比較を整理します。
| 観点 | Markdown | AsciiDoc |
|---|---|---|
| 誕生時期 | 2004年（John Gruberによる） | 2002年（Stuart Rackhamによる） |
| 普及範囲 | 非常に広い：GitHub、GitLab、Bitbucket、PyPI、npm、ブログCMSなど、あらゆる開発・文書環境で標準 | 限定的：主に技術ドキュメントやRed Hat系プロジェクト、書籍制作など |
| 主要プラットフォームでのサポート | ✅ GitHub, GitLab, VSCode, Obsidian, Jupyter, Static site generators（Hugo, MkDocsなど） | ⚠️ 一部サポートあり（GitHubはレンダリング対応なし、GitLabは対応） |
| 拡張性と標準化 | 多数の方言（CommonMark, GFM, Pandoc Markdownなど） | 仕様が明確（AsciiDoc → Asciidoctor が標準的実装） |
| 開発者コミュニティの規模 | 圧倒的に大きい | 比較的小規模だが堅実 |
👉 機能面ではAsciiDocが明確に上。
特に、大規模ドキュメント・製品マニュアル・書籍執筆などには非常に向いています。
| 機能 | Markdown | AsciiDoc |
|---|---|---|
| 見出し・箇条書き | 基本的な構文のみ | より細かく制御可能 |
| 表・脚注・数式 | 拡張仕様が必要（GFMなど） | 標準で対応 |
| クロスリファレンス（セクション・図表などへの参照） | 通常は不可 | 標準で可能 |
| 属性・変数展開 | 不可 | 可能（再利用性が高い） |
| マルチページ構成 | 不可 | 対応可能 |
| 出力形式 | HTML, PDF, etc（Pandocなどが必要） | HTML, PDF, DocBook, EPUB, etc（Asciidoctorが強力） |
実際の利用例。
| 分野 | Markdown採用例 | AsciiDoc採用例 |
|---|---|---|
| OSS README | GitHub上のほぼすべてのリポジトリ | 一部（例：Asciidoctor自身、JBoss、Spring公式ドキュメント） |
| 技術書・マニュアル | 技術書典などの同人出版、MkDocs, Sphinx | Red Hat製品ドキュメント、O’Reilly一部書籍 |
| 組織文書 | Notion, Confluence（Markdown互換） | Red Hat, Eclipse, JetBrains（ドキュメント系） |
総評。
| 項目 | Markdown | AsciiDoc |
|---|---|---|
| 普及度 | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| 機能 | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| 学習コスト | 低い | やや高い |
| 適した用途 | README・ブログ・短文 | 技術書・APIリファレンス・大規模ドキュメント |
| 結論 |
※これは私見ですが、Markdownの学習コストが低いのはその通りだと思います。しかし、AsciiDocも複雑なことをしなければ、学習コストはそれほど高くないように思います。
結論。
- Markdown：圧倒的に普及しており、汎用性が高い。軽量でどこでも使える。
- AsciiDoc：機能はリッチで、「長大なドキュメントのメンテナンス性・再利用性」が求められる場面で真価を発揮。
なぜAsciiDocはMarkdownほど普及していないのか
実際、AsciiDocがMarkdownほど普及しなかった理由は、技術的な優劣ではなく、「歴史的経緯・採用のしやすさ・ネットワーク効果」といった社会的・文化的な要因によるものが大きいです。
🧭 1. Markdownの「シンプルさ」が圧倒的に受けた
Markdownは「できることが少ない」のがむしろ長所でした。
- 「ブログを書く」「READMEを書く」といった軽量文書が主な用途で、
HTMLを直接書くよりも気軽で、覚える構文も少なかった。 - 一方、AsciiDocは構文が強力な分、覚えることが多く、初心者にはとっつきにくい。
💬 John Gruber（Markdownの作者）は、「テキストファイルをメールのように気軽に書ける」ことを目的にしていた — つまり、Markdownは最初からライトユーザー向けに設計されていたのです。
結果として、
「とりあえず書ける」「すぐ読める」「HTMLにしやすい」
という理由でMarkdownが爆発的に広がりました。
🧩 2. GitHubがMarkdownを標準採用したインパクト
GitHubが2010年代初期にREADME.mdを標準として採用したことが、決定的でした。
- OSS開発者の多くがGitHubを使っており、自然とMarkdownが事実上の業界標準になった。
- Pull RequestやIssueコメントでもMarkdown構文が使えるようになり、「書く・読む・共有する」が一気通貫で完結。
これがいわゆる「プラットフォームによるロックイン」効果です。
GitHubがAsciiDocを採用していれば、歴史は逆になっていた可能性すらあります。
⚙️ 3. AsciiDocのツールチェーンがやや重厚だった
- AsciiDocは本来、書籍や製品マニュアルのための構造化ドキュメントとして設計されていました。
- HTMLやPDFへの変換にAsciidoctorやDocBookツールチェーンが必要で、導入がやや複雑。
- Markdownなら1ファイルで完結し、PandocやGitHub内部レンダラーが即座に処理できます。
💬 要するに：
Markdownは「エディタ1つで完結」、AsciiDocは「本格的なビルド環境を必要とする」印象を与えた。
📦 4. Markdownの派生とツールが先に普及してしまった
Markdownはシンプルな仕様だったため、
- GFM (GitHub Flavored Markdown)
- CommonMark
- Pandoc Markdown
- Markdown Extra
など、多数の派生実装が登場。
結果として、Markdownエコシステムは「薄く広く」拡散しました。
一方、AsciiDocは仕様が明確で安定していたものの、
開発者層の裾野が広がりにくく、「厚く狭い」領域にとどまりました。
🧠 5. 「Markdownで十分」問題
多くのユーザーにとって、
「太字・見出し・リンク・コードブロックが書ければ十分」
という現実的な需要がありました。
AsciiDocの高度な機能（属性、変数、参照、文書構造制御など）は、
- 書籍や製品マニュアルのような長文構造化文書
- チームによる大規模ドキュメント制作
のようなニッチな分野でしか必要とされませんでした。
結果として、「一般ユーザーにはオーバースペック」になったのです。
🔄 6. クラウドサービス側のコスト問題
GitHubやNotionなどのサービス提供者にとっても、
- Markdownは軽量でパースが簡単
- ライブラリが豊富で高速
- JavaScriptなどで容易にクライアントレンダリング可能
という理由で、Markdownのほうが実装・メンテコストが圧倒的に低い。
AsciiDoc対応は「重く」「需要が少ない」ため、後回しにされました。
🧩 7. AsciiDocの用途が「業務寄り」に偏った
AsciiDocはRed HatやSpring、Eclipseなどが採用しており、
- 技術製品のマニュアル
- APIドキュメント
- 書籍出版
などに使われます。
つまり、「一般ユーザー」ではなく企業やドキュメント専門チームが主な利用者。
Markdownとはユーザー層そのものが違うのです。
✅ まとめ：普及しなかった主な要因
| カテゴリ | 要因 |
|---|---|
| 設計思想 | AsciiDocは構造化・再利用性重視、Markdownは軽量・即記述重視 |
| 導入障壁 | AsciiDocは変換ツールや構文理解が必要 |
| プラットフォーム支援 | GitHubがMarkdown標準にした |
| ユーザー層の違い | Markdownは個人・OSS、AsciiDocは企業・技術文書 |
| 実装コスト | Markdownは軽量・高速にレンダリング可能 |
一言で言うとこういうことらしい
Markdownは「カジュアルに書けるメモ帳」
AsciiDocは「章立てや変数を駆使できるドキュメントエンジン」
どちらが優れているというより、
目的の違いがそのまま普及度の差になったといえます。
