kintoneの限界はどこか：スクラッチ開発に移行する判断基準

kintoneは、現場の担当者が自分で業務アプリを作り、改善し続けられる優れたツールです。ただし、扱うデータが増え、業務のルールが複雑になり、他のシステムとの連携が広がるにつれて、設定やプラグイン、JavaScriptによるカスタマイズが積み重なり、「誰も全体を把握していない」状態になりがちです。kintoneの限界は、機能の上限そのものよりも、こうした運用の複雑さが利点を上回ったときに訪れます。

結論として、スクラッチ開発への移行を検討すべきなのは、レコード数や計算の重さ、権限の細かさ、外部連携のいずれかが業務の妨げになっており、かつそれをkintoneの設定やカスタマイズで解決するコストが、専用システムを作るコストに近づいている場合です。ただし、全面的に移行するだけが選択肢ではありません。kintoneを入力や現場の改善に残し、重い処理や外部連携だけを別システムに切り出す「併用」が最適な場合も多くあります。

この記事は、kintoneを導入して数年が経ち、アプリが増えて管理が難しくなってきた企業の担当者や、kintoneで実現しようとしている要件が重くなってきた情報システム担当者に向けています。限界のサイン、判断基準、移行と併用の選択肢、進め方を順に整理します。なお、kintoneの機能や制限値は更新されることがあるため、具体的な仕様は提供元の最新情報で確認してください。

kintoneが向いている業務と、苦しくなる業務

kintoneの限界を考える前に、kintoneが得意な領域を押さえておきます。得意な領域で使っているなら、多少の不便は運用で補うほうが合理的だからです。

kintoneが向いている業務

• 案件管理、問い合わせ管理、日報、申請など、一件ずつ登録して一覧で管理する業務
• 項目や業務フローを現場で頻繁に見直したい業務
• 利用者が社内中心で、権限の区分が部署や役割程度で足りる業務
• 担当者が設定画面からアプリを作り、改善できる体制がある業務

ノーコードの業務アプリ作成ツールとしての位置づけはkintoneの用語解説でも整理しています。

kintoneで苦しくなりやすい業務

• 複数のアプリをまたいだ複雑な集計や計算を、リアルタイムで行う必要がある業務
• 大量のレコードを頻繁に一括更新する業務
• 取引先や顧客など社外の利用者に、データの一部だけを見せたり入力させたりする業務
• 在庫の引当や予約枠のように、同時更新の整合性が厳しく求められる業務
• 基幹システムやECなど、複数の外部システムと双方向でリアルタイムに連携する業務

後者に当てはまる業務をkintoneで実現しようとすると、プラグインや外部サービス、JavaScriptのカスタマイズが増えていきます。それ自体は問題ではありませんが、増えすぎると保守が難しくなります。

kintoneの限界を示す5つのサイン

次のようなサインが複数出ているなら、現状の作り方を見直す時期に来ています。

1. レコード数の増加で操作が遅くなっている

一覧の表示や検索、集計グラフの表示に時間がかかり、現場から「重い」という声が上がっている状態です。古いレコードの整理や一覧の絞り込みで改善できることもありますが、業務上すべてのデータをすぐに参照する必要がある場合は、根本的な解決が難しくなります。

2. 計算や集計をアプリの外で行っている

kintoneの計算フィールドやルックアップで表現しきれない計算を、CSVに書き出してExcelで集計し、結果を手で戻している状態です。データの二重管理が発生し、集計結果の正しさを誰も保証できなくなります。

3. 権限の設定が複雑すぎて誰も把握していない

アプリ、レコード、フィールドの各単位で権限を細かく設定した結果、「なぜこの人にこのデータが見えるのか」を説明できない状態です。権限の変更のたびに、意図しない情報の漏れが起きていないか不安になります。

4. カスタマイズやプラグインが属人化している

JavaScriptのカスタマイズを書いた人が退職した、どのプラグインが何をしているか分からない、外部の連携サービスの契約が誰の管理か分からない、といった状態です。kintone本体のアップデートでカスタマイズが動かなくなったときに、誰も直せないリスクがあります。

5. 外部連携の不具合が業務を止めている

会計ソフトやEC、基幹システムとの連携がうまくいかず、データの欠落や重複が起きる、連携のエラーに誰も気づかない、といった状態です。連携の数が増えるほど、どこで何が起きているかを追うのが難しくなります。

判断基準：kintoneで続けるか、移行するか、併用するか

サインの有無を、判断の軸ごとに整理します。

中央の列が多いなら、まずは設定の整理や、一部機能の切り出しによる併用を検討します。右の列が多く、特に業務の中核となる処理がkintoneの外に出ているなら、スクラッチ開発を含めた見直しの検討に値します。

判断にあたって気をつけたいのは、「kintoneのライセンス費用」と「スクラッチ開発の費用」だけを比べないことです。kintoneの側には、プラグインや連携サービスの費用、カスタマイズの保守費用、そして現場で手作業により補っている時間のコストがあります。スクラッチ開発の側には、初期の開発費に加えて、サーバー費用や保守費用、改修のたびの開発費があります。両方を数年単位で並べて比較しましょう。

数年単位で比較するときに並べる項目

比較の表を作るときは、次の項目を両方の選択肢について埋めていくと、抜けが少なくなります。

• 利用料：kintoneのライセンス、プラグイン、連携サービスの月額。スクラッチ開発ではサーバーやクラウド、外部サービスの利用料。
• 初期の作業費：kintoneの整理やカスタマイズの作業費。スクラッチ開発では要件整理、設計、開発、テスト、データ移行の作業費。
• 保守費：カスタマイズやプラグインの動作確認、本体アップデートへの追随。スクラッチ開発ではライブラリの更新、障害対応、問い合わせ対応。
• 改修費：業務の変更に合わせた修正。kintoneでは現場で対応できる部分と外部に依頼する部分を分けて見積もる。
• 手作業のコスト：CSVの書き出しとExcelでの集計、連携エラーの手修正など、現状で人が補っている時間。

最後の手作業のコストは、見積書には現れないため見落とされがちです。担当者に一週間ほど作業時間を記録してもらうだけでも、比較の精度は大きく上がります。

移行と併用の4つのパターン

kintoneの限界に対しては、次のような選択肢があります。

パターン1：kintoneの中で整理し直す

アプリの統廃合、不要なフィールドやプラグインの削除、権限設計の見直し、古いレコードの別アプリへの退避などで、現状のまま使いやすくする方法です。限界の原因が「作り方の散らかり」にあるなら、最も費用のかからない選択肢です。

パターン2：重い処理だけを外部に切り出す

kintoneは入力と閲覧に使い続け、複雑な集計や計算、大量データの処理を外部のプログラムやデータ基盤で行い、結果をkintoneに戻す、あるいはダッシュボードで見せる方法です。現場の使い勝手を変えずに、限界の原因だけを取り除けます。

パターン3：社外向けの部分だけを別システムにする

取引先や顧客に見せる画面、予約や申し込みの受付など、社外の利用者が関わる部分を専用のWebシステムとして作り、社内の管理はkintoneに残す方法です。APIで両者をつなぎます。つなぎ方の考え方はAPI連携とは何かで解説しています。

パターン4：スクラッチ開発で全面的に移行する

業務の中核となる処理がkintoneに合わなくなっており、併用では複雑さが解消しない場合は、専用システムへの全面移行を検討します。ノーコード全般からスクラッチ開発へ移る際の考え方はノーコードの限界はどこかも参考になります。

スクラッチ開発へ移行する手順

全面移行、または一部の切り出しを決めた場合の進め方は、次のとおりです。

1. アプリとカスタマイズの棚卸し：すべてのアプリ、フィールド、プロセス管理、権限設定、プラグイン、JavaScript、外部連携を一覧にします。使われていないアプリも含めて洗い出し、移行対象を決めます。
2. 業務の目的から要件を組み立て直す：kintoneの画面をそのまま再現するのではなく、業務の流れと目的から、必要な機能と画面を整理し直します。kintoneの制約のために回り道していた部分は、ここで素直な形に戻します。
3. 残すもの・移すものを決める：併用する場合は、どの業務をkintoneに残し、どれを新システムに移すかを決め、データの持ち主（どちらが正本か）を項目ごとに決めます。
4. データ構造を設計する：kintoneのアプリ単位のデータを、新システムのデータベースとして設計し直します。ルックアップや関連レコードで表していた関係を、きちんとしたデータの関係として整理します。
5. 段階的にリリースする：一度にすべてを切り替えるのではなく、影響の小さい業務から順に移すか、併用期間を設けて段階的に切り替えます。切り替え方式の選び方はシステム移行は段階的か一括かで解説しています。
6. データ移行と検証：kintoneからデータを書き出し、整備したうえで新システムに取り込みます。添付ファイルやコメント、変更履歴を移すかどうかも決めておきます。
7. 運用体制を決める：移行後は、現場で設定を変える柔軟性が減ります。項目や選択肢の追加を管理画面から行えるようにする範囲と、開発に依頼する範囲を決めておきます。

具体的な場面で考える：受注管理アプリの例

架空の例として、製造業の会社がkintoneで受注管理を行っている場面を考えます。営業が受注を登録し、生産管理が製造の予定を立て、出荷担当が出荷を記録する、という流れを複数のアプリとルックアップでつないでいます。

数年の運用で、次のような状況になりました。

• 受注の金額計算に、取引先別の掛け率や数量割引など複数の条件があり、JavaScriptのカスタマイズで計算している。カスタマイズを書いた担当者はすでに異動している。
• 製造予定の集計は、毎朝CSVを書き出してExcelで行っている。
• 取引先から受注状況の問い合わせが多く、取引先自身が確認できる画面を用意したいが、kintoneのアカウントを取引先に渡すのは避けたい。

判断基準に当てはめると、計算、外部公開、カスタマイズの属人化が右寄りの状態です。ただし、受注の登録や進捗の更新は現場で使い慣れており、操作に不満はありません。

この場合、全面移行ではなく、パターン2とパターン3の組み合わせが考えられます。金額計算と製造予定の集計を外部の小さなシステムに切り出し、kintoneとはAPIでつなぐ。取引先向けの受注状況の確認画面は専用のWebページとして作り、kintoneのデータを参照して表示する。こうすれば、現場の操作は変えずに、属人化したカスタマイズと手作業の集計を解消できます。

kintoneからの移行でよくある失敗と避け方

kintoneの画面と操作をそのまま再現する

現場の慣れを優先してkintoneと同じ画面を作ろうとすると、kintoneの制約を回避するために作られた回り道まで再現してしまいます。業務の目的から画面を設計し直し、現場には試作段階で触ってもらって、慣れの問題と使いにくさの問題を区別しましょう。

現場で改善できる柔軟性を失う

kintoneの最大の利点は、現場が自分で改善できることでした。スクラッチ開発に移ると、項目の追加ひとつにも開発が必要になり、改善の速度が落ちます。頻繁に変わる選択肢や区分、通知先などは管理画面から変更できるように設計し、移行で失うものを最小限にします。

併用時にデータの正本を決めていない

kintoneと新システムの両方で同じデータを編集できる状態にすると、どちらが正しいか分からなくなります。項目ごとに、どちらのシステムが正本で、どちらが参照するだけかを決め、編集できる場所をひとつに絞ります。

費用の比較が初期費用だけになっている

スクラッチ開発の初期費用とkintoneの月額だけを比べると、判断を誤ります。カスタマイズの保守、連携サービス、手作業のコスト、移行後の保守や改修まで含めて、数年単位で比較しましょう。

移行を検討する前のチェックリスト

• すべてのアプリ、プラグイン、カスタマイズ、外部連携を一覧にしたか
• どのアプリのどの処理がボトルネックになっているかを特定したか
• kintoneの中での整理で解決できる問題を切り分けたか
• アプリの外で行っている計算や集計を洗い出したか
• 社外の利用者に公開したい範囲を整理したか
• 併用する場合、項目ごとのデータの正本を決めたか
• 移行後に現場で変更できるようにしたい項目を挙げたか
• ライセンス、プラグイン、保守、手作業のコストを数年単位で整理したか
• 段階的に切り替える順番を検討したか

よくある質問

Q. kintoneのレコード数がどのくらいになったら移行すべきですか？

レコード数だけで判断するのはおすすめしません。同じ件数でも、一覧の絞り込みや集計の仕方によって操作の快適さは大きく変わります。日常業務の操作が遅くなっているか、その遅さが設定の見直しで解消できるかを確認し、他の判断軸と合わせて考えてください。制限値などの最新の仕様は提供元の情報で確認しましょう。

Q. kintoneのカスタマイズを外部に依頼して延命するのと、スクラッチ開発に移行するのは、どちらがよいですか？

カスタマイズの量が限定的で、kintoneの得意な領域の業務であれば、延命のほうが合理的です。一方、主要な業務がカスタマイズ前提で動いており、カスタマイズの保守自体が負担になっているなら、移行や切り出しのほうが長期的には管理しやすくなります。

Q. kintoneから別のノーコードツールに乗り換えるのはどうですか？

限界の原因が特定のツールの仕様にあるなら、別のツールで解決できることもあります。ただし、計算の複雑さや社外公開、厳密な同時更新の整合性が原因の場合は、ノーコードツール全般で同じ問題が起きやすい点に注意が必要です。乗り換える前に、限界の原因がどこにあるのかを特定しましょう。

Q. 移行後もkintoneを使い続けるのは中途半端ではありませんか？

中途半端ではありません。現場の入力や改善にはkintone、重い処理や社外向けの機能は専用システム、という役割分担は、それぞれの強みを生かす合理的な構成です。大切なのは、二つのシステムの責任範囲とデータの正本を明確にしておくことです。

Otsumuに相談できること

kintoneが重い、使いにくいという場合でも、原因がアプリの散らかりや権限設定の複雑さにあるなら、kintoneの中での整理で解決できることが多くあります。不要なアプリやプラグインの整理、権限の見直し、古いレコードの退避は、社内の担当者や提供元のパートナーの支援で十分に進められます。その場合、スクラッチ開発を急ぐ必要はありません。

一方で、計算や集計がアプリの外に出ている、社外の利用者向けの機能が必要になっている、外部連携やカスタマイズが属人化して不具合が業務を止めている、といった状況では、kintoneの外に仕組みを作ることを含めて検討したほうがよいでしょう。全面移行にするか、一部の切り出しによる併用にするかの判断は、業務の中身とデータの流れを見ないと決められません。

Otsumuでは、Excelや既存ツールからのシステム化として、kintoneのアプリとカスタマイズの棚卸し、併用か移行かの判断、切り出す機能の設計と開発、データ移行までを一貫して支援しています。目的から逆算して必要な機能に絞り、AIを活用した開発で少人数・短期間で進めるため、まず重い処理ひとつを切り出すといった小さな始め方も可能です。

現状を整理するところから始めたい場合も歓迎です。30分の無料相談で、現在のkintoneの使い方と困りごとをお聞きし、続ける・併用する・移行するの選択肢を一緒に整理します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01