このブログ自体を書いている自動投稿の仕組みで、アイキャッチ画像（サムネ）だけが8回出ない朝が続いた。原因ははっきりしないままだったが、本文の投稿だけは一度も止めなかった。
何が起きていたか
2026年7月6日〜8月4日の約1ヶ月で、サムネのアップロードだけが8回失敗した。記事の公開自体は毎回成功していた。
このブログは毎朝、AIが記事を書いてWordPressに自動投稿する仕組みで動いている。記事の本文と、アイキャッチ用のサムネ画像は別々の処理で、本文をWordPressに送ったあと、続けてサムネ画像をアップロードして記事に紐づける、という順番になっている。
7月6日、投稿記録に初めて「サムネなし」の1行が残った。原因として記録されていたのは、WordPress側のセキュリティ機能（不正なアクセスを自動でブロックする仕組み）が、サムネ画像のアップロード先だけをHTTP403エラー（アクセスを拒否したときに返ってくる合図）ではじいていた、というものだった。本文の投稿先はブロックされず、サムネのアップロード先だけがブロックされる。だから記事は毎回無事に出るのに、サムネだけが空白になる、という状態が続いた。
実際の投稿ログに残っていた記録の一部はこうだ。
07/06 サムネなし・要調査
07/18 サムネなし・3回リトライも失敗
07/24 サムネなし・3回リトライも失敗
07/26 サムネなし・3回リトライも失敗
07/28 サムネなし・3回リトライも失敗
08/02 サムネなし・3回リトライも失敗
08/04 サムネなし・3回リトライも失敗
毎回「3回までリトライ」の設定は入れていたが、それでも直らない日は直らなかった。8月4日を最後に、なぜかそれ以降の11本は1回も失敗していない。何が効いたのか、正直まだ特定できていない。⚠この点は未確認のまま残っている。
なぜ「サムネなし」のまま出し続けたか
失敗した処理を直そうとして本文の投稿まで止めるより、直らなくても本文だけは毎回出すほうを選んだ。
サムネのアップロードが失敗するたびに投稿全体を止めていたら、この1ヶ月で8回、ブログが更新されない日ができていたことになる。実際にやったのは逆で、サムネの処理は「失敗してもいい」ものとして本文の処理から切り離しておいた。サムネが出なくても記事自体は読めるし、後からサムネだけ追加することもできる。一方で本文が出ないのは読者にとって「今日は何も更新されなかった」という結果になってしまう。この2つは同じ重さでは扱えない、という判断だった。
自動化を組むときにやりがちな失敗は、すべての処理を「成功しないと次に進めない」直列でつなぐこと。1ヶ所詰まると全体が止まる。
自分の仕事に置き換えると
副業や本業の作業を自動化するときも、「絶対に止めてはいけない部分」と「止まってもいい部分」を最初に分けておくと、同じ落とし穴を避けられる。
- 週次の報告書づくりなら、本文の作成が「止めてはいけない部分」、グラフや図表の自動生成は「止まってもいい部分」
- メール下書きの自動生成なら、下書き作成が「止めてはいけない部分」、署名や装飾の自動挿入は「止まってもいい部分」
- SNS投稿の自動化なら、投稿文の作成が「止めてはいけない部分」、画像生成は「止まってもいい部分」
共通しているのは、読者・上司・取引先にとって一番困るのは「何も出てこないこと」であって、「装飾が足りないこと」ではない、という優先順位だ。
一部の機能が壊れても、システム全体は止めずに、質を落としてでも動き続けさせる設計の考え方。サムネなしで記事だけは出す、というのもこの一種。
今日からできること
自分の自動化やルーティン作業を、いったんClaudeに見せて仕分けしてもらうのが早い。
「この作業の手順を書き出すので見てください。①絶対に成功しないと困る『必須ステップ』と、②失敗しても他のステップに影響しない『あってもなくてもいいステップ』に分類してください。②が①をブロックしている箇所があれば、切り離す方法も提案してください」
自分の場合、この視点で見直したのはブログの自動投稿だけだったが、同じ考え方は報告書や資料づくりの自動化にもそのまま使えると思っている。
あわせて読みたい
Claude Codeで毎朝ブログが勝手に更新される仕組みを30分で作った
AI副業ガイドの「丸投げ注意」を自分のブログ運用に当てはめたら、直近半月で2本のネタが事実未確認で没になっていた話
