kintoneバックアップの設計方法｜CSV・自動バックアップ・復元手順の使い分け

kintoneで業務アプリを使い始めると、必ずバックアップの話が出ます。

誤ってレコードを削除した。

CSV一括更新で値を壊した。

アプリ改修後にフォームや通知設定が分からなくなった。

添付ファイルを消してしまった。

コメントや承認経緯を後から確認したい。

退職者の作ったアプリを誰も復元できない。

標準のファイル書き出しを使えば、アプリのレコードをCSVで保存できます。

ただし、kintoneバックアップで問題になるのは、CSVを書き出せるかどうかだけではありません。

次のような状態が起きます。

• バックアップCSVはあるが、どの時点のデータか分からない
• 添付ファイルや変更履歴がCSVに入っていないことを後から知る
• 復元先アプリを作らず、本番アプリへいきなり読み込む
• 更新キーが決まっておらず、復元時に重複レコードが増える
• アプリ設定のテンプレートはあるが、アクセス権やWebhookが復元されない
• 自動バックアップサービスを入れたが、復元テストをしていない
• バックアップを取る人と戻す人が決まっていない
• 重要業務と参考データを同じ頻度で扱っている

バックアップは、保険のように見えます。

しかし、実務では復元作業そのものが業務です。

どのアプリを、どの時点に、どの範囲で、誰が、どの手順で戻すのか。

ここまで決めていないバックアップは、事故のときに使えません。

kintoneバックアップで最初に決めるべきなのは、取得方法ではなく、「何をどこまで復元できれば業務が再開できるか」です。

この記事では、kintoneバックアップを、標準CSV書き出し、自動バックアップ、添付ファイル、コメント、アプリテンプレート、復元テスト、保存期間、権限、運用責任まで含めて設計する方法を整理します。

kintoneデータベース設計はこちら
kintoneルックアップ一括更新の設計方法はこちら

先に結論：バックアップは「取得」と「復元」を分ける

kintoneバックアップでは、次の2つを分けます。

観点	決めること
取得	何を、どの頻度で、どこに保存するか
復元	どのアプリへ、どのキーで、どの順番で戻すか

CSVを書き出すだけなら、取得の一部です。

業務を戻すには、復元の設計が必要です。

復元したいもの	必要な準備
誤削除したレコード	更新キー、復元先、CSV読み込み手順
一括更新前の値	更新前CSV、対象一覧、差分確認
添付ファイル	添付ファイルを含めたバックアップ手段
コメント	コメントCSV、ただし戻せる範囲の理解
アプリ設定	アプリテンプレート、設定差分メモ
通知やWebhook	手動再設定メモ、管理台帳
権限設定	権限表、再設定手順

バックアップCSVを保存していても、更新キーと復元先アプリが決まっていなければ、事故時に安全に戻せません。

標準CSVバックアップでできること

kintoneヘルプでは、ファイル書き出し機能を利用して、アプリのレコードのバックアップを取れると説明されています。

kintoneヘルプ：レコードのバックアップ

ただし、kintone上のすべてのアプリのレコードを一括でバックアップすることはできません。

標準の考え方は、アプリ単位でレコードをCSVに書き出すことです。

kintoneヘルプのファイル書き出し手順では、書き出すレコードを絞り込み、ファイルに書き出し、出力されたファイルをダウンロードする流れが説明されています。

kintoneヘルプ：ファイルにデータを書き出す

標準CSVバックアップが向いているのは、次のようなケースです。

ケース	標準CSVで足りやすい理由
小規模なマスタアプリ	レコード数が少なく、添付ファイルが少ない
一括更新前の退避	更新対象だけを書き出して戻しやすい
月次の控え	月末時点の数値や状態を残せる
外部分析用の保存	Excelや外部集計で参照できる
初期移行前の控え	旧データと新データを比較しやすい

たとえば、商品マスタ、部門マスタ、取引先マスタなどは、標準CSVで一定の備えができます。

一括更新前に、対象一覧を作り、更新前CSVを保存し、更新後に差分を確認する。

この使い方なら、CSVバックアップはかなり実務的です。

一方で、標準CSVだけでは弱いケースもあります。

ケース	標準CSVだけでは弱い理由
添付ファイルが重要	添付ファイルはCSVに出ない
コメントが業務履歴	コメントは出力できても完全復元には向かない
変更履歴が監査に必要	変更履歴はCSVに出ない
アプリ設定も戻したい	レコードCSVだけではフォームや権限は戻らない
毎日更新される重要業務	手動書き出しでは漏れやすい
誤削除後に1件だけ戻したい	復元キーと手順がないと危険

標準CSVは、最初のバックアップ手段として有効です。

ただし、重要業務では、CSVだけでなく、添付ファイル、アプリ設定、復元テストまで見ます。

CSVに含まれないものを確認する

標準CSVバックアップで最も危ないのは、「取れていると思っていたものが取れていない」ことです。

kintoneヘルプでは、ファイル書き出しの注意事項として、添付ファイル、関連レコード一覧、変更履歴などは書き出せないと説明されています。

kintoneヘルプ：レコードのデータをファイルに書き出す際の注意事項

また、レコードコメントはレコードとは別のCSVで出力できますが、書き出したファイルからアプリへ読み込むことはできません。

バックアップ設計では、CSVで扱えるものと扱えないものを分けます。

対象	CSVバックアップでの扱い
文字列、数値、日付、選択肢	出力しやすい
ユーザー、組織、グループ	出力形式に注意する
ルックアップ	値は出力できるが、復元時の参照先に注意
テーブル	出力・入力形式と行の扱いを検証する
添付ファイル	標準CSVでは出力できない
関連レコード一覧	標準CSVでは出力できない
変更履歴	標準CSVでは出力できない
コメント	別CSVで出力できるが、復元用途には弱い
ステータス、作業者	プロセス管理有効時の扱いを確認する

kintoneヘルプ：入出力できるデータの一覧

特に添付ファイルは、契約書、見積書、請求書、写真、証憑など、業務上重要なものが入ることがあります。

CSVだけ取っていても、添付ファイルが戻らなければ、業務が再開できないことがあります。

添付ファイル、関連レコード一覧、変更履歴が重要なアプリでは、標準CSVだけをバックアップと呼ばない方がよいです。

復元手順は更新キーから決める

バックアップは、復元できて初めて意味があります。

kintoneヘルプでは、CSVを使って既存レコードを更新する場合、更新キーにするフィールドを使って既存レコードとファイルの行を紐づけると説明されています。

kintoneヘルプ：レコードのデータをファイルに書き出す際の注意事項

更新キーとして使えるフィールドには、レコード番号、文字列1行、数値、日付、日時、リンクがあります。

ただし、更新キーは重複してはいけません。

復元設計では、次を決めます。

項目	決める内容
復元先	本番アプリへ直接戻すか、検証用アプリへ戻すか
更新キー	レコード番号、外部ID、顧客IDなど
新規登録の扱い	既存にない行を新規として入れるか
上書き対象	どのフィールドだけ戻すか
除外対象	更新しないステータス、承認済み、請求済みなど
確認項目	件数、合計、期限、担当者、添付有無
戻し方	更新前CSVで再度戻すか、差分修正するか

本番アプリへ直接戻すのは危険です。

まず、復元先の検証用アプリを作ります。

そこへCSVを読み込み、件数、主要項目、テーブル行、ユーザー選択、ステータスを確認します。

問題なければ、本番へ戻す範囲を絞ります。

たとえば、一括更新で単価を誤った場合は、全項目を戻す必要はありません。

更新前CSVから、単価、更新キー、必要な確認項目だけを使って戻す方が安全です。

kintoneルックアップ一括更新の設計方法はこちら

アプリ設定はテンプレートと設計メモで守る

レコードデータだけでは、アプリ全体は戻りません。

フォーム、一覧、グラフ、プロセス管理、通知、権限、プラグイン、Webhookなど、アプリ設定もあります。

kintoneヘルプでは、テンプレート機能を使ってアプリやスペースの設定内容を保存できると説明されています。

kintoneヘルプ：レコードのバックアップ

アプリテンプレートは、設定を誤って変更した場合や、同じ設定のアプリを作り直したい場合に役立ちます。

ただし、アプリテンプレートにも含まれない設定があります。

kintoneヘルプでは、アプリテンプレートに含まれない設定として、各プラグインの設定、APIトークン、Webhook、Slack連携、アクセス権、アプリコードなどが挙げられています。

kintoneヘルプ：アプリテンプレートに含まれない設定

つまり、アプリテンプレートだけでは完全な復元手順にはなりません。

次のように分けます。

対象	保存方法
フォーム、一覧、基本設定	アプリテンプレート
JavaScript/CSS	テンプレート、別途ソース管理
APIトークン	再発行手順を管理
Webhook	URL、条件、連携先を管理台帳に残す
Slack連携	設定先、通知条件、管理者を残す
アクセス権	権限表として別管理
プラグイン設定	設定画面の控え、製品ドキュメント、管理台帳
通知条件	設定表と変更理由を残す

アプリ改修前は、レコードCSVだけでなく、アプリテンプレート、権限表、連携設定メモを残します。

kintone通知の設計方法はこちら

自動バックアップが必要なケース

すべてのアプリに自動バックアップが必要とは限りません。

ただし、次のようなアプリは、手動CSVだけでは弱いです。

アプリ	自動バックアップを検討する理由
問い合わせ管理	毎日更新され、誤削除や顧客対応漏れが影響する
案件管理	金額、確度、担当、履歴が頻繁に変わる
契約管理	添付ファイルと期限が重要
請求管理	金額やステータスの誤更新が影響する
在庫管理	日々の増減があり、時点復元が必要
申請・承認	作業者、ステータス、添付が重要

トヨクモのkBackupページでは、kintoneに更新があったタイミングや1日1回の自動バックアップ、レコード・アプリ・添付ファイルの復元、保存期間30日などが紹介されています。

トヨクモ：kBackupとは

こうした自動バックアップサービスは、標準CSVの弱い部分を補える場合があります。

ただし、導入すれば終わりではありません。

次を決めます。

決めること	例
対象アプリ	重要業務、添付あり、日次更新あり
保存期間	何日前まで戻せればよいか
復元単位	1レコード、全レコード、アプリ単位
復元権限	誰が復元できるか
復元テスト	四半期ごと、改修前、本番移行前
監査	誰がいつ戻したか記録する
費用	対象アプリ数とリスクの見合い

自動バックアップは、重要業務に絞って使う方が判断しやすいです。

参考データや再作成できるデータまで同じ手厚さにすると、費用と管理が増えます。

添付ファイルとコメントの扱い

添付ファイルとコメントは、バックアップで見落とされやすいです。

添付ファイルは、CSVだけでは出力できません。

コメントは出力できても、元のコメントとして完全に戻せるわけではありません。

この2つは、業務上の意味を先に判断します。

対象	業務上の意味	設計方針
契約書PDF	正式文書	添付ファイル込みのバックアップを検討
請求書控え	再発行や監査に必要	帳票控えの保存先を分ける
現場写真	証跡	外部ストレージ連携も検討
コメント	やり取りの経緯	重要な判断はステータスや履歴フィールドにも残す
変更履歴	監査、原因調査	標準CSVではなく、運用ログや監査ログを考える

kintone Developer Programの移行ガイドでも、標準のファイル書き出しでは添付ファイルを取得できないことや、変更履歴などは取得できないデータとして整理されています。

Kintone Developer Program：How To Migrate Kintone Data To A New Environment

重要な判断は、コメントだけに残さない方がよいです。

承認理由。

差し戻し理由。

例外判断。

顧客への回答。

こうした情報は、コメントではなく、履歴アプリやフィールドにも残します。

アプリ改修前のバックアップ手順

kintoneでは、アプリ改修前のバックアップが特に重要です。

フィールドを削除する。

CSVで一括更新する。

ルックアップ元を変更する。

プロセス管理を変更する。

アクセス権を変える。

通知条件を変える。

こうした作業の前に、戻し方を作ります。

改修前に保存するもの	目的
対象レコードCSV	値を戻すため
更新対象一覧	どの範囲を触ったか残すため
アプリテンプレート	フォームや一覧を戻すため
権限表	アクセス権を戻すため
通知設定表	通知条件や宛先を戻すため
連携設定メモ	API、Webhook、外部サービスを戻すため
テスト結果	変更後に何を確認したか残すため

改修作業では、作業前、作業中、作業後を分けます。

タイミング	やること
作業前	CSV書き出し、テンプレート保存、対象件数確認
作業中	作業ログ、投入CSV、エラー記録を残す
作業後	件数、合計、主要一覧、権限、通知、連携を確認
翌営業日	現場からの異常報告を確認

アプリ改修前のバックアップは、作業者の安心材料ではなく、変更を戻すための作業手順です。

保存期間と権限を決める

バックアップは、保存期間も重要です。

短すぎると、事故に気づいたときには戻せません。

長すぎると、保管場所、権限、個人情報管理が重くなります。

データ	保存期間の考え方
一括更新前CSV	更新後の確認が終わるまで、必要なら月末まで
月次締めCSV	締め処理と監査要件に合わせる
契約・請求関連	法務・経理の保存ルールに合わせる
添付ファイル	正式文書の保存ルールに合わせる
テスト用バックアップ	本番反映後に不要なら削除する
復元ログ	誰が何を戻したかを残す

保管場所も決めます。

保管場所	向いているもの	注意点
社内Drive	CSV、設計メモ、権限表	アクセス権管理が必要
外部ストレージ	添付ファイル控え	正本との関係を決める
自動バックアップサービス	重要アプリの復元	保存期間と復元権限を確認
Git	JavaScript、設定メモ	個人情報やCSVを入れない
管理台帳	バックアップ実施記録	実施漏れを確認する

バックアップファイルには、顧客情報、個人情報、金額、契約情報が含まれることがあります。

「誰でもダウンロードできる共有フォルダ」に置くのは危険です。

バックアップを取れる権限と、バックアップを見られる権限は分けて考えます。

復元テストを定期的に行う

バックアップは、復元テストをして初めて信頼できます。

テストでは、本番アプリへ戻す必要はありません。

検証用アプリを作り、バックアップCSVやテンプレートを使って、どこまで戻せるか確認します。

テスト項目	確認すること
CSV読み込み	件数、更新キー、文字コード、列対応
テーブル	行の追加、更新、削除の扱い
ルックアップ	参照先マスタが存在するか
ユーザー選択	退職者や存在しないユーザーの扱い
ステータス	プロセス管理の状態を戻せるか
添付ファイル	戻せる手段があるか
権限	復元後に見せてよい範囲か
通知	読み込み時に不要な通知が出ないか
連携	外部連携が勝手に動かないか

復元テストで見つかる問題は、事故時に必ず問題になります。

文字コードがずれる。

更新キーが重複する。

添付ファイルがない。

ルックアップ先が不足する。

テーブル行が意図通り戻らない。

通知が大量に出る。

こうした問題を、本番事故の最中に調べるのは遅いです。

よくある失敗

失敗1：CSVを書き出して安心する

CSVは重要ですが、すべてではありません。

添付ファイル、関連レコード一覧、変更履歴、アプリ設定、権限、連携設定は別に考える必要があります。

まず、重要アプリごとに「CSVで戻るもの」と「CSVでは戻らないもの」を棚卸しします。

失敗2：本番アプリへ直接復元する

事故時に焦って、本番アプリへ直接CSVを読み込むのは危険です。

復元先の検証用アプリで、件数、主要項目、更新キー、テーブル、ルックアップを確認します。

本番に戻すのは、その後です。

失敗3：更新キーがない

復元時には、どのCSV行がどのレコードに対応するかを特定する必要があります。

レコード番号だけでよい場合もありますが、移行や別アプリ復元では外部IDが必要になることもあります。

顧客ID、案件番号、外部システムIDなど、業務上の一意キーを持つ設計にします。

失敗4：添付ファイルを見落とす

CSVに添付ファイルは入りません。

契約書、請求書、証憑、写真などが重要なら、添付ファイル込みのバックアップ手段を検討します。

ファイルの正本がkintoneなのか、外部ストレージなのかも決めます。

失敗5：バックアップ権限が広すぎる

バックアップCSVには、見せてはいけない情報が含まれることがあります。

ファイル書き出し権限、保存先フォルダ、復元権限を分けます。

バックアップ作業者を増やすより、手順を整備して責任者を明確にする方が安全です。

kintoneバックアップ設計のチェックリスト

最後に、バックアップ設計のチェックリストです。

チェック	確認すること
対象	重要アプリ、添付あり、日次更新ありを分けたか
取得方法	CSV、テンプレート、自動バックアップ、外部ストレージを分けたか
取得範囲	レコード、添付、コメント、設定、権限、連携を分けたか
頻度	日次、月次、改修前、一括更新前を決めたか
更新キー	復元時に一意に特定できるキーがあるか
復元先	検証用アプリで試す手順があるか
保存期間	いつまで残し、いつ削除するか決めたか
権限	書き出し、閲覧、復元の権限を分けたか
ログ	誰がいつ取得し、いつ復元したか残すか
テスト	定期的に復元テストをしているか

kintoneバックアップは、1つの機能で完結するものではありません。

標準CSV、アプリテンプレート、自動バックアップ、外部ストレージ、復元テストを、アプリの重要度に合わせて組み合わせます。

kintone通知カスタマイズの設計方法はこちら
kintoneデータベース設計はこちら

Bitlightに相談できること

Bitlightでは、kintoneバックアップを、CSV書き出し手順だけでなく、業務継続の設計として整理します。

たとえば、次のような支援ができます。

相談内容	支援できること
何をバックアップすべきか分からない	重要アプリ、添付、連携、改修前退避を棚卸しする
CSVで戻せるか不安	更新キー、復元先アプリ、読み込み手順を設計する
添付ファイルが多い	添付込みのバックアップ手段や外部保存を整理する
自動バックアップを検討したい	対象アプリ、保存期間、復元権限、費用対効果を整理する
アプリ改修前が怖い	改修前バックアップ、テスト、戻し手順を作る
権限が心配	書き出し権限、保存先権限、復元権限を分ける

バックアップは、取って終わりではありません。

必要なときに戻せる。

戻した後に業務が再開できる。

誰が何をしたか後から説明できる。

ここまで設計して、はじめてkintoneの重要アプリを安心して運用できます。