GitHub・REST API の回数制限・2026年10月24日に確認

GitHub の「API rate limit exceeded」

GitHub は呼び出しの回数を数えていて、上限を使い切ると、しばらく答えなくなります。トークンにも権限にも問題はなく、待てば直ります。GitHub のREST API のレート制限より：一次的な上限を超えると、答えは 403 か 429 で、x-ratelimit-remaining ヘッダーが 0 になります。x-ratelimit-reset の時刻までは試し直さないこと。二次的な上限を超えたときも 403 か 429 で、そう書いた文が返ります。

答えの全体

トークンなしのとき（公開の報告より。GitHub は自分から見えた IP アドレスを書きます）：

HTTP 403

API rate limit exceeded for [IP アドレス]. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)

和訳：「[IP アドレス] は API の回数の上限を超えました（よい知らせ：認証した呼び出しなら上限はもっと高くなります。詳しくは説明書を）」。

トークンありなら、IP アドレスの代わりにアカウントを書きます。「API rate limit exceeded for user ID [番号].」（この報告のとおり）。二次的な上限なら「You have exceeded a secondary rate limit. Please wait a few minutes before you try again.」（和訳：二次的な回数の上限を超えました。数分待ってから試し直してください。この報告とこの報告のとおり）。

いまの残りはヘッダーで分かります。回数を使わずに見るには（/rate_limit の呼び出しは、GitHub が一次的な上限に数えません）：

curl -i -H "Authorization: Bearer your-token" https://api.github.com/rate_limit

x-ratelimit-limit：1時間に呼べる回数。
x-ratelimit-remaining：残りの回数。0 なら一次的な上限を使い切っています。
x-ratelimit-reset：また使えるようになる時刻（UTC の Unix 時刻・秒）。
x-ratelimit-resource：どの上限に数えられたか。たとえば core や search。

Authorization の行を外すと、トークンなしの上限が見えます。GitHub Enterprise Server なら、api.github.com の代わりに自社のサーバーの API の住所を呼びます。

どの上限か

GitHub のREST API のレート制限より：

トークンなし：1時間に60回。人やプログラムごとでなく、IP アドレスごとに数えます。同じ会社や VPN のアドレスから出ている人は、みんなで60回を分け合います。
トークンあり：1時間に5,000回をアカウントごとに。自分の個人アクセストークンも、自分の代わりに動くアプリも、同じ5,000回に数えられます。GitHub Enterprise Cloud の組織のアプリは15,000回ですが、使った分は自分の5,000回からも減ります。GitHub の例では、アプリが自分の代わりに10,000回呼ぶと、自分のトークンの分はもう残っていません。
検索には別の上限があり、トークンありで1分に30回、なしで10回です（検索）。GraphQL にも別の上限があり、ユーザーごとに1時間5,000ポイントです（GraphQL のレート制限）。GraphQL では、使い切っても答えは 200 のままで、エラーの文と x-ratelimit-remaining の 0 が返ります。
二次的な上限は、短い間の集中にかかります。同時に100件まで、1つの REST の窓口に1分900ポイントまで、中身を作る呼び出しはおおむね1分80回・1時間500回まで。GitHub は予告なしに変えることがあり、いまどこまで使ったかを確かめる方法はなく、明かされない理由でかかることもあります。

いつ試し直すか

GitHub のトラブルシューティングの順番です：

答えに retry-after ヘッダーがあれば、その秒数だけ待つ。
x-ratelimit-remaining が 0 なら、x-ratelimit-reset の時刻まで待つ。
どちらでもなければ、少なくとも1分待つ。二次的な上限で断られ続けるなら、待つ時間を毎回のばし、何回かでやめる。

断られている間に呼び続けないこと。GitHub は、その連携が締め出されることがあると書いています。

くり返さないために

トークンをまだ使っていない：トークンを入れる。上限が1時間60回から5,000回になります。
もうトークンを使っている：上限はアカウントのものなので、トークンを作り直しても直りません。ほかに何がそのアカウントを使っているかを探します。ほかのツール、スクリプト、自分のトークンを入れた CI など。
変わっていない答え：前の答えの etag を付けて読むと、何も変わっていなければ 304 が返ります。GitHub のベストプラクティスより、トークンを付けた呼び出しなら、304 は一次的な上限に数えられません。
集中：同時に送らず1件ずつ送り、変更と変更の間は少なくとも1秒あける。

IntelliJ IDEA では GitHub の文か「User authorization failed」

IntelliJ IDEA に入っている GitHub の機能が、断られた問い合わせをどう受け止めるか。ソース（2026年10月30日に確認・IntelliJ IDEA：GithubApiRequestExecutor.kt・GithubApiRequest.kt・GHAPIExceptionUtil.kt・GHSelectorErrorStatusPresenter.kt）では：

「API rate limit exceeded」と書かれた 403（401・402 でも同じ）はレート制限として扱われ、IntelliJ IDEA は GitHub の文をそのまま出します。上の文がそのまま見えます。
二次的な上限の 403 は、ログインの失敗として扱われます。IntelliJ IDEA は文の中に「API rate limit exceeded」の語があるかでレート制限を見分けていて、「You have exceeded a secondary rate limit…」にはその語が無いためです。Pull Requests のツールウィンドウがつなぐときは、「Could not connect to repository … with account …」（このアカウントでリポジトリにつなげない）と「User authorization failed」（ユーザーの認可に失敗）が出て、Log in again… が出ます。トークンに問題はないので、上のとおり待ちます（GitHub がトークンを断ったときの同じ文）。
429 は、どちらの上限でも、GitHub の文を添えたエラーとして出ます。
GraphQL では、使い切ると 200 とエラーが返り、IntelliJ IDEA はそのエラーの文を出します。
問い合わせのコードは x-ratelimit-remaining と x-ratelimit-resource を利用状況の統計のためだけに読み、x-ratelimit-reset と retry-after は読みません。いつ開くかは、上の /rate_limit で確かめます。

IntelliJ IDEA で GitHub のプルリクを見るなら

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。回数の上限と、トークンを断られたのとを分けて伝えます。上限のときは、上限に達したことと、また使えるようになる時刻（x-ratelimit-reset か retry-after から）を言います。トークンなしなら、1時間60回を使い切ったと言って設定を開けるようにし、そこでトークンを入れると上限は5,000回になります（読むのは無料のまま）。一覧は開いている間5分ごとに読み直し（設定で止められます）、毎回前の答えの etag を付けるので、トークンありなら変わっていない一覧は回数を使いません。レビュアーを読み直すのは、変わったプルリクだけです。自動の読み直しが断られても、画面の一覧はそのまま残ります。レビューのスレッドと、その解決は GraphQL を使います。1.0.42 からは、そこで上限に達したときも同じように、また使えるようになる時刻を言います（前は「GitHub の返事：」のあとに GitHub の文をそのまま出していました）。受信箱・差分・会話は無料、承認・コメント・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。

GitHub は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。