概要
| この記事の結論 Accessの「オブジェクトの依存関係」は、テーブルやクエリの利用先・参照元を調べる機能です。ナビゲーションウィンドウで対象を選び、[データベースツール]から開きます。改修前の影響調査に役立ちますが、VBAや一部のクエリは調査対象外です。表示結果を手がかりに追加調査と業務テストを行い、変更や削除の可否を判断しましょう。 |
この記事でわかること
- 依存関係の意味とリレーションシップとの違い
- 依存関係を表示する手順と、利用先・参照元の読み分け
- 表示されないときに確認する設定と制約
- 標準機能に加えて調べる範囲と、改修前後の確認方法
この記事の主な内容
- オブジェクトの依存関係とは?何を調べられる?
- オブジェクトの依存関係を表示する手順
- 2つの表示方向と一覧の見方
- 表示されない・使えないときの確認方法
- 依存関係だけでは確認できない範囲
- 改修・削除の前に行う影響調査の進め方
- まとめ
- よくある質問(FAQ)
想定読了時間:約12分~約15分
1. オブジェクトの依存関係とは?何を調べられる?
オブジェクトの依存関係とは、Accessのテーブル・クエリ・フォーム・レポート間の利用関係を調べる標準機能です。テーブルやクエリを変更する前に、どの画面や帳票を確認すべきか、調査対象を絞り込むために使います。
利用先と参照元を確認する機能
例えば、商品データを保存する「T_商品」、商品を抽出する「Q_商品一覧」、検索画面の「F_商品検索」、帳票の「R_商品一覧」があるとします。ここでは、クエリが商品テーブルを参照し、画面と帳票がそのクエリを使う構成を説明例にします。
この場合、Q_商品一覧を削除すると、利用している画面や帳票が開けなくなる可能性があります。まずクエリの利用先を調べれば、変更後に確認する候補として、検索画面と一覧帳票を挙げられます。実際の修正要否は、それぞれの設定や処理を開いて判断します。

なお、オブジェクトの名前が表示されても、フィールド変更による影響がすべて分かるわけではありません。「この画面でどのフィールドを表示しているか」「集計式にも使っているか」など、変更内容に応じた確認が必要です。
リレーションシップとの違い
リレーションシップは、主キーと外部キーなどを使ってテーブル間の関連を定義するものです。一方、依存関係は、クエリや画面・帳票を含むオブジェクトの利用状況を調べるものです。近い場所にある機能ですが、目的が異なります。

| 比較項目 | オブジェクトの依存関係 | リレーションシップ |
|---|---|---|
| 主な目的 | 変更対象の利用先・参照元を調べる | テーブル間の関連を定義・確認する |
| 主な確認対象 | テーブル、対応クエリ、フォーム、レポート | テーブル間を結ぶフィールド |
| 使う場面 | 改修前の影響候補の調査 | 関連データの設計や参照整合性の設定 |
また、クエリのデザインビューにある結合線と、データベース全体のリレーションシップ設定も同じものではありません。画面や帳票の利用先を知りたい場合は、依存関係の表示を入口にしましょう。
2. オブジェクトの依存関係を表示する手順
表示の流れは、調査するファイルを開き、対象を選択してから[データベースツール]の[オブジェクトの依存関係]を押す、という順序です。まずは調査用コピーで、対象名と表示内容を確かめます。[1]
バックアップと調査用コピーを用意する
最初に、作業前の状態へ戻せるバックアップを確保します。そのうえで、普段の業務ファイルと見分けられる場所に調査用コピーを用意しましょう。共有ファイルは、利用者の作業終了を確認するなど、社内のバックアップ手順に従って扱います。
フォームなどを置くフロントエンドと、データを置くバックエンドを分けている場合は、両方の保管場所を記録します。コピーしたフロントエンドも本番データへ接続していることがあるため、更新や削除のテストをする前にリンク先も検証用へ切り替えてください。
対象を選びデータベースツールから開く
1. 調査用のAccessデータベースを開きます。
2. ナビゲーションウィンドウで、調べたいテーブル・クエリ・フォーム・レポートを選択します。説明例では「Q_商品一覧」を選びます。
3. リボンの[データベースツール]を選択します。
4. [リレーションシップ]グループの[オブジェクトの依存関係]をクリックします。
5. 情報更新の確認が出た場合は、調査用ファイルであることを確認して進め、表示が完了するまで待ちます。

情報更新と対象名を確認する
ウィンドウが開いたら、最初に調査対象の名前を確認します。意図したQ_商品一覧ではなく、別のテーブルやフォームが対象になっていると、結果の意味も変わります。画面を開けたことだけで安心せず、対象名を調査記録と一致させましょう。
名前の自動修正情報のトラッキングを有効にするよう求められた場合は、後述の設定を確認します。情報の生成・更新には時間がかかることがあります。処理中に何度も操作したり、表示が遅いという理由だけで本番ファイルの設定を変更したりしないようにします。
3. 2つの表示方向と一覧の見方
同じQ_商品一覧を選んでも、「それを使っている側」と「それが使っている側」では、表示する相手が変わります。本記事では、前者を「利用先」、後者を「参照元」と呼び、何を調べたいかに合わせて使い分けます。
選択したオブジェクトを使っている側
Q_商品一覧を変更・削除した場合の影響候補を知りたいときは、利用先を確認します。説明例では、クエリを利用するF_商品検索とR_商品一覧が調査対象になります。「このクエリを使っているのは誰か」と読むと、方向を理解しやすくなります。
選択したオブジェクトが使っている側
Q_商品一覧がどのデータを使っているか知りたいときは、参照元を確認します。説明例ではT_商品です。画面の表示内容をさかのぼって調べる場合も、画面が使うクエリ、クエリが使うテーブルという順に、設計を確認していきます。
| 調べたいこと | 見る方向 | Q_商品一覧を選んだ例 |
|---|---|---|
| 変更の影響候補を知りたい | 選択対象を使っている側(利用先) | F_商品検索、R_商品一覧 |
| 元のデータを知りたい | 選択対象が使っている側(参照元) | T_商品 |
英語UIでは、利用先が「Objects that depend on me」、参照元が「Objects that I depend on」に対応します。日本語の表示では、選択対象を基準に「使う側」「使われる側」のどちらかを確認してください。

展開と調査対象の切り替え
一覧に展開用の[+]がある場合は、クリックして関連するオブジェクトを確認します。Microsoftの説明では、表示は最大4階層です。深い階層や対象外の処理まで、すべてを一度に調べられる機能ではありません。
途中のクエリを詳しく調べるときは、そのクエリを新たな調査対象にします。ナビゲーションウィンドウで選択し、依存関係ウィンドウの対象名が切り替わったかを確認してください。必要に応じてウィンドウを開き直し、前の対象の結果を記録しないようにします。

4. 表示されない・使えないときの確認方法
表示されない場合は、対象と方向、トラッキング設定、権限や更新状態、機能の制約を順に確認します。一覧が空であるという結果だけでは、対象オブジェクトが使われていないとは判断できません。
選択対象と表示方向を確認する
まず、調べたいファイルを開いているか、対象名が正しいかを確認します。同じ名前のファイルが複数ある場合は、フォルダや更新日時も記録しましょう。次に、利用先を知りたいのに参照元を見ていないか、表示方向を確認します。
例えば、元データを持つテーブルと、そのテーブルを利用するクエリでは、調べる方向によって表示が変わります。画面で選択した相手と調査メモを照合し、必要に応じて双方の方向を確認することが、最初の切り分けになります。
名前の自動修正情報のトラッキングを確認する
依存関係の表示には、名前の自動修正機能が管理する「名前マップ」という内部情報が使われます。そのため、情報をトラッキングする設定が無効な場合は、有効化を求められます。トラッキングとは、ここでは名前や利用関係の情報を追跡・保持することです。[2]
1. 調査用コピーで[ファイル]→[オプション]を開きます。
2. [現在のデータベース]を選び、名前の自動修正に関する設定を確認します。
3. 「名前の自動修正情報をトラックする」など、情報の追跡を行う項目を確認します。無効な場合は必要に応じて有効にし、表示される案内に従って更新します。
「情報のトラッキング」と「名前の自動修正を実行する」は別の設定です。情報のトラッキングだけを有効にしても、それだけで名前変更の自動修正が実行されるわけではありません。依存関係を調べるために、関連するチェック項目をすべてオンにする必要はありません。

有効化時には、排他アクセスを試みたり、開いているオブジェクトを閉じて情報を更新したりします。共有利用中のファイルへ無計画に適用せず、調査用コピーで確認してください。設定の詳しい役割は、「テーブルの名前変更を自動的に修正する方法」も参照してください。
権限と情報更新と対象外オブジェクトを確認する
対象をデザインビューで開く権限がない場合、依存関係の情報は利用できません。また、名前マップの更新を途中で中断すると、トラッキングがオンでも情報が古いまま残る場合があります。設定のチェック状態だけで、更新完了と判断しないことが大切です。
| 症状 | 確認する点 | 対応 |
|---|---|---|
| 意図した結果が出ない | ファイル・対象名・表示方向 | 正しい対象を選び直す |
| 設定の有効化を求められる | 情報のトラッキング | 調査用コピーで設定を確認 |
| 一部だけ情報が出ない | 権限・更新の中断 | デザインビューで開けるか、情報更新が完了したか確認 |
| 特定のクエリ等が出ない | 非対応の種類ではないか | SQLやコードを別途確認 |
| 一覧が空欄になる | 上記と実際の利用状況 | 未使用と決めず追加調査する |
特定のオブジェクトの名前マップは、デザインビューで開いて保存する方法で更新できます。まずコピー上で試し、更新後に依存関係を再確認します。全体の再作成が必要な場合は、公式資料[2]の手順を確認してから進めましょう

5. 依存関係だけでは確認できない範囲
依存関係の表示には対象外があります。したがって、表示された一覧は調査の入口として使い、コードや外部連携まで含めた最終判断は別途行います。特に削除を検討している場合は、通常の画面操作では使われない月次処理や年次処理にも目を向けましょう。
VBAとマクロとSQL固有のクエリ
Microsoftは、マクロとコードモジュールの情報は表示されないと説明しています。また、ユニオン・データ定義・パススルーなど、SQL固有のクエリも対象外です。
例えば、ボタンのVBAからクエリを呼び出している場合、その処理を依存関係の一覧だけで確認したつもりにならないようにします。使っていないように見えるクエリでも、請求締めや一括出力の処理から呼ばれている可能性があります。
サブクエリやルックアップなどの制約
サブクエリなど、入れ子の内部まで依存情報が生成されないケースがあります。公式資料では、クエリのサブデータシートの参照元やルックアップフィールドにも制約が示されています。対象外の項目が「無視されたオブジェクト」などの区分に出る場合もあります。
保存クエリを別の保存クエリから参照する構成と、SQL文の中に書くサブクエリを混同しないようにしましょう。調査では、画面に見える名前だけを追うのではなく、必要なクエリのデザインやSQLビューを開き、何を参照しているか確認します。
別ファイルや外部システムの利用状況
実務では、別のAccessファイルやExcelから同じデータを利用しているケースも調べます。1つのファイルの依存関係を見ただけで、社内のすべての利用先を把握したとは判断できません。共有フォルダの配布物、接続設定、処理手順書、利用者への確認を組み合わせます。
データをSQL Serverなどへ保存している場合も、Access側の画面やクエリの調査に加えて、サーバー側の処理や他システムからの利用状況を確認します。これは、標準機能の表示を補うための実務上の調査です。

VBAや外部連携が多く、影響範囲を追いきれない場合は、調査の段階から専門担当者へ相談すると進め方を整理できます。インフォースでは、既存Accessの構造調査から改修・保守まで、状況に応じた支援をご相談いただけます。
6. 改修・削除の前に行う影響調査の進め方
影響調査では、「どこで使うか」に加え、「何を直し、どう確かめるか」を記録します。オブジェクト名だけの一覧よりも、業務用途と確認結果を残す方が、修正漏れの確認や担当者間の引き継ぎに役立ちます。
変更内容と業務への影響を記録する
まず、変更したい内容を具体的にします。「商品情報を直す」ではなく、「Q_商品一覧の抽出条件を変える」「商品名フィールドの名前を変える」「不要と思われるクエリを削除する」のように書くと、調べる箇所とテスト項目を決めやすくなります。
次に、利用先と実際の参照箇所を確認します。以下は、Q_商品一覧を変更する場合の記録例です。実案件の検証結果ではなく、調査項目の書き方を示すものです。
| 利用先 | 参照箇所 | 業務用途 | 修正要否・確認結果 |
|---|---|---|---|
| F_商品検索 | レコードソース、画面の表示項目 | 商品検索 | 要調査/表示件数・検索を確認予定 |
| R_商品一覧 | レコードソース、集計式 | 商品一覧の印刷 | 要調査/印刷内容・集計を確認予定 |
| 関連するVBA・マクロ | クエリの呼び出し、SQL等 | 一括処理 | 追加調査/実行条件を確認予定 |
実際の記録には、変更対象、担当者、確認日、修正内容、期待結果、実測結果も加えます。表示件数や合計値が変わる変更なら、何件・いくらになる想定かを先に決めておきましょう。
コードとプロパティと外部連携を補足調査する
フォームやレポートでは、レコードソースやコントロールソースを確認します。レコードソースは画面や帳票が使うデータの出所、コントロールソースはテキストボックスなどの表示・入力先となる項目や式です。コンボボックスの値集合ソースも、必要に応じて確認します。
VBAを編集できる場合は、VBEの検索で対象名を探し、DoCmd.OpenQueryやRecordSourceなどの使用箇所を確認します。ただし、文字列を組み立ててSQLや名前を作る処理は、完全な名前の検索だけでは見つからないことがあります。検索結果を起点に、処理の流れも読んで確認してください。
- フォーム・レポート:レコードソース、表示項目、集計式、イベント処理
- クエリ:参照テーブル、フィールド、抽出条件、SQL
- VBA・マクロ:名前の参照、呼び出し、実行条件
- 外部連携:別のAccess・Excel、CSV入出力、定期処理
クエリの基本を確認する場合は下記の「Accessのクエリとは」、設計画面の操作は「デザインビューの使い方」を参照してください。
調査用コピーで修正し業務テストを行う
修正は調査用コピーで行い、想定する入力と出力を使ってテストします。フォームが開けるだけで完了にせず、検索、登録、印刷、CSV出力など、今回の変更が関係する操作を実施してください。外部送信や本番データの更新を行う処理は、検証先へ切り替えてから試します。

1. バックアップと、問題が出た場合に戻す手順を確認します。
2. 変更対象の利用先を調べ、コードや外部連携の追加調査を行います。
3. コピーで修正し、修正内容と確認項目を記録します。
4. 画面・帳票・出力・定期処理を確認し、期待結果と照合してから本番反映を計画します。
変更後に「パラメーターの入力」を求められた場合は、存在しないフィールド名などを参照していないか確認します。記事No.031「パラメーターの入力を求められる原因」も、切り分けの参考になります。名前の自動修正を設定していても、変更後の動作確認は省略しないようにしましょう。
まとめ
オブジェクトの依存関係を使うと、Accessの改修前に、利用先や参照元を調べられます。対象名と表示方向を確認し、必要なオブジェクトを順に追うことで、確認すべき画面や帳票を整理できます。
ただし、一覧だけで影響調査が完結するわけではありません。バックアップを確保し、コードや外部連携を補足調査したうえで、コピーで修正と業務テストを行いましょう。調査結果とテスト結果を記録しておくことが、次の改修や引き継ぎにも役立ちます。
変更の影響範囲が分からないAccessは改修前にご相談ください
テーブルやクエリを変更したいものの、関連する画面・帳票・VBAを追いきれない場合は、お気軽にご相談ください。現状の構成と運用を確認し、調査・改修・保守の進め方を整理します。
- 前任者が退職し、構造や処理の流れが分からない
- VBAや外部連携が多く、変更箇所を特定しにくい
- 複数のファイルで同じデータを利用している
- 業務を止めにくく、検証と本番反映の進め方を整理したい
よくある質問(FAQ)
依存関係は、テーブルやクエリがどの画面・帳票などで使われるかを調べる機能です。リレーションシップはテーブル間の関連を定義・確認する機能です。改修時の影響候補を調べるには依存関係を使います。
まず対象名と表示方向を確認し、次に情報のトラッキング、デザインビューで開く権限、情報更新の状態を確認します。対象外のクエリやコードに関する情報は、別途調査が必要です。
一覧が空というだけでは判断できません。VBAや外部ファイルなどから使われていないか追加調査し、コピーでの修正と業務テストを終えてから削除を判断します。月次・年次など、実行頻度が低い処理も確認してください。
標準の依存関係ウィンドウには、マクロとコードモジュールの情報は表示されません。VBEでの検索やマクロの内容確認を行い、実際にどのオブジェクトを呼び出しているか調べます。
依存関係に必要な情報のトラッキングと、名前変更を自動修正する実行設定は別です。表示のためにすべての設定をオンにする必要はありません。トラッキングだけを有効にしても、自動修正の実行にはなりません。
参考情報
[1] Microsoft Support オブジェクトの依存関係ウィンドウの使い方