MetaはThreads向けの公式APIを提供しており、投稿の作成・公開、返信の取得、インサイトの参照などをプログラムから実行できます。この記事では、実際に自動投稿を動かすまでに必要な手順と、実装者が必ず踏む落とし穴を順に解説します。
Threads APIでできること・できないこと
| カテゴリ | できること | 必要な権限スコープ |
|---|---|---|
| プロフィール | ユーザーID・ユーザー名・プロフィール画像の取得 | threads_basic |
| 投稿 | テキスト・画像・動画投稿の作成と公開 | threads_content_publish |
| 投稿取得 | 自分の投稿一覧・投稿単体の取得 | threads_basic |
| 返信 | リプライの取得、会話の取得、返信の投稿 | threads_manage_replies |
| 分析 | インプレッション・いいね・返信数などのインサイト取得 | threads_manage_insights |
逆に、できないことも把握しておくと設計を誤りません。
- 他人のアカウントの投稿を自由に取得する（連携したユーザー自身のデータが対象）
- キーワードでThreads全体を検索し、投稿を収集する用途（一般的な利用範囲では想定されていません）
- APIパラメータだけで「指定時刻に自動公開」する（予約は呼び出し側で実装する必要があります）
STEP1｜Meta開発者アプリを作成する
① 開発者アカウントを用意する
developers.facebook.com にログインし、開発者登録を済ませます。
② アプリを作成し、Threads用のユースケースを追加する
アプリ作成時にThreads APIを利用するユースケースを選択します。作成後、アプリIDとアプリシークレットを控えます。
③ リダイレクトURIを登録する
OAuthのコールバックURLを登録します。本番・ローカルの両方を登録しておくと開発が楽になります（例：https://example.com/auth/callback と http://localhost:3000/auth/callback）。
④ 権限スコープを設定する
必要なスコープ（threads_basic ほか）を追加します。開発中は自分のアカウントをテストユーザーとして扱えます。
⑤ アプリレビューを申請する
自分以外のユーザーに使わせる場合はアプリレビューが必要です。スコープごとに用途説明と操作動画の提出を求められます。
STEP2｜OAuthでアクセストークンを取得する
ユーザーに認可画面を表示し、返ってきた認可コードをアクセストークンに交換します。ここで重要なのがトークンの寿命です。
| 種類 | 有効期限の目安 | 扱い |
|---|---|---|
| 短期トークン | 約1時間 | 認可コード交換直後に発行される。すぐ長期トークンへ交換する |
| 長期トークン | 約60日 | 実運用で保持するトークン。期限内にリフレッシュして延長する |
自動投稿システムで最も多い障害が、長期トークンの失効による全店舗一斉停止です。設計時に次の3点を必ず入れてください。
- 1トークンの有効期限をDBに保存し、残り日数を定期ジョブで監視する
- 2残り日数が閾値（例：7日）を切ったら自動リフレッシュを試みる
- 3リフレッシュに失敗したら、該当ユーザーへ再連携を促す通知を出す
STEP3｜投稿を作成・公開する
Threadsの投稿は2ステップです。1回のリクエストでは公開されません。
① コンテナ作成
POST /{threads-user-id}/threads に media_type=TEXT と text を渡すと、コンテナIDが返ります。画像なら media_type=IMAGE と image_url を指定します。
② 公開
POST /{threads-user-id}/threads_publish に creation_id=（コンテナID）を渡すと公開されます。画像・動画の場合は処理完了まで数十秒待ってから公開するのが安全です。
返信を投稿する場合は、コンテナ作成時に reply_to_id として対象の投稿IDを指定します。スレッド形式の連投も同じ要領で、直前の投稿IDを繋いでいくことで実現できます。
STEP4｜予約投稿として動かす
前述の通り、APIに「予約」の概念はありません。実装パターンは主に2つです。
| 方式 | 仕組み | 向いているケース |
|---|---|---|
| ポーリング型 | 1分おきに『公開時刻を過ぎた予約』をDBから探して実行する | 小規模。実装が単純で追いやすい |
| タスクキュー型 | 予約作成時に指定時刻へジョブを登録し、時刻になったらキュー側が呼び出す | 件数が多い場合。時刻精度が高くスケールしやすい |
どちらの方式でも、冪等性は必ず担保してください。ジョブが二重実行されると同じ投稿が2回公開されます。予約レコードにステータス（pending / publishing / published / failed）を持たせ、状態遷移を排他制御するのが基本形です。
レート制限とエラーハンドリング
Threads APIには24時間あたりの上限があります（執筆時点の公式ドキュメントでは、ユーザーあたり投稿250件・返信1,000件が目安）。加えて、Metaのプラットフォーム全体のレート制限も適用されます。
- 429（レート制限）：即リトライせず、指数バックオフで待つ。同一ユーザーの投稿はキューで直列化する
- トークン系エラー（190など）：リトライしても回復しない。再連携フローへ誘導する
- 5xx：一時障害の可能性が高い。数回リトライして駄目なら失敗として記録し通知する
- 投稿は必ずログを残す：リクエスト内容・レスポンス・コンテナIDを保存しておかないと、事後の調査が不可能になります
まとめ
- Threads APIは投稿・返信・インサイトまで、運用自動化に必要な機能はひと通り揃っている
- 投稿は「コンテナ作成 → 公開」の2ステップ。コンテナには寿命があるため公開直前に作る
- 本番運用の最大のリスクはトークン失効。監視・自動リフレッシュ・再連携導線をセットで実装する
- 予約はアプリ側の責務。冪等性とステータス管理を最初から入れておく
予約投稿の運用設計そのものについては Threadsの予約投稿はできる？ 3つの方法と失敗しない運用設計 も合わせてご覧ください。