【ITニュース解説】4 Days, 3 Wasted Calls Per Run: My Retry Loop Mistook a Quota-Limit Message for a 'Too Short' Article

あるシステム運用者が、AIを使って自動的に記事を生成するスクリプトを運用していた。このスクリプトは、特定の製品に関するレビュー記事をAIモデル「Claude」に作成させるもので、「note2-daily-stock.sh」という名前が付いていた。AIが生成した記事は、「文字数が7,000文字以上か」「アフィリエイトリンクが2つ以上含まれているか」といった複数の基準で品質チェックが行われる仕組みだった。もし品質基準を満たさない場合、スクリプトは最大3回までAIに記事生成を依頼し直す（リトライする）ように設計されていた。

しかし、2026年9月13日から16日までの4日間、このスクリプトは毎日、同じ症状で3回連続の失敗を繰り返していた。原因は、AIモデル「Claude」の利用回数や量に設けられた上限（クォータリミット）に達してしまったことにあった。AIがクォータリミットに達すると、記事本文ではなく「上限に達しました」という短い1行メッセージを返していた。ところが、スクリプトはこの1行メッセージを「AIが記事を生成したが、本文の文字数が足りなかった」と誤って解釈してしまったのである。

スクリプトは、記事の品質チェックで「文字数が足りない」と判断すると、「もう一度試せばうまくいくかもしれない」と考えて、無駄にAIへの呼び出しを繰り返していた。実際にはクォータリミットのため、何度リトライしてもまともな記事が生成されるはずはなかった。この結果、毎日3回分のAI呼び出しが無意味に消費され、スクリプトは記事を一つも作れないまま4日間を過ごしてしまった。これは、本来であれば1回の呼び出しでリミットを検出し、すぐに処理を中止すべき状況だった。

この問題の根源は、スクリプトがエラーの種類を区別していなかった点にある。エラーには、一時的な問題でリトライすれば解決するもの（例：ネットワークの一時的な不調で文字数が足りない記事ができた）と、何度リトライしても解決しないもの（例：利用制限のためそもそも記事が生成されない）の2種類がある。今回のスクリプトは、「記事が短い」という表面的な症状だけを見て、そのエラーがリトライで解決可能なものか、不可能なものかを判断できていなかったのである。

この状況を改善するため、スクリプトに修正が加えられた。新しい処理では、AIから応答を受け取った直後に、その内容を詳細にチェックするようになった。具体的には、応答メッセージの中に「limit」「usage limit reached」といった、クォータリミットを示す特定のキーワードが含まれていないかをgrepというコマンドで検索するようにした。もしこれらのキーワードが検出された場合、それは「利用制限に達した」という明らかなサインなので、スクリプトは記事の品質チェックに進むことなく、すぐに処理を中断するように変更された。

この修正により、スクリプトはクォータリミット中に無駄なAI呼び出しを繰り返すことがなくなり、1回の呼び出しでリミットを検出して直ちに終了できるようになった。半端に生成されたファイルやダウンロードされた画像も削除され、エラーを速やかに管理者に通知する機能も追加された。これにより、無駄なリソースの消費を防ぎ、問題発生時の対応も迅速に行えるようになった。

しかし、この問題にはさらなる落とし穴があった。今回修正された「note2-daily-stock.sh」以外にも、同じような目的でAIに記事生成を依頼し、品質チェックで失敗したらリトライする構造を持つスクリプトが他にも3つ存在していた。「article-daily-stock.sh」「maker-daily-stock.sh」「series-daily-stock.sh」である。これらの兄弟スクリプトを調べたところ、いずれも今回追加されたクォータリミット検出の仕組みが実装されていなかった。

特に「series-daily-stock.sh」は、「note2-daily-stock.sh」とほぼ同じリトライ構造を持っており、クォータリミット中に動けば同様に無駄なAI呼び出しを繰り返す可能性が非常に高かった。また、「maker-daily-stock.sh」では、同じ4日間の期間に同じ題材で7回連続で失敗したという記録が残されていた。このスクリプトでは、「失敗しても次の記事の題材に進む」という応急処置が施されていたが、「リミットメッセージを文字数不足と誤解釈する」という根本的な問題は依然として未解決だった。

この一連の出来事から、システム開発における重要な教訓がいくつか得られた。 第一に、リトライ処理を設計する際には、単に「失敗した」という事実だけでなく、どのような理由で失敗したのか、そのエラーがリトライで解決可能なものなのか、あるいは不可能なものなのかを明確に区別する必要があるということだ。解決不可能なエラーに対しては、無駄なリソース消費を避けるために即座に処理を中断すべきである。 第二に、一つの問題解決策が、構造が似ている他のスクリプトに自動的に適用されるとは限らないということだ。あるスクリプトで修正を発見しても、それを手動で他の関連スクリプトにも適用し、確実に機能しているかを確認する作業が不可欠である。この伝搬作業が怠られると、同じ根本原因による問題が複数の場所で発生し続け、それぞれ異なる応急処置が施されて場当たり的な解決に終わる可能性がある。

今回のケースは、リトライ処理の設計の甘さが、資源の無駄遣いだけでなく、問題解決の遅れや品質低下につながることを示している。今後のシステム開発では、エラーの種類をきちんと識別し、それに応じた適切な処理を行うことで、より堅牢で効率的なシステムを構築する意識が求められる。また、一度得た教訓を、類似する他のシステムにも確実に反映させるための仕組みづくりも重要になるだろう。