kintoneの限界とは？スクラッチ開発に切り替える判断基準と費用

「kintoneで作ったアプリが増えすぎて管理しきれない」「レコードが増えて画面が重くなってきた」「プラグインとJavaScriptのカスタマイズが複雑になり、作った人しか触れない」――kintoneを数年使い込んだ企業から、こうした声を聞くことが増えています。kintoneは手軽に業務アプリを作れる便利なサービスですが、使い方によっては限界にぶつかることがあります。

この記事では、kintoneの限界が表れやすい場面と、スクラッチ開発へ切り替えるかを判断する基準、kintoneを残しながら外部開発で補う方法、移行にかかる費用の目安を整理します。kintone開発をこのまま続けるべきか迷っている担当者の判断材料にしてください。

kintoneの限界とは？よくある4つの壁

kintoneの限界とは、ノーコード・ローコードで手軽に作れる設計であるがゆえに、業務の規模や複雑さが一定を超えたときに運用・性能・保守の面で無理が出てくる状態のことです。kintone（サイボウズ社のクラウド型業務アプリ作成サービス）は、プログラミングなしでデータベースアプリを作れるのが強みですが、もともと大量データの一括処理や複雑な計算を中心に据えた基幹システム向けの製品ではありません。

限界が表れる場面は、主に次の4つに分けられます。

データ量と処理性能の壁

kintoneは画面上でレコードを1件ずつ扱う使い方に向いています。数万〜数十万件規模のデータを毎日集計したり、複数アプリの関連レコードを参照しながら計算したりすると、表示や処理に時間がかかることがあります。月末の締め処理や在庫の一括引当のように、大量データをまとめて処理する業務は、データベースを直接扱えるシステムのほうが得意です。

カスタマイズの属人化の壁

標準機能で足りない部分は、JavaScriptによるカスタマイズやプラグインで補えます。ただし、社内の詳しい人が独学で書いたコードが増えると、その人が異動・退職したときに誰も直せなくなります。契約プランによってはJavaScriptカスタマイズやプラグインが使えない場合もあるため、カスタマイズ前提の運用は契約内容とあわせて確認が必要です。

外部連携の壁

kintoneにはREST API（外部のシステムからデータを読み書きする窓口）がありますが、1日に実行できる1アプリあたりのAPIリクエスト数などに上限値が設けられています。2026年10月時点の具体的な上限値はサイボウズ社の公式情報で確認してください。基幹システムや会計ソフトと頻繁にデータをやり取りする構成では、上限を意識した設計が必要になり、連携ツールを何層も組み合わせると障害時の原因追跡が難しくなります。

関連記事ノーコードの限界とスクラッチ開発に切り替えるべきタイミング

スクラッチ開発に切り替える判断基準

kintoneに不満があっても、すぐに作り直すのが正解とは限りません。次のチェック項目のうち、当てはまるものが多いほど切り替えを検討する価値があります。

• 基幹業務の中心になっている：受発注・在庫・請求など、止まると売上に直結する業務をkintoneで回している。
• 処理待ちや手作業の回避策が増えた：重い集計をExcelに書き出して加工する、夜間にまとめて処理するなどの運用でしのいでいる。
• カスタマイズの保守ができる人がいない：JavaScriptやプラグインの中身を説明できる担当者がいない、または1人しかいない。
• 連携ツールが増えすぎた：外部の連携サービスやスクリプトが複数あり、全体像を把握している人がいない。
• 利用料の総額が膨らんできた：利用者数の増加やプラグイン・連携サービスの追加で、毎月の費用が想定を超えている。
• 取引先や顧客にも使わせたい：社外の利用者向けの画面や権限を細かく作り込みたい。

反対に、利用者が少なく、部署内の情報共有や申請管理といった用途にとどまっているなら、kintoneを使い続けるほうが合理的です。標準機能で回っている業務を無理に作り直すと、費用に見合う効果が得られないこともあります。

関連記事ローコードとスクラッチ開発の比較｜選び方の基準

全面移行だけではない3つの選択肢

kintoneの限界を感じたときの対応は、「すべて作り直す」か「我慢して使い続ける」かの二択ではありません。業務ごとに向き不向きを見極め、組み合わせる方法もあります。

金額は目安で、アプリ数、データ量、連携先の数によって変わります。外部で補う方法は、現場が慣れたkintoneの入力画面を残せる点がメリットですが、システムが2つになるため保守の範囲が広がる点には注意が必要です。

kintoneからスクラッチ開発への移行費用と進め方

スクラッチ開発への移行では、kintoneアプリをそのまま写すのではなく、業務を見直したうえで必要な機能を設計し直すことが大切です。kintone上では「とりあえず追加したフィールド」や「使われていないアプリ」が残っていることが多く、整理せずに移すと新システムも複雑になります。

1. アプリとカスタマイズの棚卸しアプリ一覧、フィールド、プロセス管理、JavaScript・プラグイン、外部連携を洗い出し、使われているものと不要なものを分けます。
2. 業務の再整理と要件定義現在の業務フローを確認し、新システムで実現する機能と、運用で吸収することを決めます。
3. データ移行の設計レコードや添付ファイルの書き出し方法、データの変換ルール、移行のタイミングを決めます。
4. 開発・テストkintoneで行っていた計算結果と新システムの結果を突き合わせ、差異がないかを確認します。
5. 並行稼働と切り替え一定期間は両方を動かし、問題がないことを確認してからkintoneの利用を停止します。

スクラッチ開発の見積もりは人月で算出されることが多く、人月単価の目安はPMで100万〜160万円、SEで80万〜120万円、PGで60万〜100万円程度です。開発後の保守費は年間で開発費の10〜15％程度を見込んでおきましょう。kintoneの利用料がなくなる分と、保守費やサーバー費が増える分を比べて、5年程度の総額で判断するのが現実的です。

関連記事システム移行時のデータ移行の進め方と注意点

よくある質問

まとめ

kintoneの限界は、データ量と処理性能、処理の複雑さ、カスタマイズの属人化、外部連携の4つの場面で表れやすくなります。ただし、限界を感じたからといって必ずしも全面移行が正解ではなく、アプリの整理や外部システムでの補完で解決できる場合もあります。基幹業務の中心を担い、保守や連携が回らなくなっているなら、スクラッチ開発への移行を検討する時期です。現状の棚卸しから始め、5年程度の総額で選択肢を比較しましょう。

参考：cybozu developer network「kintone APIリクエスト数の超過メールが届いたら？」／kintone ヘルプ「制限値一覧」