kintoneレコード数上限の考え方｜大量データで遅くしないアプリ設計

kintoneで業務アプリを作り始めると、途中で必ず出てくるのがレコード数の上限です。

案件が毎月増える。

問い合わせが毎日入る。

日報や作業実績が社員数分だけ増える。

在庫の入出庫履歴が積み上がる。

フォーム連携で申請や受付データが入り続ける。

ログアプリにAPI処理結果がたまる。

最初は数百件でも、1年、2年、3年と使うと、数万件、数十万件になります。

このとき、「kintoneは何件まで大丈夫か」だけを見ると判断を誤ります。

問題は、レコード数だけではありません。

• 一覧を開くたびに複雑な絞り込みをしている
• アクセス権が多く、表示対象の判定が重い
• フィールド数が多く、一覧に多くの列を出している
• テーブルに明細を詰め込みすぎている
• 添付ファイルが多く、1レコードの情報量が大きい
• グラフや集計を日常画面と同じアプリで作りすぎている
• 一括更新や外部連携が全件取得前提になっている
• 古いレコードをいつ退避するか決めていない

レコード数の上限を調べることは必要です。

ただし、実務で重要なのは「何件まで登録できるか」ではなく、「何件を、どの画面で、誰が、どの頻度で扱うか」です。

kintoneのレコード数設計では、上限値だけでなく、一覧・絞り込み・権限・フィールド数・API処理・退避方針をセットで決めます。

この記事では、kintoneのレコード数上限、100万件登録時の公式確認、動作が遅くなる原因、年間件数の見積もり、アプリ分割、アーカイブ、CSV/API、外部DBやBIに逃がす判断まで整理します。

kintoneデータベース設計はこちら
kintone集計の設計方法はこちら

先に結論：レコード数そのものに上限はない

kintone公式ヘルプの制限値一覧では、レコード数の上限はないと説明されています。

同じページでは、レコード数が多くなるとアプリの動作が遅くなる場合があり、表示やデータ処理の速度はアクセス権、絞り込み条件、フィールド数などの利用条件によって異なるとも説明されています。

また、アクセス権や絞り込みを設定していない1つのアプリに100万件を登録した状態で、登録や閲覧に問題なく使用できることを確認していると案内されています。

kintoneヘルプ：制限値一覧

つまり、読み方はこうです。

見るべき点	考え方
レコード数の上限	公式上は上限なし
100万件の確認	条件付きの確認であり、全アプリの保証ではない
遅くなる原因	アクセス権、絞り込み条件、フィールド数などで変わる
設計判断	件数だけでなく、画面・権限・処理の使い方で決める

「上限なし」は、1アプリに何でも入れてよいという意味ではありません。

実務では、次のような差が出ます。

アプリA	アプリB
10万件	10万件
フィールド20個	フィールド300個
テーブルなし	テーブルに明細多数
単純な一覧	複雑な絞り込み
権限が単純	レコード権限が複雑
APIは差分取得	APIが毎回全件取得

同じ10万件でも、体感や運用リスクは変わります。

「レコード数に上限はない」と「どんな設計でも軽く使える」は別です。件数ではなく、日常画面と処理条件を見ます。

上限なしでも遅くなる理由

kintoneが遅く感じる原因は、レコード数だけではありません。

主に次の要素が重なります。

要素	遅くなりやすい状態
一覧	表示列が多い、初期表示が全件に近い
絞り込み	条件が多い、対象レコードが広い
アクセス権	レコード権限やフィールド権限が複雑
フィールド数	1アプリに項目が多すぎる
テーブル	明細行が多く、検索や表示対象が増える
添付ファイル	レコードの確認に添付参照が多い
グラフ	大量レコードを毎回集計する
カスタマイズ	一覧表示時に大量処理を走らせる
API	全件取得、一括更新、同時実行が多い

kintoneヘルプでは、1つのアプリのフィールドは500個まで、テーブルは1つにつき10フィールドかつ100行までを目安にすること、テーブルのフィールド数や行数が多くなると表示速度、レコード操作、カスタマイズ、検索結果の表示に影響することが説明されています。

kintoneヘルプ：制限値一覧

このため、レコード数だけを見て「まだ上限なしだから大丈夫」と判断しない方がよいです。

たとえば、問い合わせアプリなら、1問い合わせ1レコードで10万件あっても、直近90日の未対応だけを日常一覧に出すなら扱いやすいです。

一方、1レコードに大量のテーブル明細、添付、コメント、権限、集計用フィールドが混ざっていると、数万件でも重く感じることがあります。

件数より一覧・権限・フィールド数を見る

レコード数が増えるアプリでは、最初に日常画面を分けます。

全件一覧を毎日開く設計は避けます。

画面	目的	設計例
日常一覧	今日見るレコード	未対応、今月、担当者別、期限切れ
管理一覧	棚卸しや確認	期間指定、状態指定、部署指定
検索用一覧	必要なときだけ探す	顧客名、管理番号、日付で絞る
集計用一覧	グラフや出力の前提	月次、年度、状態確定済み
退避候補一覧	古いレコードを見る	完了から1年以上、解約済みなど

初期表示は、特に重要です。

開いた瞬間に大量データを見せる一覧をデフォルトにすると、全員の操作が重くなります。

デフォルト一覧は、直近または未完了に寄せます。

業務	デフォルト一覧の例
問い合わせ	未対応、対応中、直近30日
案件	進行中、今月更新、担当者別
作業実績	今月、自分の実績、未承認
入出庫履歴	当月、商品指定、倉庫指定
申請	承認待ち、自分の申請、今月完了

アクセス権も見ます。

レコード権限が複雑になると、表示時の判定が増えます。

権限が必要な場合でも、次のように整理します。

方針	例
アプリを分ける	部門ごと、社外共有用、管理者用
レコード権限を単純にする	担当者、部署、状態で分ける
フィールド権限を絞る	原価、個人情報、内部メモだけに使う
一覧を役割別にする	担当者用、管理者用、経理用

kintoneセキュリティの設計方法はこちら

フィールド数も、使わない項目を持ちすぎない方がよいです。

Excel移行で列をそのまま持ち込むと、数百フィールドになりやすいです。

大量データアプリでは、入力・検索・集計に必要な項目を優先し、社内メモ、旧項目、集計補助項目、連携用項目は別アプリやログへ分ける判断も必要です。

年間件数からアプリ設計を決める

レコード数は、現在の件数ではなく、増え方で見ます。

次のように見積もります。

業務	件数の見積もり
問い合わせ	1日50件 × 営業日240日 = 年12,000件
日報	50人 × 月20日 × 12か月 = 年12,000件
作業明細	30人 × 1日10明細 × 240日 = 年72,000件
入出庫履歴	1日500件 × 300日 = 年150,000件
フォーム受付	月3,000件 × 12か月 = 年36,000件
APIログ	1日2,000件 × 365日 = 年730,000件

ここで見るのは、1年後、3年後、5年後です。

見積もり	判断
3年で数千件	1アプリで問題になりにくい
3年で数万件	一覧、権限、集計を設計する
3年で数十万件	アーカイブや分割を最初から考える
3年で100万件規模	外部DB、ログ基盤、BIも比較する

レコード数設計では、現在の件数ではなく、年間増加数と保存年数を掛けて、3年後の件数を見ます。

件数が多くなる業務では、1レコードの粒度も重要です。

粒度	特徴
1案件1レコード	管理しやすいが、明細集計には弱い
1問い合わせ1レコード	状態管理しやすい
1日報1レコード	人単位で見やすいが、作業明細がテーブルに閉じやすい
1作業1レコード	集計しやすいが件数が増える
1ログ1レコード	追跡しやすいが急速に増える

レコード数を減らしたいからといって、何でもテーブルに押し込むのは危険です。

テーブル内の明細は、検索、集計、権限、外部連携で扱いづらくなることがあります。

kintoneテーブル設計はこちら

アーカイブアプリとデータ保持期間

レコード数が増えるアプリでは、古いデータをどう扱うかを決めます。

すべてを現役アプリに残す必要はありません。

方法	向いているケース
現役アプリに残す	直近数年を頻繁に検索する
アーカイブアプリへ退避	完了済み、参照頻度が低い
CSVで保管	法定保管や監査用で、日常検索しない
外部DBへ連携	大量検索、横断集計、BIが必要
添付だけ外部ストレージ	ファイル量が多く、kintone画面で頻繁に見ない

アーカイブアプリを作る場合は、退避基準を決めます。

基準	例
状態	完了、失注、解約、対応済み
期間	完了から1年、受付から3年
利用頻度	最終更新から12か月以上
保管義務	契約、請求、証憑の保持期間
参照方法	管理番号で検索できるか

退避は、手動でも自動でもかまいません。

ただし、退避した後に困らないように、次を残します。

残す情報	理由
管理番号	現役データから追えるようにする
顧客コード	顧客単位で探せるようにする
完了日	退避条件を説明できるようにする
退避日	いつ移したかを残す
元アプリURL	必要に応じて参照できるようにする
添付の保管先	ファイルが行方不明にならないようにする

kintoneバックアップの設計方法はこちら

アーカイブは、単なる削除ではありません。

日常画面から外しつつ、必要なときに追える状態を作ることです。

CSV/API処理・一括更新・集計の注意点

大量データで問題になりやすいのは、画面表示だけではありません。

CSV、API、一括更新、集計も見ます。

kintoneヘルプでは、CSV、TSV、TXTファイルの読み込みは1ファイル100MBまで、行数は10万行までと説明されています。

また、ファイル書き出しは1ファイル100MBまでで、100MBを超えると書き出しに失敗するため、一度に書き出すフィールドやレコード数を減らすよう案内されています。

kintoneヘルプ：制限値一覧

REST APIでは、同時アクセス数は1つのドメインにつき100までで、上限を超えるとHTTP 429が返ると説明されています。

1日に実行できるAPIリクエスト数は契約コースによって上限が異なり、/k/v1/bulkRequest.jsonで複数APIを実行した場合は、それぞれがリクエスト数にカウントされます。

kintoneヘルプ：制限値一覧

このため、大量データ処理では次を決めます。

処理	設計すること
CSV取込	分割単位、事前検証、エラー時の戻し方
CSV書き出し	期間、フィールド、担当者、用途で分ける
API取得	差分取得、ページング、更新日時条件
API更新	対象件数、再実行、失敗ログ、同時実行数
集計	毎回全件集計か、集計値を保存するか
連携ログ	実行日時、件数、成功、失敗、再実行

kintone SIGNPOSTの性能上の考慮点では、定期的に大量のデータを取得・更新する処理がある場合、負荷の高い時間帯を避けること、前回連携以降に更新されたデータだけを対象にすること、変更のないレコードを処理対象から外すことなどが改善策として紹介されています。

kintone SIGNPOST：性能上の考慮点と改善策

大量データでは、全件処理を減らします。

差分で処理する。

期間で区切る。

対象一覧を作る。

実行ログを残す。

失敗した件だけ再実行する。

これを決めておくと、レコード数が増えても運用しやすくなります。

kintoneルックアップ一括更新の設計方法はこちら

外部DBやBIに逃がすケース

kintoneは業務アプリとして強いですが、すべての大量データ処理をkintone内で完結させる必要はありません。

次のような場合は、外部DB、データウェアハウス、BI、専用システムも検討します。

ケース	外部化を検討する理由
数百万件規模のログ分析	kintone画面で日常操作する粒度ではない
複数アプリ横断の重い集計	kintone標準集計だけでは設計が苦しい
会計・在庫・基幹処理	厳密な整合性や専用機能が必要
大量明細の検索	条件検索や結合を高速にしたい
外部BIで可視化したい	月次や経営指標を横断で見たい
長期保管が中心	日常アプリに残す必要が薄い

外部化は、kintoneを捨てるという意味ではありません。

kintoneは現場入力と状態管理。

外部DBは大量保管と横断検索。

BIは集計表示。

会計や在庫の専用システムは正式処理。

このように役割を分けます。

kintoneリレーショナルデータベース設計はこちら
kintoneダッシュボードの設計方法はこちら

よくある失敗

失敗1：上限なしを理由に1アプリへ詰め込む

レコード数に上限がないからといって、業務もデータも全部1アプリに入れると、一覧、権限、集計、APIが重くなります。

業務の責任単位でアプリを分けます。

失敗2：全件一覧をデフォルトにする

大量データアプリで、全件に近い一覧を最初に開く設計は避けます。

デフォルト一覧は、未対応、今月、自分の担当、直近更新などに寄せます。

失敗3：古いレコードの扱いを決めない

完了済み、失注、解約、過年度データをいつまでも現役アプリに残すと、日常画面が重くなります。

保持期間、アーカイブ、検索方法を決めます。

失敗4：APIが毎回全件取得する

外部連携やバッチ処理で毎回全件取得すると、件数が増えた時点で詰まります。

更新日時、状態、管理番号、差分フラグなどで対象を絞ります。

失敗5：テーブルで件数を減らしたつもりになる

1レコードに明細を大量に入れると、レコード数は減ります。

しかし、検索、集計、権限、API、CSV出力では扱いづらくなることがあります。

明細を1行1レコードにするか、テーブルにするかは、集計と連携の要否で決めます。

kintoneレコード数設計チェックリスト

最後に、レコード数が増えるアプリを作る前のチェックリストです。

チェック	確認すること
年間件数	1年で何件増えるか
保存年数	3年後、5年後に何件になるか
日常一覧	初期表示を未対応・直近・担当者別にできるか
検索条件	管理番号、日付、顧客、状態で探せるか
権限	レコード権限やフィールド権限が複雑すぎないか
フィールド数	Excelの列をそのまま持ち込みすぎていないか
テーブル	明細をテーブルに入れるべきか、別アプリにすべきか
添付	ファイル保管先と表示頻度を決めたか
CSV	取込・書き出しの分割単位を決めたか
API	差分取得、同時実行、リクエスト数を見たか
集計	毎回全件集計か、集計値を保存するか
退避	アーカイブ条件と検索方法を決めたか
外部化	外部DBやBIに任せる範囲を決めたか

kintoneのレコード数は、公式上の上限だけを見れば「上限なし」です。

しかし、実務では、件数が増えたときにどの画面を開き、どの権限で表示し、どの条件で集計し、どの処理で連携するかが効いてきます。

上限値を確認する。

年間件数を見積もる。

日常一覧を軽くする。

古いデータを退避する。

APIは差分処理にする。

必要なら外部DBやBIに分ける。

ここまで決めておくと、kintoneはレコードが増えても業務アプリとして使い続けやすくなります。

Bitlightに相談できること

Bitlightでは、kintoneのレコード数上限を、単なる仕様確認ではなく、大量データ運用の設計として整理します。

たとえば、次のような支援ができます。

相談内容	支援できること
何件まで1アプリで使えるか不安	年間件数、保存年数、一覧、権限、フィールド数から判断する
既存アプリが重い	一覧条件、表示列、権限、テーブル、添付、カスタマイズを見直す
古いデータを整理したい	アーカイブアプリ、CSV保管、検索導線を設計する
API連携が重くなってきた	差分取得、処理ログ、再実行、同時実行数を整理する
集計が遅い	集計値保存、月次集計アプリ、外部BI連携を検討する
外部DBに逃がすべきか迷う	kintoneに残す業務と外部化するデータを分ける

レコード数の上限確認だけでは、大量データの問題は解けません。

実際の利用画面、更新頻度、権限、集計、連携まで見て、kintoneに残すデータと逃がすデータを分ける必要があります。