1. マクロとVBAの基本的な違い
1.1 マクロとは?
- GUI(画面)操作で組み立てる簡易プログラム
- Access上であらかじめ用意されているアクション(OpenForm、Close、MsgBox など)を組み合わせて処理フローを作る
- コード(プログラム言語)を直接書かずに「手順」をビルダー画面で設定
- 条件分岐やエラー処理もある程度できるが、高度なロジックはやや制限がある
メリット: プログラミングの知識が少なくても、ある程度の自動化が可能
デメリット: 柔軟な分岐や外部ファイル操作など、多くのシナリオで限界がある
1.2 VBA (Visual Basic for Applications) とは?
- プログラミング言語を使って柔軟にロジックを記述
- Accessでフォームやレポートのイベントに紐付けられ、入力チェックや外部システムとの連携などを自由に実装
- マクロよりも細かい制御や大規模処理に向いている
- エラー処理も多彩で、ステップ実行デバッグが充実
メリット: 自由度が高く、外部APIやファイル操作、トランザクション制御など幅広いことが可能
デメリット: プログラミングの知識が必要。初心者には敷居が高いと感じられる場合が多い
2. それぞれの得意分野と使い分け
項目 | マクロ | VBA |
---|
コード記述の有無 | コード不要:GUIベースのアクション設定 | プログラミング言語:If文、ループ、APIコールなど |
操作の難易度 | 初心者が取り組みやすい | スキルが必要だが柔軟性・拡張性が高い |
外部連携(ファイル操作、API) | 制限あり:標準マクロ機能内にない処理は困難 | 可能:WinHttpRequestなどでREST APIも実装可能 |
イベントでの複雑ロジック | 基本的ロジックや条件分岐(Ifアクション程度) | 高度な条件やエラー処理、クラスモジュールも活用 |
エラー処理 | アクションレベルのOnError設定など | VBAのTry-Catch風のOn Error GoTo や豊富なデバッグ |
デバッグ | マクロの実行でエラー文が出る程度 | ステップ実行, ウォッチ変数, ブレークポイントなど充実 |
配布・バージョン差異 | バージョン差異の影響は少ない | VBA参照ライブラリのバージョン差に注意 |
3. 開発手順:まずマクロで動作を確認 → 必要に応じてVBAへ移行
多くの初心者はまずマクロで基本的な自動化(フォームを開く、メッセージを表示、簡単な条件分岐など)を体験すると、Accessの自動化の感覚を掴みやすいです。
- 小さな操作フローをマクロにする
- 例:ボタンクリックでフォームを開き、他のボタンを無効化、メッセージを表示して完了
- これをマクロビルダーで組んでみて、「こんな感じに動くのか」と体感
- ロジックが複雑化してきたらVBAに切り替える
- 「条件が多段階になる」「外部ファイルを扱いたい」「REST APIを呼びたい」「厳密なエラー処理をしたい」という段階になると、マクロで無理やりやるよりVBAに書いた方が簡潔
- マクロを「イベントプロシージャイベント プロシージャイベントプロシージャ」に置き換え、VBAコードを書き始める
- 並行利用:マクロは基本操作・VBAは高度処理
- ちょっとした「フォームを開いて~閉じて~」の操作はマクロのまま
- データ処理が複雑な部分だけVBAのサブを呼び出す
- Access 2010以降は「データマクロ」なども存在するが、メンテはやや複雑になる
4. 具体例:マクロでできること
- ボタンクリックでフォームを開く/閉じる
- OpenFormアクションやCloseWindowアクションをGUIで設定
- メッセージを出す
- MessageBoxアクションで警告やお知らせを表示
- 簡単な条件分岐(Ifアクション)
- “If [数量] > 10 Then MsgBox “数量多すぎ”” など
- レポート印刷やプレビュー
- OpenReportアクションでレポートを開く、印刷する
注意: これらは標準アクションの範囲で、複雑な外部サービスとの連携などは基本的に不可。
5. 具体例:VBAでできること
- 外部ファイル操作
- Excelやテキストファイルを読書き、フォルダ操作、画像処理など自由
- API呼び出し
- WinHttpRequestなどでREST APIと通信、Slack通知やWebサービス連携
- 複雑ロジック・トランザクション管理
- DAO/ADOでレコードセット操作やSQL文を動的生成、Commit/Rollbackなど
- 細かなエラー制御
On Error GoTo
で異なるエラー番号ごとに処理分岐、ステップ実行でバグを除去
- クラス化・再利用
- モジュール分割やクラスモジュールで大規模開発に耐えられる構成に
6. 運用のポイント:マクロとVBAを上手に組み合わせる
- 既存マクロをVBAに変換
- Accessのマクロビルダーでは、メニューから「VBAに変換」する機能(古いバージョンでは名称が異なる場合あり)がある
- まずマクロで動きを確認 → 変換してVBAコードを調整
- イベントごとのコントロール
- フォームのBeforeUpdateやAfterUpdateなど細かいイベントはVBAで制御した方が自由度が高い
- ボタンのOnClickイベントで軽い操作だけならマクロのままでもよい
- メンテナンス性
- 大規模アプリならVBAでモジュール化してソースを管理する方が分かりやすい
- シンプルアプリや初心者向けならマクロも視覚的にわかりやすい
7. まとめ:最初はマクロ、より高度な場面ではVBAへ
- マクロ:
– GUIベースの簡易的な自動化
– フォームを開く/閉じる、メッセージ表示、単純なIf分岐など
– コードを書かずに誰でも比較的短期間に作れる
- VBA:
– プログラム言語で柔軟な制御が可能
– 外部連携・ファイル操作・複雑ロジック・高度なエラー処理にも対応
– 開発者のコーディングスキルが必要だが、運用拡張性やデバッグ機能が強い
開発手順の提案:
- 簡単な操作(フォームを開く、表示メッセージ程度)はマクロで試す
- より複雑な処理(外部ファイル読み込み、API呼び出しなど)に直面したら、VBAへステップアップ
- 大規模・長期運用を想定するなら、最初からVBAベースで構築し、小さな機能でもメンテナンスしやすい構造を組む
これらのポイントを押さえれば、「マクロ or VBA」で迷う場面でも自分のニーズやスキルに合った選択がしやすくなります。最終的にはVBAを習得するほうが汎用性と拡張性に優れるのは確かですが、まずはマクロでAccess自動化の楽しさを知り、徐々にVBAへ移行する流れがおすすめです。
関連記事
Accessでは、小さい機能からでも自動化すれば業務効率が大きく上がります。マクロとVBAの両方を上手に組み合わせ、必要なときに柔軟に発展していく開発スタイルをぜひ実践してみてください。
ABOUT ME

入社した会社では、Accessを活用した基幹システムが長年運用されていました。しかし、開発者の高齢化により保守が困難となり、システムの維持・更新が急務に。
ほぼAccessに触れたことのなかった私は、ゼロから学びながら基幹システムを再構築してみることに。ついにはAccessによるシステム開発エンジニアとしてのスキルを身につけるまでに成長。
元々の業務のノウハウとそれを効率化するためのツール(Access)によって業務効率化システムをいくつも開発してきました。
みなさんの”なにか(業務のノウハウ)”とAccessで業務効率化を実現するお役に立てれば幸いです。
月30万の高配当投資も行っています。最新の銘柄情報もお届けしていきます。