Project VBAを掌握せよ：パスワード保護されたMPPファイルの「無人開削」と極限のエラーハンドリング
Project VBAの深淵へようこそ。
もし君が、MS Projectの自動化において「パスワード付きファイルを開く際にダイアログがポップアップし、自動化プロセスが永久停止する」という悪夢を経験したことがないのなら、それはまだ幸運なだけだ。GUIの背後で蠢くCOMオブジェクトは、期待通りに動かない。特にパスワード保護されたMPPファイルは、正しくハンドリングしなければ、アプリケーションのハングアップを誘発する地雷原となる。
今日は、場当たり的なコードではなく、システムアーキテクトの視点から「堅牢なプロジェクト自動オープン」の設計図を提示しよう。
—
1. 認証プロセスの深層：なぜ「ただ開く」だけではいけないのか
`Project.Application.FileOpen` メソッドには、パスワードを渡すための引数が用意されている。しかし、ドキュメント通りに引数を設定しても、環境やProjectのバージョン、あるいはバックグラウンドで動いているインスタンスの干渉により、認証エラーや予期せぬプロンプトが発生することがある。
ここで重要なのは、「GUIを抑制した状態でのファイルアクセス」と「エラーハンドリングの多重化」だ。
2. 実装の要諦：堅牢なオープン・メソッドの構築
以下のコードは、単なる実装例ではない。メモリリークを許さず、認証失敗をロジックで制御するための「防弾アーキテクチャ」である。
‘ @description: パスワード保護されたプロジェクトファイルを安全に開くための堅牢な実装
‘ @note: Projectオブジェクトの明示的な解放と、On Errorによる制御が不可欠
Public Function OpenSecureProject(ByVal filePath As String, ByVal password As String) As Project
Dim prjApp As MSProject.Application
Dim targetProject As Project
‘ プロセスの二重起動を避けるため、既存のApplicationを再利用するか、新規に生成するかは
‘ システムの要件に応じて決定せよ。ここでは新規インスタンス生成を想定。
Set prjApp = New MSProject.Application
‘ GUIを非表示にすることで、不意のプロンプトによるUIロックを回避する
prjApp.Visible = False
On Error GoTo ErrorHandler
‘ FileOpenの引数は非常にシビアである。
‘ ReadOnly等の設定はシステムの目的に応じて調整せよ。
prjApp.FileOpen Name:=filePath, Password:=password
Set targetProject = prjApp.ActiveProject
Set OpenSecureProject = targetProject
Exit Function
ErrorHandler:
‘ 認証失敗時はErr.Numberでトラップし、ログに詳細を残す
‘ 0x80040401等の認証エラーをここで握りつぶさないこと。
Debug.Print “Critical Error: ” & Err.Description
‘ クリーンアップ処理へ
If Not prjApp Is Nothing Then
prjApp.Quit
Set prjApp = Nothing
End If
Err.Raise vbObjectError + 1001, “OpenSecureProject”, “プロジェクトファイルのオープンに失敗しました。”
End Function
3. レガシー環境とメモリ最適化の真髄
シニアエンジニアであれば理解しているはずだが、VBAにおける `Set Object = Nothing` は単なる儀式ではない。ProjectのCOMオブジェクトはメモリ上に巨大なインスタンスを構築する。
- 遅延バインディングの誘惑を捨てろ: 開発時は `MSProject` ライブラリを参照設定し、アーリーバインディングを使用せよ。型安全性はバグを減らすための最初の防壁だ。
- バックグラウンドプロセスを殺せ: `prjApp.Quit` を呼び出した後も、ゾンビプロセスが残ることがある。その場合は `TaskKill` コマンドをWindows API（`Shell`関数経由）で叩き込む必要がある。これが「現場の知見」というやつだ。
‘ ゾンビプロセスを抹殺する最終手段
Private Sub KillProjectProcess()
Shell “taskkill /F /IM WINPROJ.EXE”, vbHide
End Sub
4. システム間連携における「待ち時間」の設計
API経由でファイルを開く際、ファイルサイズが大きいと `FileOpen` が完了する前に後続のコードが走ろうとする。`DoEvents` を連打するのは素人のやり方だ。
真のエンジニアは、`Application.Calculation` や `Project.IsReadOnly` などの状態が確定するまで、適切なループで待機（ポーリング）を行う。状態が確定しないまま無理やり操作を強行すれば、プロジェクトファイルは容易に破損する。
総括
VBAはレガシーと言われるが、その背後にあるCOMの仕組みは現在もWindowsエコシステムの基盤だ。パスワード付きファイルを開くという単純なタスク一つとっても、「エラーを制御する」のではなく「エラーが発生し得ない状況をコードで構築する」という設計思想が重要となる。
君たちがこれから構築する自動化システムが、夜間に無人で走り続け、翌朝には完璧なベースラインとレポートを生成していることを期待する。
技術は裏切らない。ただ、書き手の手抜きを許さないだけだ。
