グラフAPIのレート制限

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

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

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

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

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

アプリのレート制限のアクティビティに関するグラフは、アプリのアプリダッシュボードで確認します。

制限

レート制限は各アプリに課されます。レート制限ツールから、あとどれくらいでアプリに制限がかかるかという情報が表示されます。いずれかのサンプルをクリックすると、利用タイプの詳細を確認できます。

アプリでは、1時間に利用者1人あたり合計200件の呼び出しが可能です。 たとえば、アプリ利用者が100人いる場合は、2万件の呼び出しが可能になります。 これは利用者あたりの制限ではないため、1人の利用者が19,000件の呼び出しを行った場合、それ以外の利用者が行える呼び出しは1,000件になります。この制限は直近の1時間に行われた呼び出しの数に基づいて計算されます。

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

アプリの利用者の数は、1日のアクティブユーザーの平均数にその日の新しいログイン数を推定値として足したものとして計算されます。アプリの利用者数が多いほど、より正確なレート制限が得られます。利用者数が極めて少ないアプリでは、レート制限に問題が生じる場合があります。

警告:

  • すべてのAPI呼び出しがレート制限の対象になるわけではありません。そのため、実際に行った呼び出しの数とレート制限に表示される数が一致しない場合があります。
  • 消費したCPU時間と総時間に基づいた制限も発生します。これらの制限に達することは難しく、非常にまれなケースになります。この情報は、各サンプルの詳細ペインに表示されます。詳しくは、ダッシュボードのレート制限ツールのグラフをクリックしてください。
  • 広告インサイトAPIマーケティングAPIでは、異なるレート制限を使用します。マーケティングAPIについて詳しくは、マーケティングAPIのレート制限に関するドキュメント(https://developers.facebook.com/docs/marketing-api/api-rate-limiting)をご覧ください。

推奨される対処方法

レート制限では、特定の期間に行うことのできるAPI呼び出しの回数を定義しています。レート制限を超えると、そのアプリからのすべてのAPI呼び出しが制限され、少しの間、呼び出しが行えなくなる場合があります。アプリが制限にかかると、後続の呼び出しに対して呼び出し元にerror code = 4, CodedExceptionというエラーコードが表示されます。 リクエストを受け入れられるようになるまで、最長1時間ほどかかる場合があります。

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

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

レート制限のヘッダー

アプリがレート制限の対象となり得る程の数の呼び出しを行っている場合は、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時間と総時間に基づいた制限も発生します。詳しくは、ダッシュボードのレート制限ツールのグラフをクリックしてください。
  • 広告インサイトAPIマーケティングAPIでは、異なるレート制限を使用します。マーケティングAPIについて詳しくは、「マーケティングAPI Rate Limiting (マーケティング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呼び出しが原因であると考えられます。その場合は、呼び出しを減らすか、より均等になるように分散させます。

よくある質問

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が表示されました。どうすればよいですか。

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

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

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