副業自動化で「エラー時だけ通知」にする方法｜毎日監視しない運用設計

副業を自動化しても、毎回ログを開いて成功確認していると手作業が残ります。そこで目指したいのが、正常時は何もしなくてよく、異常時だけ確認する設計です。

正常と異常を先に定義する

通知を作る前に「何をもって成功とするか」を決めます。たとえば記事生成なら、出力ファイルが存在するだけでは不十分です。

• 処理が最後まで終了した
• 出力が空ではない
• 必要な項目が揃っている
• 公開前チェックを通過した

通知は3段階に分ける

小さな注意まで毎回通知すると、重要な異常が埋もれます。

再実行を無限にしない

一時的な通信エラーなら1回だけ再試行し、それでも失敗したら停止するなど上限を決めます。無限リトライはAPI料金や重複投稿につながるため避けます。

外部書き込み前に品質ゲートを置く

WordPress投稿やSNS投稿の直前に、本文欠落、タイトル未設定、重複、内部メモ残りなどを確認します。詳しくはブログ自動投稿で低品質化を防ぐチェックリストも参考にしてください。

当サイトの安全停止を例にした通知設計

2026年10月21日・22日には、WordPressの記事本文を編集しようとした操作が安全チェックで拒否されました。この場合は別の経路で書き込まず、「未実施」として記録し、次回の正規操作に引き継ぎます。通知対象は、単なる表示回数の減少ではなく、公開処理の失敗、認証切れ、重大な事実誤認など対応が必要な異常です。

記録項目の例は、実行日時、対象記事ID、処理名、判定（PASS・WARNING・ERROR）、エラー理由、再試行回数、公開HTMLでの確認結果です。これは推奨するログ設計であり、以下の全項目が既存システムで自動記録済みという意味ではありません。

ログは後から追える形にする

成功時に通知しない代わりに、実行日時、結果、処理時間、出力先などは記録します。問題が起きたときだけ過去ログを見ればよい状態にします。

まとめ

完全自動化で重要なのは、作業をゼロにすることより「人が確認すべき例外を絞ること」です。正常時は静かに実行し、異常時だけ止まって通知する設計にすると、本業と並行しやすくなります。