クリック操作で作るマクロか、VBAで書くか？迷わない判断基準

クリック時イベントの基本と選び方（マクロかVBAか）

クリック時イベントは、ボタンなどのコントロールをクリックしたときに実行される処理のことです。Access では、処理の作り方が大きく2通りあります。1つは画面で組み立てる「マクロビルダー」（マクロアクション）、もう1つはコードで書く「コードビルダー」（VBA）です。ここでは初めての人でも迷いにくいように、まず考え方をそろえます。

• マクロビルダー：対話的にアクションを積み上げる方式。記述なしで素早く作れる。配布もしやすい。
• コードビルダー（VBA）：細かい条件分岐やループ処理、API 連携など柔軟。学習は必要だが拡張性が高い。

用途ごとの早見表を置きます。最初はマクロで作り、限界に来たらVBAへ移す、という順序がおすすめです。

よくある質問（まずはどちらを選べばよい？）

「短い操作で形にしたい」「クリックで開く・閉じる程度」はマクロが向きます。「条件が多い」「処理の流れが長い」「再利用したい」はVBAの検討を始めます。

マクロビルダーで設定する定番パターン

ここではクリック時イベントを例に、よく使うマクロの作り方をまとめます。画面のどこで操作するか、最小限の手順、つまずきやすい点をセットで確認します。

［エラー時］アクションでマクロのエラーを出さずに次に進ませる

目的：一時的なエラーで処理を止めないようにする。

ポイント：マクロの先頭に［エラー時］を置き、引数で「次へ」を選ぶと、そのアクションでエラーが起きても処理を継続できます。ログを残したい場合は、エラー番号と説明をメッセージやテーブルに記録するアクションを続けて置きます。

つまずき：エラーを無視し続けると原因が見えなくなります。テスト中は「停止」設定にし、公開時だけ「次へ」に切り替える運用が安全です。

独立マクロを作成してフォームを開くボタンを設置

目的：複数の場所から同じ「フォームを開く」処理を共有したい。

手順の流れ：

• マクロとして「新規作成」→ アクションに「フォームを開く」を追加し、対象フォームやデータモードを指定。
• マクロに名前を付けて保存（例：mcrOpenCustomer）。
• フォームのボタン（コマンドボタン）に「マクロの実行」を割り当て、作った独立マクロ名を指定。

利点：同じ動作を複数フォームから呼び出せます。変更はマクロ側1箇所で完結します。

独立マクロと埋め込みマクロの違いを知って使い分け

• 独立マクロ：オブジェクトとして独立して保存。再利用に強い。命名・管理がカギ。
• 埋め込みマクロ：特定のフォームやレポートのイベント内に保存。対象と一緒に移動するため配布が簡単。

判断基準：同じ動きを複数で使うなら独立、1箇所だけなら埋め込み。テストや差し替えが多い期間は独立にしておくと安全です。

コマンドボタンウィザードを使用したボタンの作成

ウィザードは、よくある操作（開く・印刷・移動など）を対話式で設定します。フォームのデザインビューでボタンを配置し、ウィザードをオンにすると、目的を選ぶだけで埋め込みマクロが自動で作られます。作成後にプロパティシートで細かな挙動を調整します。

よくある質問（マクロはどこまででVBAへ切り替える？）

繰り返し・複雑な条件・外部データ連携・細かなエラーログが必要になったら、同じ目的の処理をVBAに置き換える検討を始めます。

データマクロでテーブルの自動処理を行う

データマクロは、テーブルのイベント（レコードの追加・更新・削除など）に反応して実行される自動処理です。フォームの有無に関わらず動くため、記録や整合性チェックに向いています。

削除後のレコードを自動で指定テーブルへ保存するデータマクロ

目的：削除履歴を残し、後から確認できるようにする。

考え方：テーブルの「削除後」イベントで、削除対象のフィールド値を履歴テーブルへ追加します。誰がいつ削除したかを含めると追跡に役立ちます。

注意：履歴テーブルが肥大化しやすいので、定期的なアーカイブや圧縮の手順を合わせて用意します。

更新日時を指定テーブルやフィールドへ自動で保存するデータマクロ

目的：更新者・更新日時を自動で記録し、変更の追跡を容易にする。

考え方：テーブルの「更新後」イベントで、該当レコードに日時とユーザー情報を保存します。フォーム側での更新漏れを防げます。

よくある質問（フォームのマクロとデータマクロの使い分けは？）

画面操作に伴う見た目や遷移はフォームのマクロ、データの記録や一貫性はデータマクロ、と役割を分けると混乱しにくくなります。

レポートの見た目を自動で整える

レポートは読みやすさが最優先です。手作業で線や色を足すのではなく、規則で整えると保守が楽になります。

レポートの詳細セクションに直線を引いて数行おきに罫線を設定する

目的：行の区切りを視覚的に分かりやすくする。

考え方：詳細セクションの印刷イベントなどで、行番号や奇数偶数に応じて線の表示/非表示を切り替えます。セクションの高さを固定にすると見出しやフッターとのズレが減ります。

レポートを数行おきに色が異なる縞模様（背景色）にするには

目的：視線の迷子を防ぎ、数字の読み違いを避ける。

考え方：条件付き書式や印刷時のイベントで、行の偶奇に応じて背景色を切り替えます。薄いグレーや淡色を選び、印刷でも視認できる濃度にします。

よくある質問（縞模様が崩れるのはなぜ？）

高さが可変のコントロールがある、グループ化や並び順が途中で変わる、改ページ条件と干渉する、などが代表例です。順に無効化して原因を切り分けます。

コードビルダー（VBA）でイベントプロシージャを作る

VBAは、より柔軟な制御や再利用性を求めるときに力を発揮します。クリック時イベントであれば、フォームのプロパティで［イベントプロシージャ］を選ぶと、該当の手続きがフォームモジュールに作られます。

基本の流れ：

• ボタンのプロパティで「クリック時」→「イベントプロシージャ」を選択。
• ビルドボタンからVBAエディタを開くと、空のプロシージャが用意されます。
• 中に処理を書き、保存して動作確認します。

テストの心得：

• まずは小さく動かし、例外処理で予期しない状態をログ化します。
• 共通処理は標準モジュールへ切り出し、複数のフォームから呼び出せる形にします。

よくある質問（VBAへ切り替える決め手は？）

「条件が多段」「同じ処理を複数の画面で使い回す」「ログと通知を細かく制御したい」なら、VBAへの移行を前向きに検討します。

オブジェクト/コントロール名を変えたときの影響

名前変更は動作に直結します。マクロはプロパティ名で参照していることが多く、VBAはコード内の識別子で参照します。どちらも参照切れが起こり得ますが、検出の仕方が異なります。

• マクロ：実行時に対象が見つからず、アクションでエラーになる。
• VBA：コンパイルで未定義エラーが出ることが多く、場所を特定しやすい。

変更前にバックアップを取り、名称を一括で見直す場合は、依存箇所の確認手順をリスト化しておくと安心です。

マクロアクションで設定しているのにエラーが出る場合

原因の例：

• 参照しているコントロール名やフォーム名が変更された。
• クエリのフィールド名が変わり、条件式が一致しなくなった。
• 実行順が前提と合わず、必要な値がまだ用意されていない。

対処：

• 名前の整合性を確認（プロパティシートやナビゲーションウィンドウで確認）。
• 条件式のテストをフォームから切り離して単体で検証。
• 実行順を明示（必要なら独立マクロ化して順序を固定）。

よくある質問（名前変更の安全な手順は？）

影響範囲をメモし、コピーで試す→参照切れを修正→元のオブジェクトへ反映、の順で進めると事故が減ります。

マクロアクションでエラーが出るときのチェックリスト

代表的な症状ごとに確認を進めると、原因へ早くたどり着けます。

• 意図しない「パラメーターの入力」ウィンドウが表示される
  • フィールド名のタイプミス、クエリの列名変更、別オブジェクトの同名フィールド参照が原因のことが多い。
  • 対処：クエリを開き、列見出しと式を確認。フォーム側のコントロールソースも照合。
• オブジェクト名の変更後に動かない
  • 対処：参照先を一覧し、命名規則を決める（接頭辞など）。
• 条件分岐が期待通りに動かない
  • 対処：分岐条件を単体で試す小さなテストマクロを作り、真偽を確認する。

開くときに意図しないパラメーターの入力ウィンドウが表示される

フォームやレポートのデータ元に、存在しないフィールド名や式が残っている可能性があります。元のクエリを直接開いて列を確認し、フォーム側の参照名と一致させます。複数のクエリをまたぐ場合は、同名の列が混在していないかも確認します。

よくある質問（チェックの順番は？）

「データソース→式→名前→実行順」の順に見直すと、無駄が少なくなります。

イベントプロシージャ/フォームモジュールを削除するとき

不要になったイベントやモジュールは、影響を確認しながら削除します。削除後にエラーが出た場合に戻せるよう、事前にコピーを残しておきます。

手順の考え方：

• フォームやレポートのイベントプロパティを空欄に戻す（［イベントプロシージャ］や［マクロ名］を外す）。
• 埋め込みマクロなら、その場で削除。独立マクロならナビゲーションから削除。
• VBA の場合は、対象のプロシージャをコメントアウト→動作確認→問題なければ削除、の順に進めます。

フォームモジュールの削除

フォームモジュール全体を削除する前に、共通処理が他から参照されていないかを確認します。該当フォームのモジュールを開き、不要な宣言やプロシージャを順に落としていくと安全です。

よくある質問（削除後に元へ戻せる？）

直前のバックアップに戻すのが確実です。小さな変更でも、節目ごとにコピーを残す運用が失敗を減らします。

どっちを選ぶ？現場で迷わない判断基準まとめ

最後に、選び方のチェックリストを置きます。上から順に当てはまるものを数えていくと、方針が決めやすくなります。

• まずは速く形にしたい → マクロ
• 1箇所だけで使う → 埋め込みマクロ
• 複数箇所で同じ処理を使う → 独立マクロ or 共通VBA
• 条件が多い/再利用したい/ログを出したい → VBA
• 名前変更や拡張が頻繁にある → VBAで関数化して管理
• 配布先の信頼設定が厳しい → マクロ中心で設計

迷ったら、最初はマクロで小さく作り、要件が増えたらVBAへ移す、の順路を基本にします。

よくある質問（最初からVBAにすべき場面は？）

外部との連携、複雑な検証、長い処理フロー、細かなログや通知が最初から必要なときは、VBAで骨格を作っておくと後戻りが減ります。

参考：用語ミニ辞典

マクロビルダー：画面操作でアクションを組み合わせて処理を作る機能。

コードビルダー（VBA）：プログラミング言語で処理を書く機能。

埋め込みマクロ：フォームやレポートのイベント内に保存されるマクロ。

独立マクロ：オブジェクトとして単体で保存されるマクロ。再利用向き。

データマクロ：テーブルのイベントに応じて実行されるマクロ。

イベントプロシージャ：イベント発生時に動くVBAの手続き。