AccessのマクロとVBAの違いと使い分け入門

結論：マクロはGUI操作の自動化、VBAはプログラミング言語

Accessには「マクロ」と「VBA」という2つの自動化手段があります。マクロはドロップダウンで操作を選ぶGUI型の仕組みで、コードを書かずにフォームの開閉やレポートの印刷などを自動化できます。VBAはプログラミング言語で、マクロより格段に広い処理が書けますが、コードの読み書きが必要です。

初心者がどちらから入るかという問いに対しては、まずマクロを試してみるのが現実的です。ただし業務が複雑になるほどVBAが必要になる場面が増え、マクロだけでは対応しきれなくなります。どちらも「できること」と「できないこと」があるので、その違いを整理しておくと判断が楽になります。

マクロとVBAの違いを比較表で整理する

Microsoftの公式ドキュメントによると、マクロのアクション（操作の命令）はVBAで使えるコマンドの一部にすぎません。逆に言えば、マクロで使えるアクションはすべてVBAでも書けます。以下の比較表で主な違いをまとめます。

「VBAは万能、マクロは劣化版」という見方は正確ではありません。セキュリティ面ではマクロに利点があり、配布するデータベースでは意図的にマクロだけを使う設計にすることもあります。

マクロで何ができるか：UIマクロ・データマクロ・特殊マクロ

Accessのマクロには大きく分けて「UIマクロ」と「データマクロ」の2種類があります。これに加え、特殊な名前を付けることで自動実行などの動作をするマクロもあります。

UIマクロはフォームやレポート、コントロール（ボタンなど）に紐付けて使います。「ボタンをクリックしたら別のフォームを開く」「レポートを印刷する」「フィルターを適用する」といった操作の自動化に使います。UIマクロにはさらに2種類あります。

• スタンドアロンマクロ：ナビゲーションウィンドウに「マクロ」として表示される独立したオブジェクトです。複数の場所から呼び出せます。
• 埋め込みマクロ：フォームやレポートのイベントプロパティに直接埋め込む形式です。ナビゲーションウィンドウに表示されないため、特定のフォームやレポートに専用の処理を持たせるときに向いています。

データマクロはAccess 2010で追加された機能で、テーブルのイベント（レコードの追加・更新・削除）に直接ロジックを紐付けます。SQL Serverのトリガーに近い動きをします。フォームを経由せずテーブルを直接操作された場合でもロジックが走る点が特徴です。対応するイベントは次の5つです（公式ドキュメントによる）。

• Before Change（変更前）
• Before Delete（削除前）
• After Insert（挿入後）
• After Update（更新後）
• After Delete（削除後）

ただしデータマクロはリンクテーブルには適用されません。ローカルテーブルのみが対象です。

AutoExecマクロは、データベースを開いたときに最初に実行されます。Microsoftの公式ドキュメントには「AutoExecマクロはほかのすべてのマクロやVBAコードより先に実行される（スタートアップフォームが指定されていても）」と明記されています。ログイン画面を最初に表示したい、データベースが信頼済みかどうかチェックしたいといった用途に使われます。AutoKeysマクロは特定のキー操作にアクションを割り当てるもので、たとえば「Ctrl+P」で特定のレポートを印刷するといった設定ができます。

VBAでしかできないこと

マクロでは対応しきれない処理が出てきたとき、VBAが必要になります。公式ドキュメントによると、VBAを使う場面の例は次のとおりです。

• カスタム関数を作る（例：複雑な計算式をまとめた独自関数）
• レコードをループ処理する（1件ずつ条件を判定して更新するなど）
• データベースオブジェクトをプログラムで作成・変更する
• ファイルの存在確認やフォルダ操作などシステムレベルの処理をする
• Windows DLLを呼び出す
• 外部プログラムとの連携（AutomationやDDE）

実務でよく問題になるのは「UIマクロからのレコードループ処理」です。たとえばボタンクリックをきっかけに「受注テーブルを全件確認して、ステータスが未完了のものだけメール送信フラグを立てる」といった処理は、UIマクロだけでは書けません。VBAでRecordsetオブジェクトを使うことになります。データマクロにはForEachRecordというループ構造がありますが、これはテーブルイベント（追加・更新・削除）に紐付く処理の中での利用に限られます。

なお、WindowsのVBScriptは段階的に廃止される予定ですが、VBA自体は廃止対象ではありません。ただしVBAコードの中でVBScript.RegExpやScriptControlを使っている場合は影響が出ることがあります。詳しくはVBScript廃止はAccess VBAに影響するかをご覧ください。

属人化リスク：VBAは読める人がいないと詰む

マクロには「画面を見ればある程度わかる」という利点があります。一方VBAは、コードを書いた本人しか読めない状態になりやすく、担当者が退職したり異動したりすると誰も手を入れられなくなります。

特に注意が必要なのは、複雑なVBAが書かれたAccess DBが社内に複数存在しているケースです。「動いているから触りたくない」という状態が長く続くと、コードの意味が誰にもわからなくなり、バグを直そうにも影響範囲が把握できない状況に陥ります。

AccessのVBAで属人化が起きやすいもう一つの理由は、VBEのパスワードロック機能です。パスワードをかけてしまうと、コードを見ることすらできなくなります。こうした状態についてはAccess属人化の危険度と脱・属人化の進め方で詳しく解説しています。

VBAのコード量が多く、属人化が進んでいるAccessの場合、移行の際に「何の処理をしているかがわからない」問題が発生します。社内のAccess DBが似た状況にある場合は、まず現状を把握することが先決です。無料の解析可否チェックで、解析・移行の見通しだけでも確認しておくことをお勧めします。

初心者はどちらから入るべきか

マクロから始めるのが現実的です。コードを書かずに「ボタンを押したらフォームが開く」「レポートを印刷する」といった基本的な自動化を試せます。マクロビルダーにはアクションカタログとIntelliSenseが備わっており、どんな命令が使えるかをその場で確認しながら組み立てられます。

マクロで物足りなくなったら、マクロをVBAに変換する機能を使って移行するのが一つの方法です。マクロビルダー上で「マクロをVisual Basicに変換」というコマンドがあり、既存のマクロを元にVBAコードを生成できます。すべてがきれいなコードになるわけではありませんが、VBAの書き方を学ぶ手がかりにはなります。

AccessとExcelの使い分けも含めた基礎知識についてはAccessとExcelの違いも参考にしてください。

よくある質問

Q. マクロとVBAのどちらが「上位」ですか。

VBAのほうができることが広く、マクロのアクションはVBAコマンドの一部にすぎません。ただし「マクロ＝劣化版」ではなく、セキュリティや保守性の面でマクロを意図的に選ぶ設計もあります。どちらが優れているかではなく、用途に合わせて選ぶものです。

Q. 既存のVBAをマクロに変換できますか。

Accessには「マクロをVBAに変換」する機能はありますが、その逆（VBAをマクロへ変換）はありません。VBAで書いた処理の一部をマクロで置き換えることは個別に作り直せば可能ですが、自動変換ツールは提供されていません。

Q. データマクロとUIマクロは何が違いますか。

UIマクロはフォームやコントロールのボタンクリックなど、画面操作をきっかけに動きます。データマクロはテーブル上のデータ変更（追加・更新・削除）をきっかけに動きます。フォームを介さずテーブルを直接変更した場合でもデータマクロは実行されるため、データの整合性を保つ用途に向いています。

Q. VBAがわからない担当者が引き継ぐと何が起きますか。

動作しているうちは問題が見えませんが、エラーが出たり仕様を変更したくなったりしたときに手が出せなくなります。パスワードロックがかかっていればコードを見ることもできません。この状態を放置すると、修正のたびに外部に依頼するか、最悪は業務を止めるリスクにつながります。