GitHubのCI/CDランナーをSNS投稿の定期実行基盤として使う——この発想はシンプルながら、無料枠で本番運用できる自動化パイプラインを手軽に構築できる点で実用性が高い。今回は、Node.jsとGitHub Actionsを組み合わせてFacebookページへの定期投稿を完全自動化する構成を取り上げ、その設計上のポイントを整理する。
Metaのトークン設計と自動化の難所
Facebook Graph API(Metaが提供するプログラマブルなSNS操作インターフェース)を使って投稿を自動化する際に最初の壁となるのが、アクセストークンの有効期限と権限構造だ。通常のユーザートークンは有効期限が短く、自動化には適さない。Meta側がユーザートークンによる `publish_actions` 権限を廃止したため、個人アカウントのトークンで直接投稿するアプローチはそもそも使えなくなっている。
この問題の公式な解決策が「Metaビジネスシステムユーザー(Business System User)」だ。これはMeta Business Suite上で作成できる、人間のアカウントに紐づかないサービスアカウントに相当する存在で、特定のFacebookページに対してフルコントロール権限を与えられる。このシステムユーザーから発行したトークンは有効期限が長く、無人の定期実行に向いている。
システムユーザートークンから実際の投稿に必要な「ページアクセストークン」を動的に取得する部分がスクリプトの核心になる。Graph APIの `/me/accounts` エンドポイントを叩くと、そのシステムユーザーが管理するページの一覧とそれぞれのページアクセストークンが返ってくる仕組みだ。これにより、マスタートークン1本をシークレットとして保持しておけば、実行のたびにページトークンを自動取得できる。
// /me/accounts でページトークンを動的取得する例
const url = `https://graph.facebook.com/v21.0/me/accounts?access_token=${SYSTEM_USER_TOKEN}`;
const response = await axios.get(url);
const targetPage = response.data.data.find(p => p.id === PAGE_ID);
const pageAccessToken = targetPage.access_token;GitHub ActionsのスケジューラとSecrets管理
GitHub Actionsは通常「コードのプッシュやPRをトリガーにCIを走らせる」用途で使われるが、`schedule` トリガーを使うとcron形式で定期実行できる。パブリックリポジトリなら無料枠の範囲内で月2,000分以上のジョブ実行が可能で、1日1回の投稿程度であれば実質ゼロコストで動かせる。
シークレットの扱いはGitHub Actionsの `Secrets` 機能で完結する。リポジトリの設定画面から `FB_ACCESS_TOKEN` といった名前で値を登録しておけば、ワークフローファイル内で `${{ secrets.FB_ACCESS_TOKEN }}` という形で参照でき、ログにも値は出力されない。トークンをコードにハードコードしないという当然の原則を、プラットフォーム側の仕組みで強制できる構成になっている。
# .github/workflows/post.yml の一部
on:
schedule:
- cron: '0 9 * * *' # 毎日9時(UTC)に実行
jobs:
post:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: node index.js
env:
FB_ACCESS_TOKEN: ${{ secrets.FB_ACCESS_TOKEN }}この構成から学べる設計パターン
今回の構成をより広い視点で整理すると、以下のような要素が組み合わさっている。
- マスタートークン1本をSecretに保持し、実行時に短命なアクセストークンを動的取得するトークン設計
- 外部APIへのマルチパートリクエスト(FormDataによる画像ストリーミング)をNode.jsで実装
- ローカルのJSONファイルからランダムにコンテンツを選んでバリエーションを出す仕組み
- GitHub Actionsの `schedule` を定期実行エンジンとして活用し、サーバーレスで完結させる構成
このパターンは、FacebookへのSNS投稿以外にも応用が利く。たとえばSlackへの定期通知・外部APIからデータを取得してスプレッドシートに書き込むバッチ処理・定期的なAPIヘルスチェックといったユースケースで、同じ「GitHub Actions + Node.js + Secrets」の構成がそのまま転用できる。サーバーやコンテナを別途用意せず、リポジトリだけで完結する点が運用コストを下げる。
Graph APIのバージョン管理にも注意が必要だ。今回のコードでは `v21.0` を明示しているが、MetaのAPIはバージョンごとにサポート期限があり、古いバージョンは予告なく非推奨になる。本番運用では定期的なバージョンアップと動作確認をワークフローに組み込んでおくと安心だ。
マスタートークン自体の有効期限が切れた場合や、Meta側のポリシー変更でスコープが変わった場合にジョブが静かに失敗し続けるリスクもある。GitHub Actionsの失敗通知をメールやSlackに転送する設定を加えておくことで、無人運用の死角をカバーできる。定期自動化の信頼性は、実行ロジックと同じくらいエラー検知の設計が問われる。