Threads 250件・Instagram 100件｜APIの投稿上限を自分のアカウントで実測した

ThreadsとInstagramのAPI投稿上限と、自分で設定した1日の枠の比較 アプリ開発
APIの上限はThreads 250件・Instagram 100件。実際に本数を決めているのは自分で設定した3件と1件のほう

SNSへの投稿を自動で回す仕組みを組むとき、1日に何件まで出してよいのかが決まらないと本数を置けません。ドキュメントを読みに行ったら、同じページに100件と50件の両方が書いてあって決着がつかなかったのです。そこで自分のアカウントに直接聞いたところ、上限だけでなく残量まで返ってきました。

上限は、自分のアカウントに聞けば残量つきで返ってくる

ThreadsとInstagramには、どちらにも「いま何件使ったか」を返すエンドポイントが用意されています。アクセストークンさえあれば、curlの1行で確かめられます。

# Threads
curl -s "https://graph.threads.net/v1.0/<THREADS_USER_ID>/threads_publishing_limit\
?fields=quota_usage,config&access_token=<TOKEN>"

# Instagram
curl -s "https://graph.instagram.com/v23.0/<IG_USER_ID>/content_publishing_limit\
?fields=config,quota_usage&access_token=<TOKEN>"

2026年9月17日に自分のアカウントで叩いた結果が、こちらです。

# Threads
{"data":[{"quota_usage":2,"config":{"quota_total":250,"quota_duration":86400}}]}

# Instagram
{"data":[{"config":{"quota_total":100,"quota_duration":86400},"quota_usage":0}]}

Threadsが250件、Instagramが100件で、どちらもquota_durationは86400秒です。quota_usageは、そのときまでに使った件数がそのまま入っています。記事を読んで数字を覚えるより、1回叩いて自分の枠を見たほうが確かだと思います。

公式ドキュメントは、同じページに100件と50件の両方を書いている

Instagramのコンテンツ公開のドキュメントを開くと、「レート制限」という見出しの下にこう書いてあるのです。

Instagram accounts are limited to 100 API-published posts within a 24-hour moving period.

（Instagramアカウントは、24時間の移動する期間内でAPI経由の投稿100件までに制限されます）

ところが、同じページのカルーセルの説明のところには、別の数字が書かれています。

Accounts are limited to 50 published posts within a 24-hour period.

（アカウントは、24時間の期間内で投稿50件までに制限されます）

日本語版のページには「AIで翻訳されたものです」という断りが出るので、最初は訳のぶれを疑いました。英語の原文を取り直して読んでも、100件と50件が同じページに並んだままです。これは訳の問題ではありません。

どちらが正しいのかを、私は決められません。ただ、APIが自分のアカウントについて返してきた値は100で、実際に止められるかどうかを決めているのはそちらのはずです。数字が食い違ったときは、読み比べるより自分の枠を聞くほうが早く終わります。

ドキュメントに載っているcurlは、そのままでは500が返る

Threads側のトラブルシューティングのページには、8つの項目をまとめて取るcurlが例として載っています。返信・削除・位置情報検索の枠まで一度に見られる形です。ところがそのまま実行すると、返ってくるのはこれです。

{"error":{"code":1,"message":"An unknown error occurred"}}

自分のトークンの権限を疑って作り直しかけたのですが、その前に項目を1つずつ試しました。結果を並べると、通るものと通らないものがはっきり分かれます。

fields に指定した項目結果
quota_usage200
config200
reply_quota_usage500
reply_config500
delete_quota_usage500
delete_config500
location_search_quota_usage500
location_search_config500

通るのはquota_usageとconfigの2つだけです。fieldsはまとめて指定するものなので、残り6つのうち1つでも混ぜると、取れるはずの2つまで落ちます。graph.threads.comとgraph.threads.netのどちらでも同じです。

例をそのままコピーして動かないとき、私はまず自分の書き間違いを探してしまいます。今回は書き間違いではなく、例のほうが通らない形でした。1つずつ削って当たりを探すほうが、権限を疑い直すより速いと思っています。

「1日」はカレンダーの1日ではない

quota_durationの86400秒は、24時間ぶんの秒数です。0時に戻る枠ではなく、そのとき時点から24時間さかのぼって数える形になっています。

測ったときのquota_usageは2です。前の日に投稿したのは3件なのですが、いちばん早い1件は24時間を過ぎていて、もう数に入っていません。枠が戻るのは日付が変わったときではなく、その投稿から24時間たったときだと、数字で確かめられたわけです。

0時に戻ると思って組むと、夜遅くに出した本数が翌朝の枠を食っていることになります。1日の本数が上限に近い設計なら、ここは先に知っておいたほうがよさそうです。

実際に効いている上限は、自分で決めたほうの数字だった

私の仕組みは、Threadsが1日3件、Instagramが1日1件で止めてあります。APIの上限と並べると、250件に対して3件、100件に対して1件です。使っているのは、どちらも1%ほどでした。

つまり、本数を決めているのはAPIの制限ではなく、自分が設定ファイルに書いた数字のほうだったわけです。上限に当たって止まったことは一度もありません。調べる前は「上限が何件か」を知りたかったのに、調べ終わって効いてくるのは別の数字だった、という形になりました。

では枠を広げるのかというと、まだ決めていません。出せる本数と、出して読まれる本数は別なので、上限が遠いことは増やしてよい理由になっていないからです。少なくとも、増やすかどうかを考えるための材料が1%という数字で手元に来ました。

自動で投稿を出している人は、自分がいま使っている枠が上限の何パーセントか、数えてみたことはありますか。

あわせて読む

出典

コメント

タイトルとURLをコピーしました