
WordPress自動投稿でブロックが崩れる3つの原因|直し方と書き方

※本記事にはプロモーション(アフィリエイト広告)を含みます。
WordPressへの自動投稿で、こんな状態になっていませんか?
- 投稿は成功しているのに、編集画面を開くとブロックが1つの塊になっている
- 「このブロックには、想定されていないか無効なコンテンツが含まれています」が出る
- プログラムから送ると、装飾やリストのスタイルだけが効かない
<!-- wp:paragraph -->というコメントが何をしているのか分からない- 公開ページの表示は正しいのに、編集画面だけおかしくて直し方が分からない
- そもそもブロック形式で送る必要があるのか判断できない
結論から書きます。WordPressの自動投稿でブロックが崩れる主な原因は、ブロックの区切りコメントの書き間違い・中身の食い違い・保存時の削除の3つです。
当ブログの運営者は、Claude Codeで3サイトの記事を毎日自動投稿しています。2026年10月に、書き直しのために取り出した87本の本文を数えたところ、56本はブロックの区切りコメントが1つも入っていませんでした。
この記事では、崩れる仕組みを公式の仕様から説明し、当ブログで実際に起きた崩れと、直し方・防ぎ方を書きます。
この記事で分かること
- WordPressのブロックの正体と、「崩れた」の2つの状態
- 自動投稿でブロックが崩れる3つの原因と直し方
- すでに崩れた記事を直す手順
- REST APIでブロック形式を送る最小の書き方
- 当ブログで実際に起きた崩れと、公開前の検算
なお、外部から記事を投稿するには、APIの窓口を自分で管理できるWordPressとレンタルサーバーが前提になります。当ブログのhayamablog.orgはエックスサーバー上のWordPressで運用しています。
結論|ブロックの崩れは「書きかけ」と「削られた」で起きる
WordPressのブロックは、特別なデータ形式ではなく、HTMLを「wp:」で始まるコメントで挟んだものです。このコメントが正しく書かれていれば、自動投稿でもブロックとして扱われます。
「崩れた」には性質の違う2つの状態がある
1つは、編集画面で「このブロックには、想定されていないか無効なコンテンツが含まれています」と出る状態です。もう1つは、記事全体が「クラシック」という1つの塊になる状態です。
前者はブロックの書き方の誤りや中身の食い違い、後者はコメントが入っていないことが原因で、直し方が違います。
公開ページは正しく見えることが多い
どちらの状態でも、公開ページの見た目は正しく表示されることが少なくありません。崩れは編集画面を開いて初めて気づくことが多いので、見た目の確認だけでは見逃します。
前提|WordPressのブロックの正体は「wp:」で始まるHTMLコメント
原因に入る前に、ブロックの仕組みを押さえておきます。仕組みが分かると、崩れた理由がすぐに見当がつきます。
ブロックはコメントで挟んだHTML
WordPress公式のブロックエディタのドキュメントでは、ブロックは <!-- wp:paragraph --> のようなコメントで始まり、<!-- /wp:paragraph --> で閉じると説明されています。コアのブロックは「core/」を省いて書き、テーマやプラグイン独自のブロックは「wp:名前空間/名前」の形になります。
ブロックの設定(属性)は、開きコメントの中にJSONで書きます。
コメントがない部分は「クラシック」として扱われる
区切りのコメントがない部分は、エディタの読み込み時に「クラシック」ブロックとしてまとめて扱われます。だから、HTMLだけを送ると、記事全体が1つの塊になります。
WordPressの自動投稿でブロックが崩れる3つの原因と直し方
ここからは、ブロックが崩れる主な原因を3つ見ていきます。
ブロックが崩れる3つの原因
- POINT 1開閉が合わない閉じ忘れ・書き間違い
- POINT 2中身が食い違う属性とHTMLがずれる
- POINT 3保存時に削られる権限でタグが消える
原因1:開きコメントと閉じコメントが合っていない
開きコメントに対応する閉じコメントがない、名前が違う、といった書き間違いです。AIに長い記事を書かせると、途中で閉じ忘れることがあります。
直し方は、開きと閉じの個数をブロック名ごとに数えて、合わないところを直すことです。当ブログでは、公開前にプログラムで実際に数えています。
原因2:ブロックの属性とHTMLの中身が食い違っている
WordPressのエディタは、開くときにブロックの属性から本来のHTMLを作り直し、保存されているHTMLと一致しないと「無効」と判定します。属性に書いた設定と、実際のHTMLのクラス名などがずれていると、この判定に引っかかります。
直すには、エディタで手作業で1つ作ったブロックを、コード表示でコピーして、その形をそのまま使うのが確実です。
原因3:保存時にタグや属性が削られている
投稿するユーザーが「unfiltered_html」という権限を持っていないと、保存時に許可されていないタグや属性が取り除かれます。その結果、保存されたHTMLが本来の形とずれ、原因2と同じ判定に引っかかります。
初期設定では、この権限を持つのは単一サイトの管理者と編集者だけです。投稿者の権限のユーザーで自動投稿していると、マークアップが削られることがあります。
原因ではないもの:REST APIだからブロックにならない、ではない
「REST APIで投稿するとブロックにならない」と言われることがありますが、REST APIそのものが原因ではありません。本文にコメントを入れて送れば、REST APIでもブロックとして保存されます。
【運営実例】当ブログで起きたブロックの崩れ
ここからは、当ブログの運営で実際に起きたことです。
87本のうち56本が、ブロックの区切りなしで保存されていた
2026年10月に、書き直し対象の87本の本文を数えたところ、ブロックの区切りコメントが入っていたのは31本で、残りの56本にはコメントが1つもありませんでした。同じ仕組みで投稿していても、記事によって書き方が分かれていたことになります。
一方、ブロック形式の31本は、開きと閉じのコメントの数がすべて一致していました。崩れの原因は「書き方が混ざること」で、ブロック形式そのものではありませんでした。
書き直しでは、ブロック形式にそろえている
今進めている書き直しでは、すべての記事をブロック形式で書き、公開前に開閉の数をプログラムで数えています。公開後にも、公開ページに壊れたブロックの印(wp-block-missing)がないかを確かめる仕組みです。
内部リンクのブログカードも崩れていた
関連記事へのブログカードを、URLだけの段落で書いたため、REST APIで投稿するとカードにならずに崩れていたこともあります。今は埋め込みブロック(wp:embed)で書いています。
<!-- wp:embed {"url":"https://example.com/記事のURL","type":"wp-embed"} -->
<figure class="wp-block-embed is-type-wp-embed"><div class="wp-block-embed__wrapper">
https://example.com/記事のURL
</div></figure>
<!-- /wp:embed -->
見た目の確認だけでは足りなかった
AIに「スマホで確認しました」と言わせても、Chrome系の検査だけではiPhone(Safari系)の崩れを見逃しました。今は、iPhoneと同じ表示エンジン(WebKit)で全ページを撮って目で見ています。
ブロックの崩れは編集画面で、表示の崩れは実機で、と確かめる場所を分けるのが大切だと考えています。
すでに崩れた記事を直す手順
ここからは、崩れてしまった記事を直す手順です。REST APIで自動投稿している人向けに書きます。
手順1:保存されている本文データを取得する
REST APIで記事を取得するとき、context=edit を付けると、保存されている本文そのもの(content.raw)が返ります。表示用に変換された content.rendered では、コメントが消えていて原因が分かりません。
curl -u "ユーザー名:アプリケーションパスワード" \
"https://example.com/wp-json/wp/v2/posts/記事ID?context=edit&_fields=content"
手順2:開きと閉じの個数を数えて、原因を絞り込む
取得した本文で、ブロック名ごとに開きと閉じの個数を数えます。合わなければ原因1、合っているのに崩れるなら原因2か原因3を疑います。
手順3:正しい本文で同じ記事を上書きする
直した本文を、同じ記事IDに送り直して上書きします。新しい記事として投稿すると、二重投稿になるので注意してください。
手順4:もう一度取得して、送った内容と突き合わせる
更新したら、もう一度 content.raw を取得して、送った本文と一致しているかを確かめます。一致しなければ、保存時に削られている(原因3)可能性があります。
REST APIでブロック形式を正しく送る最小の書き方
ここでは、自動投稿でよく使うブロックの最小の書き方を載せておきます。迷ったら、エディタで手作業で作ったものをコード表示でコピーするのが確実です。
段落と見出し
段落は wp:paragraph、見出しは wp:heading で挟みます。見出しの階層を変えるときは、開きコメントに属性を書きます。
<!-- wp:paragraph -->
<p>本文の段落です。</p>
<!-- /wp:paragraph -->
<!-- wp:heading {"level":3} -->
<h3 class="wp-block-heading">小見出し</h3>
<!-- /wp:heading -->
テーマ独自のブロックは、手で1つ作ってコピーする
テーマ独自のブロック(吹き出しやボックスなど)は、名前も属性もテーマごとに違います。名前から推測して書くと原因2になりやすいので、手で1つ作ってコピーするのが唯一の確実な方法です。
状況別|ブロックの崩れへの対処の選び方
自分の状況によって、取るべき手は変わります。状況別に答えを出しておきます。
| 状況 | おすすめの手 |
|---|---|
| 無効なコンテンツと出る | 開閉と属性を確認 |
| 記事全体が1つの塊 | ブロック形式で送る |
| 投稿者権限で投稿 | 権限とksesを確認 |
| 独自ブロックが崩れる | 手で作ってコピー |
「無効なコンテンツ」と出る人は、開閉と属性を確かめる
まず開閉の数を数え、合っていれば属性とHTMLのずれを疑ってください。エディタの「ブロックのリカバリーを試行」で直ることもあります。
記事全体が塊になる人は、ブロック形式で送り直す
コメントなしで送っているのが原因です。これから送る記事をブロック形式に変え、既存の記事は必要に応じて書き直してください。
投稿者の権限で自動投稿している人は、権限を見直す
保存時にタグが削られている可能性があります。投稿に使うユーザーの権限と、送っているタグが削られていないかを確かめてください。
WordPressの自動投稿とブロックの崩れに関するよくある質問
最後に、ブロックの崩れについてよくある質問に答えます。
ブロック形式で送らないと、SEOで不利になりますか?
公開ページの表示が正しければ、ブロック形式かどうかで検索の評価が変わるという公式の説明は見当たりません。ただ、編集画面で直しにくくなるので、運用の面ではブロック形式にそろえるほうが楽です。
クラシックの記事を、後からブロック形式に変えられますか?
エディタには、クラシックのブロックをブロックに変換する機能があります。記事が多い場合は、REST APIで本文を書き直して送るほうが早いこともあります。
Claude Codeに書かせるとき、どう指示すればいいですか?
ブロックの書き方の見本を渡し、「この形だけを使う」と指示するのが確実です。そのうえで、公開前に開閉の数をプログラムで数えさせると、閉じ忘れを防げます。
Claude CodeとWordPressのつなぎ方は、別の記事でまとめています。


投稿が401で通らないときはどうすればいいですか?
ブロックの崩れとは別に、認証情報がWordPressまで届いていない可能性があります。当ブログでも、web-prepa.comではnginxが認証ヘッダーを落としてREST APIが通らず、XML-RPCに切り替えました。


まとめ|ブロックの崩れは、書き方をそろえて数えれば防げる
WordPressの自動投稿でブロックが崩れる主な原因は、開閉の書き間違い、属性とHTMLの食い違い、保存時の削除の3つです。コメントがない記事は、崩れというより「クラシック」の1つの塊として扱われます。
当ブログでも、書き直し対象の87本のうち56本がブロックの区切りなしで保存されていました。今はすべてブロック形式で書き、公開前に開閉の数を数える形にそろえています。
自動投稿の環境をこれから用意するなら、REST APIが素直に通るサーバーを選ぶところからです。
当ブログが使っているエックスサーバー公式のほか、比べて選ぶならConoHa WING公式も候補になります。料金はキャンペーンで変わるので、申し込む前に公式で確認してください。
-
URLをコピーしました!

















