定期実行を止めても、Qiita記事を書く必要までなくなるわけではありません。必要な日にユーザーが依頼し、直近の公開記録を見てから1本だけ投稿する形にすれば、記事の根拠を確かめながら運用を続けられます。今回は、毎日投稿から手動依頼へ切り替えた後、実際に公開した手順をまとめます。
前提：公開したかどうかは記録で判断する
直近の記録では、Vol.51「自動公開を止めて、必要な日だけ手動公開に戻した理由」が2026年9月19日に公開されています。9月20日の依頼を受けた時点で、まず docs/qiita/PUBLISH_SCHEDULE.json の末尾を確認し、当日分の公開記事がまだないことを確かめました。
ここで大事なのは、「依頼が来た」ことと「記事が公開された」ことを別の状態として扱う点です。原稿がある、投稿画面を開いた、というだけでは公開済みではありません。公開URLとitem_idが確認できて初めて、スケジュールの状態を published にします。
実際に行った手順
-
直近の公開記録を見る
PUBLISH_SCHEDULE.jsonの最後の数件から、最新Vol.51の日付・状態・URLを確認します。当日の日付がすでにpublishedとして登録されていたら、新規投稿はせずに終了します。これで手動依頼が重なった場合の二重投稿を防げます。 -
今日の題材を一次情報に限定する
今回の記事では、新機能やリリースを作り話で補わず、実際に確認できた「9/19に定期公開を止めて手動運用へ切り替えた記録」と「9/20に依頼を受けて重複確認から投稿した手順」を扱いました。記事化できる作業がない日には、無理に別の成果を作らないことも運用の一部です。
-
原稿をQiitaへ入力する
タイトル・タグ・本文を入力したあと、公開設定で「全体に公開」を選び、X共有がオフであることを確認します。今回の投稿では「AI」「Qiita」「個人開発」「開発プロセス」「初心者」の5タグを設定しました。公開先や共有設定は、本文とは別に最後に見直します。
-
公開後のページで確定する
投稿操作後に表示された公開ページで、タイトル、投稿者、タグ、URLを確認します。URL末尾の識別子をitem_idとして控え、公開日時とともにスケジュールを更新します。投稿画面の表示だけで成功とせず、公開ページまで確認するのがポイントです。
失敗時にやらないこと
画面が止まったり応答が曖昧だったりしても、すぐ同じ投稿を繰り返すと重複記事になる可能性があります。HTTP 429、認証失敗、公開失敗の場合は再試行せず、原稿と確認できた状態を残して止めます。状態が不明なときは、まず公開一覧やURLを確認し、成功・失敗を区別できてから次の操作を判断します。
まとめ
定期実行を止めた後の手動公開では、依頼を受けた日付、公開履歴、記事の根拠、Qiita側の結果をひと続きで記録することが大切です。確認の順番を固定すれば、毎日投稿を続けなくても、必要な日に重複や誤認を避けて公開できます。公開した本数より、公開済みと判断した根拠が残っているかを基準にすると、翌日の引き継ぎも簡単になります。