【テクニカル・上級編】【上級プロ向け】COMオブジェクトの参照リークとゾンビプロセスの完全撲滅！巨大なCDRファイルを何千個も安全に連続バッチ処理するメモリ管理設計と例外処理 – CorelDRAW VBA解析バイブル

【上級プロ向け】CorelDRAW VBAによるCOMオブジェクト参照リークとゾンビプロセス撲滅：数千CDR連続バッチ処理のためのメモリ管理と例外処理の極意

長年、CorelDRAW VBAと格闘してきた諸君。特に、幾千、幾万というCDRファイルを一括で処理するバッチ処理システムを構築・保守してきた者ならば、あの忌々しい「メモリリーク」と、それに起因する「ゾンビプロセス」の悪夢に何度となく遭遇してきたはずだ。単にファイルを変換するだけの簡単なスクリプトであれば、些細な問題かもしれない。しかし、それがビジネスの根幹を支えるシステムとなれば、話は別だ。一回のバッチ処理で数百MB、時にはGB単位のメモリを平然と食いつぶし、最終的にはCorelDRAWプロセスが応答不能に陥り、システム全体を巻き込んでクラッシュさせる。この悪夢を、私は数えきれないほどの現場で目撃し、そして打ち破ってきた。

本稿は、単なるAPIリファレンスの羅列ではない。CorelDRAW VBA、ひいてはCOMオブジェクトモデルの深淵に潜む、オブジェクトのライフサイクル、メモリ管理の真髄、そしてレガシーシステムを支えるための堅牢な例外処理設計について、私の長年の経験と実践に基づいた「極限の知見」を、一切の装飾なく、淡々と、しかし圧倒的な精度で解説する。読者層は、既にCorelDRAW VBAに習熟し、より高度な、商用レベルで通用するシステム開発を目指すシニアエンジニア、あるいは社内システムを長年保守・運用してきたシステム管理者諸氏を想定している。Windows APIの呼び出し、COMオブジェクトの明示的な解放、そして「Errオブジェクト」を徹底的に監視し、システムを安定稼働させるための設計思想を、共に深掘りしていこう。

1. CorelDRAW VBAにおけるメモリリークの正体：COMオブジェクトの「参照カウント」という名の悪夢

まず、CorelDRAW VBAにおけるメモリリークの根本原因を理解することから始めよう。CorelDRAWは、その強力な描画機能の多くをCOM (Component Object Model) オブジェクトに依存している。VBAからCorelDRAWの機能を利用する際、我々はこれらのCOMオブジェクトを生成し、操作している。

COMオブジェクトは、その「参照カウント」によってライフサイクルが管理されている。オブジェクトが生成されると参照カウントは1になり、そのオブジェクトを参照するものが現れるたびにカウントが増加し、参照が解除されるたびにカウントが減少する。参照カウントが0になった時点で、オブジェクトはメモリから解放される、というのが理想的な挙動だ。

しかし、VBAにおいては、この参照カウントの管理に落とし穴が潜んでいる。特に、コレクションオブジェクトや、メソッドの戻り値として返されるオブジェクト、あるいはプロパティとして取得されるオブジェクトなどは、意図せず参照が残り続けてしまうことがある。これが「参照リーク」だ。参照リークが発生すると、オブジェクトはメモリから解放されず、徐々にメモリ使用量が増加していく。これが、長時間のバッチ処理でCorelDRAWがメモリを食いつぶす直接的な原因となる。

1.1. ゾンビプロセスとは何か？

参照リークが進行し、CorelDRAWプロセスが過剰なメモリを消費し続けると、Windowsのメモリ管理機能や、CorelDRAW自身の内部的なリソース管理が破綻をきたす。結果として、プロセスは応答しなくなり、タスクマネージャー上では「実行中」でありながら、一切の操作を受け付けない「ゾンビプロセス」と化す。これを手動で終了させなければ、次の処理に進むことはできない。

1.2. VBAにおける参照リークの典型的なパターン

• コレクションオブジェクトの不適切な解放: `ShapeRange` や `Layer` などのコレクションオブジェクトをループ処理する際に、ループ終了後もコレクションオブジェクトへの参照が残ってしまう。
• メソッドの戻り値: `ActiveDocument.Layers.Add()` のように、メソッドの戻り値として生成されたオブジェクトへの参照が、変数に代入されずに解放されない。
• プロパティの取得: オブジェクトのプロパティとして取得したオブジェクトが、その親オブジェクトの解放後もメモリに残り続ける。
• イベントハンドラ: イベントハンドラ内で生成されたオブジェクトが、イベントハンドラの実行終了後も参照され続ける。

2. ゾンビプロセス撲滅のためのメモリ管理設計：オブジェクトの明示的解放と「Nothing」の哲学

参照リークによるゾンビプロセスを撲滅するためには、VBAにおけるオブジェクトのライフサイクル管理を、より能動的かつ厳格に行う必要がある。単にコードを記述するだけでなく、「オブジェクトがいつ、どこで、どのように解放されるべきか」という哲学を持つことが重要だ。

2.1. 「Nothing」代入による明示的な解放

VBAにおいて、COMオブジェクトへの参照を明示的に解放する最も基本的な方法は、そのオブジェクト変​​数に `Nothing` を代入することだ。

‘ オブジェクト変数宣言
Dim myShape As Shape
Dim myShapes As ShapeRange

‘ オブジェクトへの参照を生成（例）
Set myShape = ActivePage.CreateRectangle(10, 10, 50, 50)
Set myShapes = ActivePage.Shapes.All

‘ — ここで myShape や myShapes を使用 —

‘ オブジェクトへの参照を明示的に解放
Set myShape = Nothing
Set myShapes = Nothing

この `Set obj = Nothing` は、単に変数からオブジェクトへの参照を解除するだけでなく、そのオブジェクトの参照カウントを減少させる。参照カウントが0になれば、COMオブジェクトは自動的にメモリから解放される。

2.2. オブジェクト解放のタイミング：スコープとライフサイクル

オブジェクトをいつ `Nothing` にすべきか？ これは、そのオブジェクトのスコープ（変数の有効範囲）と、本来のライフサイクルを考慮して決定する。

• ローカル変数: サブルーチンや関数内で宣言されたローカル変数は、そのサブルーチン/関数の実行が終了すると自動的に解放される。しかし、その前に `Nothing` を代入することで、より早期にメモリを解放し、リークのリスクを低減できる。
• グローバル変数/モジュールレベル変数: これらは、VBAプロジェクト全体、あるいはモジュール全体で有効であるため、意図しない参照が残りやすい。バッチ処理のような長時間実行される処理では、これらの変数が保持するオブジェクトは特に注意深く管理する必要がある。処理の各ステップの完了時点で、不要になったオブジェクトは積極的に `Nothing` に設定する。

2.3. コレクションオブジェクトの取り扱い

`ShapeRange` や `Layers` などのコレクションオブジェクトは、特に参照リークの原因になりやすい。

‘ 悪い例：ループ終了後も myShapes への参照が残る可能性がある
Dim myShapes As ShapeRange
Set myShapes = ActivePage.Shapes.All

For Each shp In myShapes
‘ 何らかの処理
Next shp
‘ ここで myShapes が必要なくなっても、明示的に解放しないとリークの原因に
Set myShapes = Nothing ‘ ← これが重要

ループ処理でコレクションを扱う場合、ループの各イテレーションで生成される一時的なオブジェクト（例えば、`shp` 変数）も、そのスコープを意識して管理する必要がある。

‘ 改善例
Dim myShapes As ShapeRange
Set myShapes = ActivePage.Shapes.All

Dim shp As Shape ‘ ループ変数はループ内で宣言・解放される
For Each shp In myShapes
‘ 何らかの処理
Set shp = Nothing ‘ 各イテレーションで解放（場合による）
Next shp

‘ ループ処理が終わったら、コレクション自体も解放
Set myShapes = Nothing

ただし、ループ変数を毎回 `Nothing` にするのは、パフォーマンス上のオーバーヘッドも考慮する必要がある。通常は、ループ変数自体はスコープで管理され、コレクションオブジェクト本体を処理の終わりに `Nothing` にすることが主眼となる。

2.4. `CreateObject` と `GetObject` の注意点

外部COMオブジェクトを生成する `CreateObject` や、既存のCOMオブジェクトを取得する `GetObject` を使用する場合も、同様に `Nothing` による解放を徹底する必要がある。

Dim cdApp As Object
On Error Resume Next ‘ エラー発生時も処理を続行
Set cdApp = GetObject(, “CorelDRAW.Application”)
If Err.Number <> 0 Then
‘ CorelDRAWが起動していない場合、新規に起動
Set cdApp = CreateObject(“CorelDRAW.Application”)
End If
On Error GoTo 0 ‘ エラーハンドリングを元に戻す

If cdApp Is Nothing Then
MsgBox “CorelDRAWを起動できませんでした。”, vbCritical
Exit Sub
End If

‘ — CorelDRAW操作 —

‘ 処理完了後、CorelDRAWプロセスへの参照を解放
Set cdApp = Nothing

この例では、`GetObject` で既存のCorelDRAWプロセスへの参照を取得し、それが失敗した場合は `CreateObject` で新規に起動しています。重要なのは、処理が完了したら `Set cdApp = Nothing` で参照を解放することです。これにより、VBAスクリプトが終了しても、CorelDRAWプロセスがメモリ上に残り続ける（ゾンビ化する）のを防ぎます。

3. Windows APIによるメモリ解放の補助とプロセス管理

VBAの `Set obj = Nothing` だけでは、COMオブジェクトの参照カウントを完全に制御しきれない場合や、より積極的なメモリ解放を行いたい場合に、Windows APIの出番となる。

3.1. `GlobalAlloc` / `GlobalFree` と `CoTaskMemAlloc` / `CoTaskMemFree`

COMオブジェクトのメモリ管理は、COMライブラリ自体が行うが、VBAのオブジェクト変数が参照するメモリ領域を直接操作するAPIは存在しない。しかし、COMオブジェクトが内部で使用するメモリバッファなどを管理するために、これらのAPIが間接的に関わってくる場合がある。

一般的に、COMオブジェクトは `CoTaskMemAlloc` / `CoTaskMemFree` を使用してメモリを割り当て・解放する。VBAの `Set obj = Nothing` は、これらのCOM APIを適切に呼び出すように設計されているはずだが、複雑なオブジェクトグラフや、外部ライブラリとの連携においては、予期せぬ挙動を示すことがある。

3.2. `EnumProcessModules` と `GetModuleMemoryInfo` (応用編)

これは非常に高度なテクニックであり、CorelDRAW VBAの範疇をやや超えるが、プロセスのメモリ使用量を詳細に把握したい場合に有効だ。Windows APIを使用して、特定のプロセスのモジュール情報を列挙し、各モジュールのメモリ使用量を把握することで、メモリリークの兆候を早期に検知できる。

‘ Declare statements for Windows API (e.g., for EnumProcessModules, GetModuleInformation)
‘ These would typically be in a separate module.
‘ Example (simplified):
‘ Public Declare Function OpenProcess Lib “kernel32” (ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessId As Long) As Long
‘ Public Declare Function EnumProcessModules Lib “psapi.dll” (ByVal hProcess As Long, ByVal lphModule As Long, ByVal cbNeeded As Long, ByRef lpcbNeeded As Long) As Long
‘ Public Declare Function GetModuleBaseName Lib “psapi.dll” Alias “GetModuleBaseNameA” (ByVal hProcess As Long, ByVal hModule As Long, ByVal lpBaseName As String, ByVal nSize As Long) As Long
‘ Public Declare Function GetModuleInformation Lib “psapi.dll” (ByVal hProcess As Long, ByVal hModule As Long, lpmodinfo As Any, ByVal cb As Long) As Long
‘
‘ Public Type MODULEINFO
‘ lpBaseOfDll As Long
‘ dwSizeOfImage As Long
‘ lpEntry Point As Long
‘ End Type

Sub CheckCorelDRAWMemoryUsage()

Dim processID As Long
Dim hProcess As Long
Dim hModule(100) As Long ‘ Array to hold module handles
Dim cbNeeded As Long
Dim moduleInfo As MODULEINFO
Dim moduleName As String
Dim totalMemory As Long

‘ CorelDRAWプロセスのIDを取得（タスクマネージャーなどから手動で確認するか、プロセス管理APIを使用）
‘ ここでは例としてIDを直接指定しますが、実際にはプロセス名から検索するAPIを使うべきです。
processID = 1234 ‘ 仮のプロセスID

‘ プロセスハンドルを取得
‘ hProcess = OpenProcess(PROCESS_QUERY_INFORMATION Or PROCESS_VM_READ, False, processID)
‘ If hProcess = 0 Then
‘ MsgBox “CorelDRAWプロセスのハンドルを取得できませんでした。エラーコード: ” & Err.LastDllError
‘ Exit Sub
‘ End If

‘ ‘ モジュールの情報を取得
‘ If EnumProcessModules(hProcess, VarPtr(hModule(0)), Len(hModule) 4, cbNeeded) Then
‘ Dim i As Long
‘ For i = 0 To (cbNeeded \ 4) – 1
‘ Dim moduleBaseAddr As Long
‘ Dim moduleSize As Long
‘ Dim moduleInfoSize As Long
‘
‘ ‘ モジュール名を取得（省略）
‘ ‘ moduleName = GetModuleBaseName(hProcess, hModule(i), Space(255), 255)
‘
‘ ‘ モジュールのメモリ情報を取得
‘ moduleInfoSize = Len(moduleInfo)
‘ If GetModuleInformation(hProcess, hModule(i), moduleInfo, moduleInfoSize) Then
‘ moduleSize = moduleInfo.dwSizeOfImage
‘ totalMemory = totalMemory + moduleSize
‘ End If
‘ Next i
‘ End If
‘
‘ CloseHandle hProcess ‘ プロセスハンドルを閉じる
‘
‘ MsgBox “CorelDRAWプロセスの総メモリ使用量 (推定): ” & FormatNumber(totalMemory / 1024 / 1024, 2) & ” MB”

‘ 上記は概念実証であり、実際のAPI呼び出しにはWinAPIの正確な宣言とエラーハンドリングが必要です。
‘ このコードは、CorelDRAWプロセスのメモリ使用量を直接VBAから監視・管理する目的で示しています。
‘ 通常、バッチ処理の安定化においては、APIによる直接的なメモリ解放よりも、COMオブジェクトの参照管理が重要です。

End Sub

注意: 上記API呼び出しコードは、概念を示すためのものです。実際の利用には、完全なAPI宣言、エラーハンドリング、および適切なデータ型定義が必要です。また、CorelDRAWの内部的なメモリ管理は複雑であり、APIで直接操作することが常に最適解とは限りません。

3.3. `TerminateProcess` (最終手段)

どうしてもプロセスが応答しなくなった場合の最終手段として、Windows APIの `TerminateProcess` を使用して強制終了させることも考えられます。しかし、これはデータ損失のリスクを伴うため、あくまで最終手段として、かつ、処理の開始前に保存されていないデータのバックアップを取るなどの対策が必須です。

‘ Declare statement for TerminateProcess
‘ Public Declare Function TerminateProcess Lib “kernel32” (ByVal hProcess As Long, ByVal uExitCode As Long) As Long

Sub ForceCloseCorelDRAW(ByVal processID As Long)
Dim hProcess As Long

‘ プロセスハンドルを取得
‘ hProcess = OpenProcess(PROCESS_TERMINATE, False, processID)
‘ If hProcess <> 0 Then
‘ TerminateProcess hProcess, 1 ‘ 1は終了コード
‘ CloseHandle hProcess
‘ Debug.Print “CorelDRAWプロセス (ID: ” & processID & “) を強制終了しました。”
‘ Else
‘ Debug.Print “CorelDRAWプロセス (ID: ” & processID & “) の強制終了に失敗しました。エラーコード: ” & Err.LastDllError
‘ End If
End Sub

4. 堅牢な例外処理設計：`Err` オブジェクトの徹底監視

バッチ処理において、予期せぬエラーは必ず発生します。CorelDRAWの内部エラー、ファイルアクセスの問題、ディスク容量不足、さらにはOSレベルでの問題など、原因は多岐にわたります。これらのエラーを適切に捕捉し、処理を継続または安全に終了させるための「堅牢な例外処理」が、システム全体の安定稼働の鍵となります。

4.1. `On Error GoTo` による構造化されたエラーハンドリング

VBAにおける標準的なエラーハンドリングは `On Error GoTo` です。しかし、これを闇雲に使用すると、コードが読みにくくなり、エラーの伝播を制御できなくなります。

Sub ProcessFile(filePath As String)
On Error GoTo ErrorHandler ‘ エラー発生時に ErrorHandler ラベルへジャンプ

Dim doc As Document
Dim cdApp As Object ‘ CorelDRAW Application Object

‘ CorelDRAWアプリケーションオブジェクトへの参照を取得または生成
Set cdApp = GetCorelDRAWApp() ‘ 既存の関数を想定

‘ ファイルを開く
Set doc = cdApp.OpenDocument(filePath)

‘ — ファイル処理 —
‘ 例: PDFにエクスポート
‘ doc.Export “output.pdf”, cdrPDF, cdrPDFSettings

‘ 処理完了後、オブジェクトを解放
Set doc = Nothing
‘ cdApp の解放は、バッチ処理全体で一度だけ行う場合が多い

Exit Sub ‘ 正常終了時はエラーハンドラをスキップ

ErrorHandler:
‘ エラー発生時の処理
Dim errNum As Long
Dim errSev As Integer ‘ Severity (vbError, vbWarning, vbInformation)
Dim errDesc As String
Dim errSource As String

errNum = Err.Number
errDesc = Err.Description
errSource = Err.Source

‘ ログ記録やユーザーへの通知
LogErrorMessage filePath, errNum, errDesc, errSource

‘ CorelDRAWオブジェクトの参照を解放（エラー発生時も重要！）
If Not doc Is Nothing Then Set doc = Nothing
‘ cdApp の解放は、バッチ処理全体で一度だけ行う場合が多い

‘ Resume Next ‘ 次の処理へ進む（場合による）
‘ Exit Sub ‘ エラーハンドラから抜ける
End Sub

‘ CorelDRAWアプリケーションオブジェクトを取得または起動するヘルパー関数
Function GetCorelDRAWApp() As Object
Dim cdApp As Object
On Error Resume Next ‘ エラー発生時も続行
Set cdApp = GetObject(, “CorelDRAW.Application”)
If Err.Number <> 0 Then
Set cdApp = CreateObject(“CorelDRAW.Application”)
If Err.Number <> 0 Then
Err.Raise Err.Number, “GetCorelDRAWApp”, “CorelDRAWを起動できませんでした。”
End If
End If
On Error GoTo 0 ‘ エラーハンドリングを元に戻す
Set GetCorelDRAWApp = cdApp
End Function

‘ エラーログ記録関数（例）
Sub LogErrorMessage(filePath As String, errNum As Long, errDesc As String, errSource As String)
Dim logEntry As String
logEntry = Now() & vbTab & filePath & vbTab & “Error ” & errNum & “: ” & errDesc & ” (Source: ” & errSource & “)”
Debug.Print logEntry ‘ イミディエイトウィンドウに出力
‘ ファイルへの追記なども可能
End Sub

4.2. `Err` オブジェクトの徹底監視と「クリーンアップ」

`On Error GoTo` でエラーハンドラにジャンプした場合、`Err` オブジェクトにはエラー情報が格納されています。この情報を利用して、エラーの原因を特定し、適切な後処理を行います。

• `Err.Number`: エラーコード。
• `Err.Description`: エラーメッセージ。
• `Err.Source`: エラーが発生したオブジェクトまたはアプリケーション。

重要なのは、エラーハンドラから抜ける前に、必ず `Err` オブジェクトの状態をクリアすることです。 VBAでは、`Err` オブジェクトは自動的にはクリアされません。次のエラーが発生する前に、`Err.Clear` を呼び出すか、またはエラーハンドラを抜けることで、情報がリセットされます。

ErrorHandler:
‘ エラー情報を取得
errNum = Err.Number
errDesc = Err.Description
errSource = Err.Source

‘ ログ記録
LogErrorMessage filePath, errNum, errDesc, errSource

‘ オブジェクトのクリーンアップ（最重要！）
If Not doc Is Nothing Then Set doc = Nothing
‘ cdApp はバッチ処理全体で管理しているため、ここで解放しない

‘ エラーをクリア
Err.Clear

‘ Resume Next ‘ 次のファイル処理へ進む
‘ Resume ExitSub ‘ エラーハンドラを抜けて、終了処理へ

4.3. `Resume Next` と `Resume` の使い分け

• `Resume Next`: エラーが発生したステートメントの次のステートメントから処理を再開します。個々のファイル処理でエラーが発生しても、バッチ処理全体は続行させたい場合に有効です。
• `Resume`: エラーが発生したステートメントから処理を再開します。これは、エラーの原因を取り除いた後に、同じ処理を再試行したい場合に使用しますが、VBAではあまり一般的ではありません。
• `Resume ExitSub`: エラーハンドラから抜けて、現在のサブルーチン/関数を終了させます。

バッチ処理においては、`Resume Next` を使用して、エラーが発生したファイルをスキップし、次のファイル処理に進むのが最も一般的で堅牢な設計です。

4.4. CorelDRAW固有のエラーコードの理解

CorelDRAW VBAには、特定の操作で発生する固有のエラーコードが存在します。例えば、不正なファイル形式、オブジェクトのロック、リソース不足などが考えられます。これらのエラーコードを事前に調査し、エラーハンドラ内で特定のコードに基づいて処理を分岐させることで、よりきめ細やかなエラー対応が可能になります。

5. システム間連携とレガシー環境の保守：COM、ActiveX、そしてCOM+

大規模なバッチ処理システムは、しばしば他のシステムと連携したり、長年運用されてきたレガシー環境に組み込まれたりします。これらの環境では、COMオブジェクトの扱いにさらに注意が必要です。

5.1. COMコンポーネントのライフサイクル管理の重要性

CorelDRAW VBAは、CorelDRAWアプリケーションというCOMサーバーと対話しています。このCOMサーバーとのやり取りにおいて、オブジェクトの参照カウントが正しく管理されていないと、CorelDRAWプロセスだけでなく、場合によってはシステム全体に影響を及ぼす可能性があります。

• `CoCreateInstance` / `CreateObject`: 新規COMオブジェクトの生成。
• `QueryInterface`: 既存のCOMオブジェクトのインターフェースを取得。
• `Release`: COMオブジェクトの参照カウントをデクリメント。

VBAの `Set obj = Nothing` は、内部的に `Release` メソッドを呼び出していますが、複雑なCOMオブジェクトグラフでは、この連鎖がうまくいかないことがあります。

5.2. ActiveXオブジェクトとレジストリ

CorelDRAWのCOMコンポーネントは、ActiveXテクノロジーに基づいています。これらのコンポーネントは、Windowsレジストリに登録されており、システム全体で共有されます。レガシー環境では、これらの登録情報が破損していたり、古いバージョンのコンポーネントが残っていたりすることが、予期せぬエラーの原因となることがあります。

5.3. COM+ と分散トランザクション (高度な領域)

非常に大規模で、複数のサーバーにまたがるようなバッチ処理システムを構築する場合、COM+ サービスや分散トランザクションの概念が必要になることもあります。これらは、トランザクションの整合性を保証し、障害発生時のロールバックなどを可能にしますが、CorelDRAW VBAの範疇を大きく超えるため、ここでは詳細な解説は割愛します。

5.4. レガシー環境での保守：ドキュメント化とリファクタリング

長年運用されてきたシステムは、しばしばドキュメントが不足しています。バッチ処理システムの保守においては、まず既存のコードを丁寧に読み解き、その挙動を理解することが最優先です。そして、必要に応じて、コメントの追加、可読性の向上、そして部分的なリファクタリング（機能を変えずにコードを改善すること）を行い、「技術的負債」を少しずつ返済していくことが、将来的な安定稼働のために不可欠です。

6. 巨大CDRファイル連続バッチ処理のための実践的設計パターン

ここまでの知見を踏まえ、数千個の巨大なCDRファイルを安全に連続バッチ処理するための設計パターンをまとめます。

6.1. バッチ処理の全体構造

• メインルーチン: 処理対象ファイルのリストを読み込み、各ファイルに対して個別の処理サブルーチンを呼び出す。
• ファイル処理サブルーチン (`ProcessFile`):
• CorelDRAWアプリケーションオブジェクトへの参照を管理（バッチ全体で1つのインスタンスを共有するのが効率的）。
• 個々のCDRファイルを開く。
• 必要な変換処理を実行。
• 厳格なオブジェクト解放: 開いたドキュメントオブジェクト、および処理中に生成された一時オブジェクトを、処理完了後またはエラー発生時に必ず `Nothing` に設定する。
• 堅牢な例外処理: `On Error GoTo` を使用し、エラー発生時にはログを記録し、`Resume Next` で次のファイル処理へ進む。
• CorelDRAWプロセス管理: バッチ処理の開始時にCorelDRAWを起動（または既存プロセスに接続）し、終了時に適切に終了させる（または、必要に応じてプロセスを維持する）。

6.2. メモリ管理の強化

• オブジェクトスコープの最小化: オブジェクト変数は、必要最小限のスコープ（ローカル変数）で宣言する。
• 明示的な解放の徹底: 処理ブロックの終わりに、不要になったオブジェクト変数を `Set obj = Nothing` で解放する。
• Garbage Collection の概念: VBAには明確なGarbage Collector（ガベージコレクタ）はありませんが、`Set obj = Nothing` を意識的に実行することで、COMオブジェクトの参照カウントを管理し、メモリ解放を促進します。

6.3. ログ記録と監視

• 詳細なログ: 処理したファイル名、成功/失敗、エラーコード、エラーメッセージ、処理時間などを記録する。
• 進捗表示: 処理中のファイル数、完了率などを表示し、ユーザーに進捗状況を伝える。
• リソース監視: バッチ処理中に、CorelDRAWプロセスのメモリ使用量やCPU使用率を定期的に監視する（タスクマネージャーの自動化、またはAPIによる監視）。異常な増加が見られた場合は、処理を一時停止または中止する。

6.4. エラーハンドリングの階層化

• ファイル単位のエラーハンドリング: 個々のファイル処理で発生したエラーは、そのファイル処理サブルーチン内で捕捉し、ログを記録して次のファイルへ進む。
• バッチ処理全体のエラーハンドリング: CorelDRAWプロセスの起動失敗、ファイルリストの読み込み失敗など、バッチ処理全体に関わる致命的なエラーは、メインルーチンで捕捉し、システム全体を安全に停止させる。

まとめ：伝説は、執念と正確さによって築かれる

CorelDRAW VBAによるCOMオブジェクトの参照リークとゾンビプロセス問題は、多くの開発者が直面する、しかし、克服可能な課題です。本稿で解説した、オブジェクトのライフサイクルへの深い理解、`Set obj = Nothing` による明示的な参照解放の徹底、そして `Err` オブジェクトを監視する堅牢な例外処理設計は、数千、数万というCDRファイルを安全に連続バッチ処理するための礎となります。

レガシーシステムであろうと、最新の環境であろうと、真に信頼性の高いシステムを構築するには、技術の深淵に潜むメカニズムを理解し、細部にまでこだわる執念が必要です。Windows APIの知識は、VBAの限界を超えるための強力な武器となりますが、それ以上に重要なのは、COMオブジェクトモデルの設計思想を理解し、それをVBAコードに落とし込む「設計力」です。

これらの知見が、諸君のプロジェクトにおける成功の一助となれば幸いです。技術の真髄を追求し、より堅牢で、より効率的なシステムを共に築き上げていきましょう。