GitHub ActionsでSNS自動投稿する方法｜定期実行・Secrets・重複投稿対策
ブログの更新情報や定期的なお知らせをSNSへ投稿するとき、毎回同じ操作を繰り返していませんか。投稿用のプログラムを用意すれば、GitHub Actionsを使って、手動操作や定期的な実行につなげられます。
GitHub ActionsによるSNS自動投稿は、実行タイミングを管理するワークフローと、SNSのAPIを呼び出す投稿プログラムを組み合わせて作ります。YAMLファイルを置くだけで、各SNSへの投稿機能が完成するわけではありません。
この記事では、Pythonの投稿スクリプトをGitHub Actionsで動かすための設定を中心に、Secretsの登録、定期実行、重複投稿の防止、失敗時の確認方法を解説します。SNSごとの投稿処理は、利用するサービスの公式API仕様に合わせて用意してください。
GitHub Actionsの仕様は2026年10月2日時点の公式資料を確認しています。利用料金やSNSのAPI仕様は、導入時にも最新情報をご確認ください。
目次
1. GitHub ActionsでSNS自動投稿する仕組み
GitHub Actionsは、GitHub上で設定した条件に応じてプログラムなどを実行する仕組みです。コードの変更をきっかけにテストを行う用途のほか、手動実行や定期実行にも利用できます。
SNS自動投稿では、ワークフローが実行環境を準備し、その環境で投稿スクリプトを動かします。スクリプトは投稿対象を選び、SNSのAPIへ送信し、結果を記録します。
| 構成要素 | 担当すること |
|---|---|
| ワークフロー | 実行条件、Pythonの準備、スクリプトの起動 |
| 投稿スクリプト | 投稿対象の選定、本文の作成、SNS APIの呼び出し |
| 認証情報 | 対象アカウントへの投稿に必要なアクセス許可 |
| 投稿履歴 | 投稿済みの内容や、SNS側の投稿IDの記録 |
ブログの更新を告知する場合は、RSSや記事データから新着情報を取得する処理も必要です。WordPressで記事を公開しただけでは、GitHubへのコード変更を示すpushイベントは発生しません。記事の更新をどの方法で検知するかも決めましょう。
2. 最初にSNS側のAPIと投稿スクリプトを準備する
投稿に必要な認証方式は、SNSや利用するAPIによって異なります。APIキーだけでなく、利用者の操作権限を持つアクセストークンや、トークンの更新処理が必要になる場合もあります。
複数のSNSへ投稿したい場合も、まず一つのSNSで動作を確認しましょう。投稿可能な文字数、画像の扱い、APIの利用条件、料金、投稿回数の制限を公式資料で確認します。
投稿スクリプトに用意する処理
- 投稿する記事や文章を選ぶ。
- 本文、リンク、画像などが投稿条件を満たしているか確認する。
- 同じ対象を投稿済みでないか確認する。
- 必要な認証情報を環境変数などから読み込む。
- SNSのAPIへ送信し、成功時の投稿IDを記録する。
- 失敗や結果不明の場合は、成功として処理しない。
ここでは、投稿スクリプトのファイル名をpost_sns.pyとします。依存するPythonライブラリはrequirements.txtに記載し、動作確認したバージョンを管理してください。
投稿せずに確認できるドライランを用意する
ドライランとは、実際の送信を行わず、投稿対象の選定や内容の組み立てを確認する動作です。テスト時にSNSへ何度も投稿しないよう、スクリプト側に切り替えを用意しましょう。
この記事の設定例では、環境変数DRY_RUNを使います。この変数はGitHub Actionsの標準的な投稿停止機能ではなく、自作スクリプトが読み取って処理を切り替えるためのものです。変数を設定するだけでは送信を止められません。
Pythonでは、環境変数から取得した"false"も文字列です。文字列をそのまま真偽値として扱わず、"true"などの値と比較し、送信する前に分岐させてください。ドライランでは、投稿済みの記録も更新しないようにします。
APIを呼び出すプログラムの基本から確認したい方へ。開発方法の選び方と、Pythonで通信結果やエラーを扱う実装例を紹介しています。
API連携の始め方｜開発方法の選び方とPythonの実装例 記事を読む →3. 認証情報をGitHubのSecretsへ登録する
秘密のAPIキーやアクセストークンを、PythonファイルやYAMLへ直接書かないようにします。GitHub Actionsでは、Secretsに保存した値を、必要なステップへ渡せます。
リポジトリの設定画面から「Settings」→「Secrets and variables」→「Actions」へ進み、「New repository secret」で登録します。組織の設定や権限によって操作できる範囲が異なるため、項目が表示されない場合は管理者に確認してください。
Secretsの名前と、スクリプトの変数名を対応させる
後のYAMLでは、例としてSNS_ACCESS_TOKENという名前を使います。これはこの記事で決めた名前であり、すべてのSNSがこの名前のトークンを使うという意味ではありません。
複数のキーが必要なAPIなら、それぞれをSecretsに登録し、スクリプト側が読み取る環境変数に対応させます。GitHub用のGITHUB_TOKENを、そのままSNSへの投稿用トークンとして使うことはできません。
Secretsへ登録した後も、実行するコードを管理する
Secretsの値を渡されたプログラムは、その値を利用できます。リポジトリやワークフローを書き換えられる人の権限、使用する外部アクション、依存ライブラリも管理しましょう。
ログの自動マスキングだけに頼らず、キーやトークンを出力しない実装にします。漏洩した可能性がある場合は、コードから削除するだけで終わらせず、対象の認証情報を失効・再発行してください。
APIキーとアクセストークンの違いや、どの情報を秘密として管理すべきかを整理したい方は、こちらもご覧ください。
APIキー・アクセストークン・シークレットキーの違いとは？API認証と安全な管理の基本 記事を読む →4. まずは手動実行するワークフローを作る
最初は、GitHubの画面から実行するworkflow_dispatchだけを設定します。投稿対象や認証情報を確認してから、定期実行を追加しましょう。
次の例は、リポジトリの直下にpost_sns.pyとrequirements.txtがあり、スクリプトがDRY_RUNと必要な認証情報を読み取る前提です。投稿先のAPI呼び出しや投稿履歴の保存は、スクリプト側に実装してください。
ワークフローの設定例
次の内容を.github/workflows/auto-post.ymlとして保存します。Pythonのバージョンは、投稿スクリプトと依存ライブラリで動作確認したものに合わせてください。
name: SNS Auto Post
on:
workflow_dispatch:
permissions:
contents: read
concurrency:
group: sns-auto-post
cancel-in-progress: false
jobs:
post:
runs-on: ubuntu-latest
timeout-minutes: 10
steps:
- name: Checkout repository
uses: actions/checkout@v7
with:
persist-credentials: false
- name: Set up Python
uses: actions/setup-python@v7
with:
python-version: "3.13"
- name: Install dependencies
run: python -m pip install -r requirements.txt
- name: Run posting script
env:
DRY_RUN: "true"
SNS_ACCESS_TOKEN: ${{ secrets.SNS_ACCESS_TOKEN }}
run: python post_sns.pyこの例では、確認日時点の公式READMEに掲載されているactions/checkout@v7とactions/setup-python@v7を使用しています。継続運用では、変更内容を確認して更新し、利用するアクションを完全なコミットSHAで固定する方法も検討してください。
各設定の役割
| 設定 | 役割 |
|---|---|
workflow_dispatch |
GitHubの画面などから手動実行できるようにする |
permissions: contents: read |
このワークフローで使うGITHUB_TOKENの権限を、リポジトリ内容の読み取りに限定する |
persist-credentials: false |
チェックアウト後のGit操作用に認証情報を保持しない |
concurrency |
同じグループの実行が同時に進むことを抑える |
timeout-minutes |
ジョブの実行時間に上限を設ける |
DRY_RUN: "true" |
対応する自作スクリプトに、送信しない確認動作を指定する |
permissionsはGitHub側の権限設定であり、SNSトークンの投稿権限を変更するものではありません。また、タイムアウトでジョブが終了しても、すでにSNS側で完了した投稿は取り消されません。
手動実行で確認する
ワークフローファイルをデフォルトブランチへ保存したら、「Actions」タブで対象のワークフローを開き、「Run workflow」から実行します。最初はドライランで、対象件数や本文の組み立てが意図どおりかを確認してください。
実際に投稿するテストでは、投稿対象を一件に絞り、スクリプトの送信処理と投稿履歴を確認したうえで、DRY_RUNを"false"に変更します。Actionsの成功表示に加えて、SNS側の投稿内容と、保存した投稿IDも確認しましょう。
5. 定期実行を追加する｜日本時間と遅延への注意
手動実行で動作を確かめたら、定期実行を追加します。現在のGitHub Actionsでは、scheduleにtimezoneを指定できるため、日本時間で予定を書けます。
毎日、日本時間の8時17分を実行予定にする例
先ほどのYAMLのon部分を、次の内容へ置き換えます。permissions以降の設定は、そのまま残してください。
on:
workflow_dispatch:
schedule:
- cron: "17 8 * * *"
timezone: "Asia/Tokyo"これは毎日8時17分を実行予定にする設定です。timezoneを省略した場合はUTCで解釈されるため、日本時間と混同しないようにしてください。
また、定期実行でも同じDRY_RUNの設定が使われます。"true"のままなら確認動作が続き、"false"ならスクリプトの実装に従って投稿します。
指定時刻ちょうどの投稿は保証されない
定期実行は、GitHub Actionsの混雑などによって遅れることがあります。負荷が高い場合には、一部の実行が行われないこともあるため、時刻を厳密に守る必要がある用途では、この条件を踏まえて実行基盤を選んでください。
毎時0分などの混雑しやすい時刻を避けることは、遅延の可能性を下げる工夫になります。ただし、時刻をずらせば確実に動くという意味ではありません。
デフォルトブランチと自動停止の条件を確認する
定期実行は、デフォルトブランチにあるワークフローを対象に動作します。作業用ブランチへファイルを置いただけでは、予定した定期実行は始まりません。
公開リポジトリでは、60日間リポジトリに活動がないと、定期実行が自動的に無効化されます。長期運用では、失敗通知だけでなく、予定していた実行自体が発生しているかも確認しましょう。
6. 二重投稿を防ぐために、投稿履歴を保存する
手動で再実行した場合や、複数の実行条件が重なった場合には、同じ記事を再び処理する可能性があります。ワークフローの同時実行を制限するだけでは、時間をずらした重複投稿までは防げません。
投稿先・アカウント・記事を組み合わせて識別する
たとえば、新着記事を一度だけ告知するなら、「SNS名」「投稿先アカウント」「記事ID」の組み合わせで投稿対象を識別します。同じ記事でも複数回告知する運用なら、告知の回や内容の版など、別の投稿として扱う条件も決めます。
投稿が成功したら、その識別情報とSNS側の投稿ID、実行日時を保存します。次回の処理では履歴を参照し、投稿済みの対象を除外してください。
実行環境のローカルファイルだけに履歴を残さない
GitHubホストの実行環境へ書き込んだファイルが、次の実行でもそのまま残るとは考えないようにします。投稿履歴は、次回の実行から確実に読み取れるデータベースや保存先へ記録しましょう。
Actionsのキャッシュや、保存期間のある成果物だけを、重複防止の唯一の記録にするのも避けます。複数の処理が同じ履歴を更新する場合は、同じ投稿対象を同時に確保しない仕組みも必要です。
通信エラーが起きたときは、投稿済みかを確認する
SNS側で投稿が完了していても、応答を受け取る前に通信が途切れることがあります。その状態で無条件に再送すると、同じ投稿が重複する可能性があります。
APIが提供する重複防止機能や投稿結果の取得方法を確認し、結果が不明なら「要確認」として止める方法を用意します。失敗したように見える実行でも、再実行の前にSNS側と投稿履歴を照合してください。
なお、先ほどのconcurrency設定は、実行中の処理を新しい実行で中断しない指定です。既定では待機できる実行にも制限があるため、すべての起動を保存する投稿キューの代わりにはなりません。
7. 投稿されないときの確認方法と料金の考え方
問題を調べるときは、「ワークフローが開始していない」「プログラムが途中で失敗した」「SNSへの投稿結果が不明」のどこに当てはまるかを分けます。原因に関係なく再実行を繰り返すことは避けましょう。
| 症状 | 確認する内容 |
|---|---|
| 実行履歴が作られない | デフォルトブランチ、scheduleの設定、タイムゾーン、ワークフローの有効状態 |
| ライブラリの読み込みで失敗する | requirements.txt、Pythonのバージョン、依存ライブラリの互換性 |
| 認証・権限エラーになる | Secretsの名前、トークンの期限、投稿権限、対象アカウント、APIの利用条件 |
| 成功表示なのに投稿されない | DRY_RUNの値、投稿対象の有無、投稿済み判定、エラーを隠していないか |
| 投稿の直後に処理が失敗する | SNS側の投稿結果と、履歴保存の成否。再送前に確認する |
ログには、処理件数、内部の投稿識別情報、成功・失敗の状態などを残します。秘密情報や未公開の本文を必要以上に記録しないよう、ログの公開範囲も考えてください。
GitHub Actionsは無料で使える？
公開リポジトリで標準のGitHubホストランナーを利用する場合、実行時間は無料で利用できます。ただし、大型ランナーは公開リポジトリでも有料であり、すべての構成が無料になるわけではありません。
非公開リポジトリでは、プランに応じた無料枠と、超過分の料金を確認します。保存容量などの費用に加えて、SNS側のAPI料金や外部のデータ保存先の料金も別に見積もりましょう。
複数のSNSへ投稿する場合は、成功状態を分ける
一つ目のSNSで成功し、二つ目で失敗することもあります。処理全体を最初からやり直すと、成功済みのSNSへ再投稿してしまうため、投稿履歴はSNS・アカウントごとに管理します。
APIの上限やトークンの期限も、投稿先ごとに異なります。最初は一つのSNSで運用を確認し、投稿先を増やす際に、履歴とエラー対応も追加しましょう。
投稿文の下書きなどにAIを組み合わせたい方へ。自動処理と人の確認を分け、エラーや費用を管理するワークフローの設計方法を解説しています。
AIとAPI連携で業務を自動化する方法｜ワークフロー設計と安全な運用の基本 記事を読む →8. 手動確認から定期運用へ進めるチェックリスト
定期実行を始める前に、投稿できることだけでなく、投稿しない条件や失敗時の扱いを確認します。止めたいときはワークフローを無効化し、実行中の処理と、すでに投稿された内容を別に確認してください。
- SNSのAPI利用条件、投稿権限、料金を確認した。
- 投稿スクリプトを用意し、ドライランが送信前に分岐することを確認した。
- 認証情報をSecretsへ登録し、コードやログに出していない。
- 手動実行で、投稿内容と投稿IDを確認した。
- 投稿履歴を、次回の実行でも参照できる場所へ保存している。
- 再実行や通信切断時の重複投稿対策を用意した。
- 定期実行の時刻、タイムゾーン、停止条件を確認した。
- 実行失敗だけでなく、予定した実行がなかった場合も確認できる。
GitHub ActionsによるSNS自動投稿は、投稿プログラムを継続して動かすための選択肢です。まずは一つのSNSで、ドライラン、手動投稿、定期実行の順に確認し、運用できる範囲を広げましょう。
自動化した後も、投稿内容やリンク先、読者の反応を見直す時間は必要です。繰り返しの操作を減らしながら、何を届けるかの確認と改善を続けてください。
参考資料
- GitHub Docs：定期実行を含むワークフローの実行条件
- GitHub Docs：GitHub ActionsでのSecretsの利用
- GitHub Docs：ワークフローとジョブの同時実行制御
- GitHub Docs：GitHub Actionsの課金
- GitHub：actions/checkout
- GitHub：actions/setup-python
Learning Tools
記事を検索したい方はここから！
記事を検索
関連記事や、今の内容に近いテーマをすぐに検索できます。
例: AI / 情報Ⅰ / Python / 統計 / 資格 / 学習法