「kintoneを使い続けてきたが、カスタマイズが複雑になりすぎて限界が見えてきた」——中小企業のkintoneユーザーから聞く悩みです。プラグインを10個以上入れ、JavaScriptカスタマイズも積み重ね、それでもまだ追加要件が出てくる。月額利用料に加えてプラグイン費用、運用保守費用が積み上がり、コストメリットも薄れてきた——こうした状況に陥っている方は少なくありません。本記事では、kintoneのカスタマイズ限界に達した時に取れる4つの選択肢と、判断の軸を整理します。
この記事の結論（3行）
- kintoneの限界サインは「プラグイン10個超」「JS開発が常態化」「動作が重い」の3つ
- 次に取れる選択肢は「プラグイン強化・連携サービス・スクラッチ・別パッケージ」の4つ
- 月額10万円超のkintone運用なら、3年TCOで他選択肢と比較する価値が出てくる
kintoneのカスタマイズ限界とは何か
kintoneは「業務アプリを簡単に作れる」ノーコード基盤として、中小企業で広く使われています。標準機能・プラグイン・JavaScriptカスタマイズの3段階で機能拡張できる柔軟さが魅力です。一方、業務が複雑化するにつれて、この拡張機能を積み上げ続ける運用が限界を迎えるタイミングがあります。
- プラグインが10個以上積み上がる
- JavaScriptカスタマイズの保守が常態化する
- レコード件数増加で動作が重くなる
この3つのサインが見えてきたら、kintoneのカスタマイズ限界に近づいています。
サイン1：プラグインが10個以上積み上がる
kintoneの標準機能で足りない部分を、プラグインで補うのは合理的な選択です。ただし、プラグインが10個を超えてくると、それぞれが月額数千円〜数万円の費用で積み上がり、年額で60〜120万円のランニングが乗ります。さらに、プラグイン同士の干渉問題が発生しやすくなり、kintoneのバージョンアップ時に動かなくなるリスクも高まります。
サイン2：JavaScriptカスタマイズの保守が常態化
プラグインで足りない部分を、JavaScriptカスタマイズで作り込むケースも多いです。最初は数行のスクリプトでも、業務要件の追加と共に数百行〜数千行に膨らみます。この保守を外注すれば月額10〜30万円、社内で対応すればエンジニア工数を1人月分使うことになります。kintoneの「ノーコード」のメリットが、ここで消えていきます。
サイン3：レコード件数増加で動作が重い
kintoneはアプリあたり50万件のレコード上限があり、それ以下でも数万件を超えると検索や集計の動作が重くなります。プラグインを多数入れている環境では、さらに動作が遅くなります。現場から「kintoneが重くて使いにくい」という声が出てきたら、限界のサインです。
限界に達した時の4つの選択肢
kintoneのカスタマイズ限界に達した時、取れる選択肢は4つあります。
| 選択肢 | 初期コスト | 月額コスト | 切り替え期間 | 適合度 | |---|---|---|---|---| | プラグイン強化 | 〜100万円 | 既存＋追加 | 1〜2か月 | 80〜90% | | 連携サービス活用 | 100〜300万円 | 既存＋月5〜15万円 | 2〜4か月 | 90〜95% | | スクラッチ開発 | 500〜2,000万円 | 保守費10〜30万円/月 | 6〜18か月 | 100% | | 別パッケージ移行 | 300〜1,000万円 | 別パッケージ次第 | 3〜9か月 | 別パッケージ次第 |
それぞれの選択肢を順に見ていきます。
選択肢1：プラグイン強化で対応
足りない機能だけを追加プラグインや有料プラグインで埋める選択肢です。初期コストは抑えられ、運用を変える必要もありません。
メリットは、現場の使い方を変えずに済むこと。デメリットは、プラグイン費用が積み上がり続けること、そして根本的なkintoneの動作の重さは解決しないことです。プラグインが10個以下で、月額のkintone関連費用が10万円以下なら、この選択肢が現実的です。
選択肢2：連携サービスで機能補完
kintoneと別のSaaS（BIツール、ワークフローツール、データベースなど）を連携させ、kintoneでは難しい部分を別サービスに担当させる選択肢です。
メリットは、kintone本体は軽いまま保てること、それぞれの得意分野で機能補完できること。デメリットは、連携の保守費用が乗ること、複数システムにまたがる障害対応が複雑になることです。例えば、kintoneで申請・承認、BIツールで集計、別データベースで大量データ管理——のような役割分担になります。
選択肢3：スクラッチ開発に切り替え
kintoneを諦め、自社業務に完全に合わせたシステムを開発する選択肢です。初期コストは大きいものの、業務との適合度は100%にできます。
メリットは、業務に完全に合わせられること、kintoneの動作の重さやプラグイン依存から解放されること。デメリットは、初期コストが大きく、開発期間が6〜18か月かかること、そしてkintoneのデータ移行費用が別途100〜300万円かかることです。kintone関連費用が月額15万円を超え、3年TCOで考えるとスクラッチ開発のほうが安くなるラインがあります。
選択肢4：別パッケージへ移行
kintoneを諦め、別のパッケージシステム（業界特化型のERPやSaaSなど）へ移行する選択肢です。
メリットは、業界標準のベストプラクティスに乗れること、kintoneより業務適合度が高いパッケージが見つかる可能性があること。デメリットは、パッケージごとに学習コストが必要なこと、データ移行費用がかかることです。同業他社で広く使われているパッケージがあれば、この選択肢は有力です。
どの選択肢を選ぶかの判断軸
4つの選択肢の中からどれを選ぶかは、3つの判断軸で決まります。
- 現在のkintone関連費用（月額）
- 業務の特殊性（業界標準パッケージで吸収できるか）
- 経営の時間軸（半年か、3年か）
この3つを整理することで、現実的に取るべき選択肢が見えてきます。
軸1：現在のkintone関連費用
月額のkintone費用（基本料金＋プラグイン＋JavaScriptカスタマイズ保守）を計算してください。
- 月額5万円以下：プラグイン強化で対応
- 月額5〜10万円：プラグイン強化または連携サービス
- 月額10〜15万円：連携サービスまたはスクラッチ開発
- 月額15万円超：スクラッチ開発または別パッケージへの移行が現実的
3年で考えると、月額15万円なら540万円、月額20万円なら720万円のランニングコストです。この水準ならスクラッチ開発の初期投資を回収できる可能性があります。
軸2：業務の特殊性
自社業務が「業界標準のやり方」で済むのか、「独自の特殊要件」が多いのかを判断してください。
- 業界標準で済む：別パッケージへの移行が候補
- 独自要件が多い：スクラッチ開発が候補
- 中間：kintone継続＋連携サービスが候補
業界標準のパッケージが存在しない・業界に特化した独自業務が多い場合、スクラッチ開発のほうが結果的に適合度が高くなります。
軸3：経営の時間軸
「半年以内に解決したい」のか「3年かけて根本解決したい」のかで選び方が変わります。
- 半年以内：プラグイン強化または連携サービス
- 3年以内：スクラッチ開発または別パッケージ
緊急性が高い場合は短期的な打ち手で延命し、並行して長期的な選択肢を検討する2段階アプローチも有効です。
経営者目線で考える「kintone継続の判断」
ここからは経営の話です。kintoneを継続するか別の道を選ぶかは、現場担当者の感覚だけで決めると失敗します。現場は「いま使っているkintoneを変えたくない」傾向が強く、変えるべきタイミングを逃すことが多いです。
経営者の判断視点は3つです。第一に、「3年後の事業規模」を想定すること。事業が拡大していくなら、kintoneの動作の重さやレコード上限が将来の制約になります。第二に、「kintone関連費用の総額」を経営者自身が把握すること。基本料金だけでなくプラグイン費・JS保守費を全て足した数字で判断します。第三に、「移行のタイミング」を逃さないこと。現場が「kintoneでもう無理」と諦める前に、計画的に次の選択肢へ移るのが理想です。
この3つの視点で整理すると、kintoneを「使い続けるべきか」「いつまでに切り替えるべきか」の経営判断がしやすくなります。
ぷらすわんの実例：kintoneを起点にスクラッチで業務統合
ぷらすわんが取り組んでいる「けんぞうくん」の事例をお伝えします。けんぞうくんは建設業向けのマッチングプラットフォームで、市場相場で2,500〜4,000万円規模のシステムを2,000万円規模で立ち上げました。
このプロジェクトで意識したのが、「kintoneで実証してからスクラッチで本番化」というアプローチです。最初の業務フロー検証はkintoneで行い、現場で本当に必要な機能を3〜4か月で見極めました。その後、kintoneでは対応しきれない57機能・30.8人月の規模の本番システムを、Next.js + Supabaseで構築しました。kintoneを最初から使わず直接スクラッチ開発に入ると、要件の探索段階で1〜2人月の追加工数が発生していたはずです。
「kintoneを継続するかスクラッチに切り替えるか」の二択ではなく、「kintoneを実証フェーズとして活用し、本番はスクラッチで作る」発想が、中小企業のシステム投資では現実的です。kintoneで業務要件が明確になっていれば、スクラッチ開発の見積もり精度が大幅に上がります。自社のkintone活用を診断することで、次のフェーズへの移行タイミングを整理できます。
kintone限界から次に進むための5つの実践
最後に、kintoneのカスタマイズ限界から次の選択肢へ進むための、5つの実践的なポイントをお伝えします。
- kintone関連費用の総額を経営者が把握する
- プラグインとJavaScriptカスタマイズを棚卸しする
- 連携サービスを導入する前にAPI連携の保守体制を検討する
- スクラッチ開発検討時はkintoneの業務要件を仕様書化する
- 3年TCOで選択肢を比較する
これらは、判断の質を上げるための実践です。
kintone関連費用の総額を把握する
kintoneの基本料金・プラグイン費・JavaScriptカスタマイズ保守費を全て合計し、月額・年額・3年累計を経営者が把握してください。この数字が他選択肢との比較の出発点です。
プラグインとJSカスタマイズを棚卸し
導入済みのプラグインとJavaScriptカスタマイズを一覧化し、「いまも使われているか」「業務に必須か」を確認してください。半年以上使われていないものは解約候補、JSカスタマイズも不要なものは削除候補です。
連携サービスはAPI保守体制を考慮
連携サービスを導入する場合、API連携部分の保守体制を事前に検討してください。kintoneや連携先のアップデートで連携が壊れた時の対応手順を決めておかないと、障害時に業務が止まります。
スクラッチ開発検討時は業務要件を仕様書化
スクラッチ開発を検討する場合、kintoneで実際に動いている業務フロー・データ構造・画面構成を仕様書としてまとめてください。これがあると、スクラッチ開発の見積もり精度が大幅に上がり、コスト削減につながります。
3年TCOで選択肢を比較
4つの選択肢を、初期コスト＋運用コスト＋移行コストを含めた3年TCOで比較してください。月額の数万円違いも、3年で見ると100万円以上の差になります。発注前に他社見積もりとの比較を依頼する場合も、3年TCOで比較してください。
まとめ
kintoneのカスタマイズ限界に達するサインは、「プラグイン10個超」「JS開発が常態化」「動作が重い」の3つです。この状態になったら、「プラグイン強化・連携サービス・スクラッチ開発・別パッケージ移行」の4つの選択肢を比較する段階です。
選び方の判断軸は、kintone関連費用の月額・業務の特殊性・経営の時間軸の3つです。月額15万円を超えてくると、スクラッチ開発や別パッケージへの移行が現実的な選択肢になります。
「kintone継続かスクラッチか」の二択で迷うのではなく、「kintoneを実証フェーズとして活用し、本番はスクラッチで作る」発想も有効です。経営者が判断軸を持って臨めば、kintoneは中小企業のDX投資の起点として活用できます。自社のkintone活用を整理したい経営者の方は、現状を項目別に整理してから判断する流れをお勧めします。