「SNSは毎日投稿が大事」と分かっていても、毎日決まった時間に手を止めて投稿するのは、実際にやってみるとかなりの負担です。
**この記事の結論:**うちでは、X(旧Twitter)への投稿をGitHub Actionsで自動化して運用しています。毎日3回(朝・昼・夜)、決まった時間に自動で投稿され、サーバー代は0円。PCの電源が入っていなくても動きます。
この記事では、その構成と作り方の流れ、実際に運用して分かったハマりどころを公開します。
この記事で分かること:
- サーバーを借りずにbotを動かす「GitHub Actions」という選択肢
- 自動投稿の全体構成(何と何を組み合わせるか)
- 時差・起動遅延など、作ってみて初めて分かるハマりどころ
1. 全体の構成 — 登場するのは4つだけ
仕組みはシンプルで、登場する部品は4つです。
投稿ストック(リポジトリ内のファイル)
↓
GitHub Actions(毎日決まった時刻に起動するスケジューラー)
↓
Pythonスクリプト(ストックから1件取り出して投稿)
↓
X API(実際の投稿処理)
投稿する文章はあらかじめ「ストック」としてリポジトリ内に用意しておき、GitHub Actionsが決まった時刻にスクリプトを起動して、1件ずつ投稿していく方式です。APIキーなどの認証情報はコードに直書きせず、GitHub Secrets(暗号化された保管場所)に登録して環境変数として渡します。
2. なぜGitHub Actionsなのか — 3つの選択肢の比較
定時実行のbotを動かす方法は他にもあります。比較すると:
| 方法 | 費用 | 特徴 | 弱点 |
|---|---|---|---|
| 常時稼働サーバー(VPS等) | 月数百〜数千円 | 自由度が最も高い | サーバー管理の手間、費用が常にかかる |
| ノーコード自動化ツール | 無料〜月数千円 | 画面操作で作れる | 実行回数制限、細かい制御がしにくい |
| GitHub Actions | 無料枠内なら0円 | コードもスケジュールもGitで一元管理 | 起動時刻に遅延がある(後述) |
1日数回の投稿という用途なら、GitHub Actionsの無料枠で十分収まります。「サーバーを持たない・管理しない・費用をかけない」が、小さく始める自動化と相性がいい理由です。
3. 作り方の流れ — 5ステップ
詳細な手順は環境によって変わるため、ここでは全体の流れを押さえます。
- X開発者アカウントの登録 — X Developer PortalでAppを作り、APIキー一式を取得する
- リポジトリの用意 — 投稿スクリプトと投稿ストックを置くGitHubリポジトリを作る
- Secretsの登録 — APIキー一式をリポジトリのSettings → Secretsに登録(コード直書きは厳禁)
- 投稿スクリプト — Pythonならライブラリ(tweepy等)でX APIを叩く。ストックから1件読んで投稿するだけの小さなスクリプトで足ります
- ワークフローの作成 —
.github/workflows/にYAMLを置き、cron(時刻指定)で毎日起動させる
最小構成のワークフローはこんな形です(毎朝7時JSTに投稿スクリプトを実行する例):
name: auto-post
on:
schedule:
- cron: "0 22 * * *" # JST朝7時。UTCで指定する点に注意(後述)
jobs:
post:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install tweepy && python post.py
# APIキーはSettings→Secretsに登録し、envブロックで渡す(コード直書きは厳禁)
たったこれだけで「毎朝7時に投稿スクリプトが動くサーバー」が手に入ります。
サーバー代0円で毎日動く仕組みを作る流れです。
4. ハマりどころ3つ — 作ってみて初めて分かること
① cronの時刻はUTC(日本時間ではない)
GitHub Actionsのcron指定は世界標準時(UTC)です。日本時間はUTC+9なので、たとえば朝7時(JST)に動かしたければ0 22 * * *(前日22時UTC)と書きます。ここを知らずに設定すると、投稿が9時間ズレます。最初にほぼ全員が踏むポイントです。
② cronは「その時刻ぴったり」には動かない
GitHub Actionsのスケジュール実行は、指定時刻から数分〜数十分遅れることがあります(共有インフラのため、混雑時間帯ほど遅れやすい仕様です)。「7時00分ちょうどに投稿」を保証する仕組みではないので、分単位の正確さが必要な用途には向きません。SNS投稿のように「朝のうちに出ればいい」用途なら実害はありません。
③ APIの権限設定と無料枠の確認
X APIはアプリの権限が「読み取りのみ」になっていると投稿できません(Read and Write権限が必要)。また、APIの無料枠には投稿数の上限があるため、自分の投稿頻度が枠に収まるかは事前に確認しておく必要があります。1日数回の投稿なら通常は問題になりません。
運用して初めて分かった注意点です。
5. 運用して分かったこと — 自動化は「器」でしかない
仕組みを動かして実感したのは、自動化そのものは投稿の質を1ミリも上げないということです。自動化が解決するのは「毎日手を止めて投稿する」という作業負担だけで、伸びるかどうかは投稿の中身で決まります。
うちの運用では、投稿文はまとめて作成・レビューして「ストック」として積んでおき、botはそれを順番に出すだけ、という分担にしています。中身を作る工程と、出す工程を分離する——これが継続できている一番の理由だと考えています。
あわせて読みたいブログを半自動化した話 — AIに書かせて、公開ボタンは人間が押す
よくある質問
プログラミングができないと無理ですか?
スクリプト自体は小規模なので、AI(ChatGPTやClaude)に「tweepyでX投稿するスクリプトを書いて」と依頼して土台を作る進め方が現実的です。ただし、APIキーの管理(Secrets登録・直書き禁止)だけは仕組みを理解してから動かすことを強くおすすめします。
アカウントが凍結されるリスクはありませんか?
API経由の自動投稿はXが公式に提供している正規の機能なので、自動化していること自体は問題ありません。リスクがあるのは中身の方で、スパム的な内容・過剰な頻度はアカウントの評価を下げます。
費用は本当に0円ですか?
GitHub Actionsは無料枠(パブリック/プライベートリポジトリで条件が異なります)の範囲内なら0円、X APIも無料プランの範囲内なら0円です。うちの運用(1日3投稿)はどちらも無料枠に収まっています。
まとめ
- GitHub Actions+X APIで、サーバー代0円の自動投稿botが作れる
- cronはUTC指定(JSTマイナス9時間)。時刻は数分〜数十分遅延する前提で設計する
- APIキーはSecretsで管理。コード直書きは厳禁
- 自動化は器。中身を作る工程(人間)と出す工程(bot)を分離すると続く
こうした業務自動化の構築は僕が実務でやっている領域です。「自社のこの作業も自動化できないか」という相談はお問い合わせからどうぞ。サイト改善の実録はブログ一覧にもまとめています。

関連記事
切り抜き・AI導入の相談
記事の内容についての質問や、切り抜き運用・AI導入の相談は、お問い合わせからどうぞ。
