kintone のバックアップは、API リクエスト枠をどれだけ食うのか

2026年10月5日

バックアップ製品の導入を検討する情シスの方が、最初に聞く質問はだいたいこれです。 「入れたことで、うちの本番に影響は出ませんか」 正当な質問です。バックアップは毎日、全レコードを読みにいくからです。 この記事では、実際にどれだけ枠を使うのか、何が起きるのかを数字で書きます。

まず、制限の正体

kintone の API リクエスト数には、アプリ単位の1日あたり上限があります。

1日のリクエスト数

1アプリにつき 10,000 件（スタンダードコース）。ワイドコースは 100,000 件。

集計期間

JST 9:00 〜 翌日 8:59。0時リセットではありません。 ここは誤解されやすい場所です。私も最初は0時で切り替わるものだと思っていました。

同時リクエスト数

1ドメインあたり 100。超えると HTTP 429 が返ります。 この枠は、顧客自身のカスタマイズや他の連携サービスと共有です。

上限を超えると、実際に何が起きるのか

ここも誤解していました。超えた瞬間にリクエストがエラーになるわけではありません。 公式の記載に沿って整理すると、起きるのは次の2つです。

1. 翌日9時ごろ、cybozu.com のストア管理者に超過メールが届きます。 つまり、気づくのは顧客の情シスです。
2. 公式は「他のユーザーの環境に重大な影響を及ぼす場合、API処理を中断することもある」としています。 常にではありませんが、止められる可能性はあるという建て付けです。

1つ目が重要です。業務が即座に止まらないとしても、 バックアップ業者が原因で、顧客の情シスに警告メールが飛ぶ。 これは障害より信用を削ります。 「データを守るために入れたものが、別の警告を出している」という状態になるからです。

では、バックアップは何リクエスト使うのか

レコードの取得は 1リクエストあたり最大500件です。 1万件のアプリなら20リクエスト。これは大したことがありません。 添付ファイルは1ファイル1リクエストなので、添付の多いアプリで増えます。

桁が変わるのはコメントです。 コメント取得 API には一括取得のエンドポイントがなく、 アプリとレコードを1件ずつ指定します。1リクエストで取れるのは最大10件。

レコード1万件のアプリは、コメントまで完全に取ろうとすると1日では終わりません。 3万件なら3日分の枠を使い切ります。 これは工夫で消せる種類の制約ではなく、API の形から来ています。

なぜコメントだけ差分が取れないのかは 別記事に書きました。 コメントの投稿も削除もレコードの revision を動かさないので、 「前回から変わったレコードだけ見る」という安上がりな方法が使えません。

だから、自分で上限を持つ

当社の実装では、kintone 側の上限に当たる前に自分で止まります。

1アプリあたりの1日の予算

既定 5,000 リクエスト。公式上限 10,000 の半分です。 残りの半分は顧客の業務のために空けておきます。テナントごとに変更できます。

同時実行数

既定 5。 ドメイン上限は 100 ですが、顧客のカスタマイズと共有する枠なので取りにいきません。

予算を使い切ったら

そのアプリの取得をその場で打ち切り、翌日の続きから再開します。 取れなかったレコードは前の世代の内容を引き継ぎ、 「今回は見ていない」という事実を世代に必ず記録します。

429 が返ってきたら

Retry-After を尊重して待ちます。指定が無い場合は指数バックオフ（最大30秒）。 連打しません。

夜間実行に失敗したら

自動リトライしません。次の晩に回します。 失敗の原因が枠の消費だった場合、リトライは火に油です。

最後の「今回は見ていない」の記録は、地味ですが外せません。 これを省くと、単に見ていないだけのレコードのコメントを「削除された」と報告します。 バックアップ製品が偽の消失アラートを出したら、その時点で誰にも信用されません。 当社の差分では「コメント0件」と「コメント未検出（標本n件）」を別物として扱っています。

実行時刻について

当社は夜間 2:30（JST）に実行します。集計期間が 9:00 始まりなので、 2:30 は「顧客が日中に使ったあとの残り枠」を使う時間帯です。

枠を多く取りたいだけなら、9:00 直後に回すほうが有利です。空の枠から始められるからです。 それを採らないのは、業務時間帯に負荷をかけることになるからです。 こちらが取りやすい時間より、顧客の業務が先に通る並びを選んでいます。

導入前に確認してほしいこと

どの製品を選ぶ場合でも、次の3点は契約前に聞いておくことをおすすめします。

• 1日に使うリクエスト数の上限を、製品側で設定できるか。 できないなら、枠は使い放題です
• 取り切れなかったとき、どう振る舞うか。 止まるのか、翌日に続けるのか、黙って欠落するのか
• 失敗時に自動リトライするか。 するなら、枠を焼き切る可能性があります

当社では、導入前に読み取り専用で実測しています。 アプリ数・レコード総数・添付の総容量・コメントが溜まっているアプリと件数に加えて、 毎日の取得にどれくらいのリクエストが必要になるかもお出しします。 所要は10分ほどで、書き込みは一切行いません。

無料診断を申し込む

API の上限値・集計期間・超過時の挙動は cybozu developer network の記載に基づいています（2026年10月時点）。仕様は変更される可能性があります。 記載内容に誤りを見つけた場合は hello@tokimodoshi.com までご連絡ください。訂正します。 関連記事: 削除しても痕跡が残らない件 ／ 復元しても元どおりにならない件 ／ 容量と原価の話 ／ アクセス権の変更に気づけるか