kintoneを導入して1年。当初の想定ほど使われていない、あるいは「この業務には使えない」という声が現場から上がってきた——この段階で相談を受けることがあります。
ここで即座に「別のツールへ移行しよう」と判断するのは早計です。「合わない」と言われている原因の多くは、製品の制約ではなく設定と運用にあります。原因を切り分けずに移行すると、移行先でも同じ問題が再現します。実際、移行してから「結局同じだった」という結末は珍しくありません。
一方で、本当にプラットフォームの制約に当たっているケースも存在します。その場合は早めに判断したほうが損失は小さくなります。そして移行を決めるなら、事前に知っておくべき重要な事実があります。kintoneから持ち出せないデータが、公式ヘルプに明記されているという点です。
本記事では、原因の切り分け方、移行前に試すべきこと、そして移行を決めた場合に何が失われるのかを整理します。なお本記事はkintoneの評価を下げることを目的としていません。「合わない」ことは製品の欠陥ではなく、適用領域の問題です。
目次
最も多い型です。製品はその業務に適しているのに、設定や運用の設計が業務と噛み合っていない状態を指します。
典型的な兆候は、現場が「入力項目が多すぎる」「どこに何を入れるか分からない」と言っているケースです。これはアプリ設計の問題であり、項目を絞り、入力順を業務手順に合わせ、不要な必須指定を外せば解決します。この型を「合わない」と判断して移行すると、移行先でも同じアプリを作り直すだけです。
もうひとつ多いのが、既存の業務手順をそのままアプリ化してしまったケースです。紙やExcelの時代に生まれた手順には、当時の制約に由来する無駄が含まれています。それを忠実に再現すると、デジタル化したのに手間が減らないという結果になります。
本当に製品の適用範囲を超えている型です。判断の目安は、標準機能でもプラグインでも実現できず、回避策の運用負荷が許容できない状態にあるかどうかです。
具体的には、多段階の条件分岐を伴う複雑な計算、大量データの一括処理、ミリ秒単位の応答が必要な処理、極めて自由度の高い画面レイアウトなどが該当します。これらはkintoneに限らず、業務アプリ基盤型のツール全般に共通する制約です。
データ量の制約も確認してください。公式の価格ページでは、APIリクエスト数の上限がプランごとに定められており、スタンダードコースで1日1万、ワイドコースで1日10万とされています。外部システムと頻繁に同期する構成では、この上限が実質的な設計制約になります。
導入の目的設定を誤っている型です。kintoneは自社の業務に合わせて作る業務アプリ基盤であり、特定業務に最適化された専用製品とは性格が異なります。
会計、給与、人事のように業務が標準化され法改正への追随が必要な領域では、専用パッケージのほうが適しています。逆に、CRMやマーケティングのように顧客との接点データを軸に営業・マーケ・サポートを横断させたい場合は、その用途に設計された製品のほうが早く成果に到達します。「何でも作れる」ことは「何にでも最適」を意味しません。
移行の判断に入る前に、現在の実装が最適かを一度確認してください。とくに次の3点は、見直すだけで印象が変わることがあります。
第一に、アプリを分けすぎていないか。関連する情報が複数アプリに散らばると、入力も参照も手間が増えます。第二に、一覧とグラフの設定が業務に合っているか。よく使う絞り込みを保存した一覧として用意するだけで、日常の操作は大きく変わります。第三に、プラグインや連携サービスで代替できないか。標準機能にない要件が、拡張で満たせる場合があります。
これは受け入れられにくい提案ですが、実務では効果があります。属人的な業務をそのままアプリ化すると、属人性がシステムに固定化されます。「この案件だけ手順が違う」という例外が多い業務は、どのツールに移行しても同じ困難に直面します。
移行を検討する前に、業務手順そのものを標準化できないかを検討してください。例外の数を減らせれば、現在のツールのままで解決する可能性があります。
全面移行か継続かの二択で考える必要はありません。合っている業務はkintoneのまま残し、合わない業務だけを別の手段に切り出す構成は実務的です。
たとえば、社内の申請・台帳管理はkintoneで継続し、顧客との接点管理はCRMへ、要件が固まっていない新規業務の検証はAIアプリビルダーで、といった分担です。移行コストを最小化しながら、制約を回避できます。ただしツールが増えるほど棚卸しと権限管理の負担は上がるため、管理ルールは先に決めてください。
ここが移行検討で最も見落とされる点です。kintone公式ヘルプには、ファイルに書き出せないデータが明記されています。移行計画を立てる前に必ず確認してください。
| 項目 | 公式ヘルプの記載 | 移行への影響 |
|---|---|---|
| 添付ファイル | 書き出せない | 見積書・図面・写真などは別手段で取得が必要 |
| 関連レコード一覧 | 書き出せない | レコード間の関連は再設計が必要 |
| 変更履歴 | 書き出せない | 監査目的で保持していた場合は要検討 |
| ラベル | 書き出せない | 画面上の説明文。実害は小さい |
| プロセス管理のステータス | ファイルに含まれない | 承認の進行状態が引き継げない |
| アクセス権設定 | ファイルに含まれない | 権限設計は移行先でゼロから構築 |
| アプリ設定 | ファイルに含まれない | 画面構成・計算式・通知条件は作り直し |
| レコードコメント | 書き出せるが読み込みはできない | 参照用に保管はできるが復元は不可 |
この表が示す事実は明確です。移行できるのは基本的に「レコードの値」だけで、業務の運用ロジックは移行できません。承認フロー、権限、通知、計算式は移行先で再構築することになります。したがって移行コストの中心はデータ移送ではなく、業務ロジックの再実装です。
添付ファイルは実務上とくに重要です。契約書や図面をレコードに添付して運用している場合、CSVには含まれないため別途取得する手段を用意する必要があります。件数が多い場合はAPIを使った取得を検討することになり、その工数も見積もりに含めてください。
書き出せるデータであっても、そのままの形で移行先に入るとは限りません。公式ヘルプの補足事項には、出力形式に関する注意点が記載されています。
まずテーブル（サブテーブル）を含むレコードは、1レコードが複数行に分かれて出力されます。移行先が1レコード1行を前提とする構造なら、変換処理が必要です。次に、チェックボックスや複数選択のフィールドは選択肢ごとに列が分かれ、選択されたものに「1」が出力されます。移行先のデータ構造によっては、この形式を元に戻す処理が要ります。
細かい点では、数値フィールドの桁区切りや単位記号は出力されません。日付は言語設定によって「年/月/日」と「月/日/年」が変わります。リッチエディターの内容は一部の文字が文字参照で出力されることがあります。いずれも一括変換で対処できますが、変換を設計せずに移行を始めると、データの不整合として後から発覚します。
もうひとつ実務上の制約として、書き出すファイルが100MBを超えると書き出しに失敗すると明記されています。大量データを扱う場合は、フィールドやレコードを絞って分割する必要があります。
見落とされやすい点ですが、ファイル書き出しはアプリのアクセス権設定で付与される権限であり、公式ヘルプによれば初期状態ではアプリ作成者のみが持ちます。また閲覧権限のないレコードやフィールドは書き出せません。
移行担当者が全アプリの書き出し権限を持っているかを、計画段階で確認してください。アプリ作成者が退職している場合、権限の再設定から始める必要があります。
ここまでの内容を踏まえると、移行コストを左右する要因が見えてきます。データ件数は主要因ではありません。
| 要因 | 影響 | 確認方法 |
|---|---|---|
| 業務ロジックの量 | 最大。計算式・通知・プロセス管理の再実装が必要 | アプリ設定の一覧を出して数える |
| 添付ファイルの有無と件数 | 大。CSVに含まれないため別手段が必要 | 添付ファイルフィールドを持つアプリを特定 |
| アプリ数と関連の複雑さ | 大。関連レコード一覧は書き出せない | アプリ間の参照関係を図に起こす |
| 権限設計の複雑さ | 中。移行先でゼロから構築 | 部門別・役職別の権限パターン数 |
| データ件数 | 小〜中。100MB制限で分割が必要な程度 | アプリごとのレコード数 |
見積もりを取る際は、件数ではなくアプリ設定の複雑さを提示してください。「レコード5万件」という情報だけでは、正確な見積もりは出ません。
全面移行の負担が大きいと判明した場合、対象を絞る方法があります。実務では、次の順序で切り出すと影響が小さく済みます。
最初に切り出すべきは、他のアプリとの関連が少なく、添付ファイルを持たず、プロセス管理を使っていないアプリです。この条件を満たすアプリは、レコードの値さえ移せば移行が完了します。逆に、承認フローが組まれ、他アプリを参照し、添付ファイルを多数持つアプリは最後に回します。
並行運用の期間をどう扱うかも決めておいてください。移行の失敗で最も多いのは、新旧が併存したまま定着してしまうことです。二重運用は現場の負担を増やすだけで、効果はマイナスになります。移行日を決め、旧アプリを参照専用にしたうえで、一定期間後に停止する計画を立ててください。
最後に、移行を判断する前に確認すべき項目をまとめます。1〜4で原因を切り分け、5〜10で移行の現実性を評価する構成です。1〜4に該当する場合、移行しても問題は解決しません。
| # | 確認項目 |
|---|---|
| 1 | 不要な入力項目・必須指定を削減する余地はないか |
| 2 | アプリを分けすぎていないか。一覧やグラフの設定は業務に合っているか |
| 3 | プラグイン・連携サービスで解決できないか |
| 4 | 業務手順そのものを標準化して例外を減らせないか |
| 5 | 合わない業務だけを切り出す併用構成は取れないか |
| 6 | 添付ファイルを持つアプリを特定したか（CSVに含まれない） |
| 7 | プロセス管理・アクセス権・計算式の再実装量を見積もったか |
| 8 | アプリ間の関連（関連レコード一覧）を図に起こしたか |
| 9 | 移行担当者が全アプリの書き出し権限を持っているか |
| 10 | 旧環境の停止日を決めたか（二重運用の恒久化を防ぐ） |
6番と7番が、移行費用の大半を決めます。この2つを確認せずに見積もりを取ると、着手後に金額が膨らみます。
移行先の選定は、「合わない」原因の型によって変わります。型①（設定・運用）なら移行そのものが不要です。型②（制約）と型③（用途）で分けて考えます。
型②の場合、制約を超えられる手段を選ぶことになります。自由度を求めるならローコード基盤やAIアプリビルダー、性能や可用性を求めるならスクラッチ開発が候補です。ただし自由度が上がるほど、権限設計とセキュリティ点検が自社責任になります。kintoneが標準で提供していた権限管理を、自分たちで設計・点検する体制が必要になる点は見落とさないでください。判断材料はノーコードとローコードの違いで整理しています。
型③の場合は、その用途に設計された製品を選ぶのが最短です。顧客接点のデータを軸に営業・マーケティング・サポートを横断させたいならCRM、会計や給与なら専用パッケージ、という具合です。汎用基盤で作り込むより、標準機能で足りることのほうが多くなります。
いずれの場合も、移行後に同じ問題を繰り返さないために、現在うまくいっていない原因を文書化してから選定に入ってください。原因が特定できていない状態で製品を比較しても、比較軸が定まりません。
まず原因を切り分けてください。入力項目が多い、どこに何を入れるか分からないという声はアプリ設計の問題であり、移行しても同じアプリを作り直すだけです。項目を絞り、入力順を業務手順に合わせ、不要な必須指定を外すことで解決する場合があります。
CSVには含まれません。公式ヘルプに「添付ファイルは書き出せない」と明記されています。件数が少なければ手動、多ければAPIを使った取得を検討することになります。この工数を見積もりに含めていないケースが多いため、計画段階で件数を確認してください。
できません。プロセス管理のステータス、アクセス権設定、アプリ設定はファイルに含まれません。移行できるのは基本的にレコードの値だけで、業務の運用ロジックは移行先で再構築することになります。移行コストの中心はここです。
件数自体は主要な障害ではありません。ただし書き出しファイルが100MBを超えると失敗するため、フィールドやレコードを絞って分割する必要があります。費用を左右するのは件数ではなく、アプリ設定の複雑さです。
レコード件数ではなく、アプリ数、アプリ間の参照関係、添付ファイルを持つアプリの特定、プロセス管理と計算式の使用状況を提示してください。件数だけでは正確な見積もりは出ません。
いいえ。合っている業務はkintoneのまま残し、合わない業務だけを切り出す併用構成が実務的です。最初に切り出すべきは、他アプリとの関連が少なく、添付ファイルがなく、プロセス管理を使っていないアプリです。
停止日を先に決めてください。移行の失敗で最も多いのは、新旧が併存したまま定着してしまうことです。二重運用は現場の負担を増やし、効果はマイナスになります。旧環境を参照専用にしたうえで、一定期間後に停止する計画にします。
現在うまくいっていない原因を文書化してから選定に入ってください。原因が特定できていない状態で製品を比較しても、比較軸が定まりません。とくに自由度の高い手段へ移る場合、kintoneが標準提供していた権限管理を自社で設計・点検する体制が必要になります。
本記事のkintoneの仕様に関する記述は、2026年8月31日時点のサイボウズ公式ヘルプおよび公式価格ページの記載に基づきます。仕様は変更される場合があるため、移行計画の策定にあたっては必ず公式情報でご確認ください。