【プロフェッショナル】Application.Runによるマクロの動的連携：別プレゼン共通ライブラリを支配する
こんにちは。開発プロジェクトの現場でアーキテクチャの統括をしている。
PowerPoint VBAを用いた業務自動化において、多くの開発者が直面する最初の「壁」がある。それは、「全社共通の便利なマクロを、なぜか作成するツール（.pptm）ごとにコピペして回り、バージョン管理の悪夢に悶絶する」というアンチパターンだ。
「共通関数を一つのマスターファイルにまとめ、そこから各業務ツールを叩きたい」
「しかし、別ファイルのプロシージャをどうやって安全に呼び出し、引数を渡し、戻り値を受け取ればいいのか分からない」
今回は、この課題に対する決定的な解法である `Application.Run` メソッド を用いたマルチプロジェクト制御の極限を伝授する。オブジェクトのライフサイクルとスコープの罠を知り尽くしたプロフェッショナルだけが書ける、堅牢で美しいコードベースを公開しよう。
—
1. なぜ「コードのコピペ」は悪であり、なぜ `Application.Run` なのか
素人がやりがちな設計はこうだ：共通関数（例：ログ出力や特殊な図形整形）を各プレゼンテーションの標準モジュールにコピペする。
これがなぜ非効率か？ 言うまでもない。共通仕様に変更が入った瞬間、全ツールを修正して再配布する地獄が始まるからだ。
では、参照設定（VBAProjectの参照）を使えばいいのではないか？
――答えは「No、実務ではリスクが高すぎる」。PowerPointのVBAにおいて、別プレゼンへの参照設定はパスの固定化やファイル移動による「リンク切れ（`MISSING:`）」を引き起こしやすく、実行時エラーの温床になる。
ここで採用すべきなのが `Application.Run` による動的バインディング（遅延バインディング） だ。
このアプローチには以下の圧倒的なアドバンテージがある。
1. 完全な疎結合: 呼び出し元のツールは、共通ライブラリ（.pptm）が「どこに存在するか」と「関数名」と「引数」だけを知っていればいい。
2. メモリとプロセスの制御: 共通ライブラリをバックグラウンドで安全に起動・操作し、処理完了後に適切に解放できる。
3. 堅牢なエラーハンドリング: ライブラリが存在しない場合や、目的の関数が見つからない場合のエラーを完全にハンドリングできる。
—
2. 堅牢なマルチプロジェクト制御の全体像
今回構築するアーキテクチャは以下の通りだ。
- 共通ライブラリ (`CommonLibrary.pptm`): 実際の処理ロジック（例：データ整形、共通ログ出力）を保持するマクロ有効プレゼンテーション。
- 業務ツール (`WorkTool.pptm`): ユーザーが操作するメインのプレゼンテーション。ここから `CommonLibrary.pptm` の関数を叩く。
⚠️ プロフェッショナルの鉄則：セキュリティとパスの罠
実務でこの仕組みを入れる際、最大の障害になるのが 「信頼できる場所（Trusted Locations）」 の設定と、「VBAプロジェクトへのアクセスをプログラムから信頼する」 のセキュリティ設定だ。これが抜けていると、`Application.Run` は容赦なく実行時エラーを吐く。また、ファイルパスは相対パス（`ThisPresentation.Path`）を基準に動的に解決するのがプロの常識である。
—
3. プロダクションコード実装
ここから、実際に現場でそのまま使える実用的なコードを提示する。
① 共通ライブラリ側 (`CommonLibrary.pptm`) のコード
まずは、呼び出される側の準備だ。任意の標準モジュール（例：`modCore`）に、外部から呼び出されるプロシージャを配置する。
Option Explicit
‘ =================================================================
‘ 共通ライブラリ側モジュール: modCore
‘ =================================================================
Public Function ExecuteComplexProcess(ByVal targetSlide As Slide, ByVal configValue As String) As Boolean
On Error GoTo ErrorHandler
‘ デバッグ用ログ（実際にはファイル出力やDB連携に置き換え可能）
Debug.Print “共通ライブラリが実行されました。設定値: ” & configValue
‘ 例として、受け取ったスライドにシェイプを動的生成する処理
Dim shp As Shape
Set shp = targetSlide.Shapes.AddTextbox(msoTextOrientationHorizontal, 100, 100, 400, 50)
shp.TextFrame.TextRange.Text = “Processed by CommonLibrary: ” & configValue
shp.TextFrame.TextRange.Font.Size = 18
ExecuteComplexProcess = True
Exit Function
ErrorHandler:
‘ 呼び出し元へエラーを伝播させるための処理
MsgBox “共通ライブラリ内でエラー発生: ” & Err.Description, vbCritical
ExecuteComplexProcess = False
End Function
② 業務ツール側 (`WorkTool.pptm`) のコントローラーコード
次に、呼び出し元である業務ツール側の標準モジュール。ここでファイルが存在するかどうかのチェック、プレゼンテーションの裏側での起動、そして `Application.Run` による安全な関数呼び出しを行う。
Option Explicit
‘ =================================================================
‘ 呼び出し元ツール側モジュール: modController
‘ =================================================================
Public Sub RunExternalLibraryProcess()
Dim libPath As String
Dim libPres As Presentation
Dim isAlreadyOpen As Boolean
Dim targetLibName As String
Dim result As Boolean
targetLibName = “CommonLibrary.pptm”
‘ 1. パスの動的解決（業務ツールと同じフォルダに共通ライブラリがあると仮定）
libPath = ThisPresentation.Path & “\” & targetLibName
‘ ファイル存在確認
If Dir(libPath) = “” {
MsgBox “必須の共通ライブラリが見つかりません。” & vbCrLf & libPath, vbCritical, “致命的エラー”
Exit Sub
}
‘ 2. 共通ライブラリがすでに開いているかチェックし、未オープンなら開く（非表示推奨）
isAlreadyOpen = False
Dim p As Presentation
For Each p In Application.Presentations
If p.Name = targetLibName Then
Set libPres = p
isAlreadyOpen = True
Exit For
End If
Next p
If Not isAlreadyOpen {
‘ 読み取り専用で安全に開く（バックグラウンド実行）
Set libPres = Application.Presentations.Open(FileName:=libPath, ReadOnly:=msoTrue, WithWindow:=msoFalse)
End If
‘ 3. Application.Run による動的メソッド呼び出し
‘ 構文: Application.Run “プレゼンテーション名!モジュール名.関数名”, 引数1, 引数2…
On Error GoTo RunError
Dim macroName As String
macroName = targetLibName & “!modCore.ExecuteComplexProcess”
‘ アクティブスライドとパラメータを渡す
Dim currentSlide As Slide
Set currentSlide = Application.ActiveWindow.View.Slide
‘ 関数の戻り値を取得
result = Application.Run(macroName, currentSlide, “Production-Ready-Param-202X”)
If result {
MsgBox “外部ライブラリの処理が正常に完了しました。”, vbInformation, “成功”
} else {
MsgBox “外部ライブラリは実行されましたが、内部で処理が失敗しました。”, vbExclamation, “警告”
}
CleanUp:
‘ 4. 自前で開いた場合は、メモリリークを防ぐために閉じる
If Not isAlreadyOpen And Not libPres Is Nothing Then
libPres.Close
End If
Exit Sub
RunError:
MsgBox “Application.Run の実行に失敗しました。” & vbCrLf & _
“エラー番号: ” & Err.Number & vbCrLf & _
“詳細: ” & Err.Description, vbCritical, “ランタイムエラー”
Resume CleanUp
End Sub
—
4. プロフェッショナルが解説する実装の急所
上記のコードを見れば分かる通り、ただ動くだけのコードとは一線を画す「実務に耐えうる設計」が施されている。
1. プレゼンテーションの重複起動防止とライフサイクル管理
`Application.Presentations.Open` を安易に叩くと、ユーザーが意図しないウィンドウが立ち上がったり、メモリ上に無駄なインスタンスが残る。コード内では 「すでに開いているか走査し、開いていなければ開き、自前で開いたものだけを終了時に閉じる（`Not isAlreadyOpen`）」 という厳密なライフサイクル管理を行っている。これがリソースリークを防ぐ定石だ。
2. `Application.Run` の文字列指定の罠
`Application.Run` の第一引数は文字列だ。
`”CommonLibrary.pptm!modCore.ExecuteComplexProcess”` のように、拡張子を含んだファイル名 をエクスクラメーションマーク（`!`）の前に記述する必要がある。ファイル名が変わると一発で動かなくなるため、変数化して管理するのがスマートなハッカーの流儀である。
3. オブジェクト参照の受け渡し
特筆すべきは、`Application.Run` を通じて `Slide` オブジェクトそのものを別プロジェクトへ渡している点 だ。VBAでは、異なるプロジェクト間であっても、適切な型（`Slide` や `Shape` など）であれば参照をそのまま渡してメソッド内で操作させることができる。これにより、高度なオブジェクト指向的アプローチが可能になる。
—
5. おわりに：組織のVBA資産を「資産」たらしめるために
マクロのコードをあちこちにコピペして回る時代は終わった。
今回紹介した `Application.Run` を軸にしたマルチプロジェクト制御をマスターすれば、あなたのチームのVBA開発は「場当たり的なスクリプト作成」から「スケーラブルなシステム開発」へと進化する。
共通ライブラリをサーバー等の共有フォルダに置き、最新版を自動チェックする仕組みを組み合わせれば、企業の業務自動化基盤は盤石なものになるだろう。
プロフェッショナルとして、保守性・拡張性の高いコードを書き続けよう。あなたの作るツールが、組織の生産性を限界突破させることを期待している。
