MakeでChatGPTの429エラー(Rate Limit)が起きる原因
Make（旧Integromat）でChatGPT API（OpenAIモジュール）を組み込み、大量のデータをループ処理で一括生成・処理する際、頻発するのが「429 Too Many Requests（Rate Limit Reached）」エラーです。 このエラーは、OpenAI側が設定している「1分あたりのリクエスト数（RPM）」や「1分あたりのトークン数（TPM）」の上限を超えたために発生します。
特にMakeのIterator（イテレータ）モジュールを使って配列データを連続処理すると、Makeは可能な限り高速でAPIを叩き続けます。Tier 1などのAPI利用枠が低いアカウントでは、わずか数十件のループ処理でも数秒でTPM/RPM制限に到達し、シナリオが強制終了（エラー停止）してしまいます。 これを回避するためには、シナリオ側で「意図的に処理を遅延させる」または「エラー発生時に自動で再実行（リトライ）する」設計が不可欠です。
Sleepモジュールを使ったAPIリクエストの待機設定
最もシンプルかつ即効性のあるRate Limit回避策は、Makeの組み込みツールである「Sleep」モジュールを挟むことです。 ChatGPTモジュールの直前、またはループのサイクル内にSleepモジュールを配置し、リクエストとリクエストの間に数秒のインターバルを設けます。
Sleepモジュールの設定ポイント
- Delayの設定値: 処理するテキストのトークン数にもよりますが、通常は
3〜5秒程度に設定するとRPM制限を回避しやすくなります。長文を生成する場合はTPM制限にも引っかかりやすいため、10秒以上の待機が必要になるケースもあります。 - 配置場所: IteratorとChatGPTモジュールの間、もしくはChatGPTモジュールの直後に配置します。
ただし、Sleepモジュール単体での対策には限界があります。API側の突発的な遅延や、想定以上のトークン消費が発生した場合、固定秒数の待機だけでは429エラーを完全に防ぎ切ることはできません。シナリオの安定稼働を確実にするには、次に解説するError Handlerの導入が必須となります。
Error Handler(Break)による自動リトライの実装手順
429エラーが発生してもシナリオを停止させず、一定時間待機した後に自動で処理を再開させるには、Makeの「Error Handler」と「Break」ディレクティブを使用します。これにより、堅牢な自動リトライ機構を構築できます。
1. Error Handlerの追加
ChatGPTモジュールを右クリックし、「Add error handler」を選択します。空のモジュールが下部に分岐して作成されるので、そこにMakeの組み込みツール（Directives）から「Break」を選択して接続します。
2. Breakモジュールの設定
Breakモジュールは、エラーが起きた際に指定した条件でリトライを行うための強力な機能です。以下のように設定します。
- Number of retries（リトライ回数）:
3〜5回程度に設定します。これ以上失敗する場合は、APIのクレジット残高不足（402エラー）など別の問題が疑われます。 - Interval between retries（リトライ間隔）: 一般的にOpenAIのRate Limitは数十秒で解除されるため、
60秒（1分）程度待機するよう設定すれば十分なケースが多いです。Tierや処理内容に応じて調整してください。
3. フィルターでの429エラー指定（推奨）
Breakモジュールに繋がるルート（点線部分）をクリックし、フィルターを設定します。 Conditionに [Error] Message を指定し、Text operatorsの Contains (case insensitive) で 429 または Too Many Requests と入力します。 これにより、「429エラーの時だけリトライを行い、他の致命的なエラー（認証エラーなど）の時は速やかにシナリオを停止する」という安全なエラーハンドリングが実現します。
この「Sleepによる予防」と「Breakによる事後リトライ」を組み合わせることで、Make上でのChatGPT APIの大量処理は劇的に安定します。途中でシナリオが止まり、手動で再実行する手間から完全に解放されるはずです。
プログラムのほうは、今後も設定されたスケジュールに従って articles フォルダへ自動で新しい実践ストックを積み上げていきます。またいつでも生成された記事の精査や、次の展開についてご相談くださいね！
