Word VBAの深淵：Document Openイベントによる「強制統治」のアーキテクチャ
諸君、Word VBAを「マクロ記録の延長」だと思っているなら、今すぐその認識を捨てろ。Wordは単なるワープロソフトではない。COM（Component Object Model）という巨大な深淵を内包した、OSの一部とも呼べるアプリケーションフレームワークだ。
今回は、社内テンプレートの改ざんを許さず、文書の整合性を強制的に担保する「Applicationレベルのイベントハンドラ」による実装技術を伝授する。これは、小手先のVBAテクニックではない。Wordのライフサイクルそのものに介入する、境界防衛戦のアーキテクチャだ。
—
1. なぜ「Document_Open」単体では不十分なのか
初心者は`ThisDocument`モジュールに`Document_Open`を書く。だが、それは素人のやり方だ。ユーザーが「マクロを無効」にして開けば、そのロジックは即座に無力化される。
真のアーキテクトは、`WithEvents`を実装したClassモジュールを用い、`Application`オブジェクト全体を監視する。これにより、どの文書が開かれようとも、Wordプロセスが起動している限り、我々の監視網から逃れることはできない。
—
2. 実装：Applicationレベルの監視ユニット
まずは、監視の要となるClassモジュール（例：`clsAppEvents`）を作成する。
‘ Classモジュール: clsAppEvents
Option Explicit
‘ Applicationオブジェクトをイベント付きで定義
Public WithEvents App As Word.Application
‘ 文書が開かれた瞬間に発火
Private Sub App_DocumentOpen(ByVal Doc As Document)
‘ メモリ最適化：不要なオブジェクト生成を避ける
‘ 文書のプロパティを確認し、保護が必要か判定
If Not IsValidTemplate(Doc) Then
Call EnforceCompliance(Doc)
End If
End Sub
Private Sub EnforceCompliance(ByRef Doc As Document)
‘ ここで強制的な保護とチェックを実行する
‘ パフォーマンスを考慮し、画面更新を一時停止
Application.ScreenUpdating = False
‘ 文書保護（パスワード付き）の強制適用
If Not Doc.ProtectionType = wdAllowOnlyFormFields Then
Doc.Protect Password:=”SecretKey2024″, Type:=wdAllowOnlyFormFields
End If
Application.ScreenUpdating = True
End Sub
—
3. ライフサイクルの管理：初期化とメモリ解放
VBAにおいて、オブジェクトのリークは死を意味する。`Application`オブジェクトへの参照を保持する変数は、アドイン（Global Template）の起動時に生成し、終了時に確実に破棄しなければならない。
標準モジュール（`modMain`）での初期化：
‘ 標準モジュール
Option Explicit
Private AppEvents As clsAppEvents
Public Sub AutoExec()
‘ Word起動時に自動実行されるエントリポイント
Set AppEvents = New clsAppEvents
Set AppEvents.App = Word.Application
End Sub
極限の知見：
ここで重要なのは、`Set AppEvents = Nothing`を明示的に呼び出すタイミングを逃さないことだ。Wordが終了する際、`AutoExit`プロシージャでオブジェクトを解放せよ。さもなくば、ゾンビプロセスがメモリ上に残り、次回の起動時にCOMエラーを引き起こす原因となる。
—
4. Windows APIによる「さらなる統治」
VBAの標準機能だけで満足してはならない。社内テンプレートのコピーを防ぐために、クリップボードの監視や、文書のハンドル特定が必要になる場面がある。
Windows APIを用いたウィンドウハンドルの特定例を挙げる。
If Win64 Then
Private Declare PtrSafe Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr
Else
Private Declare Function FindWindow Lib “user32” Alias “FindWindowA” (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
End If
‘ 特定の文書ウィンドウがアクティブになった際、APIでウィンドウ属性を操作し
‘ 編集不可の領域を視覚的にロックするなどの高度な制御が可能となる。
—
5. チーフアーキテクトからの提言：保守性の極意
最後に、このシステムを運用する諸君へ。
VBAは「書き捨て」ではない。特に`Application`レベルのイベントは、Wordの挙動全体に影響を与えるため、エラーハンドリングを徹底せよ。
1. On Error Resume Nextの濫用禁止: 必ずエラーハンドラを実装し、ログを出力しろ。
2. イベントの連鎖を断つ: `Application.EnableEvents = False` を適切に使い、イベントの多重発火による無限ループを物理的に封じろ。
3. レガシー環境への配慮: `PtrSafe`属性を忘れるな。32bit/64bitの混在環境こそが、現場の現実だ。
Word VBAは、単なる自動化ツールではない。それは、文書という「データ」と、Wordという「プラットフォーム」の間を橋渡しする、極めて強力な制御言語だ。この知見を胸に、諸君の現場を堅牢なものへと進化させてほしい。
以上だ。健闘を祈る。
