kintone のバックアップを1年分持つと、容量はいくらになるのか

2026年10月5日

先に断っておきます。これは生成したデータによる試算で、顧客テナントの実測ではありません。 レコードの構造と更新のしかたを仮定して、実際に保存処理を回した結果です。 都合の悪い結果（重複排除がほとんど効かなかったこと）も、そのまま載せます。

なぜこれを調べたか

kintone のバックアップ製品は、だいたい保存容量で課金します。 200GB ごとにいくら、という形です。 一方で当社は容量で課金しない方針にしたので、 「それで本当に成り立つのか」を自分で確かめる必要がありました。 成り立たないなら、方針のほうを変えるべきだからです。

試算の結果

30万レコードのアプリを、毎日1世代ずつ365日ぶん保存した場合。 1日あたり0.5%のレコードが更新され、500件が追加される前提です。

1年分の世代を持って 6.5GB、ストレージ原価は月15円。 レコードデータは、思っているより桁違いに小さいです。

重複排除は、ほとんど効きませんでした

注目してほしいのは 削減率 -0.4% の行です。マイナスです。 重複排除を入れた意味がなかった、どころかわずかに増えています。

理由は保存の単位にあります。当社はレコードを1,000件のパックにまとめて、 パック単位でハッシュを取って保存しています。 パック内の1件が変わると、パック全体が書き直されます。 1日0.5%の更新が全体に散らばると、結局ほぼ全部のパックが毎日書き直される。 だから効かない。

一方、ほとんど更新されないマスタ系のアプリでは、はっきり効きます。

重複排除が効くかどうかは、アプリの性質で決まります。 「重複排除しているので容量が減ります」という説明は、半分しか正しくありません。

では、なぜ容量で課金しなくて済むのか

重複排除が理由ではありませんでした。実際の理由は2つです。

レコードデータの絶対量が小さい

30万件を365世代持っても 6.5GB。重複排除が効かなくても、原価は月15円にしかなりません。 削減する以前に、最初から小さい。

添付ファイルは世代数に比例しない

添付は fileKey が変わらない限り中身も変わらないので、 何世代取っても実体は1回しか保存されません。 添付50GBのテナントでも、ストレージ原価は月113円程度が上限です。

つまり容量は原価のボトルネックではない、というのが結論です。 実際に効いてくるのは別のところでした。

• 毎日すべてのレコードを取得する実行時間
• 顧客側の kintone API 日次予算（1アプリあたり10,000リクエスト）の消費量

2つ目が重要で、これはこちらのコストではなく、顧客のコストです。 バックアップのせいで顧客の業務カスタマイズが API 制限に当たったら、 製品として失格です。だから当社は1日に使うリクエスト数に上限を設けて、 取りきれない日は翌日に回す作りにしています。

この試算が外れるとしたら

正直に書いておきます。次の場合、上の数字は当てになりません。

• 1レコードが極端に大きい場合。 長文の複数行テキストや、行数の多いサブテーブルを持つアプリは、 この試算のレコード構造より重くなります
• 添付ファイルが毎日差し替わる運用。 fileKey が変われば別の実体として保存されるので、世代数に比例して増えます
• そもそも生成データであること。 実テナントのレコードは、ここで仮定したものより多様です

なので当社では、提案の前に実際のテナントで容量を実測しています。 試算を根拠に見積もりを出すことはしません。

自社の数字を知る

自社の kintone が実際に何GB使っているか、アプリは何本あるか、 コメントはどのアプリに溜まっているか——これらを無料で実測してお返ししています。 読み取り専用の API のみを使い、書き込みは一切行いません。所要は10分ほどです。 他社の公開価格表に当てはめた場合の年額も併せてお出しします。 当社のほうが高くなる規模であれば、そう申し上げます。

無料診断を申し込む

数字は当社の保存処理を生成データに対して実行した結果です（2026年10月5日実行）。 R2 のストレージ単価は $0.015/GB・月、為替は150円/USDで計算しています。 記載内容に誤りを見つけた場合は hello@tokimodoshi.com までご連絡ください。訂正します。 関連記事: 削除しても痕跡が残らない件 ／ 復元しても元どおりにはならない件 ／ API リクエスト枠の話 ／ アクセス権の変更に気づけるか