kintone で消えたデータは、
サイボウズも戻せません。

消えたことに、気づけますか

データが戻せないことより厄介なのは、消えたこと自体に誰も気づかないことです。 レコードの値であれば kintone の変更履歴に残ります。しかし レコードコメントは、投稿しても削除してもレコードの更新日時も revision も動きません（kintone の仕様）。 承認のやりとり、顧客対応の経緯、判断の理由——業務の文脈はコメントに溜まりますが、 消されると kintone 上には何の痕跡も残りません。

次は、検証環境で実際にコメントを1本削除したあと、本製品が出力した差分です。

■ #3 契約管理
  追加 0 / 更新 0 / 削除 0
  コメント: 追加 0 / 削除 1
    [コメント削除] レコード 1  鈴木翔一朗  2026-09-22T15:49:07Z
                   「承認しました。契約書の押印へ進めてください。」

「更新 0」が要点です。kintone 側から見れば、そのレコードは何も変わっていない。 世代を取って突き合わせない限り、この1行は永久に出てきません。

復元で事故を起こさないための作り

バックアップ製品が誤って本番を上書きしたら、守るどころか事故の当事者です。 書き込み側には4つの不変条件を置いています。

1. 差分を見ずには実行できない。 復元は必ず2段階で、プランを出力してからでないと適用できません。
2. 既定はドライラン。 明示的に --confirm を付けない限り、本番へは1バイトも書きません。
3. 書き戻す直前に、現在の状態をもう1世代取ります。 復元という判断そのものが誤りだった場合に、巻き戻せます。
4. 1件の失敗で全体を止めません。 途中で例外を投げて「半分だけ復元された」状態を残すのが最悪なので、失敗は集計して最後に返します。

書き戻せないフィールド（作成者・更新日時・計算フィールド・ステータスなど、kintone 側が自動で決める値）は、 黙って落とさずプランの時点で理由つきに列挙します。

できないこと

バックアップ製品を選ぶときに本当に知りたいのは、できることより 何が戻らないかのはずです。先に書いておきます。

リアルタイムのバックアップはできません

1日1世代が基本です。世代と世代の間の変更は、最後の世代の状態まで戻ります。

復元したコメントの投稿者と日時は変わります

kintone のコメント投稿 API は投稿者と投稿日時を指定できません。 復元すると投稿者は実行ユーザー、日時は復元した瞬間になります。 黙って戻すと経緯の改ざんになるため、本文の先頭に元の投稿者と日時を必ず残します。

削除済みレコードは $id が変わります

kintone は $id を指定して作成できません。元IDとの対応表を出力します。

大量レコードのアプリでは、コメントの全件走査に日数がかかります

コメント取得 API には一括取得のエンドポイントがなく、1リクエストあたり最大10件、 レコードを1件ずつ指定する必要があります。 3万件のアプリでは1世代あたり全体の数％しか走査できず、一巡に2週間程度かかります。 走査率は毎回数値で報告し、「全部保全できています」とは言いません。 コメントが実際に溜まるのはワークフロー系のアプリ（数百〜数千件）なので、 そこでは1世代で全件走査できます。

計算フィールド・作成者・更新日時などは書き戻せません

kintone 側が自動で決める値です。復元プランの時点で理由つきに列挙します。