* で始めた行が勝手に箇条書きになる。# 価格一覧 と書いたらページの見出しになった。<version> と書いたはずの文字がプレビューから消えている。どれも Markdown が記号を「書式の指示」として解釈したことが原因で、エラーは一切出ません。この記事では、記号をそのまま表示するためのエスケープの書き方を、4 つのレンダラーで 22 例を実測した結果とあわせて解説します。
まず結論 — 記号の前にバックスラッシュを 1 つ置く
表示したい記号の直前にバックスラッシュ \ を 1 つ書きます。これだけです。
\*これは斜体になりません\*
バックスラッシュ自体は表示に残りません。上の例は、先頭と末尾のアスタリスクも含めて *これは斜体になりません* という文字列がそのまま表示されます。
バックスラッシュ自身を表示したいときは 2 つ重ねて \\ と書きます。
症状から引く早見表
「何が起きたか」から原因の記号を逆引きできるようにまとめました。すべて後述の実測で確認した症状です。
| 起きたこと | 原因 | 直し方 |
|---|---|---|
| 斜体・強調になった | * や _ で語を挟んでいる | \* \_ を前置 |
| 行全体が見出しになった | 行頭の # + スペース | \# にする |
| 番号付きリストになった | 行頭の「数字 + ピリオド」 | 1986\. のようにピリオドを \. |
| 箇条書きになった | 行頭の - や * | \- \* にする |
| 文字が画面から消えた | < と > で囲んだ語 | \< と \> にする |
| 表のセルが割れた・セルの後半が消えた | セル内の縦棒 | 縦棒の前に \（詳細は後述） |
エスケープできる記号の一覧
CommonMark 仕様の Backslash escapes別タブで開きます は「Any ASCII punctuation character may be backslash-escaped」（あらゆる ASCII 記号はバックスラッシュでエスケープできる）と定めています。対象は次の 32 記号です。
! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~
裏返しの規則が 2 つあり、こちらが事故のもとになります。
- 対象は ASCII 記号だけです。英数字の前のバックスラッシュはただの文字として残ります。同仕様は「Backslashes before other characters are treated as literal backslashes」と明記しており、
\nと書いても改行にはならず、バックスラッシュと n がそのまま表示されます - 全角の記号（「」や ※ など）はそもそも書式にならないので、エスケープは不要です。前にバックスラッシュを置くと、バックスラッシュ自体が見えてしまいます
もう 1 つ重要なのは、エスケープが必要かどうかは文字単体ではなく「出現位置」で決まることです。# が見出しになるのは行頭にあってスペースが続くときだけで、文中の # はそのままで安全です。次のセクションの実測で、この境界を具体的に確認します。
実測 — エスケープなしで何が起きるか、エスケープは効くか
エスケープの解説記事は多くありますが、「エスケープしなかったら実際に何が起きるのか」「バックスラッシュはどの実装でも本当に効くのか」を検証付きで示したものはほとんどありません。そこで 22 ケースを 4 つの実装に通して確かめました。対象は GitHub の本番レンダラー（Markdown API 経由）、marked 18.0.5、remark-gfm 4.0.1、拡張なしの CommonMark（remark-parse 単体）です。測定日は 2026-07-15、再現スクリプトと生データはリポジトリ内 scripts/benchmarks/markdown-escape-characters/ にあります。
主要なケースの結果です。
| 入力（実測ケースの文字列） | エスケープなしの結果 | エスケープ後の結果 |
|---|---|---|
Buy the *limited edition* today. | 斜体になる（4 実装一致） | \*limited edition\* でそのまま表示（4 実装一致） |
行頭の # price list | h1 見出しになる（4 実装一致） | \# price list でそのまま表示（4 実装一致） |
行頭の 1986. What a year. | 1986 番から始まる番号付きリストになる（4 実装一致） | 1986\. What a year. でそのまま表示（4 実装一致） |
Replace <version> with 2.0 | <version> が画面から消える（4 実装一致） | \<version\> で表示される（4 実装一致） |
表セル内の grep a | b | 縦棒でセルが割れ、ヘッダー列数を超えた分は捨てられる（GFM 系 3 実装一致） | バックスラッシュ前置で 1 セルに収まる（GFM 系 3 実装一致） |
「数字 + ピリオド」のリスト化は特に見落としやすい事故です。1. でも 1986. でも、行頭にあれば番号付きリストとして解釈され、続きの文が字下げされます。年号や型番で文を始めるときはピリオドを \. にしてください。
書いた Markdown が手元のレンダラーでどう解釈されるかは、Markdown to HTML に貼り付けるとその場で確認できます。変換はブラウザ内で完結し、貼り付けた内容はどこにもアップロードされません。
なお、この 4 実装はいずれも CommonMark 系で、エスケープの基本動作はきれいに一致しました。実装ごとの方言差がどこに出るのかは CommonMark と GFM の違い で別途検証しています。
実はエスケープしなくていいケース
過剰なエスケープはソースの可読性を落とすだけでなく、diff レビューのノイズにもなります。実測で「エスケープ不要」と確認できた代表例が 3 つあります。
- 単語内のアンダースコア。
max_retry_count_limitのような snake_case は 4 実装すべてでそのまま表示されました。単語の途中の_は強調として解釈されません - スペースなしの
#hashtag。見出しになるのは#の後にスペースがあるときだけで、#hashtagは 4 実装すべてでただの文字列でした - URL が続かない角かっこ。
[TODO] 後で直すのような書き方は 4 実装すべてでそのまま表示されました。ただし文書内のどこかに[TODO]: https://...という参照リンク定義があるとリンクに化けるので、その場合だけ\[TODO\]とします
注意したいのは、アスタリスクはアンダースコアと対称ではないことです。foo*bar*baz のような単語内のアスタリスクは 4 実装すべてで斜体になりました。snake_case の感覚でアスタリスクを放置すると事故になります。
バックスラッシュが効かない場所
CommonMark 仕様は「Backslash escapes do not work in code blocks, code spans, autolinks, or raw HTML」（バックスラッシュエスケープはコードブロック・コードスパン・自動リンク・生 HTML の中では働かない）と定めています。実測でも、コードスパンとコードブロックの中に書いた \* は 4 実装すべてでバックスラッシュごと表示されました。
これは 2 つの実務的な意味を持ちます。
- コードブロックの中では何もエスケープしなくてよい。
*も#もそのまま書けば、そのまま表示されます - コードの中でエスケープしようとすると逆に壊れる。
`\*`と書くと、表示されるのは*ではなく\*です
もう 1 つ、行末には固有の罠があります。仕様上「A backslash at the end of the line is a hard line break」（行末のバックスラッシュは強制改行）で、実測でも 4 実装すべてが行末の \ を <br> に変換しました。行末の記号をエスケープしたつもりでバックスラッシュを最後に置くと、記号ではなく改行が増えます。
消える記号 — 山かっこ < > は要注意
他の記号は「意図しない書式になる」だけですが、< と > は文字が消える方向に壊れます。プレースホルダを <version> のように書く習慣があると踏みやすい事故です。
実測では、Replace <version> with 2.0 という行の <version> は 4 実装すべてで画面から見えなくなりました。消え方は実装で異なります。GitHub はサニタイザが除去するため本文から消え、marked と remark は生の HTML タグとしてそのまま出力するため、ブラウザが未知のタグとして飲み込みます。どちらのルートでも読者には見えません。
直し方は 2 つあります。
Replace \<version\> with 2.0
Replace `<version>` with 2.0
\<version\> は 4 実装すべてで山かっこ付きの文字として表示されました。コマンドやコードの一部として見せたい場合は、コードスパンで囲むほうが意図も伝わります。
文書全体の例外 — 表のセルの中の縦棒だけは特別
ここまでの規則は文書のどこでも同じですが、表のセルの中の縦棒 | だけは事情が違います。表は CommonMark 本体ではなく GFM の拡張仕様別タブで開きますで、セルに生の縦棒があるとそこで列が区切られます。さらに GFM 仕様はヘッダー行より多い列を「the excess is ignored」（超過分は無視する）と定めており、実測でも grep a | b と書いたセルは縦棒で割られたうえ、後半の b が黙って捨てられました（GFM 系 3 実装一致）。データが静かに消えるという意味で、この事故だけは質が違います。
セル内の縦棒はバックスラッシュ前置でエスケープするか、HTML の文字参照 | で書きます。実測ではどちらも GFM 系 3 実装すべてで 1 セル内の縦棒として表示されました。
| command |
| --- |
| grep a \| b |
| grep a | b |
CSV やスプレッドシートのデータから Markdown の表を作る場合は、CSV to Markdown がセル内の縦棒を自動でエスケープした表を生成します。手作業でセルを目視チェックする必要はありません。変換はブラウザ内で完結します。
コードとして見せたいならコードスパンで囲む
バックスラッシュの代わりにコードスパン（バッククォートで囲む）でも記号はそのまま表示できます。ただし使い分けは明確です。
- 文章の一部として記号を見せたい場合はバックスラッシュ。
価格は \*予告なく\* 変更されますのように書けば、地の文の見た目を保ったまま記号だけが残ります - コード・コマンド・ファイルパス・正規表現として見せたい場合はコードスパン。
C:\Users\nameや\d+のような文字列は、等幅で表示されるほうが読者にも意図が伝わります
コードスパンの中ではエスケープ処理そのものが働かないため、正規表現の \d+ をそのまま書けるのが利点です。既存の HTML ページやリッチテキストを Markdown に変換する場面でのエスケープの扱いは、HTML から Markdown への変換ガイドも参考にしてください。
よくある質問
どの記号がエスケープできますか
ASCII の記号 32 種すべてです（CommonMark 仕様別タブで開きます）。英数字や全角記号の前のバックスラッシュはエスケープにならず、バックスラッシュ自体が文字として残ります。
\n と書いたのに改行されません
\n はプログラミング言語の改行記法で、Markdown のエスケープではありません。バックスラッシュ + 英字はそのまま表示されます（実測で 4 実装一致）。Markdown で改行したい場合は、空行を挟んで段落を分けるか、行末にバックスラッシュを置いて強制改行にします。
snake_case のアンダースコアはエスケープが必要ですか
不要です。単語内の _ は 4 実装すべてで強調と解釈されませんでした。ただしアスタリスクは別で、foo*bar*baz は単語内でも斜体になります。
表のセルの中の縦棒はどうエスケープしますか
縦棒の前にバックスラッシュを置くか、文字参照 | を使います。実測では両方とも GFM 系 3 実装で有効でした。CSV から表を生成するなら CSV to Markdown が自動でエスケープします。
コードブロックの中でバックスラッシュや記号を見せたいときは
何もしなくて構いません。コードブロックとコードスパンの中ではエスケープ処理自体が働かないため、* も \ もそのまま書けばそのまま表示されます。逆に \* と書くとバックスラッシュまで表示されます。
まとめ
- 記号をそのまま表示する基本は、直前にバックスラッシュを 1 つ置くことです。対象は ASCII 記号 32 種で、英数字には効きません
- snake_case・
#hashtag・URL が続かない角かっこはエスケープ不要です。過剰なエスケープはソースを汚します - コードブロック・コードスパンの中ではエスケープ自体が働きません。行末のバックスラッシュは強制改行になります
<>は文字が消える方向に壊れ、表のセル内の縦棒はデータが欠落する方向に壊れます。この 2 つだけは優先的に対処してください
書き上げた Markdown がどう表示されるかは、Markdown to HTML に貼り付ければその場で確認できます。無料で、登録も不要で、貼り付けた内容がブラウザの外に出ることもありません。