PowerPoint VBAの深淵：`ReadOnlyRecommended`を制し、堅牢なアクセス制御を実装する
我々のようなレガシーと最先端の狭間で戦うエンジニアにとって、PowerPointは単なるプレゼンテーションツールではない。時には機密データの器であり、時には社内業務フローの末端を担う自動化対象となる。
本稿では、PowerPointのファイル属性の一つである`ReadOnlyRecommended`を動的に制御し、さらにVBAのイベントハンドラを駆使した簡易的なアクセス制御層の実装について、その「真髄」を説く。
1. `ReadOnlyRecommended`の真実
まず、`Presentation.ReadOnlyRecommended`プロパティを理解せよ。これはファイルシステム上の「読み取り専用」属性とは異なる。あくまでOfficeアプリケーション層に対する「推奨」フラグであり、ユーザーに「編集して保存しますか？」というダイアログを強制表示させるためのトリガーだ。
これを動的に切り替えることは、特定の業務フェーズ（例：承認待ち状態）において編集を制限する強力なガードレールとなる。
実装：属性のトグル制御
以下のコードは、現在のプレゼンテーションの状態を判断し、属性を安全に切り替えるための基本ルーチンだ。
‘ @description: ReadOnlyRecommended属性の動的切り替え
‘ @param: bState (Boolean) – Trueで推奨、Falseで解除
Public Sub SetReadOnlyRecommendation(ByVal bState As Boolean)
On Error GoTo ErrorHandler
‘ ActivePresentationのState確認。未保存ファイルには適用不可という制約を考慮
If Application.Presentations.Count = 0 Then Exit Sub
With Application.ActivePresentation
If .ReadOnlyRecommended <> bState Then
.ReadOnlyRecommended = bState
‘ 変更を反映させるには一度保存が必要。非同期処理の競合に注意せよ
.Save
End If
End With
Exit Sub
ErrorHandler:
Debug.Print “Error: ” & Err.Number & ” – ” & Err.Description
End Sub
2. イベントハンドラを用いたアクセス制御のアーキテクチャ
単なるフラグだけでは、強欲なユーザーは「いいえ」を押して編集を強行する。真の制御を求めるなら、`Application`レベルのイベントハンドラを実装し、開かれた直後の`SlideShowBegin`や`WindowActivate`ではなく、`PresentationOpen`をフックする必要がある。
クラスモジュール（Class1）による監視
`ThisPresentation`で直接扱うのは避けよ。`ClassModule`を定義し、ライフサイクルを明示的に制御する。
‘ Class Module: clsAppEvents
Public WithEvents App As Application
Private Sub App_PresentationOpen(ByVal Pres As Presentation)
‘ 簡易アクセス制御：特定のPCユーザー以外を遮断する例
Dim currentUser As String
currentUser = Environ(“USERNAME”)
‘ 管理者ID以外が編集モードで開いた場合の強制的読み取り専用切り替え
If currentUser <> “AdminUser01” Then
If Not Pres.ReadOnly Then
MsgBox “権限外のアクセスです。本ファイルは読み取り専用で開かれます。”, vbCritical
‘ 強制的に読み取り専用に追い込むための再読み込みロジックをここに挿入
End If
End If
End Sub
3. メモリとオブジェクトの最適化：伝説的エンジニアの流儀
VBAのガーベジコレクションを信じるな。`Presentation`や`Slide`オブジェクトを操作する際、参照カウントが残ったままのプロジェクトは、いずれ`Automation Error`の深淵に沈む。
- 明示的解放: `Set obj = Nothing`は儀式ではない。スコープを抜ける前に必ず行え。
- イベントの切断: クラスモジュールを破棄する際は、必ず`App = Nothing`を呼び出し、メモリリークの温床を根絶する。
- APIによるウィンドウ制御: もしWindows APIを用いて「編集ボタンを無効化」するような高度な制御を検討しているなら、`FindWindow`と`EnableWindow`を組み合わせる必要があるが、これはOSのバージョンアップで脆弱になる「劇薬」であることを銘記せよ。
4. 現場への提言：なぜVBAで制御するのか
読者諸氏の中には「SharePointやAzure Information Protectionで制御すべきでは？」と考える者もいるだろう。正論だ。しかし、システム間の連携が困難な閉域ネットワークや、即時性が求められる社内ツールにおいては、このVBAによる制御が「最も速く、かつ最も安上がりな解」となる。
最後に、警告しておく。
VBAによるセキュリティはあくまで「善意のユーザーを止めるためのブレーキ」だ。悪意あるユーザーはVBAを無効化してファイルを開く。真の機密保護を求めるなら、暗号化を併用し、VBAはあくまで「業務遂行をスムーズにするためのインターフェース」として位置づけよ。
技術を掌握せよ。ツールに使われるな。このコードが諸氏の現場における堅牢な盾となることを期待する。
