kintoneでできないことは何か。導入社数30,000社を超えたkintoneだが、事業成長に伴い限界を感じる企業が増えている。IPA「DX白書2023」では、ローコード/ノーコードツールの利用企業においても、業務の複雑化に伴い機能の限界を感じるケースが報告されている（IPA、2023年2月）。kintoneは優秀なツールだが、事業が成長するほど「これ以上は無理だ」と感じる場面が増えてくる。
kintoneの概要と人気の理由
kintoneはサイボウズ株式会社が提供するノーコード業務アプリ構築プラットフォームだ。ドラッグ&ドロップで業務アプリを作れる手軽さ、月額1,500円/ユーザー（スタンダードコース）からの導入しやすい価格帯、そしてプラグインによる拡張性が人気の理由として挙げられる。
特にIT専任者がいない中小企業にとって、現場の担当者が自分で業務アプリを構築できる点は大きな魅力だ。案件管理、日報、在庫管理など、多くの業務をkintone上で回している企業は多い。
ただし、事業規模が拡大し、業務が複雑化してくると、kintoneの設計思想に起因する制約が顕在化する。以下で具体的に見ていく。
kintoneでできないこと10選
1. 複雑なリレーショナルデータベース設計ができない
kintoneのデータ構造はアプリ単位のフラットテーブルが基本だ。RDB（リレーショナルデータベース）のように外部キーでテーブル間を正規化して結合する設計は想定されていない。ルックアップや関連レコードで擬似的な連携はできるが、3テーブル以上のJOINに相当する処理や、多対多のリレーションには対応できない。
2. 大量データでのパフォーマンスが出ない
kintoneの1アプリあたりのレコード上限は公称で約50万件だが、実運用ではレコード数が10万件を超えたあたりから一覧表示やCSVエクスポートのレスポンスが目に見えて悪化する。ルックアップが多いアプリでは数万件でも重くなるケースがある。
3. API呼び出しのレート制限
kintone REST APIのリクエスト数には制限があり、大量のデータ連携を行う場合にボトルネックとなる（cybozu developer network「kintone REST APIの共通仕様」参照）。外部システムとの連携頻度が高い場合、この制限にすぐ到達する。特にリアルタイム同期や大量レコードの一括処理では深刻なボトルネックになる。
4. JavaScript・CSSカスタマイズの制約
kintoneはJavaScript/CSSによるカスタマイズに対応しているが、DOM操作はサイボウズが公式に保証しているAPIイベント経由に限定される。UIの大幅な変更や独自のSPA（シングルページアプリケーション）的な画面構築は事実上不可能だ。また、kintoneのUI更新に伴いカスタマイズが動かなくなるリスクも常に存在する。
5. 複雑なワークフローの実装が困難
kintoneのプロセス管理機能は、単純な承認フロー（申請→承認→完了）には対応できる。しかし、条件分岐を伴う多段階承認（金額帯による承認ルート分岐、差し戻し後の再申請ルート変更など）になると、標準機能では対応しきれない。プラグインで補完できる範囲にも限界がある。
6. 帳票出力のカスタマイズ性が低い
kintoneの標準機能には帳票出力がない。プラグインで対応する形になるが、請求書や納品書のレイアウトを厳密にコントロールしたい場合、プラグインの制約にぶつかることが多い。取引先ごとにフォーマットが異なる場合はなおさらだ。
7. 外部サービスとの深い統合が難しい
kintoneからSlackやメールへの通知は可能だが、決済サービス（Stripe等）との連携、外部APIからのWebhook受信、あるいはERPや基幹システムとのリアルタイム双方向連携となると、中間にZapierやカスタムサーバーを置く必要が出てくる。連携の複雑さが増すほど、kintoneの「手軽さ」というメリットが薄れていく。
8. マルチテナント・権限管理の粒度が粗い
kintoneのアクセス権設定はアプリ単位・レコード単位で可能だが、フィールド単位の動的な権限切り替え（ユーザーの所属部署や役職に応じて特定フィールドの表示/非表示を切り替える）は標準では難しい。組織が複雑化するほど、権限設計で詰まるケースが増える。
9. モバイル対応の限界
kintone公式モバイルアプリは存在するが、カスタマイズしたJavaScriptがモバイルでは動かない場合がある。また、オフライン対応は限定的で、現場作業者がネットワーク環境の悪い場所でデータ入力する業務には不向きだ。
10. バージョン管理・ステージング環境がない
ここまで読んで
「うちも同じだ」と思った方へ
課題は企業ごとに異なります。30分の無料相談で、
御社に合った進め方と概算費用をお伝えします。
営業電話なし エンジニアが直接対応 相談だけでもOK
kintoneにはアプリの変更履歴管理やステージング環境（本番反映前にテストできる環境）の概念がない。本番環境で直接変更を加えるしかなく、変更が業務に影響した場合のロールバックも容易ではない。開発チームが複数人でカスタマイズを進めると、変更の衝突が起きやすい。
限界を迎える3つのサイン
上記の制約は、事業フェーズによっては許容範囲内に収まる。問題は「いつ移行を検討すべきか」だ。以下の3つのサインが出たら、kintoneの限界が近い。
サイン1：プラグイン費用がkintone本体を超えている
kintoneスタンダードコースは月額1,500円/ユーザーだが、帳票出力、ワークフロー拡張、外部連携などのプラグインを積み重ねると、月額コストが本体の2〜3倍に膨らむことがある。50ユーザー規模の場合、kintone本体の月額費用に加え、業務に必要なプラグインを複数導入すると、プラグイン費用が本体を上回るケースもある（※費用は利用プラグイン・ベンダーにより異なる）。この金額であれば、スクラッチ開発の初期投資を数年で回収できる計算になる。
サイン2：カスタマイズのJSファイルが管理不能になっている
JavaScriptカスタマイズが10ファイル以上、合計数千行を超えると、どの変更がどの機能に影響するかの把握が困難になる。バージョン管理もないため、「誰かが直したら別の機能が壊れた」という事故が頻発し始めたら危険信号だ。
サイン3：kintoneに合わせて業務を変えている
システムが業務に合わせるのが理想だ。「kintoneではこの処理ができないから、手動でExcelに転記している」「kintoneの仕様に合わせて承認フローを簡略化した」といった運用回避策が3つ以上あるなら、ツールが業務のボトルネックになっている。
---
kintoneの限界、感じていませんか？
御社のkintone環境を無料で診断し、移行すべきか・このまま使い続けるべきかを判断する材料をお出しします。移行する場合の概算費用と期間もその場でお伝えします。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
---
移行先の選択肢と比較
kintoneからの移行先は、大きく3つの選択肢がある。
| 比較項目 | Laravel（PHP） | Next.js（React） | スクラッチ（フルカスタム） |
|---|---|---|---|
| 得意領域 | 業務システム、管理画面、API | ユーザー向けWebアプリ、SaaS | 基幹系、大規模業務 |
| 開発期間（中規模） | 3〜6ヶ月 | 3〜6ヶ月 | 6〜12ヶ月 |
| 初期費用目安 | 500〜1,500万円 | 500〜1,500万円 | 1,000〜3,000万円 |
| 月額ランニング | サーバー1〜5万円 | Vercel/AWS 1〜5万円 | インフラ5〜15万円 |
| DB設計の自由度 | MySQL/PostgreSQLでRDB設計自在 | 同左（バックエンド次第） | 完全自由 |
| API制限 | なし（自社サーバー） | なし | なし |
| 権限設計 | フィールド単位まで自在 | 同左 | 完全自由 |
| 運用保守 | フレームワークのLTSあり | エコシステムが活発 | 自社/外注で対応 |
kintoneの年間コストが300万円を超えている場合、LaravelやNext.jsでの再構築は2〜3年で投資回収できる可能性が高い。特にLaravelは業務システムとの親和性が高く、認証、権限管理、帳票出力、バッチ処理といったkintoneが苦手とする領域を標準的にカバーできる。
移行の費用・期間・手順についてはkintone限界？Laravel移行の費用・期間・手順を完全解説で詳しく解説しています。
まとめ
kintoneは中小企業の業務デジタル化に大きく貢献するツールだが、事業成長に伴い10の技術的限界が顕在化する。プラグイン費用の膨張、JSカスタマイズの破綻、業務の本末転倒がサインだ。限界を感じたら、LaravelやNext.jsへの移行を含めた選択肢を早めに検討することが、事業の成長を止めない判断になる。
---
kintoneからの移行、まずは診断から始めませんか？
現在のkintone環境をヒアリングし、移行の必要性・最適な移行先・概算費用を無料でお伝えします。GXOの開発体制・実績はこちら、導入事例はこちらでご確認いただけます。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
---
よくあるご質問（FAQ）
Q1. kintoneからの移行にはどれくらいの期間がかかりますか？
A1. 移行先の技術スタックと業務の複雑さによりますが、LaravelやNext.jsへの移行であれば3〜6ヶ月が一般的な目安です。既存のkintoneアプリの数が多い場合は、優先度の高い業務から段階的に移行する方法が現実的です。データ移行もAPIやCSVエクスポートで対応できるため、業務を止めずに進められます。
Q2. kintoneで蓄積したデータはそのまま移行できますか？
A2. kintoneのデータはREST APIまたはCSVエクスポートで取り出せるため、移行先のデータベースに取り込むことは技術的に可能です。ただし、kintoneのフラットなデータ構造を正規化されたRDB設計に変換する作業が必要になるため、データ量とアプリ間の関連性に応じた設計工数を見込む必要があります。
Q3. 移行中もkintoneを使い続けられますか？
A3. 並行稼働は可能です。一般的な移行プロジェクトでは、新システムの構築とテストが完了するまでkintoneを本番環境として使い続け、段階的に切り替えます。切り替え時のデータ差分同期の仕組みを設計しておけば、業務への影響を最小限に抑えられます。
参考資料
- サイボウズ株式会社「kintone導入社数について」（2023年9月公表） https://kintone.cybozu.co.jp/
- サイボウズ kintone REST APIドキュメント https://cybozu.dev/ja/kintone/docs/rest-api/
- cybozu developer network「kintone REST APIの共通仕様」 https://cybozu.dev/ja/kintone/docs/rest-api/overview/
- 経済産業省「DXレポート」（2018年9月）https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_03.pdf
- IPA 情報処理推進機構「DX白書2023」（2023年2月）https://www.ipa.go.jp/publish/wp-dx/dx-2023.html
「いくらかかる？」が
30秒でわかります
Excel・Access・kintoneからの移行費用をエンジニアが概算。
補助金適用後の自己負担額もお伝えします。
- 要件が固まっていなくてもOK
- 補助金適用後の費用もわかる
- 現行システムからの移行方法を提案
メールアドレスだけでOK|営業電話は一切なし
