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

Project VBA

2026.11.13

【極限の知見】Project VBAにおけるカスタムフィールド操作と、大量データ処理を完遂させるためのメモリ管理術

【極限の知見】Project VBAにおけるカスタムフィールド操作と、大量データ処理を完遂させるためのメモリ管理術

大規模なプロジェクト管理を行っている現場では、数千、時には数万のタスクやリソースを扱うことが珍しくない。その際、業務ロジックの要となるのがカスタムフィールド（Text1〜Text30, Number1〜Number30等）への値の書き込み、あるいはそれらを用いた高度な計算処理だ。

しかし、多くの開発者が陥る罠がある。それは、「動けば良い」という思考に基づいた、オブジェクトのライフサイクルを無視したコーディングだ。

ループ処理の中でカスタムフィールドを更新する際、メモリ使用量が指数関数的に増大し、最終的にMicrosoft Projectが「応答なし」に陥る、あるいは強制終了する。これは単なるバグではない。COM（Component Object Model）オブジェクトの参照管理を理解していないことによる、設計上の欠陥である。

本稿では、伝説的なアーキテクトの視点から、Project VBAにおけるメモリリークを回避し、極めて堅牢かつ高速なカスタムフィールド操作を実現するための設計思想を伝授する。

1. なぜ「単純なループ」がメモリを食いつぶすのか

Project VBAは、COM技術の上に構築されている。VBAからProjectのプロパティやメソッドにアクセスするたびに、VBAとProjectの間の「境界線」を越えるオーバーヘッドが発生する。

特に、以下のような書き方は、大規模データにおいて「死」を意味する。

致命的なアンチパターン

' ❌ 避けるべき設計：ループ内でオブジェクトを頻繁に参照・生成する
For Each t In ActiveProject.Tasks
    If Not t Is Nothing Then
        ' ループ内で毎回 Application や ActiveProject にアクセスするのは極めて重い
        ' また、外部オブジェクト（ADOやExcel等）をここで生成するとメモリリークの温床になる
        t.Text1 = "Processing..." 
    End If
Next t

# なぜこれが問題なのか？

1. プロパティアクセスのオーバーヘッド: `ActiveProject.Tasks` という階層をループのたびに辿ることは、COMの参照カウントを不必要に操作し続ける行為だ。
2. 参照の残留: ループ内で外部ライブラリ（例：`Scripting.Dictionary` や `ADODB.Recordset`）をインスタンス化し、適切に `Set = Nothing` しないと、メモリ上に「幽霊オブジェクト」が残り続け、Projectのメモリ空間を圧迫する。
3. 再計算の連鎖: カスタムフィールドの値を書き換えるたびに、Projectはプロジェクト全体のスケジュール再計算を試みることがある。これがメモリ消費とCPU負荷を爆発させる。

2. アーキテクトが実践する「メモリ最適化」の3原則

堅牢なツールを作るためには、以下の3原則を設計段階から組み込む必要がある。

原則I：オブジェクトの局所化とキャッシュ

`Application` や `ActiveProject` は、ループの直前でローカル変数に格納（キャッシュ）せよ。これにより、COMの階層探索を最小限に抑えることができる。

原則II：外部データのメモリ内展開（In-Memory Processing）

データベースやExcelからデータを取得する場合、「ループの中でSQLを投げる」「ループの中でExcelを開く」ことは厳禁だ。一度すべてのデータをメモリ上のコレクション（`Scripting.Dictionary` 等）に展開し、Projectの操作はメモリ内のデータとの照合のみに集中させる。

原則III：明示的なライフサイクル管理

「VBAが終了すれば解放される」という甘い考えを捨てろ。`On Error` ハンドラを実装し、エラー発生時であっても必ず `Set obj = Nothing` を通る経路を確保すること。これがプロダクションコードの「作法」である。

3. プロダクション・クオリティのコード実装例

以下に、大量のタスクに対し、外部のマスターデータ（Dictionaryに格納済みと想定）に基づいてカスタムフィールドを更新する、実戦的なコードを示す。

Option Explicit

''' <summary>
''' 大量のタスクに対してカスタムフィールドを一括更新する。
''' メモリリークを防止し、高速な処理を実現する設計。
''' </summary>
Public Sub UpdateTaskCustomFields()
    ' --- 1. オブジェクトの宣言 ---
    Dim pjApp As MSProject.Application
    Dim proj As MSProject.Project
    Dim t As MSProject.Task
    Dim dictMaster As Object ' Scripting.Dictionary
    Dim key As Variant
    
    ' 外部参照用の変数（メモリリーク対策として明示的に宣言）
    Dim errorOccurred As Boolean
    
    ' --- 2. 環境の初期化 ---
    Set pjApp = MSProject.Application
    Set proj = pjApp.ActiveProject
    Set dictMaster = CreateObject("Scripting.Dictionary")
    
    ' 画面更新の停止（Projectの描画負荷を軽減）
    pjApp.ScreenUpdating = False
    
    On Error GoTo ErrorHandler

    ' --- 3. 事前準備：外部データのメモリ展開 ---
    ' 本来はここでDBやExcelからデータを読み込む。
    ' ループ内でDBアクセスを行うのは「設計ミス」である。
    dictMaster.Add "TASK-001", "High Priority"
    dictMaster.Add "TASK-002", "Medium Priority"
    ' ... (数千件のデータをここに展開)

    ' --- 4. メイン処理：キャッシュされたオブジェクトへのアクセス ---
    ' ActiveProject.Tasks を何度も参照せず、proj.Tasks を使用
    For Each t In proj.Tasks
        ' Nothingチェックは必須（空のタスクトップ行対策）
        If Not t Is Nothing Then
            ' Dictionaryからの高速検索
            ' Task ID または Task Name をキーにする
            Dim taskKey As String
            taskKey = t.ID ' IDベースの方が高速かつ確実
            
            ' 文字列連結などの演算を行う場合も、最小限のプロパティアクセスに留める
            If dictMaster.Exists(taskKey) Then
                ' カスタムフィールドへの書き込み
                t.Text1 = dictMaster(taskKey)
            End If
        End If
        
        ' 大規模ループの場合、一定件数ごとにDoEventsを挟むことも検討するが、
        ' 速度を優先する場合は極力避ける。
    Next t

    MsgBox "更新が完了しました。", vbInformation

CleanUp:
    ' --- 5. 徹底したメモリ解放（ここが最も重要） ---
    On Error Resume Next
    
    ' Dictionaryの解放
    If Not dictMaster Is Nothing Then
        dictMaster.RemoveAll
        Set dictMaster = Nothing
    End If
    
    ' Projectオブジェクトの解放
    Set t = Nothing
    Set proj = Nothing
    Set pjApp = Nothing
    
    ' 設定の復元
    pjApp.ScreenUpdating = True
    Exit Sub

ErrorHandler:
    errorOccurred = True
    MsgBox "致命的なエラーが発生しました: " & Err.Description, vbCritical
    Resume CleanUp
End Sub

4. 実務における高度な注意点

データベース（ADO）連携時の罠

もし、タスクの更新にSQLを使用する場合、`ADODB.Recordset` を `For Each t In Tasks` の中に記述してはならない。

Bad: `Loop { Open Connection; Select; Update; Close; }`
Good: `Open Connection; Load All to Dictionary; Loop { Update via Dictionary }; Close Connection;`

この差が、処理時間を「数時間」から「数秒」へと変える。

カスタムフィールドの型（Type）の不一致

`Number1` に文字列を、`Text1` にオブジェクトを入れようとすると、COMエラーが発生し、エラーハンドラが適切に機能していない場合、プロセスがメモリを掴んだまま死ぬ。カスタムフィールドのデータ型と、代入する値の型を厳格に一致させる設計を徹底せよ。

結論

Project VBAにおける自動化ツールの価値は、「動くこと」ではなく「どのようなデータ量、どのような異常系においても、安定して、予測可能なパフォーマンスを発揮すること」にある。

オブジェクトのライフサイクルを制御し、COMのオーバーヘッドを最小化する。この当たり前の、しかし極めて高度な規律を守ることこそが、一流のエンジニアと、単なる「マクロ作成者」を分かつ境界線である。