毎日、数千人もの開発者がTwitter APIに対してリクエストを実行しています。こうした膨大な量のリクエストを管理しやすくするために、実行できるリクエストの数には制限が設けられています。こうした制限を設けることで、開発者コミュニティが安心して利用できる、信頼性と拡張性に優れたAPIの提供を実現しています。 

実行できるリクエストの最大数は一定の期間または時間間隔を1つの単位として設定されています。最も一般的なリクエスト制限間隔は15分です。エンドポイントのレート制限が15分あたり900リクエストの場合は、15分の間に900件までリクエストを実行できます。 

適用されるレート制限は使用している認証方法によって異なります。たとえば、OAuth 1.0aユーザーコンテキストを使用している場合、ユーザーのアクセストークン1セットにつき、1期間あたり1つの制限が適用されます。一方、OAuth 2.0ベアラートークンを使用している場合は、アプリによって実行されるリクエストに対して、1期間ごとに異なる制限が適用されます。これらの制限を超過するとエラーが返されます。ここからは、これらの制限の詳細と、レート制限を受けないようにするためのヒントを紹介していきます。 
 

目次

• Twitter API v2のレート制限
• レート制限と認証方法
• HTTPヘッダーと応答コード
• レート制限を受けた場合の復旧方法
• レート制限を受けないようにするためのヒント

Twitter API v2のレート制限

以下の表はTwitter API v2のレート制限をまとめたものです。これらのレート制限は、各エンドポイントのAPIリファレンスページにも記載されており、開発者ポータルの製品セクションにも表示されます。
 

**次のPOSTエンドポイントとDELETEエンドポイントには、レート制限に加えて操作制限もあります。
 

レート制限と認証方法

開発者アプリとユーザーアクセストークン両方のレベルでレート制限が設定されています。

• OAuth 2.0ベアラートークン：アプリのレート制限
  この認証方法とレート制限では、開発者アプリに代わり、エンドポイントに対して特定数のリクエストを実行できます。この認証方法を使用する場合は、ベアラートークンを使用して実行するリクエストの数によってレート制限が決定されます。
  
  エンドポイントでアプリのレート制限が15分あたり450リクエストの場合、ベアラートークンを使用するとアプリに代わって15分間に450回リクエストを実行できます。
  
  この制限はユーザーのレート制限とは完全に切り離してカウントされます。
  
  
• OAuth 1.0aユーザーコンテキスト：ユーザーのレート制限
  この認証方法とレート制限では、リクエストを認証する際に使用したユーザーアクセストークンによって特定されたTwitterに代わって、一定数のリクエストをエンドポイントに対して実行できます。たとえば、ツイートからプライベートメトリックを取得する場合は、対象ユーザーに関連付けられているユーザーアクセストークンで認証する必要があります。このトークンは3レッグ認証OAuthフローを使用して生成できます。 
  
  10人のユーザーが開発者アプリを許可しており、リクエストの実行先となるエンドポイントでレート制限が15分あたり900リクエストの場合、ユーザー1人につき15分で最大900回リクエストを実行でき、リクエストの合計件数は9,000件となります。
  
  この制限はアプリのレート制限とは完全に切り離してカウントされます。 
   

HTTPヘッダーと応答コード

アプリケーションが利用された方法でアプリケーションの現在のレート制限を確認するには、HTTPヘッダーを使用します。

HTTPヘッダーの内容は状況に応じて変化します。アプリケーション専用の認証を使用する場合、アプリケーションのコンテキストに合わせたレート制限がHTTPヘッダーに記載されます。ユーザーベースの認証を使用する場合、そのユーザーのコンテキストに合わせたレート制限がHTTPヘッダーに記載されます。

• x-rate-limit-limit:そのエンドポイントのレート制限の上限
• x-rate-limit-remaining:15分の間に実行できる残りリクエスト件数
• x-rate-limit-reset:レート制限がリセットされるまでの残り時間（単位はUTCのエポック秒）
   

特定のTwitter APIエンドポイントでアプリケーションがレート制限を超過した場合、APIから応答コードHTTP 429 “Too Many Requests”が返され、応答本文で次のエラーが返されます。

{ "errors": [ { "code":88, "message":"Rate limit exceeded" } ] } 

レート制限にかかった場合の復旧方法

これらのレート制限を超過すると、429 'Too many requests'エラーがエンドポイントから返されます。  これから説明するとおり、レート制限のエラーが発生した場合は、制限がリセットされるタイミングが記載されたHTTPヘッダーを確認し、制限がリセットされるまでリクエストを一時停止することをおすすめします。  

「Too many requests」かレート制限のエラーが発生した場合は、リクエストを実行する頻度を下げる必要があります。レート制限のエラーが発生した場合は、 x-rate-limit-reset: HTTPヘッダーを確認することで、レート制限がリセットされるタイミングがわかります。 

よく見られるもう1つのパターンがエクスポネンシャルバックオフです。エクスポネンシャルバックオフでは、あるリクエストから次のリクエストまでの時間が最初は短く（数秒など）、再試行のたびに時間が倍になっていきます。リクエストが成功するか、あるリクエストから次のリクエストまでの合理的な最長時間（たとえば、数分）に達するまでこれが続けられます。  

クライアント側で既存のレート制限を認識させ、現在超過している時間枠が過ぎるまでリクエストを一時停止できるようにしておくことをおすすめします。15分の制限が過ぎたら、そこから1～2分待ってから再試行するのが良いでしょう。

リクエスト数に関するこれらの制限を超過した場合、スタンダードベーシックレベルのアクセスによって、最近の検索とフィルタリングされたストリームエンドポイントから1か月あたり50万ツイートが提供されます。ツイート数に関する月間上限を超過した場合、アプリに通知が出るようにして、1か月のなかでどの日が登録日かわかるようにし、その日までリクエストを遅らせることをおすすめします。 
 

レート制限を受けないようにするためのヒント

これから紹介するヒントは、コードを保守的に記述し、レート制限を受ける可能性を抑えるためのものです。実現したいと考えている一部のアプリケーション機能（特に最新の結果を表示するためのもの）はレート制限の観点から実現不可能です。情報をリアルタイムで表示することがアプリケーションの目的である場合は、フィルタリングおよびサンプリングされたストリームエンドポイントを検討してください。 
 

キャッシュ

多用が想定される場合、アプリケーションまたはサイトにAPI応答を保存してください。たとえば、ウェブサイトのランディングページでページを読み込むたびにTwitter APIを呼び出すのは避けてください。代わりに、APIの呼び出し頻度を下げ、応答をローカルキャッシュに読み込んでください。こうすることで、ユーザーがウェブサイトにアクセスした時に、キャッシュされたバージョンの結果が読み込まれるようになります。
 

アクティブユーザーを優先する

サイトで多数のTwitterユーザーを追跡している場合（ユーザーの現在のステータスやTwitterの使用状況に関する統計情報を取得しているなど）は、サイトに最近サインインしたユーザーに絞ってデータをリクエストすることを検討してください。
 

検索結果に合わせて調整する

アプリケーションで大量の検索語句をモニタリングしている場合は、ヒットする結果があるものよりもヒットしない検索のクエリ頻度を下げてください。クエリ頻度を下げることで、人気のあるクエリの最新状況を常に把握しながら、ほとんど変化のないクエリのリクエストを繰り返し行わなくて済むようになります。または、フィルタリングされたストリームエンドポイントと検索クエリによるフィルターの使用を検討してください。
 

拒否リスト

レート制限に違反したアプリケーションは拒否されます。拒否されたアプリはTwitter APIから応答を取得できません。ご自身、またはアプリケーションが拒否され、それが間違いであると思われる場合は、プラットフォームサポートフォームを使用してサポートを依頼できます。次の情報をお伝えください。

1. アプリケーションが拒否されたと考える理由を説明してください。
2. レート制限に現在かかっていない場合は、問題を修正した方法を詳しく説明してください。