LASSIC Media らしくメディア
論理削除と物理削除の違い｜設計の考え方
システムで「データを削除する」と一口にいっても、その裏側には二通りのやり方があります。ひとつは、レコードを本当に消してしまう方法。もうひとつは、見かけ上は消えたように見せつつ、データ自体は残しておく方法です。この二つは、それぞれ物理削除・論理削除と呼ばれ、どちらを選ぶかで後々の運用や復元のしやすさが大きく変わってきます。
削除の方式は、開発の現場では当たり前に検討されるテーマですが、発注する側からは見えにくく、要件から抜け落ちがちなポイントでもあります。「間違って消したデータを戻せない」「消したはずの情報が残っていた」といったトラブルは、この方式選びが関わっていることも少なくないのです。この記事では、発注者やプロジェクトマネージャー、これから開発に関わる方に向けて、論理削除と物理削除の違いと使い分けの勘所を整理していきます。
論理削除と物理削除とは
物理削除とは、データベースから対象のレコードを実際に取り除く方式です。削除の命令を実行すると、その行はテーブルから消え、元には戻せなくなります。私たちが「削除」と聞いて素朴に思い浮かべるのは、こちらのイメージでしょう。
これに対して論理削除は、レコードそのものは残したまま、「これは削除済みである」という目印を付ける方式です。多くの場合、削除フラグを表す列（たとえば削除日時を記録する列など）を用意し、そこに値を入れることで「消えたことにする」わけです。データは物理的に残っているので、通常の一覧や検索では、この目印が付いた行を除外して表示します。
利用者から見れば、どちらの方式でも画面上はデータが消えたように見えます。違いはあくまで裏側にあり、実データが失われているか、それとも残ったまま隠されているかという点にあります。この差が、後々の復元や監査、性能に効いてくるのです。
この記事のポイント
- 物理削除はデータを実際に消し、論理削除は削除フラグを立てて残したまま隠す方式です。
- 論理削除は復元や履歴の保持に向く一方、クエリの複雑化やデータ肥大化を招きます。
- 復元や監査の要否、法令上の消去義務から、方式を最初に決めておくことが大切です。
なぜ論理削除が使われるのか
わざわざデータを残す論理削除には、いくつかの利点があります。とくに業務システムでは、「消したら終わり」では困る場面が多いため、論理削除が選ばれることも珍しくないのです。主な理由を整理しました。
| 利点 | 内容 |
|---|---|
| 復元できる | 誤って削除しても、目印を外せば元の状態に戻せる |
| 履歴が残る | いつ・何が消されたかをたどれ、監査や調査に役立つ |
| 整合性を保ちやすい | 他のデータから参照されている行を、関連ごと壊さずに扱える |
| 集計に活かせる | 解約済みの契約など、消えた後も分析の対象として残せる |
たとえば受注データや会員情報のように、後から「あの取引はどうなっていたか」を確認したくなるものは、論理削除と相性がよいといえます。削除したという事実そのものが、業務上の意味を持つ場合もあるからです。単に画面から消すだけでなく、「消したことを記録として残す」という発想が、論理削除の背景にあります。
論理削除の注意点
便利に見える論理削除ですが、万能ではありません。データを残し続けることの裏返しとして、いくつかの課題が生まれるのです。下の図で、二つの方式の違いを見てみましょう。
まず、データを扱うほぼすべての処理で、「削除済みの行を除く」という条件を書き続ける必要があります。この条件を書き忘れると、消したはずのデータが画面に現れてしまいます。処理が増えるほど、書き忘れのリスクも積み上がっていくのです。
次に、データが消えずにたまり続けるため、テーブルが肥大化し、検索が遅くなりやすくなります。さらに、同じ値を二度登録できない制約を設けている場合、削除済みの行が邪魔をして、同じ内容を登録し直せないといった問題も起こります。加えて見落とされがちなのが、個人情報の扱いです。論理削除ではデータが残るため、「利用者から削除を求められたら消す」という法令上の求めと、正面からぶつかることがあります。残すことが、かえってリスクになる場面もあるわけです。
どう使い分けるか
論理削除と物理削除は、どちらが優れているという話ではなく、扱うデータの性質に応じて選び分けるものです。判断の目安を整理しました。
| 観点 | 論理削除が向く | 物理削除が向く |
|---|---|---|
| 復元の必要性 | 誤削除からの復元が求められる | 復元の必要がない |
| 履歴・監査 | いつ消したかを残したい | 履歴を残す必要がない |
| データ量 | 量が限られ、増え方が緩やか | 大量に発生し、消し続けたい |
| 法令上の消去 | 保持義務のある記録 | 求めに応じ消す義務がある |
実務では、両者を組み合わせる形もよく採られます。たとえば、いったん論理削除で「削除済み」にしておき、一定期間が過ぎたら物理削除で消す、あるいは別の保管場所へ移す、という運用です。ふだんの操作は復元できるようにしつつ、古くなったデータはためこまない——という両取りをねらうやり方だといえます。大切なのは、削除するデータごとに「戻せる必要があるか」「残す義務や、逆に消す義務があるか」を見極めることでしょう。
発注・開発でおさえる点
削除方式は、いったん決めて作り込むと後から変えるのが大変な部分です。だからこそ、発注や設計の早い段階で方針を固めておきたいところです。
削除の要件を最初に言葉にする
「このデータは誤って消したときに戻せる必要があるか」「消した履歴を残すべきか」「利用者の求めに応じて完全に消す義務があるか」を、対象のデータごとに整理しておきます。これらは業務やコンプライアンスの要件に直結するため、開発側だけでは決めきれないのです。発注する側から要件として示しておくことが、後の手戻りを防ぎます。
方針を設計書に明記する
「どのデータを論理削除にし、どれを物理削除にするか」「論理削除したデータをいつ完全に消すか」といった方針を、設計書に書き入れておきます。方式が画面や機能ごとにばらばらだと、抜け漏れや不整合の元になります。全体で統一の取れた方針を持っておくと、実装も点検もしやすくなるでしょう。
削除まわりのテストを用意する
公開前のテストでは、削除したデータが一覧や検索に現れないか、復元が想定どおり動くか、完全な消去が求められる場面でデータが残っていないかを確かめます。削除は表からは地味な機能ですが、トラブルになると影響が大きいため、確認の項目に含めておくと取りこぼしを防ぎやすい領域です。
よくある誤解と勘所
削除方式は、直感と実際とがずれやすいテーマです。代表的なつまずきを表にまとめました。
| よくある誤解 | 実際のところ |
|---|---|
| 論理削除にしておけば無難 | データが残るため、個人情報の消去義務とぶつかる場合がある |
| 物理削除は危険で避けるべき | バックアップと権限の管理を整えれば、妥当な選択肢になる |
| 削除フラグを足すだけで済む | 全処理で除外条件が要り、制約や性能への影響も伴う |
| 方式は後から自由に変えられる | 処理全体に関わるため、後からの変更は負担が大きい |
勘所は、削除を「消すか残すか」の二択で捉えず、「戻せる必要があるか」「残す義務・消す義務があるか」という軸で考えることです。論理削除は残すための仕組みであり、残すことには利点と負担の両面があります。どちらを選ぶにせよ、削除したデータがその後どう扱われるべきかを、設計の初めに描いておくことが、あとあとの安定につながっていきます。
まとめ
- 物理削除はレコードを実際に消す方式で、論理削除は削除フラグを立てて残したまま隠す方式である。
- 論理削除は、復元・履歴・参照整合性・集計といった面で利点がある。
- 一方で、除外条件の書き忘れ、データ肥大化、制約や個人情報の消去義務との衝突といった課題を伴う。
- 復元や監査の要否、法令上の消去義務を軸に、データごとに方式を選び分ける。
- 削除の要件と方針は、後から変えにくいため、発注・設計の早い段階で固めておく。
よくある質問
論理削除と物理削除は、どちらを選ぶのが一般的ですか。
データの性質によって変わるため、一律にどちらが標準とはいえません。受注や会員情報のように、後から確認したり誤削除から戻したりする必要があるデータは、論理削除が選ばれやすい傾向があるのです。一方で、大量に発生するログや一時的なデータ、法令上すみやかに消す義務があるデータは、物理削除が向きます。実務では両者を組み合わせ、いったん論理削除にして一定期間後に物理削除する、という運用もよく採られます。
論理削除にすると、個人情報の扱いで問題になりますか。
注意が必要な点です。論理削除ではデータが残り続けるため、利用者から削除を求められた際に「消す義務」を果たせているか、あらためて確認が要ります。目印を付けて隠しているだけでは、データそのものは存在しているためです。個人情報にあたるデータを扱う場合は、論理削除で残す期間や、最終的に物理削除する仕組みをあわせて設計し、法令上の求めに応えられる形にしておくことが求められます。
論理削除で性能が落ちると聞きました。なぜですか。
消したデータが残り続けることで、テーブルの行数が増えていくためです。行数が多くなるほど検索の負担は増し、応答が遅くなりやすくなります。加えて、多くの処理で「削除済みを除く」という条件が加わるため、その分の負担も乗るのです。対策としては、削除済みかどうかを見分けるための索引を工夫したり、古い論理削除データを定期的に物理削除・退避したりするやり方があります。データ量の見通しをふまえて設計することが大切です。
すでに物理削除で作ったシステムを、後から論理削除に変えられますか。
変更は可能ですが、相応の負担を見込む必要があります。削除方式は、データを扱うほぼすべての処理に関わるため、削除フラグの列を追加するだけでなく、一覧・検索・集計などの各処理に除外の条件を入れて回る作業が生じるのです。影響範囲が広いぶん、テストの手間も大きくなります。だからこそ、削除方式は最初の設計で決めておくのが望ましく、途中で見直す場合は影響範囲を洗い出したうえで、計画的に進めることをおすすめします。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、データ設計の方針づくりから実装、公開済みシステムの点検・改修までを一貫して支援する体制です。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。削除方式やデータ保持の設計でお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
