LINE Messaging APIで429が返るとき｜頻度と月の通数を分けて調べる

LINE Messaging APIの「429 Too Many Requests」は、短時間のリクエストが多い場合だけに返るエラーではありません。月のメッセージ通数や、一部の機能の同時処理数も原因になります。まず、どのAPIを呼び、どんなエラーメッセージが返ったかを確認してください。

原因が違えば、送信をゆっくりにする、処理中の配信を確認する、月の送信計画を見直す、といった対応も変わります。429という番号だけを見て、すぐプランを上げたり、同じリクエストを繰り返したりしないことが出発点です。

最初にAPIの種類と発生時刻を確認する

調査では、機能名、HTTPメソッド、エンドポイント、発生時刻、ステータスコード、エラーの分類を揃えます。認証トークン、送信本文、個人情報を調査用の資料へそのまま貼り付ける必要はありません。

同じ時間帯に動く処理も見ます。定期配信、個別通知、データ連携などが、同じチャネルの同じ機能を呼び出していないかを確認してください。担当者一人の操作だけが少なくても、サービス全体では集中している場合があります。

公式リファレンスでは、レート制限がチャネル単位・エンドポイントごとに適用されることが説明されています。サーバーを増やしただけで、同じチャネルの制限が分割されると考えないでください。

頻度・月の通数・処理中の予約を分ける

図：四つは順番に発生する状態ではなく、原因候補と確認先です。対象のAPIで起こり得る条件を公式資料と照合します。

短時間に呼び出しが集中している

対象エンドポイントの上限と、自分たちの呼び出し頻度を比べます。制限値は機能によって異なるため、Messaging API全体に一つの秒間上限があるという見方はできません。

複数の処理が集中しているなら、キューで呼び出しを調整し、待ち時間や再試行回数に上限を設けます。待機中の通知に何の優先度が必要かも決めます。キャンペーンの大量送信を進めるために、個別の相談に必要な連絡まで長く待たせないようにします。

月に送れるメッセージ数を超えている

エラーメッセージが月の上限を示す場合は、当月の上限目安と使用量を確認します。秒間の呼び出しを減らしても、月の残数そのものは増えません。

料金と通数の対象はMessaging APIの公式料金案内と、メッセージ通数の数え方を照合します。API呼び出し回数と、プランで数えるメッセージ通数を同じ数字として扱わないでください。

残数があるように見えても、配信中の処理で予約されている

公式リファレンスでは、送信開始から件数が確定するまで、送信予定数が月の残数に対して予約されることが説明されています。特にナローキャストでは、この扱いによって、別の送信が月の上限エラーになる場合があります。

この場合は、処理中の配信と予定数を確認します。「画面には残数がある」という情報だけで原因を否定せず、送信開始前と処理中の状態を分けて見ます。根拠はナローキャストの注意事項です。

一部のAPIで同時処理数を超えている

オーディエンスの作成・追加などには、同時処理数の条件があります。すべてのメッセージ送信に同じ条件が当てはまるという意味ではありません。該当するAPIなら、ジョブの待機中・実行中の状態を確認して、次の処理を始めるタイミングを調整します。

原因を確認してから、再試行の方法を決める

無制限に同じ処理を再送すると、さらに負荷が集中します。結果が不明な送信では、重複して届ける問題も起こり得ます。対象APIに合わせた再試行の扱いは、送信結果とリトライキーの整理を確認してください。

復旧の確認は、エラーが一回出なくなったことだけで終えません。待機していた処理がどれだけ残り、どの通知が未完了かを見ます。期限を過ぎた通知まで機械的に流さず、今届ける意味があるかを再判定する運用を組み合わせます。

まず一件の429について、呼んだ機能、エラーの分類、月の残数、同時に動いていた処理を並べてください。原因が説明できてから送信計画を変えると、不要な再試行や、根拠のないプラン変更を避けられます。

仕様確認：2026年10月7日。参照：Messaging APIリファレンス、料金案内。制限の数値は対象APIの最新資料を参照してください。