AIでAccessのVBA・構造を解析する|属人化したシステムの可視化
仕様書ゼロのAccessでも、VBAとクエリをテキスト化してAIに渡せば処理の概要・依存関係の手がかりを集められます。読み取れること・読み取れないこと(accde/mde・業務の意図)の限界と、5ステップの実務手順を解説します。
結論:AIは解析の手がかりを集める道具であり、答えを出す道具ではない
仕様書がなく属人化したAccessでも、VBAコードやテーブル構造をテキスト化してAIに渡せば、処理の概要や依存関係の手がかりを集めることができます。ただし「AIが全部自動で解析してくれる」は過剰な期待です。AIが解析できるのは、テキストや画面キャプチャなど入力として取り出せた範囲に限られます。実行専用形式(.accde/.mde)はVBAソースコードそのものの解析には使えませんが、取得可能なテーブル構造や画面挙動などは解析材料にできます。業務の意図や例外の判断基準は、最終的に人が確認するしかない領域です。
当社の実務経験では、テキスト化して人が検証する運用を組み合わせることで、棚卸しの速度や確認範囲が改善する場合があります。ただし改善の度合いはAccessの状態(変数名の命名規則・コードの複雑さ・ドキュメントの有無など)によって大きく変わります。
AIで読み取れること
Accessファイル(.accdb/.mdb)をそのまま生成AIにアップロードしても、当社が2025年11月8日に確認した一般的なChatGPT利用環境では、ACCDB/MDBを直接かつ安定して解析できませんでした。AIが読める形にするには、まず人間がAccessの設計情報をテキストとして取り出す手順が必要です。
取り出せる情報は主に4種類です。VBA標準モジュールのコード、クエリのSQL文、テーブル構造(フィールド名・型・主キー・インデックス)、そしてマクロの定義一覧です。これらをテキスト化してAIに渡すと、処理の概要説明、クエリ間やVBA間の依存関係の整理、設計書の下書きといった出力が期待できます。ただし正確性は保証されず、人による照合が前提です。
テーブル情報の抽出にはAccessのDatabase Documenter(データベースドキュメンター)が使えます。VBAモジュールはVBE(Visual Basic Editor)上のVBProjectに含まれる各VBComponentを、VBComponentオブジェクトのExportメソッドでテキストファイルとして書き出せます(標準モジュールは.bas、クラスモジュールは.cls形式)。当社では独自のスクリプトでこれらを一括テキスト化してからAIに渡す手順を取っています。
AIで読み取れないこと(限界)
AIで解析できる範囲には明確な境界があります。誤解したまま使うと、見えていない部分を「ない」と判断する誤りが起きます。
| 状況 | AIで解析できるか | 補足 |
|---|---|---|
| VBAコードが読める.accdb/.mdb | テキスト化すれば対応可能 | VBEからモジュールをExportできる |
| 実行専用形式(.accde/.mde) | VBAは不可 | ソースコードが削除されているため。テーブル構造は別途確認できる場合あり |
| パスワードロックされたVBAプロジェクト | ロック解除前は不可 | 在職中の担当者がいれば解除できることもある |
| 業務の意図・例外の判断基準 | AIは推測のみ | 「このクエリが何のために使われているか」は現場に確認するしかない |
| フォーム・レポートのレイアウト | 構造プロパティのみ | AIが取り出せるのは設計プロパティの列挙。画面キャプチャを別途取得して画像対応AIに渡す方法もある |
.accde/.mde形式の場合はVBAを読む手がないため、テーブル構造とふるまいの観察が主な手がかりになります。この状況についてはaccde/mdeで中身が見られないAccessの解析で詳しく説明しています。
実際の手順:テキスト化からAI解析まで
2025年11月時点での実務的な流れは次のとおりです。
- VBAモジュールのエクスポート:VBE(Visual Basic Editor)を開き、VBProjectに含まれる各VBComponentをExportメソッドで書き出す(標準モジュールは.bas、クラスモジュールは.cls形式)。フォームやレポートのイベントコードは、イベントプロパティで呼出方式を確認し、実装はApplication.SaveAsTextで取得する方法もある。
- クエリSQL文の抽出:AccessのクエリをSQLビューで開き、SQL文をテキストファイルへコピーする。クエリ数が多い場合はDAOのQueryDefsを使ってSQL文を一括取得するVBAスクリプトを使うと効率的です。
- テーブル構造の書き出し:Database Documenterで出力するか、DAOのTableDefs・Fields・Indexesを列挙するVBAでテキスト化する。
- AIへのインプット:集めたテキストを生成AIに渡し、処理の概要、モジュール間の呼び出し関係、処理フロー、注意が要りそうな箇所を聞く。一度に全ファイルを渡すとAIのコンテキスト制限を超えやすいため、モジュール単位や機能単位に分けて問いかけるのが現実的です。
- 人による確認:AIの出力はあくまで手がかりです。「このクエリはマスタ更新に使われている」という解説が正しいかどうかは、実際の業務フローを知る人が照合します。
なお、「何が不明か」を特定する段階はブラックボックス化したAccessの解析手順でも解説しています。AI活用はその後の調査を効率化する位置づけです。
精度について誤解しやすいこと
AIを使った解析の精度について、よく聞かれる誤解を整理します。
当社の利用経験では、比較的単純なコードの要約や調査候補の抽出にAIは役立つ場合があります。ただし正確性は保証されず、変数名が意味不明な略語だったり、処理が複雑に絡み合っていると解釈が曖昧になります。正確性は保証されず、人による照合が必要です。
業務の文脈(「なぜこのフィールドに値を入れるのか」「この例外処理はどんな判断から来ているのか」)は、コメントや識別子からAIが推測できる場合はありますが、真の業務意図や判断理由は確定できないため、最終的には関係者による確認が必要です。精度を数値で示せる性質のものではなく、「解析の手がかりを集める速さと網羅性が改善する場合がある」という効果として捉えるのが正確です。
属人化したAccessの解析作業をゼロから始める場合の課題については、Access属人化の危険度と脱・属人化の進め方もあわせてご覧ください。
当社のAI解析サービスの位置づけ
当社がAccess解析でAIを使う目的は、「人の確認が要る箇所を絞り込む速さ」にあります。全体のVBAコードやクエリをAIで一通り読んで、複雑度が高い部分・外部連携が疑われる部分・エラー処理が怪しい部分に印を付けるという使い方です。そこから先は経験を持つエンジニアが実際のコードを追います。
お客様のAccessファイルが解析できる状態かどうかは、まず確認が必要です。解析可否チェックは無料の解析可否チェックからお申し込みいただけます。.accdeや.mdeで「VBAが読めないかもしれない」という状況でもご相談ください。テーブル構造とふるまいから取り出せる情報の範囲を確認します。
よくある質問
Q. .accdbファイルをChatGPTに直接アップロードすれば解析できますか。
当社が2025年11月8日に確認した一般的なChatGPT利用環境では、ACCDB/MDBを直接かつ安定して解析できませんでした。VBAモジュールのエクスポートやDatabase Documenterでテーブル構造をテキスト化してから渡す手順が必要です。
Q. AIを使えば仕様書が自動で完成しますか。
完成はしません。AIが業務の意図や例外の判断基準を推測として出力することはありますが、確定情報としては扱えません。AIの出力を下書きとして、業務を知る担当者が確認・補足することで初めて仕様書として使えるものになります。最低限残すべきドキュメントの考え方は仕様書がないAccessに最低限残すべきドキュメントで解説しています。
Q. .accde形式でVBAが読めなくても何か分かりますか。
テーブル構造やリレーション、フォームのコントロール名・プロパティはaccdeでも読み取れる場合があります。また、実際に画面を操作したふるまいから処理の流れを推測する方法もあります。VBAそのものを読むことはできませんが、移行の手がかりを集める方法は複数あります。
Q. 担当者が退職済みでコードの意味が誰も分からない場合でもAI解析は有効ですか。
コードから「何をしているか」の概要を読み取る作業にAIは役立つ場合があります。ただし「なぜそう作ったか」という意図は、元担当者が不在で仕様書や変更記録、関係者の証言も残っていない場合は特定が難しく、推測に頼る部分が増えます。担当者が退職する前に残しておくべき情報についてはAccessを作った担当者が退職する前にやるべきことでまとめています。
触れないAccessが「診断できるか」だけ、確かめませんか。
顧客データは送信不要。発注の義務もありません。
約2分・ファイル送信不要・発注義務なし/説明はオンライン・売り込みはしません