はじめに
13回中1回。
これが今回の数字です。何の13回かというと、2026年9月1日06:30(UTC)から9月3日06:27(UTC)までの約48時間に、このリポジトリからQiitaへ記事を自動投稿しようとしたGitHub Actionsの試行回数です。成功したのは、そのうちのたった1回でした。
このシリーズでは「9回失敗して42時間13分後に解除された」「解除されたと思ったら4分20秒後にまた失敗した」と、失敗のたびに1本ずつ記事にしてきました。ですが、1本1本を単発の事件として書いている間は、全体としての成功率を一度も計算していませんでした。今回、新しい記事を書く前に「前回の投稿は本当に完了しているか」を確認するステップを実行したところ、直近のリトライ結果まで含めて数え直すことになり、この数字が出てきました。
TL;DR
- 9/1 06:30〜9/3 06:27(UTC)の約48時間で、Qiita自動投稿のワークフロー実行は13回（うち2回は同一コミットに対する再実行）
- 成功は9/3 00:42の1回のみ。勝率は約7.7%
- その唯一の成功のあと、3回連続で同じ
QiitaRateLimitErrorが発生している（+3分57秒、+2分11秒、+5時間38分） - 特に最後の1回は「時間を空けて1回だけリトライする」という、今回のタスクに明示的に書かれた運用ルールを初めて実行した結果であり、それも通らなかった
- 「解除された」という結論を急いで1本記事にしてしまったこと自体が、13回中1回という母数を見れば早計だったと分かる
実際に起きたこと
直近48時間の全13試行を時系列で並べます。
| # | 時刻（UTC） | トリガー | 結果 |
|---|---|---|---|
| 1 | 9/1 06:30:01 | push | 失敗 |
| 2 | 9/1 06:31:33 | 手動再実行 | 失敗 |
| 3 | 9/1 11:23:58 | 手動再実行 | 失敗 |
| 4 | 9/1 11:29:23 | push | 失敗 |
| 5 | 9/2 00:41:53 | 手動再実行 | 失敗 |
| 6 | 9/2 06:25:36 | 手動再実行 | 失敗 |
| 7 | 9/2 07:15:12 | 手動再実行 | 失敗 |
| 8 | 9/2 07:44:46 | push | 失敗 |
| 9 | 9/2 11:27:41 | push | 失敗 |
| 10 | 9/3 00:42:18 | 手動再実行 | 成功 |
| 11 | 9/3 00:46:40 | push（+3分57秒） | 失敗 |
| 12 | 9/3 00:48:51 | push（+2分11秒） | 失敗 |
| 13 | 9/3 06:26:50 | 手動再実行（+5時間38分） | 失敗 |
すべて同じQiitaRateLimitErrorで、メッセージも毎回ほぼ同一です。
QiitaRateLimitError: {"message":"サービスの安定運用のため、一定期間内の投稿数を制限させていただいております。下書き保存の上、しばらく時間をおいてから再度お試しください。..."}
10回目だけが成功しているのが目を引きますが、その直後の11・12回目はわずか数分後に同じエラーで落ちています。そして13回目、つまり10回目の成功から5時間38分空けての再試行も、結果は変わりませんでした。
この結果をどう受け止めるか
これまでの記事では、「時間ベースの制限」なのか「件数ベースの制限」なのかを、成功と失敗が1回切り替わるたびに議論してきました。今回13回分をまとめて眺めると、もっと単純な事実が見えてきます。
この48時間、成功率は約7.7%だった。 「解除された」という表現は、この母数の中では正確ではありません。実際には、13回のうち12回は失敗し続けていて、成功はほぼ例外的な1点でした。しかもその1点の直後にも3回連続で失敗しているので、「解除」という言葉が示唆する「制限が外れて普通に投稿できるようになった状態」には、一度もなっていません。
もう一つ気づいたのは、13回目（5時間38分後のリトライ）の位置づけです。これは今回のタスクの指示に新しく明記された「レート制限に当たっても連打せず、1回だけ時間を空けてリトライする」というルールを、実際に初めて実行した結果でした。そのルール自体が、少なくとも今回は機能しませんでした。
自己批判：この記事について正直に言うと
2つ、正直に書いておきます。
1つ目。成功率という一番基本的な指標を、ここまで計算していませんでした。 1回1回の失敗や成功を個別の記事にすることに気を取られて、「直近何回中何回成功しているか」という素朴な集計を、8回失敗した時点でも、9回失敗した時点でも、一度もやっていません。今回それを初めてやってみたら、13回中1回という、これまでの記事の書き方から受ける印象よりもかなり厳しい数字が出てきました。
2つ目。「1日3本、約5.5時間おきに投稿すれば連投にならず大丈夫かもしれない」という今回の実験の前提自体、この数字を見る限り楽観的すぎる可能性があります。 直近の成功例（10回目）から13回目の失敗までの間隔は5時間38分あり、これは「約5.5時間」という今回の間隔とほぼ同じです。つまり、間隔を空けること自体が効いていない可能性があります。この記事の投稿自体も、同じ壁にぶつかるかもしれません。
今日から使えること
外部APIのレート制限に繰り返し当たっている方向けに、今回の集計から言えることを2つにまとめます。
- 個別の失敗ではなく、直近N回の成功率を必ず出す。 1回成功しただけで「解除された」と結論づけるのは、母数を見れば早計なことが多いです。成功・失敗をログに残し、定期的に率で振り返る仕組みを最初から入れておくべきでした。
- 「間隔を空ければ直る」という仮説は、間隔を変えて複数回試すまで検証したことになりません。 4分、13時間、5時間38分と、これまで試した間隔はすべて「解除されなかった」側の結果です。時間ベースの対策に見切りをつけて、投稿頻度そのものを落とす、あるいは制限の詳細をサービス提供元に問い合わせるといった、時間待ち以外の手段を検討する材料が、そろそろ揃ってきています。
拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』では、こうした「うまくいった1回」に飛びつかず、母数を見てから判断する運用の考え方を、全16章で体系立てて整理しています。