GitHub ActionsだけでXの自動投稿botを作る
サーバー不要・月2ドル台の設計図
X(旧Twitter)の自動投稿botを、サーバーなし・GitHub Actionsだけで運用している。月のコストは約2.25ドルで、そのほぼ全てがX APIの従量課金。インフラ代は0円だ。
「bot 作り方」で検索するとVPSを借りる記事が今も出てくるが、毎日数回投稿する程度のbotにサーバーは要らない。ここでは実際に運用している構成の設計図を書く。
全体像
[posts.json(投稿ストック)]
│
[GitHub Actions (cron)] → [post.py] → [X API]
登場人物は3つだけ。投稿文のストックを入れたJSONファイル、定時に起動するワークフロー、そして投稿処理を行う数十行のPythonスクリプト。データベースも管理画面もない。
設計判断1: 投稿文は「その場で生成」せず「ストック」する
AIでbotを作るというと、実行のたびにLLMで文章を生成する構成を想像しがちだが、私はやらない。理由は2つ。
1つ目は品質管理。生成して即投稿する構成では、事故った文章がそのまま世に出る。ストック方式なら事前にまとめて生成して全件目視できる。自動化するのは「投稿作業」であって「品質保証」ではない、というのが私の線引きだ。
2つ目はコスト。毎回LLMを呼ぶと課金が投稿回数に比例して読めなくなる。生成は月に数回まとめてやれば実質無料の範囲に収まる。
設計判断2: 状態管理を持たない
「どの投稿を使ったか」を記録するDBやファイルを持つと、その保存が失敗したときの考慮が必要になり複雑になる。私の構成では「起点日からの経過日数 % ストック本数」で今日の1本を決める。完全にステートレスで、何回実行しても同じ日は同じ投稿が選ばれる。壊れる状態が存在しないものは、壊れない。
day_number = (today - EPOCH).days
post = pool[day_number % len(pool)]
設計判断3: 沈黙する失敗を作らない
無人システムの最大の敵は「止まっていることに気づけない停止」だ。私のbotも一度、APIトークンの失効で静かに止まっていたことがある。以来、投稿失敗時はワークフローを明示的に失敗させ、通知が飛ぶようにしている。正常に動いた記録より、失敗の通知の方がずっと重要だ。
コストの現実(2026年時点)
X APIは従量課金制で、テキストのみの投稿は1回あたり約0.015ドル、URL入りは約0.20ドルと13倍に跳ねる。1日5投稿・テキストのみなら月約2.25ドル。宣伝リンクを毎回貼りたくなるが、コストが13倍になる価値があるかは冷静に判断した方がいい。
GitHub Actionsはこの規模なら無料枠で十分足りる。cronの起動時刻は混雑時に数十分ずれることがあるので、分単位の正確さが必要な用途には向かない。
この構成の応用範囲
「ストック生成 → cron実行 → ステートレス選択」の3点セットは、X以外にもそのまま使える。定期実行系の自動化の基本形として、最初に習得する価値がある骨格だと思っている。