WordPressへの投稿で通信が切れたら、最初に押すのは「再送」ではありません。投稿先で記事ID・スラッグ・公開状態を調べ、届いていないと確認できた操作だけ続けるのが先です。返事がないことと、投稿がないことは別。ここを分けるだけで、同じ記事が二つ並ぶ事故をかなり減らせます。
自動投稿が途中で止まると、心配で同じボタンをもう一度押したくなります。原稿をつくり、画像を用意し、いざ公開という時に「タイムアウト」。読者に見えているのか、下書きだけ残ったのかも分からない。事業の発注なら、相手から返答がないだけで同じ注文を二度出すのは怖いはずです。ブログの公開にも、同じ慎重さが要ります。
この記事はプログラムの専門家だけに向けた話ではありません。WordPressへAPIで投稿している人、外注や生成AIに投稿を任せる人、土日も記事を出したい小さなメディアの運営者に向けて、「何を見れば再開してよいか」を四つの場面で整理します。難しい横文字を覚えなくても、記事の身分証を一つ決める、届いたか調べる、同じものを直すの三点で運用できます。
返事がない投稿は、失敗と決めない

まず、送信と返信は別の出来事です。自分のパソコンから投稿リクエストを送る。WordPressが記事を保存する。WordPressから成功の返事が戻る。この三つの間で通信が切れる可能性があります。例えば保存は終わったのに、返事だけがこちらへ戻らなかったら、画面には「失敗」のように見えても記事は存在します。そこで最初から新しい記事を作り直すと、重複が生まれます。
HTTPの基本仕様をまとめたRFC 9110は、同じ操作を繰り返しても同じ結果になる処理と、そうとは限らない処理を区別しています。新規作成に使うPOSTは、何も確認せず機械的に再試行してよいと考えるべきではありません。WordPressの公式REST APIでも、新規記事は POST /wp/v2/posts、既存記事の更新は POST /wp/v2/posts/<id> と送り先が分かれます。新しくもう一本作る操作と、同じ記事を仕上げる操作は違うのです。
では、タイムアウト画面を見たとき、最初の一分で何をするか。まず送信した原稿、予定スラッグ、記事の内部ID、送信時刻を手元で固定します。次にWordPressの「投稿一覧」とREST APIの取得結果を読みます。WordPressの公式仕様では、投稿一覧をスラッグで絞り、各記事のID、状態、URLを取得できます。スラッグは記事URLの末尾に入る短い名前です。ここで同じスラッグの記事や、下書きに残った記事を探します。
一覧に見当たらない場合でも、すぐに「絶対に未送信」とは言いません。閲覧用の一覧は通常、公開済み記事が中心で、下書きは認証が必要な範囲にあります。公開ページだけを見て空でも、下書きとして保存された可能性は残ります。APIの認証が切れているなら、認証を直して読み取りをやり直す。読めない状態を「記事なし」と書き換えないことが大事です。
この境界は、WordPress公式の投稿API仕様と、HTTPのRFC 9110を根拠にしています。すべての環境で同じ通信障害が起きるという話ではなく、「結果が不明な新規作成を無条件で繰り返さない」という安全側の運用です。
記事の身分証は、タイトルではなく固定IDで持つ

「同じ記事か」をタイトルだけで比べると、意外に間違えます。校正で一文字変わることもあれば、違う内容なのに似た見出しになることもあります。だから記事ごとに、制作側で変えない番号を一つ持ちます。例えば「20260917の二本目」という制作上のIDです。そのIDに、WordPressから返った数値の投稿ID、予定スラッグ、公開URLを結び付けます。編集上の日付は管理用であって、後日公開した記事の公開日時を遡らせるためのものではありません。
私なら台帳は大げさにしません。「内部ID」「WordPress投稿ID」「スラッグ」「状態」「実URL」「最後に確かめた時刻」の六欄から始めます。記事の公開を人に任せる場合でも、この一行があれば話が早い。「原稿は完成しました」「下書きはあります」「読者に見えます」のどこまで進んだかを分けて答えられます。逆に「完了」とだけ書いた台帳は、トラブルの日に役立ちません。
| タイムアウト後の判断 | NG(✕) | OK(◯) |
|---|---|---|
| 公開ページに見えない | すぐ新規投稿を再送 | 下書きも含めて同じIDを探す |
| 同じ題名の記事がある | 題名だけで同一と決める | 投稿ID・スラッグ・本文を照合 |
| 記事IDが確認できた | もう一度新規作成 | そのIDの既存記事を更新する |
| 読取APIも失敗 | 「記事はない」と記録 | 確認不能と記録し、認証を回復 |
スラッグにも注意が必要です。同じ文字列を送れば必ず同じ投稿へ書き込まれる、という仕組みではありません。WordPressは投稿のスラッグを一意に保つ処理を持ちますが、それを「二重投稿を防ぐ保証」と見なすと危険です。投稿IDで既存記事を指定して更新すること、公開済みのURLを照合することが実務の中心です。スラッグが変化したり末尾に数字が付いたりしたら、そこで立ち止まり、別記事ができていないか確認します。
ここでいう「固定」は、タイトルの修正や本文の追記を禁じる意味ではありません。固定するのは記事の同一性です。記事の中身は必要に応じて改善できます。注文番号を変えずに納品書の誤字を直す感覚に近いでしょう。重複を防ぎながら、品質を上げられます。
再開は「送信前・送信中・送信後」で分ける

自動化の仕組みは、失敗のたびに新しい作業を起こすより、同じ記事のどこまで進んだかを引き継ぐ形が向いています。送信前なら原稿を検査する。送信中に通信が切れたなら、WordPress側を読む。送信後にURLが分かったなら、読者向けのページを確認する。これを一本の流れにしておきます。各段階の「次にすること」が決まっていれば、席を外していても、同じ再送ボタンを押すだけのループにはなりません。
送信前:中身と対象を固定する
本文、見出し、画像、リンク、カテゴリー、投稿先アカウントを確かめます。未完成の画像や別記事の広告が混じっていないか、個人を特定できる情報が残っていないかも確認します。この時点で原稿と画像の版を記録しておくと、後で「送ったのはどの版か」を照合できます。版が変わったのに、前の確認結果をそのまま使わないことも必要です。
送信中:結果不明は、まず読み取る
送信直前に「この内部IDの作業を始めた」と記録し、送信後にはWordPressの投稿IDか失敗理由を残します。通信が途切れて結果不明になったら、同じIDやスラッグの投稿を探すまで再送しません。見つかった記事が下書きなら、その投稿IDを使って本文と画像を読み戻し、足りないところだけ直します。公開済みなら新規作成は不要です。確認しても存在が確定できない場合は、再試行をする前に、認証やサーバー側の応答を調べます。
送信後:APIの返事と読者の画面は別
APIから成功の返事が来ても、それだけで作業終了にはしません。実際の公開URLを開き、記事タイトル、本文、画像、リンクが読者に見えるか確かめます。スマートフォン幅で表が横にはみ出ないか、画像に文字を入れた場合は小さくしても読めるか。WordPressの下書きと公開画面では、テーマの見え方が変わることもあります。公開直後の確認は、システムのためというより読者のためです。
APIの認証が外れたときに、パスワードや認証コードをログへ書いたり、ブラウザのCookieを抜き出したりしないでください。WordPressは外部ツール向けにアプリケーションパスワードを案内していますが、使う場合もHTTPSと権限管理が前提です。必要な本人認証は公式の手順で回復し、資格情報を記事制作の台帳やチャットへ貼らないことが安全です。
毎日続けるなら、投稿本数より「欠けの見つけ方」を決める

二重投稿を避ける話は、投稿し忘れを見つける話とセットです。完成した原稿の一覧だけを見ていると、そもそも記事が作られなかった日は見えません。毎日二本と決めるなら、日付ごとに二つの枠を先に用意し、各枠へ内部ID、制作、下書き、公開、実URLの状態を入れます。空欄なら空欄のまま、不足として残します。翌日の二本を出しても、前日の空欄は勝手に消しません。
一記事をWordPress、note、Xなどに広げる場合も、媒体ごとの状態を別に持ちます。WordPressが公開済みでも、Xが未投稿ならXだけ未完。Xだけが通信不明なら、Xの公式投稿一覧を先に見ます。WordPressまで作り直さない。一つの媒体のエラーで全作業を止めないことと、同じ媒体へ重複させないことは両立します。
確認の間隔は短ければよいわけではありません。毎分同じ画面を調べても、原稿や認証の問題は直りません。「次に確認できる時刻」と「次に実行する操作」を記録して、予定された再開時刻に同じIDから続けます。障害で何も動かせない日は、無理に成功と数えるより、何が読めず、何を待ち、何が動かせるかを分けて残す方がいい。経営の現場でも、在庫が不明なまま出荷済みにしないのと同じです。
収益リンクも公開可否と分けます。記事の疑問に独立して答えているなら、適合する広告が見つからないだけで公開を止める必要はありません。後から適合商品やサービスを確認できた場合に、同じWordPress投稿IDの本文を更新します。関係の薄い商品や未確認の価格をとりあえず貼るより、読者の信頼を守れます。ただし広告を載せたなら、リンク先、商品名、表示条件、画像の使用権、広告であることの表示は更新時に確認します。
最終報告はシンプルで十分です。日付ごとの新規必要数と公開数、記事ごとのWordPress実URL、各媒体の実URL、未完の工程と次の再開点。ここまでそろって初めて「公開済み」と言える。ダッシュボードの緑色や「送信しました」という一文より、読者が実際に開けるページが一番強い証拠です。
参考資料:WordPress REST API:Posts、WordPress REST API:Authentication、RFC 9110:HTTP Semantics。APIの仕様は更新され得るため、実装時には現行の公式資料と自分のサイトの設定を再確認してください。
よくある質問(Q&A)
Q. タイムアウトしたら何回まで再送してよいですか?
A. 回数で決めません。最初の送信が届いたか確認できない間は、同じ新規作成を繰り返さないのが基本です。公式の投稿一覧と既知のIDを調べ、未作成を確かめてから再開します。
Q. スラッグを同じにすれば二重投稿を防げますか?
A. それだけには頼れません。WordPress投稿IDと公開URLを記録し、既存記事があればそのIDの更新へ進めます。スラッグは照合に役立ちますが、単独の保証ではありません。
Q. ほかのSNSだけ未投稿なら、WordPressも公開し直しますか?
A. いいえ。WordPressで公開済みの同じ記事を新規作成し直さず、未完の媒体だけ公式状態を確認して続けます。全媒体の成功を一つの送信結果から推測しないことが大切です。
「返事がない」と「仕事が終わっていない」は、似ていて違います。二重投稿も、届いたか分からないまま新しい一本を作るところから始まりがちです。焦る時ほど、まず相手側の状態を確かめる。この順番は、ブログだけでなく、日々の仕事を任せる時にも使える考え方だと思います。
自動化は、人が何も見なくてよくなる魔法ではありません。できた記事、届かなかった返事、空いたままの日付をそれぞれ分けておけば、翌日も同じ記事から落ち着いて再開できます。元球児や経営者としてだけでなく、親として迷いながら選ぶ話は「親父の奮闘記」にもまとめています。

コメント