【入門編】Application.GetOptionとSetOptionによるAccess環境設定の動的変更と復元 – Access VBA解析バイブル

Access VBA

2026.08.24

こんにちは！ Access VBAの海原へようこそ。
日々、クエリやフォーム、そして膨大なデータの処理に立ち向かっていることと思います。

「AccessのマクロやVBAを実行したとき、突然『～を変更しますか？』なんてダイアログが出てきて処理が止まってしまった…」
「『名前の自動修正』のせいで、意図しないところでオブジェクトが書き換わって冷や汗をかいた…」

そんな経験はありませんか？
Accessには、開発や運用を助けるための便利機能がたくさん備わっていますが、プログラムを自動実行させたい時には、かえって邪魔になることがあります。

今回は、処理の実行中だけAccess全体の環境設定（オプション）をスマートに切り替え、終わったら何食わぬ顔で元の状態に復元する「プロの技」を伝授しましょう。ここをクリアすれば、あなたの書くプログラムは一段とプロフェッショナルなものになりますよ。

—

なぜ環境設定を「動的」にいじる必要があるのか？

Accessのオプション画面（[ファイル]タブ＞ [オプション]）を開くと、たくさんのチェックボックスや設定項目がありますよね。
例えば、次のような設定です。

「アクションクエリを実行しますか？」などの確認メッセージ（警告）
「名前の自動修正」に関連する各種チェックボックス

これらを毎回手動でカチカチと切り替えるのは、現実的ではありません。忘れたままにしておくと、他の処理に悪影響が出たり、思わぬバグを生む原因になります。

そこで登場するのが、VBAから直接Accessの設定を読み書きする `Application.GetOption` と `SetOption` という強力なメソッドコンビです。

2つのメソッドの役割

`Application.GetOption(“設定項目名”)`

現在の設定値が「どうなっているか」を取得します（およそ数値で返ってきます）。

`Application.SetOption “設定項目名”, 値`

設定値を強制的に書き換えます。

これを使って、「①現在の設定を退避 ➔ ②邪魔な機能をオフにして処理を実行 ➔ ③絶対に元の設定に戻す」というライフサイクルを構築するのが今回のテーマです。

—

陥りがちな罠：設定を戻し忘れる恐怖

ここで少し、ベテランエンジニアとしての警告をさせてください。
初学者がやりがちな最大のミスがこれです。

‘ 【やってはいけないアンチパターン】
Application.SetOption “Confirm Action Queries”, False ‘ 警告を消す
‘ ─── ここで何らかの処理 ───
‘ エラーが発生してプログラムが中断！
‘ 結果、警告が出ない危険な状態のままAccessが放置される……！

途中でエラーが発生したり、予期せぬブレークポイントに引っかかったりすると、「元に戻すコード（`SetOption`）」に到達せず、Accessの設定が改変されたままになってしまいます。これは実務では致命的なトラブルの元です。

だからこそ、「エラーが起きようとも、確実に元に戻す（クリーンアップする）」という安全な実装パターンが必要なのです。

—

実践！安全確実な環境設定の切り替えパターン

それでは、実際のコードを見てみましょう。
今回は、大量のデータ削除や更新を行う前に「確認メッセージ」と「名前の自動修正」を一時的に無効化し、処理が終わったら（あるいはエラーになっても）必ず元に戻すプロシージャを作成します。

開発環境の標準モジュールなどに、そのままコピペして使っていただけます。

Option Compare Database
Option Explicit

‘ メインの実行プロシージャ
Public Sub ExecuteBatchProcessSafe()

‘ 1. 現在の設定値を退避するための変数
Dim orgConfirmAction As Long
Dim orgNameAutocorrect As Long

‘ エラーハンドラの設定（万が一の備え）
On Error GoTo ErrorHandler

‘ —————————————————-
‘ 2. 現在の設定を「GET」して変数に記憶する
‘ —————————————————-
‘ ※「アクションクエリの確認」の内部名
orgConfirmAction = Application.GetOption(“Confirm Action Queries”)

‘ ※「名前の自動修正: データベースの変更を名前の自動修正ログに記録する」の内部名
orgNameAutocorrect = Application.GetOption(“Name AutoCorrect Log Changes”)

‘ —————————————————-
‘ 3. 処理のために設定を一時変更（SET）する
‘ —————————————————-
‘ 警告を出さない (False = 0)
Application.SetOption “Confirm Action Queries”, 0

‘ 自動修正機能をオフにする (False = 0)
Application.SetOption “Name AutoCorrect Log Changes”, 0

Debug.Print “【システム】環境設定を一時的に変更しました。”

‘ —————————————————-
‘ 4. 本丸の処理を実行（今回はシミュレーション）
‘ —————————————————-
‘ ここで普段の重い処理や、確認を出したくないクエリ実行を行います
‘ DoCmd.OpenQuery “qryDeleteOldData”

‘ あえてエラーを発生させるテストをする場合は、下のコメントアウトを外してください
‘ Err.Raise 9999, , “テスト用の意図的なエラー”

MsgBox “バッチ処理が正常に完了しました！”, vbInformation, “完了”

CleanUp:
‘ —————————————————-
‘ 5. 【最重要】何があっても必ず元の設定に復元する
‘ —————————————————-
Application.SetOption “Confirm Action Queries”, orgConfirmAction
Application.SetOption “Name AutoCorrect Log Changes”, orgNameAutocorrect

Debug.Print “【システム】環境設定を元の状態に復元しました。”
Exit Sub

ErrorHandler:
‘ エラーが発生した場合はここに飛びますが、
‘ そのまま CleanUp ラベルへ流し込むことで「復元処理」を確実に実行させます
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical, “エラー”
Resume CleanUp

End Sub

コードのここがポイント！

1. `On Error GoTo ErrorHandler` と `CleanUp` ラベルの組み合わせ
VBAには、JavaやC#にあるような `try-finally` 構文がありません。そのため、Access VBAで確実な後始末（クリーンアップ）を行うには、「エラーが起きても `CleanUp` ラベルを通るように誘導する」というイディオム（定石）を使います。これができるだけで、コードの信頼性が一気に跳ね上がります。
2. 設定項目の英語名に注意
`GetOption` や `SetOption` の引数に指定する文字列は、Accessの英語環境におけるオプション名である必要があります。日本語版Accessであっても、内部名（例: `”Confirm Action Queries”` など）を指定する必要がある点に注意してください。

—

押さえておきたい主要なオプション項目名リスト

実務でよく利用するオプション名の一覧を共有しておきます。必要に応じてコード内の文字列を書き換えて活用してください。

※設定値の `True` は Access VBA の内部では `-1` として扱われます。安全のために `0`（False）または `-1`（True）を直接指定するのが確実です。

—

まとめ

今回は、`Application.GetOption` と `SetOption` を用いた環境設定の動的変更と、エラー発生時をも考慮した「確実な復元パターン」について解説しました。

環境設定をいじる時は必ず「取得(Get) ➔ 変更(Set) ➔ 復元」のセットで行う。
エラーで中断しても復元処理が必ず通るように、`CleanUp` ラベルやエラーハンドラを設計する。

ここをクリアすれば、あなたはもう「マクロの記録や見よう見まねのコード」から完全に脱却し、システム全体の挙動をコントロールできる「真のAccess開発者」の仲間入りです。

現場のアプリの品質を高めるために、ぜひこの実装パターンをあなたの引き出しに加えてみてくださいね。それでは、次回の極限の知見でお会いしましょう！