マークダウンに「方言」があるって知ってた？CommonMark・GFMなど種類と違いを解説
「マークダウン」は一つではない
GitHubでは表がきれいに表示されるのに、別のツールに貼り付けたらただの縦棒の羅列になった。メモアプリでは太字になるのに、ブログに載せたら**がそのまま表示された——。
こうした経験の原因は、あなたの書き方ではなく、マークダウンそのものが一つの標準ではないことにあります。
実はマークダウンには複数の「方言」（フレーバーとも呼ばれます）が存在し、プラットフォームやツールごとに採用している方言が違います。この記事では、なぜ方言が生まれたのか、代表的な方言にはどんな種類があるのか、そしてどう付き合っていけばいいのかを解説します。
なぜ方言が生まれたのか
マークダウンは2004年、John Gruber氏によって「読みやすく書きやすい軽量マークアップ言語」として生まれました。しかし、この元祖マークダウンには大きな弱点がありました。仕様が曖昧だったのです。
たとえば「リストの中に別のリストを入れたらどうなるか」「強調記号が入れ子になったらどう解釈するか」といった細かいルールが定義されておらず、しかもマークダウンには「構文エラー」という概念がありません。どんな書き方をしても何かしらの結果が出力されてしまいます。
その結果、各ツールの開発者が独自の解釈で実装を進め、10年以上かけて実装ごとの挙動がバラバラに分かれていきました。「あるシステムでは正しく表示される文書が、別のシステムでは違う表示になる」という状況が当たり前になってしまったのです。
こうして生まれたのが、数々のマークダウン方言です。
代表的なマークダウン方言
CommonMark：標準化を目指した「共通語」
バラバラになったマークダウンを統一しようと立ち上がったのがCommonMarkプロジェクトです。曖昧だった文法を、大量のテストケース付きで厳密に定義し直しました。
CommonMarkの特徴は、あえて機能を増やさないことです。見出し・段落・リスト・リンク・画像・強調・コード・引用といった基本構文だけを規定し、その代わりエッジケース（例外的な書き方）の解釈を徹底的に定めています。「どのパーサーで処理しても同じ結果になる」ことを最優先にした、いわばマークダウン界の共通語です。
GFM（GitHub Flavored Markdown）：事実上の標準
GFMはGitHubが使っている方言で、CommonMarkの「厳密なスーパーセット」と位置づけられています。つまりCommonMarkのルールはそのまま守りつつ、次のような拡張機能を追加しています。
| 拡張機能 | 記法 |
|---|---|
| テーブル | パイプ | とハイフン - |
| 取り消し線 | ~~テキスト~~ |
| タスクリスト | - [x] 完了項目 |
| 拡張自動リンク | URLをそのまま書くとリンク化 |
意外に思われるかもしれませんが、テーブルはCommonMarkには存在しません。GFMの拡張機能です。「マークダウンといえば表が書ける」というイメージは、GFMが広く普及した結果なのです。
GitHubの影響力もあり、GFMは現在「事実上の標準」として多くのサービスに採用されています。
GitHub独自拡張：GFMのさらに外側
ややこしいことに、GitHub.comで使える機能のすべてがGFM仕様というわけではありません。アラート記法（[!NOTE]）、Mermaid図、絵文字ショートコード（:smile:）、@メンションなどは、GFM仕様ではなくGitHub.com独自のレイヤーです。GitHubの外に持ち出すと基本的に動きません。
その他の主な方言
- Pandoc Markdown：文書変換ツールPandoc用。脚注・引用文献・定義リストなど、学術文書向けの機能が豊富
- MultiMarkdown：メタデータや脚注をサポートした初期の拡張版
- Markdown Extra：PHP向けに拡張されたバージョン
- Goldmark：静的サイトジェネレーターHUGOが採用するGo製パーサー。CommonMark準拠
方言の違いはどこに現れるのか
違い1：使える機能が違う
最もわかりやすい違いです。GFMで書いたテーブルは、CommonMarkのみ対応のパーサーではただのテキストとして表示されます。取り消し線の~~も同様です。
違い2：同じ記法でも解釈が違うことがある
より厄介なのがこちらです。方言によって、あるいは同じ仕様でも実装によって、細部の解釈が異なる場合があります。たとえば、見出しの#の後にスペースが必須かどうか、改行を<br>に変換するかどうか、といった点はツールによって挙動が分かれます。
違い3：仕様通りでも直感に反するケースがある
日本語ユーザーが特につまずきやすい例を一つ紹介します。CommonMark準拠の環境で、次のように書いても太字になりません。
**バッチ処理(Message Batches API)**を使用する
これはバグではなく、CommonMarkの「フランキングルール」という強調判定の規則によるものです。閉じ側の**は、直前が)などの約物の場合、直後が空白か約物でないと「強調の終了」と認識されません。英語ならスペースで単語が区切られるので問題になりませんが、日本語のように文字が連続する言語では引っかかりやすいのです。
この場合は、括弧の外で太字を閉じる（**バッチ処理**(Message Batches API)）か、太字の前後に半角スペースを入れると解決します。CJK言語対応はCommonMark側でも改善が議論されている課題です。
主なプラットフォームはどの方言を使っているか
| プラットフォーム | ベースとなる方言 |
|---|---|
| GitHub / GitLab | GFM（＋独自拡張） |
| HUGO | CommonMark（Goldmark） |
| Obsidian | CommonMark ＋ 独自拡張 |
| Qiita | 独自パーサー（GFM互換に近い） |
| esa.io | CommonMark |
| Notion | 独自実装（マークダウン入力対応） |
| Slack / Discord | 独自仕様（マークダウン風記法） |
注意したいのは、SlackやDiscordのように「マークダウン風だが別物」の記法を持つサービスです。Slackの太字は*一重アスタリスク*であるなど、CommonMarkともGFMとも異なるため、同じ感覚で書くとうまくいきません。
方言とうまく付き合うための3つの指針
1. 迷ったらCommonMarkの範囲で書く
基本構文だけで書かれた文書は、どの環境でもほぼ同じように表示されます。将来別のプラットフォームへ移行する可能性があるなら、CommonMarkの範囲に収めておくのが最も安全です。
2. 拡張機能は「どの方言のものか」を意識する
テーブルや取り消し線を使うときは、「これはGFMの拡張だ」と意識しておきましょう。移植先がGFM対応かどうかで、書き直しの要否が判断できます。GitHub独自機能（アラートやMermaid図）は、さらに移植性が低いことも覚えておくと安心です。
3. 表示が崩れたら「方言の違い」を疑う
書き方を何度見直しても崩れる場合、原因はあなたではなくパーサーの方言かもしれません。使っているプラットフォームがどの仕様を採用しているかを確認し、その仕様のドキュメントに当たるのが解決への近道です。
まとめ
- マークダウンは一つの標準ではなく、複数の方言（フレーバー）が存在する
- 元祖マークダウンの仕様が曖昧だったため、実装ごとに解釈が分かれて方言が生まれた
- CommonMarkは標準化を目指した共通語、GFMはそれを拡張した事実上の標準
- テーブルや取り消し線は「マークダウン標準」ではなくGFMの拡張機能
- プラットフォームごとに採用する方言が違うため、同じ記法でも表示が変わることがある
- 互換性を重視するならCommonMarkの範囲で書くのが安全
「マークダウンはどこでも同じ」という思い込みを手放すだけで、表示崩れに遭遇したときの原因究明がぐっと楽になります。自分がよく使うプラットフォームがどの方言を話しているのか、一度確認してみてはいかがでしょうか。