【テクニカル・上級編】【上級者向け】Project VBAにおけるカスタムフィールド操作のメモリリーク対策 – Project VBA解析バイブル

Project VBA

2026.11.13

Project VBAにおける「メモリの深淵」：大規模カスタムフィールド操作における極限のメモリ管理術
If VBA7 Then
Else
End If
1. 4. アーキテクトの視点：システム間連携における注意点
2. まとめ

Project VBAにおける「メモリの深淵」：大規模カスタムフィールド操作における極限のメモリ管理術

大規模なプロジェクトスケジュールを扱うエンジニアにとって、MS Projectの自動化は強力な武器となる。しかし、数万件のタスクやリソースを抱えるエンタープライズ環境において、その武器が「メモリリーク」という名の鈍器に変わる瞬間を、私は何度も目にしてきた。

「少量のデータでは動く。しかし、本番環境の巨大なファイルではProjectが応答なしになる、あるいはメモリを食いつぶしてクラッシュする。」

もし君がこの問題に直面しているなら、それは君のロジックが間違っているのではなく、COM（Component Object Model）のライフサイクルと、Projectの計算エンジンに対する理解が不足しているということだ。

本稿では、カスタムフィールド（Task/Resource）の定義と計算式を大量のオブジェクトに対して適用する際、いかにしてメモリの断片化を防ぎ、システムを極限まで安定させるか。その真髄を解説する。

1. COM参照カウントの罠：なぜ `Set obj = Nothing` だけでは足りないのか

VBAは、内部的にはCOMオブジェクトを操作している。オブジェクトが生成されるたびに「参照カウント」がインクリメントされ、それがゼロになった時に初めてメモリが解放される。

しかし、MS Projectのような複雑なアプリケーションにおいて、`Task` オブジェクトや `Resource` オブジェクトは、単独で存在しているわけではない。それらは `Tasks` コレクション、`ActiveProject` オブジェクト、そして計算エンジン（Calculation Engine）と密接に、かつ複雑に絡み合っている。

致命的なアンチパターン

大量のタスクをループで処理する際、以下のようなコードを書いていないか？

' 【警告】典型的なメモリリークを誘発するコード
Dim t As Task
For Each t In ActiveProject.Tasks
    If Not t Is Nothing Then
        t.Text1 = "Processed" ' カスタムフィールドへの書き込み
    End If
Next t
' ループ終了後、t の参照が残っている可能性がある

このコードの問題は、`For Each` イテレータが内部的に保持するポインタと、変数のスコープが、大規模なループにおいて「解放の遅延」を引き起こす点にある。特に、カスタムフィールドの値を書き換える操作は、Project内部で「再計算フラグ」を立てるため、オブジェクトの生存期間が計算エンジンによって不当に引き延ばされるケースがある。

2. 極限の最適化戦略：明示的解放とインデックス制御

メモリ使用量を最小化するための鉄則は、「オブジェクトの生存期間を、その用途の最小単位にまで絞り込むこと」である。

戦略1：インデックスベースのループ

`For Each` は便利だが、内部的なイテレータオブジェクトを生成する。メモリの極限を攻めるなら、インデックスを用いた `For` ループを使用し、各ステップでオブジェクト参照を完全に切り離すべきだ。

戦略2：Windows APIによるワーキングセットの強制整理

VBA単体では、OSレベルのメモリ管理（Working Set）を制御することはできない。しかし、Windows APIの `EmptyWorkingSet` を呼び出すことで、アプリケーションが確保している物理メモリをOSに返却するよう促すことができる。これは、バッチ処理のような「一度限りの大規模処理」において極めて有効だ。

3. 実装：プロフェッショナル・メモリ管理モジュール

以下に、大規模なカスタムフィールド更新を安全に行うための、実戦的なコード例を示す。

Option Explicit

' Windows APIの宣言：メモリの物理的な整理を行うためのもの
' プロジェクトのメモリ使用量が膨れ上がった際、OSにメモリを返却させる。
If VBA7 Then
    Declare PtrSafe Function EmptyWorkingSet Lib "psapi.dll" (ByVal hProcess As LongPtr) As Long
    Declare PtrSafe Function GetCurrentProcess Lib "kernel32" () As LongPtr
Else
    Declare Function EmptyWorkingSet Lib "psapi.dll" (ByVal hProcess As Long) As Long
    Declare Function GetCurrentProcess Lib "kernel32" () As Long
End If

''' <summary>
''' 大規模タスク集合に対してカスタムフィールドを安全に更新する
''' </summary>
Public Sub OptimizeCustomFieldUpdate()
    Dim pj As Project
    Dim t As Task
    Dim i As Long
    Dim taskCount As Long
    
    On Error GoTo ErrorHandler
    
    Set pj = ActiveProject
    taskCount = pj.Tasks.Count
    
    ' 高速化のための設定：計算を一時停止する
    ' これを行わないと、1件書き換えるたびに全プロジェクトの再計算が走り、
    ' メモリとCPUを無駄に消費する。
    pj.Calculation = pjCalculationManual
    
    Debug.Print "Processing started: " & taskCount & " tasks."

    ' 戦略1: インデックスベースのループによるオブジェクト管理
    For i = 1 To taskCount
        ' オブジェクトの取得
        Set t = pj.Tasks(i)
        
        ' Nothingチェックは必須
        If Not t Is Nothing Then
            ' カスタムフィールド（Text1）への書き込み操作
            ' ここで複雑なロジックを挟む場合も、t の参照範囲を最小限にする
            t.Text1 = "ID_" & i & "_VAL"
            
            ' --- 重要なプロセス ---
            ' 処理の途中で、不要になったオブジェクト参照を明示的に解放
            Set t = Nothing
        End If
        
        ' 数千件ごとにメモリの断片化を防ぐためにAPIを呼び出す
        ' (頻度が高すぎるとオーバーヘッドになるため、一定の間隔で行う)
        If i Mod 5000 = 0 Then
            Call ReleaseProcessMemory
            Debug.Print i & " tasks processed... Memory cleared."
        End If
    Next i

    ' 最後に計算を再開し、結果を反映させる
    pj.Calculation = pjCalculationAutomatic
    Debug.Print "Processing completed successfully."

CleanUp:
    Set t = Nothing
    Set pj = Nothing
    Exit Sub

ErrorHandler:
    MsgBox "Critical Error: " & Err.Description, vbCritical
    Resume CleanUp
End Sub

''' <summary>
''' OSレベルでプロセスのワーキングセットを整理する
''' </summary>
Private Sub ReleaseProcessMemory()
    On Error Resume Next
    ' 現在のプロセスハンドルを取得し、メモリを整理
    Call EmptyWorkingSet(GetCurrentProcess())
    On Error GoTo 0
End Sub

4. アーキテクトの視点：システム間連携における注意点

もし君が、VBAから外部の .NET アプリケーションや Python スクリプト経由で Project を操作しているなら、問題はさらに複雑になる。

COMオブジェクトを外部プロセスから操作する場合、「親プロセスが死んでも、子プロセス（MS Project）にオブジェクトの参照が残っているために Project.exe がタスクマネージャーに残る」という現象が頻発する。これは、参照カウントが適切にデクリメントされず、Projectが「まだ誰かが自分を使っている」と誤認するためだ。

この場合、VBA側での `Set obj = Nothing` はもちろんのこと、呼び出し側のラッパー（Wrapper）層においても、オブジェクトのライフサイクルを厳格に管理（`using` ブロックの徹底など）する必要がある。

まとめ

MS Project VBAにおける大規模処理の成功は、コードの「美しさ」ではなく、メモリの「管理能力」にかかっている。

1. 計算モードの制御: `pjCalculationManual` を使い、計算エンジンの暴走を抑える。
2. 参照の局所化: `For Each` を避け、インデックス制御と明示的な `Set = Nothing` を徹底する。
3. OSとの対話: 極限の状況下では Windows API を用い、物理メモリを強制的に整理する。

これらを遵守することで、君のシステムは、数万のタスクを抱える巨大なプロジェクトにおいても、揺るぎない安定性を発揮するだろう。

技術に妥協は許されない。