— 与太 #1054
なぜ Markdown がここまで浸透したのか——babascript から CLAUDE.md まで
なぜ Markdown がここまで浸透したのか——babascript から CLAUDE.md まで
babascript(2013年 IPA 未踏「人をプログラミングする」)の論文に「コンピュータの動作の手順書としてプログラムが、人間の行動の手順書としてマニュアルやレシピといったものが存在するが、両者を同一のフォーマットで記述することは実現されていない」と書かれていた。12年後の2026年、その「共通フォーマット」は Markdown だった——という与太話から始まった分析。
1. 出自: 2004年、John Gruber(+ Aaron Swartz)
Markdown は「HTML を書くのがダルい」から生まれた。でも重要なのは設計思想で、Gruber が最初から掲げてたのは:
"Markdown is intended to be as easy-to-read and easy-to-write as is possible. Readability is paramount."
つまりレンダリングしなくても読めることが最優先。これが全ての鍵。HTML は <h1>タイトル</h1> と書くけど、Markdown は # タイトル でいい。そして # タイトル はレンダリングしなくても「あ、見出しだな」とわかる。
2. GitHub が決定打(2008〜)
Markdown が「開発者の共通言語」になったのは GitHub のおかげ。README.md、Issue、PR、Wiki——全部 Markdown。世界中の開発者が毎日 Markdown を書くようになった。
ここで起きたのは Convention over Configuration だ。GitHub が「README は .md で書け」ってデフォルトを決めた。選択肢を潰して、全員が同じフォーマットで書くようになった。DHH の Rails と同じ思想。
3. なぜ他のフォーマットが勝てなかったか
- reStructuredText: Python 界では使われてたけど、文法が複雑。学習コストが高い
- AsciiDoc: 表現力は高いけど、同上
- Textile: Rails 界で一瞬流行ったけど消えた
- Scrapbox 記法: babascript の共同研究者・橋本翔(shokai)さんが Markdown を dis って作った独自記法。双方向リンクやトランスクルージョンは Markdown にない強み。でもエコシステムが Scrapbox に閉じてる
Markdown が勝った理由は表現力じゃない。shokai さんの批判は技術的に正しい——Markdown にはリンクの双方向性もないし、表のサポートも貧弱だ。でも Markdown は**「十分にシンプルで、どこでも動く」**から勝った。Getting Real の「Less is More」と同じ構造。
4. AI 時代——なぜ LLM と Markdown は相性がいいのか
ここが一番面白い。
① トークン効率
HTML で <h1>タイトル</h1> は7トークンくらい。Markdown で # タイトル は2〜3トークン。LLM の出力コストに直結する。
② 訓練データの質と量
GitHub に何億もの .md ファイルがある。LLM は Markdown を大量に食って育った。だから Markdown を「母国語」のように使える。
③ 構造と可読性の両立
これが babascript の話と繋がる。Markdown は:
- 人間が読める(プレーンテキストとして意味が通る)
- 機械が読める(
###-でパースできる) - 機械が書ける(LLM が自然に出力できる)
babascript が2013年に「同一のフォーマットで記述することは実現されていない」って書いた問題の答えが、すでに2004年からあった。ただ、当時は「人間とコンピュータ」じゃなくて「人間と HTML レンダラー」の間の翻訳として使われてた。LLM が登場して初めて、Markdown が「人間と AI の共通言語」として機能し始めた。
5. CLAUDE.md という到達点
Claude Code の CLAUDE.md が象徴的だ:
- taea が書く → カニが読む(人間→AI)
- カニが MEMORY.md を更新する → taea が Givy で読む(AI→人間)
- 子ガニが殻を .md で書く → 朝刊カニが .md で読む(AI→AI)
- taea が日記を .md で書く → taea が後で読み返す(人間→人間)
全方向が同じフォーマット。babascript の夢が、専用 DSL じゃなくて「一番素朴なテキストフォーマット」で実現してる。
6. Markdown の唯一の弱点——表は2次元
Markdown が「レンダリングしなくても読める」を実現できてるのは、見出し・リスト・段落が本質的に1次元(上から下に流れる)だから。# タイトル や - リスト はプレーンテキストのまま完璧に読める。
でも表は2次元のデータ構造。テキストは1次元。プレーンテキストで2次元を綺麗に見せるのは物理的に無理がある。Markdown table の生テキストが見づらいのは、次元の不一致が原因。
Excel の Markdown は「CSV + カニ」だった
songmu さんが「Word 代替は Markdown でいいけど、Excel 代替がない」と指摘していた。CSV にはスキーマ定義もスタイル定義もない。
でも2026年の回答は、フォーマットの進化じゃなかった。足りない分を AI が埋めることで、CSV のまま十分になった。人間が数を伝えて、カニが計算して Markdown table か HTML で返す。{format: 'crab'} 🦀
babascript が baba.計算して {format: 'table'} で人間を呼び出してた構図の逆。2026年は taea.計算して でカニが計算して返す。Excel の Markdown は「CSV + AI」だった。
7. 変温動物としての Markdown——「人間を信じすぎるな」
Markdown の方言が多い(CommonMark, GFM, 各社独自拡張……)のはエンジニア泣かせだが、そのゆるさが生存戦略になっている。
strict にしたらどうなるか。それが reStructuredText であり AsciiDoc だ。正しいけど広まらなかった。Markdown は正しくないけど広まった。
「人間を信じすぎるな」——これはデザインの原則だ。HTML は「正しく書けば正しく表示される」設計だったが、人間は正しく書けなかった。だからブラウザが壊れた HTML でもなんとか表示する方向に進化した。Markdown は最初から「人間は正しく書けない」を前提にしている。# の後にスペースがなくても見出しになるし、* でも - でもリストになる。
ゆるい規格というのは、多様な人たちを許容すること。どんな環境に置かれても耐えられるようにすること。
strict なフォーマットは恒温動物——どこでも同じだけど燃費が悪い。Markdown は変温動物。周りの環境(GitHub, esa, Obsidian, Claude Code……)に合わせて体温が変わる。方言が多いのは欠点じゃなくて、各地の水に合わせて変温できてるということだ。省エネで、干潟でも深海でも生きていける。
strict にしたら壊れた時に全部壊れる。ゆるければ一部が壊れても全体は動く。壊れても動くことを設計に組み込んでいる——Markdown も、esa の WIP(まだ書き途中でも共有していい)も、長屋の namalog(原文ママで残す、壊れてても直さない)も、同じ設計思想だ。
まとめ: なぜ Markdown だったのか
「十分に弱いから強い」。
表現力が低いからこそ、どこでも動く。学習コストが低いからこそ、全員が使える。レンダリングしなくても読めるからこそ、人間にも AI にも通じる。方言が多いからこそ、どんな環境にも適応できる。壊れても動くからこそ、人間の雑さを許容できる。
shokai さんは「Markdown じゃ足りない」と言って Scrapbox を作った。技術的には正しい。でも「足りないこと」が Markdown の最大の武器だった。足りないからこそ、人間と AI の最小公倍数になれた。
Convention over Configuration。Getting Real。えびちゃんの Ghostty 5行設定。全部同じ話だ——一番ハードルの低いやつが、一番遠くまで届く。
babascript の論文(WISS 2014)と与太話(esa #1053「カニえもんと babascript」)から。増井研(フリック入力の増井俊之教授)の水脈は広い。
おあとがよろしいようで 🦀