AIエージェントのAPI制限を共有枠で制御する設計

Airbyteは、複数のAIエージェントが外部APIを使う際のレート制限を、個別再試行ではなく共有予算として扱う設計を解説しました。

要点

• エージェントごとの指数バックオフだけでは、組織共通のAPI枠を把握できません。
• 共有トークン枠、バックプレッシャー、優先度、段階的な機能縮退を組み合わせます。
• Salesforce、HubSpot、Jiraのように異なる制限方式を提供者ごとにモデル化します。

今回のブログ記事で語られていること

記事は、単一エージェントでは妥当に見える再試行処理が、複数エージェントの本番運用では逆に混雑を増やす問題から始まります。各インスタンスが同じ組織、アカウント、アプリのAPI枠を消費しているのに、ローカルな再試行処理は全体の残量を知りません。同時に429を受けた処理が似た時刻に再試行すると、ジッターを加えても共有枠そのものの超過は防げないと説明しています。

基盤になるのは、中央ストアで管理する共有トークン枠です。取得処理は原子的に実行し、複数プロセスが最後の一枠を同時に使わないようにします。事前予約には有効期限を設け、エージェントが停止した場合に未使用枠を戻します。その上で、残量が少ないときは新しいツール呼び出しを送らないバックプレッシャーを働かせます。制限は提供者ごとに異なり、Salesforceの日次・同時実行、HubSpotの短時間バーストと日次枠、Jiraのポイント制を一つの固定式へ押し込めない点も重要です。

需要が枠を上回る場合は、顧客向け書き込み、処理に必要な読み取り、背景のポーリングを同列に扱いません。記事は重要度を付け、空振りの多いポーリングをキャッシュや破棄へ回し、重要な書き込みを残す方法を示します。外部APIが遅くなった場合には、重要でない処理を止める段階的な機能縮退も事前に決めます。共有枠、流量制御、優先度、縮退のどれかが欠けると、再試行が障害中の提供者をさらに圧迫する連鎖が起きるという結論です。

実装時は、API提供者が返す残量やリセット時刻を成功応答からも読み、429が届く前に制御します。運用担当は、どのツール呼び出しを止められるか、どれを顧客処理として守るかを業務側と合意する必要があります。

今回のブログ記事が関係する人

複数エージェントを運用する基盤担当、外部SaaS連携を実装する開発者、障害時の処理優先度を決めるプロダクト責任者に関係します。

結局、今回のブログ記事をどう読むべきか

429対応を再試行ライブラリだけの問題にせず、組織共通の希少資源を配分する設計問題として捉え直す記事です。エージェント数が増える前に、共有枠と止められる処理を定義することが実践的です。