グラフAPIのレート制限

レート制限では、特定の期間に行うことのできるAPI呼び出しの回数を定義しています。レート制限は各アプリに課されます。

レート制限を大幅に超えるアプリや何度も超えるアプリは、無効になる可能性があります。

Facebook グラフAPIのレート制限が発生する状況は、ごく一部の場合のみです。このドキュメントでは、制限の内容とその処理方法について説明します。

アプリで発生するレート制限は主に、アプリケーションレベルのレート制限とページレベルのレート制限の2つです。

アプリケーションレベルのレート制限

これらの制限は、ページアクセストークン以外のアクセストークンを使用して行った呼び出しに適用されます。

レート制限を超えたアプリからのすべてのAPI呼び出しには制限がかけられ、error code = 4, CodedExceptionで失敗します。過去1時間の利用が制限を下回るようになると、また呼び出しが成功します。制限は1時間の枠内で計算されます。また現在の利用割合はアプリダッシュボードで確認できます。

レート制限ダッシュボード

レート制限ツールから、あとどれくらいでアプリに制限がかかるかという情報が表示されます。アプリに関わるレート制限の情報については、アプリダッシュボードの2つのグラフで確認できます。

  • グラフの1つでは、返されたグラフAPIの応答に影響する現在の利用状況を表示します。これはグラフAPIのリクエストで返されたヘッダー値を視覚化して表したものです。
レート制限に近づいているアプリのグラフ
  • もう1つのグラフでは、レート制限の履歴を表示します。データの表示形式は、過去24時間と過去7日間を選択できます。履歴グラフの任意のサンプルをクリックすると、メソッド別の内訳など、利用状況の詳細を表示できます。呼び出しの分量によっては履歴データが存在しない場合もあるため、すべてのアプリで履歴が利用できるとは限りません。呼び出しの分量が多いアプリは、履歴データが利用できる可能性が高くなります。
過去24時間のレート制限を超えたアプリの履歴グラフ

制限

アプリが実行できる呼び出しの、1時間当たりの総数は、利用者数の200倍です。これは利用者当たりの制限ではないため、全利用者の呼び出し総数がアプリの制限を超えない限り、利用者1人が1時間当たり200以上の呼び出しを実行することもできます。例えば、アプリ利用者が100人いる場合は、1時間当たり2万件の呼び出しが可能になります。そのうち19,000回の呼び出しが、最も熱心な利用者の上位10名で占められている可能性もあります。

アプリにレート制限がかかると、特定の利用者にではなく、アプリへのすべての呼び出しが制限されます。

アプリの利用者の数は、1日のアクティブユーザーの数にその日の新しいログイン数を足したものとして計算されます。1日の利用状況の伸びが良くない時期がある場合は、週間または月間のアクティブユーザー数を使用してアプリの利用者数を計算します。実際のアプリ数とは無関係に、1日のエンゲージメントが低いアプリより、1日のエンゲージメントが高いアプリの方がレート制限も高くなります。

警告:

  • すべてのAPI呼び出しがレート制限の対象になるわけではありません。そのため、実際に行った呼び出しの数とレート制限に表示される数が一致しない場合があります。
  • 消費したCPU時間と総時間に基づいた制限も発生します。エンドポイントで多数の処理を必要とする場合、呼び出しの分量が制限以下であっても、アプリがこれらの制限に達する可能性があります。特別なエンドポイントを除き、アプリがCPU時間と合計時間の制限に達することはほとんどありません。利用可能な場合、CPU時間と合計時間が長時間に及ぶエンドポイントの情報を、履歴グラフで確認できます。
  • Ads Insights APIMarketing APIでは、異なるレート制限を使用します。Marketing APIについて詳しくは、Marketing APIのレート制限に関するドキュメント(https://developers.facebook.com/docs/marketing-api/api-rate-limiting)をご覧ください。

推奨される対処方法

レート制限を避けるには:

  • 2つの時間間隔にクエリを均一に分散させることによって、トラフィックスパイクを避ける。
  • フィルターを使ってデータ応答のサイズを制限し、重複するデータをリクエストする呼び出しを回避する。
  • レート制限のヘッダーを使用して、呼び出し回数を動的に調整する。

レート制限のヘッダー

呼び出しに対するグラフAPIへの反応は、すべてX-App-Usage HTTP ヘッダーを含みます。このヘッダーにはアプリの現在の利用率が含まれます。このパーセンテージは、レート制限グラフに表示される使用率と同じです。制限にかからないようにするには、この数字を使用して呼び出しのロードを動的に調整します。

レート制限のヘッダーはJSON形式の文字列であり、次のような形式になります。

{
  "call_count"    : x, 
  "total_time"    : y, 
  "total_cputime" : z
}

x、y、zの値は、各指標が使用されているパーセンテージ全体を表す数です。これらの指標のいずれかが100を超えると、アプリがレート制限にかかります。

ページレベルのレート制限

これらの制限は、ページアクセストークンを使用して行った呼び出しに適用されます。制限に達すると、エラーコード32を受け取ります。

ページレベルのレート制限の詳細については、こちらのブログ投稿(https://developers.facebook.com/blog/post/2016/06/16/page-level-rate-limits/)をご覧ください。

レート制限ダッシュボード

アプリがアクセストークンを使用して呼び出しを行ったそれぞれのページについて、レート制限チャートを表示できます。

制限

レート制限は、アプリではなくそれぞれのページが対象となります。レート制限ツールを使用すると、ページのアクセストークンを使用するアプリの数と、ページがどれくらい制限に近づいているかに関する情報を確認できます。いずれかのサンプルをクリックすると、利用タイプの詳細を確認できます。

1日あたりのページを使用した利用者の数は、直近24時間以内にページで操作を行った利用者のユニーク数になります。ページ操作は、ページまたはページコンテンツのクリックが対象になります。

現在の24時間の枠のレート制限は、直近24時間の利用者数を使用して計算されます。

24時間あたりに、ページに代わって1日の利用者ごとに合計で4,800件の呼び出しを実行できます。例えば、1日の利用者が100人のページであれば、ページに代わって24時間の間に48万件の呼び出しを実行できます。この24時間の枠はスライド制であり、数分ごとに更新されます。呼び出し制限はページあたりの制限であるため、1つのアプリが40万件の呼び出しを行った場合、それ以外のアプリが行える呼び出しは8万件になります。ページがレート制限にかかると、そのページのアクセストークンを使用して行うアプリからの呼び出しのみが制限されます。つまり、アプリは引き続き別の呼び出しを行うことができます。

ページへの呼び出し数は、1日あたりのページアクセストークンを使用して推定呼び出し数として算出されます。1日あたりのページの呼び出し数が多いほど、より正確なレート制限が得られます。呼び出し数が極めて少ないページでは、レート制限に問題が生じる場合があります。

警告:

  • すべてのAPI呼び出しがレート制限の対象になるわけではありません。そのため、実際に行った呼び出しの数とレート制限に表示される数が一致しない場合があります。
  • 消費したCPU時間と総時間に基づいた制限も発生します。詳しくは、ダッシュボードのレート制限ツールのグラフをクリックしてください。
  • Ads Insights APIMarketing APIでは、異なるレート制限を使用します。Marketing APIについて詳しくは、「Marketing API Rate Limiting (Marketing APIのレート制限)」に関するドキュメントをご覧ください。

推奨される対処方法

ページが制限にかかると、後続の呼び出しに対して呼び出し元にerror code = 32, CodedExceptionというエラーコードが表示されます。そのページにリクエストを受け入れられるようになるまで、最長1時間ほどかかる場合があります。

レート制限を避けるには:

  • 2つの時間間隔にクエリを均一に分散させることによって、トラフィックスパイクを避ける。
  • フィルターを使ってデータ応答のサイズを制限し、重複するデータをリクエストする呼び出しを回避する。
  • レート制限のヘッダーを使用して、呼び出し回数を動的に調整する。

レート制限のヘッダー

レート制限の対象となり得るほどの数の呼び出しがページに代わって行われると、X-Page-Usage HTTPヘッダーが返されます。このヘッダーにはページの現在の利用率が含まれます。ページのアクセストークンを使用して呼び出しを行うと、そのページのみのX-Page-Usage値を取得できます。このパーセンテージは、そのページのレート制限グラフに表示される使用率と同じ数字になります。制限にかからないようにするには、この数字を使用して呼び出しのロードを動的に調整します。

レート制限のヘッダーはJSON形式の文字列であり、次のような形式になります。

{
  "call_count"    : x, 
  "total_time"    : y, 
  "total_cputime" : z
}

x、y、zの値は、各指標が使用されているパーセンテージ全体を表す数です。これらの指標のいずれかが100を超えると、アプリがレート制限にかかります。

アカウントレベルのレート制限

これらの制限は、ユーザーアクセストークンを使用して行った呼び出しに適用されます。この制限に達すると、アプリにエラーコード17が表示されます。このエラーは、特定のユーザーアカウントからAPIへの呼び出し数が多すぎる場合に発生します。

注:

これには、自分のアプリだけでなく他の多くのアプリが行ったユーザー呼び出しも含まれます。

レートが制限されていると、利用者からのAPI呼び出しが調整されます。

レート制限を避けるには:

これを回避するための操作はありません。利用者(場合によっては他のアプリ)からの呼び出し数が多すぎるためにレートが制限されます。 ただし、特定のアプリの利用者間でこの現象が多発する場合は、そのアプリからのAPI呼び出しが原因であると考えられます。その場合は、呼び出しを減らすか、より均等になるように分散させます。

プロフィール写真URL

グラフAPIから返されたプロフィール写真URLには、さまざまなレート制限がある場合があります。これらの制限に到達すると、リクエストはHTTP応答コード429(多すぎるリクエスト)を返します。常にレート制限に到達する場合:

  • 複数の時間間隔にわたって、クエリを均等に分散します。
  • サーバー側ではなくクライアント側に、写真を読み込みます。
  • 写真をサーバー側に読み込む必要がある場合、写真をキャッシュします。

よくある質問

API呼び出しの数え方

個別のHTTPS APIリクエストではなく、すべての呼び出しがレート制限の対象として計上されます。例えば、1件のAPI呼び出しで複数のIDを指定する場合、1件のHTTPS APIリクエストであっても、それぞれのIDが独自のAPI呼び出しとして計上されます。

この考え方については、次の例をご覧ください。

リクエストの例 API呼び出しの数

GET https://graph.facebook.com/photos?id=4
GET https://graph.facebook.com/photos?id=5
GET https://graph.facebook.com/photos?id=6

3

GET https://graph.facebook.com/photos?id=4,5,6

3

IDを使用して、複数のオブジェクトを移動する場合は、API応答のパフォーマンスを向上できる2番目の例を強くおすすめします。ただし、レート制限の観点でいうと、これは呼び出しの数の問題を改善するものではありません。

Batch APIを使って、リクエストのバッチ処理を行うこともできます。ただし、各サブリクエストは個別のAPI呼び出しとなり、複数のIDを指定する際には、さらにそれが複数のAPI呼び出しとして計上されます。

アプリやページがレート制限の対象となる場合、レート制限エラーが発生したAPI呼び出しも、レート制限の対象として計上されます。


どのようなエラーがアプリに表示されますか
調整のタイプ 最小しきい値 エラーコード

アプリケーションレベルの調整

利用者1人あたり200件の呼び出し/1時間

4

アカウントレベルの調整

該当なし

17

ページレベルの調整

利用者1人あたり4,800件の呼び出し/24時間

32

カスタムレベルの調整

該当なし

613


エラーコード613が表示されました。どうすればよいですか。

エラー応答にerror_subcode 1996が含まれる場合、Facebookでは、アプリのAPIリクエストボリュームに一貫性のない動作があることを確認しています。最近、APIリクエストの数に影響を及ぼす変更を実施した場合、このエラーが発生する場合があります。

サブコードが表示されない場合、アプリはカスタムレート制限を超過しています。この問題の解決方法については、パートナーマネージャーにお問い合わせください。


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

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