対象: 2026年5月のSNS自動投稿準備
確認範囲: tacademy.jp向けのREADMEと状態ファイル
記録上の注意: 実際のSNS投稿は確認できていません
ブログの記事を見つけることと、SNSへ実際に届けることは、ひと続きの自動化に見えても別の仕事です。5月の作業で形にしようとしたのは、その間をつなぐ小さなPythonスクリプトでした。ただし、残された記録が示すのは設計とテストの入口までです。「投稿済み」という表示だけで、XやPinterestに公開されたと決めてよいのか。そこは分けて考える必要があります。
記事を見つけて、投稿文へ渡す
当時の対象は tacademy.jp のWordPressでした。後に扱う tac-ademy.com とは別のサイトです。READMEに記された案では、WordPress REST APIから新着記事を読み込み、APIが使えない場合はRSSフィードへ切り替えます。Xには記事タイトルとURLを、Pinterestにはタイトル、説明、記事URL、アイキャッチ画像を渡す想定でした。
外部サービスを呼ぶ前に、記事の発見と投稿文の組み立てを分ける。構造が小さい分、どこで止まったかを追いやすくする考え方です。Zapierなどを挟まずPythonでつなぐ案も、READMEには明記されています。ただし、これは当時の設計として書かれた機能説明であり、稼働中の自動投稿を実証する運用記録とは違います。
取得経路を二つにしたのは、WordPress APIの応答がないときにRSSへ回すためです。ここで担保されるのは記事情報を探す入口であって、XやPinterestへの送信成功ではありません。記事の取得、投稿用データの組み立て、外部APIの応答を別々に見られる形にしておけば、失敗を「自動投稿が動かなかった」の一言で片づけずに済みます。
二重投稿を防ぐ記録は、投稿証明ではない
一度扱った記事をもう一度送らないよう、投稿済みURLを state/posted.json に記録する設計もあります。初回は既存記事をまとめて「処理済み」として登録し、過去記事を一気に流さない方針です。状態ファイルには記事URL、タイトル、marked_at が並びます。
けれど、時刻が記録されていることと、SNS側で投稿が成功したことは同じではありません。このファイルは重複を避けるための内部状態として読めますが、投稿APIの成功応答、公開URL、画面記録は確認できませんでした。初回に既存記事を登録する処理なら、なおさら「投稿済み」の語を外部公開の証拠として扱えません。
READMEも初回実行時は過去の記事を投稿済みとして先に記録し、古い記事をまとめて送らない流れを案内しています。その後、必要に応じて既存記事を除外する設定を切り替える構成です。したがって、状態ファイルの日時は「このURLを内部で処理済みにした時刻」と読むのが安全です。送信結果と同じ一覧にしてしまうと、二重投稿対策の記録が、いつの間にか公開実績に見えてしまいます。
dry-runの先に残った確認
READMEには --dry-run を使うテスト手順があり、APIへ送る前の確認経路が用意されています。APIを使えない場合に、XやPinterest向けの文面だけをファイルに出す案も記載されています。つまり、いきなり公開するのではなく、検出・整形・送信を段階に分ける余地がありました。一方、手順書があることだけでは、そのテストがどの条件で実行され、何を確認したかまでは分かりません。
READMEには個別のテスト投稿用コマンドも載っていますが、これも「投稿を試せる」という手順の説明です。実行ログや返却された投稿IDがなければ、試験投稿を送ったとは言えません。安全側に倒すなら、dry-runの出力、投稿APIの応答、実際の投稿先URLを一つの実行記録に結びつけること。確認した工程と、まだ確認していない工程を分けるだけで、月次ログの意味はずっと明瞭になります。
ここで確認できる到達点は、自動投稿の設計とdry-runの入口、そして重複防止用の状態管理です。実SNSへの投稿が成功したという証拠はありません。次にログを残すなら、内部の処理済み記録とは別に、送信先、API応答、公開された投稿URLを対応づける必要があります。そうして初めて、「準備した」と「届けた」の境目を確かめられます。
