【PowerPoint VBA】共有サーバーの「死のロック」を無効化せよ：ReadOnly強制オープンと排他制御の極意
共有ネットワークドライブ上に置かれたPowerPointファイルをVBAで操作しようとして、`Run-time error ’70’: Permission denied`に打ちのめされたことはないか？
これは単なるエラーではない。マルチユーザー環境における「排他制御の無知」に対する、OSからの冷徹な宣告だ。大規模組織のレガシーシステムを保守するエンジニアにとって、ファイルロックは日常茶飯事。今回は、この泥沼を回避し、いかなる状況下でも安全にデータを抽出するための「極限のハンドリング」を伝授する。
—
1. 衝突を回避する「強制ReadOnly」の戦略
PowerPointの`Presentations.Open`メソッドをデフォルトで使うのは、地雷原を裸足で歩くのと同じだ。我々アーキテクトが目指すべきは、「相手が編集していようが、こちらの処理は止めない」という強固な堅牢性である。
ここで重要なのは、`ReadOnly`引数に`msoTrue`を指定するだけでは不十分だという事実だ。OSが掴んでいるハンドルをいかにスマートに回避するか、その実装が問われる。
実装コード：堅牢なReadOnlyオープン
‘ 共有ファイルを安全に開き、データ抽出後確実に閉じるためのテンプレート
Public Sub OpenPresentationSafely(ByVal targetPath As String)
Dim pptApp As Application
Dim targetPres As Presentation
‘ Error Handlingのセットアップ
On Error GoTo ErrHandler
‘ 既に開かれている可能性、ロックされている可能性を考慮
‘ ReadOnly:=msoTrue で開き、排他ロックを回避する
Set targetPres = Presentations.Open(FileName:=targetPath, _
ReadOnly:=msoTrue, _
Untitled:=msoFalse, _
WithWindow:=msoFalse)
‘ — ここにデータ抽出処理を記述 —
Debug.Print “Processing: ” & targetPres.Name
‘ ——————————
‘ 処理終了後、即座にオブジェクトを解放
targetPres.Close
Set targetPres = Nothing
Exit Sub
ErrHandler:
If Err.Number = 70 Then
MsgBox “ファイルは現在他のユーザーによってロックされています。”, vbCritical
Else
MsgBox “予期せぬエラー: ” & Err.Description, vbCritical
End If
‘ メモリリーク防止のため、オブジェクトを明示的にNothingへ
If Not targetPres Is Nothing Then targetPres.Close
Set targetPres = Nothing
End Sub
—
2. Windows APIによるロック状態の「先読み」
`On Error`による事後処理は、あくまで最後の手札だ。プロのエンジニアは、オープンする前に「そのファイルが本当に開けるのか」を検知する。
Windows APIの`CreateFile`関数を呼び出すことで、ファイルへのアクセス権限を事前にテストできる。これにより、`Runtime Error`を発生させる前に「待機」や「スキップ」の判断を下すことが可能になる。
Windows APIを利用した排他チェック
If VBA7 Then
Private Declare PtrSafe Function CreateFile Lib “kernel32” Alias “CreateFileA” ( _
ByVal lpFileName As String, ByVal dwDesiredAccess As Long, _
ByVal dwShareMode As Long, ByVal lpSecurityAttributes As Long, _
ByVal dwCreationDisposition As Long, ByVal dwFlagsAndAttributes As Long, _
ByVal hTemplateFile As Long) As Long
Private Declare PtrSafe Function CloseHandle Lib “kernel32” (ByVal hObject As Long) As Long
End If
‘ 0xFFFFFFFF は INVALID_HANDLE_VALUE
Const GENERIC_READ = &H80000000
Const FILE_SHARE_READ = &H1
Const OPEN_EXISTING = 3
Const INVALID_HANDLE_VALUE = -1
Function IsFileLocked(ByVal filePath As String) As Boolean
Dim hFile As Long
hFile = CreateFile(filePath, GENERIC_READ, 0, 0, OPEN_EXISTING, 0, 0)
If hFile = INVALID_HANDLE_VALUE Then
IsFileLocked = True
Else
CloseHandle hFile
IsFileLocked = False
End If
End Function
この関数をオープン前に挟むことで、コードの予測可能性（Predictability）は飛躍的に向上する。
—
3. なぜ「オブジェクトの解放」が宗教の域まで重要なのか
VBAにおけるメモリ管理は、ガベージコレクションに頼れない。特にPowerPointの`Presentation`や`Slide`オブジェクトをループ内で生成し続けると、メモリリークは確実にシステムを死に至らしめる。
- 明示的な`Nothing`代入: ローカル変数であっても、ループの最後には必ず`Set obj = Nothing`を記述せよ。
- Applicationの生存期間: 外部から`CreateObject`で立ち上げた`PowerPoint.Application`は、`Quit`メソッドを呼んだだけではメモリ上にプロセスが残ることがある。必ず`Set pptApp = Nothing`まで記述し、参照カウントをゼロにすることを徹底する。
—
結論：アーキテクトの矜持
VBAは「簡易的なツール」として軽視されがちだが、大規模な共有サーバー環境で安定稼働させるためには、OSレベルの知識と、徹底したメモリ管理の規律が必要だ。
1. 事前チェック（API）でリスクを排除する。
2. ReadOnlyオープンで競合の余地をなくす。
3. 確実な解放（Nothing）でリソースを回す。
この3点を守るだけで、あなたの書くVBAコードは、他者の稚拙なスクリプトとは一線を画す「システム」へと昇華するはずだ。次の現場でも、このアーキテクチャを標準として実装してほしい。健闘を祈る。
