AccessのAutoExecで起動時にマクロを自動実行する方法と安全な設計

2026.10.18

概要
この記事でわかること
この記事の主な内容
起動時に行う処理とAutoExecの役割を決める
AutoExecでメニューフォームを開く
VBAのFunctionを起動処理から呼び出す
実行されない原因を順番に調べる
失敗と二重実行に備えた起動処理を設計する
配布と保守のためにテストと復旧手順を残す
まとめ
よくある質問
関連記事
参考情報

概要

この記事の結論
Accessでデータベースを開いたときに処理を実行するには、独立したマクロを作り、名前をAutoExecとして保存します。最初はメニューフォームを開く処理だけで動作を確認しましょう。VBAを呼ぶ場合、RunCodeからは標準モジュールのPublic Functionを指定します。信頼設定、失敗時の停止、再起動で同じ処理が重複しない設計まで確認すると、業務で扱いやすくなります。
AutoExecとは、Accessデータベースを開いた際に自動実行される、特定の名前を持つマクロです。

この記事でわかること

AutoExecでメニューフォームを開く
VBAのFunctionを起動処理から呼び出す
実行されない原因を順番に調べる
失敗と二重実行に備えた起動処理を設計する

この記事の主な内容

起動時に行う処理とAutoExecの役割を決める
AutoExecでメニューフォームを開く
VBAのFunctionを起動処理から呼び出す
実行されない原因を順番に調べる
失敗と二重実行に備えた起動処理を設計する
配布と保守のためにテストと復旧手順を残す
よくある質問

想定読了時間：約15分～20分

起動時に行う処理とAutoExecの役割を決める

AutoExecは、Accessデータベースを開いた際の入口になるマクロです。「Accessというアプリを起動したら全ファイル共通で動く」という仕組みではありません。設定したデータベースを開いたときに実行されます。

フォーム表示だけなら起動フォーム設定も使える

毎回メニューを1画面開くだけなら、［ファイル］→［オプション］→［現在のデータベース］の［フォームの表示］を利用する方法があります。初期設定の読込や分岐など、複数の処理を行ってから画面を開くならAutoExecが候補になります。

目的	選ぶ方法	設計上の注意
メニューフォームを表示	フォームの表示設定	保存後にDBを開き直して確認
複数の起動処理を実行	AutoExec	処理順と失敗時の動きを決める
あるフォームを開くたびに処理	フォームのイベント	DB起動とフォーム起動を区別
夜間に定時処理を実行	別途スケジュール設計	AutoExec単独には時刻予約機能がない

同じ初期化をAutoExecとフォームの読込時イベントの両方へ書くと、重複して実行される原因になります。起動処理の責任を1か所にまとめ、フォーム側にはその画面に必要な処理を残すと、引継ぎ時にも追いやすくなります。

起動時に重い業務処理を入れすぎない

利用者が画面を開くたびに全件集計やCSV取込を実行すると、起動待ちや重複更新が発生しやすくなります。まずは設定読込、接続の確認、メニュー表示などに範囲を絞ります。定期処理が必要なら、誰がいつ実行するかを起動操作から分けて検討してください。

AutoExecでメニューフォームを開く

最初は「フォームを開く」だけの短いマクロで確認します。業務データの追加・削除を含めずに起動の仕組みを確かめておけば、問題が起きても原因を絞れます。作業前には変更前のファイルと既存の起動設定を保存します。

作成手順

1. 検証用データベースに、単独で開けるF_メニューを用意します。

2. ［作成］タブから［マクロ］を選び、独立したマクロを作ります。

3. ［フォームを開く］アクションを追加します。

4. フォーム名にF_メニュー、ビューにフォームを指定します。

5. マクロ名をAutoExecとして保存します。

6. データベースを閉じて開き直し、メニューが開くか確認します。

AutoExecは、フォームのボタンに埋め込むマクロ名ではなく、ナビゲーションウィンドウで確認できる独立したマクロとして用意します。名前に余分な空白を付けたり、モジュールをAutoExecと名付けたりしても同じ動きにはなりません。

既存のAutoExecがある場合

既存マクロを上書きする前に、アクションと順番を確認します。起動時に接続先を切り替える、利用者を確認するなどの処理が含まれていることがあります。コピーを保管し、まず必要な処理を一覧化してから変更します。メニュー表示だけに置き換えて起動できても、業務の前提を壊す可能性があります。

起動フォームとの重複を確認する

［フォームの表示］にも同じメニューが指定されている場合は、起動の入口を整理します。AutoExecは他のマクロやVBAに先立って動くため、その後のフォームイベントも含めて順序を考えます。起動処理がフォームを開けば、そのフォームのイベントも発生します。

VBAのFunctionを起動処理から呼び出す

マクロのRunCode、表示名では［プロシージャの実行］などから呼べるのは、VBAのFunctionプロシージャです。Subを直接指定する例をそのまま使わないでください。標準モジュールにPublic Functionを置き、必要ならその内部から既存のSubを呼びます。

標準モジュールへ入口を作る

［作成］→［モジュール］で標準モジュールを作り、名前をmodStartupとします。次の例では、F_メニューを開く処理だけを行います。関数とモジュールに同じ名前を付けず、VBEの［デバッグ］でコンパイルを確認してください。

Option Compare Database
Option Explicit

Public Function AppStartup() As Boolean
On Error GoTo ErrHandler

‘必要な初期化は、メニュー表示より前に追加する
DoCmd.OpenForm “F_メニュー”, acNormal
AppStartup = True
Exit Function

ErrHandler:
MsgBox “起動処理を完了できません。” & vbCrLf & _
Err.Number & “：” & Err.Description, vbExclamation
AppStartup = False
End Function

これは入口の最小例であり、接続確認や排他制御を実装した完成品ではありません。通常処理を実行する権限の判断やログ出力が必要な場合は、その要件を追加します。コードはAccess実機では未実行のため、導入先のコピーでコンパイルと起動を確認してください。

AutoExec側の指定

AutoExecのアクションを［プロシージャの実行］にし、関数名をAppStartup()とします。引数がない場合も括弧を付け、先頭に等号は付けません。RunCodeは関数の戻り値を無視するため、Falseを返しただけで後続アクションが自動停止するわけではありません。

項目	正しい例	避ける例
標準モジュール名	modStartup	関数と同じAppStartup
入口の宣言	Public Function AppStartup() As Boolean	Public Sub AppStartup()
RunCodeの関数名	AppStartup()	=AppStartup()／AppStartup
AutoExecの後続処理	この例では置かない	失敗してもメニューを開く処理を続ける

この例では、AutoExecをRunCodeの1アクションにし、メニュー表示も関数内に集めます。初期化でエラーが発生すればメニュー表示の前でエラー処理へ移るようにします。失敗後にも別の起動フォーム設定から業務画面が開かないか、併せて確認します。

実行されない原因を順番に調べる

動かないときは「マクロが起動していない」のか「起動したが途中で失敗した」のかを分けます。いきなりすべてのマクロを有効にする設定へ変えるのではなく、ファイルの入手元と管理状態を確かめ、組織の信頼設定に従って対応します。

症状	確認する対象	対応
まったく動かない	独立マクロ名・開いたファイル	AutoExecの存在とパスを確認
警告で無効化される	信頼設定・配布元・組織ポリシー	信頼できるファイルか確認して管理者と調整
関数が見つからない	Function宣言・標準モジュール・括弧	呼出名とコードの配置を修正
VBAで止まる	コンパイル・参照設定・対象名	最初のエラーを解決
自分のPCだけ動く	接続先・権限・外部部品・パス	配布先の環境を比較
画面が重複して動く	起動フォーム・読込時イベント	同じ初期化を重ねない

Shift起動を保守手順に使う場合

通常はShiftキーを押したままデータベースを開くことで、AutoExecなどの起動オプションを回避できます。ただしAllowBypassKeyがFalseに設定されている場合など、利用できない条件があります。すべての環境で必ず停止できる救済策として扱わないでください。

業務用に配布する前に、管理者が復旧できる原本、バックアップ、起動処理を一時的に無効にする手順を確保します。利用者向けの画面制限と、保守担当者が安全に調査できる経路を両立させることが重要です。

失敗と二重実行に備えた起動処理を設計する

起動処理は、再起動されても不整合にならないことが必要です。利用者は反応が遅いと、もう一度ファイルを開くことがあります。複数人利用では、別のPCからほぼ同時に起動することも想定します。

失敗を成功として扱わない

接続確認に失敗したのに通常メニューを開くと、後続操作で別のエラーが出て原因が分かりにくくなります。失敗した段階とエラー内容を通知し、正常な処理を続けない設計にします。ただし、MsgBoxを出すだけでデータベース全体の利用が禁止されるわけではありません。アクセス権の制御とは分けて考えます。

毎日の更新処理を入れる場合の考え方

「最終実行日が今日でなければ実行する」という確認だけでは、2台が同時に未実行と判定して処理を始める可能性があります。必要なら処理キーの一意制約、実行権の取得、トランザクションなどで、同時実行の競合を防ぐ設計を追加します。

管理項目	例	目的
処理キー	日付＋処理名	同じ仕事を識別する
開始日時と終了日時	実際の実行時刻	途中停止と完了を区別する
実行者・端末	利用者ID・端末名	問い合わせ時の追跡に使う
結果	実行中・成功・失敗	未完了を成功扱いしない
処理件数・エラー内容	取込件数・失敗理由	再実行の判断材料にする

「何度実行しても結果が重複しない性質」を冪等性と呼びます。難しい用語ですが、要点は再起動で同じ売上や同じ取込データを増やさないことです。既存のキーで重複を防ぐなど、データ側の設計と一緒に考えます。

Accessの設定や運用で解決が難しい場合は

設定変更だけで改善しない場合や、複数人での利用・外部DB・既存のVBAが関わる場合は、原因と影響範囲を整理してから改修を進めましょう。Accessの教科書では、既存Accessの修正や運用の見直しについて相談できます。対象画面、症状、再現手順をまとめると、調査の相談がしやすくなります。

Accessの教科書に起動処理の見直しを相談する

配布と保守のためにテストと復旧手順を残す

自分のPCで起動しただけでは配布確認は終わりません。ネットワーク切断、権限不足、対象フォームの名前変更など、失敗する条件でも確認します。業務更新を含む場合は、テスト用データと本番の接続を必ず区別します。

テスト条件	期待する挙動
通常起動	必要な初期化後にメニューが開く
連続で開き直す	業務データが重複しない
2台から同時起動	競合の扱いが定義されている
接続先へ到達できない	失敗を通知し通常処理へ進まない
別PC・Runtime	必要な部品と操作導線で利用できる
管理者による保守起動	定めた復旧手順が使える

ログにパスワードや接続文字列をそのまま記録しないでください。調査に必要なのは、発生時刻、処理名、対象環境、エラー番号などです。記録先が使えない場合にも何も表示されず停止しないよう、通知方法を決めておきます。

まとめ

AutoExecは、名前を決めて保存するだけで起動処理の入口を作れます。ただし、業務で重要なのは処理内容と順序です。RunCodeからはFunctionを呼び、失敗時の停止、再実行と同時起動、配布先の信頼設定まで確認しましょう。画面表示だけなら、起動フォーム設定で十分な場合もあります。

よくある質問

直接呼ぶ対象はFunctionです。標準モジュールにPublic Functionを用意し、AutoExecのRunCodeで関数名と括弧を指定します。既存のSubを利用したい場合は、Functionの中からそのSubを呼ぶ構成にします。関数名の先頭には等号を付けず、モジュール名と関数名も分けてください。また、RunCodeは戻り値を無視するため、Falseを返すだけでは後続アクションを止められません。失敗時に次へ進まない流れを別途設計します。

まず独立したマクロとしてAutoExecが存在するか、開いているファイルが正しいかを確認します。次に信頼設定の警告、組織のポリシー、Shift起動の有無を調べます。VBAを呼ぶ構成なら、標準モジュールのPublic Function、括弧、関数名、コンパイルエラーを確認してください。別PCだけ動かない場合は接続先や権限の差も候補です。安全性を確認せずマクロを全面的に有効化するのではなく、失敗している段階を分けて対処します。

必ずではありません。通常はShiftキーを押しながらデータベースを開くことで起動オプションを回避できますが、AllowBypassKeyがFalseになっている場合などは使えません。保守手順として採用するなら、対象ファイルの設定と実際の操作を管理者が確認してください。起動処理に不具合があるときのために、変更前の原本やバックアップも残します。Shiftだけを唯一の復旧策にせず、保守担当者が調査できる経路を配布前に準備することが大切です。

実装はできますが、利用者の再起動や複数PCの同時起動で同じデータを取り込まない設計が必要です。最終実行日を調べるだけでは、2台が同時に未実行と判断する可能性があります。処理キーの一意制約、排他制御、実行結果の記録、失敗後の再実行方法を考えてください。待ち時間が長い取込は通常の起動処理から分離した方が扱いやすい場合もあります。AutoExec自体には毎日特定時刻に動かす予約機能はない点も区別しましょう。

正常な初期化が終わった場合だけ業務メニューを開き、失敗時は発生した段階とエラー内容を通知します。後続のマクロに無条件でメニュー表示を置くと、初期化が失敗しても先へ進むため注意してください。ログには時刻、処理名、エラー番号などを記録し、パスワードなどは含めません。通知するだけではDB全体の利用制限にはならないので、権限管理とは分けて考えます。ネットワーク切断や権限不足を再現し、想定どおり止まるか確認してください。

AutoExecを保存したデータベースを開いたときに動きます。Access本体を起動しただけで、すべてのファイルに共通するAutoExecが実行されるわけではありません。また、信頼設定などで処理が無効化されている場合や、Shift起動で回避した場合は通常どおりに動かないことがあります。確認するときは、どのフォルダーのどのデータベースを開いたかを記録してください。同じ名前の旧版や検証用コピーを開いていると、設定変更を確認できません。

必須ではありません。メニューなど1つのフォームを表示するだけなら、Accessのオプションにある［現在のデータベース］の［フォームの表示］で指定する方法があります。初期設定の読込や分岐など、複数の操作を行ってから画面を開きたい場合にAutoExecを検討します。両方へ同じ処理を設定すると、どこで実行されたか追いにくくなります。起動の入口を整理し、フォームの読込時イベントにある処理も含めて重複がないか確認してください