はじめに
日本語の文章を書いていて、次のようなMarkdownを書いたことはないでしょうか。
人間の感覚では、「一番」を鉤括弧ごと太字にしたいだけです。
ところが、Markdownビューアによっては、意図した通りに太字にならず、** がそのまま残ることがあります。さらに同じような書き方が複数回出てくると、単に全部失敗するのではなく、別の ** 同士が結びついて、想定外の範囲が太字になることもあります。
本稿では、この現象をCommonMark系のMarkdown仕様から整理します。
最初に注意点を書いておきます。
この記事は、AI利用の有無を判定する方法を示すものではありません。人が手書きしたMarkdownでも同じ表示崩れは起こります。本稿の目的は、日本語文中におけるMarkdown強調記法の挙動を整理し、公開前のプレビュー確認や記法調整の重要性を示すことです。
一方で、生成AIの出力では、日本語文中にも英語圏的なMarkdown強調が自動挿入されることがあります。そのため、** の残留や意図しない太字化が、「AI出力をそのまま貼ったのではないか」という疑惑につながりやすい面もあります。ただし、それはあくまでMarkdown記法上の痕跡であり、AI利用の決定的証拠ではありません。
本稿の結論を先にまとめると、次の通りです。
-
**は単純な囲み記号ではなく、前後の文字によって開始・終了可否が判定される - 日本語では分かち書きをしないため、鉤括弧や句読点と
**が密接し、期待と違う解釈になりやすい -
**の残留はAI利用の決定的証拠ではないが、生成AI出力で露呈しやすいMarkdown上の痕跡ではある
この前提で、最小再現パターンから見ていきます。
1. 最小再現パターン
まず、手元で確認したパターンを並べます。
確認環境は以下です。
| 項目 | 内容 |
|---|---|
| markdown-it | 14.2.0 |
| markdown-it preset | commonmark |
| commonmark.js | 0.31.2 |
| micromark | 4.0.2 |
本稿執筆時、2026年5月30日現在の状況です。
将来、環境により、表現結果が異なる可能性を考慮し、一部の出力結果は執筆時の内容を画像として貼付しています。
Qiita本番環境そのものを完全に再現したものではありません。Qiita公式ヘルプでは、2022年2月にMarkdownパーサーがCommonMarkerベースへ変更され、基本的にGitHub Flavored Markdownに準拠すると説明されています1。そのため、本稿では「CommonMark/GFM系で起こり得る挙動」として扱います。
| No | パターン | Markdownソース | CommonMark系での観察結果 |
|---|---|---|---|
| 3 | 鉤括弧なし | それが、**一番**大事だ。 |
それが、一番大事だ。 |
| 比較的安定して太字化される | |||
| 4 | 閉じ側の後ろを 読点にする |
それが、**「一番」**、大事だ。
|
それが、「一番」、大事だ。 |
」**、 のように後続が句読点だと閉じやすい |
|||
| 5 | 鉤括弧を 強調範囲の 外に出す |
それが「**一番**」大事だ。 |
それが「一番」大事だ。 |
| 回避策として安定しやすい | |||
| 6 | 前後に スペースを 入れる |
それが **「一番」** 大事だ。 |
それが 「一番」 大事だ。 |
| 英語圏的な書き方では安定 しやすい |
補足すると、次のように閉じ側の後ろを読点にした自然な形も、CommonMark系では通りやすくなります。
それが、**「一番」**、大事だ。
表示結果の例は次の通りです。
つまり、問題は「日本語だから必ず壊れる」という話ではありません。
より正確には、分かち書きをしない日本語文中で、通常文字、全角鉤括弧、句読点、半角アスタリスクが密接したとき、Markdownパーサーの強調開始・終了判定が、人間の期待とズレることがある、という問題です。
2. ** は単純な囲み記号ではない
多くの人は、Markdownの太字を次のように理解しています。
**ここが太字**
これは実用上はだいたい正しい理解です。
ただし、CommonMark仕様では、** は単純に「左から見つけた ** と右から見つけた ** で囲む」という処理ではありません。CommonMarkでは、* や _ の連続を delimiter run と呼び、その前後の文字を見て、強調の開始になれるか、終了になれるかを判定します2。
CommonMark仕様では、ざっくり言うと次のような判定が行われます。
| 概念 | ざっくりした意味 |
|---|---|
| delimiter run |
* または _ が連続した区切り文字列 |
| left-flanking delimiter run | 強調の開始側になり得る区切り文字列 |
| right-flanking delimiter run | 強調の終了側になり得る区切り文字列 |
| strong emphasis |
**...** や __...__ による強い強調、通常はHTMLの <strong>
|
CommonMark仕様では、double ** がstrong emphasisの開始になれるのは、それがleft-flanking delimiter runの一部である場合です。また、double ** がstrong emphasisの終了になれるのは、それがright-flanking delimiter runの一部である場合です3。
ここが重要です。
** は、見た目としては同じ ** でも、文中で置かれた位置によって、次のように役割が変わります。
** の状態 |
起こり得ること |
|---|---|
| 開始になれる | 後ろの文字列を太字範囲として開始できる |
| 終了になれる | 前から始まった太字範囲を閉じられる |
| 開始にも終了にもなれる | 前後関係により、どちらの役割にもなり得る |
| どちらにもなれない | 文字としてそのまま残る |
つまり、Markdownソース上では正しそうに見えても、仕様上は「その ** は閉じ記号として扱えません」と判定されることがあります。
3. 日本語の鉤括弧で起きやすい理由
では、なぜ日本語文中の **「一番」** は崩れやすいのでしょうか。
理由は大きく3つあります。
| 理由 | 説明 |
|---|---|
| 日本語は分かち書きをしない | 英語のように単語間へ自然にスペースが入りにくい |
| 鉤括弧が文中に密接する |
文字 + ** + 「 や 」 + ** + 文字 が起こりやすい |
| 鉤括弧や句読点は約物として扱われる | 前後文字の種類によって、開始・終了判定が変わる |
約物（やくもの、英: punctuation mark）：言語の記述に使用する、記述記号類の総称。ここでは説明を簡単にするため、全角鉤括弧や句読点をまとめて「約物」と呼びます。厳密には、CommonMark仕様ではUnicode punctuation characterとして扱われる文字種が強調判定に関係します。
たとえば、次のケースを見ます。
それが、**「一番」**大事だ。
書く人の意図はこうです。
しかし、Markdownパーサーは、書く人の意図ではなく、** の前後の文字を見ます。
先頭側の ** は、前が読点 、、後ろが開き鉤括弧 「 です。ここは開始候補になり得ます。
一方で、閉じ側として期待している ** は、前が閉じ鉤括弧 」、後ろが通常文字の 大 です。この形では、CommonMark系の判定では終了側として扱われにくくなります。
その結果、開始と終了の対応が成立せず、次のように ** がそのまま残ることがあります。
この挙動は、CommonMarkのIssueでもCJK punctuation、つまりCJK文字圏の句読点・約物と強調記法の相性として議論されています4。Issue上でも、日本語は一般に文中へスペースを入れないため、英語では期待通りに強調される文が、日本語では失敗する例が挙げられています。
ここで重要なのは、「日本語が悪い」でも「ブラウザが悪い」でもないということです。
Markdownの仕様と、日本語の自然な書き方の相性が、特定の位置関係でズレるという話です。
4. 複数の ** があると、なぜ別の範囲が太字になるのか
単体では ** が残るだけに見えるケースでも、同じパターンが複数回出ると、よりややこしい表示になります。
たとえば、次のMarkdownを見ます。
それが、**「一番」**大事だ1。それが、**「一番」**大事だ2。それが、**「一番」**大事だ3。
CommonMark系の観察結果は、概ね次のようになります。
書く人の期待は、それぞれの **「一番」** が独立して太字になることです。
しかし実際には、意図したペアではなく、仕様上ペアになれる ** 同士が結びつきます。
かなり単純化すると、次のような流れです。
| 順番 | 人間の期待 | パーサー上の起こり方の例 |
|---|---|---|
1個目の**
|
1つ目の 開始 |
開始候補になるが、対応する終了が見つからない |
2個目の**
|
1つ目の 終了 |
」**大 の形になり、終了ではなく開始候補として扱われる |
3個目の**
|
2つ目の 開始 |
前後条件により、2個目を閉じる側として扱われることがある |
4個目の**
|
2つ目の 終了 |
また開始候補として扱われる |
5個目の**
|
3つ目の 開始 |
4個目を閉じる側として扱われることがある |
6個目の**
|
3つ目の 終了 |
終了としても開始としても成立せず、残ることがある |
ここで起きているのは、単純な「直近の ** 同士をペアにする」処理ではありません。
CommonMark/GFMでは、強調の開始・終了には前後文字に基づく条件があり、さらに複数の解釈があり得る場合の優先ルールもあります3。そのため、人から見ると「2個目と3個目が勝手にペアになった」ような表示になります。
さらに、末尾に ** を追加すると、次のようになります。
それが、**「一番」**大事だ1。それが、**「一番」**大事だ2。それが、**「一番」**大事だ3。**
観察結果の例です。
末尾の ** が追加されたことで、最後に残っていた開始候補が閉じられ、さらに別の範囲が太字になります。
これも「壊れた」というより、パーサーが仕様に従って、開始可能性・終了可能性・前後文字の条件から役割を割り当てた結果と考える方が自然です。
ただし、実際の表示はMarkdownパーサー、ビューア、レンダリング実装、拡張記法の有無に依存します。Qiita、GitHub、VS Codeプレビュー、markdown-it、note、ChatGPTビューアなどで、完全に同じ表示になるとは限りません。公開前には、必ず投稿先のプレビューで確認する必要があります。
5. 回避策
実務上は、仕様を完全に暗記するより、壊れにくい書き方を決めておく方が安全です。
5.1 鉤括弧を強調範囲の外に出す
もっとも自然な回避策は、鉤括弧を太字範囲の外へ出すことです。
それが「**一番**」大事だ。
表示例です。
この方法では、鉤括弧自体は太字になりません。
しかし、日本語文として不自然なスペースを入れずに済みます。Qiita記事では、かなり扱いやすい回避策です。
5.2 前後にスペースを入れる
Qiita公式ヘルプでも、強調したい場合は次のように前後へスペースを入れる例が示されています1。
それが **「一番」** 大事だ。
表示例です。
Markdownとしては安定しやすい書き方です。
ただし、日本語文ではスペースが少し不自然に見えることがあります。技術記事では許容できても、小説、エッセイ、ニュース文体では気になる場合があります。
5.3 閉じ側の直後を句読点にする
文として許されるなら、閉じ側の後ろに読点を置く方法もあります。
それが、**「一番」**、大事だ。
表示例です。
ただし、文章のリズムが変わります。
句読点をMarkdownのためだけに増やすと、文体が崩れる場合があります。あくまで文章として自然な場合に使うべきです。
5.4 HTMLタグを使う
投稿先が許可している場合は、HTMLタグを使う方法もあります。
それが、<strong>「一番」</strong>大事だ。
表示例です。
Markdownの強調判定を避けられるため、意図は明確です。
ただし、サービスによってはHTMLタグがサニタイズされたり、利用できるタグが制限されたりします。QiitaではHTML記法も一定範囲で扱えますが、投稿先ごとの仕様確認が必要です。
5.5 生成AI出力をそのまま貼らず、人間が調整する
生成AIは、次のようなMarkdownを自然に出力することがあります。
これは **「重要」** なポイントです。
英語圏のMarkdown感覚では、強調の前後にスペースを置くことが多いため、この形なら通りやすいです。
一方で、日本語としてスペースを詰めると、次のようになります。
これは**「重要」**なポイントです。
この形は崩れやすくなります。
AI出力を使うかどうかにかかわらず、公開前には次の確認が必要です。
| 確認項目 | 見るポイント |
|---|---|
** が残っていないか |
強調記法が文字として露出していないか |
| 意図しない範囲が太字になっていないか | 複数の ** が別ペアになっていないか |
| 投稿先のプレビューで確認したか | ローカルプレビューだけで判断していないか |
| 日本語として不自然なスペースがないか | Markdown都合で文体が崩れていないか |
6. 生成AI時代の注意点
ここからは、少し社会的な観察です。
筆者の観察では、生成AIの文章には、見出し、箇条書き、太字、表などのMarkdownが含まれることが少なくありません。
しかし、日本語文中でMarkdown強調が多用されると、今回のような表示崩れが起こりやすくなります。
たとえば、公開記事の中に次のような文字が残っていたとします。
これは**「重要」**なポイントです。
読者によっては、「AIが出したMarkdownをそのまま貼ったのではないか」と感じるかもしれません。
ただし、ここは慎重に扱うべきです。
** の残留は、AI利用の決定的証拠ではありません。Markdownに慣れていない人間でも起こします。手書きでも起こります。エディタ、プレビュー、投稿先の実装差でも起こります。
そのため、本稿で言えるのは、次の範囲までです。
| 言えること | 言えないこと |
|---|---|
** の残留は、Markdown強調記法の処理ミスとして説明できる |
AI利用の有無を断定できる |
| 生成AI出力ではMarkdown強調が入りやすく、露呈しやすい | AIだけが起こすミスだとは言えない |
| 公開前プレビューの重要性が上がっている | 表示崩れだけで著者の執筆プロセスは判定できない |
生成AI時代に重要なのは、「AIを使ったかどうか」よりも、最終的に公開する文章を人間が確認したかどうかです。
Markdownは、ソースが正しそうに見えても、表示結果が期待とズレることがあります。特に日本語文中の **「...」** は、公開前に必ずプレビューで確認した方が安全です。
おわりに
Markdownの太字記法 **...** は、見た目ほど単純ではありません。
CommonMark/GFM系のMarkdownでは、** の前後にある文字によって、強調の開始になれるか、終了になれるかが判定されます。
日本語は英語のように分かち書きをしないため、通常文字、全角鉤括弧、句読点、半角アスタリスクが密接しやすい書き方です。その結果、Markdownソース上では正しそうに見えても、ビューア上では ** が残ったり、意図しない範囲が太字化されたりすることがあります。
実務上の回避策は、次の通りです。
| 回避策 | おすすめ度 | 備考 |
|---|---|---|
「**一番**」 のように鉤括弧を外へ出す |
高 | 日本語文として自然にしやすい |
**「一番」** のように前後へスペースを入れる |
中 | Markdownとして安定しやすいが、日本語では不自然な場合がある |
**「一番」**、 のように後続を句読点にする |
中 | 文として自然な場合のみ使う |
<strong>「一番」</strong> を使う |
中 | 投稿先がHTMLを許可する場合に有効 |
| 投稿前にプレビュー確認する | 必須 | 最終的には表示結果で確認する |
Markdownは、人間にとって書きやすい記法です。
しかし、書きやすいことと、常に直感通りに解釈されることは別です。
生成AIの出力を使う場合も、自分で手書きする場合も、日本語文中の強調記法は最後にプレビューで確認する。これだけで、かなりの表示崩れは防げます。
注意書き
この記事は、AI利用の有無を判定する方法を示すものではありません。人間が手書きしたMarkdownでも同じ表示崩れは起こります。本記事の目的は、日本語文中におけるMarkdown強調記法の挙動を整理し、公開前のプレビュー確認や記法調整の重要性を示すことです。
参考
-
Qiita Markdown - Qiita ヘルプ。QiitaのMarkdownパーサー変更、GFM準拠、強調記号前後スペースに関する説明 ↩ ↩2
-
CommonMark Spec 0.31.2 - Emphasis and strong emphasis。delimiter run、left-flanking delimiter run、right-flanking delimiter run、およびstrong emphasisの判定規則の根拠 ↩
-
GitHub Flavored Markdown Spec - Emphasis and strong emphasis。GFMにおけるCommonMark系の強調判定規則の根拠 ↩ ↩2
-
commonmark/commonmark-spec Issue #650 - Emphasis with CJK punctuation。CJK句読点とMarkdown強調の相性問題に関するIssue ↩