Pleasanterでマスタを誤削除したときの影響と復旧手順｜同じ名称で再登録しても直らない理由

Pleasanterで業務台帳を運用していて、台帳から参照しているマスタを誤って削除してしまいました。気づいた後、私は同じ名称のマスタを新しく登録すれば元に戻ると考えていました。ところが、見た目は同じ名称でも、既存の台帳からは以前と同じデータとして認識されず、検索も編集も正常にできません。

ここで分かったのは、Pleasanterのマスタ参照では、利用者が画面上で見る名称ではなく、内部のレコードIDが効いているということです。実際に確認した症状、同名で再登録しても直らなかった理由、ゴミ箱から復旧した手順、復旧後の確認項目、再発防止のために見直した運用を、順に書いていきます。

参照中のマスタを誤って削除したときに起きたこと

対象の環境では、業務データを登録する台帳サイトとは別に、部署や担当グループを管理するマスタサイトを用意していました。台帳側の項目からマスタを検索し、該当する名称を選択する構成です。利用者には名称が表示されるので、私も最初は「同じ名前を作り直せば復旧する」と思っていました。

ところが、削除後に同名のマスタを作成しても、既存台帳の編集画面では以前と同じ参照先として扱われません。新しいマスタは検索候補に出てくるものの、過去に登録したデータとの関係は戻らない。一覧画面では名称らしき表示が残っているレコードもあって、最初は復旧できたように見えました。

実際には、台帳そのものが消えたのではなく、台帳が参照していた元のマスタとの紐づきが切れていました。表示だけを見て正常と判断すると、編集、検索、集計、エクスポートをやったところで問題が表に出ます。復旧時には見た目だけでなく、内部の参照関係まで見る必要がありました。

同じ名称で再登録しても元に戻らなかった理由

調べた結果、削除前のマスタと再登録後のマスタでは、レコードIDが違っていました。名称は人が内容を判断するための表示情報で、Pleasanterがレコードを識別するときには、個別に割り当てられたIDが使われます。

削除前の「放熱アプリグループ」というマスタにレコードID「10XX」が割り当てられていたとします。削除後、同じ名称で作り直したデータのレコードIDが「25XX」なら、名称が一致していても内部的には別のレコードです。

削除前
マスタ名：放熱アプリグループ
レコードID：10XX

再登録後
マスタ名：放熱アプリグループ
レコードID：25XX

既存台帳が参照していたのは、名称ではなく削除前のレコードIDです。再登録したレコードIDへ自動的に置き換わることはありません。この仕組みを理解せずに既存台帳を一括更新すると、本来復元できた参照情報まで書き換えてしまいます。私はまず、削除前のレコードそのものを復元できないか確認する方針へ切り替えました。

復旧作業を始める前に確認した内容

復旧を急いで追加操作を繰り返すと、元の状態が分からなくなります。現在の状態を記録してから作業を始めました。最初に見たのは、削除したマスタがゴミ箱に残っているか、既存台帳のレコードが残っているか、再登録した同名マスタがすでに使われていないか。

• 削除したマスタの名称、削除日時、作業者
• ゴミ箱に残っている削除済みレコード
• 既存台帳の件数と表示状態
• 再登録した同名マスタのレコードID
• 再登録後のマスタを選択した台帳がないか
• バックアップの取得日時と復元可能な範囲

あわせて、作業前の一覧画面や編集画面を保存し、台帳をCSVまたはExcelへ出力しました。復旧後に件数や表示内容を比較するためです。利用者が操作を続けると新しいマスタを選択するレコードが増えるので、影響が大きいなら一時的な利用停止や関係者への周知も要ります。

ここまで整理したうえで、以降は次の順で作業を進めました。

ゴミ箱から元のマスタを復元した手順

削除済みのマスタがゴミ箱に残っていたので、新規登録したマスタへ置き換えるのではなく、削除前のレコードを復元しました。元のレコードを戻せば、既存台帳が参照していたレコードIDを維持できます。

操作としては、対象のテーブルへ移動し、ナビゲーションメニューの「管理」から「ごみ箱」を開きます。Pleasanterはレコードを削除したときに削除履歴を保存していて、この画面から履歴の閲覧、復元、履歴の削除ができます。この操作には「サイトの管理権限」が要ります。一般の編集権限だけでは、ごみ箱そのものが開けません。

出典：テーブル機能：レコードをごみ箱から復元 | Pleasanter

まず、ゴミ箱の一覧から対象レコードを探しました。同じ名称のデータが複数ある可能性があるので、名称だけでは判断せず、更新日時、削除日時、作成者を確認します。対象を特定してから復元を実行し、マスタサイトの通常一覧へ戻ったことを確認しました。

※ 検証環境でダミーデータを使って再現した画面です。

この画面で実際に使ったのは、次の3つです。

• 削除日時の列：いつ消したかで対象を絞り込みます。名称が同じレコードが並んでいても、ここを見れば今回の作業で消したものが分かります。
• 件数の表示：復元前に控えておくと、想定した件数だけが戻ったかを後から確認できます。
• 左端のチェック欄：復元するレコードだけを選びます。ヘッダのチェックで全選択もできますが、対象以外まで戻すと状況が複雑になるため、今回は1件ずつ選びました。

復元後は、既存台帳を開いて名称が表示されるかを確認しました。ただ、表示が戻っただけでは復旧完了とは言えません。編集画面でマスタを検索できるか、既存の選択状態を維持できているか、新規レコードでも選択できるかを順番にテストします。

私の環境では、元のマスタを復元したことで、既存台帳との参照関係を確認できる状態に戻りました。同名データを作り直すより先に、ゴミ箱から元レコードを復元できるか調べる。これが先です。

再登録してしまった同名マスタを整理した方法

元のマスタを復元すると、削除後に私が作成した同名マスタと合わせて、名称が同じデータが2件並びます。放置すると、利用者が新旧どちらを選べばよいか分かりません。

とはいえ、新しく作成したマスタをすぐ削除するのも避けました。削除から復元までの間に、利用者が新しいマスタを選択して台帳を登録しているかもしれないからです。まず、新しいマスタのレコードIDを参照している台帳がないかを確認しました。

参照している台帳があれば、対象レコードを一覧化して、復元した元のマスタへ付け替えます。参照がないと確認できてから、誤って作成したマスタを削除または利用停止にします。作業時には、削除対象の名称だけでなく、レコードIDも確認しました。

復旧後に確認した機能

復旧後は、既存台帳の表示だけでなく、マスタを使う関連機能を一通り確認しました。マスタ参照は、編集画面以外にも一覧検索、集計、エクスポート、スクリプト、帳票、API連携で使われます。

特に気をつけたのは権限です。管理者アカウントでは問題なく検索できても、一般利用者ではマスタが出てこないことがあります。実際の利用者と同じ権限を持つテストアカウントでも確認しました。

ゴミ箱から復元できない場合に考える対応

先に、公式マニュアルに書かれている制限を2つ押さえておきます。どちらも、復旧できるかどうかの分かれ目です。

1つ目は、ごみ箱から削除したレコードは復元できないことです。前掲の画面にあった「ごみ箱から削除」を実行すると物理削除となり、そのレコードはゴミ箱からも消えます。ここまで進むと、この記事の手順では戻せません。

2つ目は、サイトを復元しても、その配下のレコードは一緒に戻らないことです。マスタのレコードではなくテーブルごと削除した場合、テーブルを復元しただけでは中身が空のままになります。フォルダ、テーブル、レコードの順に、上位から順番に復元していきます。

出典：サイト機能：サイトの復元 | Pleasanter

これらに当てはまってゴミ箱から戻せないなら、バックアップからの復元を検討します。ただし、データベース全体を過去の時点へ戻すと、マスタ削除後に登録または更新された他のデータまで失われます。

バックアップの取得日時、現在との差分、復旧対象の範囲を整理してから判断してください。できれば本番環境の複製を作り、検証環境で復元手順と影響範囲を確認します。

データベースを直接変更する方法は、最終手段です。参照テーブルや履歴の構造を理解せず、IDや参照値だけを書き換えると、新しい不整合が生まれます。私は、直接修正が必要な場合は保守担当や製品に詳しい担当者へ相談し、本番環境をいきなり操作しない方針にしています。

再発防止のために見直した運用

今回の誤削除を受けて、マスタの削除権限と運用ルールを見直しました。一般利用者や通常の編集担当者には削除権限を付与せず、必要最小限の管理者だけが削除できるようにします。

これは運用上の申し合わせではなく、権限設定で実現できます。Pleasanterでレコードを削除するには、サイトまたはレコードに対して「読み取り権限」と「削除権限」の両方が必要です。削除権限は読み取りや更新とは別に管理されているので、「編集はできるが削除はできない」利用者を作れます。マスタのように参照される側のテーブルは、この形にしておくのが安全です。

出典：テーブル機能：レコードの削除 | Pleasanter

使わなくなったマスタはすぐに削除せず、「利用停止」「廃止」などの状態を追加して、新規登録時の候補から除外する方法も検討しました。過去データから名称を確認できる状態が残るので、参照関係を壊しにくくなります。

• 削除権限を管理者だけに限定する
• 削除ではなく無効化を基本とする
• 変更前に参照件数を確認する
• 変更日時、作業者、理由を記録する
• 定期的にバックアップを取得する
• バックアップからの復元テストを行う

マスタは複数の台帳や処理から参照されるので、一件の削除が広い範囲へ響きます。通常データより慎重に扱う対象として、事前確認と作業後テストを標準化しておきます。

まとめ

Pleasanterで参照中のマスタを削除した場合、同じ名称のデータを作り直しても、既存台帳との紐づきは戻りません。削除前と再登録後ではレコードIDが違い、Pleasanterからは別のレコードとして扱われるからです。

私の環境では、ゴミ箱に残っていた元のマスタを復元し、既存台帳の表示、検索、編集、出力、権限を確認しました。その後、誤って作成した同名マスタの参照状況を調べて、重複を整理しています。

再発防止では、削除権限の限定、削除ではなく無効化する運用、変更前の参照確認が効きます。誤削除に気づいたら、同名データを作り直す前に、元のレコードを復元できるか確認してください。