X自動投稿を再設計する — 403エラーからの運用改善

2026年8月4日

アマグラマー

X自動投稿を再設計する — 403エラーからの運用改善

以前GCVP側のブログで、X API v2でPOST /2/tweetsが403「You are not permitted to perform this action」になる原因を取り上げました。今回はその後日談です。403の原因を直しただけでは終わらず、SNS運用の設計そのものを見直すことになった経緯を振り返ります。

前回のあらすじ — 403の原因はスパム判定

前回の記事の要点だけ振り返ると、X API v2で投稿がブロックされた原因は、ハッシュタグの付け方がXのスパム判定に引っかかっていたことでした。対処として、edit_optionsを使って「ハッシュタグ無しで投稿→編集で追加」を自動化する方法を実装し、403自体は解消しました。

これで「自動投稿の技術的な障害」は片付いたはずでした。しかし、しばらく運用を続けるうちに、技術的な障害とは別の問題が表面化しました。

見つかった本当の問題 — ほぼ同一内容の重複投稿

evergreenテーマ（測地系や座標変換の豆知識など、期限のないネタ）を毎日決まった数だけ機械的に消化していく設計にしていたところ、日を空けて投稿した2件が、ほぼ同一の内容になってしまう事故が発生しました。結果として、一方を本人が手動で削除する対応を取ることになりました。

原因を振り返ると、「その日の担当分を機械的に順番消化する」という設計そのものに無理がありました。ネタの元データ（スケジュールJSON）に内容の近い案が複数残っていると、順番に消化しているだけでは重複に気づけません。403エラーのような「Xに拒否される」失敗はすぐに気づけますが、「投稿には成功するが内容が重複している」失敗は、API側では一切エラーにならないため、事後に人間が気づくしかないという性質の悪さがありました。

再設計した3つの点

この事故を受けて、運用を次の3点で見直しました。

重複回避チェックの新設：原稿を作る前に、既存の投稿予定・投稿済み内容と照合するチェック工程を追加しました。
スケジュールデータの整理：投稿案データに残っていた実質的な重複案を洗い出し、削除しました。
投稿構成の変更：毎日の投稿を「evergreen1件＋その日実際に公開されたブログ記事のダイジェスト1件」という構成に変更しました。ダイジェスト側は当日新しく公開された記事の中からランダムに1件を選ぶため、内容が構造的に重複しにくくなります。

evergreenのような「いつ投稿しても良いネタ」を機械的に消化する設計は効率的に見えますが、消化順序だけに頼ると同じような内容が近い日程で重なるリスクを常に抱えます。一方、その日実際に公開された記事を紹介する仕組みは、日々の実態と連動しているため、自然と内容がばらけるという副次的な利点がありました。

自動化した部分・人間に残した部分

もう1つ大きく変えたのは、「投稿」という最後の一手を自動化の対象から外したことです。原稿の生成・重複チェック・画像やリンクの選定はスクリプトが行いますが、実際にXへ投稿するボタンは、本人が原稿を確認したうえで手動で押す、という運用に切り替えました。

これは、git commitを人間が行うという判断と根っこが同じです。自動化が壊れたときの被害の大きさで線を引くと、原稿作成の失敗は「作り直せばよい」程度で済みますが、誤投稿・重複投稿は公開済みの情報として残ってしまい、取り消しのコストが高くつきます。取り消しコストが高い操作は、最後の判断を人間に残す、という考え方です。