【実務・中級編】Application.GetOptionで「名前の自動修正」機能をVBAから一時的に無効化するリスク回避術 – Access VBA解析バイブル

Accessの「名前の自動修正」という名の爆弾を、VBAで完封する技術

Access開発の現場で、ある日突然、クエリの実行が遅延したり、不可解なエラーでシステムが停止したりしたことはないだろうか。その元凶の多くは、Accessのデフォルト機能である「名前の自動修正（Name AutoCorrect）」にある。

この機能は、テーブル名を変更した際にフォームやクエリの参照先を追従してくれる親切な機能のように見える。だが、大規模なシステムや複雑なクエリが絡み合う本番環境において、この「裏側で行われる監視と更新」は、パフォーマンスを殺し、データベースの破損リスクを高めるだけの「重荷」でしかない。

本稿では、この悪名高き機能をVBAから制御し、堅牢なシステムを構築するための「プロの防衛術」を伝授する。

—

なぜ「名前の自動修正」をオフにすべきなのか？

結論から言えば、「実行時のオーバーヘッド」と「未知の副作用」である。

1. パフォーマンス低下: 変更を検知するために常にメタデータを監視するため、複雑なクエリを多用するシステムではCPUコストが跳ね上がる。
2. データベース破損のリスク: 名前の自動修正テーブル（MSysNameMap）が肥大化すると、最悪の場合、DBファイル全体の破損を招く。
3. 予期せぬ挙動: 意図しないタイミングで参照先が書き換わることは、大規模アプリにおいてデバッグを困難にする最大の要因だ。

プロの開発現場では、「名前の自動修正」は無効化するのが基本原則である。

—

「名前の自動修正」を制御するプロダクションコード

`Application.GetOption` および `Application.SetOption` を使用することで、この機能をプログラムから制御できる。重要なのは、「処理の開始時にバックアップを取り、終了時に確実に元の状態へ戻す」というライフサイクル管理だ。

以下に、実業務でそのまま使える堅牢なクラスモジュール風の制御コードを提示する。

‘ ==============================================================================
‘ 機能名: AutoCorrectManager
‘ 概要: 「名前の自動修正」設定を一時的に操作するクラス
‘ ==============================================================================
Option Compare Database
Option Explicit

‘ Accessのオプション定数
Private Const OPT_NAME_AUTOCORRECT As String = “Track Name AutoCorrect Info”

‘ 現在の設定を保持する変数
Private m_OriginalState As Boolean

‘ 自動修正を無効化し、現在の設定を退避する
Public Sub DisableAutoCorrect()
‘ 現在の状態を取得（True:有効, False:無効）
m_OriginalState = Application.GetOption(OPT_NAME_AUTOCORRECT)

‘ 有効であれば無効化する
If m_OriginalState = True Then
Application.SetOption OPT_NAME_AUTOCORRECT, False
Debug.Print “名前の自動修正を無効化しました。”
End If
End Sub

‘ 設定を元の状態へ戻す
Public Sub RestoreAutoCorrect()
If Application.GetOption(OPT_NAME_AUTOCORRECT) <> m_OriginalState Then
Application.SetOption OPT_NAME_AUTOCORRECT, m_OriginalState
Debug.Print “名前の自動修正を元の設定(” & m_OriginalState & “)に戻しました。”
End If
End Sub

実務での利用例（イディオム）

処理の途中でエラーが発生しても設定が「無効」のままにならないよう、必ず `Finally` ブロック的な構造（エラートラップ）を持たせること。

Public Sub RunHeavyProcess()
Dim manager As New AutoCorrectManager

On Error GoTo Err_Handler

‘ 処理前に無効化
manager.DisableAutoCorrect

‘ — ここに本来の重い業務処理を記述 —
‘ 例: 大量データのインポート、複雑なクエリの実行など

‘ 終了後に復元
manager.RestoreAutoCorrect
Exit Sub

Err_Handler:
‘ エラー時も確実に復元を試みる
manager.RestoreAutoCorrect
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical
End Sub

—

アーキテクトからの助言：設計の哲学

このコードを実装する上で、一つだけ覚えておいてほしいことがある。それは、「この設定はアプリケーション全体（現在のAccessインスタンス）に影響する」ということだ。

• マルチユーザー環境では注意せよ: `SetOption` はそのセッション中、すべての処理に影響を与える。バックグラウンドで別の非同期処理が走っている場合、安易な切り替えは混乱を招く。
• 初期設定としてオフにする: 可能であれば、配布前にAccessのオプション画面から「名前の自動修正」を完全にオフにしておくのがベストだ。VBAでの動的制御は、あくまで「どうしてもオンにせざるを得ない開発環境」と「リリース後の運用」のハイブリッドを想定したバックアッププランであるべきだ。

最後に

「便利な機能」の裏には、往々にして「制御できないリスク」が隠れている。業務自動化エンジニアにとって重要なのは、ツールが提供する便利機能をそのまま信じることではない。「その機能がいつ、どこで、どのようなコストを払っているのか」を透視し、必要に応じて無効化する勇気を持つことだ。

このコードをあなたのプロジェクトに組み込み、システムをより静かで、より堅牢なものへと進化させてほしい。それが、プロの仕事だ。