WordPressの自動投稿でブロックが崩れる3つの原因|254本を数えて分かった記法の実態

※本記事にはプロモーション(アフィリエイト広告)を含みます。

先に立場を明かします。このブログの記事は、AI(Claude Code)が書いてWordPressのREST API経由で自動公開しています。

2026年7月10日から9月21日までの74日間で、3つのカテゴリ合わせて254本が公開されました(2026年9月21日時点の集計)。

この記事を書くために254本すべての本文データを数えたところ、200本はブロック形式で、54本はブロックを区切るコメントが1つも入っていませんでした。

同じサイトの同じ仕組みなのに、2つの書き方が並走していました。毎日投稿している本人が、この検証をするまで気づいていませんでした。

この記事では、その判断の根拠を実測で示します。検証用の下書きに十数通りの書き方をまとめて入れ、REST APIに投げて保存後のデータと出力がどう変わったかを1つずつ確認しました。

あわせて、この検証の途中で、自分がやっていた崩れチェックが機能していなかったことも分かりました。その訂正も含めて書きます。

なお、この記事の内容はWordPressが自分の管理下にあること(＝レンタルサーバーで動かしていること)が前提です。WordPressを自分で動かせる環境があれば、ここに書いた手順はそのまま試せます(当ブログはエックスサーバーで運用しています)。

結論|WordPressの自動投稿でブロックが崩れる原因は3つ。対処は「全部書く」か「全部やめる」の二択

最初に結論を書きます。REST APIからの自動投稿でブロックが崩れる原因は、記法を使っていないことではなく、ブロック記法を使いかけて途中でズレていることにほぼ集約されます。

つまり、きちんと最後まで書くか、いっそ一切使わないかのどちらかであれば壊れません。危ないのは中間です。

「崩れた」には性質の違う2つの状態がある

同じ言葉でも中身は別物です。まずここを分けないと、直す方向を間違えます。

1つ目は、編集画面に警告が出る状態です。「このブロックには、想定されていないか無効なコンテンツが含まれています」と表示され、ブロックがエラー扱いになります。

これが本来の意味での「壊れた」です。

2つ目は、警告は出ないけれど本文がまとまった塊として扱われる状態です。段落ごとに分かれません。

これは壊れているのではなく、最初からブロックとして扱われていないだけです。

原因は3つしかなく、どれも「書きかけ」から生まれる

実際に試した範囲では、崩れの原因は3種類に収まりました。開閉コメントの数が合っていない、ブロックの属性とHTMLの中身が食い違っている、実在しないブロック名を書いている、の3つです。

いずれも、ブロック記法を部分的に使っているときにだけ起きます。次の章で、原因ごとに何が起きたかを実測とセットで書きます。

この記事で確かめたこと・確かめていないこと

この記事の実測は、実際にREST APIへ投稿し、保存されたデータと出力側のHTMLを取得して確認した範囲です。何を送ると何が保存され、公開側にどう出るかは実物で確かめています。

一方で、編集画面を実際に開いて警告が出るかどうかは確認していません。この記事で編集画面の話をするときは、WordPressの公式資料に書かれている仕組みの説明として扱い、断定を避けています。

また、実測はすべて当ブログの環境(WordPressテーマはSWELL)で、管理者権限のアプリケーションパスワードを使って行ったものです。権限やテーマが違えば結果が変わる可能性があります。

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

ここから原因ごとに見ていきます。自動生成した本文を投げている場合、ほとんどは原因1か原因2のどちらかに当たります。

それぞれ、実際に壊れた形を送って何が起きたかを確認しました。

原因1|開きコメントと閉じコメントの数が合っていない

最も多く、最も被害が大きいのがこれです。試しに、閉じコメントを1つだけ抜いた段落を本文の途中に入れて投稿しました。

保存後のデータを見ると、その段落は閉じられないまま次のブロックが始まり、後続のブロックが未完了の段落の内側に入る形になっていました。さらに本文の末尾には、送っていないはずの <!-- /wp:paragraph --> が1つ増えていました。

なぜ末尾に補われたのかまでは特定できていないので、ここは「自分の環境ではこうなった」という観測として書いておきます。いずれにせよ、送った本文と保存された本文が一致していないこと自体が異常です。

問題は、1か所のミスがその場で止まらず後ろ全部に波及することです。しかも投稿自体はエラーにならないので、投げた側は成功したと判断してしまいます。

直し方は単純で、投稿する前に開きと閉じの個数を数え、一致しなければ送らないようにするだけです。具体的な数え方は後半の検算の章に書きます。

原因2|ブロックの属性とHTMLの中身が食い違っている

コメント側に {"className":"is-style-check_list"} と書いたなら、HTML側にも同じクラスが必要です。片方だけ直したときに起きやすいズレです。

試しに、属性に {"className":"zure"} と書きながらHTML側には別のクラスを付けた段落を投げました。結果は、公開側の出力ではエラーにならず、そのまま表示されました。

ただしこれは「問題ない」という意味ではありません。WordPressの公式資料には、編集画面の読み込み時に、保存されているHTMLとブロックの定義から作り直したHTMLを突き合わせて検証し、一致しなければそのブロックを無効として扱う、という仕組みが説明されています(developer.wordpress.org・2026年9月時点)。

つまりこの種のズレは、公開ページに出ないまま編集画面側だけで問題になる形です。表示が正常なことは、何の保証にもなりません。

クラス名だけではありません。見出しの {"level":3} に対して <h2> を書く、画像の {"id":123} に対応しないURLを書く、といった不一致も同じ扱いです。

直し方は、属性を手で組み立てないことに尽きます。次の章のテンプレのように、属性とHTMLがセットになった形をそのまま使ってください。

原因3|実在しないブロック名を書いている

テーマやプラグインが追加するブロックには、それぞれ固有の名前(スラッグ)があります。これは推測できる決まりではなく、そのテーマの実装そのものです。

実際に存在しないブロック名を作って投げてみたところ、投稿は成功し、公開側には中身のHTMLだけがそのまま出力されました。エラーも警告も出ません。

当ブログが使っているSWELLの場合、吹き出しブロックは wp:loos/balloon、FAQブロックは wp:loos/faq という名前で保存されています。テーマ名から推測できる形ではありません。

直し方は、テーマ独自ブロックだけは推測で書かないことです。管理画面で手作業で1つ作って保存し、そのデータを取り出して記法をコピーするのが確実です。

これは原因ではない|REST APIで投稿するとブロックエディタにならない(1つの塊になる)

最後に、原因と間違われやすいものを1つ外しておきます。コメントを一切付けていない場合、それは崩れではありません。

この状態では警告も出ず、公開ページの表示も正常です。問題になるのは、編集画面で段落ごとに分かれてほしいときだけです。

「編集画面を開いたら1つの塊だった」という症状でここに来た方は、直すべきはエラーではなく方針だということになります。どちらを選ぶかは、後半の運営実例が判断材料になるはずです。

すでに崩れた記事を直す手順【WordPressの自動投稿】

原因が分かっても、すでに公開してしまった記事は残ります。ここでは、崩れた記事を洗い出して直すまでの流れを4段階に分けて書きます。

1本ずつ編集画面で開いて直す方法もありますが、自動投稿で記事数が積み上がっている場合は現実的ではありません。数えて絞り込むところから始めます。

手順1|保存されている本文データを取得する

まず、記事の生データを取り出します。REST APIで ?context=edit を付けて取得すると、編集画面が扱っているのと同じ形が返ってきます。

curl -u "ユーザー名:アプリケーションパスワード" \
  "https://example.com/wp-json/wp/v2/posts/123?context=edit&_fields=content"

この context=edit は認証が必要です。認証なしで取得すると表示用に加工された本文が返り、ブロックコメントが含まれないので確認になりません。

手順2|開きと閉じの個数を数えて対象を絞り込む

取得した本文に対して、開きコメントと閉じコメントの数を数えます。一致していない記事だけが、原因1に当たる候補です。

開き: <!-- wp:    の出現数
閉じ: <!-- /wp:   の出現数
※ 画像や区切り線など単体で完結するブロックは
   <!-- wp:image ... /--> の形なので、開きの数から除く

当ブログでこれを200本に対して実行したところ、不一致は0本でした。全記事を1本ずつ開いて確認するより、はるかに早く安全を確認できます。

手順3|正しい本文で同じ記事を上書き更新する

対象が絞れたら、正しい形に直した本文で同じ記事IDに対して更新をかけます。新しく投稿し直すと重複記事になるので、必ず更新にしてください。

直し方に迷ったら、前の章の最小テンプレの形に合わせるのが確実です。テーマ独自ブロックが絡んでいる場合は、管理画面で1つ作り直して記法を取り直します。

手順4|更新後にもう一度取得して突き合わせる

更新したら、その記事をもう一度取得して、送った本文と保存された本文が一致しているかを比べます。ここが最後の関門です。

検証で確認したとおり、送った内容と保存された内容がズレることは実際に起こります。更新できたという結果だけで判断しないでください。

記事数が多いときは、直す前に方針を決める

崩れている記事が数十本を超える場合は、1本ずつ直す前に「今後どちらの方式でいくか」を先に決めたほうが早く終わります。

ブロック形式で揃えるなら、テンプレを1つ作って全記事を作り直す形になります。コメントを使わない方式に寄せるなら、コメントを取り除いてクラス名だけを残す形です。

どちらにしても、方針を決めずに個別対応を続けると、記法が混在したまま記事だけが増えます。当ブログが実際にそうなりました。

【コピー用】REST APIでブロック形式を正しく送る最小テンプレ

ブロック形式で送ると決めたなら、必要なのは正しい形の見本です。ここでは当ブログの記事から実際の保存データを取り出し、そのまま使える形に整えました。

いずれも管理画面で手作業で作った記事から取り出したものなので、推測ではなく、WordPressが実際に保存している形です。

ただし保存される形はWordPressやテーマのバージョンで変わります。運用に入れる前に、自分の環境で同じブロックを1つ作って見比べてください。

段落ブロック(wp:paragraph)

最も基本の形です。段落ブロックの中は <p> が1つで、標準の状態ではクラスは付きません。

<!-- wp:paragraph -->
<p>本文のテキスト</p>
<!-- /wp:paragraph -->

改行を入れたいときは <br> を使います。段落を分けたいときは、このかたまりごと増やします。

見出しブロック

見出しは、H2であれば属性を省略できます。ただしHTML側には wp-block-heading というクラスが付く点に注意してください。

<!-- wp:heading -->
<h2 class="wp-block-heading">見出しのテキスト</h2>
<!-- /wp:heading -->

<!-- wp:heading {"level":3} -->
<h3 class="wp-block-heading">小見出しのテキスト</h3>
<!-- /wp:heading -->

H3以下は {"level":3} のように階層を属性で指定し、HTML側のタグも合わせます。ここが食い違うと原因2に当たります。

リストブロック

リストは入れ子になっていて、外側のリスト本体と、内側の各項目がそれぞれ別のブロックです。

内側を省略しても公開側の出力は同じでした。ただしリストブロックは項目も1つのブロックとして扱う作りなので、編集画面では無効と判断される可能性があります(実機では確認していません)。

<!-- wp:list -->
<ul class="wp-block-list"><!-- wp:list-item -->
<li>1つ目の項目</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>2つ目の項目</li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

テーマ独自のスタイルを当てる場合は、属性とHTMLの両方に同じクラスを書きます。<!-- wp:list {"className":"is-style-check_list"} --> と <ul class="is-style-check_list wp-block-list"> をセットにする形です。

属性側の className に wp-block-list は書きません。こちらはWordPressが付けるクラスだからです。

画像ブロック

画像は属性が多く、最もズレやすいブロックです。先にメディアライブラリへアップロードし、返ってきたIDを属性とクラスの両方に使います。

<!-- wp:image {"id":1234,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large"><img
  src="https://example.com/wp-content/uploads/2026/09/sample.jpg"
  alt="画像の説明" class="wp-image-1234"/></figure>
<!-- /wp:image -->

属性の id と、img タグの wp-image-1234 は同じ番号でなければいけません。sizeSlug と size-large も対応しています。

テーマ独自ブロックは「手で1つ作ってコピー」が唯一の正解

吹き出しやFAQのようなテーマ独自ブロックは、名前も属性もテーマごとに違います。当ブログの吹き出しは <!-- wp:loos/balloon {"balloonID":"2924"} --> のように、テーマ内部のIDを属性に持っています。

この数字は管理画面で登録した設定に紐づくもので、外から推測して書けるものではありません。推測で書いた時点で原因3に当たります。

手順としては、管理画面でそのブロックを1つ使った記事を保存し、本文データを取り出して記法を確認します。REST APIであれば ?context=edit を付けて取得すると、保存されている生の形が見られます。

なお ?context=edit での取得には認証が必要です。認証なしだと表示用に加工された本文が返り、ブロックコメントが含まれません。

どのサーバーで動かすかで迷っている場合はAIブログのサーバーの選び方にまとめています。

前提|WordPressのブロックの正体は「wp:」で始まるHTMLコメント

ここまでの話が腑に落ちない場合は、ブロックが何でできているかを知っておくと一気に理解が進みます。短く整理します。

ブロックは専用のデータ形式ではなく、コメントで挟んだHTML

WordPressのブロックは、独自のデータベース構造ではありません。普通のHTMLを、WordPress専用のHTMLコメントで挟んだだけのものです。

このコメントはブラウザには表示されません。WordPressが「ここからここまでが段落ブロック」と判断するための目印としてだけ機能します。

だからプログラムから送れます。実際に試したところ、管理者権限のアプリケーションパスワードで投稿した場合、送ったコメントは削られずそのまま保存されていました。

コメントがない部分は「クラシック」としてまとめて扱われる

では、このコメントがないHTMLはどうなるのか。WordPressはエラーにせず、旧エディタ形式のかたまりとして受け取ります。

WordPressの公式リファレンスでは、本文を解析する parse_blocks() という関数において、ブロック名が特定できない部分はブロック名が空の要素として返される仕様が説明されています(developer.wordpress.org・2026年9月時点)。

この「ブロック名のない部分」が、編集画面でいうクラシックブロックにあたります。本文全体にコメントがなければ全体が1つにまとまり、コメントが混ざっていれば、その隙間ごとに分かれます。

そしてREST APIは、ブロック記法が正しいかどうかを検証しません。

ただし保存前にWordPress側の処理は通るため、送った文字列が一字一句そのまま残るとは限りません。実際、原因1の検証では末尾にコメントが1つ増えていました。

記法が間違っていても投稿のレスポンスは正常に返ってくる、という自動投稿の落とし穴はここから生まれます。認証まわりで同じ構造につまずいた話はWordPressの自動投稿が401で通らない原因にまとめています。

【運営実例】同じサイトの自動投稿で、2つの書き方が並走していた

ここからは、当ブログが実際にどう投稿しているかという話です。この記事を書くために全記事を調べたところ、予想と違う結果が出ました。

自分では「ブロック形式は使っていない」と思っていました。実際には2つの書き方が同じサイトの中で並んで動いていました。

254本を全件数えたら、200本がブロック形式だった

74日間で自動公開した254本すべての本文データを取得し、wp: で始まるコメントの数を数えました。結果は次のとおりです。

カテゴリ	本数	ブロック形式	コメントなし
英会話	101本	101本	0本
漫画・アニメ	85本	85本	0本
ブログ	68本	14本	54本
合計	254本	200本	54本

カテゴリごとにきれいに分かれていました。英会話と漫画・アニメは1本の例外もなくブロック形式で、ブログ系だけが途中から切り替わっていました。

ブロック形式の記事は、1本あたり120個から420個のコメントを含んでいます。自動生成でも、この規模のブロック記法は問題なく出力できていました。

ブログ系だけが、3回にわたって記法を行き来していた

ブログ系68本を公開日順に並べると、切り替わった場所がはっきり出ました。

• 7月30日〜31日の5本はブロック形式
• 8月1日からコメントなしに変わり、その後もときどきブロック形式が混ざる
• 8月27日から31日までの6本は、また全部ブロック形式に戻っている
• 9月1日以降の21本は、1本の例外もなくコメントなし

原因は、記事を書くときに参照している手順書がカテゴリごとに分かれていることです。英会話と漫画・アニメの手順書にはブロック記法の見本が入っていて、ブログ系の手順書には入っていませんでした。

つまり意図して選んだのではなく、参照する文書が違ったせいで勝手に分岐していたということです。毎日投稿している本人が、この検証をするまで気づいていませんでした。

ブロック形式の200本は、開閉の数が1本残らず一致していた

崩れているのではないかと思い、ブロック形式の200本について開きコメントと閉じコメントの個数を突き合わせました。画像のように単体で完結するブロックは除いて数えています。

不一致は0本でした。1本あたり数百個のコメントを含む記事が200本あって、そのすべてで数が合っていました。

ここから言えるのは、自動生成だからブロック記法が壊れる、ということはないという点です。見本さえ正しければ、機械のほうが人間より確実に守ります。

それでもブログ系をコメントなしのまま続けている理由

分岐に気づいたあとも、ブログ系は当面そのままにしています。理由は2つあります。

1つは、表示に効いているのがクラス名のほうだからです。テーマの装飾はCSSのクラスに当たっているので、クラス名さえ正しければ見た目は再現できます。

検証中に、これを裏づける挙動も確認できました。ブロックコメント付きで送った段落には出力時にテーマ由来のクラスが付き、コメントなしで送った段落には付きませんでした。

自分でクラスを書けば同じ出力になります。

もう1つは、途中で切り替えると記事によって作りがさらに割れるからです。すでに54本がコメントなしで積み上がっています。

揃えるならどちらかに寄せてまとめて直すほうが安全だと判断しました。記事の中身をどう組み立てているかはClaude Codeにブログ記事を執筆させる方法に書いています。

コメントなしの運用で実際に失っているもの

いい面だけではないので、失っている点も書きます。3つあります。

• 編集画面で本文が段落ごとに分かれないため、ブロック単位の操作ができない
• 再利用ブロックなど、ブロックを前提にした機能を本文に適用しにくい
• 編集画面で開いて保存し直したときに、HTMLが整形される可能性がある

1つ目は日常的に効いてきます。公開後に文章を直すとき、目的の段落だけをクリックして編集するという操作ができません。

2つ目は、あとから本文の一部を共通パーツに差し替えたくなったときに効いてきます。ブロックとして分かれていないため、置き換える単位そのものがありません。

3つ目は実際に踏んだわけではありませんが、リスクとして認識しています。そのため本文を直すときはHTMLを扱う画面から触るようにしています。

ブロックエディタ自体の扱いにくさはWordPressのブロックエディタが使いにくい原因にまとめました。

この実例から言えること

どちらの方式でも運用は成立します。200本と54本、どちらも表示が崩れたという報告は受けていません。

問題は混在していたことのほうです。記法は意識して決めないと、参照する手順書ごとに勝手に分かれます。

これから仕組みを組む方は、最初にどちらでいくかを決めて、手順書に見本を1つ置いてください。後から揃えるより確実に楽です。

【訂正】自動投稿の検算として公開ページの警告を数えても意味がなかった

この記事を書くための検証中に、自分の運用の誤りが1つ見つかりました。隠さずに書きます。

当ブログでは公開後に記事ページを取得し、ブロックが解決できなかったときに出るクラス名の出現回数を数えて、0件であることを確認していました。以前の記事でもこの手順を紹介しています。

この検算は、実際には何も検出していませんでした。Claude Codeでブログを自動投稿する方法に書いた内容を、ここで訂正します。

存在しないブロックを公開しても、公開側には警告が出なかった

確かめ方は簡単でした。実在しないブロック名を本文に入れて投稿し、出力側のHTMLを取得して警告クラスの数を数えました。

結果は0件でした。壊れたブロックを入れているのに0件です。

中身のHTMLだけが普通に出力されていました。

理由は前の章で引用したとおりで、ブロックの検証は編集画面の読み込み時に行われる処理だからです。公開ページ側には、その結果が出てきません。

つまりこの検算は、壊れていても常に0件を返します。通っていたのではなく、そもそも何も見ていませんでした。

代わりに入れた3つの検算

公開ページを見ても分からない以上、確認は別の場所で行う必要があります。今回の検証をふまえて、次の3つに置き換えました。

1つ目は、投稿する前に開きコメントと閉じコメントの個数を数え、一致しなければ送らないことです。原因1はこれで確実に止まります。

2つ目は、投稿した直後に保存されたデータを取得し、自分が送った本文と一致しているかを突き合わせることです。原因1の検証では末尾にコメントが1つ増えていたので、この比較なら検出できます。

3つ目は、本文を解析してブロック名が空の部分がどれだけあるかを数えることです。意図せずクラシック扱いになっている範囲が把握できます。

見た目の確認は、この種の不具合の検査にならない

ここが一番の教訓です。ブロックの崩れは、公開ページを目で見ても分かりません。

実際、閉じコメントを抜いたケースでも公開側には段落もリストも普通に表示されていました。崩れているのは編集画面から見たときの構造だけです。

自動投稿では記事を開いて眺める確認は検査になりません。数えるか、送ったものと突き合わせるか、機械的な手段が必要です。

仕組み全体をどう組んだかはClaude Codeでブログを自動投稿する方法に書いています。

WordPressの自動投稿とブロックの崩れに関するよくある質問

検証中に自分でも迷った点を、質問の形でまとめました。いずれも2026年9月時点の当ブログ環境での確認にもとづいています。

ブロック形式で送らないと、SEOで不利になりますか?

ブロックコメント自体は出力時に取り除かれるため、検索エンジンが読む本文と見出しの構造は同じです。

ただしブロック形式で送ると wp-block-heading のようなクラスが付くので、HTMLが完全に同一になるわけではありません。

ただし、テーマ独自ブロックを使わないぶん装飾の幅は狭くなります。読みやすさが落ちれば間接的に影響する可能性はあるので、クラス名で同じ見た目を再現できているかは確認してください。

すでに崩れたまま公開した記事は、どう直せばいいですか?

本文データを正しい形に直して、同じ記事に上書き更新するのが確実です。編集画面で開いて「ブロックのリカバリーを試行」を使う方法もありますが、記事数が多いと現実的ではありません。

記事数が多い場合は、まず開閉コメントの数が合っていない記事だけを機械的に洗い出し、そこから優先的に直すのが早いです。

クラシック扱いの記事を、後からブロック形式に変えられますか?

編集画面でクラシックブロックを選び、ブロックへ変換する機能を使えば個別には可能です。ただし変換時にHTMLが整形されるため、テーマ独自のクラスが落ちて装飾が変わる可能性があります。

記事数が積み上がってからの一括変換は、それ自体が作業になります。方針を決めるなら早いほうがいいというのが、記法が混在してから気づいた側の正直な感想です。

投稿は成功するのに装飾だけ効かないのはなぜですか?

ほとんどの場合、テーマが期待しているクラス名が付いていないか、綴りが違っています。装飾はCSSのクラスに当たっているためです。

確認方法は、管理画面で同じ装飾を手で1つ作って保存し、本文データを取り出して実際のクラス名と見比べることです。推測で書いたクラス名は、たいてい実物と違います。

SWELL以外のテーマでも同じ結果になりますか?

ブロックがコメントで区切られる仕組みはWordPress本体の機能なので、原因と直し方の部分はテーマが変わっても同じです。

一方で、独自ブロックの名前と属性、出力時に付くクラス名はテーマごとに違います。テンプレをそのまま流用せず、自分のテーマで1つ作って見比べてください。

まとめ|WordPressの自動投稿でブロックが崩れるのは「書きかけ」のときだけ

最後に要点を整理します。

• 崩れる原因は「開閉の数が合わない」「属性とHTMLが食い違う」「実在しない名前を書く」の3つ
• どれもブロック記法を中途半端に使ったときに起きる
• コメントを一切付けない選択なら、崩れは発生せず表示も正常
• 代わりに、編集画面でブロック単位に扱えなくなる
• 方式を決めずに進めると、手順書ごとに記法が勝手に分かれる
• 公開ページを見るだけの確認は、この不具合の検査にならない
• テーマ独自ブロックは推測で書かず、手で1つ作ってコピーする

当ブログは、調べてみたら2つの方式が並走していました。どちらの記事も表示は崩れていません。

ただし編集画面で手を入れながら育てるつもりなら、最初からブロック形式で送るほうが後々きくと思います。付けない選択は、編集画面でほとんど触らない運用とセットです。

どちらを選ぶにしても、検算だけは先に用意してください。今回わかったとおり、確認しているつもりで何も見ていないという状態があり得ます。

そしてこれらはすべて、WordPressが自分の管理下にあって初めてできることです。

これから環境を用意するならエックスサーバー公式を確認してみてください。2026年9月7日から10月5日まで、12か月以上の新規契約を対象に利用料金の半額が後からキャッシュバックされるキャンペーンが実施されています(申請手続きが必要・詳細と期限は公式ページでご確認ください)。

サーバーを比較して決めたい場合は、WordPressが最初から動く状態で始められるConoHa WING公式も候補になります(料金と条件は変動するため公式ページでご確認ください)。

自動投稿の仕組みそのものを一から組む方法はClaude Codeでブログを自動投稿する方法に、AIで記事を増やした結果どうなったかはAIブログのアクセスが増えない理由にまとめています。