API 連携は、つながればOK ではない — 回数の壁・仕様変更・障害情報の見方

調査の詳細

このページの答えは、以下の調べで出しました。対象・確認時期・出典を並べます。

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

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

回数で公開（18件）— 実例

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

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

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

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

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

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

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

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

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

記載なし（28件）

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

書いていない例。

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

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

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

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

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

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

56件のうち、この調査で型を確かめられたシステムを並べます。

型を確かめたうえで、変更を知る経路を1つ確保してください。 誰も見ていない、という状態が一番まずいです。担当者が変わったときに購読が引き継がれないことがよくあります。

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

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

専用ページがある（22件）

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

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

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

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

お知らせ・メールで知らせる（25件）

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

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

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

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

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

上限に当たったとき、何が起きるか

設計の前に知っておくべきことがあります。上限を超えたときにどうなるかは、サービスによって違います。 エラーが返るだけ（多くは 429 Too Many Requests）、しばらく待てば通る、個別に連絡が来る／強制停止の可能性（マネーフォワード クラウド経費のエンタープライズは「無制限」だが、負荷次第で個別連絡や強制停止の可能性ありと明記）の3通りです。「無制限」と書いてあっても、無制限に呼び出してよい、という意味ではありません。そしてエラーが返ったあと、こちらの仕組みが何をするかを決めておく必要があります。4つの作り方（何もしない・すぐ再試行・待って再試行・記録して知らせる）は、上の「レート制限とは」のページの 2 節に置きました。

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

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

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

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

調査記録から: 経理・会計／人事・労務の「回数の壁・仕様変更・障害情報」を横に並べる

（この表は調査記録から機械で描いています。記号や札をクリックすると、編集部の総結と原文・出典が出ます。）

経理・会計

◎ 条件なしで当てはまる　○ 条件つき・一部　△ 限定・要申請・無いと明記　× 当てはまらないと明記　？ 編集部がまだ確認していません　― 提供元が公開していない（編集部が調べた）　— 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。

材料の調査日（最新）: 2026-09-03

人事・労務

◎ 条件なしで当てはまる　○ 条件つき・一部　△ 限定・要申請・無いと明記　× 当てはまらないと明記　？ 編集部がまだ確認していません　― 提供元が公開していない（編集部が調べた）　— 記号は編集部の札から機械で付けています。物差しは項目ごとに違い、列の見出しがその項目の意味です。札の意味と根拠は各セルの要約を押すと出ます。

材料の調査日（最新）: 2026-09-03

ここでの調査範囲について

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

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