予約したSNS動画が見つかりません。すぐに同じファイルをアップロードし直すべきでしょうか。
まだ再送しません。最初に、どの段階まで完了したと証明できるかを確認します。動画はSNSへ渡る前に止まることも、SNS側で処理中のことも、すでに公開済みなのに管理画面への反映が遅れていることもあります。全部を同じ「失敗」と扱うと、1件の障害を重複投稿へ広げてしまいます。
以下の5項目を上から順に確認してください。
30秒チェック
- エディターは動画と投稿設定を受け付けたか
- アップロード後に安定したメディア参照値が返ったか
- コンテンツIDまたは公開ジョブIDが存在するか
- SNS側の投稿IDまたは元投稿URLが存在するか
- 公開プロフィールで実際に何が表示されているか
証拠が途切れた最初の項目で止まり、推測ではなく 未確認 と記録します。
1. エディターは動画を受け付けたか
SNS側を疑う前に、投稿前の入力を確認します。対象アカウント、予約日時、タイムゾーン、本文、ファイル要件が意図どおりかを見ます。
ファイル未選択、未対応形式、長さや容量の超過などが残っている場合、SNSへの公開リクエストはまだ始まっていない可能性があります。まず入力エラーを修正し、この段階をSNS障害として記録しないようにします。
残す証拠は必要最小限にします。
- 公開チャンネルとアカウント名
- 予約日時とタイムゾーン
- ファイル容量、長さ、解像度、コーデック
- 同じ書き出しファイルか確認するためのフィンガープリント
- 画面に表示された検証結果
パスワード、アクセストークン、署名付きアップロードURL、非公開プロンプト、顧客情報は障害記録へコピーしません。
2. メディア転送は完了したか
多くの予約投稿ツールは、SNS投稿を作成する前にアップロード先を準備し、そこへファイルを転送します。準備APIが成功しても、実際の転送だけが失敗することがあります。
asset_ref やメディアIDのような再利用可能な参照値が発行されたかを確認します。転送が明確なエラーで終わり、参照値もない場合は「メディアアップロード失敗」です。Instagram、TikTok、YouTube、Facebookが公開リクエストを受け取った証拠がない限り、各SNSの拒否とは呼びません。
タイムアウトはさらに慎重に扱います。クライアントが応答を受け取れなくても、保存先にメディアが作成されている場合があります。同じファイルを送る前に保存結果を照合します。
3. コンテンツIDまたは公開ジョブIDはあるか
コンテンツIDや公開ジョブIDは、準備段階と実際の公開処理を分ける境界です。
どちらもなければ、追跡すべき下流リクエストはありません。IDがある場合は、新しい投稿を作らず同じIDを確認します。accepted、scheduled、publishing は進行状態であり、閲覧者が動画を見られる証拠ではありません。
状態の全体像は、「予約済み」は「公開済み」ではない：SNS投稿を確認する方法で確認できます。
4. SNS側の投稿IDまたは元投稿URLはあるか
SNS側の投稿IDがあれば、提供元が投稿をすでに認識している可能性があります。元投稿URLがあれば、確認対象を1件に固定できます。
再試行より先に次を実施します。
- 既存のコンテンツIDとジョブIDを保存する
- 同じIDの状態が変化しているか確認する
- URLがあれば既存の元投稿を開く
- 複数チャンネルの結果をチャンネル別に分ける
4チャンネル中3件が公開済みで1件だけ失敗している場合、全体を再送すると成功済みの3件が重複するおそれがあります。未解決の1件だけを対象にする前に、そのSNSに既存投稿がないか確認します。
5. 公開プロフィールでは何が見えるか
最後の確認は予約ツールの外で行います。SNSの元投稿を開き、次を確かめます。
- 期待した公開アカウントか
- 動画またはサムネイルが表示されるか
- 承認した本文か
- 必要な root と reply の構造か
- 表示されたURLが実際にクリックできるか
管理画面で public と保存されていても、元投稿が非公開、欠落、別の本文で表示されていれば完了ではありません。観察した結果を残し、誤りを証明できる箇所だけを修正します。
安全な再試行の判断表
| 最後に確認できた状態 | 分かること | 次の判断 |
|---|---|---|
| エディターの検証失敗 | 公開処理の前で止まっている | 入力を修正し、SNS障害とは扱わない |
| 転送エラー、メディア参照値なし | 投稿へ添付できる既知のメディアがない | アップロード経路を修正してから1回だけ検討 |
| アップロード結果が未確認 | メディアが作成済みの可能性がある | 保存結果を先に照合 |
| コンテンツIDまたはジョブIDあり | 公開処理が始まった可能性がある | 同じIDを終端状態まで追跡 |
| SNS側IDまたは元投稿URLあり | SNSに投稿が存在する可能性がある | 再試行前に元投稿を確認 |
| 公開元投稿が正常 | 閲覧者向けの結果まで到達した | 再投稿しない |
4チャンネルの動画運用で起きた実例
2026年8月15日、ANKK運用者は同じ10秒の縦型動画をInstagram、TikTok、YouTube、Facebook向けに準備しました。
最初のコマンドライン操作ではアップロード準備は完了しましたが、保存先への転送がHTTP 403を返しました。再利用可能なメディア参照値、コンテンツID、公開ジョブ、SNS側ID、元投稿URLは作成されていませんでした。したがって、この時点で4つのSNSに対する正確な結果はすべて 未試行 です。
その後、同じフィンガープリントのファイルを、別途確認済みの対応フローから1回だけアップロードしました。1つのメディア参照値を4つの固有コンテンツリクエストへ使い、4件すべてが終端の published に到達しました。各SNSの元投稿も個別に確認しました。
後の成功によって、最初のHTTP 403がSNS提供元の失敗へ変わるわけではありません。確認済みの境界から復旧したため、結果が曖昧なまま同じ動画を重複送信せずに済んだという事例です。
チャンネルごとに証拠を1行残す
channel/account:
scheduled_at/timezone:
media_reference_present:
content_or_job_id:
terminal_state:
provider_id_or_permalink:
public_outcome:
manual_retry_count:各項目を 観察、推測、未確認 に分けます。チャンネル別の行が正確になってから、バッチ全体を要約します。
予約投稿ツールを比較している場合は、この復旧項目をSNS予約投稿ツールの比較・乗り換え前に確認したい7項目にも追加してください。
文章作成ツールを変えずに公開状態を確認する
この記事はANKK運用者が実際の公開作業をもとに作成しました。ANKKに内蔵AIライターはありません。人、外部AIツール、スクリプトが準備したコンテンツを、SNS予約、チャンネル別状態、提供元の元投稿確認へつなぎます。