kintoneからデータを移す｜持ち出せるものと、手で作り直す部分
「kintone ikou」で調べている人が最初に知りたいのは、いま貯まっているレコードと、業務に合わせて作り込んだアプリの設定を、どこまで持ち出せるのかという点です。この記事では、kintoneが公式に公開している入出力の一覧をもとに、ファイルとして出せるもの、出せるけれども戻せないもの、そもそも出せないものを整理します。あわせて、アプリの設定をテンプレートで運ぶときに何が欠けるのか、APIで運ぶときに何が上限になるのかも並べます。移るかどうかを決める前に、作り直しになる部分の量を数字で見積もれる状態を目指します。
kintoneのデータは、2つの層に分かれている
kintoneを移す話が難しくなるのは、運んでいるものが2種類あるからです。ひとつはレコード、つまり日々入力されてきた中身です。もうひとつはアプリの設定、つまり業務に合わせて組み立てた入れ物そのものです。
表計算ソフトから移ってきたチームの場合、価値の大半は前者にあります。何年ぶんかの案件記録がそこにあり、それが持ち出せるなら移行は成立します。
一方、kintoneを業務システムとして作り込んできたチームは、後者の比重が高くなります。フィールドの並び、入力の制限、他のアプリを参照する仕組み、承認の流れ、通知の条件。これらは長い時間をかけて社内で合意しながら組んだもので、失うと業務そのものが止まります。
移行の見積もりを誤るのは、たいていこの後者を軽く見たときです。レコードはCSVで運べるので「移せる」と判断してしまい、設定の作り直しに何日かかるかを数えていない。まずは、自分たちの価値がどちらの層にあるのかを見定めてください。前者が中心なら移行は現実的で、後者が中心なら費用の計算が変わります。
公式が示している、入出力の一覧
kintoneのヘルプには、何をファイルとして出し入れできるのかが表で整理されています。大きな区分としては次のとおりです。
| データの種類 | 入力 | 出力 |
|---|---|---|
| アプリの設定 | テンプレート化すれば可 | テンプレート化すれば可 |
| アプリのデータ | CSVで可 | CSVで可 |
| スペースの設定 | テンプレート化すれば可 | テンプレート化すれば可 |
| スペースのデータ | 不可 | 不可 |
| ピープルのデータ | 不可 | 不可 |
| システム設定 | 不可 | 不可 |
ここで目を引くのは、スペースのデータが出せないと示されている点です。スペースの中で交わされたスレッドの会話は、ファイルとして持ち出す方法が案内されていません。社内の議論をスレッドで積み上げてきたチームは、その部分が運べないという前提で計画を立てることになります。
システム設定も出せません。ユーザーや組織、グループの構成は、移行先で作り直すことになります。人数が100人規模になると、この作業だけで1日かかります。
フィールド単位で見ると、出せないものが3つある
レコードの書き出しは、フィールドの種類ごとに可否が決まっています。公式のヘルプには、ファイルに書き出せないデータとして次のものが挙げられています。
次のデータは、ファイルに書き出すことができません。［ラベル］、［添付ファイル］、［関連レコード一覧］、変更履歴 出典: jp.kintone.help
この4つのうち、移行で重くなるのは添付ファイルと変更履歴です。
添付ファイルは、CSVに含まれません。つまり、レコードを全部書き出しても、そこにぶら下がっていた見積書や図面は1つも付いてきません。運ぶなら別の手段が要ります。
変更履歴も出せません。誰がいつ何を直したのかという記録は、kintoneの中にしか残らないという前提になります。監査のために履歴を残す運用をしている場合、この点は移行の判断そのものに関わります。
関連レコード一覧も出せませんが、これは表示のための仕組みなので、元になっているレコードさえ運べれば移行先で作り直せます。ラベルも画面上の見出しなので、同じ扱いです。
出せるけれども、戻せないもの
もうひとつ、見落とされやすい区分があります。書き出しはできるのに、CSVから読み込むことはできない項目です。公式の表では、次のものが出力だけ可能として示されています。
・ステータス。プロセス管理を有効にしている場合のみ出力できる ・作業者。同じくプロセス管理を有効にしている場合のみ出力できる ・コメント。レコードのコメント機能を有効にしている場合のみ出力できる ・レコード番号
この区分が効いてくるのは、kintoneの中で別のアプリに移す場合や、一度書き出して整えてから戻す運用をしている場合です。ステータスと作業者は戻せないため、承認の途中だったレコードを別の場所に移すと、進行の状態が失われます。
移行の実務では、この制約から「承認が動いている案件は移さない」という判断がよく取られます。動いているものは元の場所で終わらせて、新しい案件から新しい場所で始める。データの整合を保つうえで、これがいちばん事故が少ない進め方です。
コメントも戻せません。レコードのコメントを書き出すには、レコードを書き出すときに出力の選択肢でコメントを出す指定をする必要があり、レコードとは別のCSVとして出ると説明されています。単独では出せません。また、投稿した人はログイン名で出るとも書かれています。移行先で人を照合するときは、このログイン名を手がかりにすることになります。
書き出すには権限が要る
作業を始める段階で詰まりやすいのが権限です。公式ヘルプには、レコードを書き出すにはアプリのアクセス権の設定でファイル書き出しの権限が必要であり、初期設定ではアプリの作成者だけに許可されていると書かれています。
つまり、移行を任された人が過去に作られたアプリの作成者でなければ、そのままでは書き出せません。アプリが50個あって、作った人が何人にも分かれているなら、権限の付与だけで半日かかります。しかも、作った人がすでに退職している場合もあります。
あわせて、閲覧の権限が無いレコードやフィールドは書き出せないとも明記されています。部署ごとに見える範囲を分けている運用では、1人がすべてを書き出すことができません。誰がどこを書き出すのかを最初に割り振っておかないと、移行の終盤で「あの部署のデータが無い」と気づくことになります。
100MBという壁を、どう回避するか
書き出しには容量の上限があります。公式の制限値一覧には、ファイルの書き出しは1ファイルにつき100MBまでで、超えると失敗すると書かれています。超える場合は、一度に書き出すフィールドかレコードの数を減らすように案内されています。
読み込み側にも上限があり、CSVは1ファイル100MBまで、行数は10万行までです。Excelの形式で読み込む場合はさらに厳しく、1ファイル1MBまで、1,000行まで、500列までと示されています。移行の作業でExcelの形式を経由すると、この上限に引っかかります。CSVで扱うのが基本です。
レコード数そのものに上限は無いと書かれており、絞り込みを設定していない1つのアプリに100万件を登録した状態で問題なく使用できることを確認している、という記載もあります。つまり、件数が多いアプリは実在します。そうしたアプリを移すときは、日付などで期間を区切って何回かに分けて書き出す段取りになります。
分割して書き出す場合は、分け方を記録しておきます。あとで件数を突き合わせるときに、どの範囲をどのファイルに入れたかが分からなくなると、漏れの検証ができません。
添付ファイルを、どう運ぶか
添付ファイルはCSVに含まれないため、別の方法で運びます。現実的な選択は3つです。
1つめは、運ばないと決めることです。過去の案件の資料は元の環境を一定期間残して閲覧だけできるようにし、動いている案件のぶんだけ手で運ぶ。契約の都合で元の環境を残せるなら、これがいちばん手間が少なくなります。
2つめは、手で落とすことです。レコードを開いて添付を保存する作業なので、件数に比例します。300件のレコードに資料が1つずつ付いているなら、1件30秒でも2時間半です。
3つめは、APIで落とすことです。件数が多い場合はこれしかありませんが、次の節の上限が効いてきます。
なお、1つのファイルの容量は1GBまでと制限値一覧に書かれています。大きな設計図や動画を扱っている業種では、運ぶ側の回線と保存先の容量も計画に入れてください。
APIで運ぶときの上限
機械的に運ぶ場合、押さえておくべき数字が3つあります。
1つめは1日に実行できるリクエスト数です。これは契約しているコースによって上限が違い、料金ページ側に記載されています。2026年9月時点の料金ページでは、1アプリあたり1日1万リクエスト、スタンダードコースは10万リクエストと示されています。
2つめはリセットの時刻です。1日のリクエスト数は日本時間の毎朝9時にリセットされると書かれています。夜通し流して上限に届いた場合、翌朝9時まで再開できません。移行の日程を組むときは、この時刻を基準にします。
3つめは同時アクセス数です。1つのドメインにつき100までで、超えるとHTTPの429が返ると明記されています。並列で流して早く終わらせようとすると、ここに当たります。
上限を超えた場合、翌日の午前9時ごろに契約の管理者あてに警告のメールが送られ、このメールは停止できないとも書かれています。移行の作業で上限に触れると、経理や情報システムの担当者に通知が飛ぶことになります。事前に一報を入れておくと、余計な問い合わせが発生しません。
アプリの設定は、テンプレートで運ぶ。ただし欠ける
アプリの設定は、テンプレートとして書き出すことでファイルにできます。ここまでは公式の入出力の表にあるとおりです。問題は、そのテンプレートに含まれないものが多いことです。ヘルプには、含まれない設定として次のものが挙げられています。
・各プラグインの設定。有効か無効かの状態は引き継がれる ・APIトークン ・Webhook ・Slackとの連携 ・アクセス権の設定 ・アプリコード
さらに、ユーザーや組織、グループの情報を使って設定しているものも含まれないとして、次が挙げられています。
・ユーザー選択、組織選択、グループ選択の選択肢の候補や初期値 ・ルックアップの絞り込みの初期設定の条件 ・一覧やグラフの絞り込み条件 ・プロセス管理の作業者 ・アクションが実行できる条件 ・アプリの条件通知、レコードの条件通知、リマインダーの条件通知の、通知先や条件
この一覧を読むと分かることがあります。テンプレートで運べるのは「箱の形」であって、「誰に対して何が起きるか」の部分はほぼ運べません。承認の流れは形だけ残り、誰が承認するかは消えます。通知の条件も同じです。
つまり、kintoneの中で別の環境にアプリを複製する場合ですら、人に紐づく設定は全部入れ直しになります。別の道具へ移るなら、なおさら作り直しです。アプリが30個あり、それぞれに通知が3本ずつ設定されているなら、90本の通知を移行先で組み直す計算になります。
なお、アクションの利用者は、設定されている値にかかわらずテンプレートでは全ユーザーに設定されると書かれています。テンプレートから作ったアプリをそのまま使うと、意図より広い範囲に操作が開いた状態になります。複製の運用をしているなら、ここは毎回の確認項目です。
スペースごと運ぼうとしたときに欠けるもの
スペースの単位でもテンプレートが作れます。ただし、こちらも含まれないものが明示されています。
・スペースの公開か非公開かの設定 ・ゲストスペースかどうかの設定 ・スペースやスレッドの作成者と作成日時 ・スペースのメンバー、スレッドをフォローしているユーザー ・スレッドのコメント ・スペース内のアプリのレコード ・20MBを超える添付ファイル
スレッドのコメントが含まれないという点は、前述の「スペースのデータは出せない」と対応しています。社内の議論の記録は、テンプレートでも運べません。
また、テンプレート化するスペースの外にあるアプリを参照している場合、テンプレートの作成時にエラーになって作れないとも書かれています。アプリどうしを参照し合う設計にしているほど、この制約に当たりやすくなります。
書き出したファイルを、どう整えるか
書き出しが終わったら、移行先が読める形に整える作業が残っています。kintone特有の事情がいくつかあるので、順に挙げます。
計算のフィールドは、読み込んだあとに値が再計算されると説明されています。文字列の1行のフィールドに自動計算を設定している場合も同様です。つまり、書き出した数字がそのまま固定されるわけではありません。移行先で同じ計算式を組めないなら、計算の結果を別の列として持ち出し、ただの数値として扱うほうが確実です。
ルックアップのフィールドは、指定された値に従って他のフィールドの値が更新されると書かれています。参照元のアプリを移していない状態で読み込むと、期待した値にならないことがあります。参照の関係があるアプリは、参照される側から先に移すのが順番です。
テーブルとして設定したフィールドは、ファイルから読み込むことで内容を更新したり追加したりできると案内されています。ただし、1行のレコードが複数行に展開される形になるため、移行先が同じ構造を持っていないと、そのままでは収まりません。テーブルを多用しているアプリは、移行先での表現方法を先に決めておきます。
作成者、作成日時、更新者、更新日時は、新規に登録するレコードの場合に限ってファイルから入力できると書かれています。そのためには、ファイルを読み込む権限だけでなくアプリの管理権限も必要です。過去の記録の日付を保ったまま移したいなら、この条件を満たす人が作業する必要があります。
更新キーの決め方を、先に固める
kintoneの中でデータを入れ直す場合も、移行先で重複を防ぐ場合も、レコードを一意に識別する列が要ります。kintoneではこれを更新キーと呼び、指定できるのはレコード番号、文字列の1行、数値、日付、日時、リンクの6種類と示されています。
注意点が2つ書かれています。ひとつは、更新キーに指定するフィールドは他のレコードと値が重複しないものでなければならないこと。もうひとつは、レコード番号以外を更新キーにする場合、フィールドの設定で値の重複を禁止する設定を有効にする必要があることです。
レコード番号はレコードを作ったときに自動で割り当てられ、同じアプリ内で重複しないため、更新キーとしてよく使われると案内されています。ただし、ファイル側に存在しないレコード番号が含まれていると読み込み時にエラーになるとも書かれています。新しいレコードとして登録したい行は、レコード番号の列を空欄にします。
移行先が別の道具の場合、レコード番号はそのまま引き継げないことが多いものです。その場合でも、元のレコード番号を1つの列として持ち込んでおくと、あとで元のデータと突き合わせるときの手がかりになります。件数が合わないときに、どの行が欠けたのかを特定できるのは、この列があるときだけです。
移行の段取りを4週間で組む
実務でよく使われる並びを挙げます。アプリが数十個ある規模を想定した、4週間の組み方です。
・1週目。棚卸しをする。アプリの一覧を出し、それぞれのレコード件数、添付の有無、プロセス管理の有無、通知の本数、プラグインの有無を表にする。ここで移さないアプリを決める ・2週目。1つのアプリで通しの試験をする。書き出し、整形、読み込み、件数の突き合わせまでを1周回して、かかった時間を測る。この時間に残りのアプリ数を掛ければ、全体の見積もりになる ・3週目。残りを順に移す。参照関係のあるアプリは、参照される側から先に移す。並行して、通知と権限を移行先で組む ・4週目。並走する。古い場所は読むだけ、新しい場所に書くという約束を配り、運び漏れを拾う
2週目の通し試験を省くと、見積もりが根拠のない数字になります。1つ回してみれば、整形にどれだけ時間がかかるのかが分かります。多くの場合、書き出しと読み込みは一瞬で終わり、時間を使うのは整形と確認です。
棚卸しの段階で「移さないアプリ」を決めるのも重要です。長く使っていると、作ったまま使われていないアプリが必ず出てきます。全部を移そうとすると作業量が倍になるので、直近6か月でレコードが増えていないアプリは、元の環境に残すか、書き出したファイルを保管するだけにする判断が現実的です。
契約とサポートの条件も、判断材料に入れる
移行を検討する場面では、料金だけでなく、提供の条件がどう変わるかも見ておくのが実務です。2026年9月時点の料金ページでは、ライトコースが1ユーザーあたり月1,000円、スタンダードコースが月1,800円、ワイドコースが月3,000円と示されています。いずれも税抜きで、最小のユーザー数はライトとスタンダードが10ユーザー、ワイドが1,000ユーザーです。年額で契約する場合は、1ユーザーあたり12,000円、21,600円、36,000円と記載されています。
あわせて、サポートの提供内容が変わることが公式に告知されています。2026年6月29日付の案内では、AIによるサポートを段階的に開始することと、ライトコースの電話サポートの窓口を2026年9月の定期メンテナンスをもって終了することが示されています。同じ案内には、有人のサポートが平日の10時から12時と13時から17時30分であること、AIのサポートが24時間365日であることも書かれています。対象はシステム管理者と記載されています。
移行の判断にこれをどう使うかというと、「詰まったときに誰にどう聞けるか」が変わるかどうかを見ます。ライトコースで運用していて、電話で聞く前提の体制を組んでいたなら、条件が変わります。逆に、メールとチャットで足りているなら影響はありません。料金だけを見て比較すると、この種の変化を見落とします。
バックアップと、移行の書き出しは別物
移行の準備を進めていると、「バックアップを取ってあるから大丈夫」という声が出ることがあります。ここは分けて考える必要があります。
バックアップは、元の環境に戻すための控えです。移行のための書き出しは、別の環境に運ぶための素材です。形式も求められる中身も違います。バックアップとして保管しているファイルが、そのまま移行先に読ませられるとは限りません。
とくに、添付ファイルと変更履歴が書き出せないという制約は、バックアップの目的でも同じように効きます。CSVだけを保管していても、資料と履歴は含まれていません。移行の前に、いま何が控えとして残っているのかを確かめておくと、後から「あると思っていたものが無い」という事態を避けられます。
元の環境を解約する時期も、この確認が済んでからにします。解約すると、書き出しの操作そのものができなくなります。費用を止めたい気持ちは分かりますが、1か月ぶんの料金と、取り返しのつかない欠落を比べれば、判断は明らかです。
移らないほうがよい場合
移行の手間を並べてきましたが、移らない判断が合理的な場面もあります。
ひとつめは、プラグインとカスタマイズに深く依存している場合です。プラグインの設定はテンプレートに含まれず、移行先に同じものがあるとは限りません。JavaScriptで作り込んだ画面も、そのままでは動きません。
ふたつめは、承認の流れが業務の中心にある場合です。ステータスと作業者は書き出せても読み込めず、テンプレートにも作業者は含まれません。承認の設計をもう一度やり直す覚悟が要ります。
みっつめは、社内に作り込みを担える人がいて、その人が業務の改善を回している場合です。道具を替えると、その人が積み上げた土地勘が一度ゼロに戻ります。移行の費用には、この学び直しの時間も含めて数えるべきです。
よっつめは、変更履歴を業務や監査の根拠にしている場合です。履歴は書き出せないため、移行の時点で過去の記録は元の環境にしか残りません。
逆に、移る理由がはっきりしている場合もあります。日々の進行をやりとりするのに画面の切り替えが多い、社外の人を入れるたびに設定が重い、最小のユーザー数と実際の人数が合っていない、といった理由は、作り直しの手間を払ってでも解消する価値があります。判断は、運べない部分の量と、いま払っている不便の大きさの比較です。
寄せられる相談から見えていること
道具の入れ替えについて届く相談を見ていると、多いのは「レコードは出せると聞いたが、それで足りるのか分からない」という戸惑いです。実際に足りないのは、添付ファイル、変更履歴、スレッドの会話、そして人に紐づく設定です。この4つを数えてから判断すれば、見積もりは大きく外れません。
もうひとつ多いのが、最小のユーザー数に関する相談です。実際に使うのが6人でも、契約の下限が10ユーザーなら10人分を払うことになります。人数の少ないチームほど、1人あたりの実質の負担が重くなります。
料金の作り方としては、機能で絞らず、区切るのは人数とボードの数だけという形もあります。この場合、使う人数がそのまま金額になり、下限に合わせる必要がありません。そのかわり、業務システムとして自由に作り込む方向には向きません。どちらが合うかは、作りたいものが業務の入れ物なのか、進行を見る板なのかで変わります。料金の考え方と、板の上で何ができるのかを整理したできることを並べて見ると、性格の違いが分かります。
移行先を絞る段階なら、軸を決めてから並べます。案件の進行を板で扱いたいならTrelloとの比較が、文書と進行を同じ場所に置きたいならNotionとの比較が、国内の開発現場でよく使われる作りと比べたいならBacklogとの比較が近い論点を扱っています。全体を見渡すなら比較の一覧から入るのが早道です。データの受け入れ側にどんな仕組みがあるかを確かめたいならTrelloからの移行を、預けるデータの扱いを確かめたいなら安全性の考え方を見てください。判断に迷う点があればよくある質問にも近い相談が並んでいます。
最後に、移行の見積もりに必要な数字を挙げます。アプリの数。レコードの総件数。添付ファイルの個数と合計の容量。通知とリマインダーの本数。プラグインの数。参照し合っているアプリの組み合わせの数。書き出しの権限を持っている人の数。この7つが出れば、移行にかかる日数と、作り直しになる量はその場で計算できます。
Q1. kintoneのレコードを書き出すと、添付ファイルも付いてきますか？
付いてきません。公式ヘルプには、ファイルに書き出せないデータとしてラベル、添付ファイル、関連レコード一覧、変更履歴が挙げられています。添付ファイルを運ぶには、レコードを開いて手で保存するか、APIを使って取得するかのどちらかになります。件数が多い場合は、過去の資料は元の環境を残して閲覧だけできるようにする、という割り切りも現実的です。
Q2. アプリの設定はテンプレートで丸ごと運べますか？
形は運べますが、含まれない設定が多くあります。公式ヘルプには、プラグインの設定、APIトークン、Webhook、Slackとの連携、アクセス権、アプリコードが含まれないと明記されています。さらに、一覧やグラフの絞り込み条件、プロセス管理の作業者、通知の宛先や条件も含まれません。人に紐づく設定はほぼ作り直しになると考えてください。
Q3. 書き出しがうまくいかないときは、何を確認すればよいですか？
まず権限です。アプリのアクセス権でファイル書き出しの権限が必要で、初期設定ではアプリの作成者だけに許可されていると書かれています。次に容量です。書き出すファイルが100MBを超えると失敗すると明記されているため、フィールドやレコードを絞って分割します。閲覧権限が無いレコードやフィールドは書き出せない点も、部署ごとに権限を分けている場合は確認が必要です。
Q4. 承認の途中にあるレコードは、そのまま移せますか？
ステータスと作業者は書き出しはできても、CSVから読み込むことはできないと公式の表に示されています。そのため、進行の状態を保ったまま移すことはできません。実務では、動いている案件は元の場所で終わらせて、新しい案件から新しい場所で始める進め方が取られます。移行の時期を、承認の区切りに合わせて決めるのが安全です。