はじめに
4分20秒。
これが今回の数字です。実はこの記事、最初は別の内容で書き始めていました。「Qiitaのレート制限は、9回の失敗と42時間13分を経て、10回目の試行で解除されていた」というタイトルで、直前の失敗（9/2 11:27 UTC）から13時間14分、一度もリトライせずに待った末に、次の試行が成功した記録です。その記事を書き終えて、いざこのリポジトリにpushしようとしたところ——そのpush自体が、同じQiitaRateLimitErrorで失敗しました。しかも、直前の成功からわずか4分20秒後でした。
この記事は、その「解除された」という結論が、記事を書いている最中に覆った経緯をそのまま記録したものです。タイトルも内容も、当初の予定から書き換えています。
TL;DR
- 9回連続の失敗（9/1 06:30〜9/2 11:27 UTC）の後、13時間14分の完全放置を経て、10回目の試行が成功した（9/3 00:42:41 UTC）
- その成功を記事にまとめ、公開しようとpushしたところ、4分20秒後（9/3 00:47:01 UTC）、11回目の試行が同じ
QiitaRateLimitErrorで失敗した - つまり「レート制限が解除された」という表現は正確ではなかった。正しくは「1回だけ枠が開いて、すぐに再び閉じた」
- これは「時間さえ空ければ解除される」という単純な仮説（前回記事で支持していた側）よりも、「一定期間内に投稿できる件数そのものに上限があり、1件消費するとまた次の上限まで塞がる」という仮説のほうに近い挙動
- 記事のタイトルと結論を、公開前に実際のログに合わせて書き直した
実際に起きたこと
直近3回の試行を時系列で並べます。
| # | トリガー | 時刻（UTC） | 前の試行からの間隔 | 結果 |
|---|---|---|---|---|
| 9 | git push（「13時間12分」記事） | 9/2 11:27:41 | — | 失敗（QiitaRateLimitError） |
| 10 | 手動ワークフロー実行 | 9/3 00:42:18 | 13時間14分37秒後 | 成功 |
| 11 | git push（本記事、当初版） | 9/3 00:46:41 | 4分23秒後 | 失敗（同一エラー） |
10回目の成功を見て、僕は「13時間14分の放置が効いたのだろう」と考え、その仮説をそのまま記事の結論にしました。ところが、その記事を公開するための11回目の試行は、成功からたった4分20秒しか空いていないタイミングで、同じエラーに阻まれました。
もし「時間さえ空ければ解除される」が正しいなら、成功した直後にまた投稿できなくなるのは筋が通りません。むしろ、この4分20秒という短さは、「一定期間に投稿できる件数の上限（クォータ）が1つ空き、それを10回目が使い切った」と考えるほうが自然です。
この結果をどう受け止めるか
前回記事（本記事の当初版）は、13時間14分の放置後に成功したことをもって、「時間経過で解除される」という仮説を支持する方向のデータだと書きました。しかし今回の11回目の即時失敗は、その解釈に疑問を投げかけます。
考えられる説明は2つあります。
1つ目。件数ベースの制限。一定期間（例えば24時間）ごとに投稿できる件数の上限があり、10回目の成功でその期間内の枠を使い切った。この場合、次に投稿できるようになるのは「時間が経てば」ではなく「その期間が明けたとき」であり、単純な待機時間では説明できません。
2つ目。運。たまたま10回目が成功する瞬間のウィンドウに滑り込み、11回目はそのウィンドウの外に出てしまった、という偶然の可能性も否定はできません。ただ、4分20秒という短さを考えると、1つ目の「件数ベース」の説明のほうが有力に見えます。
いずれにせよ、はっきりしているのは「1回成功した」ことは「解除された」ことを意味しない、という点です。
自己批判：この記事について正直に言うと
3つ、正直に書いておきます。
1つ目。最初の結論を急ぎすぎました。 「解除されていた」というタイトルで記事を書き終えた時点では、まだそのpush自体を試していませんでした。1件の成功だけを根拠に「解除」と断定したのは、前々回・前回の記事で自分が繰り返し戒めていた「サンプル数が少ないうちに結論を出す」という同じ失敗です。
2つ目。件数ベースの仮説も、まだ検証できていません。 「一定期間の投稿上限」という説明は今回のデータに整合的ですが、その期間が何時間なのか、何件までなのかは分かりません。次に投稿できるタイミングを実際に観測しない限り、これも仮説の域を出ません。
3つ目。この記事自体のpushが、また同じ結果になるかもしれません。 今書き直しているこの記事も、公開しようとした瞬間にまたQiitaRateLimitErrorに阻まれる可能性があります。もしそうなれば、それはそれで「件数ベース説」をさらに補強する材料になります。
今日から使えること
APIのレート制限に繰り返し引っかかっている方向けに、今回の経験から言えることを2つにまとめます。
- 1回の成功を「解除された」と解釈しない。 単発の成功は、制限が完全に外れたことの証拠にはなりません。少なくとも、成功の直後にもう一度試すか、一定時間を置いて再現性を確認するまでは、暫定的な結果として扱うべきです。
- 「時間ベース」と「件数ベース」の両方の仮説を並行して疑う。 待てば直るという前提だけで運用ルールを組むと、件数ベースの制限には対応できません。今回のように、成功直後の再試行という自然な形でデータが手に入ることもあるので、それを見逃さず記録することが次の判断材料になります。
拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』では、こうした「立てた仮説が新しいデータですぐに覆る」状況で、結論を急がずに運用のルールを機械的に守り続ける考え方を、全16章で体系立てて整理しています。