ハクソク

世界を動かす技術を、日本語で。

なぜ私たちはまだMarkdownを使っているのか？

2026年4月4日原文(bgslabs.org)

概要

  • Markdown はシンプルだが、その設計や運用には多くの矛盾や問題点が存在
  • CommonMark による仕様統一の努力は評価されるが、根本的な課題は言語自体にある
  • 拡張や互換性 の問題、HTMLとの混在、パーシングやセキュリティリスクが顕在化
  • 理想的なマークアップ言語 には明確な仕様とビルドシステム、拡張性が必要
  • 現状のMarkdown は万能ではなく、用途に応じた適切な選択が重要

Markdownの光と影

  • Markdown は、 最小限の記法 で文書を整形できるマークアップ言語
    • 主な目的は、 MarkdownファイルからHTMLファイルへの変換
    • 視認性が高く、記述も簡単 で、初心者でもチートシートだけで使い始められる
    • C言語のように、出力が予測しやすい 点も魅力
  • しかし、 私たちが本当に求めているもの は何かが曖昧
    • UIやプログラミング的な拡張 を求める声も多く、機能追加が混乱を招く
    • 仕様の不明瞭さ が、さまざまな解釈や実装の違いを生む要因

Markdownの曖昧な仕様と実装の混乱

  • 同じ出力を別の記法で書ける という問題
    • 例: # HelloとHello =====はどちらも同じ見出しに変換
    • 強調（太字・斜体） も**bold**、__bold__、<b>bold</b>など複数の書き方が可能
    • 入れ子や複雑な強調記法 がパーサーの脆弱性（ReDoS等）を誘発
  • HTMLのインライン挿入 が可能
    • Markdown内で<span>や<div>などHTMLタグを直接記述できる
    • これにより、 MarkdownパーサーだけでなくHTMLパーサーも必要 となる
    • セキュリティリスク（XSS等） の温床となりやすい
  • 古い記法や複数の書き方が混在
    • 見出しやリスト、水平線など、 2通り以上の記載方法 が存在
    • 文脈依存の記法 （例: footnoteや参照リンク）でパースが複雑化

パーシングとレンダリングの課題

  • パース自体は簡単 だが、 文脈依存の仕様 があると一気に難易度が上がる
    • 例: footnoteや参照リンクは グローバルな定義解決 が必要
  • レンダリングはさらに難しい
    • 現代のMarkdownは フットノートやカスタムコールアウト、数式、カスタムスタイリング など多機能化
    • 単純なテキスト変換から、コンパイラ的な処理 が求められる
    • 依存関係や実行エンジン まで必要になるケースも

セキュリティと運用の現実

  • インラインHTMLやプラグイン、埋め込み実行エンジン の導入で攻撃面が広がる
    • 実際に XSS脆弱性（CVE） が繰り返し発生
  • パーサーの多様化 と 独自拡張 が標準化を阻害
    • どのツールも「 万能ではない」状態

理想のマークアップ言語とは

  • 明確で一貫した仕様 と ビルドシステム の必要性
    • インラインHTML禁止、明確なショートコードや関数の導入
    • カスタムフック の定義（コンパイル前・中・後）
    • 仕様の完全な定義
  • 現状の選択肢の限界
    • Plain text： 美しいが専門性が高い
    • reStructuredText： 読むのは良いが書きにくい
    • mdx： HTMLに近づきすぎて可読性が犠牲
  • 万能な選択肢は存在しない という現実

結論：Markdownをどう使うべきか

  • Markdownはシンプルな文書作成には最適
    • ただし、 拡張や複雑な要件には向かない
  • 用途に応じて適切なツールを選択
    • 必要なら カスタムビルドのツールや独自仕様 の導入を検討
  • 「言語」として万能を求めず、道具として割り切って使う姿勢 が重要

Hackerたちの意見

UNIX/Linux自体と同じように、悪い方が良いってことだよね。完璧は「十分良い」の敵なんだ。人々が書くことをもっと簡単にできるようにしたいんだよね。書くことへの障壁、特にドキュメントを作ることへの障壁は最小限に抑えるべきだよ。うまく書くのは十分難しいから！マークアップは余計な手間だし、複雑なマークアップはさらに手間がかかる。Markdownは、著者にほとんど認知負荷をかけずに、ちょうどいい構造とタイポグラフィの機能を提供する、今のところのベストな妥協案だと思う。しかも、最近はもっと複雑なことが必要なら、好きなAIエージェントにやらせればいいしね。

└

Markdownで十分に完璧な解決策があるよ。新しい革命的な技術が車輪の技術を置き換えないのと同じだね。

└

私にとって、Markdownは他のマークアップ言語に比べて余計な認知負荷が多いんだ。• 太字やイタリックにアスタリスクを使うかアンダースコアを使うか決めなきゃいけない。• 箇条書きにアスタリスク、ハイフン、プラスを使うか決めなきゃいけない。• 解析に関するいろんなルールや例外を覚えておかなきゃいけない。

└

Markdownは、Usenetやメール、他のテキストメディアで既に使われていた慣習をしっかりと組み込もうと頑張ったことも忘れないでね。引用を示すための「>」は、Usenetで広く使われていた慣習だったし、強調を示すためのアスタリスクやアンダースコアも一般的な慣習だった。どちらも合法だし、どちらも一般的だったからね。特に強調するためのダブルアスタリスクやダブルアンダースコアもよく使われていたし、箇条書きを表示するためのアスタリスクや段落を分けるための空行、コードを書くための4つ以上のスペースのインデントもそうだった。これは「道を舗装する」デザイン哲学の良い例で、ユーザーが既にやっていることをする方が、理想的な世界を押し付けるよりも良いってことだね。そして、それがうまく機能しているんだ。

└

「悪い方が良い」ってのは、「最悪が最高」って意味じゃないからね。

└

これがまさにReStructured Textが良い/悪い理由だよ。

└

「悪い方が良い」ってのはすごく古い考えだよ。論文の中で、コペルニクスは「悪いお金が良いお金を追い出す」って原則を提唱した。これは後にサー・トーマス・グレシャムによってグレシャムの法則として知られるようになった。この現象はニコル・オレスムによっても以前に指摘されていたけど、コペルニクスは独立して再発見したんだ。グレシャムの法則は、ポーランドや中央・東ヨーロッパではコペルニクス＝グレシャム法則として知られている。 https://en.wikipedia.org/wiki/Monetae_cudendae_ratio

└

「それが私たちが知っている最良の妥協だ」と言うのはちょっと行き過ぎだと思う。もっと読みやすくて直感的なフォーマットはあるけど、マークダウンのように広まってはいないんだよね。

└

私たちは、人々が最小限の摩擦で書き出しを行うことを奨励したいんだ。書くことへの障壁、特にドキュメントを作成する際の障壁は最小限にすべきだよ。うまく書くのは十分難しいから！ AsciiDoc（またはreStructuredText）みたいなものはどう？ * https://docs.asciidoctor.org/asciidoc/latest/asciidoc-vs-mar... * 「マークダウン、AsciiDoc、またはreStructuredText – ドキュメントをコードとして扱う物語」: https://news.ycombinator.com/item?id=33468213 簡単なことはまだ簡単だけど、必要な人にはもっと高度な選択肢があるみたいだね。

└

ドキュメント作成の障壁は、最小限に抑えるべきだよね。ちゃんと書くのも十分難しいのに！ 書くって、すごく要求される作業なんだよね。同時に、みんな良い、アクセスしやすくて検索可能なドキュメントを期待してるけど、実際にはほとんど手に入らない。なんでだろう？ 取り除けない障壁の一つは、意味の構造を保持する必要があることなんだ。TFAの著者はこう書いてる：「悪い点は、私たちが何を求めているのか分からないことだ。」まさにその通り。私たちは、なぜ書くのかを認識できず、その結果表現できなくなってる。技術的なドキュメントを書くのは、KLOCのためじゃない。役に立つ、意味のあるものを書くことは、KPIやSEOのためのパフォーマンス的な埋め草じゃなくて、構造が必要なんだ。効果的に取り出せない価値のあるものは、失われてしまう。実際のコードやデータベースの行を同じペースで失うことを想像してみて。私たちは常に意味を管理するのに失敗してる。プログラミングの技術は意味に関するものなのに、これは非常に逆説的だよね。コードを意味的に整理するのは、コンパイルのためだけじゃなく、拡張やリファクタリング、レビュー、取り出し、理解のためにも必要だから。私たちも同じ配慮を持って書く必要があるんだ。複雑である必要はないのに、レシピに合わない道具を使い続けてる。 > Markdownは、私たちが知っている中での最良の妥協策だよ。キー入力を減らして、書くという手作業を楽にしてくれる。でも…それは問題の一部しか解決してない。例えば、HTML5は最小限の意味的タグを提供してる。簡素なタグのセットかもしれないけど、簡単に入力できるテキストの塊よりは改善されてる。

└

逃れられない真実なんだけど、魔法のような解決策を考えた後でも…時には基本的なCRUD機能にちょっとした機能を追加しただけのものが、実際にコードを書くときに残るし、メンテナンスも少なくて済むんだ。人を驚かせるものと、実際に使われるものがあるよね。

Markdownは素晴らしいよ。だって、いろんなことを定義しないから。見出し？ただの見出しだし、フォントもサイズも色もない…ただの見出し。だから、どんなデバイスでも表示できるし、どんな紙にでも印刷できる。どんなアクセシビリティツールとも連携できるし、読者の要求に最適化されるんだ。作成者が「これが良い」と思ったものじゃなくてね。ウェブには、レイアウトの選択が悪くてアクセスしづらい素晴らしいコンテンツがたくさんある。テキストをくれれば、どうやって読みやすくするかは自分で選びたい。生のMarkdownを解析せずに読めるってのもさらに良い点だよね。読者にとってどう見えるかを完全にコントロールできないのは、バグじゃなくて機能なんだ。

Hacker Newsで議論の続きを見る