🥝

ZapierのLoop処理におけるAPIレート制限の回避策

に公開

Zapierを活用してAPIから取得した一覧データを外部ツールへ連携する際、「Looping by Zapier」は非常に有用な機能です。

本記事では、「Backlogの課題データをAPI経由で取得し、Notionのデータベースに同期する」という実例をもとに、構築時に直面したAPIレート制限という課題と、「Code by Zapier」ステップを用いた解決策について解説します。

AIに相談しても一般的な回答しか得られず、並列実行制御という本質的な解決策には辿り着けませんでした。PCの前であれこれ試行錯誤してもダメだったのですが、頭を洗っていたときにふと、この解決策が降りてきました。
類似の知見も少ないため、同じ課題に直面している方の参考になればと思い共有します。
BacklogやNotionに限らず、APIを利用して複数のデータを処理するあらゆるシナリオにおいて応用可能かと思います。

直面した課題:APIレート制限によるエラーの発生

構築したZapの構成概要は以下の通りです。

  1. Trigger: 日次実行
  2. Action: Backlog APIへリクエストを送信し、更新された課題一覧(JSON)を取得
  3. Loop: 取得した課題データを「Looping by Zapier」で反復処理
  4. Action: Notion APIへリクエストを送信し、各課題ページを更新(または作成)

標準的なフロー構成ですが、実行時にNotionへの書き込みステップにおいて 429 Too Many Requests エラーが多発する事象が発生しました。

原因:Looping仕様における「並列実行」の挙動

「Loop」という名称から、プログラミングにおける for 文のような順次処理を想起しがちです。

しかし、ZapierのLooping機能は、並列処理に近い挙動[1]を示します。
例えば20件の課題データが存在する場合、Zapierはそれらに対する後続のアクションをほぼ同時にトリガーします。

その結果、20件分のリクエストが短時間にAPIへ集中し、設定されたレート制限に抵触することになります。

「Delay by Zapier」による解決の限界

一般的な解決策として「アクションの前に待機時間を設ける」手法が考えられますが、Zapier標準の「Delay by Zapier」には、本ケースにおいて以下の2つの制約が存在します。

  1. 最小単位が1分である点[2]
    数秒間隔の制御で十分な場合でも、最小設定値である1分間の待機が必要です。20件の処理では合計20分以上を要し、実用的な処理速度とは言えません。

  2. Delayステップ自体も並列で動作する点
    仮に「1分待機」を設定しても、並列で実行されている20件の処理が「一斉に1分間待機し、一斉に再開する」挙動となります。
    結果として、1分後に再びアクセス集中が発生し、エラーの根本解決には至りません。

解決策:「Code by Zapier」による「可変待機」の実装

この課題を解決するためには、「1件目は2秒後、2件目は4秒後、3件目は6秒後……」といったように、処理順序に応じて待機時間を動的に変化させる実装が必要です。

これを実現するために、「Code by Zapier」を利用します。

実装コード

Loopステップの直後に「Code by Zapier」を配置し、Input Dataとして index というキーでLoopingステップから出力される loop_iterationを渡します。

Input Dataの設定
Input Dataの設定

コード(Python)は以下の通りです。

import time

# ループの回数を取得(デフォルト: 1)
idx = int(input_data.get('index', 1))

# 待機時間を計算して実行
delay_per_item = 2  # APIのレート制限に合わせて調整する値
sleep_time = idx * delay_per_item

time.sleep(sleep_time)

return {'status': 'slept', 'seconds': sleep_time, 'index': idx}

ロジックの解説

  • loop_iteration: Zapierが自動的に付与する「現在のデータが何件目か」を示す数値です。
  • idx * delay_per_item: これにより、後続ステップの実行タイミングを階段状に分散させることが可能になります。擬似的な順次処理を実現し、APIへの負荷を平準化します。
  • return {...}: Zapierの次のステップへデータを渡すための処理です。必須ではありませんが、ログで「何秒待機したか」「何番目の処理か」を確認できるように出力しています。

留意点:テスト実行時の挙動について

本実装を行う際、Zapierのエディタ上で「Test Step」を実行して動作検証を行う場面がありますが、以下の仕様に留意する必要があります。

テスト時のLoop対象データ

エディタ上のテストでは、Loop対象データのうち「最初の1件」のみが処理される仕様[3]となっています。

そのため、Inputの index には常に 1 が渡され、何度テストを実行しても「2秒待機」の結果のみが返却されます。「計算ロジックが機能していない」と誤解されるケースがありますが、ZapをPublishして本番稼働させた際には、正常に 2, 3, 4... とインクリメントされた数値が渡され、意図通りに動作します。

まとめ

ZapierのLoop機能においてAPIレート制限が発生する場合、以下の3点を考慮してください。

  1. ZapierのLoopは並列実行されるため、API制限に抵触しやすい
  2. 標準のDelay機能は「1分未満」の指定ができず、並列実行の解消策としては不十分である
  3. Pythonステップで「係数 × 待機時間」を実装し、実行タイミングを分散させる手法が有効である
脚注
  1. Loop your Zap actions - Zapier Help Center ↩︎

  2. Add delays to Zaps - Zapier Help Center ↩︎

  3. Loop your Zap actions - Zapier Help Center ↩︎

Discussion