AIで記事を作れるようになると、次に考えたくなるのが「毎日、決まった時刻に自動投稿できないか」です。原稿作成からWordPress公開まで自動で進めば、手間はほとんどなくなるように見えます。

私も当初は、13時に記事を公開する定期処理を目指しました。しかし実際に運用すると、ログイン状態、途中エラー、重複投稿、公開前の確認など、文章生成とは別の問題が目立ちました。

そこで現在は、朝にAIが原稿と画像を準備し、公開するときは自分がログインした後に一記事ずつRunする方式へ変えています。自動化を減らしたように見えますが、実際には作業の再現性が上がり、失敗から戻りやすくなりました。

この記事では、毎日自動投稿をやめた理由と、「一記事ずつRun」を安定して続けるための設計を、初心者向けに紹介します。

毎日自動投稿が魅力的に見える理由

定期投稿には分かりやすい魅力があります。公開を忘れない、更新頻度を保てる、手作業の時間を減らせる、という三つです。

テーマ一覧があり、AIが記事を書き、画像を作り、WordPressへ登録できるなら、時計に合わせて起動するだけで完成しそうです。特に記事数を増やしたい時期は、「自動で一本増える」という仕組みが理想に見えます。

ただし、原稿を作る工程と、外部へ公開する工程では失敗の重さが違います。原稿ファイルなら後から直せます。公開では、誤った内容や重複記事が読者に見え、URLや検索結果にも影響します。予定時刻に動いたことより、正しい記事が一度だけ公開されたことの方が重要です。

定期公開で起きた四つの問題

ログイン状態は毎回同じではない

WordPressの画面を操作するには、ログインが必要です。認証が切れる、追加確認が表示される、管理画面の表示が変わる、といったことがあります。原稿作成は正常でも、最後の公開だけ止まるケースがありました。

「時刻になれば必ず公開できる」という前提が崩れると、定期処理は不安定になります。認証を無理に自動化するより、人が安全にログインした後で処理を開始する方が確実でした。

途中まで成功すると状態が分かりにくい

原稿の貼り付けは成功したが、画像設定で止まった。下書きはできたが、内部リンクが未設定だった。公開ボタンの直前でエラーになった。このように、一つの記事でも工程ごとに状態が異なります。

全体をもう一度実行すると、同じ下書きや画像が増えるおそれがあります。そこで、原稿・画像・WordPress・内部リンクを別々の状態として管理し、未完了の工程だけを再開する必要がありました。

重複を防ぐ判断が必要

定期処理は、前回の処理が本当に終わったかを知らなければなりません。通信の遅れで結果を受け取れなかっただけなのか、投稿自体が失敗したのかは、見た目だけでは判断しづらい場合があります。

「未完了」と判定してもう一度投稿すれば、同じ記事が二つできます。公開前に、管理表のURL、WordPressの状態、既存タイトルを確認する工程が欠かせません。

公開前に人が見たい項目が残る

AIが整った文章を作っても、サイト全体の流れは人が見た方がよい部分があります。タイトルが隣の記事と似すぎていないか。内部リンク先は公開済みか。画像は内容と合っているか。CTAが重複していないか。プレビューで見出しが崩れていないか。

これらを確認せず定刻だけを守ると、更新数は増えても記事の信頼性が下がります。

「1記事ずつRun」とは何か

私が採用したのは、準備と公開を分け、公開処理は一記事単位で始める方式です。

朝の準備では、AIが管理表から対象を一件選びます。必要な資料と直前の記事を読み、本文とアイキャッチ画像を作り、指定のGoogle Driveフォルダへ保存します。最後に原稿状態・画像状態・URL・処理日時を管理表へ記録します。

公開時は、人がWordPressへログインします。その後、公開待ちの記事を一件だけ選び、Runします。原稿を登録し、画像、カテゴリー、スラッグ、内部リンク、CTAを確認します。プレビューに問題がなければ公開し、公開URLを管理表へ戻します。

重要なのは、「一件終わるまで次へ進まない」ことです。複数記事をまとめて動かすと、失敗したときにどの記事まで完了したのか分かりにくくなります。一記事なら、確認範囲と影響範囲が小さくなります。

変えてよかった三つの点

失敗の範囲が小さくなった

一記事だけなら、エラーが起きても他の記事へ波及しません。画像設定で止まった場合は、その工程から再開できます。公開済みの記事を再び対象にしないルールも入れやすくなりました。

復旧手順を言葉にできるようになった

処理開始時に「処理中」、原稿完成後に「完成」、公開後に「公開済」と記録します。URLも工程ごとに残します。次回は状態を見て、最初の未完了工程から始めます。

この設計にすると、「何となく動かなかった」ではなく、「画像アップロードで停止。原稿は完成済み。次は画像から再開」と具体的に判断できます。

人の確認が短時間で済む

自動化をやめたのではなく、人が必要な場所だけを残しました。原稿と画像が用意されているので、公開時に白紙から作る必要はありません。人はログイン、プレビュー、最終判断に集中できます。

私は、自動化率が少し下がっても、毎回同じ手順で安全に終わる方を選びました。ブログ運営では、派手な一回の成功より、壊れにくい繰り返しの方が価値があります。

初心者向けの実装手順

まず管理表を作る

最低限、記事番号、タイトル、原稿状態、原稿URL、画像状態、画像URL、WordPress状態、公開URL、エラー内容を分けます。一つの「完了」だけでは、途中から再開できません。

準備タスクを独立させる

原稿作成と画像作成は、公開処理から切り離します。公開権限を持たない準備タスクなら、誤って外部へ出す危険を減らせます。完成ファイルは決めたフォルダへ保存し、管理表へURLを記録します。

公開対象を一件に固定する

WordPressが未公開で、準備が完成した最小番号を一件だけ選びます。対象が決まったら、他の記事を触りません。これだけでも重複や飛ばしを防ぎやすくなります。

人がログインしてからRunする

自動処理に認証情報を無理に持たせず、自分でログインを確認してから開始します。処理中に追加認証や警告が出たら、その場で止められます。

最後に管理表へ戻す

公開URL、公開日時、設定した画像、内部リンクの状態を記録します。エラー時は、失敗工程、原因、完了済み工程、次に必要な操作を残します。翌日の処理はこの記録を読み、同じ作業を繰り返しません。

自動化率より「再現性」を測る

運用を評価するとき、私は「何％自動化したか」より、次の三つを見ます。

・同じ入力なら、同じ手順で完了できるか

・途中で止まっても、未完了工程から戻れるか

・人が確認すべき場所が明確か

一記事ずつRunする方式は、最速ではないかもしれません。しかし、処理単位が小さいので、原因を見つけやすく、やり直しも少なくなります。結果として、公開までの総時間が安定します。

毎日投稿は目的ではない

毎日投稿すること自体が、読者への価値になるわけではありません。目的は、役立つ記事を正しい状態で届け、継続して改善できることです。

公開本数を増やす前に、準備・確認・公開・記録という流れを一件で安定させます。その型ができてから、一日に扱う件数を増やす方が安全です。

まとめ

私は、13時の定期公開を止め、ログイン後に一記事ずつRunする運用へ変えました。

理由は、認証状態の変化、途中エラー、重複投稿、公開前確認に対応しやすくするためです。朝はAIが原稿・画像・管理表を準備し、公開時は人がログインして一記事だけ処理します。工程別の状態とURLを残し、失敗したら最初の未完了工程から再開します。

完全自動化を目標にするより、失敗しても戻れる設計を目標にする。これが、AIブログを長く続けるための現実的な方法だと考えています。

次の記事では、この運用を支える管理表の項目と、重複を防ぐチェック方法をさらに具体的に解説します。

内部リンク候補

No.8「AIブログ自動化はどこまで可能？私が実際にやっている方法」

No.11「ChatGPTでWordPress投稿はどこまで自動化できる？実際に試して分かった限界」

No.12「WordPress自動投稿でログインエラーが発生｜完全自動化をやめた理由」