cybozu.comのディスク容量は「ユーザー数×5GB」（2026年4月時点）で計算できますが、この容量は多いようで少ないです。画像やPDFなどの添付ファイルを多用するアプリを運用していると、想定以上に早く容量の上限に達してしまう可能性があるためです。
そのため、kintoneで添付ファイルを利用するアプリを構築する場合、事前に先々の利用容量のシミュレーションをしておくことが無難です。アプリ稼働前に数カ月後・数年後のデータ増加量を見積もりしておくことで、容量不足への対応が必要となるおおよその時期が明確になりますし、あらかじめ対策を考慮したアプリを作成する、もしくはアプリとしては作らないほうが良いかも、という判断にもつなげられます。
本記事では、cybozu.com全体のディスク領域の考え方を図解し、容量消費の最大要因である添付ファイルの適切な管理手法（事前シミュレーション、変更履歴の設定、外部ストレージ連携など）を詳しくお伝えします。これを読めば、運用途中で慌てることなく、見通しを持った安全なkintone環境を構築できるようになります。
目次
図解でわかるkintoneディスク容量の仕組みと容量の試算
まず、kintoneを含む「cybozu.com」のディスク容量の仕組みと、なぜ事前のシミュレーションが必要なのかを説明します。
ディスク容量はcybozu.com全体に対してかかるもの
kintoneのディスク容量は、kintone単体に割り当てられているわけではありません。kintoneは「cybozu.com」という基盤上で動いており、サイボウズの各サービス（kintone・Garoon・サイボウズ Office・メールワイズ）共通で割り当てられています。
そのため、kintoneのみを利用しているならば「5GB × ご契約ユーザー数」をkintone単独でほぼ使用できると考えてよいですが、kintoneの他にサイボウズ Officeとメールワイズも使用している場合、3つのサービスで容量を分け合って使用する仕組みとなっているため、kintone単体で全容量を使えるわけではありません。
つまり、例えばkintoneで大容量のファイルを添付するとそこで容量を取ってしまうため、他のサービスの動作やデータ保存にも影響を及ぼす可能性があります。だからこそ、容量についてはkintoneの中だけの問題と捉えるのではなく、サイボウズのサービス全体としての考慮が必要なものであると認識する必要があります。
ディスク容量を構成する領域について
ヘルプページにも記載がありますが、ディスク使用量はで算出されています。
ディスク使用量＝添付ファイル領域 ＋ 監査ログ領域 ＋ データベース領域
この中で容量を一番使用しているのは、間違いなく添付ファイル領域です。データベース領域と監査ログ領域に対して容量を減らすような対応（保存期間を短くしたり、レコードを削除したり）もありますが、これはほぼ効果が無いと考えられえます。よって、ファイルの添付をいかに最小限にするか、もしくは、いかに削除して空きを確保するかを考えることが重要です。
アプリ構築前に数年分をシミュレーション
添付ファイルを扱うアプリを構築する際は、構築前に数年分の増加率をシミュレーションしてみることが大事です。
事前に行う理由は、数年後に容量上限に達するタイミングを予測し、事前に認識＆対応を行うためです。アプリが本格稼働してから容量不足の警告が出て慌ててデータを消そうとしても、日々の業務で使っている過去データをすぐに消すことは困難。あらかじめ行うとよいでしょう。
シミュレーションといっても、このように簡易的にざっくりと計算をしてみるだけでOKです。数字にしてみることで、現在の空き容量で何年耐えられるかが明確になります。もし1年後に上限に達すると分かれば、アプリ構築の段階で「外部ストレージ連携を組み込む」「1年経過したデータはバックアップして削除する運用ルールを作る」などの対策を考え、打つことができます。
まずは、これから作るアプリの月間増加量を計算し、見通しを立ててみましょう。
ディスクの空き容量を考慮したアプリ設計・運用のポイント
事前のシミュレーションで将来の容量増加ペースが把握できたら、次はいかに無駄な消費を抑えるかをアプリ設計に組み込みます。これらを構築時に考慮し設定しておくことで、将来の容量不足リスクを下げることができます。
「レコードの変更履歴」をオフにする
添付ファイルを頻繁に更新（差し替え）するアプリでは、「レコードの変更履歴」のチェックを外してオフにすることを検討したほうが良いです。なぜなら、レコードが更新されるたびに変更履歴として過去のデータが保持されるためです。
テキストデータであれば問題ありませんが、添付ファイルを差し替えた場合、過去のファイルも履歴として見えないところで容量を消費し続けます。 例えば、1MBのファイルを5回差し替えた場合、最新の1MBだけでなく、過去の4回分（4MB）も履歴として保存されています。
頻繁に提案書や図面などのファイルを差し替え更新するようなケースでは、シミュレーションで算出した概算ディスク増加量と合わせて、
- 最新の情報だけ見れればよいのかどうか
- 1つ1つの添付ファイルサイズが大きいかどうか
- 変更履歴を記録する必要があるかどうか
等を考慮したうえで、消費容量が多いと想定される場合は「レコードの変更履歴を記録する」のチェックは外したほうがよいでしょう。
添付ファイルを定期的にバックアップ/削除する
大容量のファイルを扱うアプリでは、一定期間経過したファイルを削除するという運用ルールを構築時から決めておくとよいでしょう。
バックアップ運用の一例
- 年に1回（または半年に1回）、対象となる古いレコードを絞り込む。
- 必要なファイルは、社内のファイルサーバー等へ一括ダウンロード（バックアップ）する。
- バックアップが完了したkintone上の添付ファイルを一括削除する。
マニュアルで行ったり、プラグインを使って一括ダウンロードしたり、バックアップ系のサービスを使用したりと、やり方は色々とありますので、自社の運用に合わせて選択をします。
外部ストレージ連携プラグインへ切り替える
シミュレーションの結果、数年以内に確実に追加容量が必要になると判明した場合、kintoneの添付ファイルフィールドを使うのではなく、最初から「外部ストレージ連携」を利用したアプリ構成を検討するとよいです。
kintoneのディスク増設オプションは毎月費用が発生し続けますが、すでに社内でBoxやDropboxなどのクラウドストレージを契約している場合やディスク増設オプションでは容量がそもそも足りない場合、クラウドストレージのほうがメリットが大きいからです。
以下のような要件がある場合は外部ストレージ連携したほうが、後々の容量問題を事前に対応できます。
kintoneと外部ストレージをつなぐ連携プラグインを活用すれば、kintoneの画面上から直接外部ストレージにファイルを保存・閲覧できます。kintoneのディスク容量を一切消費せずに、業務要件を満たすシステムを構築可能です。
参考：kintone容量問題が起きる前に！PDF編集×クラウド連携プラグイン構成例
事前の試算で「kintone標準の添付ファイルではデータ容量的に厳しい」と判断したなら、外部連携という選択肢を取り入れましょう。
kintoneで管理しない
BoxやDropboxなどの外部ストレージ連携ができるプラグインを利用するのも1つですが、そもそもとしてkintoneで管理しないということも選択肢の1つになります。kintoneの基本機能、例えばプロセス管理と組み合わせて使いたい、顧客情報と紐づけて管理したいといった要件が無いのであれば、無理にkintoneを使う必要はありません。別の方法を探すのが良いでしょう。
まとめ
kintoneのディスク容量不足は、日々の業務を突然停止させる重大なリスクをはらんでいます。本記事でお伝えしたポイントは次の通りです。
- cybozu.com全体の容量（5GB × ユーザー数）を把握し、アプリ構築前に数年先の増加率をシミュレーションする。
- 容量を圧迫する最大の要因である添付ファイルに対し、レコードの変更履歴オフや定期削除の運用ルールを設ける。
- 事前試算で不足が見込まれる場合は、外部ストレージ連携プラグインへの切り替えやディスク増設オプションの利用を検討する。
容量不足に陥ってから慌てるのではなく、事前の設計と見通しを持つことが大切です。本記事を参考に、添付ファイルを利用するアプリの見直しを行ってみてはいかがでしょうか。
