外部LLM APIを使わずWordPress記事を予約する方法

AIで原稿を整えても、記事生成とWordPress保存を同じ処理へ詰め込む必要はありません。外部LLM APIを使わずに予約投稿したい場合は、原稿ファイル、投稿ガード、WordPress RESTの再取得を別工程にすると、意図しないAPI利用や即時公開を防ぎやすくなります。

このサイトでは2026年7月30日、投稿前ガードの表示を確認し、外部LLM APIが無効、実投稿テストではなく予約投稿、保存先がfutureであることを一件ずつ確かめました。この記事では、その実運用を一般化して説明します。最終確認日：2026年7月30日

記事生成とWordPress保存を分離する

最初に決めるのは、文章をどこで整え、どの処理がWordPressへ保存するかです。原稿をJSONなどの決まった形式へ保存し、投稿プログラムはそのファイルだけを読む構成なら、文章の確認前にネットワークへ送信される範囲を限定できます。

原稿ファイルを唯一の入力にする

タイトル、本文、カテゴリー、検索意図、出典を一つの原稿ファイルへまとめます。投稿時に別のAIへ再生成させると、確認済み本文と保存本文が変わるため、ファイルの内容をそのまま使う経路へ固定します。空ファイルや形式不正なら投稿処理を止めてください。

ファイル名だけを確認するのでは不十分です。文字コード、必須項目、本文の長さ、見出し、リンクを読み取り、保存直前の本文からハッシュ値を作ると、WordPress再取得後に同じ本文か比較できます。

外部プロバイダーを実行時に無効化する

設定ファイルへAPIキーが残っている環境では、入力元をファイルへ変えただけで安心できません。このサイトの監督付き経路では、OpenAI、Gemini、Claudeの3系統を実行時に無効化し、外部LLMを選択する関数も使えない状態にしてから投稿確認へ進みます。

安全側の判定は『APIを呼んだ記録がない』ではなく、『呼び出せない経路へ固定した』です。想定外の設定値を検出した時は別サービスへ切り替えず、その記事を下書きのまま残します。

投稿前ガードで公開条件を確認する

ガードは投稿そのものを始める前に、実行モードと保存状態を表示します。具体的には、外部LLMが無効、dry runではない、保存状態がfuture、自動予約が有効という四点をチェックします。一つでも違えば本文を送信しません。

futureと即時公開を区別する

WordPress REST APIのPosts公式資料では、投稿状態としてpublish、future、draft、pending、privateなどが定義されています。予約投稿はfutureと予約日時の組み合わせで保存し、publishを使いません。

サーバーとパソコンで時刻設定が異なる場合があるため、日付だけでなく時刻とタイムゾーンも確認します。例えば、このサイトでは毎日9時の枠を使い、同じ日の既存予約を上書きせず、翌日以降の最初の空きへ入れます。

ガードは記事ごとに実行する

一件目が合格しても、二件目の前に設定や原稿が変わる可能性があります。複数記事を補充する時も、記事ごとにガードを再実行し、その結果と対象投稿IDを同じ作業記録へ残します。

ガードの終了コードだけでは成功と判断しません。表示された外部LLM、dry run、投稿状態を読み、期待値と一致した場合だけWordPress更新へ進むのがポイントです。

• 外部LLM APIが無効
• dry runではなく保存処理
• 投稿状態がfuture
• 自動予約が有効

保存前に復元可能なバックアップを作る

既存下書きを予約へ移す時は、タイトルと本文だけでなく、元の状態、日時、スラッグ、カテゴリー、タグ、アイキャッチIDも保存します。本文だけのコピーでは、失敗時に元の投稿状態へ戻せません。

WordPressの編集データを一件ずつ保存する

認証付きRESTで対象投稿を取得し、レスポンスを投稿ID別のJSONへ保存します。バックアップには認証情報を入れず、変更前の投稿データと取得日時だけを残します。複数記事を一つの巨大なファイルへまとめるより、復元対象を特定しやすくなります。

バックアップ後にWordPressをもう一度取得し、対象がまだdraftで、別処理に変更されていないか確認します。取得後に状態が変わっていた場合は競合と判断し、上書きしません。

SEO情報と本文形式も変更前に数える

タイトル、focus keyword、H2とH3の数、吹き出し、内部リンク、外部リンクを変更前後で比較します。見た目を整える処理が、広告リンクやショートコードを消していないかを数字で確認できます。

スラッグを変える場合は、公開済みURLではない下書きか、同じスラッグが使われていないかを確認します。公開済み記事のURL変更や301は別の高リスク作業として分離してください。

WordPress保存後に同じ投稿を再取得する

保存要求が200番台でも、期待どおり予約されたとは限りません。対象投稿IDを指定して再取得し、status、date、title、content、featured_mediaを保存前の計画と比較します。

本文はハッシュと主要項目で照合する

保存したHTMLから余分な空白差を除いたハッシュを作り、再取得した本文と一致するかを確認します。さらに、タイトル、見出し数、出典URL、禁止した広告リンクがないことも読み直します。

WordPress側でショートコードやHTMLが正規化される場合は、単純な文字列一致だけでなく、見出しとリンクの構造も比べます。差分が説明できない時は成功扱いにしません。

SEOと予約枠を別々に検査する

focus keywordの保存成功と、future予約の成功は別の確認項目です。SEO設定が失敗した時に記事だけ予約されないよう、一連の処理として確認し、必要なら変更前の下書きへ戻します。

同じ日へ複数の記事が入っていないかも再集計します。対象記事だけ正しくても、既存予約との衝突で毎日公開が途切れることがあるためです。

アイキャッチを無料ローカル生成でWebPへ統一する

本文と予約日時を確認した後、画像担当を分離します。対象投稿IDだけを画像処理へ渡し、既存画像がWebPなら維持し、未設定または別形式の場合だけローカル生成したWebPへ置き換えます。

画像担当へ投稿IDだけを渡す

記事投稿プログラムから有料画像APIを呼ばず、画像専用ツールへ投稿IDを渡します。元画像は削除せず、新しい画像のアップロードと紐付けに失敗したら旧アイキャッチへ戻せるようにします。

画像生成の担当を一つへ固定すると、別サイトの認証情報やデザインを誤って使う事故も防げます。複数サイトを運用している場合ほど、サイトごとの画像ツールを混同しないことが欠かせません。

mime typeとURLの両方を確認する

拡張子だけを.webpへ変えても、実体がJPEGならWebP化とはいえません。WordPressメディアを再取得し、mime_typeがimage/webp、画像URLの末尾が.webp、対象記事のfeatured_mediaとメディアIDが一致することを確認します。

外部LLMを使わない予約投稿は、単なる費用削減ではありません。原稿確認、投稿ガード、バックアップ、REST再取得、画像確認を分離することで、どこで失敗したか追跡できる運用になります。