結論から先に。 kintoneは「小さく始めて現場が育てる」用途では今も最良のノーコード基盤です。一方で、(1)大量データの横断集計、(2)帳票の作り込み、(3)複雑な承認フロー、(4)フィールド単位の権限、(5)基幹システムとのリアルタイム連携、この5つが本格的に必要になった時点で、プラグインを積み増すより「卒業（別システムへの移行）」を検討したほうが総コストで安くなる分岐点が来ます。判断の目安は明快で、プラグイン込みの月額が「対象ユーザーの本体料金と同額かそれ以上」になったら、投資対効果を再計算するサインです。
本記事は、ネット上でよく語られる「kintoneの限界」を、サイボウズ公式ヘルプの制限値で1つずつ裏取りしたうえで、回避策とその回避策自体の限界、そして「留まる／卒業する」の判断軸まで、GXOの発注支援の現場感覚で整理したものです。よくある誤情報（「レコードは50万件で頭打ち」など）も公式仕様に照らして訂正します。
数字の出どころについて：本文中の上限値・仕様は、サイボウズ公式の「kintone制限値一覧」「サイボウズのクラウド基盤 制限事項」「kintone SIGNPOST 性能上の考慮点」を確認時点（2026年7月）で参照しています。料金・プラグイン価格は各社公式の公開値で、改定される前提で確認してください。プラグインの月額はサードパーティ製品の公表値であり二次的な参考値です。
この記事を読むべき人
- kintoneを2〜3年運用し、「最近もっさりする」「プラグインが増えすぎた」と感じ始めている経営者・事業責任者
- 現場が勝手に増やしたアプリを情シス（またはひとり情シス・兼任情シス）が抱えきれなくなっている担当者
- 「このままkintoneを拡張し続けるか、作り替えるか」を、感覚ではなく数字と要件で決めたい発注決裁者
- ベンダーから「kintoneでは無理なのでスクラッチで」と言われ、それが本当に妥当か第三者の視点で確かめたい人
逆に、利用者が数十人・データが数万件・業務がシンプルで不満が出ていないなら、この記事の後半（移行判断）はまだ読まなくて構いません。kintoneに留まるのが合理的です。
NOCODE EXIT
Bubble／kintone の限界、スクラッチ移行で解消しませんか？
ノーコードの肥大化・応答遅延・カスタマイズ限界を Laravel+Vue 移行で根治。概算費用・移行期間・データ移行設計・並行稼働プランをその場で確認できます。
前提：kintoneの「限界」は、噂ではなく公式仕様で測る
「kintoneの限界」を語る記事は多いのですが、数字が古かったり、そもそも間違っていたりするものが少なくありません。判断を誤らせる代表的な誤解を、公式仕様で先に正しておきます。
横にスクロールして確認できます
| よくある誤解 | 実際（公式仕様・確認時点） |
|---|---|
| レコードは50万件で上限に達する | レコード数に上限はない。サイボウズは「1アプリに100万件を登録した状態で快適に使用できる」ことを確認済み。ただし数万件でも権限・フィルタ次第で遅くなる |
| 一覧はいくらでも表示できる | 1つの一覧・グラフで扱えるのは各1,000件まで。全件を画面に出す設計は最初から不可能 |
| APIで一括に全部取れる | REST APIで一度に取得できるのは500件。大量データは複数回に分けて取得する設計が前提 |
| フィールドは無制限に足せる | 1アプリ500フィールドまで（ラベル等の装飾は除外）。100を超えると詳細・一覧の表示が遅くなり得る |
| 24時間止まらない | 定期メンテナンスで利用できない時間が発生する。24時間365日ミッションクリティカルな基幹には不向き |
ここが出発点です。「限界がある＝ダメ」ではなく、**「上限値を知ったうえで、その内側で設計できるか」**を問うのが正しい向き合い方です。以下、実務で本当に詰まりやすい順に10個を並べます。
限界1：複雑なリレーショナルデータの横断集計が苦手
具体的な制約
kintoneは「アプリ」単位でデータを持ちます。アプリ間の関連付けはルックアップ（参照コピー）と関連レコード（一覧表示）で行いますが、リレーショナルデータベースのような多対多・多階層の集計は標準では組めません。
- ルックアップは基本的に1件を参照してコピーする仕組みで、多対多の関係を直接は表現できない
- 関連レコード一覧に出せるのも上限があり、そこに紐づく数値を横断合計する標準機能はない
- 「顧客→案件→作業→工数」のような3階層以上をまたいだ集計は、標準機能だけでは成立しない
回避策とその限界
- プラグイン（krewData等）で集計処理を組む：可能。ただし集計は原則バッチ（定期実行）で、リアルタイム反映ではないケースが多い
- JavaScript APIで自作：可能だが、作った人しか直せない「属人化した隠しシステム」になりやすい
- 非正規化（データを冗長に持つ）：簡易には効くが、更新漏れによるデータ不整合の温床になる
どこで詰むか
製造の部品表（BOM）、物流の配送・在庫、工事の原価管理など、データ構造そのものが多階層な業務を全部kintoneに載せようとすると、集計プラグイン＋自作JSの二重メンテに追われます。「表計算の延長」で始めた業務が、いつのまにか「壊れやすい基幹システム」になっているのが典型的な失敗パターンです。
限界2：大量データ・大量アクセス時のパフォーマンス低下
具体的な制約（公式仕様で裏取り）
繰り返しになりますが、レコード数に固定上限はありません。公式は100万件まで快適動作を確認済みとしています。ただしSIGNPOST（公式の設計指針）は、「データ量 × 複雑さ（フィルタ・権限）× アクセス頻度」が掛け算で効くと明言しています。つまり件数が少なくても、複雑な絞り込み条件や細かい権限設定が重なると数万件で遅くなります。
- 1つの一覧・グラフの上限は各1,000件
- REST APIの同時接続は1ドメインあたり100、一度の取得は500件
- CSVは書き出し100MBまで、読み込みは100MB・10万行まで
- フィールドが100を超えると一覧・詳細画面の表示に遅延が出得る
回避策とその限界
公式が挙げる改善策は現実的です。アプリを期間・部署・件数で分割する／古いレコードをアーカイブ用アプリへ移す／既定の一覧をシンプルにしIDでソートする／自動実行のAPIをボタン起動に変える。ただしこれらは「重くなったので運用でしのぐ」策であり、分割すればするほど横断分析が難しくなるというトレードオフを抱えます。
どこで詰むか
「年度またぎで数年分を横断分析したい」というニーズと、「重いからアプリを分けたい」という運用が正面衝突します。ここが、kintoneを分析基盤として使い続けるかの最初の天井です。
限界3：帳票出力・印刷の作り込みができない
具体的な制約
見積書・請求書・納品書のような、レイアウトが決まった帳票の出力は標準機能にありません。レコードの印刷はブラウザの印刷に依存し、罫線や改ページ、明細行の折り返しといった細かな制御ができません。まとめて何百件もPDF化する一括出力も標準では不可です。
回避策とその限界
プリントクリエイター、RepotoneU、SVF Cloudなどの帳票プラグイン・外部サービスで対応できます。ただし帳票は月額課金が恒常的に積み上がるうえ、テンプレートの改修（税率変更、様式変更、インボイス対応など）のたびに設定作業が発生します。
どこで詰むか
帳票を「毎日・大量に・様式厳格に」出す業務（受発注、建設、卸）ほど、帳票プラグインへの依存が深くなり、後述するコスト積み上がりの主因になります。
限界4：複雑な承認ワークフローに対応しきれない
具体的な制約
標準の「プロセス管理」は一直線の承認には強い一方、以下が苦手です。
- 条件（金額・部署・区分）による承認ルートの動的な分岐
- 金額に応じた承認者の自動切り替え
- 複数人が同時に承認する並列承認
- 差し戻し後の再申請フローの柔軟な制御
回避策とその限界
JavaScriptでロジックを組むか、コラボフロー・ジョブカンワークフローなど専用ツールと連携します。ただし、ワークフローの本体を外部ツールに出すと「データはkintone、承認は別」の二重構造になり、監査証跡の一貫性が崩れやすくなります。
どこで詰むか
稟議・経費精算・与信のように金額と組織階層で分岐する承認を無理にkintoneへ寄せると、JS改修が雪だるま式に増えます。ここは「そもそもワークフロー製品を使うべき領域」だと割り切る判断が要ります。
限界5：UI・画面レイアウトのカスタマイズに天井がある
具体的な制約
- フォームは縦積みが基本で、タブ切替やアコーディオンのような凝ったレイアウトは標準では作れない
- 一覧画面やモバイル画面のデザイン自由度は低い
- トップ画面のカスタマイズは「ポータル」の枠内に限られる
回避策とその限界
CSS/JSカスタマイズや gusuku Customine のようなツールで見た目は調整できます。ただしJS/CSSでの作り込みは、サイボウズ側のアップデートで表示が崩れるリスクを常に背負います。
どこで詰むか
**社外向け（顧客ポータル、取引先入力画面）**として使おうとした瞬間に、UIの制約とブランド表現の要求がぶつかります。社内利用なら許容範囲でも、社外の目に触れる画面は別途Web開発したほうが早いことが多いです。
限界6：外部システムとのリアルタイム連携は開発が要る
具体的な制約
REST APIとWebhookは提供されていますが、エラー時のリトライや整合性担保は自前実装が前提です。会計・ERP・在庫といった基幹との双方向・リアルタイム連携には、中間サーバーかiPaaS（連携基盤）が必要になります。
回避策とその限界
Zapier、Make、DataSpiderなどのiPaaSで多くはつながります。ただしiPaaSは実行回数・データ量で課金が増え、連携が増えるほど「どこで何が同期しているか」が見えにくいブラックボックスになります。
どこで詰むか
「kintoneを基幹の一部に組み込む」構想は、連携コストが想定の数倍に膨らむ典型例です。単独のハブとして使うか、基幹の一部にするかで、必要な投資額が一桁変わります。
限界7：フィールド単位の権限（項目別の閲覧制御）が弱い
具体的な制約
レコード単位・アプリ単位のアクセス制御は可能ですが、**「同じレコードの中で、この項目はA部門に見せ、B部門には隠す」**という項目単位の制御は素直にできません。組織が「部→課→係→チーム」と深いほど、権限設計が複雑化します。
回避策とその限界
アプリを閲覧用と編集用に分ける、JSで画面上の表示・非表示を切り替える、といった回避はできます。ただしJSでの非表示は「画面に出していないだけ」で、APIやCSV書き出しでは取得できてしまうことがあり、セキュリティ要件を満たしたつもりが穴になる危険があります。
どこで詰むか
個人情報・給与・与信・カルテなど、項目レベルの秘匿が監査・法令要件になっている業務では、この制約は「回避策で頑張る」領域を超えます。ここは設計の根幹に関わるため、後述の「卒業」判断の重い一票になります。
限界8：ファイル・文書管理としては物足りない
具体的な制約
- 添付ファイルの全文検索はできない（ファイル名の検索のみ）
- バージョン管理機能がない
- フォルダ構造での整理ができない
- 添付は1ファイル1GBまでという上限がある
回避策とその限界
図面・契約書・マニュアルの管理は、Box・Google Drive・SharePointなど文書管理に特化したサービスへ寄せ、kintoneにはリンクを貼る運用が現実的です。すべてをkintoneに集約しようとすると、検索性とガバナンスの両方で行き詰まります。
限界9：レポート・分析（BI）の柔軟性が足りない
具体的な制約
標準グラフは棒・円などの基本集計に限られ、クロス集計の自由度が低く、複数アプリを横断した分析や時系列トレンド分析は標準では困難です。1つのグラフが扱えるのも1,000件までという上限が効いてきます。
回避策とその限界
krewDashboardのようなプラグインや、Tableau・Power BIなどのBIへデータを流して分析する手があります。ただしBI連携は、「集計の正解を作る」設計・運用の負荷（どのデータをどう結合し、どの粒度で見るか）を別途抱えることになります。
どこで詰むか
経営会議の意思決定資料をkintone単体で作ろうとすると、集計プラグイン＋Excel手作業のハイブリッドに逆戻りします。データに基づく経営を強めたい会社ほど、この天井に早く当たります。
限界10：プラグイン・連携費用が静かに積み上がる
具体的な制約
限界1〜9を回避するたびに、月額課金のプラグイン・iPaaSが増えていきます。kintone本体の料金は公開時点で以下の通り（税抜・1ユーザー月額、改定前提で公式要確認）。
横にスクロールして確認できます
| プラン | 月額/ユーザー | 主な制約 |
|---|---|---|
| ライトコース | 1,000円 | JavaScript/外部APIカスタマイズ不可 |
| スタンダードコース | 1,800円 | カスタマイズ・API連携可 |
| ワイドコース | 要問合せ | 1,000ユーザー以上向け |
ここに、制約を補うプラグイン費（各社公式の公開目安・二次参考値）が乗ります。
横にスクロールして確認できます
| プラグイン例（用途） | 月額目安 |
|---|---|
| 帳票出力 | 6,000円〜 |
| データ集計 | 30,000円〜 |
| ダッシュボード | 16,500円〜 |
| ノーコードカスタマイズ | 55,000円〜 |
積み上がりのイメージ（従業員30名・スタンダード＋主要プラグインを仮に全部入れた場合）
- 本体：1,800円 × 30名 ＝ 54,000円/月
- プラグイン群：おおむね10万円台/月
- 合計：月15万円前後、年間で約200万円規模になり得る
これはあくまで「フル装備にした場合」の試算で、実際は必要なものだけ入れます。ただし重要なのは、この金額帯に入ると、パッケージSaaSやローコード、場合によってはスクラッチ開発と正面から比較すべきレンジに乗るという事実です。「気づいたら本体より周辺費のほうが高い」状態は、卒業を検討すべき明確なシグナルです。
GXOの判断軸：kintoneに「留まる／卒業する」をどう決めるか
ここからがGXOの実務観点です。移行するか否かは、感覚ではなく5つの軸のスコアで決めます。各軸で「留まる側」に寄るか「卒業側」に寄るかを見てください。
横にスクロールして確認できます
| 判断軸 | kintoneに留まってよい | 卒業（移行）を検討すべき |
|---|---|---|
| データ規模と横断分析 | 単一アプリ内で完結、数万件規模、横断集計は軽い | 多階層データを横断集計、数十万件で体感が重い |
| プロセスの複雑さ | 承認・権限がシンプル | 金額分岐の承認、項目別権限、監査要件がある |
| 外部接続 | kintone単独のハブとして使う | 基幹とリアルタイム双方向で密結合が必要 |
| コスト構造 | プラグイン込みでも本体料金の範囲に収まる | 周辺費が本体費と同額以上に膨らんでいる |
| 提供範囲 | 社内利用が中心 | 社外ユーザー・顧客向け画面を出す |
目安：卒業側が2つ以上に該当したら、いったん立ち止まって投資対効果を再計算する。3つ以上なら移行の具体検討に入る。 とくに「項目別権限が法令・監査要件」と「社外提供」は、回避策の限界がセキュリティ事故に直結するため、1つでも該当すれば重く見ます。
失敗パターンとして最も多いのは、「せっかく作り込んだから」というサンクコストで判断を先延ばしにすることです。作り込みが深いほど移行は重くなるので、先延ばしは問題を大きくします。判断は「作り込む前」か「限界が見え始めた今」が最もコストが低いタイミングです。
卒業する場合：移行コストの目安と「見積もりの読み方」
移行を決めたら、移行先ごとに費用・期間が大きく変わります。以下は一般的な費用感（相場の目安であり、要件で上下します）。
横にスクロールして確認できます
| 移行先 | 費用目安 | 期間目安 | 向いているケース |
|---|---|---|---|
| パッケージ／SaaS | 50万〜200万円 | 1〜3ヶ月 | 業務が標準的でカスタマイズが少ない |
| ローコード開発 | 200万〜500万円 | 2〜4ヶ月 | ある程度の作り込みが要る |
| スクラッチ／Web開発 | 500万〜1,500万円 | 4〜8ヶ月 | 完全に自社業務へ合わせたい |
見積もりを読むときに絶対に外してはいけない観点を挙げます。ここがブレると、後から「追加費用」が雪崩れます。
- データ移行費が別建てになっていないか：kintoneはデータ構造が独自なので、移行の最大工数はほぼ常にデータの変換・名寄せ・クレンジングです。ここを「別途お見積り」で空欄にした提案は危険信号です。
- プラグインで実現していた機能の「作り直し費」が入っているか：帳票・集計・ワークフローは、kintoneではプラグインで賄っていた分を新システムで再実装する必要があります。見積もりにこの再現コストが含まれているか確認します。
- 保守・運用・改修費が初期費とは別に明示されているか：初期の開発費だけ安く見せ、運用フェーズで回収する見積もりは、総保有コストで比較すると割高になりがちです。
- 並行稼働（旧新の二重運用）期間の運用負荷が織り込まれているか：切り替えは一夜にはできません。並行期間の現場負荷を誰が持つかが抜けると、移行が現場で頓挫します。
GXOが発注支援で徹底するのは、**「開発費の安さ」ではなく「データ移行＋機能再現＋運用まで含めた総額の比較可能性」**です。見積もりの粒度が各社バラバラなままだと、そもそも比較できません。比較できる粒度に揃える整理は、システム開発・要件定義の相談の入口で最初に行う作業です。
発注前チェックリスト（kintone卒業・システム再構築を進める前に）
外部ベンダーに相談する前に、社内でここまで埋めておくと、見積もりのブレと手戻りが大きく減ります。
- 現状のアプリ一覧・利用者数・データ件数・使用プラグインを棚卸ししたか
- プラグイン込みの月額合計を、本体料金と並べて計算したか
- 「絶対に必要な要件」「将来ほしい要件」「今回はやらない要件」を3段で分けたか
- 帳票・集計・ワークフロー・権限のうち、どれが移行の必須要件かを特定したか
- 項目別権限・社外公開など、セキュリティ・監査の要件を明文化したか
- 既存データの構造（アプリ間の参照関係）を図で整理したか
- 移行先候補（SaaS／ローコード／スクラッチ）を、上の判断軸でスコア化したか
- 見積もりに「データ移行費」「機能再現費」「保守運用費」が別建てで入っているか
- 旧新の並行稼働期間と、その間の運用責任者を決めたか
- 検収条件（機能・性能・セキュリティ・ドキュメント）を先に定義したか
ベンダーに必ず聞くべき質問（第三者検証の観点）
「kintoneでは無理なのでスクラッチで」という提案が来たとき、それが妥当か見極める質問です。ベンダー選びは、答えの中身より答え方の誠実さで判断できます。
- 「kintone＋プラグインで、あと何年・いくらまで延命できますか」——いきなり全面刷新を勧める前に、延命案とその限界を説明できるか。
- 「移行の最大工数はどの作業ですか」——「データ移行」と即答できないベンダーは、移行の勘所を分かっていない可能性がある。
- 「今プラグインで実現している機能を、新システムでどう再現しますか」——帳票・集計・ワークフローの再現方針を具体的に語れるか。
- 「並行稼働はどれくらい必要で、その間の現場負荷は誰が持ちますか」——切り替えの現実を織り込んでいるか。
- 「引き継ぎ時に、ソースコード・設計書・データ定義は誰のものになりますか」——ベンダーロックインを避けられる契約か。
これらに具体的に答えられないまま高額な刷新を勧めてくる場合は、AI導入可否アセスメント（要件と投資対効果の壁打ち）のような第三者の整理を挟んで、提案の妥当性を確かめてから発注するのが安全です。AIやデータ活用まで見据えた要件なら、投資判断の前に見積もりの前提そのものを検証しておく価値があります。
GXOに相談すべきタイミング
次のいずれかに当てはまるなら、記事を読み進めるより、早めに現状を整理したほうが安全です。
- プラグイン込みの月額が本体料金と同額以上に膨らんでいる
- 「重い」「遅い」の声が現場から上がり、アプリ分割でしのいでいる
- 項目別権限や社外公開など、回避策の限界がセキュリティ要件に触れている
- ベンダーから全面刷新を勧められたが、妥当性を第三者で確かめたい
- 社内稟議で、留まる／卒業するの費用対効果を数字で説明する必要がある
GXOは、kintoneの利用状況の棚卸しから、留まる場合の最適化（不要プラグインの整理・設計見直し）、卒業する場合の要件定義・RFP設計・見積もり比較・移行先選定・開発・運用まで、DXシステム開発の進め方に沿って一貫して支援します。特定ベンダーの製品を売るためではなく、自社にとっての総保有コストが最小になる選択を一緒に見極めるのが役割です。
※ 営業電話はしません ｜ オンライン対応可 ｜ 相談だけでもOK
FAQ
kintoneのレコードは何件まで登録できますか？
固定の上限はありません。 サイボウズは1アプリに100万件を登録した状態で快適に使用できることを確認済みと公表しています。ただし件数が少なくても、複雑なフィルタや細かい権限設定が重なると数万件で体感が重くなることがあります。「上限」より「快適に使える設計かどうか」で考えてください。
一覧に全データを表示できないのはなぜですか？
1つの一覧・グラフで扱える件数は各1,000件までという仕様の上限があるためです。全件を1画面に出す設計はもともと想定されていません。絞り込み・ページングを前提に運用します。
プラグインを足せば、できないことはすべて解決しますか？
機能面はかなり補えます。ただし、(1)月額課金が恒常的に積み上がる、(2)自作JSは属人化・アップデートで崩れるリスクがある、(3)JSでの項目非表示はAPI経由では見えてしまう場合がある、という「回避策そのものの限界」が残ります。回避策を積むほど、卒業時の移行も重くなります。
いつkintoneを「卒業」すべきですか？
本文の5つの判断軸で、卒業側に2つ以上該当したら投資対効果を再計算、3つ以上なら移行の具体検討に入るのが目安です。特に「項目別権限が監査要件」「社外ユーザーへの提供」は、1つでも該当すれば重く見ます。
移行で一番お金と時間がかかるのはどこですか？
ほぼ常に**データ移行（構造の変換・名寄せ・クレンジング）**です。kintoneはデータ構造が独自なので、ここを軽く見積もった提案は後から追加費用が膨らみます。見積もりでデータ移行費が別建て・具体化されているかを必ず確認してください。
社内だけで移行判断を進めても大丈夫ですか？
アプリとデータの棚卸しは社内でできます。ただし、要件定義・見積もり比較・移行先選定は、各社の見積もり粒度を揃えないと比較できず、ベンダー主導になりがちです。発注前に第三者で粒度を整える価値が高い領域です。
この記事のまとめ
kintoneの限界は「弱点」ではなく「設計の境界線」です。上限値を公式仕様で正しく把握し、境界の内側で設計できるうちは留まる、境界を越える要件（横断集計・帳票・複雑承認・項目別権限・リアルタイム連携・社外提供）が本格化したら卒業を検討する——この線引きを、サンクコストではなく数字で行うことが、コスト膨張と手戻りを防ぐ唯一の方法です。判断に迷う段階でこそ、棚卸しと要件整理を先に済ませておくと、後戻りの少ない意思決定ができます。
参考にした一次・公式情報
制度・価格・仕様は改定されます。本記事の数値は確認時点（2026年7月）のものであり、発注判断の際は各公式ページで最新値を再確認してください。プラグイン価格は各サードパーティ公式の公開値（二次参考値）です。
