ブラックボックス化したAccessの解析手順｜仕様書ゼロから構造を可視化

結論：仕様書がなくても、Accessの構造は4段階の手順で可視化できる

作った人がいない、仕様書が残っていない、なのにそのAccessを止めるわけにもいかない。こういった状況で中身を把握するには、Accessが持つ標準機能（Database Documenter・オブジェクトの依存関係）と、設計情報の解析を組み合わせた手順が有効です。ソースが読めないaccde/mde形式でも、データ構造やふるまいから手がかりを取り出せる場合があります。

この記事では、ブラックボックス化したAccessを解析する4段階の手順を整理します。ツールの使い方から、当社が実務で確認したリスク特定の観点まで、順に解説します。

なぜAccessはブラックボックス化するのか

Accessはテーブル・クエリ・フォーム・マクロ・VBAコードがひとつの.accdbファイルに同居します。業務仕様書を自動生成する仕組みはないため、担当者の頭の中に仕様があるまま運用されがちです。担当者が退職したり、長期間改修が凍結されたりすると、「動いているが誰も説明できない」状態に至ります。

accde/mde形式（VBAソースとフォーム・レポート等の設計変更を制限した配布形式）になると通常の方法ではVBAコードを読めなくなります。テーブルやクエリ・マクロは確認できる場合が多いですが、元のaccdbが手元にない場合は把握できる範囲に限界があります。accde/mdeの詳細はaccde/mdeで中身が見られないAccessで解説しています。

ブラックボックス化は単なる「分かりにくさ」にとどまりません。改修できないまま環境変化に対応できず、止まったときに誰も直せないというリスクに直結します。Access属人化の危険度と脱・属人化の進め方もあわせてご覧ください。

手順1：オブジェクト一覧の全量把握

最初にやることは、Accessファイルに何が入っているかを一覧で把握することです。Accessには「Database Documenter（データベース ドキュメント作成ツール）」という標準機能があり、テーブル・クエリ・フォーム・レポート・マクロ・モジュールの設計情報を詳細なレポートとして出力できます。

操作はメニューの「データベース ツール」タブ→「Database Documenter」から行います。「すべてのオブジェクト型」タブを開き、「すべて選択」をクリックしてからOKを押すと、プリントプレビューに全オブジェクトの設計詳細が出力されます。フォームであれば、フォーム全体のプロパティ、各セクション、ボタン・ラベル・テキストボックスなどのコントロールのプロパティ、さらにコードモジュールとユーザー権限まで列挙されます（Microsoft Support: Document and print your database design）。

ただし、このレポートは量が多い割に読みにくく、そのまま設計書として使うには整理が必要です。まずは「何が存在するか」の全量を把握するためのスタート台として使うのが現実的です。

手順2：オブジェクト間の依存関係を追跡する

次は「各オブジェクトが何に依存しているか」を確認します。Accessの「オブジェクトの依存関係」ウィンドウを使うと、テーブル・クエリ・フォーム・レポートがどのオブジェクトをデータソースとして使っているか、また逆にどのオブジェクトから参照されているかを視覚的に確認できます。ただしこの機能を使うには、対象をデザインビューで開ける権限があり、かつ「名前の自動修正情報を追跡する」オプションが有効になっている必要があります。フォームやレポートをデザインビューで開けないaccde/mde形式では、依存関係をたどれないことがあります。

操作はナビゲーションウィンドウでオブジェクトを選択し、「データベース ツール」タブ→「オブジェクトの依存関係」をクリックします。「自分に依存するオブジェクト」と「依存するオブジェクト」を切り替えながら、最大4階層まで展開して確認できます（Microsoft Support: オブジェクトの依存関係ウィンドウ）。

注意が必要なのは、このウィンドウはマクロとコードモジュールの依存情報を表示しません。ユニオンクエリやパススルークエリ、サブクエリも対象外です。VBAコード内で文字列として別オブジェクトを参照している箇所は、ここには現れません。この限界は後の手順で補います。

手順3：処理フローを実際のふるまいから復元する

オブジェクト一覧と依存関係だけでは、「どの業務でどの画面が使われ、何の処理が走るか」という処理フローは見えません。特にVBAを多用するケースでは、コードを読まないと動作を把握できない箇所が出てきます。

処理フローを復元する手がかりは2種類あります。ひとつはVBAコードのモジュール参照です。accdbが手元にある場合、VBE（Visual Basic Editor）を開いてコードを読むと、どのフォームがどの処理を呼んでいるかが分かります。もうひとつは実際の画面操作です。入力から出力（帳票・集計・エクスポート）の流れを実際に動かしてトレースすると、コードを読まなくても処理の概形が見えてきます。

当社の解析では、設計情報の静的解析と、実際のふるまいの動的解析を組み合わせて処理フローを復元します。特にaccde/mdeのようにソースが読めない場合でも、外から見えるふるまいを手がかりに仕様を再構成できます（当社実務）。

手順4：リスク箇所を特定して優先順位をつける

構造と処理フローが見えたら、次はどこが危ないかを整理します。優先度が高いリスク箇所の判断基準は次の通りです（当社実務）。

• 業務の起点になるフォームやクエリが、単一のテーブルに強く依存している
• 多くのオブジェクトから参照されているテーブルやクエリ（削除・変更の影響が広い）
• エラー処理なしで走るVBAコード（止まると原因が追えない）
• 外部ファイル（Excelシートやテキストファイル）へのリンクやインポート処理（パスが変わると壊れる）
• 顧客情報や請求データなど、破損時に業務が止まるテーブルの容量と更新頻度

リスク箇所が特定できると、「全面作り直し」か「危険な部分だけ先に手当て」かの判断ができます。全部を一気に直す必要はなく、止まると困る箇所から順番に対処するのが現実的です。

中身の解析から着手したい場合は、まず無料の解析可否チェックでそのAccessが解析できるかを確認できます。ファイルの送信は不要で、状況をお知らせいただくだけです。

AIを使った解析について

当社ではAccessファイルを隔離した環境でAIが設計情報を自動解析し、テーブル構造・依存関係・リスク箇所をレポートにまとめます。解析の時間短縮を目的としてAIを活用しているため、規模が大きいAccessでも解析の可能性が広がっています（当社実務）。

ただし、AIは文脈を外れた業務ルール（「この得意先コードは廃番だが残している」「このクエリは月末だけ使う」など）は読み取れません。AIの解析結果をベースに、業務担当者へのヒアリングで補完する形が実務では安定しています（当社実務）。なお、顧客データそのものは外に送らず、設計情報だけを解析対象とします。

よくある質問

Q. Database Documenterを使えば、それだけで仕様書が完成しますか。

いいえ。Database Documenterのレポートはプロパティの羅列で、業務ロジックや処理フローは出力されません。「何があるか」は把握できますが、「何をしているか」は別途コードやふるまいを読む必要があります。仕様書として使えるようにするには、出力内容をもとに人が整理する作業が要ります。

Q. accde形式でソースが読めない場合、手順はどこまで進められますか。

テーブルのデータ構造やクエリ定義はaccde/mdeでも確認できる場合が多いです。一方、VBAコードとフォーム・レポート・モジュールの設計は閲覧・編集が制限されるため、手順3の処理フローはふるまい観察が中心になります。元のaccdbが手元にある場合と比べると情報量は減りますが、移行の手がかりを取り出すこと自体は可能なケースが多いです。

Q. 解析にはどのくらいの時間がかかりますか。

Accessファイルの規模（テーブル数・クエリ数・VBAの行数）によって変わります。当社の解析サービスでは、隔離環境でAIが設計情報を自動解析し、依存関係とリスク評価を含む詳細レポート（20万円から）をお渡しします。解析にかかる期間は規模に応じてお見積もりの段階でお伝えします。

Q. 解析だけ依頼して、移行開発は別の会社に頼めますか。

対応しています。当社の解析レポートは、開発会社がそのまま設計図として使える形式でお渡しします。移行開発は御社の開発会社で進めていただいても、当社で対応することも可能です。