コマンドボタンをウィザードで作った後の［埋め込みマクロ］—使い方と注意点をやさしく解説

ウィザードで作ったボタンの「埋め込みマクロ」を徹底理解

Accessでは、フォームに配置するコマンドボタンをウィザードで手早く作成できます。ただ、作成して終わりにせず、ボタンの動作を担う「埋め込みマクロ」の中身を確認・整えることで、保守性と信頼性が大きく向上します。ここでは、作成直後の点検ポイントから、名前変更に強い設定、応用的な書き換え方法まで、実務で役立つ視点で掘り下げます。

accdb 形式で自動生成される「埋め込みマクロ」の仕組み

新形式（.accdb）でウィザードからコマンドボタンを作成すると、［プロパティ シート］>［イベント］>［クリック時］に「埋め込みマクロ」が割り当てられます。右側の［…］を押してマクロ ビルダーを開くと、たとえば「フォームを開く」「レポートを印刷する」などのアクションが並び、引数（開く対象、Where条件、データモードなど）が自動入力されています。

• 代表的なアクション例：
  OpenForm / OpenReport / CloseWindow / GoToRecord / RunMenuCommand / Requery / MessageBox
• 自動で入る引数例：
  オブジェクトの種類、オブジェクト名、ビュー、WhereCondition、WindowMode など

ウィザード直後は一見問題なさそうでも、フィールド名やオブジェクト名の変更に弱い指定になっている場合があります。次章の点検を必ず行いましょう。

まずは点検：対象オブジェクトの指定を「読める名前」に直す

マクロ ビルダーの引数欄（たとえば［フォーム名］）に、記号列のような内部参照が入っていることがあります。可読性が低く、後から見返したときに対象が判別しにくいため、手動でオブジェクト名に置き換えるのが安全です。

• 該当欄を一度空にするとプルダウン（候補リスト）が出ます。
• 実際に開きたいフォーム／レポート名を選び直して保存します。
• 動作は変わらず、読みやすさとメンテナンス性が向上します。

名前変更に強くする：自動修正と明示指定のベストプラクティス

オブジェクト名を後で変更する可能性があるなら、マクロの引数は必ずプルダウンから「実名で」指定しておきます。さらに、［Access のオプション］で「名前の自動修正」が有効なら、リネーム時の追従性が高まります（既定でオン）。

• 明示指定の効果：参照切れ（対象が見つからないエラー）を未然に防止。
• 自動修正の限界：複雑な条件式やテキストで組み立てた式までは追従しないことがあるため、式内のオブジェクト名は定期的に目視点検を。

ウィザード既定の動作を業務向けにチューニング

ウィザード生成のままでは「とりあえず動く」設定です。運用を意識して次の調整を加えると実用度が上がります。

• WhereConditionでレコードを絞る：「OpenForm」に Where 条件（例：顧客ID=[Forms]![F_検索]![txt顧客ID]）を追加し、対象だけを開く。
• WindowMode の使い分け：ダイアログで開きたい場合は「ダイアログ」、編集させたくない場合はデータモードを「読み取り専用」に設定。
• 確認ダイアログの追加：CloseWindow の前に MessageBox を挟み、［はい］のときだけ実行する分岐を入れる。
• 描画負荷の軽減：RunMenuCommand 等の前に一時的に Echo をオフ、処理後にオンに戻す（重い処理で体感が改善）。
• TempVar の活用：SetTempVar で値を保持し、OpenForm の Where に流用。フォーム間受け渡しが安定。

「閉じる」ボタンの作法：対象の明示と誤操作対策

ウィザードの「フォームを閉じる」は、多くの場合「アクティブウィンドウを閉じる」設定です。意図しない画面を閉じないよう、次の工夫を推奨します。

• CloseWindow の「オブジェクトの種類」「オブジェクト名」を明示指定する。
• MessageBox で保存確認（「保存して閉じる／保存せず閉じる／キャンセル」）などの分岐を追加する。
• 未保存レコードがあるときだけ確認を出す（条件列に Not IsNull(Screen.ActiveForm.Dirty) 等の条件式）。

mdb 形式（旧形式）での違い：VBAイベントになるケース

旧形式（.mdb）では、同じウィザード操作でも［クリック時］が「イベントプロシージャ」（VBA）として生成されます。コードはVBEで確認・編集可能です。レガシー資産を引き継ぐ場合は、次の点に注意します。

• VBA とマクロの混在方針を決める（保守窓口・スキルに合わせる）。
• セキュリティセンター／信頼済みの場所を設定し、起動時の警告を抑止。
• 必要に応じて「マクロをVisual Basicに変換」（フォーム／レポートのマクロ変換）を検討し、ロジックを一元化。

埋め込みマクロの保守テクニック

• 命名規則：ボタン名は目的が伝わるように（例：cmdOpen顧客台帳、cmdPrint請求書）。
• コメント活用：マクロ ビルダーの［説明］に意図・更新履歴を記録。将来の自分を助けます。
• 共通化：複数フォームで同じ処理を使うなら、独立マクロに切り出して呼び出しに変更。
• エラー分岐：「OnError」アクションでエラーハンドル先を用意し、MessageBoxやログ書き出しを実装。
• パフォーマンス：OpenForm 直後に Requery を多用しない／無駄な再描画を避ける／大量印刷はキュー制御。

運用上のトラブルと対処のヒント

• 対象が開かれない：Where 条件のフィールド名・データ型の不一致を確認。文字列は引用符、数値はそのまま。
• 別の画面が閉じられる：CloseWindow のオブジェクト名が未指定。必ず明示する。
• 名前変更でリンク切れ：オブジェクト名を実名に直す／依存関係ウィンドウで影響調査／検索で当該名を網羅的に置換。
• セキュリティ警告：ファイルの配置先を「信頼済みの場所」に設定。ネットワーク共有の場合はパス単位で登録。

チームで育てる埋め込みマクロ：運用ルール例

• 新規ボタンは作成直後に「対象オブジェクトを実名で指定」「必要に応じてWhere条件追加」「メッセージボックス要否を判断」。
• 変更は担当者・日付・要旨を説明欄へ追記。最低限のレビュー（ダブルチェック）を実施。
• 月次で「依存関係」「参照切れ」チェックを行い、不要ボタン／未使用マクロを整理。

まとめ：ウィザード任せにしない一手間が、長期運用の強さになる

ウィザードは素早く正確にボタンを作ってくれますが、業務システムとして長く使うには「埋め込みマクロの中身を読める形に整える」「対象を明示する」「運用上の分岐や確認を足す」というひと工夫が欠かせません。オブジェクト名の明示、Where 条件の活用、エラーハンドリングの追加——これらを押さえるだけで、改修や人員交代に強いフォームに育ちます。今日作ったボタンの［クリック時］、まずは一度開いて“読める”状態に整えてみてください。