kintoneからの移行を考えるタイミング

Excel台帳の限界を感じてkintoneに移行し、しばらく順調に運用してきた。でも最近、アプリの動きが少し重い気がする。他部署からの「あの機能も欲しい」という要望に、標準機能だけでは応えきれなくなってきた。プラグインや外部連携を足すたびに、構成がどんどん複雑になっている気がする——。そんな感覚を抱きはじめた担当者に向けて、この記事を書きました。

結論を先に言うと、「kintoneが遅くなった」「複雑な要望が増えた」というだけで、即座に他システムへの移行を決断する必要はありません。多くの場合、運用の見直しや設計の整理で解決できます。一方で、いくつかの兆候が重なっている場合は、移行を具体的に検討し始めるべきタイミングに来ています。本記事では、その見極め方を一次情報に基づいて整理します。特定のツールを貶めたり、逆に移行を煽ったりする意図はなく、あくまで判断材料を提供することが目的です。料金・仕様は変更される可能性があるため、本記事の数値は執筆時点(2026年8月)にサイボウズ公式サイト・公式ヘルプで確認できた内容として扱ってください。

なお、「Excelからkintoneへの移行」を検討している段階の方は、本記事ではなくノーコード・ローコードの比較記事や、実際の移行手順とコストを解説した別記事(kintoneでExcel台帳を置き換える手順と費用感)をご覧ください。本記事は「すでにkintoneを導入して運用している」ことを前提に、そこから先、他システムへの移行を考えるべきかどうかを扱います。

kintoneは中小企業のノーコード・ローコードツールとして広く使われており、Excel運用からの脱却先として選ばれるケースが非常に多いツールです。だからこそ、導入して数年が経過し、事業が成長したり組織の要件が複雑化したりする過程で、「このまま使い続けてよいのか」という迷いが生じるのは自然なことです。この迷いに、闇雲に不安を感じる必要はありません。本記事で挙げる観点に沿って、一つずつ確認していきましょう。

この記事で分かること

この記事では、次の流れで解説します。

• kintoneからの移行を考え始める7つのサイン
• サインが出たときにまず確認すべきこと(移行の前に、運用改善で解決できないか)
• kintoneの公式な仕様上限(レコード数・フィールド数・API制限)
• 移行を検討する場合の3つの選択肢
• 移行を「決めない」という判断も含めた検討フロー
• 費用感と検討にかかる期間の目安
• よくある失敗パターン

順を追って見ていきます。

kintoneからの移行を考え始める7つのサイン

まず、どんな状態になったら「そろそろ移行を検討すべきか」を考え始めればよいのか、典型的なサインを7つ挙げます。1つでも当てはまったら即移行、というわけではありません。複数のサインが同時に重なっているかどうかが、検討の緊急度を判断する目安になります。

1. 動作が明らかに遅くなった。レコード一覧の表示やグラフの描画に、体感で数秒以上かかるようになった
2. 標準機能とプラグインの組み合わせだけでは要件を満たせなくなった。外部システムとの連携や、複雑な計算処理が必要になってきた
3. API連携が制限に引っかかるようになった。夜間バッチや他システムとの同期処理でエラーが出るようになった
4. アプリの数が増えすぎて、どれが「正」のデータか分からなくなってきた
5. 月額のライセンス費用が、当初の想定より大きく膨らんでいる。ユーザー数の増加やプラグイン追加が積み重なった結果
6. 現場から「もっとこういう画面がほしい」という要望が繰り返され、その都度カスタマイズで対応している
7. 事業の成長に伴い、他の基幹システム(会計・在庫・販売管理など)との一体的な連携が必要になってきた

実務上の視点: このリストで最も見落とされやすいのは4番目です。kintoneは1つのライトコース契約で200個、スタンダードコースで1,000個までアプリを作成できます(サイボウズ公式サイトによる、2026年8月時点の目安)。上限に達していなくても、部署ごとに似たようなアプリを作り続けた結果、「どのアプリが最新の正式データか分からない」という属人化に近い状態に陥っているケースは珍しくありません。これはkintone自体の限界というより、運用ルールが追いついていない状態です。

7つのサインを、もう少し具体的な業務シーンに落とし込むと次のようなイメージになります。実際にあなたの会社で起きていることと照らし合わせてみてください。

• 顧客管理アプリのレコード一覧を開くたびに、読み込みに数秒〜十数秒かかるようになり、現場から「重い」という声が出ている
• 「他部署のあの業務にもkintoneを使いたいが、今のプランのアプリ数上限に近づいている」と情シス担当者が気づいた
• ECサイトの受注データをkintoneに自動連携する仕組みを組んだが、注文件数が増えた月にエラーが頻発するようになった
• 「見積書アプリ」「見積書アプリ(改)」「見積書アプリ_2025」のように、似た名前のアプリが乱立し、どれを更新すればよいか新人が迷う
• 半年前に10ユーザーで契約したライトコースが、気づけば30ユーザーに増えており、当初の想定より月額費用が3倍近くになっている
• 営業部から「案件ごとの粗利を自動計算するグラフが欲しい」という要望が続き、その都度プラグインや外部サービスを追加してきた結果、誰も全体構成を把握できなくなっている
• 生産管理や在庫の引当処理など、条件分岐が複雑な業務をkintoneの計算フィールドとワークフロー機能だけで無理やり再現しようとしている

これらは実際に中小企業のひとり情シス・総務兼任担当者からよく聞かれる状況です。1つだけであれば運用の工夫で乗り切れることが多い一方、3つ以上重なっている場合は、次章以降の確認を早めに始めることをおすすめします。

サインが出ても、まず確認すべきこと

7つのサインのうち1つか2つに心当たりがある、という段階であれば、いきなり移行を検討するのではなく、まず次の3点を確認してください。多くの場合、ここで解決します。

確認1: 動作の重さは、レコード数・フィールド数が原因か

kintone公式のヘルプ・制限事項ページによれば、kintoneには登録レコード数そのものの上限値は設けられていません。ただし、登録レコード数が多くなるとパフォーマンスに影響が出る場合があるとされており、1つのアプリに100万件のレコードを登録した状態でも快適に使用できることが確認されている、と案内されています。つまり、数百〜数千件程度の規模で動作が重いと感じている場合、レコード数そのものが原因である可能性は低く、次のような別の要因を疑うべきです。

• 1つの画面に表示するフィールド数が多すぎる、または不要な集計・グラフを多用している
• ルックアップやフィールド参照が複数アプリをまたいで連鎖している
• 添付ファイル(画像・PDFなど)を大量に、しかも高解像度のまま保存している

フィールド数については、公式の制限事項として1アプリあたり500個までという上限が明記されています。この上限に近づいている場合、そもそも1つのアプリに情報を詰め込みすぎている設計上の問題である可能性が高く、アプリを機能単位で分割することで解決できる場合があります。

確認2: 複雑な要望は、本当に「今」必要か

現場からの要望が積み重なると、つい全部に対応しようとしてしまいますが、要望のすべてが事業上重要とは限りません。次の観点で棚卸しをしてみてください。

この棚卸しをせずに要望を都度カスタマイズで積み上げていくと、後述する「移行しない」という選択肢を取った場合にも、運用がさらに複雑化してしまいます。移行を検討するかどうかにかかわらず、一度この整理をしておく価値があります。

確認3: API制限は、設計の見直しで回避できないか

外部システムとの連携で夜間バッチ処理がエラーになる、というサインが出ている場合、原因の多くはAPIの呼び出し方にあります。kintoneの開発者向け公式ドキュメント(cybozu developer network)によれば、レコード取得APIで一度に取得できるレコード数は最大500件で、limitパラメーターの初期値は100件です。大量データを扱う連携処理では、この上限を意識せずに1件ずつAPIを呼び出していたり、ページネーション(offsetによる分割取得)の実装が非効率だったりするケースがよくあります。

実務上の視点: offsetパラメーターには上限があり、公式ドキュメントによれば10,000件までとされています。10,000件を超える範囲を取得したい場合は、offsetを使わずカーソルAPIなど別の取得方法に切り替える必要があります。この制約を知らずに設計されたバッチ処理は、データ量が増えた段階で必ずエラーに突き当たります。まずは自社の連携処理がこの制約内で組まれているかを、開発を担当した会社に確認することをおすすめします。

これら3つの確認をした上で、「運用の見直しでは解決しない」という結論に至った場合に、初めて移行の検討に進みます。

確認1〜3を実際に行う際は、担当者ひとりで抱え込まず、次のような役割分担で進めると精度が上がります。

特にAPI連携部分は、当初の構築を外部の開発会社に依頼しているケースが多く、担当者だけでは原因の切り分けが難しいことがあります。契約している保守契約の範囲内で調査を依頼できないか、まず確認するとよいでしょう。

kintoneの公式な仕様上限(2026年8月時点)

移行を検討する際の判断材料として、kintoneの主な仕様上限を一覧にまとめます。数値は変更される可能性があるため、最新の情報は必ずサイボウズ公式サイト・公式ヘルプでご確認ください。

この一覧を見て分かる通り、多くの中小企業の業務規模であれば、レコード数やフィールド数そのものが移行の直接的な理由になることは、実はそれほど多くありません。移行を後押しする要因になりやすいのは、むしろ「API連携の設計上の制約」「アプリ数増加に伴う管理コストの増大」「月額費用の積み上がり」といった、仕様上限そのものより一段抽象度の高い課題であるケースが目立ちます。

それでも移行を検討すべき3つのケース

前章までの確認を経てもなお、次のいずれかに当てはまる場合は、他システムへの移行を具体的に検討する価値があります。

ケース1: 会計・在庫・生産管理など、専門性の高い基幹業務を担わせようとしている

kintoneはノーコードで柔軟にアプリを作れる汎用データベースツールであり、会計処理や複雑な在庫引当・生産管理のような、業界特化の専門ロジックを前提とした業務には本来向いていません。四則演算や基本的な関数を組み合わせた計算フィールドは作れますが、複雑な条件分岐や大量データの高速な一括処理が必要な業務では、標準機能やプラグインでの対応に限界が出やすくなります。この場合の選択肢は、その業務領域に特化したパッケージシステムの導入か、フルスクラッチ開発開発になります。

ケース2: 外部システムとの連携が事業の中核になっている

社内の1業務を管理するだけでなく、複数の外部システム(ECサイト、会計ソフト、生産管理システムなど)とリアルタイムに近い形でデータを同期させる必要が出てきた場合、kintoneのAPI制限(1日10,000リクエスト、一度の取得最大500件)が実務上のボトルネックになる可能性があります。連携するシステムの数が増えるほど、この制約への抵触リスクは高まります。

ケース3: 保有しているデータそのものが、事業の重要な資産になっている

顧客データや取引履歴が数十万件規模になり、それ自体が事業の競争力を左右する資産になっている場合、汎用ツールの標準的な検索・分析機能では物足りなくなることがあります。自社専用の分析基盤やダッシュボードが必要になってきた段階は、移行を検討する現実的なタイミングの1つです。

このケースでは、レコード数自体が公式の推奨目安(1アプリ100万件)を超えているかどうかよりも、「そのデータをどう活用したいか」が判断の分かれ目になります。単純な検索・一覧表示だけであればkintoneのままで問題なく運用できる規模でも、複数アプリをまたいだ横断的な集計や、機械学習を用いた需要予測のような高度な分析を行いたい場合は、汎用データベースツールの標準機能では対応しきれず、専用の分析基盤(データウェアハウスやBIツールとの連携を前提とした設計)が必要になります。

3ケースに当てはまらない場合の考え方

逆に言えば、上記3ケースのいずれにも当てはまらない場合は、移行を急ぐ必要は薄いと考えてよいでしょう。よくある誤解として、「kintoneを使い続けているのは、なんとなく古い・遅れている感じがする」という漠然とした印象だけで移行を検討してしまうケースがあります。しかし、道具の新旧と自社業務への適合度は別の話です。現状の業務に過不足なく対応できているのであれば、無理に乗り換える理由はありません。

移行先の3つの選択肢

移行を検討すると決めた場合、主な選択肢は次の3つに整理できます。それぞれメリット・デメリットが異なるため、自社の状況に照らして選ぶ必要があります。

• 他のノーコード・ローコードツールへの乗り換え: ノーコード・ローコードという枠組み自体は維持しつつ、より自社の業務特性に合ったツールに移る選択肢です。移行コストは比較的抑えられますが、乗り換え先でも将来同様の限界に突き当たる可能性は残ります
• 業務特化型のパッケージシステムの導入: 会計・生産管理・在庫管理など、専門領域に特化した既製システムを導入する選択肢です。業界標準の機能が最初から揃っている反面、自社独自の業務フローに完全には合わない場合があります
• フルスクラッチでの開発: 自社の業務に合わせて一から設計・開発する選択肢です。最も柔軟性が高く、将来のベンダーロックインのリスクをソースコードの権利関係の交渉次第で下げられますが、開発期間・費用が他の選択肢より大きくなる傾向があります

どの選択肢を取るにしても、現在kintoneに蓄積したデータを移行先に持ち出せるかどうかの確認が欠かせません。kintoneは標準機能でCSV形式でのデータエクスポートに対応しているため、データポータビリティの観点では比較的移行しやすいツールに分類されます。ただし、添付ファイルや複雑なルックアップ関係を含むデータの移行では、単純なCSV出力だけでは不十分な場合があるため、実際の移行手順や注意点は別記事(自社システムのデータを吸い出せるか確認する方法)で詳しく解説しています。

移行を「まだしない」という判断も、立派な選択肢

ここまで移行検討の観点を挙げてきましたが、最も伝えたいのは「サインが出た=すぐ移行すべき」ではないという点です。移行には相応の費用・期間・現場の学習コストがかかります。次のような状態であれば、当面はkintoneの運用を見直しながら使い続けるという判断も十分に合理的です。

• サインが1〜2個で、確認1〜3で挙げた運用改善によって解消の見込みがある
• 現状の課題が一部の部署・一部の業務に限られており、全社的な影響が小さい
• 今後1〜2年の事業計画において、業務規模や連携要件の急拡大が見込まれていない

移行するかどうかを決めきれない場合は、いきなり移行プロジェクトを立ち上げるのではなく、まず自社の業務全体を俯瞰するシステム管理台帳を整備し、どのシステムにどんなデータがあり、どこにボトルネックが生じているかを可視化することをおすすめします。全体像が見えないまま部分的な判断を重ねると、結果的に「なんとなく不安だから移行する」という根拠の薄い意思決定になりがちです。

実務上の視点: 経営層に移行の是非を説明する際は、「kintoneが悪い」という説明の仕方は避けたほうが無難です。むしろ「事業の成長・要件の変化によって、当初導入した規模を超えてきた」という前向きな理由として説明するほうが、稟議や予算確保の場面で受け入れられやすくなります。

検討にかかる期間と費用感の目安

移行を具体的に検討する場合、大まかな流れと期間感は次のようになります。あくまで一般的な目安であり、業務の複雑さやデータ量によって大きく変わります。

1. 現状棚卸し・要件整理(2〜4週間): 現在kintoneで管理している業務・データ・連携先をすべて洗い出す
2. 移行先候補の比較検討(2〜4週間): パッケージシステムの選定、または開発会社への相談・見積もり取得
3. PoC・試験導入(1〜2ヶ月): 本格移行の前に、小規模な範囲で実現可能性を検証する
4. 本移行・並行運用(移行規模による): 段階的にデータ・業務を移し、一定期間は旧環境と並行稼働させる

費用感については、乗り換え先のツール・システムの性質によって幅が大きすぎるため、本記事では具体的な金額を示しません。パッケージシステムであれば導入費用とライセンス費用、フルスクラッチであれば要件定義から本稼働までの開発費用がかかります。詳細な見積もりの読み方や外注の進め方については、外注のはじめかたカテゴリの記事群を参考にしてください。

なお、移行の検討期間中もkintoneのライセンス費用は発生し続けます。並行運用の期間が長引くほど、kintoneと移行先の両方の費用がかかる二重コストの期間も延びるため、検討開始の段階でおおよそのスケジュール感を社内で共有しておくことをおすすめします。特に、稟議や予算確保のプロセスに時間がかかる会社では、「検討を始めてから実際に稟議が通るまで」の期間も見込んで、全体スケジュールを逆算しておくと後工程で慌てずに済みます。

部門・業種によって判断が分かれるポイント

kintoneからの移行検討は、どの部門がどんな業務で使っているかによって、判断基準が変わってきます。ここでは代表的な3つのパターンを挙げます。

営業・案件管理での利用

案件管理や見込み客管理でkintoneを使っている場合、移行を検討する主なきっかけは、案件数の増加そのものよりも、マーケティングオートメーションやCRM機能(メール配信の自動化、商談確度のスコアリングなど)への要望が強まることです。この領域は専門特化型のSaaSが多数存在するため、フルスクラッチより先に、専業ツールへの乗り換えを比較検討する価値があります。

総務・バックオフィス業務での利用

勤怠管理・経費精算・稟議申請などのバックオフィス業務で使っている場合、法改正への対応(労働基準法や税制の変更など)が専業ベンダーの製品では自動的にアップデートされるのに対し、kintoneの自社構築アプリでは都度手動で改修が必要になる点が、移行検討のきっかけになりやすい傾向があります。法改正対応の頻度が高い業務領域では、自社でメンテナンスし続けるコストと、専業SaaSのライセンス費用を比較する視点が有効です。

生産・在庫・物流での利用

製造業や卸売業で、在庫管理・生産管理にkintoneを使っている場合、事業拡大に伴って複数拠点・複数倉庫の在庫をリアルタイムに近い形で同期する必要が出てくると、前述のAPI制限(1アプリ1日10,000リクエスト)がボトルネックになりやすい領域です。拠点数・SKU数が今後どう増える見込みかを事業計画と照らし合わせ、増加が見込まれるなら早めに移行検討を始めたほうが、後になって慌てて移行するよりも落ち着いて選定できます。

移行を検討する際に社内で合意しておきたいこと

移行の是非を検討するプロセスでは、担当者の技術的な判断だけでなく、経営層・現場部門との合意形成が欠かせません。検討を始める段階で、次の3点を関係者と共有しておくと、後々の手戻りを防げます。

• なぜ今、移行を検討するのか(前章までの7つのサイン・3つのケースのうち、どれに該当しているか)
• 移行しない場合に想定されるリスク(現状のまま使い続けた場合、いつ頃どんな支障が出そうか)
• 移行する場合の概算期間・概算費用のレンジ(具体的な金額が出せない初期段階でも、桁感だけは共有する)

これらを共有せずに検討を進めると、いざ移行の意思決定をする段になって「そもそもなぜ移行するのか」を経営層に一から説明し直すことになり、時間をロスします。検討の初期段階からメモや簡単な資料として残しておくことをおすすめします。

よくある失敗パターン

移行検討の過程で陥りやすい失敗パターンを、あらかじめ共有しておきます。

• 勢いで移行を決めてしまい、現状の業務要件を十分に洗い出さないまま開発会社に相談する。結果として、移行先でも同じような使いにくさを再現してしまう
• 一部の担当者の不満だけを根拠に、全社的な移行プロジェクトを立ち上げてしまう。現場の合意形成が不十分なまま進めると、移行後に定着しない
• 移行先を1社だけに絞って検討し、相見積もりを取らないまま契約してしまう。結果的に、移行してもなお特定の1社に依存する状態(ロックイン)を再生産してしまう
• kintoneに蓄積した数年分のデータを、移行直前になって初めてエクスポートしようとする。添付ファイルやルックアップ関係が複雑な場合、想定より時間がかかり、移行スケジュール全体に影響する

特に最後の点は見落とされがちです。移行を検討し始めた段階で、並行して現状データのバックアップ・エクスポート可否の確認だけは先に済ませておくと、後工程がスムーズになります。

まとめ

kintoneからの移行を考えるタイミングは、「動作が重い」「要望が複雑化した」という単一のサインだけで判断するのではなく、複数のサインが重なっているか、そして運用改善で解決できる範囲を超えているかを見極めることが重要です。公式に案内されている仕様上限(レコード数・フィールド数・API制限)を踏まえると、多くの中小企業の業務規模では、仕様上限そのものよりも設計・運用面の課題が移行検討のきっかけになりやすい傾向があります。

移行を決める前に、まず自社の現状を棚卸しし、運用改善で解決できる部分とできない部分を切り分けてください。それでも移行が必要だと判断した場合は、データを外部形式で持ち出せるかどうかを確認したうえで、複数の移行先候補を比較検討することをおすすめします。

kintoneへの移行そのものの手順や費用感を知りたい方は、「kintoneでExcel台帳を置き換える手順と費用感」の記事もあわせてご覧ください。また、移行先の選定で開発会社への外注を検討する場合は、外注のはじめかたカテゴリの記事群で、見積もりの読み方や発注前の準備を解説しています。