こんにちは！ 現場でバリバリとAccessやVBAを使ったシステム開発をしていると、避けて通れないのが「データの整合性」という名の魔物です。
「外部キー制約をちゃんとかけたはずなのに、インポートしたデータに変な値が混じってエラーになった…」
「手動でデータを突っ込んだせいで、親子の繋がりがブツ切りになってしまった…」
そんな修羅場をくぐり抜けてきたあなたなら、データを取り込む前に「リレーションシップが正しく組まれているか」「孤児レコード（親がいない子データ）が生まれていないか」をプログラムでパッと検証できたら、どれほど安心か想像できるのではないでしょうか。
今回は、Accessの内部構造の核心に迫る`CurrentDb.Relations`オブジェクトを使いこなし、データの整合性をVBAで完全に掌握するための極意を伝授します。ここをクリアすれば、あなたのAccess VBAのスキルは間違いなく一段上のステージに到達しますよ！
—
1. なぜ「動的なリレーション検証」が必要なのか？
通常、Accessの画面（リレーションシップウィンドウ）でテーブル同士を結び、データの整合性（参照整合性）を有効にしていれば、不正なデータは弾かれます。
しかし、大量のデータをCSVや外部DBから一括インポートする瞬間や、一時テーブルを駆使して複雑な集計を行うプロセスでは話が別です。あらかじめ制約の不備に気づけなかったり、インポートの順番を誤ったりすると、データベース全体がエラーの海と化してしまいます。
そこで、インポート処理の直前や日次バッチの最初に、「今、データベースのリレーション構造はどうなっているか」「ルールを破る不届きなデータ（孤児レコード）が潜んでいないか」をVBAで動的にスキャンし、自衛する仕組みが必要になるのです。
—
2. 基礎知識：CurrentDb と Relations コレクションの正体
VBAからAccessのデータベースを操作するとき、お馴染みなのが `CurrentDb` 関数です。
Dim db As DAO.Database
Set db = CurrentDb
この `db`（DAO.Databaseオブジェクト）の中には、そのデータベースが持つすべてのリレーションシップ情報が `Relations` コレクション として詰まっています。
構造のイメージ
CurrentDb (Database)
┗━━ Relations (コレクション：テーブルを繋ぐ「線」の集まり)
┣━━ Relation 1 (例: 顧客マスタ ── 受注テーブル)
┃ ┣━━ Table : 顧客マスタ
┃ ┣━━ ForeignTable: 受注テーブル
┃ ┗━━ Attributes : 参照整合性(Cascade等)のフラグ
┗━━ Relation 2 …
この `Relations` をループで総なめにし、どのテーブルとどのテーブルがどう結ばれているかをプログラムで読み解くことで、設計図通りの環境になっているかを動的に検証できるというわけです。
—
3. 実践！リレーションの存在確認と整合性チェックコード
お待たせしました。ここからは、開発現場でそのままコピペして使える実践的なコードをご紹介します。
このコードは、定義されているリレーションを走査し、「親テーブルに存在しないキーを持つ子データ（孤児レコード）」が子テーブルに紛れ込んでいないかをチェックする優れものです。
‘ ==============================================================================
‘ モジュール名: modRelationValidator
‘ 概要: データベース内のリレーションシップを走査し、参照整合性違反（孤児レコード）を検出する
‘ ==============================================================================
Public Sub VerifyDatabaseRelations()
Dim db As DAO.Database
Dim rel As DAO.Relation
Dim rs As DAO.Recordset
Dim sql As String
Dim violationCount As Long
Set db = CurrentDb
violationCount = 0
Debug.Print “=== リレーションシップおよび整合性チェックを開始します ===”
‘ データベースに定義されている全てのリレーションをループ処理
For Each rel In db.Relations
‘ システムテーブルや隠しテーブルを除外（通常のリレーションのみ対象）
If (rel.Attributes & dbRelationSystemObject) = 0 Then
Dim parentTable As String
Dim childTable As String
Dim fieldPair As DAO.Field
parentTable = rel.Table
childTable = rel.ForeignTable
Debug.Print vbCrLf & “チェック中: [” & parentTable & “] ──> [” & childTable & “]”
‘ 参照整合性（Cascading等）が有効にされているかチェック
If (rel.Attributes & dbEnforceIntegrity) <> 0 Then
Debug.Print ” -> 参照整合性: 有効”
‘ ここがポイント！
‘ 親テーブルに存在しないキーが子テーブルに無いかを調べるSQLを動的に組み立てる
‘ ※複数フィールドのリレーションにも対応できるよう、最初のフィールドを代表して検証
Set fieldPair = rel.Fields(0)
sql = “SELECT Count() AS OrphanCount FROM [” & childTable & “] ” & _
“WHERE [” & childTable & “].[” & fieldPair.ForeignName & “] IS NOT NULL ” & _
“AND [” & childTable & “].[” & fieldPair.ForeignName & “] NOT IN ” & _
“(SELECT [” & parentTable & “].[” & fieldPair.Name & “] FROM [” & parentTable & “]);”
‘ SQLを実行して孤児レコード数を取得
Set rs = db.OpenRecordset(sql, dbOpenSnapshot)
If rs(“OrphanCount”) > 0 Then
Debug.Print ” 【警告】整合性違反を検出！ 孤児レコード数: ” & rs(“OrphanCount”) & ” 件”
violationCount = violationCount + rs(“OrphanCount”)
Else
Debug.Print ” -> 整合性OK（違反データなし）”
End If
rs.Close
Else
Debug.Print ” -> 参照整合性: 無効（定義のみ）”
End If
End If
Next rel
Debug.Print vbCrLf & “=== チェック終了 ===”
If violationCount > 0 Then
MsgBox “警告: データベース内に合計 ” & violationCount & ” 件の参照整合性違反が見つかりました。” & vbCrLf & _
‘イミディエイトウィンドウを確認してください。’, vbExclamation, ‘整合性チェック
Else
MsgBox “素晴らしい！すべてのリレーションでデータの整合性が保たれています。”, vbInformation, ‘整合性チェック
End
‘ クリーンアップ
Set rs = Nothing
Set db = Nothing
End Sub
—
4. コードの深掘りとエンジニアの知見
上記のコードを書くにあたって、Access VBAの裏側の挙動を知る上での重要なポイントをいくつか解説しておきます。
① `rel.Attributes` のビット演算
DAOの `Relation.Attributes` プロパティは、複数のフラグがビット演算（OR結合）で格納されています。
- `dbEnforceIntegrity` が立っていれば、参照整合性が有効です。
- システム内部で自動生成されるリレーション（`dbRelationSystemObject`）をそのまま処理しようとするとエラーや無駄な処理になるため、必ず除外するフィルターをかけましょう。
② 複数フィールド（複合キー）への配慮
本格的なデータベース設計では、複数の列を組み合わせて外部キーにすることがあります。今回のサンプルコードでは簡略化のために `rel.Fields(0)`（最初の1番目のフィールド）を対象にしていますが、実務で完全なバリデーションを行う場合は、`For Each fieldPair In rel.Fields` で全てのペアを結合するSQLを動的構築するとさらに堅牢になります。
—
5. 陥りやすいエラーと対策
この動的検証を現場に導入する際、初心者が必ずと言っていいほどハマる罠がいくつかあります。
1. 「実行時エラー ‘3265’: 項目が見つかりません。」
- 原因: 削除されたテーブルや、名前が変更されたフィールドを指している「ゴースト・リレーション」がデータベース内に残っている場合に発生します。
- 対策: あらかじめリレーションの整合性を綺麗に整えておくか、エラーハンドリング（`On Error Resume Next` との適切な組み合わせ）を実装してください。
2. データ型不一致エラー（型が一致しません）
- 原因: 親の主キーが「長整数型(Long)」なのに、子の外部キーが「テキスト型(Short Text)」になっている場合、SQLの `IN` 句や結合で型不一致エラーが起きます。
- 対策: VBAのコードを実行する以前に、テーブル定義のデータ型が完全に一致していることが大前提です。
—
まとめ：データ構造をプログラムで「監視」する強さ
今回は、`CurrentDb.Relations` を使ったリレーションの動的検証と、孤児レコードの検出ロジックについて解説しました。
画面上でポチポチと設定を確認する時代から一歩進み、「プログラムが自らデータの健全性を監査する」というアプローチを手に入れたあなたは、もうただの初学者ではありません。立派なプロフェッショナル・エンジニアの思考回路を持っています。
データインポート処理の冒頭に今回の検証ロジックを組み込んでおくだけで、後から原因不明のバグに頭を悩ませる時間は劇的に減るはずです。
ここをクリアすれば、Access VBAの基本はバッチリです！ ぜひご自身の開発環境に組み込んで、その威力を体感してみてくださいね。
