10sec Tips

10秒tips

突然の429エラーを防ぐ！Messaging API「レート制限」攻略の鉄則

  • 「メッセージ配信や設定変更の途中で、なぜか429エラーが発生して処理が止まる……」そんなトラブルに直面していませんか？
  • LINE Messaging APIでは、プラットフォームの安定稼働のために機能（エンドポイント）ごとの「レート制限」が細かく定められています。
  • 今回は、突然のエラー停止を防ぎ、安定した大量配信・データ連携を実現するための実務ポイントをサクッと解説します！

📊 10秒でわかる！エンドポイント別の主な制限値

レート制限はチャネル単位かつAPI機能（エンドポイント）ごとに適用され、同じURLでもHTTPメソッドが異なれば別機能としてカウントされます。

対象機能・エンドポイントレート制限値 実務上の注意点
オーディエンス管理系60リクエスト/分 作成・更新・取得・削除が対象。IDごとに同時処理数上限（10件）あり
Webhook設定・情報取得1,000リクエスト/分 運用開始時やURL変更時の連続呼び出しに注意
リッチメニュー作成・削除100リクエスト/時 時間単位の厳しい制限（管理画面からの操作は対象外）
リンク済みリッチメニュー一括置換3リクエスト/時 最も制限が厳しいエンドポイントの1つ。頻繁な切替はNG
マルチキャスト送信・クーポン管理200リクエスト/秒大量配信時のバケット枯渇・スパイクに注意
一般的なエンドポイント2,000リクエスト/秒短期トークン（370/秒）やローディング（100/秒）など個別設定あり

💡 成果を出すための「3つの鉄則」

  • 「トークンバケット方式」の枯渇を防ぐ
    • リクエストごとに消費されるトークンが補充速度を上回り続けると、バケットが空になり429エラーが返されます。
    • API送信を設計する際は、瞬間的なスパイクだけでなく、補充速度を考慮したキューイングや送信間隔（レートリミッター）の導入が必要です。
  • 「制限の桁」と「同時処理数」を事前に把握する
    • 秒単位（2,000/秒）のエンドポイントがある一方、リッチメニュー一括置換（3/時）やオーディエンス管理（60/分）など極端に枠が狭い機能が存在します。
    • 特にオーディエンス操作では、レート制限とは別に「同一IDにつき同時処理数10件まで」という上限があり、ジョブステータス（待機中・実行中）の監視が欠かせません。
  • バックオフ（再試行待機）を組み込む
    • 429エラーが返ってきた際に即時リトライを繰り返すと、バケットが回復せずエラーが長期化します。
    • しばらく時間を置いてから段階的に再リクエストを送る「エクスポネンシャル・バックオフ」等のリトライ制御を必ず実装しましょう。

🏁 今回の結論

Messaging API活用の鍵は、機能ごとの「制限値の桁」と「バケット補充のペース」を正しく見極めたアーキテクチャ設計にあります。

大量配信やバッチ処理を稼働させる前に、利用するAPIの単位（秒・分・時）と同時処理数の上限を必ずチェックしておきましょう。

🤝 LINE運用・API開発ならフォーグローブにおまかせ！

  • フォーグローブは、LINEヤフー社より「コミュニケーション部門」および「LINEミニアプリ部門」の2部門で認定を受けているTechnology Partnerです。
  • 429エラーを回避する大量配信基盤の構築から、Webhook・トークン管理の最適化まで、高度な技術力でトータルにサポートいたします。
  • 「API連携が安定しない」「大量配信時のエラー対策を見直したい」という際は、ぜひお気軽にご相談ください！
一覧にもどる