PowerPoint VBAを掌握する極限の知見：バージョン＆ビルド判定による「環境依存バグ」の完全制圧
開発プロジェクトの現場において、最もエンジニアを疲弊させる悪夢は何か。
それは、「自分の開発環境では完璧に動作するのに、ユーザーの端末（あるいは特定のクライアント環境）で突然クラフトが崩壊し、あるいは未定義のエラーで強制終了する」という、環境差異に起因する不具合だ。
特にPowerPoint VBAの生態系は、Office 2013、2016、2019、2021、そしてサブスクリプション型のMicrosoft 365（旧Office 365）が混在するカオスな戦場である。さらに厄介なことに、Microsoft 365の「毎月の機能更新（Current Channel）」や「半期チャネル（Semi-Annual Enterprise Channel）」によって、昨日まで動いていたAPIが今日のアップデートで沈黙するという事態が現実に起こる。
今回は、PowerPoint VBAの根幹をなす `Application.Version` と `Application.Build` を極限まで解剖し、特定のOfficeアップデートで発生する既知のバグやメソッドの非互換性を安全にバイパスする「堅牢な互換性設計（防御的プログラミング）」の極意を伝授しよう。
—
1. なぜ「バージョン依存の事故」は起きるのか？
甘い設計のコードによく見られるアンチパターンは、次のようなものである。
‘ 【最悪のアンチパターン】
‘ 実行環境を考慮せず、無邪気に最新のメソッドを呼び出す
ActivePresentation.Merge “C:\path\to\other.pptx”
この `Merge`（比較・マージ）メソッドや、近年のモダンな図形操作、非同期保存に関連するAPIは、特定のOfficeビルド以降でなければ実装されていなかったり、あるいは特定のバージョン（例：バージョン2004のビルド周辺など）でメモリリークや強制終了を引き起こす既知のバグ（マイクロソフトのサポートフォーラムでも阿鼻叫喚となる類のもの）を孕んでいる。
「エラーハンドラー（`On Error Resume Next`）で捕まえればいいじゃないか」と思ったならば、VBAエンジニアとしての修行が足りない。
致命的なクラッシュ（Access Violationなど）は、VBAの `Err` オブジェクトで捕捉することすらできず、ホストアプリケーションごと強制終了する。予防医学と同じで、実行前にバージョンを査察し、危険な航路を避けることこそが唯一無二の正解なのだ。
—
2. バージョンとビルド情報の正確な取得メカニズム
PowerPointのバージョン情報を取得するプロパティには、主に以下の2つが存在する。
1. `Application.Version`: メジャーバージョンを返す（例: Office 2016なら “16.0”、Office 2013なら “15.0”）。
2. `Application.Build`: マイナーバージョンや内部ビルド番号を文字列で返す（例: “13801.21092” など）。
ここでプロとしての知見を一つ。`Application.Version` は「文字列」を返すため、数値として比較する際には型変換に注意しなければならない。また、Microsoft 365環境においては、メジャーバージョンは一律 `”16.0″` を名乗り続けるという極めてタチの悪い仕様になっている。
つまり、Microsoft 365内の細かなビルド差異やアップデートによるバグを検知するためには、`Application.Version` ではなく `Application.Build` の数値解析が不可欠となる。
—
3. 【プロダクションコード】堅牢な環境判定と安全なバイパス設計
実務でそのまま組み込める、極限まで洗練されたバージョン判定・安全実行モジュールの実装例を提示する。
このコードは、特定のビルド番号未満の環境でクラッシュする処理を実行しようとした場合、安全に機能をダウングレード（あるいはスキップ）させる設計になっている。
Option Explicit
‘ ==============================================================================
‘ モジュール名: MdlEnvironmentGuard
‘ 概要: PowerPointのバージョンおよびビルドを解析し、環境依存バグを回避する
‘ ==============================================================================
‘ バグ修正が行われたターゲットビルドのしきい値（例としての定数定義）
Private Const TARGET_SAFE_BUILD As Long = 13929
Public Sub ExecuteSafeOperation()
‘ 1. 実行環境の安全性を事前検証
If Not ValidateEnvironmentForFeatureX() Then
MsgBox “お使いのPowerPointのバージョン/ビルドは、” & vbCrLf & _
“この機能で発生する既知のバグの安全圏外にあります。” & vbCrLf & _
“処理を安全にスキップします。”, vbExclamation, “互換性ガード”
Exit Sub
End If
‘ 2. 安全が担保された環境でのみ実行するメイン処理
Call UnsafeFeatureX_Core
End Sub
‘ ——————————————————————————
‘ 環境検証ロジック
‘ ——————————————————————————
Private Function ValidateEnvironmentForFeatureX() As Boolean
Dim appVersion As Double
Dim appBuild As Long
On Error GoTo ErrorHandler
‘ メジャーバージョンの取得 (例: “16.0” -> 16.0)
appVersion = Val(Application.Version)
‘ Office 2013 (v15.0) 以前は問答無用でNG
If appVersion < 16.0 Then
ValidateEnvironmentForFeatureX = False
Exit Function
End If
' Microsoft 365 / Office 2016以降のビルド番号を取得
' Buildプロパティは文字列型であるため、安全にLong型へ変換
appBuild = CLng(Val(Application.Build))
' --------------------------------------------------------------------------
' 【重要】特定のバグが存在するビルド範囲のブラックリスト判定
' 例：ビルド 13000 から 13928 の間で発生する致命的描画バグを回避
' --------------------------------------------------------------------------
If appBuild >= 13000 And appBuild < TARGET_SAFE_BUILD Then
' 危険なビルド範囲に該当
ValidateEnvironmentForFeatureX = False
Exit Function
End If
' すべての関門をクリア
ValidateEnvironmentForFeatureX = True
Exit Function
ErrorHandler:
' 予期せぬ型変換エラー等の場合は安全側に倒してFalseを返す
ValidateEnvironmentForFeatureX = False
End Function
' ------------------------------------------------------------------------------
' 潜在的リスクを持つコア処理（安全圏でのみ呼ばれる）
' ------------------------------------------------------------------------------
Private Sub UnsafeFeatureX_Core()
' ここに特定のモダンAPIや、複雑な図形結合・マージ処理を記述
Debug.Print "安全な環境下で高度な処理を実行中..."
' 実装例：安全が確認された環境でのみ実行する処理
' ActivePresentation.Merge ...
End Sub
---
4. 現場で活きるチーフアーキテクトからの提言
ファイルやデータベース連携時の注意点
もしこのVBAツールが、社内のファイルサーバー経由で多人数に配布される、あるいはローカルDB（SQLiteやAccess）と連携する性質のものであるならば、「起動時に自動でバージョンログを収集する仕組み」を組み込むことを強く推奨する。
‘ ログ出力のイメージ（エラー suppressorを通じたサイレント収集）
Public Sub LogEnvironmentMetrics()
Dim fso As Object, ts As Object
Set fso = CreateObject(“Scripting.FileSystemObject”)
‘ 共有サーバーのログ等に Version と Build を書き残すことで、
‘ 「どの部署の誰のPCでバグを踏んでいるか」を瞬時に特定できる。
End Sub
インフラの更新スピードと、ユーザーが勝手に行うOfficeアップデートのスピードの間に生じる「歪み」を制御できるのは、コードを書く我々エンジニアだけだ。
まとめ
「動けばいい」というアマチュアのプログラミングから脱却し、エンタープライズクオリティの堅牢性を手に入れたいのであれば、「APIを叩く前に、環境の足元を疑え」。
`Application.Version` と `Application.Build` を制する者は、PowerPoint VBAの環境依存トラブルを制す。この知見をあなたの開発プロジェクトに直ちに実装し、無駄なトラブルシューティングの工数をゼロへと昇華させてほしい。
