概要
| この記事の結論 Accessの削除クエリは、条件に一致するレコードをまとめて削除する機能です。実行後は通常の［元に戻す］で復元できないため、先にバックアップを取り、同じ条件の選択クエリで対象IDと件数を確認します。WHERE句を省くと全件が削除対象になります。また、参照整合性や連鎖削除の設定によって関連テーブルにも影響が及ぶため、画面に見える件数だけで安全と判断しないことが大切です。 削除クエリとは、指定条件に合う行そのものをテーブルから取り除くアクションクエリです。 |
この記事でわかること
- バックアップと削除対象を先に確認する
- デザインビューで条件付き削除を作成する
- SQLで日付と複数条件を指定する
- 削除できない原因と関連テーブルへの影響
この記事の主な内容
- 削除クエリで消えるものを理解する
- バックアップと削除対象を先に確認する
- デザインビューで条件付き削除を作成する
- SQLで日付と複数条件を指定する
- 削除できない原因と関連テーブルへの影響
- 実行後の確認と誤削除からの復旧
- よくある質問
想定読了時間：約15分～20分
削除クエリで消えるものを理解する
削除クエリは、テーブルから条件に合うレコードをまとめて取り除きます。レコードとは1行分のデータです。選択クエリが結果を表示するだけなのに対し、削除クエリは保存されているデータを変更します。練習では本番へ接続していない検証用コピーを使ってください。
行全体と項目の値を区別する
DELETEでは、主キーを含む行全体が消えます。電話番号だけを空欄にしたい場合は、行を削除するのではなく、そのフィールドを更新するクエリを検討します。テーブルの構造はDELETEでは残ります。テーブル自体を消すDROP TABLEとは目的が違います。
| やりたいこと | 方法 | 残るもの |
|---|---|---|
| 不要なレコードを取り除く | 削除クエリ DELETE | テーブル構造は残る |
| 特定フィールドの値を空にする | 更新クエリ UPDATE | 行と他の項目は残る |
| 通常の一覧から除外し履歴を残す | 無効フラグ等による論理削除 | レコードは残る |
実行後の取り消しを前提にしない
削除クエリの実行後は、通常の［元に戻す］では復元できません。画面を閉じたり、保存せず終了したりしても削除したデータが戻るとは考えないでください。SQLやVBAで特別にトランザクションを設計する場合は別として、この記事の画面操作はバックアップから戻す準備が前提です。
バックアップと削除対象を先に確認する
削除前には、復元に使えるバックアップと、対象ID・件数の確認が必要です。「古いデータだから」という理由だけで削除せず、参照中の帳票や業務、保存期間、別システムとの連携への影響も確認します。ここで示す期間は操作説明用であり、実際の保管期間を決めるものではありません。
データ本体の保存先を確認する
フォームやクエリが入ったフロントエンドと、テーブルがあるバックエンドを分けている場合、フロントエンドだけのコピーではデータを復元できません。リンクテーブルなら接続先を確認し、共有ACCDBやSQL Serverなど、データ本体のバックアップを取ります。利用中のファイルを単純コピーするだけで十分かも確認が必要です。
バックアップは、取得日時と保存先が分かり、必要時に復元できて初めて役立ちます。共有利用中は作業時間を決め、対象データへの更新を止めるなどの調整を行います。また、確認後に別の人がレコードを追加すると削除対象が変わる場合があるため、事前表示と実行を離しすぎないようにします。
選択クエリで消す行と残す行を確認する
例として、T_処理履歴に履歴ID、処理日時、削除許可を用意します。履歴IDは長整数の主キー、処理日時は日付/時刻型、削除許可はYes/No型です。「2026年10月1日より前で、削除許可がTrue」の行を対象にします。日付だけでなく、業務上削除してよい状態も条件に含める例です。
| 履歴ID | 処理日時 | 削除許可 | 期待する扱い |
|---|---|---|---|
| 11 | 2026/09/30 09:00 | True | 削除候補 |
| 12 | 2026/09/30 18:00 | True | 削除候補 |
| 13 | 2026/10/01 00:00 | True | 残す |
| 14 | 2026/09/20 10:00 | False | 残す |
SELECT [履歴ID], [処理日時], [削除許可]
FROM [T_処理履歴]
WHERE [処理日時] < DateSerial(2026,10,1)
AND [削除許可] = True
ORDER BY [履歴ID];
候補が11と12の2件だけになることを確認します。境界にある13が残ること、古くても許可されていない14が残ることも重要です。単に「2件」という数字を見るだけでは、別の2件を削除する誤りを見抜けません。対象IDと内容の両方を点検してください。
デザインビューで条件付き削除を作成する
最初から全件削除のクエリを作るより、確認済みの選択クエリを複製して削除クエリへ変更する方が条件を照合しやすくなります。Q_削除候補とQ_履歴削除のように名前を分け、実行用であることが分かるようにしてください。削除クエリをダブルクリックすると実行へ進む点にも注意します。
作成と実行の手順
1. Q_削除候補を保存し、別名のQ_履歴削除として複製します。
2. Q_履歴削除をデザインビューで開き、クエリの種類を［削除］に変更します。
3. T_処理履歴の「*」を追加し、その列の［削除］行が［From］になっていることを確認します。
4. 処理日時と削除許可の条件列は［Where］とし、条件を同じ行に置きます。
5. SQLビューでも、対象テーブルとWHERE条件が意図どおりか照合します。
6. 実行前に候補を再確認し、実行時の削除件数が想定と違えば中止します。
FromとWhereの役割
Fromは削除元のテーブル、Whereはどのレコードを対象にするかという条件です。処理日時を条件欄に置いても、処理日時だけが消えるわけではありません。条件に合う行全体が消えます。不要な表示列を残して判断しづらい場合は、削除元の*と必要な条件列に整理します。
同じ条件行に入力した条件は通常AND、別の「または」の行へ分けた条件はORとして扱われます。「古い、かつ削除許可あり」のつもりで別々の行に書くと、「古い、または削除許可あり」へ範囲が広がる原因になります。実行前のSQL表示でANDとORも確認してください。
警告の件数は最後の確認に使う
警告ダイアログの有無や表現は設定・実行方法によって変わるため、警告だけを安全装置にしないでください。特にVBAの一括処理では、画面の警告と同じ動きをしない場合があります。初心者向けの手順では、警告を消す設定を追加せず、候補の確認とバックアップを省略しない運用にします。
SQLで日付と複数条件を指定する
確認済みの条件をDELETEへ置き換えると、次のSQLになります。実行前にSELECT版とWHERE句が一致しているか確認します。WHEREを削除すると全件が対象になるため、条件を消して試す操作は本番に対して行わないでください。
DELETE FROM [T_処理履歴]
WHERE [処理日時] < DateSerial(2026,10,1)
AND [削除許可] = True;
1日分は翌日未満までで指定する
日付/時刻型には時刻も入ります。2026年9月30日と完全一致する条件では、9月30日の15時などを取りこぼす場合があります。1日全体を対象にするなら、その日の0時以上、翌日の0時未満という範囲で指定します。終了時刻を23時59分59秒に決め打ちするより、境界を明確にできます。
SELECT [履歴ID], [処理日時]
FROM [T_処理履歴]
WHERE [処理日時] >= DateSerial(2026,9,30)
AND [処理日時] < DateSerial(2026,10,1)
AND [削除許可] = True;
上は確認用のSELECTです。候補を確認してから削除用に同じ条件を使います。Nullの処理日時はこの範囲条件に一致しません。日時不明のデータを削除したい場合は、古いデータと混ぜず、Is Nullで別に抽出して理由を確認してください。
毎回条件を変える場合は型を決める
担当者が基準日時を入力するなら、パラメーターを日付/時刻型に設定しておくと、文字列として比較するミスを避けやすくなります。ただし、確認用と削除用で違う値を入力する危険は残ります。入力値を固定した画面や対象ID一覧を使い、確認した条件のまま実行する設計が必要です。
PARAMETERS [p基準日時] DateTime;
SELECT [履歴ID], [処理日時]
FROM [T_処理履歴]
WHERE [処理日時] < [p基準日時]
AND [削除許可] = True;
削除クエリ・データ保全を整理したい方へ
検証用データで手順を確かめても解決しない場合や、複数の画面・テーブル・利用者への影響を整理する必要がある場合は、Accessの教科書へご相談ください。現在の構成、起きている症状、期待する結果をまとめると、確認すべき範囲を伝えやすくなります。
削除できない原因と関連テーブルへの影響
削除できないときは、エラーを回避することより、なぜ止められているのかを確認します。参照整合性はデータの関係を守る機能です。関連する注文がある顧客を削除できない場合、整合性を解除して無理に削除すると、顧客のいない注文が残るおそれがあります。
連鎖削除で子の行まで消える場合がある
リレーションシップに連鎖削除が設定されていると、親の削除が子テーブルへ波及します。顧客1件の削除で、関連する注文やその先の明細にも影響が及ぶ構成があります。クエリで直接表示した親の件数だけで削除範囲を判断せず、関係図と子の件数を確認します。
| 確認点 | 想定される原因 | 対応の方向 |
|---|---|---|
| ファイルと接続先 | 読取専用、更新権限なし | 管理者と権限・保存場所を確認 |
| データの使用状態 | 他の人や画面がロックしている | 対象を閉じ、作業時間を調整 |
| リレーション | 参照整合性で親を削除できない | 関連データの扱いを設計 |
| クエリ構造 | 集計や結合により更新不可 | 削除先1表と対象IDを明確化 |
| リンクテーブル | 一意キー認識や接続権限の問題 | リンク定義と接続先を確認 |
| 信頼設定 | アクションクエリが無効 | 出所を確認したDBだけ信頼設定を検討 |
結合した結果を削除する場合
複数テーブルを結合したクエリでは、削除先が曖昧になったり、更新不可になったりします。まず「どのテーブルの、どの主キーの行を消すのか」を一覧にします。必要に応じて対象IDを別のクエリで確定し、削除対象を1表へ絞る構成を検討します。プロパティ変更だけで万能に直るものではありません。
SQL Serverなどのリンク先では、サーバー側の制約やトリガーによって追加の処理が動く場合もあります。Accessの画面上に見える設定だけで影響を判断せず、接続先の管理者にも確認します。フロントエンドの検証コピーが本番へリンクしたままなら、そこでの削除も本番データを変更します。
実行後の確認と誤削除からの復旧
削除後は、対象IDがなくなったことと、残すべきレコードが残ったことを確認します。説明用サンプルなら、11と12が消え、13と14が残ることを照合します。関連テーブルへの影響、件数、利用画面の再表示も確認し、実行日時・条件・件数・バックアップを記録します。
間違って削除した場合の初動
誤削除に気付いたら、関係者へ連絡して追加更新を止め、現在の状態も保全します。すぐにバックアップで全体を上書きすると、バックアップ取得後の正常な更新まで失う可能性があります。まず別の場所へ復元し、削除対象とその後の更新を比較して、戻す範囲を決める必要があります。
復元では、主キーと外部キー、連鎖削除で消えた子テーブル、再実行による重複も確認します。データベースの種類やバックアップ方式によって使える復旧方法は異なります。処理中の画面を閉じるだけ、最適化するだけで削除データが戻るとは考えないでください。
論理削除が向く場合
あとから履歴を参照する必要があるデータは、削除日時や無効フラグで通常の一覧から除外する方式が候補です。ただし、すべての検索・集計・連携で無効データを正しく扱う必要があります。データを残し続けることが常に適切とは限らないため、業務の保管方針に合わせて物理削除と使い分けます。
削除の安全性は、DELETE文の短さでは決まりません。対象を確認できること、実行中に対象が変わらないこと、関連データの影響を把握できること、復元できることをそろえてから実行します。繰り返し使う処理では、これらの確認を画面と運用手順に組み込んでください。
よくある質問
通常の画面操作で削除クエリを実行した後は、［元に戻す］で復元できません。保存せず閉じても削除前には戻らないため、実行前のバックアップが必要です。誤削除した場合は追加更新を止め、現在の状態を保全したうえで別環境へバックアップを復元します。その後、消えた行とバックアップ後の正常な更新を比較し、戻す範囲を判断してください。トランザクションで取り消せるよう特別に設計した処理と、通常の削除操作は区別して考えます。
特定フィールドだけを空にする場合は、削除クエリではなく更新クエリを使います。削除クエリは主キーを含む行全体を消すため、電話番号だけを消すつもりで実行すると顧客そのものを失います。更新ではNullを許可する項目か、空文字を保存できる項目かを確認し、必要な条件を指定してください。例えば電話番号を消しても顧客名とIDは残すという目的を先に整理します。更新クエリもデータを書き換えるので、対象確認とバックアップは必要です。
対象テーブルの全レコードが削除対象になります。テーブル自体の構造は残りますが、その中のデータは失われます。画面のデザインビューで条件を消した場合も同様なので、テスト目的で条件なしにする操作は本番へ接続した状態で行わないでください。実行前にSELECT版とDELETE版の条件を照合し、候補IDと件数を確認します。警告が表示される設定でも、実行を連続して進めると誤操作につながるため、警告だけに頼らない確認手順が必要です。
日付/時刻型に時刻まで保存されている可能性があります。2026年9月30日との一致条件は、同日の15時の値と一致しない場合があります。1日分なら9月30日0時以上、10月1日0時未満の範囲で指定してください。また、Nullの日時は通常の大小比較では抽出されません。まず選択クエリで日時を時刻付き表示し、実際の保存値を確認します。日付に見える文字列を比較している場合は、データ型の確認と入力・取込方法の見直しも必要です。
原因を調べずに解除することは避けてください。参照整合性は、存在しない顧客に注文がひも付くような不整合を防ぐための設定です。削除が止まるのは、残すべき関連データがあることを知らせている可能性があります。どの親と子が関係し、履歴を残す必要があるかを確認してください。関連データも消すなら順序と範囲を設計し、連鎖削除の影響も点検します。顧客を無効扱いにして履歴を保持する方法が適する場合もあります。
更新可能な接続と必要な権限があれば、リンク先の実データが削除されます。手元のAccessファイル内だけで完結する処理ではない点に注意してください。フロントエンドをコピーしても、リンクが本番へ向いたままなら本番データに影響します。検証時は接続先を必ず確認し、バックアップもデータ本体側で取得します。SQL Serverなどでは一意キー、権限、制約、トリガーなども関係するため、削除できない場合は接続先の設定と合わせて調べます。
レコードを削除しても、Accessファイルのサイズがその場で同じ割合だけ小さくなるとは限りません。空いた領域が残るためです。ACCDBのサイズを整理する際は最適化と修復が候補ですが、事前バックアップと他利用者が使用していない状態などの確認が必要です。また、リンク先のデータを削除した場合は、フロントエンドのサイズとは直接結び付きません。最適化は誤削除を元に戻す操作でもありません。容量対策とデータ復旧を分けて考えてください。
履歴を後から参照する必要があるなら、無効フラグや削除日時を使う論理削除が候補です。行を残すため確認しやすい一方、すべての一覧・集計・連携で除外条件を統一する必要があります。物理削除は行を取り除くため、保存期間を過ぎた不要データの整理などに向きますが、通常は取り消せません。業務上の保持方針と復元方法を決め、両者を使い分けてください。画面から見えなくなれば十分なのか、保存データ自体をなくす必要があるのかが判断の出発点です。
Accessの教科書へのご相談
削除クエリ・データ保全を整理したい方へ
検証用データで手順を確かめても解決しない場合や、複数の画面・テーブル・利用者への影響を整理する必要がある場合は、Accessの教科書へご相談ください。現在の構成、起きている症状、期待する結果をまとめると、確認すべき範囲を伝えやすくなります。
関連記事
参考情報
Microsoft Support 削除クエリの作成と実行
https://support.microsoft.com/en-us/access/create-and-run-a-delete-query
Microsoft Support DELETEステートメント
https://support.microsoft.com/en-us/access/delete-statement
Microsoft Learn DELETEステートメント
https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/delete-statement-microsoft-access-sql