MS Project VBAを掌握する：ApplicationからTaskまでを迷わず操作する極限の知見
レガシーシステムの最前線、あるいは巨大なプラントやITインフラの統合スケジュール管理において、Microsoft ProjectのVBA（Visual Basic for Applications）は今なお強力な武器である。しかし、Excel VBAのノウハウのままProject VBAに挑み、オブジェクト階層の罠に沈むエンジニアを私は数多く見てきた。
Excelが「二次元配列の延長」であるならば、Projectは「動的かつ制約に満ちた時系列ネットワーク構造」である。この複雑怪奇なオブジェクトモデルを完全に手懐けることなしに、堅牢な自動化は実現しない。
今回は、`Application`から`Task`に至るまでのオブジェクト階層を正確に把握し、メモリの呪縛から逃れ、実戦で耐えうるコードを書くための極限の知見を授けよう。
—
1. Projectオブジェクトモデルの構造的真実
Projectのオブジェクト階層は、一見するとExcelに似ているが、その内部挙動は全く異なる。
Application
└─ Project (ActiveProject / Projects)
├─ Task (Tasks / OutlineChildren)
└─ Resource (Resources)
このツリー構造において、最大の罠は「アクティブコンテキストへの依存」と「遅延バインディング・早期バインディングの選定ミス」にある。Excelのように漫然と `ActiveCell` や `ActiveProject` を叩くコードは、マルチプロジェクト環境やバックグラウンド処理において確実に爆発する。
階層を迷わず渡り歩くための鉄則
- `Application`: 常にグローバルなスコープ、およびウィンドウやアプリケーション全体の設定を握る。
- `Project`: 複数のプロジェクトが同時に開かれる（MDI構造）ため、インデックスや名前で明示的に指定すべきである。
- `Task` / `Resource`: コレクションのインデックスは「ID（通し番号）」であり、「UniqueID（不変の識別子）」ではない。ここを混同すると、タスクの並び替えや削除時に致命的なバグを生む。
—
2. メモリ最適化とオブジェクト解放の作法
Project VBAは、COM（Component Object Model）のラップ層として動作する。特に大量のタスクを一括処理する際、オブジェクト変数を解放せずにループを回すと、メモリリークやProject自体のフリーズを引き起こす。
「VBAだから自動で解放される」という甘い考えは捨てよ。ループ内で生成・取得したオブジェクトは、明示的に `Nothing` を代入して参照カウントを落とすのがシニアエンジニアの嗜みである。
また、処理速度を極限まで引き上げるために、以下の3種の神器を必ずプロシージャの冒頭と末尾に挟むこと。
1. `ScreenUpdating = False` （画面描画の抑制）
2. `Calculation = pjCalculationManual` （自動再計算の停止）
3. エラーハンドリングによる確実な環境復元
—
3. 実践コード：階層を迷わず走査し、タスクを操作する堅牢なプロシージャ
以下に、`Application` から `Project` を経由し、特定の条件に合致する `Task` の階層を安全かつ高速に走査・操作する実用コードを示す。
このコードでは、明示的なオブジェクトの解放、`UniqueID` をベースにした安全な参照、そしてパフォーマンスチューニングを網羅している。
Option Explicit
Sub OptimizeAndTraverseTasks()
‘ —————————————————————–
‘ 処理概要:
‘ ApplicationからActiveProjectを経由して全タスクを走査し、
‘ カスタムフィールドの値を安全に更新する。
‘ メモリ解放とパフォーマンス最適化を徹底した実装例。
‘ —————————————————————–
Dim appRef As MSProject.Application
Dim prjRef As MSProject.Project
Dim tskRef As MSProject.Task
‘ パフォーマンス向上のための変数
Dim originalCalc As Long
‘ 早期バインディングを利用するため、参照設定で “Microsoft Project 16.0 Object Library” が必須
Set appRef = Application
‘ 1. 開かれているプロジェクトが存在するか検証
If appRef.Projects.Count = 0 Then
MsgBox “現在開かれているプロジェクトがありません。”, vbCritical, “エラー”
Exit Sub
End If
‘ アクティブプロジェクトの取得（必要に応じて Projects(“filename.mpp”) に変更可能）
Set prjRef = appRef.ActiveProject
‘ 2. パフォーマンス最適化の適用
On Error GoTo ErrorHandler
originalCalc = appRef.Calculation
appRef.ScreenUpdating = False
appRef.Calculation = pjCalculationManual ‘ 自動再計算を停止し、処理速度を爆発的に上げる
‘ 3. タスク階層の走査
Dim targetCount As Long
targetCount = 0
For Each tskRef In prjRef.Tasks
‘ ヌルタスク（空行や削除済みスロット）の除外
If Not tskRef Is Nothing Then
‘ サマリータスク（親タスク）ではなく、実作業タスク（かつ有効なUniqueIDを持つ）を対象とする
If Not tskRef.Summary Then
‘ 例として、テキスト1（Text1）にステータスを書き込む
‘ ※タスクのインデックスではなく UniqueID をログや外部連携のキーとして信用すること
tskRef.Text1 = “Verified by Engine_” & tskRef.UniqueID
targetCount = targetCount + 1
End If
End If
‘ 【極限の知見】ループ内でのオブジェクト使い回しによるメモリ肥大化を防ぐため、
‘ 必要に応じて個別の解放はできないが、ループ脱出後に親を解放する。
Next tskRef
‘ 4. 変更の確定と手動再計算の実行
appRef.Calculate
MsgBox “処理が完了しました。更新されたタスク数: ” & targetCount, vbInformation, “完了”
CleanUp:
‘ 5. 環境の確実な復元とメモリ解放
On Error Resume Next
appRef.Calculation = originalCalc
appRef.ScreenUpdating = True
‘ オブジェクト変数の明示的解放（COM参照の切断）
Set tskRef = Nothing
Set prjRef = Nothing
Set appRef = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “致命的エラー”
Resume CleanUp
End Sub
—
4. チーフアーキテクトからの提言：レガシー連携とAPIの限界
Project VBAを使用する上で、避けて通れないのが外部システム（ERPや基幹DB、Excelダッシュボード）との連携である。
- 遅延バインディングの罠: `CreateObject(“MSProject.Application”)` を用いた外部からの操作は、プロセスが背後で残りやすく、ゾンビプロセスの温床となる。外部VBScriptや他アプリから操作する場合は、必ず最後に対象の `Quit` メソッドと変数への `Nothing` 代入を徹底しタスクマネージャーを汚染しないこと。
- エンタープライズ環境（Project Server / Project Online）: ローカルMppファイルと異なり、サーバー側のエンタープライズリソースプールやチェックアウト/チェックインの概念が絡む。VBAからこれらを操作する場合、単純なオブジェクト操作だけでなく、PJLPAやPWAのREST API、あるいはCSOM（Client Object Model）への移行を視野に入れるべき過渡期にあることを忘れてはならない。
オブジェクトモデルの階層を正確に理解し、メモリとコンテキストを支配した者だけが、Project VBAを真の自動化ツールとして使いこなすことができる。日々の保守・開発において、上記の知見が貴プロジェクトの羅針盤となることを願う。
