Project VBAを掌握する極限の知見：ActiveSelectionの呪縛と、真に堅牢なオブジェクト参照のアーキテクチャ
Microsoft ProjectのVBA開発において、多くの開発者が最初に直面し、そして最後まで悩まされるのが「選択範囲（`ActiveSelection`）」という名の魔物だ。
画面上のUIと連動するこのプロパティは、プロトタイピングにおいては非常に直感的である。しかし、エンタープライズ領域のバッチ処理、他システムとの連携、あるいはユーザーの自由奔放な操作が引き起こす非同期的なイベント処理において、`ActiveSelection`ほど脆弱で信頼性の低いオブジェクトはない。
本稿では、Project VBAのオブジェクトモデルの深層に踏込み、`ActiveSelection`が孕む致命的な罠の正体を暴き、ユーザーのUI操作に依存せず、タスクIDを直叩きして安全に制御するための防御的プログラミングの極意を伝授する。
—
1. なぜ `ActiveSelection` は使ってはならないのか
UIとロジックの結合が生む不可避の破綻
`ActiveSelection`は、文字通り「現在ユーザーが画面上で何を選択しているか」を返す。ここに最大の罠がある。
バッチ処理や外部APIからのキック、あるいはタスクシートが非アクティブな状態でこのプロパティにアクセスすると、Projectは容赦なくランタイムエラーを発生させる。あるいは、ユーザーがセルを選択しているのか、行全体を選択しているのかによって、返されるコレクションの粒度が変わり、コードは予期せぬ挙動を示す。
シニアエンジニアたる者、「UIの状態に依存するビジネスロジック」は悪であるという原則を忘れてはならない。
オブジェクトのライフサイクルとメモリの闇
Projectのオブジェクトモデルは、ExcelやWordに比べて裏側のC++エンジン（COMコンポーネント）と密に結合している。
`ActiveSelection`から取得した `Selection` オブジェクトや、それに内包される `Task` オブジェクトの参照を適切に管理しないと、COMの参照カウントが解放されず、Projectプロセスがタスクマネージャー上にゾンビとして残り続ける。これが、大規模なスケジュール自動化スクリプトが突然フリーズする根本原因である。
—
2. 防御的プログラミングの極意：ActiveX / UI非依存のタスク参照
ユーザーがどこを選択していようとも、あるいは画面が表示されていなかろうとも、狙ったタスクを確実に対象とするためには、「IDによる直接索引（Direct Indexing）」と「厳密なNothing判定」を組み合わせたコードを書く必要がある。
以下のコードは、UIの状態を一切気にせず、指定したユニークID（UniqueID）を持つタスクを安全に取得・操作するプロフェッショナル・スタンダードの関数である。
‘ ==============================================================================
‘ 致命的なエラーを回避し、指定されたUniqueIDのタスクを安全に取得・操作するプロシージャ
‘ ==============================================================================
Public Sub SafeExecuteTaskOperation(ByVal targetUniqueID As Long)
Dim targetTask As MSProject.Task
Set targetTask = Nothing
‘ 1. Applicationオブジェクトの生存確認（COMの整合性担保）
If Application.Projects.Count = 0 Then
MsgBox “現在開かれているプロジェクトがありません。”, vbCritical, “System Error”
Exit Sub
End If
‘ 2. エラーハンドリングの有効化（存在しないIDへのアクセス対策）
On Error Resume Next
Set targetTask = ActiveProject.Tasks.UniqueID(targetUniqueID)
On Error GoTo 0
‘ 3. オブジェクトの存在確認（防御的判定）
If targetTask Is Nothing Then
MsgBox “指定されたUniqueID: ” & targetUniqueID & ” のタスクは存在しません。”, vbExclamation, “Warning”
Exit Sub
End If
‘ 4. トランザクション的な安全な操作
On Error GoTo ErrorHandler
‘ 例：タスク名の変更とコストの加算
targetTask.Name = targetTask.Name & ” [Processed]”
targetTask.Cost = targetTask.Cost 1.05
‘ ログ出力やシステム連携処理（ここにビジネスロジックを記述）
Debug.Print “Successfully processed Task ID: ” & targetUniqueID & ” (” & targetTask.Name & “)”
CleanUp:
‘ 5. 明示的なメモリ解放（COMオブジェクトのゾンビ化を防ぐ極意）
Set targetTask = Nothing
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “Runtime Error”
Resume CleanUp
End Sub
コードの解説：なぜこの書き方が必要なのか？
1. `ActiveProject.Tasks.UniqueID(…)` の活用
行番号（IDプロパティ）はユーザーがタスクを挿入・削除するたびに変動する。永続性を担保すべきシステム連携では、絶対に変動しない `UniqueID` を使用する。
2. `On Error Resume Next` との正しい付き合い方
エラーを闇雲に無視するのではなく、「指定したIDが存在しない」という例外ケースを捕捉するためだけに限定して使用し、直後に `On Error GoTo 0` でハンドリングをリセットしている。
3. 徹底的な `Set … = Nothing`
VBAのスコープを抜ける際、参照型のオブジェクト変数に `Nothing` を明示的に代入することで、COM RCW（Runtime Callable Wrapper）の参照カウンタを即座にデクリメントし、メモリリークを根絶する。
—
3. レガシー環境とシステム間連携における実践知
基幹システム（SAPや独自ERPなど）からCSVやXML経由で送られてきたタスク群に対し、VBAから一括更新をかけるアーキテクチャ設計では、以下の最適化が必須となる。
画面描画の凍結（ScreenUpdating）によるパフォーマンス最大化
タスクをループ処理で一括変更する際、UIが裏で再描画されていると、実行速度が数十分の一に劣化する。さらに、これが `ActiveSelection` のようなUI依存処理と組み合わさると、画面のフォーカス喪失によるCOMエラーを誘発する。
‘ バッチ処理前の最適化
Application.ScreenUpdating = False
Application.Calculation = pjCalculationManual ‘ 自動計算の停止
‘ — ここに安全なタスク操作ループを記述 —
‘ 処理後の復元
Application.Calculation = pjCalculationAutomatic
Application.ScreenUpdating = True
Application.CalculateAll
この「描画停止・手動計算化・一括処理・計算実行・描画復元」のライフサイクルを遵守することこそが、数万行規模の大規模工程表を扱う現場で生き抜いてきたエンジニアの知見である。
—
4. チーフアーキテクトからの提言
Project VBAはレガシーな技術と見なされがちだが、その裏で稼働するCOMのメカニズムを正しく理解し、UIの呪縛から解放された堅牢なコードを書く限りにおいて、今なお最強のローカルオーケストレーションツールである。
「今、ユーザーが何を選択しているか」に頼るコードを書くのは今日で終わりにしよう。
IDを直叩きし、オブジェクトを制し、メモリを支配する。その境地に至った時、あなたの書くVBAコードは、絶対に落ちない鉄壁のインフラストラクチャの一部となる。
