レート制限

レート制限とは、一定期間内にアプリやユーザーが実行できるAPI呼び出しの数です。この制限を超えるか、CPU時間または合計時間の制限を超えると、アプリやユーザーがスロットリングされることがあります。スロットリングされたユーザーやアプリの発行するAPIリクエストは失敗します。

すべてのAPIリクエストはレート制限に従います。グラフAPIとInstagram基本表示APIのリクエストはプラットフォームレート制限に従い、マーケティングAPIとInstagramグラフAPIのリクエストはビジネスユースケース(BUC)レート制限に従います。

ページAPIリクエストは、リクエストで使用されるトークンに応じて、プラットフォームレート制限またはBUCレート制限に従います。アプリアクセストークンまたはユーザーアクセストークンを使用したリクエストは、プラットフォームレート制限に従います。システムユーザートークンまたはページアクセストークンを使用したリクエストは、ビジネスユースケースレート制限に従います。

エンドポイントに対して相当数の呼び出しが行われると、ほとんどのAPI応答に含まれるヘッダーに、リアルタイムのレート制限使用統計が書き込まれます。プラットフォームレート制限の使用統計は、アプリダッシュボードにも表示されます。呼び出しがレート制限に達すると、それ以降アプリが発行するリクエストはすべて失敗し、呼び出しカウントが制限を下回るのに十分な時間が経過するまで、APIはエラーコードを返します。

プラットフォームレート制限とビジネスユースケースレート制限の両方がリクエストに適用可能な場合は、BUCレート制限が適用されます。

プラットフォームレート制限

プラットフォームレート制限は、リクエストで使用されるトークンのタイプに応じて、個々のアプリまたはユーザーレベルでトラッキングされます。

アプリ

アプリアクセストークンを使用したグラフAPIリクエストは、そのアプリのレート制限に対してカウントされます。アプリの呼び出しカウントは、1時間のローリング枠で可能な呼び出しの数です。これは次のように計算されます。

ユーザー数は、アプリのデイリーアクティブユーザー数(重複を除く)に基づいて算出します。1日の利用量が少ない日がある場合(週末はアプリの利用が多いが平日は少ない場合など)は、週間および月間のアクティブユーザー数を使用してアプリのユーザー数を算出します。アプリの実際のインストール数にかかわらず、1日あたりの利用が少ないアプリよりも、1日あたりの利用が多いアプリの方が、レート制限が高くなります。

これはユーザーあたりの制限ではなく、アプリからの呼び出しに対する制限であることに注意してください。アプリからの呼び出しの合計数がアプリの上限を超えない限り、個々のユーザーは1時間あたり200件を超える呼び出しをアプリから実行できます。例えば、アプリのユーザーが100人いる場合、アプリは1時間あたり20,000件の呼び出しを実行できます。ただし、その呼び出しのうち19,000件は、最も利用頻度が高い10人のユーザーによるものかもしれません。

ユーザー

ユーザーアクセストークンを使用したグラフAPIリクエストは、そのユーザーの呼び出しカウントに対してカウントされます。ユーザーの呼び出しカウントは、ユーザーが1時間のローリング枠で可能な呼び出しの数です。プライバシーへの配慮から、Facebookはユーザーの実際の呼び出しカウントの数値は公開していません。

ユーザーの呼び出しカウントは複数のアプリにまたがる可能性があることに注意してください。例えば、あるユーザーがApp1からX件、App2からY件の呼び出しをするとします。X+Yがユーザーの呼び出しカウントを超えると、そのユーザーはレート制限を受けます。レート制限が適用されても、アプリの動作に問題があるとは限りません。ユーザーが複数のアプリを使用している場合もあれば、APIを誤用している場合もあります。

ヘッダー

アプリから相当数のリクエストを受信するエンドポイントは、X-App-Usage HTTPヘッダーまたはX-Ad-Account-Usage HTTPヘッダー(v3.3以前の広告API呼び出しの場合)を応答に含めます。ヘッダーには、現在のアプリレート制限の使用状況を記述するJSON形式の文字列が挿入されます。

ヘッダーの内容

X-Ad-Account-Usageヘッダーの内容

合計CPU時間

リクエストの処理にかかったCPU時間。total_cputimeが100に達すると、呼び出しがスロットリングされることがあります。

合計時間

リクエストの処理にかかった時間の長さ。total_timeが100に達すると、呼び出しがスロットリングされることがあります。

X-App-Usageヘッダーの値の例

x-app-usage: {
    "call_count": 28,         //Percentage of calls made 
    "total_time": 25,         //Percentage of total time
    "total_cputime": 25       //Percentage of total CPU time
}

X-Ad-Account-Usageヘッダーの値の例

x-ad-account-usage: {
    "acc_id_util_pct": 9.67,   //Percentage of calls made for this ad account.
    "reset_time_duration": 100,   //Time duration (in seconds) it takes to reset the current rate limit score.
    "ads_api_access_tier": 'standard_access'   //Tiers allows your app to access the Marketing API. standard_access enables lower rate limiting.
}

ダッシュボード

アプリダッシュボードには、レート制限を受けたアプリユーザーの数、アプリの現在のアプリレート制限の使用状況、過去7日間の平均アクティビティが表示されます。アプリレート制限カードで[詳細を表示]をクリックし、グラフ上の任意の場所にマウスを重ねると、特定の時点における使用状況の詳細を表示できます。使用状況は呼び出しの量に左右されるため、このグラフに7日間すべてのデータが表示されないことがあります。呼び出しの量が多いアプリほど、より多くの日数のデータが表示されます。

エラーコード

アプリまたはユーザーがレート制限に達すると、そのアプリまたはユーザーが発行するリクエストは失敗し、APIは応答でエラーコードを返します。

スロットリングのエラーコード

応答の例

{
  "error": {
    "message": "(#32) Page request limit reached",
    "type": "OAuthException",
    "code": 32,
    "fbtrace_id": "Fz54k3GZrio"
  }
}

Facebook安定性スロットリングコード

ベストプラクティス

• 制限に達したときは、API呼び出しを停止します。呼び出しを停止しないと、呼び出しカウントが増え続け、呼び出しが再び成功するようになるまでにより多くの時間がかかるようになります。
• トラフィックの急増を回避するため、クエリを均等に分散します。
• フィルターを使用してデータ応答のサイズを制限し、重複データをリクエストする呼び出しを回避します。
• X-App-Usage HTTPヘッダーをチェックして、アプリがどの程度制限に近づいているか、すでに制限に達している場合はいつ呼び出しを再開できるかを確認します。
• ユーザーがスロットリングされている場合は、原因がアプリでないことを確認します。ユーザーの呼び出しを減らすか、時間を空けてユーザーの呼び出しをさらに均等に分散します。

ビジネスユースケースのレート制限

すべてのマーケティングAPIリクエストと、システムユーザートークンまたはページアクセストークンを使用したページAPIリクエストは、クエリするエンドポイントに応じて、ビジネスユースケース(BUC)レート制限が適用されます。

マーケティングAPIの場合、同じビジネスユースケース全体の広告アカウントにレート制限が適用されます。例えば、広告管理のビジネスユースケースの場合、すべてのエンドポイントが、同じ広告アカウント内の合計クォータを共有します。特定のエンドポイントがAPIリクエストを多発してスロットリングを起こした場合、同じビジネスユースケースが設定された他のエンドポイントでもレート制限エラーが発生します。クォータはアプリのマーケティングAPIアクセスレベルによって異なります。スタンダードアクセスのマーケティングAPIレベルは、開発アクセスのマーケティングAPIレベルよりも多くのクォータを持ちます。デフォルトでは、新規のアプリは開発レベルになっています。より多くのレート制限クォータを得るためにアップグレードする必要がある場合は、アプリレビューで広告管理スタンダードアクセスのアドバンスアクセスにアップグレードしてください。

広告インサイト

アプリによる広告インサイトAPIへのリクエストは、呼び出しカウント、合計CPU時間、合計時間などのアプリのレート制限指標にカウントされます。アプリの呼び出しカウントは、1時間のローリング枠で行うことのできる呼び出しの数です。これは次のように計算されます。

広告管理スタンダードアクセス機能へのスタンダードアクセスを持つアプリの場合は、次のようになります。

広告管理スタンダードアクセス機能へのアドバンスアクセスを持つアプリの場合は、次のようになります。

アクティブ広告数は、各広告アカウントで現在掲載中の広告の数です。ユーザーエラー数は、APIの呼び出し時に受信したエラーの数です。レート制限を引き上げるには、広告管理スタンダードアクセス機能を申請することができます。

レート制限には、1時間のローリング枠の合計CPU時間と合計ウォール時間の制限もあります。詳細は、HTTP X-Business-Use-Case ヘッダー total_cputimeとtotal_timeをチェックしてください。

レート制限のエラーを受け取る場合は、X-Business-Use-Caseヘッダーのestimated_time_to_regain_accessを参照して、推定ブロック時間を確認してください。

広告管理

アプリから広告管理APIへのリクエストは、呼び出しカウント、合計CPU時間、合計時間などのアプリのレート制限指標にカウントされます。アプリの呼び出しカウントは、1時間のローリング枠で行うことのできる呼び出しの数です。これは次のように計算されます。

広告管理スタンダードアクセス機能へのスタンダードアクセスを持つアプリの場合は、次のようになります。

広告管理スタンダードアクセス機能へのアドバンスアクセスを持つアプリの場合は、次のようになります。

アクティブ広告数は、各広告アカウントの広告の数です。

レート制限には、1時間のローリング枠の合計CPU時間と合計ウォール時間の制限もあります。詳細は、HTTP X-Business-Use-Case ヘッダー total_cputimeとtotal_timeをチェックしてください。

レート制限のエラーを受け取る場合は、X-Business-Use-Caseヘッダーのestimated_time_to_regain_accessを参照して、推定ブロック時間を確認してください。

カタログ

カタログバッチ

アプリによるリクエストは、アプリが、カタログIDあたり1時間のローリング枠で実行できる呼び出しカウント、合計CPU時間、合計時間などのレート制限指標にカウントされます。それは、以下のように計算されます。

ユニークユーザーは、過去28日間における、インテントを持った(すべてのカタログ上の)ビジネスのユニークユーザーの数です。ユーザーに表示されるカタログ商品が多いほど、より多くの呼び出しクォータが割り当てられます。

カタログ管理

アプリが行うリクエストはカウントされ、各カタログIDの1時間のローリング枠内でアプリが呼び出せる数が減っていきます。次のように計算されます。

ユニークユーザーは、過去28日間における、インテントを持った(すべてのカタログ上の)ビジネスのユニークユーザーの数です。ユーザーに表示されるカタログ商品が多いほど、より多くの呼び出しクォータが割り当てられます。

この数式がさまざまなカタログのエンドポイントに適用されます。

現在のレート使用状況を取得する方法については、ヘッダーをご覧ください。

レート制限には、1時間のローリング枠の合計CPU時間と合計ウォール時間の制限もあります。詳細は、HTTP X-Business-Use-Case ヘッダー total_cputimeとtotal_timeをチェックしてください。

レート制限のエラーを受け取る場合は、X-Business-Use-Caseヘッダーのestimated_time_to_regain_accessを参照して、推定ブロック時間を確認してください。

カスタムオーディエンス

アプリからカスタムオーディエンスAPIへのリクエストは、呼び出しカウント、合計CPU時間、合計時間などのアプリのレート制限指標にカウントされます。アプリの呼び出しカウントは、1時間のローリング枠で実行できる呼び出しの数です。以下のように計算されますが、700,000を超えることはありません。

広告管理スタンダードアクセス機能へのスタンダードアクセスを持つアプリの場合は、次のようになります。

広告管理スタンダードアクセス機能へのアドバンスアクセスを持つアプリの場合は、次のようになります。

アクティブカスタムオーディエンスの数は、各広告アカウントのアクティブなカスタムオーディエンスの数です。

レート制限には、1時間のローリング枠の合計CPU時間と合計ウォール時間の制限もあります。詳細は、HTTP X-Business-Use-Case ヘッダー total_cputimeとtotal_timeをチェックしてください。

レート制限のエラーを受け取る場合は、X-Business-Use-Caseヘッダーのestimated_time_to_regain_accessを参照して、推定ブロック時間を確認してください。

InstagramグラフAPI

InstagramグラフAPIの呼び出しは、呼び出し元アプリの呼び出しカウントに対してカウントされます。アプリの呼び出しカウントは、アプリとアプリユーザーの組み合わせごとに一意で、アプリが24時間のローリング枠で行った呼び出しの数です。これは次のように計算されます。

インプレッション数は、アプリユーザーのInstagramアカウントのコンテンツが過去24時間以内にユーザーの画面に読み込まれた回数です。

注

• Instagram基本表示APIにはプラットフォームレート制限が適用されます。
• ビジネスディスカバリーとハッシュタグ検索は、プラットフォームレート制限に従います。

LeadGen

アプリからリード獲得APIに対して行われるリクエストは、アプリの呼び出しカウントに対してカウントされます。アプリの呼び出しカウントは、24時間のローリング枠で可能な呼び出しの数です。これは次のように計算されます。

獲得リード数は、過去90日間にこの広告アカウントでページごとに獲得されたリードの数です。

Messengerプラットフォーム

ページ

ページのレート制限は、使用されるトークンのタイプに応じて、プラットフォームレート制限またはBUCレート制限のロジックに従います。ページアクセストークンまたはシステムユーザーアクセストークンを使用して行われるすべてのページAPI呼び出しのレート制限は、下記の方法で計算されます。アプリアクセストークンまたはユーザーアクセストークンを使用して行われるすべての呼び出しは、アプリレート制限またはユーザーレート制限に従います。

ページアクセストークンまたはシステムユーザーアクセストークンを使用してアプリからページAPIに対して行われるリクエストは、アプリの呼び出しカウントに対してカウントされます。アプリの呼び出しカウントは、24時間のローリング枠で可能な呼び出しの数です。これは次のように計算されます。

利用ユーザー数は、そのページを利用したユーザーの24時間あたりの数です。

ユーザーアクセストークンまたはアプリアクセストークンを使用してアプリからページAPIに対して行われるリクエストは、プラットフォームレート制限のロジックに従います。

ページの公開コンテンツへのアクセス機能を使用する際にレート制限の問題を回避するため、システムユーザーアクセストークンを使用することをおすすめします。

Spark ARコマースエフェクトの管理

アプリがコマースエンドポイントに対して実行するリクエストは、アプリの呼び出しカウントとしてカウントされます。アプリの呼び出しカウントは、1時間のローリング枠で可能な呼び出しの数です。これは次のように計算されます。

カタログ数は、アプリで管理するすべてのコマースアカウントにおけるカタログの合計数です。

WhatsApp Business管理API

ヘッダー

BUCロジックのレート制限を受けるアプリによるすべてのAPI応答には、X-Business-Use-Case-Usage HTTPヘッダー(v3.3以前の広告API呼び出しの場合)と、現在のアプリレート制限の使用状況を記述するJSON形式の文字列が含まれます。このヘッダーは、1つの呼び出しで最大32個のオブジェクトを返すことができます。

X-Business-Use-Case-Usageヘッダーの内容

合計CPU時間

リクエストの処理にかかったCPU時間。total_cputimeが100に達すると、呼び出しがスロットリングされることがあります。

合計時間

リクエストの処理にかかった時間の長さ。total_timeが100に達すると、呼び出しがスロットリングされることがあります。

広告APIアクセスレベル

ads_insightsおよびads_managementタイプにのみ使用します。レベルにより、アプリのマーケティングAPIへのアクセスが許可されます。デフォルトでは、アプリはdevelopment_accessレベルです。Standard_accessでは低めのレート制限が有効になります。広告管理スタンダードアクセス機能への「アドバンスアクセス」を申請すれば、高レート制限を取得し、スタンダードレベルを維持することができます。

X-Business-Use-Case-Usageヘッダーの値の例

x-business-use-case-usage: {
    "{business-object-id}": [
        {
            "type": "{rate-limit-type}",           //Type of BUC rate limit logic being applied.
            "call_count": 100,                     //Percentage of calls made. 
            "total_cputime": 25,                   //Percentage of the total CPU time that has been used.
            "total_time": 25,                      //Percentage of the total time that has been used.   
            "estimated_time_to_regain_access": 19,  //Time in minutes to regain access.
            "ads_api_access_tier": "standard_access"  //Tiers allows your app to access the Marketing API. standard_access enables lower rate limiting.
        }
    ],      
    "66782684": [
        {
            "type": "ads_management",
            "call_count": 95,
            "total_cputime": 20,
            "total_time": 20,
            "estimated_time_to_regain_access": 0,
            "ads_api_access_tier": "development_access" 
        }
    ],
    "10153848260347724": [
        {
            "type": "ads_insights",
            "call_count": 97,
            "total_cputime": 23,
            "total_time": 23,
            "estimated_time_to_regain_access": 0,
            "ads_api_access_tier": "development_access"
        }
    ],
    "10153848260347724": [
        {
            "type": "pages",
            "call_count": 97,
            "total_cputime": 23,
            "total_time": 23,
            "estimated_time_to_regain_access": 0
        }
    ],
...
}

エラーコード

アプリがビジネスユースケースレート制限に達すると、それ以降アプリが発行するリクエストは失敗し、APIは応答でエラーコードを返します。

エラーコードメッセージの例

{   
"error": {      
    "message": "(#80001) There have been too many calls to this Page account. Wait a bit and try again. For more info, please refer to https://developers.facebook.com/docs/graph-api/overview/rate-limiting.",      
    "type": "OAuthException",      
    "code": 80001,      
    "fbtrace_id": "AmFGcW_3hwDB7qFbl_QdebZ"   
    }
}

ベストプラクティス

• 制限に達したときは、API呼び出しを停止します。呼び出しを停止しないと、呼び出しカウントが増え続け、呼び出しが再び成功するようになるまでにより多くの時間がかかるようになります。
• X-Business-Use-Case-Usage HTTPヘッダーをチェックして、広告アカウントがどの程度制限に近づいているか、いつ呼び出しを再開できるかを確認します。
• エラーコードとAPIエンドポイントを確認し、スロットリングタイプを確かめます。
• 別の広告アカウントに切り替え、しばらくしてからこのアカウントに戻ってきます。
• 既存の広告を変更するよりも、新しい広告を作成することをおすすめします。
• 送信トラフィックの急増を回避するため、2つの時間間隔にクエリを均一に分散させます。
• フィルターを使用してデータ応答のサイズを制限し、重複データをリクエストする呼び出しを回避します。

よくある質問

API呼び出しはどのようにカウントされますか？

個々のAPIリクエストではなく、すべての呼び出しがレート制限の対象としてカウントされます。例えば、複数のIDを指定して単一のAPIリクエストを実行できますが、IDごとに1つのAPI呼び出しとしてカウントされます。

このカウント方法の例を次の表に示します。

可能であれば、1つのAPIリクエストに複数のIDを指定することを強くおすすめします。それにより、API応答のパフォーマンスが向上します。

スクレイパーを作成しています。どのような点に注意すべきでしょうか？

データをスクレイピングするサービスを開発している場合は、スクレイピングに関する規約をご覧ください。