kintoneから移せるのは、画面に見えるもの全部ではありません。文字、数値、日付など多くのレコード値はCSVへ出せます。一方、添付ファイルと変更履歴は標準のレコードCSVに入らず、コメントは別CSVです。「移せるか」は、抽出できるか、新しい仕組みに入れられるか、元の意味を保てるかの三段階で判断します。
月末、経理が案件レコードの変更履歴を開き、「請求金額を誰がいつ直したか」を確認している会社を考えます。最新金額だけをCSVで移すと、新システムの画面は合っていても、その確認作業はできません。データ移行は行数を合わせる仕事ではなく、次の判断に必要な関係を残す仕事です。
kintoneから乗り換えなくていい条件は、どこで分かるのか？
必要な履歴と添付の残し方が未定なら、解約を急がず読取専用で残して移行設計を続けます。
移行先の機能が決まっていても、現行データの出口が決まっていなければ切り替えられません。特に、変更履歴を監査や契約上の説明に使っている、添付を原本として扱っている、コメントで承認の補足を残している場合です。
次のどれかに当てはまる間は、kintoneを止めずに調査します。
- どのアプリとレコードを移すか一覧になっていない
- 添付ファイルの件数と容量を確認していない
- コメントと変更履歴を残す理由を業務担当者へ聞いていない
- 移行前後で照合する件数、金額、添付件数が決まっていない
- 移行先で履歴をどう見せるか、または別保管するか決まっていない
これは永久にkintoneを残すという意味ではありません。必要な証跡を確定し、移行後の参照方法と解約条件が決まるまで、戻れる場所を消さないという判断です。
CSVで移せるデータは、どこまであるのか？
文字、数値、選択、日付などは出力できますが、入力可否と値の再現条件は項目ごとに異なります。
kintoneヘルプの入出力できるデータの一覧では、文字列、数値、選択、日付、ユーザー選択、ルックアップなど多くのフィールドに入出力の対応があります。ただし、計算値は読込後に再計算される場合があり、作成者・作成日時・更新者・更新日時を入力できるのは新規登録するレコードに限られます。
テーブルを含むレコードは、一つのレコードが複数行になります。新システム側で親レコードと明細行に分けるなら、kintoneのレコード番号だけでなく、明細の順序や識別方法も持たせます。
| データ | 標準CSV出力 | 移行時の扱い | 注意すること |
|---|---|---|---|
| 文字・数値・日付・選択 | できる | 項目対応して投入 | 文字コード、空欄、選択肢 |
| テーブル | できる | 親と明細の関係を変換 | 一レコードが複数行 |
| ルックアップ | できる | 参照先マスタを先に移す | キー重複とコピー値 |
| 作成者・更新者・日時 | 出力できる | 監査用項目へ保持も検討 | 新規読込時の制約 |
| 計算フィールド | 出力できる | 結果保持か再計算を決める | 移行先の式との差 |
| 関連レコード一覧 | できない | 元アプリのキーから再構築 | 表示用の関係を確認 |
CSVへ出せることと、そのまま投入できることは同じではありません。ユーザー選択に入っている退職者のログイン名、廃止した選択肢、重複するルックアップキーは、移行先のマスタと対応させます。
添付ファイルは、どうやってレコードと一緒に移すのか？
公式APIかcli-kintoneで取得し、アプリ・レコード・項目・ファイル名の対応表を保って移します。
標準のレコードCSVには添付ファイルが入りません。kintoneのREST API一覧には、レコード取得とファイルダウンロードのAPIが別々に公開されています。レコードから添付の情報を取り、ファイルキーを使って本体を取得する流れです。
サイボウズ公式のcli-kintoneも、添付ファイルの出力先を指定してダウンロードできます。出力先は「フィールドコード-レコード番号」のように分かれるため、移行先のIDへ変換する表を残します。
たとえば、契約アプリのレコード番号125に、契約書、覚書、見積書が三つ添付されているとします。三つのファイルを同じフォルダへ置くだけでは、どれが契約原本で、どの項目に付いていたか分かりません。元アプリID、元レコード番号、フィールドコード、元ファイル名、容量、移行先ID、取込結果を一行ずつ記録します。
ファイル名の重複、0バイト、権限不足、パスに使えない文字を検出し、取得件数と移行先の添付件数を照合します。容量合計だけが同じでも、一件欠けて別のファイルが重複していれば不合格です。
コメントは、移行先へ同じ形で戻せるのか？
別CSVへ出せますが再読込はできないため、会話として再現するか証跡として保管するかを決めます。
kintoneヘルプの書き出し時の注意事項によると、コメントはレコードとは別のCSVへ出力できますが、そのCSVをアプリへ読み込むことはできません。コメントを投稿したユーザーはログイン名で出力され、閲覧権限がないレコードのコメントは出力されません。
移行先にコメント機能があっても、過去日時や退職者名で投稿を再現できるとは限りません。無理に現在のシステムユーザーとして投稿し直すと、「誰がいつ書いたか」が変わります。
コメントを次の三つに分けます。
| コメントの役割 | 移行方法の候補 | 判断 |
|---|---|---|
| 現在進行中の引継ぎ | 新システムの備考やタスクへ要約 | 担当者が内容を確認 |
| 契約・承認の証跡 | 投稿者・日時・本文を読取専用で保管 | 改変しない形を優先 |
| 雑談・完了連絡 | 移さず期限付きで保管 | 業務上の必要性を確認 |
すべてを同じ扱いにすると、必要な証跡が埋もれます。反対に、コメントを全部捨てると、例外処理の理由だけが消えることがあります。
変更履歴は、なぜ最新レコードと別に考えるのか？
変更前の値、変更者、日時が業務判断の根拠になり、最新値だけでは説明できない場面があるためです。
kintoneヘルプのレコードの変更履歴では、レコードがいつ誰によって作成されたか、どの箇所が変更されたかをバージョンごとに確認でき、過去の版へ戻せると説明しています。一方、標準のファイル書き出しでは変更履歴を出力できません。
ここは「APIなら必ず全部取れる」と推測しません。サイボウズが公開するREST APIの一覧には、レコード、コメント、ファイルの操作はありますが、レコード変更履歴を取得するAPIは掲載されていません。必要な履歴については、契約中の環境で実際の取得方法と対象を確認します。
請求金額の修正履歴が監査対象なら、選択肢は三つです。kintoneを一定期間読取専用で残す、必要な画面や証跡を別の保管庫へ固定して残す、移行先に履歴データとして取り込む。どれを選ぶかは、保存義務、検索頻度、閲覧権限、改変防止の要件で決めます。
移行判断の目安は、どの数字で確定すればよいか？
アプリ、レコード、添付、コメントを数え、移行前後の件数と重要項目の集計差分をゼロにします。
全社共通の合格基準ではなく、発注者が業務影響に合わせて決める数値です。少なくとも次を移行計画に置きます。
編集部の出発線は、重大な取得エラー0件、理由不明の照合差分0件、本番相当の全量リハーサル1回以上です。公式基準ではないため、止まったときの影響に応じて厳しくしてください。
| 照合対象 | 移行前に数えるもの | 移行後に照合するもの |
|---|---|---|
| アプリ | 対象数、除外数 | 作成済みの移行先機能数 |
| レコード | アプリ別件数 | 成功、除外、エラーの合計 |
| 金額・数量 | 重要項目の合計 | 同じ条件での集計差分 |
| 添付 | 件数、容量、0バイト | 件数、対応表、取得失敗 |
| コメント | レコード別件数 | 移植、保管、廃棄の合計 |
| ユーザー | 現役、退職、外部 | 移行先ID、表示だけ残す人 |
差分ゼロは「何でも全件移す」という意味ではありません。廃棄すると決めたコメントも件数を残し、承認者と理由を記録します。成功件数だけを報告せず、対象、成功、除外、失敗の合計が一致するかを見ます。
データ移行は、どの手順で進めるのか？
棚卸し、試行抽出、対応表、試行移行、全量リハーサル、本番、照合の七段階で進めます。
- 対象を棚卸しする。 アプリ、レコード、添付、コメント、変更履歴、ユーザー、連携を一覧にし、残す理由を業務担当者へ聞きます
- 少量で試行抽出する。 通常、添付あり、テーブルあり、退職者、文字化けしやすいデータを含むレコードを選びます
- 項目とIDの対応表を作る。 元アプリ・レコード・ユーザー・ファイルを、移行先のIDへ結ぶ表を決めます
- 試行移行する。 新システムへ投入し、画面、検索、集計、権限、添付の開封を担当者が確認します
- 全量リハーサルを行う。 本番と同じ手順で抽出、変換、投入、照合を実施し、所要時間と失敗行を記録します
- 本番移行と差分移行を行う。 更新停止時刻を決め、リハーサル後に増えたレコードと添付を取り込みます
- 照合して解約を判定する。 件数、集計、添付、コメント、履歴参照、受入テスト、切り戻し条件を確認します
月末締めの途中で抽出すると、kintone側の金額が後から変わります。いつ更新を止め、止められない業務の差分をどう拾うかを決めてください。
移行と並行稼働の費用は、どこで増えるのか？
抽出対象、添付容量、試行回数、照合、並行契約の月数が増えるほど作業と利用料が増えます。
見積書では、レコード移行、添付取得、コメント保管、履歴対応、試行移行、本番移行、照合結果表を別の行にします。「データ移行一式」だけでは、添付も履歴調査も含まれない可能性があります。
旧環境を三か月残すなら、その利用料も比較に入れます。サイボウズの料金ページによると、スタンダードコースは一ユーザーあたり月額1,800円（税抜）、最小10ユーザーです。10ユーザーを三か月残す場合は54,000円（税抜）で、これは編集部による単純な掛け算です。オプション、契約形態、移行作業費は含みません。
並行期間をゼロにして利用料を抑えると、履歴参照や切り戻しの余地を失います。期間を長く置けば安全になるとも限りません。いつ、誰が、何を確認したら旧環境を閉じるかを先に決めます。
社内では、移行前に何を決めておくべきか？
残す理由、正とするデータ、廃棄承認、更新停止、照合責任者、解約条件を社内で決めます。
データの持ち主は情報システム部門だけではありません。営業はコメントの引継ぎ、経理は金額と履歴、管理部は契約書添付を確認します。各部門から一人ずつではなく、実際に月末や例外対応を行う人を参加させます。
廃棄するデータも決裁対象です。「古いから不要」ではなく、最終利用日、保存義務、紛争や監査で使う可能性を確認します。法的な保存判断が必要な資料は、社内の法務・税務担当または専門家へ確認してください。
開発会社へは、どの情報を渡せばよいか？
アプリ一覧、出力見本、件数と容量、権限、連携、履歴用途、照合条件を一組で渡してください。
CSVを一つ渡すだけでは、添付とコメントの扱いを見積もれません。各アプリから通常レコードと例外レコードを匿名化して出し、添付の種類、退職者、テーブル、ルックアップを含めます。
開発会社には、抽出スクリプトだけでなく、項目対応表、エラー一覧、移行前後の照合表、再実行手順を成果物として求めます。kintone移行の費用と移行の失敗パターンも同じ資料で確認してください。
一次情報は、どの資料を確認したか？
kintoneの入出力、添付取得、コメント、変更履歴、料金を扱うサイボウズ公式資料を確認しました。
- kintone ヘルプ「入出力できるデータの一覧」
- kintone ヘルプ「レコードのデータをファイルに書き出す際の注意事項」
- kintone ヘルプ「レコードの変更履歴」
- cybozu developer network「kintone REST API」
- cybozu developer network「kintoneコマンドラインツール（cli-kintone）」
- サイボウズ「料金 | kintone」
関連記事と相談先は、どこから確認できるか？
kintone移行の親記事、費用、段階刷新、失敗パターンを往復し、個別のデータ調査を相談できます。
Heygoodは、CSVの行を新しい箱へ移して完了とは考えません。現行環境を一緒に棚卸しし、添付・コメント・履歴がどの判断に使われているかを確認します。移す、読取専用で残す、期限を決めて廃棄する、の三つに分けるところから相談できます。