泥沼の互換性地獄を脱却せよ：PowerPoint VBAにおけるバージョン分岐の真髄
現場で戦い続けているエンジニアなら、一度は経験があるはずだ。
「最新のPCで動くツールを構築したのに、役員の古いノートPC（Office 2013）で走らせた途端、コンパイルエラーや実行時エラーで沈黙する」という悪夢を。
VBAは、一度デプロイすれば10年以上生き残る「ゾンビのようなコード」を量産する。この環境下で、単に `Application.Version` を眺めるだけでは不十分だ。本稿では、レガシー環境とモダン環境の境界線を安全に渡り歩くための、真のアーキテクトによる「防御的プログラミング」の極意を伝授する。
—
1. なぜ「If Application.Version」だけでは足りないのか
多くの初心者は、単に `If Val(Application.Version) >= 16 Then` と書き、その中に最新機能を詰め込む。しかし、これは危険な賭けだ。
VBAは事前バインディング（Early Binding）において、参照設定されたライブラリのメソッドをコンパイル時に検証する。存在しないプロパティをコード上に記述している時点で、古いバージョンの環境ではコンパイルすら通らないリスクがあるのだ。
本当に安全なコードを目指すなら、「Late Binding（実行時バインディング）」を活用した動的なアクセスか、あるいはインターフェースを介した抽象化が必要になる。
—
2. 実装：安全なバージョン判定と機能制限のテンプレート
以下のコードは、モダンなスライド切り替え効果（Office 2016以降で導入されたものなど）を制御する際の、実戦的なテンプレートだ。
‘ —————————————————————————
‘ @brief PowerPointのバージョンに応じて安全に機能分岐を行う
‘ @description 事前バインディングでコンパイルエラーを回避しつつ、
‘ 各環境に最適な処理を実行する。
‘ —————————————————————————
Public Sub ApplyModernTransition(ByRef targetSlide As Slide)
Dim pptVersion As Double
pptVersion = CDbl(Application.Version)
‘ 16.0 は Office 2016 / 365
‘ バージョン判定による分岐
If pptVersion >= 16# Then
‘ モダン環境のみ実行可能な処理
‘ CallByNameを使用し、プロパティ名を実行時に評価することで
‘ 古い環境でのコンパイルエラーを完全に排除する
On Error Resume Next
CallByName targetSlide.SlideShowTransition, “SectionProperties”, VbMethod
If Err.Number <> 0 Then
Debug.Print “この環境ではSectionPropertiesはサポートされていません。”
End If
On Error GoTo 0
Else
‘ レガシー環境用のフォールバック処理
Debug.Print “レガシー環境のため、標準的な切り替えを適用します。”
targetSlide.SlideShowTransition.EntryEffect = ppEffectFade
End If
‘ 【重要】メモリ最適化：明示的なオブジェクト解放
‘ VBAのGCは信用するな。スコープを抜ける前に参照を断ち切るのが鉄則。
Set targetSlide = Nothing
End Sub
—
3. シニアエンジニアが意識すべき「3つの技術的視点」
① `CallByName` 関数による抽象化
先ほどのコードで示した通り、`CallByName` を使うとプロパティやメソッドを文字列として指定できる。これにより、古いバージョンのインターフェース定義ファイル（Type Library）にそのメンバが存在しなくても、実行時までコンパイラを黙らせることが可能だ。これは「レガシー保守の最終兵器」と言える。
② メモリとオブジェクトライフサイクル
PowerPointのオブジェクトモデルは非常に重い。特に `Presentation` や `Slide` オブジェクトをループ処理で回す際、不用意な参照保持はメモリリークに直結する。
- Withステートメントの多用を避ける: 内部的に暗黙の参照が生成され、解放タイミングが不明瞭になる。
- Nothingの徹底: 処理の終了時に `Set obj = Nothing` を行うのは当然として、ループ内での一時変数も必ず解放する癖をつけよ。
③ Windows APIとの共存（高度な制御）
Officeの標準機能でどうにもならない場合、`User32.dll` の `FindWindow` や `SendMessage` を呼び出すことになるだろう。その際、64bit版Officeと32bit版Officeの混在環境を考慮し、必ず `PtrSafe` 属性を付与すること。
If VBA7 Then
‘ 64bit/32bit両対応の宣言
Private Declare PtrSafe Function GetActiveWindow Lib “user32” () As LongPtr
Else
‘ 旧世代の32bit専用宣言
Private Declare Function GetActiveWindow Lib “user32” () As Long
End If
—
最後に：コードは「生き物」である
あなたが書いたそのVBAコードは、5年後に誰がメンテナンスするのか？あるいは、5年後のWindows Updateで動かなくなる可能性はないか？
「とりあえず動けばいい」という考えは捨てろ。バージョン分岐を適切に配置し、実行時バインディングを駆使し、メモリのライフサイクルを制御する。この泥臭い積み重ねこそが、荒波のようなエンタープライズ環境で生き残る「本物の自動化エンジニア」の条件だ。
技術は裏切らない。コードの隅々にまであなたの意志を込めてほしい。健闘を祈る。
