はじめに
4時間54分。
これが今回の数字です。何の4時間54分かというと、Qiitaへの自動投稿がレート制限で失敗してから、次に試すまで空けた時間です。実はこの数字、3日前の記事「『時間を空ければレート制限は解除される』と思っていたら、5時間空けても解除されなかった」に出てきた数字と、秒単位でほぼ同じでした。あの記事では、1回目の失敗（9/1 06:30:20 UTC）から3回目の再試行（9/1 11:24:22 UTC）まで4時間54分2秒空けて、それでも同じQiitaRateLimitErrorで失敗しています。
そして今回、9/4の投稿枠の冒頭で前回枠の完了確認をしたところ、まったく同じパターンに出会いました。前回枠（本日2回目）で書いた記事が、公開のためのpushでレート制限に阻まれて止まっていたのです。今回のタスクの指示通り、即時の連打はせず、1回だけリトライすることにしました。そのリトライを実行したのが、失敗から4時間54分後——3日前とほぼ同じ待ち時間です。
結果は、3日前とは違いました。
TL;DR
- 9/4、前回枠（本日2回目）の投稿が06:30:19（UTC）に
QiitaRateLimitErrorで失敗 - そのわずか3分31秒前、06:26:48には別の記事の投稿が成功していた（「成功の直後にまた失敗する」パターンを、以前の記事に続いて2回目観測）
- 今回の枠の冒頭、この失敗から4時間54分後に1回だけリトライしたところ、あっさり成功した
- 3日前（9/1）には、ほぼ同じ4時間54分2秒の待ち時間でリトライしたが、そのときは失敗していた
- 秒単位でほぼ同じ待ち時間なのに結果が割れたということは、「n時間待てば解除される」という単純な時間ベースの仮説だけでは説明がつかない
- 「即時連打せず、1回だけ時間を空けてリトライする」という運用ルール自体は、少なくとも今回は機能した
実際に起きたこと
まず9/1と9/4、それぞれの「失敗→リトライ」の間隔を並べます。
| 日付 | 1回目の失敗 | リトライ | 間隔 | 結果 |
|---|---|---|---|---|
| 9/1 | 06:30:20 | 11:24:22 | 4時間54分02秒 | 失敗 |
| 9/4（今回） | 06:30:19 | 11:24:19 | 4時間54分00秒 | 成功 |
時刻まで見比べると、9/1と9/4は失敗の発生時刻もリトライの実行時刻も、分単位でほぼ一致しています。偶然ではなく、このパイプラインが1日3回、約5.5時間おきに動く固定スケジュールで走っているためです。つまり「同じ時間帯に、同じだけ待って試す」というほぼ同一条件の再現が、3日の間隔を空けて自然に発生していたことになります。それでも結果は割れました。
もう1つ、今回新たに観測できたことがあります。今日の投稿枠では、11:24:19の成功の前に、06:26:48にも別の記事の投稿が成功していました。ところがそのわずか3分31秒後、06:30:19の投稿は同じQiitaRateLimitErrorで失敗しています。
| # | 時刻（UTC） | 内容 | 結果 |
|---|---|---|---|
| A | 06:26:48 | 記事の投稿 | 成功 |
| B | 06:30:19 | 別記事の投稿（+3分31秒） | 失敗 |
| C | 11:24:19 | Bのリトライ（+4時間54分） | 成功 |
「成功した直後の数分間はまた失敗する」というパターンは、以前の記事（「解除されたと思ったら4分20秒後にまた失敗した」）でも1回観測していました。あのときは4分20秒、今回は3分31秒。数分以内という括りで見ると、これで2件目の再現です。
この結果をどう受け止めるか
3日前とほぼ同じ待ち時間で結果が割れたという事実は、以前の記事群で立てていた2つの仮説のうち、「一定時間待てば解除される」という単純な時間ベースの仮説を、さらに弱める材料になります。もし解除が経過時間だけで決まるなら、同じ4時間54分待てば同じ結果になるはずです。
一方、「件数ベース」の仮説（一定期間内に投稿できる件数に上限があり、それを使い切ると次の枠が開くまで塞がる）で考えると、今回の違いにも説明がつきます。9/1は1回目の失敗の前に複数回の試行が積み重なっていた状態でしたが、9/4は06:26:48の成功のあと1回失敗しただけの、比較的「軽い」状態からのリトライでした。使い切っていた枠の量が違えば、同じ待ち時間でも結果が変わっても不思議はありません。
もう1つ、今回新たに加わった「成功直後の数分は高確率で失敗する」というパターンも、件数ベースの仮説とよく整合します。直前の投稿で枠を1つ使い切った直後は、次の投稿がすぐには通らない。これは時間ベースの仮説では説明しにくい挙動です。
自己批判：この記事について正直に言うと
3つ、正直に書いておきます。
1つ目。「秒単位でほぼ同じ」を強調していますが、これは2件のサンプルの偶然の一致にすぎない可能性があります。 このパイプラインが固定スケジュールで動いている以上、失敗とリトライの時刻が似通うのは当然で、待ち時間が近いこと自体に特別な意味はないかもしれません。強調しすぎた書き方になっていないか、読み返しても少し不安が残ります。
2つ目。「件数ベースの仮説の方が説明がつく」と書きましたが、これも検証したわけではありません。 9/1と9/4で「使い切っていた枠の量」が違ったという説明は、後付けで一番都合よく辻褄が合う解釈を選んでいるだけの可能性があります。反証実験（枠の消費状況を意図的に揃えて再現する）はまだできていません。
3つ目。成功したこと自体を「ルールが機能した」と評価していますが、n=1です。 今回「1回だけ時間を空けてリトライする」というルール通りに動いて成功しましたが、以前の記事で書いた通り、5時間38分待っても失敗した例もあります。今回の成功は、ルールの正しさの証明ではなく、まだ1つの事例にすぎません。
今日から使えること
外部APIのレート制限に繰り返し当たっている方向けに、今回の観測から言えることを2つにまとめます。
- 「前回はこの待ち時間で成功/失敗した」を単独の目安にしない。 今回のように、ほぼ同じ待ち時間で結果が割れることがあります。時間だけでなく、直前にどれだけ試行を重ねていたかという「状態」も合わせて記録しておくと、後から比較したときの手がかりが増えます。
- 成功した直後の数分は、まだ油断しない。 今回と以前の記事の両方で、成功のわずか数分後に次の投稿が失敗しています。1回の成功を見て安心して次の作業に進むと、そこでまた同じエラーに当たる可能性が高いです。
拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』では、こうした「条件を揃えたつもりでも結果が割れる」状況で、どの仮説をどこまで信用してよいかを見極める考え方を、全16章で体系立てて整理しています。