拡張子判定でコケるな。PowerPoint VBAにおける「ガード節」による堅牢な設計術
業務自動化の現場において、PowerPoint VBAは強力な武器だ。しかし、多くの開発者が陥る最初の罠が「環境依存とファイル形式の不整合」である。
`.pptx`（マクロなし）で開いているのにマクロを保存しようとしてエラーを吐く、あるいは古い`.ppt`形式で挙動が怪しくなる――。こうした「運用でカバー」という甘い考えは、自動化エンジニアとしては即刻捨てるべきだ。
今日は、あなたのコードが運用中に予期せぬクラッシュを起こさないための、「ファイル形式を先読みし、処理を安全に分岐させるガードロジック」を伝授する。
—
なぜ「拡張子判定」を処理の冒頭に置くべきなのか
VBAにおける処理の失敗の多くは、後続の複雑なロジックの中で「ファイル形式が違った」ことに気づくために起こる。これではリソースの無駄であり、デバッグも困難だ。
プロの設計では、「処理の開始直後に、前提条件をクリアしているかチェックし、NGなら即座に停止する」という「ガード節（Guard Clause）」の概念を徹底する。
注意すべきポイント
- FullNameの罠: `Presentation.FullName` はパス全体を返す。単に `Right` 関数で判定するのはリスクが高い（ファイル名に`.pptx`が含まれている場合などに誤判定するため）。
- 保存の可否: `.pptx` で開いている場合、`Save` メソッドを叩いてもマクロは保存されない。これを知らずに自動化を進めるのは危険極まりない。
—
【実戦コード】堅牢なファイル形式判定ロジック
このコードは、モジュールの冒頭に配置し、メイン処理へ進む前に環境をクリーンアップするための「門番」となるものだ。
‘ —————————————————————————
‘ 概要: 現在のプレゼンテーション形式を判定し、処理を安全に制御する
‘ —————————————————————————
Public Sub ExecuteAutomatedTask()
Dim targetPres As Presentation
Set targetPres = ActivePresentation
‘ 1. ガード節：ファイル形式による事前チェック
Select Case GetFileExtension(targetPres.FullName)
Case “pptm”, “ppsm”
‘ マクロ有効形式なら安全に進む
Debug.Print “マクロ有効形式を確認。処理を開始します。”
Case “pptx”, “ppsx”
MsgBox “警告: このファイルはマクロなし形式です。” & vbCrLf & _
“保存機能を利用する場合は .pptm への変換が必要です。”, vbExclamation
Exit Sub
Case Else
MsgBox “未対応のファイル形式です。処理を中断します。”, vbCritical
Exit Sub
End Select
‘ 以下にメインの業務ロジックを展開する
Call RunMainProcess(targetPres)
End Sub
‘ —————————————————————————
‘ 拡張子を抽出する汎用関数
‘ —————————————————————————
Private Function GetFileExtension(ByVal filePath As String) As String
‘ FSOを使わずにパスから拡張子を抽出（依存関係を減らす設計）
Dim dotPos As Long
dotPos = InStrRev(filePath, “.”)
If dotPos > 0 Then
GetFileExtension = LCase(Mid(filePath, dotPos + 1))
Else
GetFileExtension = “”
End If
End Function
—
アーキテクトの視点：この設計の「強み」
1. 依存関係の排除（低結合）
あえて `Scripting.FileSystemObject` を使わずに標準関数で記述した。これは、特定の環境でライブラリ参照設定が外れていても動作させるための「現場の知恵」だ。自動化ツールは、配布先のPC環境に左右されてはならない。
2. 拡張性を確保したSelect Case
`If` 文のネストはコードを汚染する。`Select Case` を使うことで、将来的に「特定の社内フォーマット（.pptxmなど）」が増えた際にも、分岐を一行追加するだけで対応できる保守性を担保した。
3. エラー回避の心理的安全性
「ユーザーが間違ったファイルを開いて実行しても、絶対にシステムを壊さない」。この安心感こそが、業務自動化ツールがチーム内で信頼されるための絶対条件である。
—
エンジニアへの提言
良いコードとは、複雑なロジックを詰め込んだコードではない。「失敗が予見される場所を徹底的に塞ぎ、残りのリソースを本来の業務ロジックに100%集中させるコード」だ。
今日学んだこのガードロジックを、あなたの全てのプロジェクトの「入り口」に実装してほしい。それだけで、運用中に発生する「謎のエラー」の8割は撲滅できるはずだ。
次は、このチェックを通過した後に、いかにしてDB連携や外部API通信へ安全に引き継ぐか――。その設計論について深掘りしていくことにしよう。
現場からは以上だ。健闘を祈る。
