ChatGPT・ClaudeのMarkdownをWordPressへ入稿する方法を解説。通常貼り付け、書式なし貼り付け、Gutenbergブロック変換を順に試し、Yomuが必要な条件を整理します。
目次(10)
ChatGPTやClaudeで記事本文をMarkdownまで作れても、WordPressへの入稿作業は別に残ります。
raw Markdownをそのまま貼ると、見出しやリストが期待どおりブロック化されないことがあります。逆に、AIへ毎回「WordPressのGutenberg形式にして」と頼むと、形式変換だけでなく本文やリンクまで変わっていないか確認する必要があります。
そこで、AIにはMarkdownまで作ってもらい、MarkdownからGutenbergブロックへの変換は別工程に分けると扱いやすくなります。
WordPressのBlock Editorは、段落・見出し・リストなどを独立したブロックとして扱い、保存時には<!-- wp:paragraph -->のようなHTMLコメントを含む独自のブロック形式へシリアライズします。raw Markdownとは別の文書構造です。
結論:WordPress標準の貼り付けを先に試し、必要なときだけブロック変換する
2026年9月15日時点では、WordPress Block EditorにはMarkdownを扱う貼り付け経路があります。
Gutenberg Issue #70065では、Paste as plain text / Paste and Match Format(一般に Ctrl/Cmd + Shift + V)でMarkdown構文を貼ると、対応する構文がブロックへ変換される挙動が説明されています。一方、2026年4月に登録されたIssue #77064では、Markdownのコピー&ペースト体験全体を改善する提案が現在も議論中です。
さらに、ChatGPTなどからコピーした表示済みのリッチテキストは、Web版・デスクトップ版・モバイル版などコピー元によって書式保持結果が変わる例もWordPress公式Gutenbergリポジトリで報告されています。
したがって、実務では次の順で試すのが合理的です。
| 状況 | 最初に試す方法 | 次の手段 |
|---|---|---|
| ChatGPT・Claudeの表示済み文章 | 通常貼り付け | 崩れた部分だけ修正 |
| raw Markdown | 書式なし貼り付け / Match Format | 対応しない要素を確認 |
| 長文を毎回同じブロック構造へ移す | Gutenbergブロックへ変換 | コードエディター経由で読み込む |
| 独自ブロック・CTA・画像 | WordPress側で追加 | テーマ・プラグイン仕様に合わせる |
短い文章ならWordPress標準機能で十分な場合があります。 Yomuが意味を持つのは、Markdown原本を保ちながら長文を繰り返しGutenbergの標準ブロックへ移したい場合です。
この記事ではWordPress標準のBlock Editorを前提にします。テーマやプラグインが追加する独自ブロックまでは自動変換の対象にしません。
raw Markdownと「AI画面に表示された文章」は分けて考える
次のMarkdownを例にします。
## 調査結果
**結論**としてAを選びます。
- 理由1
- 理由2
この文字列をMarkdownファイルやコードブロックからコピーしたものがraw Markdownです。
Gutenbergにはraw Markdownを変換する貼り付け経路がありますが、通常貼り付け・書式なし貼り付け・コピー元の形式で結果が変わります。特に複雑なコードフェンスやコピー元固有のHTMLではIssueが残っているため、##や**が文字として残る、期待したブロックにならない、といった結果は起こり得ます。
一方、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 | Gutenberg |
|---|---|---|
| 段落 | 通常テキスト | Paragraphブロック |
| 見出し | ## / ### |
Headingブロック |
| 箇条書き | - |
Listブロック |
| 引用 | > |
Quoteブロック |
| コード | コードフェンス | Codeブロック |
| 表 | ` | ... |
したがって、安定した移行で必要なのは「記号を消すこと」ではなく、MarkdownのAST上の意味をGutenbergブロックへ写すことです。
MarkdownをGutenbergブロックへ変換して貼る手順
ここでは「AIにGutenbergコードそのものを生成させる」のではなく、AI → Markdown → ブロック変換という流れに固定します。
この方法なら、文章の生成と媒体固有の変換を分離できます。AIに公開先の細かな形式まで毎回覚えさせる必要もありません。
ブラウザMarkdownエディタ「Yomu」では、Markdownを編集したあと、WordPress向けのブロック形式へ書き出せる設計にしています。
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へ戻し、見出し、段落、リスト、引用、コード、表がそれぞれ独立したブロックとして認識されているか確認します。
その後に一度下書き保存し、ページを再読み込みします。ブロックのシリアライズが不正なら、再読込時に「予期されていない、または無効なコンテンツ」といったブロック検証エラーが出ることがあります。
Gutenbergへ貼る前の共通テスト原稿
投稿本文をすべて変換する前に、次の短い原稿で「段落・見出し・リスト・リンク・表」を確認します。
## 納品前チェック
本文に **強調** と [リンク](https://example.com/) を入れる。
- A
- B
| 項目 | 値 |
| --- | ---: |
| 数量 | 3 |
貼り付け直後に見えていることと、下書き保存して再度開いたときにブロック構造が保たれることは別の確認です。Custom HTMLブロックへすべて押し込む前に、標準の見出し・段落・リスト・表の各ブロックとして適切に編集できるかを確認してください。
受け側の権限や環境で許されないHTML要素が除去される場合もあるため、変換HTMLの文字列がそのまま保存されることを成功条件にしないことが重要です。
変換後にWordPress側で確認すること
単なる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のは画像参照です。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として解釈されていないか確認します。
見た目だけではなく、コピーしたときに元コードが保持されるかまで確認すると技術記事として安全です。
WordPress標準だけで済むケースを先に切り分ける
短い原稿なら、変換工程を増やすより直接貼ってみる方が速いことがあります。
raw Markdownの場合は、通常貼り付けだけでなく「書式なし貼り付け / Paste and Match Format」も試します。Gutenbergにはこの経路でMarkdown構文をブロックへ変換する処理があります。
ただし、Markdownのすべての構文やコピー元を同じ精度で扱えるわけではありません。WordPress公式リポジトリではMarkdown貼り付け改善が継続しており、コードフェンスやコピー元アプリによる差も報告されています。
したがって、標準貼り付けで問題なくブロック化されたらそのまま使う。再現性が不足する長文だけブロック変換へ切り替えるという運用が現実的です。
公開前原稿なら、変換処理がどこで行われるかも見る
社内記事や公開前のSEO原稿を変換するだけなら、本文を変換サーバーへ送る必要はありません。
Yomuは文章変換をブラウザ内で行う設計にし、本文をWordPress向けへ変換するためだけの外部送信を行わない方針です。
オンラインツールへ未公開原稿を貼る場合の確認方法は、オンラインMarkdownエディタは安全? ファイルを送信しないツールの見分け方で整理しています。
最後に確認する順番
公開前は、リストビューでブロック構造を見てからプレビューすると確認が速くなります。
- H2/H3の階層
- Listブロックの入れ子
- Quote・Code・Tableブロック
- リンクURL
- 画像と独自ブロック
- 下書き保存後の再読み込み
- PC・スマートフォンのプレビュー
よくある質問
WordPressにMarkdownを貼ると`##`や`**`がそのまま残るのはなぜ?
通常貼り付けでは、コピー元のHTMLやプレーンテキストなど別の表現が優先される場合があります。raw Markdownなら「書式なし貼り付け / Paste and Match Format」を試してください。それでも変換されない要素や、長文で再現性が必要な場合はGutenbergブロック形式へ変換します。
ChatGPTの画面からコピーした文章はそのまま貼ってもいい?
表示済みの文章はリッチテキストとして貼られるため、ある程度そのまま使える場合があります。ただしコピー元・貼り付け先によって書式保持の結果が変わる報告があるので、長文では公開前チェックを省かない方がよいです。
MarkdownをHTMLに変換して貼るのではだめ?
一度表示できればよいだけならHTMLでも足りる場合があります。ただし通常のHTMLには<!-- wp:... -->のブロック境界が含まれないため、公開後もBlock Editorで編集し続けるならGutenbergブロックとして入れた方が扱いやすくなります。
貼り付け後に「予期されていない、または無効なコンテンツ」と出るのは?
ブロックのシリアライズが不正なときに出るブロック検証エラーです。コードエディターへ貼ったあとは、Visual Editorへ戻して各ブロックを確認し、下書き保存して再読み込みしてから確かめます。
画像はYomuの変換で一緒にWordPressへ入る?
入りません。Markdownの画像記法は参照情報で、YomuはWordPressの認証情報を受け取って投稿するツールではないため、画像はWordPress側でメディアライブラリへ登録します。
まとめ
WordPress GutenbergとMarkdownは、どちらも文章構造を扱いますが、保存形式は別です。
2026年9月15日現在、WordPressにはMarkdown変換の貼り付け経路がある一方、Markdown貼り付け体験全体の改善は公式Gutenbergリポジトリで継続しています。長文を安定して移す場合は、MarkdownをGutenbergのブロック形式へ先に変換し、コードエディター経由で読み込ませる方法に意味があります。
ポイントは、AIに文章生成とWordPress固有形式への変換を一度に任せないことです。AIにはMarkdownまで作ってもらい、公開時にGutenbergブロックへ変換すれば、入稿工程を固定しやすくなります。
原稿はMarkdownとして残し、WordPressには公開用のブロック形式を渡す。この分離にすると、同じ原稿をnoteやはてなブログ、Wordへ展開するときにも使い回せます。
Word形式へも展開する場合は、MarkdownをWordに変換する方法でDOCX出力との使い分けを整理しています。
Markdownをブラウザで編集し、そのままWordPress標準ブロックへ変換したい場合は、Yomuを使えます。
参考
- WordPress Gutenberg Issue #70065「Pasting Markdown as plain text...」
- 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)」