レートリミットとは？API利用制限の仕組みと発注時の確認点

システム開発の提案書やAPI仕様書に、「レートリミット: 1分あたり60リクエスト」「上限を超えた場合は 429 を返却」といった記載を見つけて、手が止まった経験はないでしょうか。数字そのものは読めるのですが、それが自社の業務量に対して足りているのか、足りなかったときに何が起きるのかまでは書かれていません。そのまま社内レビューに諮ってよいものか、判断がつかないまま日が過ぎていきます。

この判断が難しいのには理由があります。レートリミットを扱う情報の多くは、APIを「提供する側」がどう制限を実装するかという技術解説か、用語辞典的な短い定義のどちらかに寄っています。一方で発注担当者が知りたいのは、APIを「呼び出す側」のシステムを外注するとき、何が設計漏れになりやすく、それをどう見抜けばよいかという実務的な物差しです。ここを埋める情報がほとんど流通していません。

しかもレートリミットの厄介さは、平常時には表面化しない点にあります。日中の通常業務では問題なく動いていたのに、月末の一括同期や繁忙期のキャンペーンのときだけ上限に張り付き、一部のデータだけが登録されないまま、エラー通知も出ずに処理が完了扱いになる。こうした「気づけない失敗」は、翌月の締め作業や監査の場で初めて発覚します。

安心していただきたいのは、この論点は非エンジニアでも十分にチェックできるということです。仕組みの理解は3つの要素（単位時間・カウント対象・超過時の挙動）に集約でき、対策も4系統に整理できます。あとは、それが要件定義・見積・受入テストに反映されているかを工程ごとに確認すればよいだけです。

本記事では、レートリミットの定義と目的から始めて、上限を超えたときに業務側で何が起きるのか、制限方式の違いが業務パターンにどう効くのか、主要サービスの制限値をどう読むのか、そして呼び出す側が取れる設計対策と、発注時にベンダーへ確認すべき項目までを順に解説します。読み終えたときに、提案書の制限値を自社の数字と突き合わせ、質問票に落とせる状態になることを目指します。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

レートリミットとは？APIの利用回数を制限する仕組み

レートリミットの定義と「単位時間あたり」という考え方

レートリミット（レート制限、Rate Limiting）とは、一定時間あたりに実行できるAPIリクエストの数に上限を設ける仕組みです。「1分あたり60リクエストまで」「1日あたり10,000リクエストまで」といった形で、API提供側があらかじめ定めています。

この定義で最も重要なのは「単位時間あたり」という部分です。レートリミットは総量の制限ではなく、時間あたりの速度（レート）の制限です。1日10,000リクエストという上限があるサービスに対して、10,000件のデータを1件ずつ送る処理は、理論上は上限内に収まります。しかし同じ10,000件を1分間で一気に送ろうとすると、今度は「1分あたり」の上限に引っかかって止まります。総数だけを見ていると判断を誤るのは、この二重構造が理由です。

もう一点、実務で混乱しやすいのが「何に対する上限か」という適用単位です。同じ「1分あたり60リクエスト」でも、契約アカウント全体に対する上限なのか、APIキー単位なのか、接続元IPアドレス単位なのか、あるいは特定のエンドポイント（機能）単位なのかで、使える量はまったく変わります。仕様書を読むときは、数字だけでなくその数字が何に紐づいているかを必ずセットで確認してください。

API提供側がレートリミットを設ける4つの理由

なぜAPIには制限があるのでしょうか。API提供側がレート制限を設ける理由は、おおむね次の4つに整理できます。この背景を理解しておくと、「交渉すれば外してもらえるのではないか」という誤った期待を持たずに済みます。

このうち最初の2つが本質的です。つまりレートリミットは、API提供側の都合で恣意的に設けられた障害物ではなく、共有インフラを成立させるための前提条件です。したがって設計上は「取り除くもの」ではなく「その中で収まるように業務を設計するもの」として扱う必要があります。この視点の切り替えが、後述する設計パターンの出発点になります。

クォータ・スロットリング・同時実行数上限との違い

API仕様書には、レートリミットとよく似た用語が複数並んでいることがあります。それぞれ効き方が違い、しかも同時に別々に効くため、混同すると「どの数字を気にすべきか」を見誤ります。

たとえば「1日10,000リクエスト、同時接続100まで」と書かれたサービスの場合、1日の総量には余裕があっても、処理を速くしようとして並列度を上げると同時接続数の側で先に止まります。逆に、1件ずつ順番に処理する設計なら同時接続数には余裕がありますが、件数が多ければ1日の上限に届きます。どちらか一方に余裕があることは、もう一方の安全を意味しません。

仕様書の制限値が複数並んでいたら、それぞれについて「自社の処理はこの数字に対してどれくらいか」を個別に確認してください。この読み分けができていない状態でチェックリストを埋めても、形式的な確認に終わってしまいます。

レートリミットを超えると何が起きるのか（429エラーと業務影響）

429 Too Many Requests と Retry-After ヘッダーの意味

レートリミットを超えたリクエストに対して、多くのAPIは HTTP ステータスコード 429 Too Many Requests を返します。これは「一定時間内にリクエストを送りすぎた」ことを示すクライアントエラーで、レート制限の文脈で標準的に使われる応答です（MDN Web Docs: 429 Too Many Requests）。

429 が返ってきたときに重要なのが、あわせて返される Retry-After ヘッダーです。これは「次のリクエストまでどれだけ待つべきか」をAPI提供側が明示するもので、秒数または日時の形式で示されます。呼び出す側のシステムがこの値を読み取って待機時間を決めれば、無駄な再試行を減らし、相手のサーバーにも負荷をかけずに処理を再開できます。

ここが発注時の最初の確認ポイントになります。Retry-After を無視して即座に再送を繰り返す実装は、429 を大量に発生させるだけで処理は進まず、場合によってはAPI提供側から一時的な利用停止措置を受けることさえあります。「リトライ処理を入れています」という説明を受けたら、その待機時間が Retry-After に従っているかまで確認する価値があります。

レスポンスヘッダーで残り回数を把握する

多くのAPIは、429 が返る前の通常のレスポンスにも残量情報を含めています。代表的なものが以下のヘッダーです。名称はサービスによって差がありますが、意味するところは共通しています。

これらは実装上の細かい話に見えますが、運用面では大きな意味を持ちます。残量ヘッダーを記録しておけば、「先月は上限の30%しか使っていなかったが、今月は80%まで来ている」という枯渇の予兆を、業務が止まる前に検知できます。逆にこれを記録していないシステムは、上限に達した瞬間に初めて問題を認識することになります。

後述する監視の話にもつながりますが、「残量が見えているか」は、レートリミットへの対応が本気かどうかを判断する分かりやすい指標のひとつです。

業務側から見た3つの失敗パターン（即時エラー・遅延・サイレントな欠落）

ここからが、発注担当者にとって本題です。技術的には同じ「429 が返った」という事象でも、業務側から見える結果は3通りに分かれます。そして、どのパターンになるかは呼び出す側の実装次第です。

パターン1: 即時エラーで止まる

上限に達した時点で処理が中断し、画面にエラーが表示されたり、失敗通知が飛んだりします。業務は止まりますが、止まったことが分かるため対応できます。3つの中では最も扱いやすいパターンです。

パターン2: リトライして遅延するが最終的に完了する

待機してから再試行する仕組みがあれば、処理は遅れながらも最後まで完走します。ただし「30分で終わるはずの夜間バッチが4時間かかった」という形で、後続処理のスケジュールに影響が出ます。翌朝の始業までに終わらなければ、実質的には障害と同じです。

パターン3: 一部データだけが欠落し、エラーも出ない

最も損害が大きいのがこのパターンです。たとえば1,000件のレコードを外部サービスに同期する処理で、途中の200件が 429 で失敗したにもかかわらず、失敗を握りつぶして「処理完了」とログに記録してしまう実装がこれにあたります。画面にはエラーが出ず、担当者は正常終了だと認識します。

欠落に気づくのは、多くの場合ずっと後です。月末の締め作業で件数が合わない、顧客から「登録したはずの情報が反映されていない」と連絡が来る、あるいは監査で指摘される。そのときには、どのレコードがいつ失敗したのかを追跡する材料も残っていません。復旧のために全件を再同期しようとすれば、今度はその処理自体が上限に引っかかります。

このサイレントな失敗こそが、レートリミットを設計段階で確認すべき最大の理由です。「429 が返ったときにどう振る舞うか」という技術的な問いは、業務の言葉に翻訳すれば「止めるのか、遅らせるのか、それとも黙って落とすのか」という業務仕様の問いです。そしてこれは、技術者ではなく発注側が決めるべき事項です。

レートリミットの主な制限方式と挙動の違い

同じ「1分あたり60リクエスト」という制限値でも、API提供側が採用している制限方式によって、通るリクエストの入り方は変わります。ここでは実装の詳細ではなく、「まとめて送ったときに通るのか落ちるのか」という一点に絞って4つの方式を比較します。この違いが、月次一括処理のような業務にそのまま効いてきます。

固定ウィンドウとスライディングウィンドウの違い

固定ウィンドウ方式は、時間を一定の区切り（毎分0秒〜59秒など）で区切り、その区間内のリクエスト数を数える方式です。実装が単純で分かりやすい反面、区切りの境目で問題が起きます。「1分あたり60回」の制限に対して、10時00分59秒に60回、10時01分00秒にさらに60回を送ると、どちらの区間でも上限内ですが、結果として約1秒間に120回が通ってしまいます。逆に言えば、自社の処理がたまたま境目をまたぐと、想定外に多く通ったり、リセット直前に一気に弾かれたりします。

スライディングウィンドウ方式は、固定の区切りを使わず「現在時刻から遡って60秒間」という移動する窓でリクエスト数を数えます。境目の抜け道がなくなるため制限が厳密になり、提供側から見れば負荷が読みやすくなります。呼び出す側から見ると、「リセットを待てば一気に送れる」という前提が通用しなくなるのが特徴です。

トークンバケットとリーキーバケット（バーストを許すかどうか）

残る2方式は、バケツ（バケット）の比喩で説明されるもので、バーストを許容するかどうかという点で対照的です。

トークンバケット方式は、バケツに一定の速度でトークン（通行券）が溜まっていき、リクエストのたびにトークンを1枚消費するイメージです。しばらくAPIを使っていなければトークンが満タンまで溜まるため、そのタイミングであれば短時間にまとめて送っても通ります。これがバースト（突発的な集中）の許容です。ただしトークンを使い切れば、以降は補充される速度でしか送れません。現に Anthropic の Claude API はトークンバケット方式を採用しており、上限が毎分ちょうどにリセットされるのではなく継続的に回復する挙動になっています（Anthropic: Rate limits、本記事執筆時点）。

リーキーバケット方式は、バケツの底に空いた穴から一定速度で水が漏れていくイメージで、流量を必ず平準化します。どれだけまとめて送っても、処理される速度は一定です。バケツから溢れた分は捨てられる（エラーになる）ため、突発的な大量送信には向きません。

この違いが業務にどう効くかを整理すると次のようになります。

「月末に1万件をまとめて同期する」という業務要件があるとき、連携先がトークンバケット方式なら蓄積分の範囲で通る可能性がありますが、リーキーバケット方式なら確実に時間をかけて流す設計が必要になります。同じ制限値でも設計の前提が変わるということです。

RPM・TPM・RPD・同時実行数という単位の読み分け

制限値には方式だけでなく、単位の違いもあります。特に生成AI・LLM のAPIでは複数の単位が同時に効くため、読み分けが必要です。

RPM と TPM の違いは、生成AIを使う案件では特に重要です。RPM は「何回呼んだか」を数えますが、TPM は「どれだけの文章量をやり取りしたか」を数えます。したがって、1回のリクエストで長文の資料を丸ごと投げるような使い方では、呼び出し回数が少なくても TPM の側で先に上限に達します。OpenAI の API も RPM・TPM・RPD・TPD といった複数の指標をそれぞれ独立に適用しており、どれか一つを超えれば 429 が返る仕組みです（OpenAI: Rate limits、本記事執筆時点）。

「1分あたり500回まで使えるので余裕があります」という説明を受けたときは、その回数制限とは別にトークン量の制限が効いていないかを確認してください。社内文書を要約させるような用途では、実務上の制約はほぼ TPM 側にあります。

主要サービスのレートリミット実例と仕様書の読み方

抽象的な説明を自社の数字に落とすため、日本企業の連携先として現実的なサービスの公開値を見ていきます。目的は数値を覚えることではなく、仕様書のどこを見て何を確認するかという読み方の型を身につけることです。制限値は改定されるため、個別の案件では必ず最新の公式ドキュメントを確認してください。

kintone のレートリミット（1日あたりのリクエスト数と同時実行数）

業務システムの連携先として広く使われている kintone は、レートリミットの構造が分かりやすい例です。本記事執筆時点で公開されている値は次のとおりです。

注目すべきは適用単位が項目ごとに違う点です。1日あたりの上限は「1アプリあたり」なので、連携するアプリが複数あればそれぞれに10,000リクエストの枠があります。一方、同時リクエスト数は「1ドメインあたり」なので、こちらは環境全体で共有されます。並列処理でアプリをまたいで高速化を図ると、アプリ単位の枠には余裕があるのに、ドメイン単位の同時接続数で頭打ちになります。

超過時の挙動も、項目によって異なります。1日あたりの上限を超えた場合は、cybozu.com のストア管理者宛に警告メールが送信されますが、リクエスト自体が即座にエラーになるわけではありません。ただし継続的に超過し、他の利用者の環境に重大な影響を及ぼす場合は、API処理が中断されることがあるとされています。また、リクエスト数の集計は日本時間の毎朝9時にリセットされ、集計期間は9:00〜翌8:59です（cybozu developer network: kintone APIリクエスト数の超過メールが届いたら？）。一方、同時接続数が100を超えた場合は、REST API の実行時に 429 が返ります（cybozu developer network: kintoneの性能Vol.2 - 同時リクエスト数）。

つまり同じサービス内でも、「警告メールだけで処理は通る制限」と「その場で 429 になる制限」が併存しています。制限の種類ごとに超過時の挙動が違うという事実は、仕様書を読むときの重要な観点です。

生成AI・LLM API のレートリミット（RPMとTPM）

生成AIのAPIは、レートリミットの構造が kintone とかなり異なります。共通する特徴は次の3点です。

第一に、契約ティア（利用実績に応じた段階）によって上限が変わります。OpenAI・Anthropic ともに、累計利用額などに応じてティアが上がり、上限も引き上げられる仕組みを採っています。したがって「このAPIの上限は◯◯です」という言い方は正確ではなく、「現在の自社のティアでは◯◯です」が正しい表現になります。

第二に、複数の指標が独立して効きます。OpenAI は RPM・TPM・RPD・TPD を、Anthropic は RPM・ITPM（入力トークン毎分）・OTPM（出力トークン毎分）をそれぞれ別々に適用しており、どれか一つでも超えれば 429 になります。

第三に、前述のとおり実質的な制約は多くの場合トークン側にあります。長文を扱う用途では、回数制限に余裕があってもトークン制限で先に止まります。

発注時の確認としては、「どのティアで契約する前提の見積か」「ティアが上がるまでの期間、業務は成立するか」を押さえておく必要があります。稼働直後は最も低いティアからのスタートになるため、想定した処理量が初月から出せないケースがあるからです。なお、トークン量は制限であると同時に課金額そのものでもあります。予算面の整理についてはLLM APIの利用量と課金もあわせてご覧ください。

API仕様書で確認すべき5項目

サービスごとに書き方は違いますが、確認すべき論点は共通しています。API仕様書のレートリミットの節を読むときは、次の5項目を埋める形で読み進めてください。この5項目が埋まらない仕様書は、ベンダーに質問すべき箇所が残っていると判断できます。

特に見落とされやすいのが2の「カウント対象」です。一括登録API（複数件をまとめて送るAPI）が1リクエストとして数えられるなら、1,000件の登録は工夫次第で数十リクエストに圧縮できます。逆に件数分カウントされる仕様なら、その工夫は効きません。この一点で必要な設計がまったく変わるため、必ず確認してください。

自社の想定リクエスト数を概算する手順

最後に、提案書の制限値が足りるかどうかを自分で判断する手順です。厳密な計算は不要で、桁が合っているかを確認することが目的です。

手順1: 対象データの件数を洗い出す

連携対象のレコード件数を業務ごとに書き出します。「顧客マスタ 8,000件」「日次の受注データ 平均300件・繁忙期 1,200件」といった粒度で構いません。ここで平常時と最大時の両方を書くことが重要です。

手順2: 同期の頻度を掛ける

その件数が1日に何回同期されるかを掛けます。1日1回の夜間バッチなら1倍、1時間ごとなら24倍です。リアルタイム連携の場合は、1件の発生ごとにリクエストが1回発生すると考えます。

手順3: 一括処理による圧縮を考慮する

一括APIが使えて、かつ1リクエストとしてカウントされる仕様なら、件数を1回あたりの上限件数（100件など）で割ります。使えない場合はこの手順を飛ばします。

手順4: 制限値と突き合わせる

得られた数字を、仕様書の1日あたり上限・1分あたり上限の両方と比べます。ここで注意したいのは、1日の上限に対しては十分でも、処理が短時間に集中していれば1分あたりの上限には収まらないことです。夜間バッチの実行時間を考慮し、「1分あたり何件流れる想定か」も計算してください。

たとえば、繁忙期に1,200件の受注データを1件ずつ登録し、それを30分のバッチ枠で処理する場合、平均すると1分あたり40件です。「1分あたり60リクエスト」という制限値に対しては一見余裕がありますが、処理が均等に分散する保証はなく、冒頭に集中すれば超過します。平均値で余裕があることと、瞬間的に超えないことは別問題です。この余裕の少なさに気づけたなら、それがベンダーへの質問になります。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

レートリミットを前提にした実装・運用の設計パターン

ここまでで「何が起きるか」「自社の数字はどれくらいか」が整理できました。次は、APIを呼び出す側が取れるレート制限の対策を4系統に整理します。ベンダーが言う「レートリミットには対応済みです」の中身は、基本的にこの4系統のいずれか（または組み合わせ）です。どこまでを実装範囲としているかを確認する材料として読んでください。

なお、ここで扱うのは外部APIを呼び出す側の対策です。自社が提供するAPIに対して制限をかける側の仕組みについては、API Gatewayの解説をご覧ください。

リトライ設計（指数バックオフ・ジッター・冪等性）

最も基本的な対策が、失敗したリクエストを後で再試行するリトライです。ただし「失敗したらすぐ送り直す」という素朴な実装では、かえって状況を悪化させます。

指数バックオフは、再試行の待ち時間を1秒、2秒、4秒、8秒と指数関数的に伸ばしていく方式です。相手のサーバーが混雑しているときに間隔を空けることで、回復の余地を与えます。ここにジッター（待ち時間へのランダムなばらつきの付与）を加えると、複数の処理が同時に失敗した場合でも再試行のタイミングが分散し、同じ瞬間に一斉に再送されて再び弾かれる事態を避けられます。この組み合わせは分散システムの標準的な作法として知られています（AWS Architecture Blog: Exponential Backoff And Jitter）。加えて、前述の Retry-After ヘッダーが返る場合は、その値を優先して待機するのが最も確実です。

リトライで見落とされやすいのが冪等性（べきとうせい）の担保です。冪等性とは「同じ操作を何回実行しても結果が変わらない」という性質を指します。たとえば、リクエストは相手に届いて処理されたのに、応答が返ってくる途中で通信が切れた場合、呼び出す側からは失敗に見えます。ここで単純に再送すると、同じ注文が二重に登録されます。これを防ぐには、リクエストごとに一意の識別子を付けて、相手側が重複を検知できるようにする、あるいは登録前に既存データの有無を確認するといった作りが必要です。

発注側の確認としては、「リトライは実装されているか」だけでなく「二重登録は防げるか」までを聞いてください。前者だけの回答なら、リトライが正常に動いた結果としてデータが重複するリスクが残ります。

キューと流量制御でリクエストを平準化する

リトライが「失敗した後の対処」であるのに対し、そもそも上限を超えないように送るのが流量制御です。

処理すべきリクエストをいったんキュー（待ち行列）に入れ、そこから一定のペースで取り出して実行します。1分あたり60リクエストが上限なら、1秒に1件ずつ取り出すよう調整すれば、原理的に上限を超えません。並列処理を行う場合も、同時に動くワーカー（処理担当）の数を制限することで、同時実行数の上限を守れます。

この方式の利点は、処理の完了が保証されやすいことです。上限に達しても捨てられずキューに残るため、時間はかかっても最終的には全件が処理されます。前述の3つの失敗パターンのうち、最も避けたい「サイレントな欠落」を構造的に防げるのが大きな価値です。

一方で、キューの導入は仕組みとして一段複雑になります。キューに滞留した件数の監視、処理が終わらない場合の打ち切り判断、再起動時の状態復元といった考慮事項が増えるためです。「大量データを扱うのにキューがない」設計は要注意ですが、逆に少量のリアルタイム連携にキューを入れるのは過剰とも言えます。業務量に見合った選択がされているかという観点で見てください。

キャッシュ・バルクAPI・差分同期で呼び出し回数を減らす

3つ目は、リクエストの数そのものを減らすアプローチです。上限に対する余裕を根本的に増やせるため、効果が大きい割に見積では見落とされがちな領域です。

特に効果が大きいのが、下2つです。毎晩8,000件の顧客マスタを全件同期している処理を、変更分のみ（1日あたり数十件）に切り替えれば、リクエスト数は2桁減ります。また、5分ごとに「新しいデータはないか」と問い合わせるポーリング処理は、1日あたり288回のリクエストを消費しますが、そのほとんどは「変更なし」という応答です。相手がWebhook（変更時にこちらへ通知を送る仕組み）に対応していれば、この無駄をまるごと削減できます。

見積の中に「全件同期」という言葉を見つけたら、差分同期にできないかを確認する価値があります。

監視・アラートと上限緩和申請の運用

最後は、稼働後の運用に関する対策です。ここが抜けていると、対策1〜3を実装していても問題の発生に気づけません。

残量の記録: 前述の X-RateLimit-Remaining のようなヘッダーを定期的に記録し、使用率の推移を追えるようにします。「上限の何%を使っているか」が見えていれば、業務量の増加に対して余裕がいつ尽きるかを事前に予測できます。

429 発生率のアラート: 429 が発生した回数を計測し、一定の閾値を超えたら担当者に通知します。リトライで最終的に成功していても、429 が増えているなら上限に近づいているサインです。成功したかどうかだけでなく、何回失敗して成功したかを見るのがポイントです。

失敗レコードの追跡: リトライしても最終的に処理できなかったデータを、確実に記録して人が確認できる状態にします。ここが用意されていないと、サイレントな欠落が発生します。

上限緩和の申請: 業務拡大により恒常的に上限に近づいた場合、プラン変更や申請によって上限を引き上げられるサービスがあります。ただし申請から反映までに時間がかかることも、追加費用が発生することもあります。誰がいつ判断して申請するのかを運用ルールとして決めておかないと、必要になってから慌てることになります。

発注時に確認すべきレートリミット設計のチェックポイント

ここまでの内容を、発注プロセスの各工程で使える確認項目に落とし込みます。技術的な正解を判定する必要はありません。質問して、回答が返ってくるかどうかを見るだけで、設計が検討されているかは判断できます。そのまま社内レビューやベンダーへの質問票に転記してお使いください。

なお、レートリミットはAPI連携案件で確認すべき論点のひとつです。連携先の認証方式・データ形式・障害時の切り分けなど、より広い範囲の確認事項はAPI連携の発注チェックリストにまとめています。

要件定義で決めておくこと

この段階で決めるべきは、技術仕様ではなく業務仕様です。ここを曖昧にしたまま設計に進むと、実装者が推測で決めることになります。

• 連携先APIの制限値（1分・1日・同時実行数）を洗い出したか。誰が確認したか
• ピーク時（月末・繁忙期・キャンペーン時）のリクエスト数を試算したか。平常時だけの試算になっていないか
• 上限に達したとき、業務としてどうするか。止める・遅らせる・件数を分割するのどれを選ぶか
• 遅延が許容される場合、何時間までなら業務が成立するか（例: 翌朝9時までに完了すればよい）
• 一部データが処理できなかった場合、誰にどう通知するか。手動で再実行する運用を許容するか
• 連携先の上限は、契約プランによって変わるか。現在の契約プランで足りるか

3番目の項目が最重要です。「上限に達したときの業務仕様」は発注側にしか決められません。ここを決めずに「エラーにならないようにしてください」とだけ伝えると、結果的に失敗を握りつぶす実装になる余地が生まれます。

見積で確認すること

対策には工数がかかります。見積に含まれていない対策は、後から追加費用になるか、実装されないまま納品されます。

• リトライ処理の実装が工数に含まれているか。指数バックオフ・Retry-After への対応まで含むか
• 冪等性の担保（二重登録の防止）が含まれているか
• キュー・流量制御の実装が必要な規模か。必要なら工数に含まれているか
• 監視・アラートの実装が含まれているか。それとも運用フェーズの別見積か
• 失敗レコードの記録と再実行の仕組みが含まれているか
• 上限に達した場合の追加対応（設計変更・上限緩和の申請支援）は、どこまでが見積の範囲内か

これらの項目名が見積書に一切現れない場合、「レートリミット対策はどの項目に含まれていますか」と質問してください。回答が明確でないなら、後から追加費用になる可能性が高い領域です。

受入テストで確認すること

レートリミットの問題は、平常時のテストでは絶対に検出できません。テスト計画にこの観点が入っているかを確認してください。

• 上限到達を意図的に再現するテストを実施するか。実施しないなら、その理由は何か
• ピーク時想定のデータ量（繁忙期の最大件数）でテストするか。少量データのテストで済ませていないか
• 上限に達したときの挙動が、要件定義で決めた業務仕様（止める・遅らせる・分割する）どおりか
• 失敗したレコードを追跡できるログが残るか。どこを見れば確認できるか
• リトライ後にデータが二重登録されていないかを検証するか
• 残量ヘッダーの記録・429 のアラートが、テスト環境で想定どおり動作するか

「上限到達のテストは、本番の連携先に負荷をかけるため実施できない」という回答もあり得ます。その場合は、テスト用環境の有無や、制限値を模擬した検証方法について代替案を確認してください。実施しないこと自体は問題ではなく、実施しないリスクを双方が認識していないことが問題です。

契約・運用で決めておくこと

稼働後に発生する変化への備えです。ここは技術ではなく分担の取り決めになります。

• 連携先APIの仕様変更・制限値変更があった場合、誰が検知し、誰が対応するか
• 制限値の変更に伴う改修は、保守契約の範囲内か、別途見積か
• 上限緩和の申請は、発注側とベンダーのどちらが行うか。費用負担はどちらか
• 外部サービス側の障害・制限で業務が停止した場合の責任分界点をどこに置くか
• 業務量が増加した場合の再試算を、いつ・誰が行うか（例: 年1回、または取引先が◯社を超えたとき）
• 監視アラートの通知先は誰か。休日夜間の対応をどうするか

3番目と4番目は、契約書の記載と実態が食い違いやすい部分です。外部APIの制限は自社にもベンダーにも制御できない要因であるため、「起きたときにどう動くか」をあらかじめ合意しておくことが、稼働後のトラブルを最小化します。

発注前から運用までのレートリミット確認フロー

最後に、ここまでの内容を時系列で整理します。それぞれの段階で「発注側が決めること」と「ベンダーが担うこと」を分けて示します。判断の主体を明確にすることが、設計漏れを防ぐ最も確実な方法です。

あわせて、実務で繰り返し起きる失敗パターンを3つ挙げておきます。いずれも、上の表のどこかが抜けたときに発生するものです。

失敗1: 平常時のデータ量だけでテストして、月末に落ちる

受入テストを100件程度のサンプルデータで実施し、問題なしとして本番稼働。最初の月末に1,200件の一括処理が走った瞬間に上限を超えて停止します。要件定義でピーク時の業務量を提示していれば防げた事象です。

失敗2: リトライはあるが冪等性がなく、二重登録が発生する

429 に対するリトライは実装されており、テストでも正常に動作していました。しかし通信断のタイミングで再送が走り、同じ受注データが2件登録されます。見積の段階で「二重登録の防止」を確認していれば防げた事象です。

失敗3: 監視がなく、欠落に気づけない

対策そのものは実装されていましたが、429 の発生状況を記録する仕組みがなく、業務量の増加によって上限に近づいていることに誰も気づきませんでした。ある日を境に一部のデータが同期されなくなり、発覚したのは3か月後の棚卸しでした。監視・アラートを見積に含めていれば防げた事象です。

レートリミットは、仕様書の片隅に書かれた小さな数字です。しかしその数字は、自社の業務量・処理のタイミング・対策の実装範囲という3つの要素と掛け合わさって、本番稼働後の安定性を左右します。逆に言えば、この3つを工程ごとに確認していけば、非エンジニアの立場でも設計の妥当性を十分に見極められます。まずは手元の提案書を開いて、連携先の制限値と自社のピーク時の件数を並べて書き出すところから始めてみてください。

関連情報

API連携を含むシステム開発の発注・要件定義について、確認項目や進め方をまとめた資料をご用意しています。お役立ち資料から無料でダウンロードいただけます。

外部API連携を含むシステムの発注をご検討中で、制限値の試算や要件の整理段階から相談したい場合は、お問い合わせフォームよりご連絡ください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。