Markdownの誕生: なぜプレーンテキストがWebに勝ったか

GitHubのリポジトリを開くと、最初に目に入るのはコードではなく README.md だ。このファイルは通常Markdownで書かれており、プロジェクト内で最も読まれる文書である。求人情報、学術論文、法律契約書がMarkdownで書かれることはめったにないが、Web上の技術文書の大部分はMarkdownで書かれている。その理由を理解するには、レンダリングされる前に人間が読むことを前提にした形式に立ち返る必要がある。

Markdownはどこから来たか

2004年、テクノロジー記者のJohn Gruberは、Aaron Swartzの助言を受けながらMarkdownの構文仕様を公開した。Gruberの目標は実用的だった。見た目の良いプレーンテキストでWeb向けに書き、その後HTMLに変換できる方法が欲しかった。当時のWebはタグで動いていた。ブログ記事を書くとは、あらゆる段落、リスト、リンクを山括弧で囲むことを意味した。Gruberは、このようなノイズが大多数の人々が公開していた文章にとって不要だと考えた。

結果は小さな慣習の集合だった。

• 見出しは # を使う。
• リストは - または * を使う。
• リンクは [text](url) を使う。
• 強調は *text* または _text_ を使う。
• コードはバッククォートを使う。

これらの慣習は、電子メール、Usenet、そしてライターがすでに知っていたプレーンテキストの習慣から借りてきたものだった。Markdownは多くのものを発明したわけではない。ただ、そのルールを文書化しただけだ。

Gruberはまた、構文をHTMLに変換するPerlスクリプト Markdown.pl という参考実装も公開した。読みやすいソース形式と決定論的な出力形式の組み合わせは、導入を容易にした。ライターはどのテキストエディタでも編集できるファイルを手に入れ、出版者はCSSでスタイル設定できるクリーンなHTMLを手に入れた。

MarkdownはHTMLではない

これは自明に聞こえるが、技術的には重要な違いだ。HTMLは構造化ドキュメント形式である。要素、属性、ネスト、動作を記述する。ブラウザはソースが人間にどう見えるかを気にしない。マークアップから構築できるDOM（Document Object Model）を気にする。

Markdownは執筆上の慣習である。DOMも、イベントハンドラも、フォームも、フロントマター利用者が追加するもの以外のメタデータスキーマもない。マークアップ言語というよりは速記法に近い。Markdownをパーサーに通すと、出力は通常HTMLだが、Markdown自体が扱うのは、ライターが手で入力する文書の部分、すなわち見出し、段落、強調、リスト、リンク、画像、コードだけだ。

この違いが、それぞれの形式が活躍する場所を形作る。

HTMLは最終的なページだ。Markdownは原稿だ。

なぜこれほど急速に広まったか

MarkdownをニッチなPerlスクリプトから技術文書のデフォルト言語に押し上げたのは、3つの力だ。

バージョン管理。 Gitが標準になるにつれ、開発者はドキュメントをコードと並べて保存し始めた。プレーンテキストが勝ったのは、diffが読みやすかったからだ。HTMLやWord文書では、小さな編集でもdiffの中で読めない塊になる。Markdownは読みやすさを保った。

GitHub。 2009年、GitHubはリポジトリページで README.md ファイルをレンダリングし始めた。突然、すべてのプロジェクトがMarkdownファイルを必要とするようになった。Stack Overflowも質問と回答にMarkdownを採用した。開発者は、毎日使うプラットフォームがそれを要求したため、この構文を覚えた。

静的サイトジェネレーター。 Jekyll、Hugo、Gatsby、そして後のNext.jsなどのツールは、Markdownファイルを完全なWebサイトに変換した。ライターはCMSなしで公開できるようになった。ソースファイルはGitリポジトリに置かれ、ビルドステップがHTMLを生成した。この、今ではdocs-as-codeと呼ばれるワークフローは、Markdownを現代Webの大きな一部の入力形式にした。

メモアプリが最後の押しを加えた。Obsidian、Notion、Bear、Logseq、iA WriterはすべてMarkdownまたはその近傍の構文をサポートしている。この形式は開発者ツールの枠を超え、個人の知識を整理する方法となった。

MarkdownはdocxやPDFを置き換えるか

いいえ。この質問が出るのは、Markdownは軽快に感じ、他の形式は重く感じるからだが、それらは別の問題を解決している。

.docx ファイルは、リッチ編集のためのZIP圧縮XMLパッケージだ。変更履歴の追跡、コメント、スタイル、目次、差し込み印刷、埋め込みメディアに対応している。契約書、レポート、技術的でないユーザーによる往復編集が必要な原稿向けの形式だ。

PDFは固定レイアウトの電子ペーパー形式だ。フォント、行間、ページ送りをデバイス間で保持する。これは、最終的な請求書、履歴書、どこでも同じ見た目であるべき学術論文にとってまさに求められる特性だ。

Markdownは交換用形式だ。原稿執筆、バージョン管理、Web公開には優れている。ページレイアウト、精密なタイポグラフィ、印刷にそのまま使える出力には向かない。現実的なワークフローは、執筆にMarkdownを使い、文書がテキストエディタを離れる必要があるときにdocxやPDFに変換することだ。

そこでブラウザベースのコンバーターが役立つ。Markdownの原稿を共有可能なPDFにする必要がある場合、私たちの Markdown to PDFコンバーター がローカルで変換を処理する。PDFから編集可能なMarkdownを始めたい場合は、PDF to Markdownコンバーター がファイルをアップロードせずに構造を抽出する。

Markdownが得意なこと、そこで崩れること

利点

• 読みやすいソース。 Markdownファイルはレンダリング後のページとほぼ同じくらいきれいだ。ターミナル、メールクライアント、スマホのメモアプリで読める。
• ポータブル。 プレーンテキストだ。ベンダー独自のものもなく、ライセンスもなく、破損するバイナリ形式もない。
• diffに強い。 Gitはどの文が変更されたか正確に示せる。ライターとレビュアーがすぐに恩恵を受ける。
• ツールが豊富。 あらゆるプログラミング言語にパーサーがある。主要なプラットフォームすべてにエディタがある。
• Webネイティブ。 Webの実際の出力形式であるHTMLにコンパイルされる。

限界

• 曖昧な仕様。 Gruberのオリジナル仕様は、エッジケースを未定義のままにしている。同じ入力に対して、異なるパーサーが異なるHTMLを出力する。これがCommonMarkが存在する理由だが、すべてのツールがCommonMarkを採用しているわけではない。
• レイアウト制御がない。 画像の配置、ページ余白の設定、印刷スタイルの定義は、HTMLやCSSに頼らなければできない。
• フレーバーの混沌。 GitHub Flavored Markdown、Pandoc Markdown、MultiMarkdown、Obsidian Markdown、MDXは、互換性のない拡張をそれぞれ追加している。あるツール用に書かれたファイルが、別のツールでは正しくレンダリングされないことがある。
• 表と脚注は後付け。 これらはコア構文ではなく拡張でサポートされており、動作が様々だ。

正直なまとめは、Markdownは段落、リスト、リンク、コードといった文章の90%を得意とする。残りの10%はHTMLや専門の形式に押し付ける。

AI時代のMarkdown

大規模言語モデル（LLM）を使ったことがあれば、Markdownを見たことがあるだろう。ほとんどのチャットインターフェースは、LLMの出力をデフォルトでMarkdownとしてレンダリングする。それには実用的な理由がある。

第一に、Markdownはコンパクトだ。トークンは高コストであり、# を <h1></h1> の代わりに使う形式はスペースを節約する。第二に、Markdownは構造的に単純だ。見出し、リスト、コードブロックは、モデルが出力しやすく、パーサーが検証しやすい。第三に、トレーニングデータにMarkdownがあふれている。GitHub、Stack Overflow、Reddit、ドキュメントサイトがすべてMarkdownを使っているため、モデルは構文を確実に学習する。

チャット出力を超えて、MarkdownはAI知識システムの保存形式にもなっている。RAG（Retrieval-Augmented Generation、検索拡張生成）パイプラインでは、構造が予測可能なため、文書をMarkdownやプレーンテキストに分割することが多い。ベクトルデータベース、メモツール、コーディングアシスタントは、人間が読めて機械が解析できるMarkdownファイルとして長期コンテキストを保存する。

リスクはフレーバー間の不整合だ。あるモデルはGitHub形式の表を出力し、別のモデルは同じ表をHTMLで出力するかもしれない。フレーバーが混在する知識ベースは、ツール間を移動するときに壊れる可能性がある。CommonMarkまたは文書化されたフレーバーに標準化することが、AI生成のMarkdownをポータブルに保つ唯一の方法だ。

Markdownの未来と進化

Markdownが表現力の高い形式になることはない。表、脚注、定義リスト、属性など、それを豊かにしようとするあらゆる試みは、人気を呼んだシンプルさそのものから遠ざける。本当の進化は2つの方向で起こっている。

標準化。 2014年に始まったCommonMarkは、厳密なパース仕様を定義する。これを実装するツールが増え、ファイルをあるパーサーから別のパーサーに移したときの驚きが減っている。

埋め込み。 MDXでは、Markdownの中にReactコンポーネントをインポートできる。Jupyter NotebookはMarkdownセルを実行可能なコードと混ぜる。静的サイトジェネレーターはMarkdownを構造化コンテンツのデータソースとして扱う。いずれの場合も、Markdownは小さく保たれ、周囲のツールが機能を追加する。

可能性の高い未来は、現状の延長線だ。Markdownは普遍的なプレーンテキスト原稿形式であり、コンバーターがそれをHTML、PDF、docx、スライド、あるいは目的地に必要なものに変換する。

プラットフォーム別の閲覧・編集ツール

Markdownを使うのに特別なアプリは必要ない。どのテキストエディタでも動く。ただし、いくつかのツールは体験を大幅に向上させる。

Windows

• VS Code: Markdown拡張機能とともに、開発者のデフォルト選択。プレビュー、lint、markdown-itレンダリングをサポート。
• Typora: 必要になるまで構文を隠す、ミニマルなWYSIWYGスタイルのエディタ。
• MarkText: クリーンな分割ビューを持つ、Typoraのオープンソース代替。
• Notepad++: 簡単な編集には十分。プラグインによるMarkdownシンタックスハイライト付き。

macOS

• iA Writer: 没入型執筆と構文コントロールに特化。
• Bear: Markdown風構文を使う、個人の知識管理向けメモアプリ。
• Ulysses: Web公開を行う長文ライターに人気。
• Marked 2: エディタではないが、他の場所で編集したファイルの強力なライブプレビューレンダラー。

Linux

• Ghostwriter: ライブプレビュー付きの没入型Markdownエディタ。
• Apostrophe: 散文を想定したクリーンなGTKベースのエディタ。
• ReText: 複数形式へのエクスポートが可能なシンプルなエディタ。
• Vim / Neovim / Emacs: すでにターミナルに住むライターにはかなわない。

クロスプラットフォーム

• Obsidian: リンク、グラフ、プラグインを備えたローカルファーストな知識ベース。
• Logseq: すべてをMarkdownまたはOrgファイルとして保存するアウトライナー。
• Joplin: エンドツーエンド暗号化とMarkdownサポートを持つオープンソースのメモアプリ。

言語別のMarkdownライブラリ

Markdownを解析またはレンダリングするソフトウェアを構築する場合、パーサーを自分で書く必要はめったにない。エコシステムは成熟している。

これらのライブラリのほとんどは、コア構文をうまく処理する。違いは拡張、パフォーマンス、CommonMarkへの厳密な準拠の度合いに現れる。使っている言語だけでなく、サポートする必要があるフレーバーに基づいて選ぶべきだ。

結論

Markdownが勝ったのは、強力だからではない。邪魔をしないからだ。ライターはどのテキストエディタでも開き、ドキュメントを入力し、ファイル形式を気にせずバージョン管理にコミットできる。そのトレードオフは意図的なものだ。Markdownはレイアウトの正確性を放棄し、代わりに移植性と読みやすさを得ている。

このトレードオフが、README、ドキュメント、静的サイト、メモアプリ、そして今やAI出力を支えている理由だ。そして、MarkdownがdocxやPDFと並んで生き続ける理由でもある。それぞれの形式には役割がある。Markdownの役割は、プレーンテキストの出発点となることだ。その出発点を表現力の高い形式に移す必要があるとき、通常次のステップはコンバーターだ。