業務システム56件のAPI制限を調査 半数が上限非公開

Qiitaのsongchongの報道では、国内で利用される業務システム56件を対象に、API連携の設計と運用に直結する公開情報の実態が調査された。2026年9月1日に公開された同調査は、呼び出し回数の上限、仕様変更の告知方法、障害情報の公開、サポート窓口の有無を公式資料から1件ずつ確認したものだ。結論として、1分あるいは1日あたりの呼び出し上限を公開しているのは56件中28件にとどまり、残る半数は設計段階で許容頻度が把握できない状況が明らかになった。

「1分・1日あたりの呼び出し回数の上限を公開しているのは、56件中28件。ちょうど半分です」

この結果は、API連携が接続時点で完了するものではなく、継続的な保守を前提とする領域であることを示している。見積書における保守費の根拠についても、相手側の仕様変化と運用制約への対応という観点から再整理が求められる。

56件に見るAPI公開情報の全体像

調査では4つの観点が集計された。呼び出し回数の上限、仕様変更の告知、障害情報の公開、サポート窓口の有無である。結果は以下のとおりだ。

呼び出し回数の上限を公開しているのは28件で、全体の半数に相当する。仕様変更の告知は何らかの形で確認できたものが40件、障害情報の公開は51件、サポート窓口の記載は55件であった。裏返せば、呼び出し上限が確認できないものが28件、仕様変更の告知手段が確認できないものが16件、障害情報の出し方が確認できないものが5件存在する。

同調査は「記載なし」を「制限や障害が存在しない」ことと同義ではないと明確に定義している。公開資料から確かめられなかったという事実を示す区分であり、非公開領域が設計時の不確実性として残る点に注意が必要だ。

内訳はさらに細分化されている。呼び出し上限については「回数で公開」が18件、「回数以外の単位」が4件、「契約で決まるとだけ記載」が6件、「記載なし」が28件であった。仕様変更の告知は「廃止日が決まる」が4件、「追う手段がある」が10件、「追う手段がない」が26件、「記載なし」が16件。障害情報は「専用ページがある」が22件、「全体ページに含まれる」が4件、「お知らせ・メール」が25件、「記載なし」が5件という構成だ。いずれの区分でも、情報の粒度と追跡可能性に大きな差がある。

呼び出し上限は単位も条件も不統一

APIのレート制限は、短時間に大量のリクエストが集中することによるサーバー負荷を防ぐための速度制限である。上限を超えた場合、HTTPステータスコードの429 Too Many Requestsが返却されることが一般的だ。429は呼び出し頻度が過多であることを示す合図であり、開発現場では原因切り分けの起点となる。

今回の調査で「回数で公開」に分類された18件についても、単位は統一されていない。Qiitaのsongchongの報道で示された具体例を見ると、ばらつきの大きさが分かる。

boardは1日3,000リクエスト、1秒あたり3リクエスト、リスト取得APIの同時リクエスト4までという複合的な上限を設け、上限緩和には対応しないと明記している。Google WorkspaceはAPIや操作ごとに上限が異なり、Directory APIのデフォルトはプロジェクトごとにユーザーあたり毎分2,400クエリとされる。SmartHRはアクセストークンごとに1時間5,000回かつ1秒10回、サブドメインごとに1分50,000回という多層の制限を設け、残り回数はレスポンスヘッダーで確認できる仕組みを提供する。

マネーフォワード クラウド経費はプラン別に上限を設定し、チームが1時間300回、コーポレートが1時間3,600回、エンタープライズは無制限としつつも負荷に応じた個別連絡や強制停止の可能性に言及している。HubSpotは公開配布のOAuthアプリで導入先アカウントごとに10秒あたり110リクエスト、日次でアカウントあたり250,000から1,000,000とし、追加購入による引き上げが可能だ。Salesforce Sales Cloudは24時間の総枠がエディションとライセンス数で決定される方式で、Enterpriseでライセンス15の場合100,000に15×1,000を加えた115,000が上限となる。20秒以上かかる同時リクエストは本番環境で25までという制約も併記されている。

一方で、Zoho CRMは回数ではなくクレジット制を採用し、24時間単位で無料版5,000、有償版50,000にユーザー数比例分を加算する。Shopifyは回数ではなく処理の重さで制限するleaky bucket方式を採用し、GraphQLでは1回あたり上限1,000ポイント、大量処理は上限対象外のBulk operationsを用いる設計としている。

「全部違います。つまりサービス同士の上限値を、数字の大小で単純に比べることはできません」

この指摘が示すとおり、1日、1秒、1分、10秒、24時間、クレジット、ポイントといった異なる分母が混在するため、単純な数値比較は成立しない。設計時には各サービスの定義を個別に読み解く必要がある。

さらに「契約で決まるとだけ」に分類された6件は、プランやエディションで決まると記載されるのみで具体的な数値が公開されていない。契約後に初めて上限が判明する構造は、見積もりや処理設計の精度に直接影響する。

上限の引き上げ可否もサービスごとに異なる。HubSpotは追加購入で引き上げ可能、boardは上限緩和に対応しないと明記、Google WorkspaceはWorkspaceアカウントごとの上限は引き上げ不可としている。公開されている数値が固定値なのか、交渉や課金で変動し得るのかという点も、運用計画に含めて確認すべき要素だ。

仕様変更と障害情報の公開実態

仕様変更の告知については、4段階に区分された。最も保守計画が立てやすいのは「型1 廃止日が決まる」に分類された4件で、日付や版で区切りが示され、いつまでに対応すべきかが明確だ。次に「型2 追う手段がある」の10件は、更新履歴やRSS、GitHubなどで変更を検知する経路が用意されている。

一方で最多となった「型3 追う手段がない」の26件は、方針や版の表記はあるものの、変更を追う具体的な手段が仕様書から判別できない。「記載なし」の16件は、変更頻度や告知方法自体が公開資料で確認できないものだ。半数近くが能動的に追跡しにくい状態にあることは、連携後の保守負荷を押し上げる要因となる。

障害情報については、状況がやや異なる。専用ページを公開しているものが22件あり、APIを独立した項目として掲載する例も含まれる。サービス全体のダッシュボードの一部として提供されるものが4件、お知らせ欄やメールで通知する運用が25件であった。専用ページを持たない後者の場合、機械的な監視や自動検知の組み込みが難しく、運用側でのポーリングや手動確認に依存する場面が生じる。公開資料で障害情報の出し方が確認できないものは5件であった。

サポート窓口については55件で記載が確認され、ほぼ全てのサービスで問い合わせ経路自体は用意されている。ただし窓口の有無と、レート制限や仕様変更に関する詳細情報の公開度は必ずしも連動しない。

保守費の根拠と設計時の留意点

同調査は、連携後に発生する事象を3つに整理している。回数の壁に当たる、仕様が変わる、相手のシステムが止まるという3点だ。Qiitaのsongchongの報道では、このうち「相手のシステムが落ちる」ことを障害と定義し、安定性という物差しの中での壊れ方として位置付けている。

それぞれに対する対応は異なる。回数の壁については、呼び出し頻度の設計、再試行の間隔、キューイングやバッチ分割といった制御が求められる。仕様変更については、廃止予告の監視、バージョン移行の計画、互換性維持のための改修が必要になる。障害については、相手側の稼働状況の把握、リトライやフォールバック、利用者への通知といった運用設計が問われる。

いずれも一度構築して終わる作業ではなく、相手側の変更と障害を前提とした継続的な対応が不可欠だ。調査結果が示すように、上限の単位が不統一で、告知手段や障害ページの有無にもばらつきがある環境では、設計前に公開情報を精査し、不明点は契約条件として確認する工程が重要になる。見積もりにおける保守費は、こうした不確実性への備えと、変更検知から改修、検証、展開までの一連の作業に対する費用と捉えることが適切だ。

公開情報が乏しい領域では、実装後の試行で初めて制約が判明する事態も起こり得る。429エラーの発生条件や、ヘッダーでの残り回数提示の有無、引き上げ可否といった運用面の情報は、公式資料に加えて検証環境での挙動確認を通じて補完する必要がある。仕様変更の追跡についても、RSSや更新履歴の有無だけでなく、通知の粒度や廃止までの猶予期間を事前に把握しておくことが、保守計画の精度を高める。

編集部の見解

短期的には、API連携の見積もりと設計プロセスにおいて、レート制限と変更告知の公開度を評価項目として明文化する動きが広がると見る。56件中半数で上限が非公開という事実は、工数算定の不確実性を直接押し上げる。3から6か月の間では、提案段階での公開情報チェックリストの整備や、契約前の上限確認を必須化する開発組織が増えると評価できる。

長期的には、業務システム側の情報公開の標準化が進むかどうかが焦点になると考える。単位の不統一や告知手段のばらつきは、利用者側の個別対応を強いる構造だ。1から3年の視点では、専用ステータスページや変更履歴の機械可読な提供が競争上の要素となり、公開姿勢が選定基準に影響する可能性があると見る。

編集部からの問いとして、利用者側はどこまでを事前調査で担保すべきかという論点がある。公開情報が乏しい場合に、契約条件として上限や猶予期間の明記を求めるのか、実装側で制御と監視を厚くするのかという選択だ。保守費を固定的な費用と捉えるのではなく、相手側の変化を吸収するための運用設計費として再定義することが問われていると言えそうだ。

参考

• 「API連携、つながればOK？ 回数の壁・仕様変更・障害情報を業務システム56件で調べてみた」, by songchong — Qiita, 2026-09-01T19:08:55.000Z (ARR)
• 元記事URL: https://qiita.com/songchong/items/1a599320ecb21cc4dd05?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items