kintoneを導入して1年。当初の想定ほど使われていない、あるいは「この業務には使えない」という声が現場から上がってきた——この段階で相談を受けることがあります。

ここで即座に「別のツールへ移行しよう」と判断するのは早計です。「合わない」と言われている原因の多くは、製品の制約ではなく設定と運用にあります。原因を切り分けずに移行すると、移行先でも同じ問題が再現します。実際、移行してから「結局同じだった」という結末は珍しくありません。

一方で、本当にプラットフォームの制約に当たっているケースも存在します。その場合は早めに判断したほうが損失は小さくなります。そして移行を決めるなら、事前に知っておくべき重要な事実があります。kintoneから持ち出せないデータが、公式ヘルプに明記されているという点です。

本記事では、原因の切り分け方、移行前に試すべきこと、そして移行を決めた場合に何が失われるのかを整理します。なお本記事はkintoneの評価を下げることを目的としていません。「合わない」ことは製品の欠陥ではなく、適用領域の問題です。

「合わない」には3つの型がある

①設定・運用が合っていない

最も多い型です。製品はその業務に適しているのに、設定や運用の設計が業務と噛み合っていない状態を指します。

典型的な兆候は、現場が「入力項目が多すぎる」「どこに何を入れるか分からない」と言っているケースです。これはアプリ設計の問題であり、項目を絞り、入力順を業務手順に合わせ、不要な必須指定を外せば解決します。この型を「合わない」と判断して移行すると、移行先でも同じアプリを作り直すだけです。

もうひとつ多いのが、既存の業務手順をそのままアプリ化してしまったケースです。紙やExcelの時代に生まれた手順には、当時の制約に由来する無駄が含まれています。それを忠実に再現すると、デジタル化したのに手間が減らないという結果になります。

②プラットフォームの制約に当たっている

本当に製品の適用範囲を超えている型です。判断の目安は、標準機能でもプラグインでも実現できず、回避策の運用負荷が許容できない状態にあるかどうかです。

具体的には、多段階の条件分岐を伴う複雑な計算、大量データの一括処理、ミリ秒単位の応答が必要な処理、極めて自由度の高い画面レイアウトなどが該当します。これらはkintoneに限らず、業務アプリ基盤型のツール全般に共通する制約です。

データ量の制約も確認してください。公式の価格ページでは、APIリクエスト数の上限がプランごとに定められており、スタンダードコースで1日1万、ワイドコースで1日10万とされています。外部システムと頻繁に同期する構成では、この上限が実質的な設計制約になります。

③そもそも用途が合っていない

導入の目的設定を誤っている型です。kintoneは自社の業務に合わせて作る業務アプリ基盤であり、特定業務に最適化された専用製品とは性格が異なります。

会計、給与、人事のように業務が標準化され法改正への追随が必要な領域では、専用パッケージのほうが適しています。逆に、CRMやマーケティングのように顧客との接点データを軸に営業・マーケ・サポートを横断させたい場合は、その用途に設計された製品のほうが早く成果に到達します。「何でも作れる」ことは「何にでも最適」を意味しません。

移行を検討する前に確認すべきこと

標準機能・プラグインで解決しないか

移行の判断に入る前に、現在の実装が最適かを一度確認してください。とくに次の3点は、見直すだけで印象が変わることがあります。

第一に、アプリを分けすぎていないか。関連する情報が複数アプリに散らばると、入力も参照も手間が増えます。第二に、一覧とグラフの設定が業務に合っているか。よく使う絞り込みを保存した一覧として用意するだけで、日常の操作は大きく変わります。第三に、プラグインや連携サービスで代替できないか。標準機能にない要件が、拡張で満たせる場合があります。

業務側を変えられないか

これは受け入れられにくい提案ですが、実務では効果があります。属人的な業務をそのままアプリ化すると、属人性がシステムに固定化されます。「この案件だけ手順が違う」という例外が多い業務は、どのツールに移行しても同じ困難に直面します。

移行を検討する前に、業務手順そのものを標準化できないかを検討してください。例外の数を減らせれば、現在のツールのままで解決する可能性があります。

併用という選択肢

全面移行か継続かの二択で考える必要はありません。合っている業務はkintoneのまま残し、合わない業務だけを別の手段に切り出す構成は実務的です。

たとえば、社内の申請・台帳管理はkintoneで継続し、顧客との接点管理はCRMへ、要件が固まっていない新規業務の検証はAIアプリビルダーで、といった分担です。移行コストを最小化しながら、制約を回避できます。ただしツールが増えるほど棚卸しと権限管理の負担は上がるため、管理ルールは先に決めてください。

移行を決めたら：持ち出せないデータを先に把握する

公式に「書き出せない」と明記されているもの

ここが移行検討で最も見落とされる点です。kintone公式ヘルプには、ファイルに書き出せないデータが明記されています。移行計画を立てる前に必ず確認してください。

この表が示す事実は明確です。移行できるのは基本的に「レコードの値」だけで、業務の運用ロジックは移行できません。承認フロー、権限、通知、計算式は移行先で再構築することになります。したがって移行コストの中心はデータ移送ではなく、業務ロジックの再実装です。

添付ファイルは実務上とくに重要です。契約書や図面をレコードに添付して運用している場合、CSVには含まれないため別途取得する手段を用意する必要があります。件数が多い場合はAPIを使った取得を検討することになり、その工数も見積もりに含めてください。

出力形式にも癖がある

書き出せるデータであっても、そのままの形で移行先に入るとは限りません。公式ヘルプの補足事項には、出力形式に関する注意点が記載されています。

まずテーブル（サブテーブル）を含むレコードは、1レコードが複数行に分かれて出力されます。移行先が1レコード1行を前提とする構造なら、変換処理が必要です。次に、チェックボックスや複数選択のフィールドは選択肢ごとに列が分かれ、選択されたものに「1」が出力されます。移行先のデータ構造によっては、この形式を元に戻す処理が要ります。

細かい点では、数値フィールドの桁区切りや単位記号は出力されません。日付は言語設定によって「年/月/日」と「月/日/年」が変わります。リッチエディターの内容は一部の文字が文字参照で出力されることがあります。いずれも一括変換で対処できますが、変換を設計せずに移行を始めると、データの不整合として後から発覚します。

もうひとつ実務上の制約として、書き出すファイルが100MBを超えると書き出しに失敗すると明記されています。大量データを扱う場合は、フィールドやレコードを絞って分割する必要があります。

書き出しには権限が必要

見落とされやすい点ですが、ファイル書き出しはアプリのアクセス権設定で付与される権限であり、公式ヘルプによれば初期状態ではアプリ作成者のみが持ちます。また閲覧権限のないレコードやフィールドは書き出せません。

移行担当者が全アプリの書き出し権限を持っているかを、計画段階で確認してください。アプリ作成者が退職している場合、権限の再設定から始める必要があります。

移行コストは何で決まるか

ここまでの内容を踏まえると、移行コストを左右する要因が見えてきます。データ件数は主要因ではありません。

見積もりを取る際は、件数ではなくアプリ設定の複雑さを提示してください。「レコード5万件」という情報だけでは、正確な見積もりは出ません。

部分移行という現実解

全面移行の負担が大きいと判明した場合、対象を絞る方法があります。実務では、次の順序で切り出すと影響が小さく済みます。

最初に切り出すべきは、他のアプリとの関連が少なく、添付ファイルを持たず、プロセス管理を使っていないアプリです。この条件を満たすアプリは、レコードの値さえ移せば移行が完了します。逆に、承認フローが組まれ、他アプリを参照し、添付ファイルを多数持つアプリは最後に回します。

並行運用の期間をどう扱うかも決めておいてください。移行の失敗で最も多いのは、新旧が併存したまま定着してしまうことです。二重運用は現場の負担を増やすだけで、効果はマイナスになります。移行日を決め、旧アプリを参照専用にしたうえで、一定期間後に停止する計画を立ててください。

判断のためのチェックリスト

最後に、移行を判断する前に確認すべき項目をまとめます。1〜4で原因を切り分け、5〜10で移行の現実性を評価する構成です。1〜4に該当する場合、移行しても問題は解決しません。

6番と7番が、移行費用の大半を決めます。この2つを確認せずに見積もりを取ると、着手後に金額が膨らみます。

移行先はどう選ぶか

移行先の選定は、「合わない」原因の型によって変わります。型①（設定・運用）なら移行そのものが不要です。型②（制約）と型③（用途）で分けて考えます。

型②の場合、制約を超えられる手段を選ぶことになります。自由度を求めるならローコード基盤やAIアプリビルダー、性能や可用性を求めるならスクラッチ開発が候補です。ただし自由度が上がるほど、権限設計とセキュリティ点検が自社責任になります。kintoneが標準で提供していた権限管理を、自分たちで設計・点検する体制が必要になる点は見落とさないでください。判断材料はノーコードとローコードの違いで整理しています。

型③の場合は、その用途に設計された製品を選ぶのが最短です。顧客接点のデータを軸に営業・マーケティング・サポートを横断させたいならCRM、会計や給与なら専用パッケージ、という具合です。汎用基盤で作り込むより、標準機能で足りることのほうが多くなります。

いずれの場合も、移行後に同じ問題を繰り返さないために、現在うまくいっていない原因を文書化してから選定に入ってください。原因が特定できていない状態で製品を比較しても、比較軸が定まりません。

よくある質問（FAQ）

Q1. 現場が使ってくれません。移行すべきですか？

まず原因を切り分けてください。入力項目が多い、どこに何を入れるか分からないという声はアプリ設計の問題であり、移行しても同じアプリを作り直すだけです。項目を絞り、入力順を業務手順に合わせ、不要な必須指定を外すことで解決する場合があります。

Q2. 添付ファイルはどうやって移行しますか？

CSVには含まれません。公式ヘルプに「添付ファイルは書き出せない」と明記されています。件数が少なければ手動、多ければAPIを使った取得を検討することになります。この工数を見積もりに含めていないケースが多いため、計画段階で件数を確認してください。

Q3. 承認フローや権限設定は移行できますか？

できません。プロセス管理のステータス、アクセス権設定、アプリ設定はファイルに含まれません。移行できるのは基本的にレコードの値だけで、業務の運用ロジックは移行先で再構築することになります。移行コストの中心はここです。

Q4. データ件数が多いのですが、移行できますか？

件数自体は主要な障害ではありません。ただし書き出しファイルが100MBを超えると失敗するため、フィールドやレコードを絞って分割する必要があります。費用を左右するのは件数ではなく、アプリ設定の複雑さです。

Q5. 見積もりを取るとき、何を伝えればよいですか？

レコード件数ではなく、アプリ数、アプリ間の参照関係、添付ファイルを持つアプリの特定、プロセス管理と計算式の使用状況を提示してください。件数だけでは正確な見積もりは出ません。

Q6. 全面移行しかありませんか？

いいえ。合っている業務はkintoneのまま残し、合わない業務だけを切り出す併用構成が実務的です。最初に切り出すべきは、他アプリとの関連が少なく、添付ファイルがなく、プロセス管理を使っていないアプリです。

Q7. 移行中の並行運用はどう扱えばよいですか？

停止日を先に決めてください。移行の失敗で最も多いのは、新旧が併存したまま定着してしまうことです。二重運用は現場の負担を増やし、効果はマイナスになります。旧環境を参照専用にしたうえで、一定期間後に停止する計画にします。

Q8. 移行先で同じ問題が起きないようにするには？

現在うまくいっていない原因を文書化してから選定に入ってください。原因が特定できていない状態で製品を比較しても、比較軸が定まりません。とくに自由度の高い手段へ移る場合、kintoneが標準提供していた権限管理を自社で設計・点検する体制が必要になります。

本記事のkintoneの仕様に関する記述は、2026年8月31日時点のサイボウズ公式ヘルプおよび公式価格ページの記載に基づきます。仕様は変更される場合があるため、移行計画の策定にあたっては必ず公式情報でご確認ください。