ChatGPTのMarkdownをWordPressに貼ると崩れる？ Gutenbergブロックへ変換する方法

ChatGPTやClaudeで記事本文をMarkdownまで作れても、WordPressへの入稿作業は別に残ります。

raw Markdownをそのまま貼ると、見出しやリストが期待どおりブロック化されないことがあります。逆に、AIへ毎回「WordPressのGutenberg形式にして」と頼むと、形式変換だけでなく本文やリンクまで変わっていないか確認する必要があります。

そこで、AIにはMarkdownまで作ってもらい、MarkdownからGutenbergブロックへの変換は別工程に分けると扱いやすくなります。

WordPressのBlock Editorは、段落・見出し・リストなどを独立したブロックとして扱い、保存時には<!-- wp:paragraph -->のようなHTMLコメントを含む独自のブロック形式へシリアライズします。raw Markdownとは別の文書構造です。

結論・前提・確認した仕様

完成済みのraw Markdownを安定してWordPressへ移したいなら、Gutenbergの標準ブロック形式へ変換し、コードエディターへ貼ってからVisual Editorへ戻す方法が再現しやすいです。

2026年4月6日にWordPress公式Gutenbergリポジトリへ登録された「Improve Markdown support」では、Markdownをコピー＆ペーストしてもBlock Editorやフロント側で整形されないことが改善対象として挙げられており、2026年8月27日時点でも議論中です。

一方、ChatGPTなどですでに見出しや太字として表示された文章をコピーした場合は、コピー元が渡すHTML等の書式をGutenbergが受け取れるため、ある程度そのまま貼れる場合があります。ただし、Gutenberg公式リポジトリでもコピー元・貼り付け先によって書式保持結果が変わる報告があります。

この記事ではWordPress標準のBlock Editorを前提にします。テーマやプラグインが追加する独自ブロックまでは自動変換の対象にしません。

raw Markdownと「AI画面に表示された文章」は分けて考える

次のMarkdownを例にします。

## 調査結果

**結論**としてAを選びます。

- 理由1
- 理由2

この文字列をMarkdownファイルやコードブロックからコピーしたものがraw Markdownです。

Gutenbergは2026年現在、raw Markdown全文の貼り付けを汎用的にブロック変換する仕様として完成しているわけではありません。そのため##や**が文字として残る、期待したブロックにならない、といった結果が起こり得ます。

一方、ChatGPTやClaudeの回答画面で、すでに見出しや太字として描画された文章をコピーした場合は、Markdownソースではなくリッチテキストとして貼られることがあります。

「Markdownを貼る」と「Markdownから描画された文章を貼る」は同じ操作ではありません。

短い文章なら後者を直接貼って確認する方法でも十分ですが、Markdownファイルを原稿の正本として持つ場合や、長文を毎回同じ形で移したい場合は、クリップボード任せにしない方が管理しやすくなります。

WordPressに限らず、AIの文章を別アプリへ貼ったときに書式が崩れる仕組みは、ChatGPTの文章をコピペすると書式が崩れるのはなぜ？で整理しています。

Gutenbergが保存しているのはブロックのシリアライズ形式

WordPress公式のBlock Editor Handbookでは、ブロックはHTMLへシリアライズされ、そのブロック境界をHTMLコメントで表す仕組みが説明されています。

段落ブロックなら、概念的には次の形です。

<!-- wp:paragraph -->
<p>これは段落です。</p>
<!-- /wp:paragraph -->

見出しならwp:heading、リストならwp:listというように、文章の意味がブロック種別として残ります。

Markdownも文章構造を持っていますが、表現方法が違います。

したがって、安定した移行で必要なのは「記号を消すこと」ではなく、MarkdownのAST上の意味をGutenbergブロックへ写すことです。

MarkdownをGutenbergブロックへ変換して貼る手順

ここでは「AIにGutenbergコードそのものを生成させる」のではなく、AI → Markdown → ブロック変換という流れに固定します。

この方法なら、文章の生成と媒体固有の変換を分離できます。AIに公開先の細かな形式まで毎回覚えさせる必要もありません。

ブラウザMarkdownエディタ「Yomu」では、Markdownを編集したあと、WordPress向けのブロック形式へ書き出せる設計にしています。

Yomu — ブラウザで使えるMarkdownエディタ

1. AIにはMarkdown原稿まで作ってもらう

まず原稿をMarkdownとして完成させます。

WordPress向けのブロックコードまでAIに出させるのではなく、ここでは一般的なMarkdownで文章構造を確定します。

WordPress側で文章そのものを大きく直すのではなく、内容修正は原本側で済ませてから変換すると、Markdown版とWordPress版の差分が増えにくくなります。

AIへ原稿を書かせる場合は、記事タイトルを本文へ重ねず、本文見出しをH2から始めるよう指定しておくと扱いやすくなります。

WordPressの記事本文として使うMarkdownを書いてください。
記事タイトルは本文に含めず、主要見出しはH2、その下位はH3にしてください。

2. YomuでMarkdownとしてプレビューする

変換前に、見出し階層、リストの入れ子、表、コードフェンス、リンクを確認します。

Markdown自体が壊れている状態でGutenbergへ変換すると、変換後に原因が分かりにくくなります。

3. WordPressブロック向けに書き出す

Yomuで標準Markdown要素をGutenbergの標準ブロックへ変換します。

この段階で重要なのは、通常HTMLではなく<!-- wp:... -->を含むWordPressがブロックとして再解釈できる保存形式へすることです。

4. WordPressをコードエディターへ切り替える

記事編集画面の右上にある三点メニューから「Code editor」へ切り替えます。

WordPress公式ドキュメントでは、Visual EditorとCode Editorを切り替えるショートカットも案内されています。

WindowsではCtrl + Shift + Alt + M、MacではShift + Option + Command + Mです。

5. 変換済みブロックコードを貼る

新規下書きのコードエディターへ、Yomuで生成したブロックコードを貼ります。

6. Visual Editorへ戻す

再びVisual Editorへ戻し、見出し、段落、リスト、引用、コード、表がそれぞれ独立したブロックとして認識されているか確認します。

その後に一度下書き保存し、ページを再読み込みします。ブロックのシリアライズが不正なら、再読込時に「予期されていない、または無効なコンテンツ」といったブロック検証エラーが出ることがあります。

単なるHTML変換とGutenbergブロック変換は違う

MarkdownをHTMLへ変換すると、たとえば次のようになります。

<h2>調査結果</h2>
<p>本文です。</p>

これはWebページとしては正しいHTMLです。しかし、Gutenbergが後から「Headingブロック」「Paragraphブロック」として管理するためのブロック境界は含みません。

WordPressへ一度表示できればよいだけならHTMLでも足りる場合がありますが、公開後もBlock Editorで普通に編集し続けるなら、Gutenbergブロックとして入れた方が扱いやすくなります。

どこまで自動変換し、どこからWordPress側で仕上げるか

変換ツールで全てを自動化しようとすると、WordPress固有機能との境界で破綻します。

標準的な文章構造は変換する

段落、H2/H3、太字、リンク、リスト、引用、コード、単純な表など、Markdown側にも意味がある要素はGutenbergの標準ブロックへ移します。

画像はメディアライブラリへ自動アップロードしない

Markdownの![alt](path)は画像参照です。WordPressのImageブロックとして正式に使うには、最終的にはWordPressのメディアライブラリへ画像を登録する必要があります。

YomuはWordPressの認証情報を受け取って投稿するツールではないため、画像アップロードはWordPress側で行います。

CTA・吹き出し・FAQなどの独自ブロックはWordPress側で追加する

テーマやプラグインが追加したブロックは、サイトごとに仕様が違います。標準Markdownから汎用的に生成する対象にはしません。

本文を移した後、必要な場所へCTA、FAQ、商品ボックスなどを追加する方が安全です。

表は変換成功だけでなくスマートフォン表示まで見る

Markdown表をTableブロックへ変換できても、それで記事として完成とは限りません。

列数が多い、セル内の文章が長い、URLが大量に入る、といった表はスマートフォンで読みにくくなります。

ここは「技術的に変換できたか」と「読者が読めるか」を分けて判断します。列を減らす、比較項目を縦にする、重要な結論を本文へ出すなど、最終レイアウトはWordPress側で調整します。

同じMarkdown原稿をnoteにも使う場合は、ChatGPT・Claudeをnoteにコピペすると崩れる？で、note側の制約と変換方法を整理しています。

コードでは<や>が欠けていないか確認する

Codeブロックへ変換する場合、コード中のHTMLタグや特殊文字が通常HTMLとして解釈されていないか確認します。

見た目だけではなく、コピーしたときに元コードが保持されるかまで確認すると技術記事として安全です。

raw Markdownを直接貼る方法を完全に捨てる必要はない

短い原稿なら、変換工程を増やすより直接貼ってみる方が速いこともあります。

ただし2026年8月時点では、WordPress公式側でもraw Markdown貼り付けの改善は未完了です。直接貼った結果が毎回同じになることを前提にせず、問題なくブロック化されたらそのまま使う、崩れるならブロック変換へ切り替えるという運用が現実的です。

表示済みのChatGPT・Claude回答をコピーする場合も、コピー元アプリや貼り付け先によって書式保持結果が変わる報告があるため、長文では公開前チェックを省かない方がよいです。

公開前原稿なら、変換処理がどこで行われるかも見る

社内記事や公開前のSEO原稿を変換するだけなら、本文を変換サーバーへ送る必要はありません。

Yomuは文章変換をブラウザ内で行う設計にし、本文をWordPress向けへ変換するためだけの外部送信を行わない方針です。

オンラインツールへ未公開原稿を貼る場合の確認方法は、オンラインMarkdownエディタは安全？ ファイルを送信しないツールの見分け方で整理しています。

最後に確認する順番

公開前は、リストビューでブロック構造を見てからプレビューすると確認が速くなります。

1. H2/H3の階層
2. Listブロックの入れ子
3. Quote・Code・Tableブロック
4. リンクURL
5. 画像と独自ブロック
6. 下書き保存後の再読み込み
7. PC・スマートフォンのプレビュー

まとめ

WordPress GutenbergとMarkdownは、どちらも文章構造を扱いますが、保存形式は別です。

2026年8月現在、raw Markdownのコピー＆ペーストはWordPress公式側でも改善課題として残っています。長文を安定して移す場合は、MarkdownをGutenbergのブロック形式へ先に変換し、コードエディター経由で読み込ませる方法に意味があります。

ポイントは、AIに文章生成とWordPress固有形式への変換を一度に任せないことです。AIにはMarkdownまで作ってもらい、公開時にGutenbergブロックへ変換すれば、入稿工程を固定しやすくなります。

原稿はMarkdownとして残し、WordPressには公開用のブロック形式を渡す。この分離にすると、同じ原稿をnoteやはてなブログ、Wordへ展開するときにも使い回せます。

Word形式へも展開する場合は、MarkdownをWordに変換する方法でDOCX出力との使い分けを整理しています。

Markdownをブラウザで編集し、そのままWordPress標準ブロックへ変換したい場合は、Yomuを使えます。

参考

• WordPress Gutenberg Issue #77064「Improve Markdown support」
• WordPress Gutenberg Issue #72006「Formatting lost when pasting text from certain apps」
• Block Editor Handbook「Key Concepts」
• Block Editor Handbook「Paragraph」
• WordPress.org「Use keyboard shortcuts (Block Editor)」