AIによるブログ自動化はどこまで任せる？保存・確認・公開の設計

AIによるブログの自動化は、資料整理、下書き、画像の準備、WordPressへの下書き保存といった繰り返し作業から任せるとよいでしょう。事実の判断と公開の判断は別の確認段階に置き、保存結果を確認してから公開や予約に進みます。生成量よりも、誤りを見つけて元に戻せる仕組みを基準に、自動化の範囲を決めるほうが実用的です。

自動化する作業と判断する作業を分ける

自動化とは、複数の作業を決めた順序と条件で実行することです。AIが原稿を作る機能と、WordPressに保存する機能は別です。両者をつないでも、事実確認まで終わるわけではありません。各段階の入力、結果、停止条件を先に決めましょう。

たとえば、タイトルと本文が完成しても、別の記事に画像が設定されていたら公開準備は完了していません。段階ごとに完了条件を決めると、一部の成功を全体の成功と誤って報告することを減らせます。

最初は下書きの保存までつなぐ

初めは、入力資料→原稿生成→形式検査→下書き保存→確認、という順序で組んでみましょう。1記事で全体の流れを確認してから対象数を増やすほうが、誤りの原因を探しやすくなります。生成がうまくできるからといって、すぐに無人公開まで広げる必要はありません。

保存前には必須項目を検査します。タイトルと抜粋、本文の見出し階層、リンク先の存在、サイトに実在するカテゴリーを確認してください。形式の検査は自動化できますが、有用性と事実関係は別途確認が必要です。

画像は、アップロードの成功と記事への設定を分けて確認します。メディアライブラリにあっても、アイキャッチに選ばれていない場合があります。複数の記事を処理するなら、原稿ごとの投稿ID、メディアID、段階の状態を記録し、取り違えを防ぎます。

WordPress APIの基本構造

API（Application Programming Interface）は、プログラムが他のサービスの機能を、決められたリクエストで利用する窓口です。WordPress REST APIでは投稿の作成、取得、更新ができます。投稿APIの公式文書は、本文、抜粋、カテゴリー、アイキャッチ、投稿状態のフィールドを説明しています。

以下は、認証を準備した自動化からPOST /wp-json/wp/v2/postsに送れるリクエスト本文の例です。実行スクリプトではなく、記事を公開せずに下書きとして作成する構造を示しています。

{
  "title": "確認するブログ記事のタイトル",
  "content": "<p>確認する本文です。</p>",
  "excerpt": "記事の内容と読者が得られる情報をまとめます。",
  "status": "draft"
}

カテゴリーやアイキャッチを追加する場合は、実際のサイトから取得したIDを使います。メディアAPIのpostは添付先、投稿のfeatured_mediaはアイキャッチの選択を表すため、同じ処理として扱わないでください。各フィールドはメディアAPIの公式文書で確認できます。

新規投稿の応答で受け取ったIDは、すぐに記録します。応答を受け取れなかったとき、同じ作成リクエストを無条件で繰り返すと重複投稿が生まれる可能性があります。まず記録と実際のサイトで作成済みかを調べ、再試行の要否を判断する仕組みが必要です。

認証情報と既存の編集を守る

接続アカウントに必要な権限を与え、パスワードやトークンは公開原稿、プロンプト、ログに含めません。WordPressはHTTPSリクエストでアプリケーションパスワードを使う認証をサポートしています。条件と接続方法はREST APIの認証文書で確認してください。

既存記事を変更する場合は、最初に読んだ内容と保存直前の内容を比較します。作業中に運営者が編集していたら、古い原稿を丸ごと上書きせず、最新内容に変更案を適用し直してください。本文だけを変更するリクエストなら、状態、公開日、スラッグを一緒に送らないほうが安全です。

公開記事を変更する前には、復元用の本文と主な設定を保存します。失敗した場合に、どの記事のどの値を戻すか分かる必要があります。ログを残す自動化でも、認証ヘッダーや秘密の値まで記録していないか確認しましょう。

予約公開はタイムゾーンと実際の状態まで確認する

確認済みの記事を予約するときは、サイトのタイムゾーンと入力時刻を合わせます。APIの現地公開時刻とGMT時刻が同じ瞬間を表しているか比較してください。「予約をリクエストした」と「未来の日時で保存された」は別々に確認します。

たとえば韓国時間で間隔を決めたなら、最初の公開時刻と各記事の順序を記録し、保存結果が意図した間隔か計算できます。下書きの日付を残したまま状態だけを変えたり、実行するパソコンのタイムゾーンがサイトと同じだと思い込んだりしないようにします。

WordPressの標準的な予約処理にはWP-Cronが関わります。公式文書によると、ページへのリクエストをきっかけに予約処理を確認するため、訪問がない場合は実行が遅れることがあります。正確な時刻が重要なら、ホスティングの定期実行設定も別途確認します。WP-Cronの説明を参照してください。

保存後の状態がfutureなら「予約完了」と記録します。予約時刻を過ぎてから再取得し、publishか確認します。ログアウト状態でも公開URLが開くことを確認して初めて、「公開完了」と扱えます。

エラーの段階で止め、そこから再開する

複数の記事を処理する場合は、記事ごとに状態を管理します。1記事の画像アップロードが失敗したとき、ほかの記事まで成功として扱わず、「原稿完了・下書き保存完了・画像設定待ち」のように実際の結果を記録してください。

• 原稿の確認に失敗：保存や公開に進まず、修正項目を残します。
• アップロードに失敗：作成済みの投稿やメディアを確認してから再試行します。
• 編集の競合：最新原稿を読み直し、変更案を調整します。
• 公開時のエラー：対象と原因を確認し、保管した値で必要な部分を復元します。

架空の例として、投稿IDが5010、新しくアップロードしたメディアIDが7020で、アイキャッチ設定だけが失敗したとします。以下の順序なら、成功した作成処理を繰り返さずに再開できます。実際のサイトでは、保存応答で受け取ったIDに置き換えてください。

1. GET /wp-json/wp/v2/posts/5010で投稿を再取得し、タイトル、本文、抜粋、分類、状態を記録と比較します。別の編集があれば変更を止めます。
2. GET /wp-json/wp/v2/media/7020でファイルの存在と、添付先のpostを確認します。
3. 投稿とメディアが確認でき、元の設定意図も変わらなければ、不足しているアイキャッチ設定だけを再試行します。その記事用に新規アップロードしたメディアの添付先が未設定なら別途補いますが、既存の共用メディアの添付先は勝手に変えません。
4. 再取得し、投稿のfeatured_mediaと新しいメディアのpostが、それぞれ意図したIDか確認して完了と記録します。投稿や画像を新規作成する処理から繰り返してはいけません。

作業後は、保存した本文、抜粋、分類、画像を再取得します。公開した場合は、最終URLとモバイル画面も確認しましょう。自動化は作成速度だけでなく、やり直しにかかる時間、重複の発生、復元の可能性も合わせて評価します。必要な確認を残しながら繰り返し作業を減らす仕組みが、長く管理しやすい形です。