世界の中心で、Markdown に吠える

起：まずは吠えさせてくれ

気づいたら Markdown に向かって吠えていた。

──おい Markdown、セル結合くらいできてもいいだろ。

──おい Markdown、2カラムくらい許してくれよ。

──おい Markdown、文字色くらい付けさせてくれよ。

別に Markdown が嫌いなわけじゃない。
むしろ好きだ。
だからこそ、「お前もっとできる子だろ！」 と言いたくなる。

設計書を書くときにも、
ブログを書くときにも、
どんな文章を書くときにも、
“あと一歩” が足りない。

今日はその「あと一歩」に向かって吠えさせて。

---

設計書を書くときに表が弱すぎる問題

設計書を書こうとすると、Markdown の表がこう言ってくる。

「セル結合？ そんな高等技術、うちにはないっす」

いや、ないっすじゃないんだよ。
2026年だぞ。

• 列幅は勝手に変わる
• 表内の箇条書きは崩壊する
• コードを書いたら地獄絵図
• スクロールしないと読めない表とか論外

もう <table> に逃げた瞬間、
「負けた…」
って気持ちになるんだけど・・・

---

ブログを書くときにレイアウトが弱すぎる問題

ブログを書こうとすると、Markdown がこう言ってくる。

「2カラム？ 画像の横に文章？
いや〜、ちょっとそういうのは…」

いや、照れてる場合じゃない。

• NOTE / WARNING / TIP の方言戦争
• 図と文章を並べたいのに並ばない
• 画像サイズは“運”
• カスタムブロックはサービスごとに別言語

Markdown、君はいつから
「文章しか書けない子」
になってしまったんだ。

---

どんな文章でも欲しくなる“最低限の文明”

• 図表番号
• セクション参照
• メタ情報
• カラー
• ハイライト
• 統一カスタムブロック

これ全部、HTML なら一瞬でできる。

Markdown、君は HTML の省略記法だろ。
省略しすぎて文明を捨てるのはやめてくれ。

---

転：ここで一度、歴史を振り返ろう

怒りをぶつけたところで、
一度 Markdown の成り立ちを振り返ってみる。

Markdown は「WYSIWYG が嫌だ！」から始まった

当時の WYSIWYG は重かった。
落ちた。
勝手にレイアウトが変わった。
コピペすると謎の呪文が混ざった。

だから John Gruber はこう思った。

「もういい。
HTML を簡単に書ければそれでいい。
WYSIWYG は信用ならん。」

こうして Markdown は生まれた。
「軽い・素朴・プレーンテキスト最高！」 という思想で。

---

しかし時代は進化した

今の WYSIWYG はヌルヌル動く。
Google Docs も Notion も、昔の WYSIWYG とは別物だ。

ブラウザも PC もスマホも、
WYSIWYG くらいじゃビクともしない筋肉を手に入れた。

---

それでもプレーンテキスト文化は死ななかった

某 GitHub のような
“プレーンテキスト純血主義” の世界では、
リッチなフォーマットは嫌われる。

• invisible character
• 謎のスタイル
• WYSIWYG の残りカス

こういうのを混ぜるとレビューで怒られる。

だから Markdown は今でも重宝されている。
でも、表現力は足りない。

文明が進化しても、プレーンテキスト文化は生き残った。
むしろ強くなった。

---

ER図の二の舞を憂う

Markdownは、もともと気軽な発想から始まった。

書き方を決めて、HTMLへ変換すればいい。
それだけで十分だった時代が、確かにあった。

しかしその後、
HTMLもCSSも、ブラウザも、表現力と構造表現を大きく進化させてきた。
一方で、Markdownはほとんど同じ姿のまま使われ続けている。

この状況に、どこか既視感がある。

かつてER図も、
業務構造や設計意図を人に伝えるための「思考の道具」だった。
だが表現力の限界と実装との乖離によって、
次第に「描くこと自体が目的の図」になっていった。

今のMarkdownも、同じ分岐点に立っているように見える。

幸いなことに、Markdownはパーサーやレンダラを通さなくても、テキストそのものが意味を持つ。
この性質がある限り、Markdownは単なる表示用フォーマットには堕ちていない。

使われなくなるわけではない。
下書きとして、メモとして、入口としては残り続けるだろう。
しかしこのまま変わらなければ、
設計や思想を載せる器としては、静かに役割を終えていく――
そんな未来も、現実味を帯びてきている。

---

承：だからこそ、Markdown は“こうあってほしい”

歴史を踏まえたうえで、
Markdown に求めたいのはこれだ。

HTML でできるなら、Markdown でも“できてほしい”

• セル結合
• 列幅指定
• 表の階層構造
• 2カラム
• 図表の並列
• カラー
• ハイライト
• 統一カスタムブロック
• 図表番号・参照

これ全部、HTML ならできる。
だから Markdown でも “できてほしい”。

---

用途別ではなく、統一された拡張がほしい

Markdown は記法だ。
用途ごとに分断される前提のものではない。

設計書を書くときも、
ブログを書くときも、
技術記事を書くときも、
日々のメモを書くときも、
同じ Markdown で書き続けたい。

それができるからこそ、
Markdown は思考を妨げない記法として受け入れられてきた。

しかし現実には、
用途ごとに異なる拡張や書き方が増え、
書き手は次第に
「何を書くか」ではなく
「どこに書くか」を意識させられるようになっている。

この分断に、歯がゆさを感じている人は少なくないはずだ。

設計書でも、技術記事でも、ブログでも、
構造を保ったまま、長く書き続けたい。
ただそれだけなのに、
用途が変わるたびに表現を使い分けなければならない。

設計書は、その問題が
もっとも早く、もっとも顕著に現れる場所にすぎない。
だが同じ違和感は、
他の多くの文書でも静かに蓄積されている。

だからこそ、
用途別の拡張ではなく、
どこで使っても通用する、統一された表現力がほしい。

---

実装が標準を連れてくる

仕様だけでは、世界は動かない。
Markdownの歴史を見ても、それは明らかだ。

実際に人が使えるパーサーがあり、
エディタがそれを理解し、
プラットフォームがそれを受け入れたとき、
はじめて「それがMarkdownだ」と認識される。

もし、

• 拡張Markdownを正しく解釈できるパーサーが公開され
• VSCode や Obsidian で違和感なく扱え
• GitHub や主要な公開サービスで破綻せず表示できる

そんな実装が現れれば、
それは仕様として合意されていなくても、
事実上の標準になっていく。

Markdownの未来を決めるのは、
会議室でも仕様書でもない。
「日常的に使われる実装」そのものだ。

---

結：あなたも Markdown に吠えてほしい

Markdown に期待していたのは、
最先端の機能でもない。
華美な装飾でもない。

構成管理と相性がよく、思考と構造を壊さずに、
長く書き続けられること。
ただ、それだけ。

それが叶わない場面が増え、歯がゆさを感じている人は、
きっと自分だけではないはずだ。

今日はその気持ちを、言葉にして置いておくことにする。

---