カスケード更新・削除でAccessの参照整合性を保つ｜親テーブル変更・削除が子テーブルに波及する仕組みと設定手順・MOS Access試験対策

「顧客テーブルの顧客IDを変更したら、受注テーブルの外部キーがエラーになった」「親レコードを削除しようとすると参照整合性違反で弾かれる」——Accessで参照整合性を設定したデータベースを管理していると、こうした場面に必ず出くわします。

この問題を解決するのがカスケード更新とカスケード削除です。リレーションシップに設定する2つのオプションで、親テーブルの変更・削除を子テーブルに自動的に波及させることができます。正しく理解して使えば、整合性を保ちながら柔軟なデータ管理が実現します。

本記事では、カスケードの仕組みと動作原理から始まり、リレーションシップウィンドウでの設定手順・設定しなかった場合のエラー挙動・運用上の注意点までを体系的に解説します。MOS Access試験の頻出チェックリストも収録しています。

カスケードとは何か｜参照整合性との関係

Accessのリレーションシップで「参照整合性を設定する」とはどういう意味かを最初に整理します。

参照整合性とは、子テーブルの外部キーが必ず親テーブルの主キーに存在する値だけを持てるようにするルールです。たとえば顧客テーブル（主キー：顧客ID）と受注テーブル（外部キー：顧客ID）がリレーションされている場合、受注テーブルに存在しない顧客IDを持つレコードは登録できません。

この参照整合性を有効にすると、逆に親テーブル側での操作にも制約がかかります。

• 子テーブルにレコードが存在する親レコードの主キーを変更しようとすると、エラーが発生する
• 子テーブルにレコードが存在する親レコードを削除しようとすると、エラーが発生する

この制約を「自動的に処理する」のがカスケードの役割です。カスケードには2種類あります。

オプション	動作	対象操作
フィールドの連鎖更新（カスケード更新）	親の主キーを変更すると、子の外部キーも同じ値に自動更新される	UPDATE（更新）
レコードの連鎖削除（カスケード削除）	親レコードを削除すると、対応する子レコードも自動削除される	DELETE（削除）

どちらも「リレーションシップの編集」ダイアログで設定します。参照整合性のチェックボックスをオンにした状態でないと、2つのカスケードオプションは表示されません。

カスケード更新の仕組みと設定手順

カスケード更新は、親テーブルの主キー値を変更したとき、子テーブルの外部キー値を自動的に同じ値に更新する機能です。

想定例：顧客テーブルの顧客ID「1001」を「2001」に変更した場合を考えます。カスケード更新なしでは、受注テーブルに「顧客ID=1001」のレコードが残ったままエラーが発生します。カスケード更新を設定しておくと、受注テーブルの外部キー「顧客ID」も自動的に「2001」に書き換えられます。なお、この例は仕組みを示すための想定例であり、実測値ではありません。

カスケード更新の設定手順

1. 「データベースツール」タブ →「リレーションシップ」グループ →「リレーションシップ」ボタンをクリックしてリレーションシップウィンドウを開く
2. 設定したいリレーションシップの結合線をダブルクリックする（または右クリック →「リレーションシップの編集」）
3. 「リレーションシップの編集」ダイアログが開いたら、「参照整合性」チェックボックスがオンになっていることを確認する
4. 「フィールドの連鎖更新」チェックボックスをオンにする
5. 「作成」（既存のリレーションシップを変更する場合は「保存」）をクリックする

設定後、リレーションシップウィンドウの結合線に「1」と「∞」の記号が表示されていれば、参照整合性が有効な状態です。

カスケード更新が使えない場面

カスケード更新はオートナンバー型の主キーには設定できません。オートナンバー型はAccessが自動で採番するフィールドであり、ユーザーが直接値を変更できないからです。カスケード更新が実際に効力を発揮するのは、テキスト型や数値型など、手動で変更可能な主キーを持つテーブルです。

カスケード削除の仕組みと設定手順

カスケード削除は、親テーブルのレコードを削除したとき、そのレコードを参照しているすべての子レコードを自動的に削除する機能です。

想定例：顧客テーブルから顧客ID「1001」のレコードを削除する操作を考えます。カスケード削除なしでは「参照整合性の制約に違反するため削除できません」というエラーが発生します。カスケード削除を設定しておくと、受注テーブルの顧客ID「1001」に紐づくすべての受注レコードも同時に削除されます。なお、実際のデータベースでは削除前に「x件の関連レコードも削除されます」という確認メッセージが表示されます。

カスケード削除の設定手順

1. 「データベースツール」タブ →「リレーションシップ」→ 設定したい結合線をダブルクリックする
2. 「参照整合性」チェックボックスがオンになっていることを確認する
3. 「レコードの連鎖削除」チェックボックスをオンにする
4. 「作成」または「保存」をクリックする

連鎖の深さに注意する

カスケード削除は連鎖します。顧客テーブル → 受注テーブル → 受注明細テーブルという多段リレーションがある場合、顧客テーブルのレコードを削除すると受注テーブルのレコードが削除され、さらに受注明細テーブルのレコードも削除されます。ただし、各リレーションシップにカスケード削除を設定している場合に限られます。

カスケードを設定しない場合のエラー挙動

参照整合性は設定しているがカスケードを設定していない状態で親テーブルを操作すると、Accessは次のようなエラーを表示します。

操作	エラーメッセージ（概要）	原因
親レコードの主キーを変更	「フィールドの値を変更できません。リレーションシップの制約に違反します」	カスケード更新なし
親レコードを削除	「このレコードを削除できません。リレーションシップに関連レコードがあるため削除できません」	カスケード削除なし
子テーブルに存在しない外部キーを入力	「入力した値はフィールドの制約に違反しています」	参照整合性そのものによる制約

これらのエラーは意図した保護機能です。カスケードを設定せずに参照整合性だけを有効にした場合、子レコードが残ったまま親レコードを削除できないため、データの孤立（いわゆる「孤立レコード」）を防ぐことができます。

カスケードの危険性と運用上の注意点

カスケード削除は便利ですが、設定ミスや操作ミスによって大量のデータが意図せず消えるリスクがあります。運用前に必ず以下の点を確認してください。

バックアップを必ず取ってから設定する

カスケード削除を設定した後で親レコードを誤って削除すると、子テーブルのデータも一括消去されます。AccessにはExcelのような「Ctrl+Z」での元に戻す操作がほとんど利用できない（レコード削除は取り消し不可）ため、設定変更の前は必ずデータベースファイルのバックアップを作成してください。

カスケード削除の削除確認ダイアログを見落とさない

カスケード削除を設定したデータシートやフォームから親レコードを削除しようとすると、Accessは「このレコードを削除すると、関連テーブルのレコードも削除されます。削除してよいですか？」という確認ダイアログを表示します。このメッセージを読まずに「はい」をクリックすると、子テーブルのデータも消えます。

VBAでカスケード削除を含む処理を自動化する場合、DoCmd.SetWarnings False を使うと確認ダイアログが表示されずに削除が進んでしまいます。自動化コード内での使用には細心の注意を払ってください。

カスケード更新とオートナンバー型の組み合わせは設定できない

主キーがオートナンバー型のテーブルにはカスケード更新を設定できません（Accessがダイアログ上で「フィールドの連鎖更新」チェックボックスをグレーアウトします）。オートナンバー型はユーザーが変更できないため、連鎖更新の必要がないからです。

多対多リレーション（中間テーブル）とカスケードの関係

多対多リレーションシップは中間テーブル（ジャンクションテーブル）を介して実現します。カスケード削除を設定する際は、親テーブル → 中間テーブルのリレーションシップにのみカスケード削除を設定し、中間テーブル → もう一方の親テーブルへのリレーションシップにはカスケード削除を設定しないのが基本設計です。設定が逆になると一方の親を削除したときに他方の親データまで消える事故につながります。

設定確認の方法｜リレーションシップウィンドウの見方

カスケードの設定状態はリレーションシップウィンドウで確認できます。

1. 「データベースツール」タブ →「リレーションシップ」ボタンをクリックしてウィンドウを開く
2. 確認したいリレーションシップの結合線をダブルクリックする
3. 「リレーションシップの編集」ダイアログで各チェックボックスの状態を確認する

チェックボックスの状態	動作
「参照整合性」のみオン	整合性チェックあり・カスケードなし（エラーで操作ブロック）
「参照整合性」+「フィールドの連鎖更新」オン	親の主キー変更時に子の外部キーを自動更新
「参照整合性」+「レコードの連鎖削除」オン	親レコード削除時に子レコードを自動削除
両方オン	更新・削除どちらの操作も子テーブルへ波及

よくある質問とトラブルシューティング

Q：「フィールドの連鎖更新」がグレーアウトして選択できない

主キーがオートナンバー型の場合、カスケード更新は設定できません。オートナンバー型はユーザーが値を変更できないため、連鎖更新の対象にならないからです。主キーをテキスト型や数値型に変更すれば選択可能になりますが、既にデータが入っているテーブルの主キー型を変更するのはリスクが伴うため、設計段階での検討が必要です。

Q：カスケード削除を設定したが、削除時にエラーが出る

複数テーブルにまたがるリレーションシップがある場合、すべての中間テーブルのリレーションシップにもカスケード削除が設定されているか確認してください。途中のリレーションシップにカスケード削除が設定されていないと、連鎖が止まってエラーになります。

Q：一般的に、カスケード削除はどのような場面で使うのか

一般的には、親と子が密接に紐づいており「親なしでは子が存在できない」関係に使います。典型的には「注文ヘッダー（親）→ 注文明細（子）」「プロジェクト（親）→ タスク（子）」などです。逆に、子が独立した意味を持つ場合（たとえば、担当者が退職しても取引先レコードを残しておきたい場合）はカスケード削除を設定せず、外部キーをNull許容型にするか、手動で処理する設計を選択します。

MOS Access試験（MO-500）での出題ポイント

MOS Access 365試験（MO-500）では、リレーションシップと参照整合性に関する操作が出題されます。カスケード設定はその一部として頻出の実技操作です。

出題範囲に含まれます。分野別の出題数・配点は公表されていません。

頻出の操作	確認ポイント
リレーションシップウィンドウの開き方	「データベースツール」タブ →「リレーションシップ」
参照整合性を設定する	結合線をダブルクリック →「参照整合性」チェックをオン
カスケード更新を設定する	「フィールドの連鎖更新」チェックをオン（オートナンバー型は不可）
カスケード削除を設定する	「レコードの連鎖削除」チェックをオン
既存のリレーションシップを変更する	結合線をダブルクリック → 編集 →「保存」
リレーションシップを削除する	結合線を選択 → Delete キー

試験対策のよくあるつまずき

よくあるつまずきとして、「参照整合性のチェックを外した状態でカスケードを探す」ミスがあります。カスケードのチェックボックスは参照整合性をオンにするまでグレーアウトしており、選択できません。操作手順として「まず参照整合性をオン → 次にカスケードをオン」の順番を覚えておきましょう。

もうひとつのよくあるつまずきは、カスケード更新・カスケード削除の名称を逆に覚えてしまうことです。「フィールドの連鎖更新」が主キーの値変更に対応し、「レコードの連鎖削除」が削除操作に対応します。日本語の名称でイメージを固めておくと本番での操作ミスを防げます。

MOS Access試験の受験料は一般価格と学割価格の2種類があり、税込金額です。最新の受験料は公式サイトの「受験料・価格」（https://mos.odyssey-com.co.jp/exam/examfee.html）でご確認ください。

まとめ

カスケード更新・カスケード削除は、Accessのリレーションシップで参照整合性を有効にした上で追加設定する2つのオプションです。

• カスケード更新（フィールドの連鎖更新）：親の主キー値を変更すると、子の外部キー値も自動更新される（オートナンバー型には設定不可）
• カスケード削除（レコードの連鎖削除）：親レコードを削除すると、対応する子レコードも自動削除される
• 設定は「データベースツール」タブ →「リレーションシップ」→ 結合線をダブルクリック →「リレーションシップの編集」ダイアログから行う
• カスケード削除は大量データが消えるリスクがあるため、設定前のバックアップと運用ルールの確認が必須
• MOS Access試験（MO-500）では、参照整合性とカスケード設定の実技操作が出題される

カスケードを正しく設定することで、データベース管理の手間を減らしながらリレーショナルデータの整合性を維持できます。設定する際は必ずバックアップを取り、削除の影響範囲を事前に把握した上で運用してください。

MOS Access試験の対策や、Accessデータベース設計の実務応用については、当サイトの他の記事もあわせてご確認ください。