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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

元のマスタを復元すると、削除後に私が作成した同名マスタと合わせて、名称が同じデータが2件存在する状態になりました。この状態を放置すると、利用者が新旧どちらを選択すればよいか判断できません。

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

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

復旧後に確認した機能

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

特に注意したのは権限です。管理者アカウントでは問題なく検索できても、一般利用者ではマスタが表示されない可能性があります。そのため、実際の利用者と同じ権限を持つテストアカウントでも確認しました。

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

ゴミ箱に対象レコードが残っていない場合は、バックアップからの復元を検討します。ただし、データベース全体を過去の時点へ戻すと、マスタ削除後に登録または更新された他のデータまで失われる可能性があります。

そのため、バックアップの取得日時、現在との差分、復旧対象の範囲を整理してから判断する必要があります。可能であれば本番環境の複製を作成し、検証環境で復元手順と影響範囲を確認します。

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

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

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

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

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

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

まとめ

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

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

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