※本記事にはプロモーションが含まれます
筆者はブログ5サイトをAIで自動運営している。今回は、日曜に仕込んだはずの下書きが、一度も処理されないまま消えていた話をする。
「作り置き」型の自動化は便利な反面、うまく仕込めていても後工程の仕様次第で永久に拾われなくなることがある。今回はその実例と、直した手順をまとめる。
日曜だけ、記事が消えていた
この副業システムでは、noteの記事を毎週水曜に自動で公開パックへ仕上げる仕組みが動いている。加えて日曜には、別の担当タスクが週末用の下書きを1本「作り置き」する運用を新設したばかりだった。
ところが、種まき開始後の最初の日曜（2026年7月26日）に仕込んだ下書きが、翌週になっても在庫として残ったままだった。ここ、迷いやすいところだが、下書き自体はきちんと保存されていた。処理されていなかっただけだ。
原因は「最新の1件だけ見る」自動化の仕様だった
調べると、原因は単純だった。作り置きの保存先が「note/下書き/」直下だったのに対し、水曜の公開パック作成タスクは「直下にある最新日付の1本だけ」を対象にする仕様だったのだ。
つまり、日曜に作った下書きよりあとに別の下書きが同じ場所にできると、水曜のタスクはそちらだけを拾い、日曜分は静かに取り残される。逆に日曜分がいちばん新しければ、今度は水曜分を押しのけてしまう。フォルダを共有していたせいで、新しい方が古い方を毎回追い出す構造になっていた。
あわてなくて大丈夫、この手の設計ミスは珍しくない。「作り置き（在庫）」と「今週処理する分（処理待ち）」を同じ場所に置くと起きやすい典型パターンだ。
| 項目 | 直す前 | 直した後 |
|---|---|---|
| 保存場所 | note/下書き/ 直下（共有） | note/下書き/在庫/ を新設して分離 |
| 水曜タスクの対象 | 直下の最新1件（在庫と区別なし） | 在庫フォルダは対象外と明記 |
| 結果 | 新しい方が古い方を押しのけて死蔵 | 在庫は溜められ、最古の1本から処理 |
| 異変への気づき方 | 特になし（発見は偶然） | 在庫3本以上で警告する行を追加 |
参考：自宅システムの実行ログ（種まき/実行ログ.md 2026-07-26 23:50時点の実測）
自動化の設計を4つ直した
その場で対応したのは次の4点だ。
1つ目：「note/下書き/在庫/」を新設し、死蔵していた1本をそこへ移動した。
2つ目：日曜の作り置きタスクの保存先を、必ず在庫フォルダ配下にするよう改訂した。あわせて、在庫が3本以上たまったら警告を出す行を追加した。
3つ目：水曜の公開パック作成タスク側にも「在庫フォルダは対象外」と明記した。下書きがゼロのときは「在庫が◯本あります」と知らせ、「在庫から公開パックを作って」と指示されたときだけ最古の1本を処理する動きに変えた。
4つ目：関連する案内文（README）の説明表も、新しい保存場所に合わせて書き直した。
実際に運用してみて
私が見ている実行ログには、この日の対応が時系列でそのまま残っている。「日曜の『note作り置き』が自動では永久に拾われない構造だった」「今日が種まき開始後の最初の日曜＝死蔵1本目のうちに発見」と記録されていて、被害が1本で済んだのは単に運が良かっただけだとわかる。仕組みを新設した直後は、こういう取りこぼしが起きやすい。
同じ夜には、もう1件別の見落としも見つかっている。週次の点検スクリプトが存在しないフォルダのパスを見ていて、note下書きの滞留をずっと「0件」と誤って報告し続けていたのだ。監視の仕組みがあっても、見ている場所自体が間違っていれば異常は検知できない。この点検の話はまた別の機会に詳しく書きたい。
同じ月に見つかった、もう一つの落とし穴
無人運用にありがちな見落としは、これだけではなかった。同じブログ群を支えるサーチコンソール連携（検索順位データの自動取得）でも、2026年7月21日に別の設計ミスが見つかっている。
週1回のデータ取得を自動化する仕組みを作ったはずが、実行ログを確認すると「起動設定が一度も登録されていなかった」ことが判明した。取得自体は動いていたが、それは人が手動で走らせていた分だけで、自動起動のスイッチそのものが入っていなかった。
2つの件に共通しているのは、どちらも「一見動いているように見える」状態だったという点だ。作り置きの下書きは保存されていたし、データ取得も手動実行では成功していた。仕組みの一部が動いていることと、設計どおりに全体が回っていることは、別の話だとあらためて思う。
参考：自宅システムの実行ログ（GSC連携/実行ログ.md 2026-07-21時点の実測）
作り置き型の自動化に共通する設計原則
今回の教訓は、note以外の自動化にもそのまま応用できる。ポイントは3つ。
在庫と処理待ちは別の場所に置く。同じフォルダで共存させると、新しい方が古い方を追い出す事故が起きやすい。
「最新の1件だけ見る」仕様は要注意。仕込むタイミングが不定期な作り置き運用と組み合わせると、取りこぼしが発生しやすい設計だと覚えておくといい。
件数の警告を仕込む。在庫が想定より増えていたら、どこかで処理が止まっているサインになる。数を見るだけの簡単な仕組みでも十分に効く。
ブログの自動運営そのものを任せてみたい方へ 【AIが自動でブログを運営】AIブログくんGOLDで効果的なAIブログを始めよう！無料体験実施中！
よくある質問
Q. 「作り置き」型の自動化で気をつけることは？
A. 保存先を「在庫（作り置き）」と「処理待ち」で分けることです。同じフォルダに置くと、後から作った分が先に作った分を押しのけて、古い方が処理されなくなることがあります。
Q. こうした設計ミスはどうやって見つければいい？
A. 監視や点検が「異常なし」と報告していても、それだけで安心しないことです。実際にフォルダの中身を目で見て、意図した通りに処理が進んでいるかを定期的に確認すると見つけやすくなります。
作り置きは便利な仕組みだが、保存場所の設計を誤ると静かに死蔵する。在庫と処理待ちを分け、件数の警告を仕込む。この2つだけで、今回のような取りこぼしはかなり防げる。
あわせて読みたい
自社の自動化運営についてのご相談は、まとめページの自社サービス枠からお問い合わせいただける。
