CommonMark と GFM の違い | 5 つの拡張と対応ツール一覧

TL;DR — CommonMark と GFM の違い

• CommonMark は Markdown の「標準仕様」。見出し・リスト・強調・リンク・画像・コード・引用といった基本構文だけを厳密に定義しています。
• GFM（GitHub Flavored Markdown）は、その GFM spec が「CommonMark の厳密なスーパーセット」と説明している方言。テーブル・取り消し線・タスクリスト・拡張自動リンク・生 HTML の制限という 5 つの拡張を CommonMark に追加しています。
• GitHub.com で使える [!NOTE] などのアラート、絵文字ショートコード、@mention、Issue 参照、Mermaid 図、数式、脚注は GFM spec ではなく GitHub.com 独自のレイヤー。GitHub の外では基本的に動きません。
• 段落内の改行（ソフト改行）を <br> にするかどうかは CommonMark と GFM spec で同じ（<br> にしない）。GitHub.com の Issue / PR コメント欄だけが例外的に改行する設定で、.md ファイルとは挙動が違います。
• どの方言で書くか迷ったら、素の CommonMark に閉じれば最も互換性が高く、GitHub 中心なら GFM 拡張まで使える、と覚えておけば十分です。
• FormatArc の Markdown to HTML は GFM 拡張（テーブル・取り消し線・タスクリスト・自動リンク）に対応した変換ツールです。自分の Markdown が GFM 依存かどうかを確認するのにも使えます。

CommonMark と GFM の関係 — GFM は CommonMark を土台にした拡張仕様

CommonMark は、もともと曖昧だった Markdown の文法をテストスイート付きで厳密に定義し直したプロジェクトです。実装ごとの差をなくし、どのパーサーで処理しても同じ結果になることを目指しています。仕様としては意図的に拡張を取り込まず、見出し・段落・リスト・リンク・画像・強調・コード・引用といったコア構文だけを規定しています。

GFM（GitHub Flavored Markdown） は GitHub が使っている Markdown の方言で、GFM spec 自身が「CommonMark の厳密なスーパーセット（strict superset）」だと説明しています。つまり、文法上は次の関係になります。

• 正しい CommonMark の文書は、GFM パーサーでもまったく同じように描画される
• GFM は CommonMark に対していくつかの拡張を「追加」しているだけで、コア構文を変えてはいない

ただし「スーパーセット」という言葉は GFM spec の説明に限った話で、GitHub.com の実際の表示や、各ライブラリの実装、CommonMark の最新版との細かい差まで含めると例外もあります。本記事では「GFM spec が定義する拡張」と「GitHub.com が独自に足している機能」を分けて整理します。

比較表 — CommonMark と GFM の対応機能

ポイントは 3 列に分かれている点です。テーブルや取り消し線などは GFM spec の拡張なので、GFM 対応のパーサーなら GitHub 以外でも動きます。一方でアラートや絵文字、脚注は GFM spec には含まれず、GitHub.com（やそれを真似たプラットフォーム）でしか保証されません。

実際に HTML へ変換すると何が変わるか

CommonMark だけで処理するパーサーと GFM 対応のパーサーでは、同じ Markdown でも出力 HTML が変わります。次の入力で比べてみます。

| 商品 | 在庫 |
| --- | --- |
| りんご | 3 |

~~売り切れ~~ 在庫あり

- [x] 入荷確認
- [ ] 値札の差し替え

CommonMark のみのパーサーでは、| 商品 | 在庫 | の行はテーブルにならずそのままパイプ記号付きの段落として出力され、~~売り切れ~~ も打ち消し線にならず文字どおりチルダが残り、- [x] は普通のリスト項目になります。GFM 対応のパーサーなら <table>、<del>、<input type="checkbox"> を含む HTML に変換されます。

つまり「Markdown が壊れて見える」と感じたとき、原因がプラットフォームの方言違いであるケースは多いです。手元の Markdown が GFM 拡張に依存しているかどうかを確かめたいときは、Markdown to HTML に貼り付けて出力 HTML を見るのが手早い方法です。

GFM が CommonMark に追加した 5 つの拡張

テーブル

パイプ | とハイフン - で組む表です。CommonMark にはテーブルの定義がないため、テーブルは GFM の拡張機能という位置づけになります。CommonMark のみを実装したレンダラーでは表として描画されず、パイプ付きのテキストがそのまま残ります。配置指定（:--- / :---: / ---:）やセル内パイプのエスケープなど、書き方の詳細は Markdown 表の書き方 にまとめています。

取り消し線

~~取り消したい文字~~ で <del> 要素になります。チルダ 2 つで囲む書き方は GFM の拡張で、CommonMark には含まれません。

タスクリスト

リスト項目の先頭に - [ ]（未完了）または - [x]（完了）を書くとチェックボックスとして描画されます。GitHub では Issue や PR の本文でクリックして状態を変えられますが、その「クリックで切り替わる」挙動は GitHub.com 側の機能で、ただの HTML として出力するレンダラーでは静的なチェックボックスになります。

拡張自動リンク

https://example.com のように URL をそのまま書くと自動でリンクになります。CommonMark で URL をリンクにするには <https://example.com> のように山かっこで囲む必要がありますが、GFM はかっこなしの裸の URL も検出してリンク化します。

生 HTML の制限（disallowed raw HTML）

CommonMark も GFM も、Markdown の中に生の HTML を書くことを許しています。違いは、GFM が <script> / <iframe> / <style> などごく一部のタグを「禁止された生 HTML」として無効化する点です。さらに GitHub.com では、これとは別レイヤーでより厳しい HTML サニタイズがかかります（属性の除去など）。FormatArc の Markdown to HTML は構文変換のみを行うため、信頼できない入力を変換した場合は出力 HTML を別途サニタイズしてください。

GFM spec ではなく GitHub.com 独自の機能

次の機能は「GitHub の Markdown」としてよく紹介されますが、GFM spec には書かれていません。GitHub.com（およびそれを真似た一部のサービス）でだけ動くと考えてください。

• アラート — > [!NOTE] / > [!TIP] / > [!IMPORTANT] / > [!WARNING] / > [!CAUTION] の 5 種類。色付きのコールアウトとして描画されます。
• 絵文字ショートコード — :smile: のような :name: 記法。標準の Markdown には絵文字の概念がありません。
• @mention / Issue・PR 参照 / コミット SHA — @username、#123、コミットハッシュを自動でリンク化します。リポジトリのコンテキストがないと意味を持たない機能です。
• Mermaid 図・数式 — ```mermaid コードブロックや $...$ の数式。これも GitHub.com のレンダリングパイプラインの追加機能です。
• 脚注 — [^1] 形式。GitHub.com はサポートしますが GFM spec の差分ではありません。remark-gfm や Hugo の Goldmark など、ツールによっては GFM 系の拡張とまとめて脚注も有効になる場合がありますが、それは各実装の判断です。

これらを使った Markdown を GitHub の外（README をそのままコピーした先のブログ、ドキュメントツールなど）に持っていくと、多くの場合そのまま素のテキストとして表示されます。GitHub.com 専用の書き方として割り切るのが安全です。

段落内の改行（hard line break）の扱いの違い

ここは誤解が多いポイントです。CommonMark でも GFM spec でも、段落の中で 1 回だけ改行（ソフト改行）した場合は <br> にはならず、前後の行がつながった 1 つの段落になります。改行を <br> にしたいときは、行末に半角スペース 2 つを置くか、行末にバックスラッシュ \ を置くか、<br> タグを直接書く必要があります。これは CommonMark と GFM で共通の挙動です。

例外は GitHub.com の Issue / PR / Discussion のコメント欄で、ここだけは「1 回の改行をそのまま <br> にする」設定になっています。一方で同じ GitHub 上でも .md ファイル（README やドキュメント）は CommonMark / GFM 標準の挙動で、スペース 2 つや \ が必要です。「GitHub のコメント欄では改行できたのに README では改行されない」という現象はこれが原因です。

どのプラットフォーム・ツールがどちらの方言か

正確には「素の CommonMark」「CommonMark + GFM 拡張」「独自方言」のどれに近いか、という見方になります。代表的なものを整理します。

「GFM 対応」と書かれていても、GitHub.com 独自のアラートや絵文字までサポートしているとは限りません。逆に「CommonMark のみ」のツールでも、プラグインを足せば GFM 拡張が使えることが多いです。最終的には使っているライブラリやサービスのドキュメントで「どの拡張が有効か」を確認するのが確実です。

自分の環境が GFM 対応か確認する方法

凝った調査をしなくても、次の手順で大まかに判定できます。

• テーブル（| col |）、取り消し線（~~text~~）、タスクリスト（- [ ]）を 1 つずつ書いてみて、描画されれば GFM 拡張に対応している
• ライブラリを使っているなら設定を見る。marked なら gfm: true、remark なら remark-gfm プラグイン、markdown-it ならデフォルトで GFM のテーブル・取り消し線が有効
• 静的サイトジェネレータなら設定ファイルを確認する。Hugo は markup.goldmark.extensions、Astro は markdown.remarkPlugins に remark-gfm があるか、など

手元の Markdown ファイルがそもそも GFM 拡張に依存しているかを知りたいだけなら、Markdown to HTML に貼り付けて、テーブルや取り消し線が HTML 化されるかを見れば一目でわかります。

どちらを基準に Markdown を書くべきか

• 一番互換性が高いのは素の CommonMark の範囲に閉じることです。どのレンダラーでもほぼ確実に意図どおりに表示されます。
• GitHub やそれに準じたプラットフォーム（GitLab、多くのドキュメントツール）が前提なら、GFM の拡張（テーブル・取り消し線・タスクリスト・自動リンク）まで使って問題ありません。実務ではこの範囲が標準的です。
• [!NOTE] などのアラート、絵文字ショートコード、@mention、Mermaid、脚注は「GitHub.com の外では壊れる前提」で使ってください。README には便利でも、コピーしてブログに貼ると素のテキストになります。
• 配布や移植を考えるなら、生 HTML をなるべく混ぜない方が安全です。CommonMark でも GFM でも、生 HTML を含む文書はサニタイズやレンダラーの実装に挙動が左右されます。

FormatArc の Markdown 変換ツールはどの方言か

FormatArc の Markdown to HTML は、内部で marked を gfm: true で動かしています。そのため次のようになります。

• GFM spec の拡張（テーブル、取り消し線、タスクリスト、拡張自動リンク）はそのまま HTML に変換されます
• 段落内の改行（ソフト改行）は breaks: false 相当の挙動で、<br> にはなりません。CommonMark / GFM spec と同じで、GitHub.com のコメント欄の改行挙動とは異なります
• GitHub.com 独自のアラート（[!NOTE] など）、絵文字ショートコード、@mention、Mermaid、脚注には対応していません。これらは GFM spec の機能ではないためです

逆方向の HTML to Markdown も、出力する Markdown はテーブルや取り消し線を含む GFM 寄りの形式です。どちらもブラウザ内で処理が完結し、登録もアップロードも不要です。社内の未公開ドキュメントを貼り付けても外部に送信されません。

変換の手順を詳しく知りたい場合は Markdown を HTML に変換する方法 を、逆変換は HTML を Markdown に変換する方法 を参照してください。

よくある質問

CommonMark と GFM、どちらで Markdown を書くべきですか？

最も互換性が高いのは素の CommonMark の範囲です。GitHub やそれに準じたプラットフォームが前提なら、GFM の拡張（テーブル・取り消し線・タスクリスト・自動リンク）まで使って構いません。[!NOTE] などの GitHub.com 独自機能は GitHub の外では壊れる前提で使ってください。

CommonMark にテーブル構文はありますか？

ありません。テーブルは GFM の拡張機能で、CommonMark の仕様には含まれていません。CommonMark のみを実装したレンダラーでは | col | がそのままパイプ付きのテキストとして表示されます。書き方の詳細は Markdown 表の書き方 を参照してください。

GitHub の [!NOTE] アラートは他のツールでも使えますか？

基本的に GitHub.com（と一部それを真似たサービス）でしか動きません。GFM spec にはアラートの定義がないため、他の Markdown レンダラーでは > [!NOTE] がそのまま引用ブロックの中のテキストとして表示されます。

Obsidian や Notion は GFM 互換ですか？

完全互換ではありません。Obsidian は CommonMark をベースに GFM のテーブルやタスクリストにも対応しつつ、[[wikilink]] などの独自記法を持っています。Notion も独自方言で、エクスポート時の Markdown は GFM 寄りですが、エディタ内の記法は Notion 固有です。使う前に各ツールのドキュメントで対応記法を確認してください。

FormatArc はどちらの方言で変換しますか？

GFM 寄りです。Markdown to HTML は marked を gfm: true で動かしているため、テーブル・取り消し線・タスクリスト・自動リンクに対応します。段落内の改行は <br> にしません（CommonMark / GFM spec と同じ）。GitHub.com 独自のアラート・絵文字・mention・Mermaid・脚注には対応していません。

関連記事

• Markdown を HTML に変換する方法 — Markdown を HTML へ変換する具体的な手順。GFM のテーブルやタスクリストにも対応。
• Markdown 表の書き方: 配置・エスケープ・コピペできる例 — GFM テーブルの配置指定・パイプのエスケープ・改行の扱いを詳しく解説。
• GFM テーブル チートシート — 配置・パイプのエスケープ・レンダリング結果を 1 ページにまとめた早見表 (GitHub / GitLab / Obsidian / Notion 対応)。
• HTML を Markdown に変換する方法 — Web ページや Notion エクスポートの HTML を GFM 寄りの Markdown に変換する手順。

まとめ

CommonMark は Markdown の標準仕様、GFM はそれを土台に 5 つの拡張（テーブル・取り消し線・タスクリスト・拡張自動リンク・生 HTML の制限）を足した方言です。GitHub.com で見かけるアラートや絵文字、@mention、Mermaid、脚注はさらにその上に乗った GitHub.com 独自のレイヤーで、GitHub の外では基本的に動きません。

どの方言で書くか迷ったら、互換性重視なら CommonMark、GitHub 中心なら GFM 拡張まで、GitHub.com 独自機能は壊れる前提で、と覚えておけば困りません。手元の Markdown が GFM 拡張に依存しているか確かめたいときや、Markdown を HTML へ変換したいときは Markdown to HTML を使ってください。ブラウザだけで完結し、登録もアップロードも不要です。