面倒解決エンジニアの森田ユウゴです。
台湾からお届けする「#kintone100日チャレンジ」の85日目。
「kintoneのルックアップフィールドにchangeイベントが追加された！」
と舞い上がっていたものの、いざ実装されると何に使うか悩んでしまっている私です。間違いなく、プラグイン実装中とかに「ルックアップはchangeイベント無いのか…」みたいに思ってきたはずなのですが。。。
本日のテーマは、kintoneで一括削除を使う管理者・運用担当者向けの「一括削除 CSVバックアッププラグイン」。標準UIへのDOM操作という禁断の標準DOM動作を承知のうえで、一括削除の直前にCSVバックアップを強制する構成に挑戦しました。
「一括削除 CSVバックアッププラグイン」について
🎯 どんな課題に向き合ったか（現場の不とベネフィット）
現場の「不」: kintoneの一括削除は便利ですが、誤って実行するとレコードは本当に消えてしまいます。後から「昨日の状態に戻せませんか」「一部だけ復旧できませんか」と相談されても、バックアップがなければ打てる手がほとんどありません。
導入後の世界（ベネフィット）: 一括削除の前に、削除対象レコードのCSVをローカルへダウンロードし、さらにバックアップ専用アプリへ添付保存します。完全復旧ではありませんが、少なくとも復元作業の材料を残せます。
💡 着想・こだわり
バックアップや復旧支援の考え方自体は、既に優れた運用や既製サービスがあります。今回のこだわりは、そこではなく「標準の一括削除ボタンを押す直前」にゲートを置いたことです。
ベンダーとしてkintoneの運用現場を見ていると、「一括削除は本当にどうしようもない」という場面に何度も遭遇します。削除後に相談を受けても、バックアップがなければ復旧はほぼ不可能です。
ただし、今回の実装はきれいな正攻法ではありません。kintone標準の一括削除ダイアログには、バックアップ処理を差し込むためのJavaScript APIイベントがありません。そのため、標準ダイアログのDOMをMutationObserverで検知し、削除ボタンを一時的に無効化しています。
DOM操作であることは分かっています。しかもシステムUIまわりなので、通常は避けるべき実装です。それでも、一括削除事故の重さを何度も見てきた立場として、「削除前にバックアップを強制する」発想には現実的な意味があると考えました。
✨ これで出来ること（機能概要）
まずはこちらをご覧ください。
一括削除前のバックアップ強制: 標準の一括削除ダイアログに割り込み、CSVバックアップが完了するまで削除ボタンを押せないようにします。
CSVの二重保存: 削除対象レコードをCSV化し、ローカルダウンロードとバックアップ先アプリへの添付保存を同時に行います。
削除リスクの明示確認: バックアップ完了後に「削除の危険性を理解しました」のチェックを入れて、初めて標準の削除ボタンを有効化します。
課題
現時点では下記のような課題が残っています。
標準DOM依存
一括削除ダイアログへ割り込む公式JavaScript APIがないため、.ocean-ui-dialog などの標準DOM構造に依存しています。これはkintoneアップデートで壊れる可能性があり、推奨できる実装ではありません。設計上は、壊れた場合に「バックアップなしで削除させない」側へ倒すことを重視しています。
完全復旧ではない
CSVバックアップがあっても、復旧時にはレコードIDが変わります。添付ファイル、変更履歴、関連レコード、他システム連携まで完全に戻せるわけではありません。それでも、何も残っていない状態よりは復旧の選択肢を大きく増やせます。
需要はあるだろうけれども、これを業務委託で依頼されたら少し気が滅入ってしまいます。削除ガードという重大な防御ですが、それがkintoneのDOM依存なのでアップデート追従は必須なので…。
お客様にご提案時、こういったリスクを許容いただくようにしていただく必要がございます。
さいごに
#kintone100日チャレンジ として、2026年4月から毎日プラグインをバイブコーディングしています。明日もお楽しみに！
私森田ユウゴはココナラでkintoneに関する各種サービスを出品しております。
SIerの中でもインフラSEとして約10年、特に「運用保守」にはベンダーとして深く携わってきました。
作りっぱなしにしない導入やカスタマイズのご提案が可能です。
お気軽にご相談をくださいませ
→森田ユウゴのプロフィールはこちら👇
