API連携、つながればOK？回数の壁・仕様変更・障害情報を業務システム56件で調べてみた

Last updated at 2026-09-01Posted at 2026-09-01

「一度作ってしまえば、あとは自動で動き続けますよね」

連携の話をすると、だいたいこう言われます。そして見積書の「保守費」の欄を見て、「何を保守するんですか」と聞かれます。

保守するものは、あります。 相手のシステムが変わるからです。

日本の業務システム56件について、呼び出し回数の上限・仕様変更の告知の仕方・障害情報の公開・サポート窓口を、公式資料から1件ずつ調べました。

結論から書きます。

1分・1日あたりの呼び出し回数の上限を公開しているのは、56件中28件。ちょうど半分です。
仕様変更の告知は40件、障害情報の公開は51件、サポート窓口は55件で確認できました。

残り半分は、どれだけの頻度で呼び出してよいのかが設計前に分かりません。 これが見積もりの精度を左右します。

3つとも、いちばん大きいか2番目に大きいのが「分からない」です。 それぞれの区分の意味は次のとおりです。以降の本文も、この言葉で通します。

回数の壁	件	意味
回数で公開	18	「1日3,000回」のように、回数と時間の単位で上限が出ている
回数以外の単位	4	回数ではなくクレジットや処理の重さで測る。他社と数字を比べられない
契約で決まるとだけ	6	「プラン別」「エディション次第」とあるが、具体的な数値は出ていない
記載なし	28	公開資料に上限の記載が見つからない

仕様変更の告知	件	意味
型1 廃止日が決まる	4	日付や版で区切り、いつまでに直せばよいかが分かる。保守の計画が立つ
型2 追う手段がある	10	更新履歴・RSS・GitHub など、変更に気づく経路が用意されている
型3 追う手段がない	26	方針や版の表記はあるが、変更を追う手段が仕様書からは分からない
記載なし	16	変更の頻度も告知の方法も、公開資料には見つからない

障害情報	件	意味
専用ページがある	22	稼働状況の専用ページを公開。APIを独立した項目で出している例もある
全体ページに含まれる	4	製品単独ではなく、サービス全体のダッシュボードの一部として出る
お知らせ・メール	25	専用ページは無いが、お知らせ欄やメールで知らせる運用。機械的な監視はしにくい
記載なし	5	障害情報の出し方が、公開資料には見つからない

「記載なし」は「制限や障害が無い」という意味ではありません。 公開資料から確かめられなかった、という意味です。

総論の記事では、連携を作った後に起きることを3つ（回数の壁・仕様が変わる・止まる）挙げるところまで書きました。この記事は、その3つを56件の公式資料で数え、保守費が何に対する費用なのかを確かめます。

1. 作った後に起きることは、3つです

何が起きるか	具体的には
① 回数の壁に当たる	呼び出しすぎて弾かれる
② 仕様が変わる	相手のAPIが変更・廃止される
③ 止まる	相手のシステムが障害で落ちる

言葉を揃えておきます。総論の記事で**「安定性」と呼んだ物差しの中身が「壊れ方」（何がきっかけで止まるか）＝この3つで、そのうち③の「相手のシステムが落ちる」ことを障害**と呼びます。

この3つに対して、こちらがやることはそれぞれ違います。順に見ます。

2. ① 回数の壁 — 単位がバラバラです

APIには呼び出し回数の上限（レート制限）があります。短い時間に大量の要求が集中するとサーバーが落ちるので、提供側が自衛のために設けている速度制限です。

なお本記事では、APIに1回データを求めることをリクエスト（呼び出し）と書きます。サービスによっては同じものをクエリと呼びます。

上限を超えると、多くの場合 429 Too Many Requests（要求が多すぎます）というエラーが返ります。429はHTTPの状態を表す番号のひとつで、「呼び出しが多すぎるので一時的に断った」という意味です。この数字は覚えておくと便利で、開発者から「429が出た」と報告されたら、回数の問題だとすぐ分かります。

2-1. 回数で公開（18件）— 実例

システム	公開されている上限
board	3,000リクエスト/日（リセットはUTC）・3リクエスト/秒・リスト取得APIの同時リクエスト4まで。「上限緩和には対応していません」
Google Workspace	API・オペレーションごと。Directory APIのデフォルトはプロジェクトごとにユーザーあたり毎分2,400クエリ。Workspaceアカウントごとの上限は引き上げ不可
SmartHR	アクセストークンごとに1時間5,000回・1秒10回、サブドメインごとに1分50,000回。残りの回数はレスポンスヘッダー（応答に添えて返ってくる管理情報）で確認できる
マネーフォワードクラウド経費	プラン別。チーム 300回/時間、コーポレート 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	回数ではなく「1回の処理の重さ」で制限（leaky bucket＝一定の速さで水が抜けるバケツにたとえた方式）。GraphQL（欲しい項目だけを指定して取る通信方式）は1回あたり上限1,000ポイント。大量処理は Bulk operations（上限対象外）

2-2. 回数以外の単位（4件）— そもそも単位が揃っていません

上の表を見比べてください。1日・1秒・1分・10秒・24時間・クレジット・ポイント。 全部違います。

つまりサービス同士の上限値を、数字の大小で単純に比べることはできません。 「boardは3,000でSmartHRは5,000だから…」という比較は成立しません。分母が違うからです。

2-3. 契約で決まるとだけ（6件）と、引き上げられるか

6件は「プラン別」「エディション次第」とあるだけで、具体的な数値が出ていません。 契約してみるまで、どれだけ呼び出せるのかが分かりません。

そして数値が出ている場合でも、増やせるかどうかは別の問題です。

もう1つの軸があります。上限を上げられるのかです。

HubSpot：追加購入で引き上げ可能
board：「上限緩和には対応していません」と明記
Google Workspace：Workspaceアカウントごとの上限は引き上げ不可
マネーフォワードクラウド経費：プランを上げれば増える

「上限に当たったらどうするか」を、設計の段階で決めておく必要があります。 上げられないなら、そもそも上限内に収まる設計にするしかありません。

2-4. 記載なし（28件）

そして、ここが本題です。56件中28件は、回数の上限が公開資料からは確認できませんでした。

書いていない例。

freee会計：仕様上は429エラーの定義だけがあり、上限値の記載はなし
jGrants：APIドキュメントにもOpenAPI仕様ファイルにも、レート制限の記載は無い

「書いていない＝制限が無い」ではありません。 freee会計は429エラーを定義しているので、制限はあるが値が公開されていない状態です。

これが設計にどう効くか。「1日何件処理できますか」という問いに、開発会社は答えられません。 実際に呼び出してみるまで分からないので、見積もりに幅が出ます。 あるいは「上限に当たったら再試行する」という余計な作りが必要になります。

もう1つ。kintoneはライトコースではAPIが使えません（価格表で「—」）。回数以前に、プランで使えるかどうかが決まります。

3. ② 仕様が変わる — 告知の仕方が3通りあります

40件で仕様変更の告知について記述を確認できました。 中身は3つの型に分かれます（区分の意味は冒頭の表のとおり）。

型1 廃止日が決まる — 日付や版で切り、廃止日を明示する

一番ありがたい形です。いつまでに改修すればよいかを、前もって計画できます。

HubSpot：版が日付で切られ、提供終了日が決まる。新しい連携は最新の日付版を使うよう案内
Salesforce Sales Cloud：バージョン制（Spring/Summer/Winterの各リリースで新版）。各バージョンを初出から最低3年サポートし、廃止の1年以上前に通知。 廃止版を呼び出すと 410 GONE（この宛先はもう無くなりました、を表すHTTPの番号）が返る
Shopify：RESTからGraphQLへの移行が期日つきで告知されている。年2回、150以上の更新があるとベンダー自身が書いている

Salesforceの「最低3年サポート・廃止1年以上前に通知」は、稟議に書ける条件です。 保守の計画が立てられます。

Shopifyの「年2回、150以上の更新」も正直な情報です。 多いと感じるかもしれませんが、回数が分かっていることのほうが重要です。

型2 追う手段がある — 更新は頻繁でも、変更に気づける

freee会計：高頻度更新（GitHubに連日「Update schema files」のコミット）。仕様変更は開発者ポータルのRSSフィードでも告知
board：仕様書はバージョン1.9.0。「β版」等の不安定宣言はなし。新機能・変更は公式ブログの「更新履歴」カテゴリーで告知

freee会計のようにGitHubで仕様が公開されていると、差分が機械的に見られます。 これは設計図（OpenAPI＝APIの仕様を機械が読める形で書いた文書）が配布されていることの副次的な利点です。

型3 追う手段がない — 変更を仕様書からは追えない

SmartHR：spec の version 表示は 0.0.1 固定＝変更履歴は仕様書からは追えない（API専用のリリースノートページは別途存在）
kintone：公式仕様の版ディレクトリは1個のみ＝仕様本体は約15か月更新なし（＝安定している、とも読めます）

kintoneの例は解釈が分かれます。「更新されていない」は「安定している」とも読めます。 悪い意味ではありません。

実務でやること

型を確かめたうえで、変更を知る経路を1つ確保してください。

RSSフィードがあれば購読する（freee会計）
更新履歴のページがあればブックマークする（board）
リリースノートのメール通知があれば登録する

誰も見ていない、という状態が一番まずいです。担当者が変わったときに、購読が引き継がれないことがよくあります。

4. ③ 止まる — 障害情報を公開しているか

51件で記述を確認できました。 ただし中身に差があります（区分の意味は冒頭の表のとおり）。

ここでいうステータスページとは、いま正常に動いているか・障害が起きていないかを、提供側が公開している専用のページのことです。

4-1. 専用ページがある（22件）

システム	公開されているもの
kintone	稼働状況ページ（テナント単位）。メンテナンス・障害の告知はJSON APIでも取得可
freee会計	稼働状況ページ。「freee会計 \| API」などAPIを独立した項目として掲示し、過去のインシデント履歴も残る
board	専用ステータスページ。board Web／board API／お問い合わせ窓口の3系統を表示し、過去の履歴・メンテナンス予定・RSS購読を提供
Salesforce Sales Cloud	インスタンス単位（契約ごとに割り当てられたサーバー環境の単位）の稼働状況を公開（自社の環境名で検索できる）
e-Gov電子申請	稼働状況とメンテナンス情報を公開。休止予定も日時つきで告知

freee会計とboardが「APIを独立した項目として」表示しているのは重要です。 画面は動いているがAPIだけ落ちている、という状態があり得るからです。連携が止まったとき、画面を開いて「動いてますね」で終わらせないために、この区別が要ります。

そしてboardのステータスページには、こう書かれています。

「ステータスの更新は、自動連動ではなく、担当者が状況を確認の上更新しています」

これは誠実な記述だと思います。リアルタイムではないことを、先に言っているからです。

4-2. お知らせ・メールで知らせる（25件）

SmartHR：専用の稼働状況ページは存在しない（status.smarthr.jp はアプリ本体へリダイレクト）
マネーフォワードクラウド会計：専用の稼働状況ページは存在しない

無い＝障害情報を出していない、ではありません。 お知らせ記事やメールで告知される運用のことがあります。ただし機械的に監視する手段が無いという意味では、設計に影響します。

4-3. 全体ページに含まれる（4件）

製品ごとの専用ページは無く、サービス全体のダッシュボードの一部として出る型です。Google 系の4件（Google Classroom・Google Workspace・Google スプレッドシート・Google フォーム）がこれに当たります。

稼働状況は分かりますが、「その製品だけが落ちている」かどうかは読み取りにくいという点で、専用ページとは別に数えています。

4-4. 別ドメインにあって気づけないことがあります

board のステータスページは、本体サイトとは別のドメインにあり、本体のサイトマップにも載っていません。 フッターの導線から辿って初めて見つかります。

本体ドメインを検索しただけでは「無い」に見えます。 実際、編集部も最初はそう見えました。

探し方：本体ドメインで見つからなくても、status.<サービス名> のようなドメインや、フッターのリンクを確認してください。

4-5. 上限に当たったとき、何が起きるか

設計の前に知っておくべきことがあります。上限を超えたときにどうなるかは、サービスによって違います。

エラーが返るだけ（多くはこれ。429 Too Many Requests）
しばらく待てば通る（時間の枠がリセットされる）
個別に連絡が来る／強制停止の可能性（マネーフォワードクラウド経費のエンタープライズは「無制限」だが、負荷次第で個別連絡や強制停止の可能性ありと明記）

3番目があることは覚えておいてください。 「無制限」と書いてあっても、無制限に呼び出してよい、という意味ではありません。

そしてエラーが返ったあと、こちらの仕組みが何をするかを決めておく必要があります。

作り方	起きること
何もしない	そのデータは流れないまま終わる（気づかない）
すぐ再試行する	さらに上限を消費する（悪化する）
少し待って再試行する	通ることが多い（これが推奨される作り）
記録して人に知らせる	気づける

「何もしない」が一番危険です。 エラーが起きたことに誰も気づかず、データが片方にだけ入っている状態が残ります。あとで突き合わせたときに初めて分かります。

見積もりを取るときに聞いてください。

「上限に当たったとき、どう動く作りになりますか。再試行しますか。誰かに知らせますか。」

この2つが入っていない見積もりは、安く見えます。 入れれば当然その分の工数が乗ります。初期費用を抑えた作りにするのか、止まらない作りにするのかを、自分で決めてください。

5. これが保守費の正体です

3つを合わせると、作った後にやることの一覧になります。

やること	頻度	誰が
回数の上限に当たっていないか見る	常時（監視）	作った人
仕様変更の告知を追う	随時	誰かが購読
告知が来たら直す	年数回	作った人
止まったときに気づく	常時（監視）	作った人
止まったときに問い合わせる	障害時	担当者

3行目が費用です。 Shopifyのように年2回・150以上の更新がある相手なら、追従の作業が定期的に発生します。Salesforceのように「最低3年サポート・廃止1年前通知」なら、3年に一度の大きな作業として計画できます。

見積書の「保守費」は、この作業の予約金です。「何を保守するんですか」と聞かれたら、この表を見せてください。

5-1. 相場は書きません

「保守費は開発費の○%が相場」という書き方をしたくなりますが、書きません。調べていないからです。

そもそも連携の開発費そのものに公開価格が存在しないので、その割合にも公開価格はありません。

書けるのは構造だけです。相手の仕様が変わるから、こちらも直す。それが毎年かかる。

6. 契約前に聞く4つ

1. 呼び出し回数の上限はいくつですか。単位は何ですか

28件は公開されていません。公開されていない場合は必ず聞いてください。

2. 上限は引き上げられますか

「対応していません」と明記している例（board）があります。上げられないなら、設計で収めるしかありません。

3. 仕様変更はどうやって告知されますか。旧版はいつまで使えますか

RSS／リリースノート／メールのどれかがあるかを聞きます。「最低○年サポート」と答えられるなら、保守計画が立ちます。

4. 障害情報はどこで見られますか。APIの稼働状況は分かりますか

画面とAPIを分けて表示しているか、を聞いてください。

7. まとめ

作った後に起きるのは3つ（回数の壁／仕様変更／障害）
回数の上限を公開しているのは28/56。ちょうど半分
単位がバラバラ（1日・1秒・1分・10秒・クレジット・ポイント）なので、サービス同士を単純比較できない
上げられるかが実務では効く。「上限緩和には対応していません」と明記する例もある
仕様変更の告知は40/56。**日付版＋廃止日明示（HubSpot）／最低3年サポート・1年前通知（Salesforce）／年2回150件（Shopify）**のように、読める形で出す系統がある
障害情報は51/56。APIを独立して表示している例（freee会計・board）は、連携の監視で効く
これらが保守費の正体。 相手が変われば、こちらも直す

「作って終わり」ではありません。
ただし、告知の仕方が読める相手なら、いつ何をするかは計画できます。

この記事の調査範囲について

対象は、編集部が一次調査を終えて公開している56システムです。日本の業務システム全体ではありません。
確認時期は2026年7月28日〜8月19日です。上限も仕様も変わります。
「公開資料に記載が無い」と「制限が無い」は別です。 28件は前者です。
稼働率（SLA）の数字は書いていません。調べていないためです。
特定のシステムを「安定している／不安定だ」と評価していません。 調べたのは告知の仕方であって、実際の障害頻度ではありません。
仕様変更の頻度を体感で書いていません。 freee会計の「高頻度更新」はGitHubのコミット履歴で確認した事実、Shopifyの「年2回150件」はベンダー自身の記述です。
保守費の相場・目安は書いていません（連携の開発費に公開価格が存在しないため）。

各システムの「レート制限」「仕様変更」「障害情報」「サポート」の欄は RenkeiMap で1件ずつ、出典URLと調査日つきで公開しています。

調査対象の56システム（全件・公式ページ）

※ 一次調査を終えて公開している 56 件です。判断の元にした記述・出典URL・調査日は RenkeiMap に1件ずつ載せています。

【転載OK】本記事の転載について

本記事の文章・図表は、すべて転載 OK です。図は加工しないままお使いください。転載の際は、出典として renkeimap.jp もしくは本記事へのリンクをお願いします。事前の連絡は不要です。

※ 筆者は日立系ITベンダー・介護ソフトベンダー・大学病院IT部門を経て独立し、現在は中小企業のIT・DX支援をしながら、業務システムの「つながり」を一次資料で調べています。文中の「編集部」は、筆者が所属する IT連携マップ編集部のことです。誤りを見つけられましたら訂正窓口（無料・アカウント不要）へお願いします。訂正履歴も公開しています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

API連携、つながればOK？ 回数の壁・仕様変更・障害情報を業務システム56件で調べてみた