Xの自動投稿が止まったときの復旧手順｜認証・キュー・本文・実行履歴を順番に確認

自動投稿が止まると、最初に再実行ボタンを押したくなります。しかし、直前の処理が成功していた場合は同じ投稿を重複送信し、認証エラーの場合は失敗回数だけを増やします。復旧では、投稿の有無を外部画面で確認し、原因を層ごとに切り分ける順番が重要です。

この記事は、X投稿運用で確認しているアカウント、認証、入力データ、本文、送信、記録の流れを、再現可能なランブックへ整理したものです。APIの仕様や契約プランは変わるため、具体的な上限を固定せず、公式開発者情報と実行履歴を確認して判断します。

1. 最初に最後の成功時刻と公開結果を確認する

まず、Xの公開プロフィールで最新投稿の時刻と本文を確認します。次に、運用台帳や実行ログで最後に成功した処理、失敗した処理、予約中の処理を確認します。画面に投稿があるのにログが失敗のままなら、送信後の記録だけが失敗した可能性があります。

この段階では再実行しません。対象の投稿ID、予定時刻、本文の先頭、実行IDを一つのメモへそろえます。時刻は日本時間と協定世界時の混同を避け、表示されているタイムゾーンを記載します。投稿が見つからない場合も、削除済みや限定表示など別の状態を決めつけません。

2. アカウントとAPI認証を本文より先に確認する

投稿アカウントが意図したものか、開発者アプリの状態、権限、トークンの有効性を確認します。認証情報そのものをログへ出力せず、設定されているか、期限や権限エラーが返っているかだけを記録します。パスワードや秘密鍵をチャットや共有文書へ貼りません。

認証エラーでは、同じ資格情報で連続再試行せず、公式画面でアプリと権限を確認します。権限変更やトークン再発行を行った場合は、古い値を安全に無効化し、実行環境だけを更新します。ローカルで成功しても定期実行環境に新しい値が反映されていない場合があるため、環境を分けて確認します。

3. 投稿キューと本文の品質ゲートを確認する

認証が正常なら、投稿候補がキューへ入っているか、予定時刻を過ぎているか、処理済みと誤判定されていないかを確認します。候補が空の場合は送信処理ではなく、テーマ生成、承認、予約登録の上流工程を調べます。失敗した投稿だけを手動追加すると、後で元のキューから重複送信されるおそれがあります。

本文が品質ゲートで止まった場合は、文字数、禁止表現、重複、リンク、広告表示、対象読者、目的を確認します。ゲートを無効化して送るのではなく、なぜ不合格になったかを修正します。内容が古い、出典がない、同じ主張が続く投稿は、予定を埋めるために公開しません。

4. 一件だけ試験送信して記録まで確認する

原因を修正したら、保留中の全件を流さず、重複していない一件だけを試験対象にします。送信前に本文、リンク、広告表示、予定アカウントを確認し、送信後に公開画面の投稿IDと時刻を記録します。短時間に複数投稿して停止期間を埋め合わせません。

送信が成功しても、実行ログ、台帳、次回予定が更新されるところまで確認します。投稿だけ成功し記録が失敗すると、次回の重複判定ができません。記録更新が失敗した場合は、公開済み投稿IDを手動で復旧台帳へ入れ、自動実行を一時停止した状態で整合を取ります。

5. 復旧記録と再発防止を次回運用へ反映する

復旧後は、発生時刻、影響範囲、直接原因、検知方法、暫定対応、恒久対応を残します。「認証エラー」だけでは足りず、どの権限が不足し、どの確認で分かり、次回どう検知するかを書きます。担当者を責める記録ではなく、次に同じ状態が起きたときの判断を短くする記録にします。

監視は投稿本数だけでなく、最後の成功からの経過時間、キュー件数、連続失敗、同一本文、台帳と公開画面の不一致を対象にします。自動復旧は安全な読み取りと一回の再試行までに限定し、権限変更、秘密情報更新、大量再送は人の確認対象にします。

確認した一次情報・運用記録

• X Developer Platform documentation
• ツキラボ X公式アカウント
• ツキラボ：X運用を週次改善へ変える設計図

サービスの仕様や規約は更新される場合があります。実行前にリンク先の最新表示を確認してください。