【Access VBA】暗黙の罠を断つ！`GetOption` / `SetOption` による環境設定の動的制御と完全復元パターン
開発現場でこんな恐怖を味わったことはないか？
「バッチ処理を走らせたら、確認ダイアログが大量に出て処理が止まった」
「Accessが勝手にオブジェクト名を書き換えて、リレーションが崩壊した」
「エラーハンドリングの途中でマクロや警告の抑止が解除され、ユーザーの画面がカオスになった」
Access VBAにおける最大の悪夢、それは「開発者の意図しないグローバル環境の汚染」だ。
Accessのオプション設定（「名前の自動修正」や「アクションクエリの確認メッセージ」など）は、アプリケーション全体に影響を与える。コード内でこれらを変更したはいいが、エラー落ちや予期せぬ中断によって「元の状態に戻らない」という事態が発生すると、デバッグは困難を極め、最悪の場合はデータベースの破損を招く。
今回は、プロのアーキテクトが現場で必ず実装している、`Application.GetOption` と `Application.SetOption` を使った「環境設定の安全な動的変更と確実な復元（トランザクション的アプローチ）」の極意を伝授する。
—
なぜ「そのまま書く」コードは地雷なのか？
多くの初級～中級プログラマがやりがちなアンチパターンを見てみよう。
‘ 【最悪のアンチパターン】
Sub BadExample_RunBatch()
‘ 警告を消すためにオフにする
Application.SetOption “Confirm Action Queries”, False
Application.SetOption “Confirm Document Deletions”, False
‘ ここで何らかの重い処理
DoCmd.RunSQL “DELETE FROM T_TempWork”
DoCmd.RunSQL “INSERT INTO T_Main SELECT FROM T_TempWork”
‘ 元に戻す（つもり）
Application.SetOption “Confirm Action Queries”, True
Application.SetOption “Confirm Document Deletions”, True
End Sub
このコードのどこが致命的か？
もし、`DoCmd.RunSQL` の実行中になんらかのランタイムエラー（ロック競合やデータ型不一致など）が発生し、エラーハンドラにジャンプしたり処理が中断したりした場合、`True` に戻すコードは一生実行されない。
結果、そのセッション（場合によってはAccess自体）の警告設定が「オフ」のままになり、ユーザーが別の作業で誤って重要データを一括削除しても、二度と確認ダイアログが出なくなる。これは業務システムにおいて致命的なセキュリティホールとなる。
—
堅牢な設計思想：RAIIパターンと確実な復元
C++などのモダン言語には「RAII（Resource Acquisition Is Initialization）」という概念があるが、VBAであってもそれに近い「確実に後始末を保証する構造」を作らなければならない。
プロが守るべき設計原則は以下の3つだ。
1. 現在の状態を必ず退避（Get）してから変更（Set）する（ハードコーディングで「元はこうだったはず」と決め打ちしてはならない）。
2. エラーが発生しようとも、例外なく復元処理（Finallyに相当するブロック）を通す。
3. オプション名のスペルミスによる実行時エラーを防ぐラッパーを意識する。
—
【プロダクションコード】コピペで使える最強の制御クラス・モジュール
ここでは、実務の現場でそのまま組み込める、オプションの退避・変更・復元をカプセル化されたプロシージャとして提供する。
標準モジュール（例：`modEnvironmentManager`）に以下のコードを配置してほしい。
Option Compare Database
Option Explicit
‘ ==============================================================================
‘ 処理名: 危険な環境設定を一時変更し、確実に元の状態へ復元する安全実行ラッパー
‘ 開発現場の知見: エラーハンドリングの確実性を担保するため、退避と復元をセットで管理
‘ ==============================================================================
Public Sub ExecuteInQuietMode()
Dim orgActionQueries As Boolean
Dim orgDocDeletions As Boolean
Dim orgNameAutoCorrect As Boolean
Dim hasError As Boolean
On Error GoTo ErrorHandler
‘ ==========================================================================
‘ 1. 現在の設定値を退避 (GetOption)
‘ ==========================================================================
orgActionQueries = Application.GetOption(“Confirm Action Queries”)
orgDocDeletions = Application.GetOption(“Confirm Document Deletions”)
‘ ※「名前の自動修正」のマスター設定を無効化する場合
‘ （名前の自動修正はパフォーマンス低下や破損の原因になるためバッチ時は切るべき）
orgNameAutoCorrect = Application.GetOption(“Name Auto Correct Save”)
‘ ==========================================================================
‘ 2. 一時的に環境設定を変更 (SetOption)
‘ ==========================================================================
Application.SetOption “Confirm Action Queries”, False W ‘ アクションクエリ確認の抑制
Application.SetOption “Confirm Document Deletions”, False ‘ ドキュメント削除確認の抑制
Application.SetOption “Name Auto Correct Save”, False ‘ 自動名前修正の抑制
‘ ==========================================================================
‘ 3. 本丸の処理（ここに重い一括処理やトランザクションを記述）
‘ ==========================================================================
Debug.Print “— バッチ処理開始 —”
‘ 例：意図的にエラーを起こしてみるテスト（コメントアウトを外して検証可能）
‘ Err.Raise 9999, , “想定外のバッチエラー”
DoCmd.SetWarnings False ‘ DoCmdレベルの警告も念のため殺す
‘ ここに実際のクエリ実行やレコードセット処理を書く
DoCmd.SetWarnings True
Debug.Print “— バッチ処理正常終了 —”
CleanUp:
‘ ==========================================================================
‘ 4. 【最重要】いかなる結果であっても必ず設定を元に戻す
‘ ==========================================================================
Application.SetOption “Confirm Action Queries”, orgActionQueries
Application.SetOption “Confirm Document Deletions”, orgDocDeletions
Application.SetOption “Name Auto Correct Save”, orgNameAutoCorrect
Exit Sub
ErrorHandler:
hasError = True
MsgBox “バッチ処理中にエラーが発生しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“内容: ” & Err.Description, vbCritical, “システムエラー”
‘ エラー発生時もクリーンアップへ強制ジャンプ
Resume CleanUp
End Sub
—
アーキテクトが解説する実装の急所
1. `GetOption` の引数文字列の罠
`Application.GetOption` や `SetOption` の引数に指定する文字列は、Accessのオプション画面の英語表記（またはローカライズされた環境に応じた正確な名称）である必要がある。
日本語版Accessであっても、VBAの内部パラメータ名（例: `”Confirm Action Queries”`）は英語ベースであることが多いため、手動でテストを行い、実行時エラー（引数が無効です等）が出ないことを必ず確認してほしい。
2. 「名前の自動修正 (Name Auto Correct)」は悪魔の機能
プロとしてあえて言わせてもらう。Accessの「名前の自動修正」機能は、開発初期の利便性と引き換えに、クエリのパフォーマンス低下やデータベースの肥大化・破損を引き起こす最大の元凶だ。
大規模なデータインポートやテーブル構造変更を伴うバッチ処理の前には、必ず `Application.GetOption(“Name Auto Correct Save”)` で現在の状態を吸い上げ、一時的に `False` に設定することを強く推奨する。
3. グローバルスコープの汚染を防ぐ
マルチユーザー環境や、複雑にモジュールが入り組んだAccessシステムにおいて、あるプロシージャが勝手にグローバル設定を変えて放置することは、他の開発者への暴力に等しい。
「自分が変えたなら、自分が責任を持って退避した値に戻す」。この原則を徹底するために、上記のように変数への退避と `CleanUp` ラベルへのジャンプ（構造化例外処理の模倣）を標準フォーマットとしてチームに展開してほしい。
—
終わりに：プロとアマを分けるもの
動くコードを書くだけなら素人でもできる。しかし、「異常系や予期せぬ中断が起きても、システムの環境を汚さず、元の綺麗な状態へ確実に復元できるコード」を書くことこそが、プロのエンジニアとそうでない者を分かつ境界線だ。
`GetOption` と `SetOption` は諸刃の剣である。その鋭利な刃を正しくコントロールし、鉄壁の堅牢性を持つAccessアプリケーションを構築してほしい。
