Project VBAを掌握する極限の知見：タスクIDとユニークIDの迷宮と、依存関係制御の鉄則
Microsoft ProjectのVBA開発において、多くのエンジニアが最初に直面し、そして最終的に深手を負うのが「IDの二面性」である。
画面上の行番号として表示される`ID`（タスクID）と、データベースのプライマリキーのように沈み込んでいる`UniqueID`（ユニークID）。この2つの仕様の本質を理解せずして、堅牢なWBS（Work Breakdown Structure）の自動生成や、外部システムとの連携基盤を構築することは不可能だ。
今回は、タスクの並び替えや動的削除が頻発する現場において、なぜタスクID依存がシステムを崩壊させるのか、そしてユニークIDを用いた極限の依存関係制御がいかにして実装されるべきか、その全貌を解き明かす。
—
1. タスクID（ID）とユニークID（UniqueID）の決定的な断絶
まず、オブジェクトモデルにおけるアイデンティティの定義を明確にする必要がある。
- タスクID (`Task.ID`):
- 性質: 可変（Volatile）
- スコープ: 現在のプロジェクト内における「行インデックス」
- 挙動: ユーザーがタスクをドラッグして並び替えたり、途中のタスクを削除したりすると、自動的に再採番（リインデックス）される。
- ユニークID (`Task.UniqueID`):
- 性質: 不変（Immutable）
- スコープ: プロジェクトのライフサイクル全体を通じて一意
- 挙動: タスクが生成された瞬間に割り振られ、削除されるまで決して変わらない。並び替えの影響も受けない。
罠：タスクIDで依存関係（Predecessors）を組む罪
レガシーなVBAコードや、ネット上の散逸したサンプルコードによよく見られるアンチパターンがこれだ。
‘ 【アンチパターン】タスクIDベースで先行タスクを指定する
ActiveProject.Tasks.Add “タスクB”
‘ タスク1の完了をタスク2の前提条件にするつもりが…
ActiveProject.Tasks(2).Predecessors = “1”
このコードの何が問題か。ユーザーがUI上で「タスク1」の上に別のタスクを挿入した瞬間、元の「タスク1」は「タスク2」にスライドし、IDが変化する。結果として、依存関係のグラフ（PERTチャート）は完全に破壊され、スケジュールは予期せぬクリティカルパスを描くことになる。
堅牢なエンタープライズシステムを構築する場合、「コード内でのタスク参照には一切タスクID（ID）を使わない」のが鉄則である。
—
2. ユニークIDを用いた堅牢な依存関係（Predecessors）の制御
では、ユニークIDを使って依存関係をプログラムから安全に構築するにはどうすればよいか。
MS ProjectのVBAにおいて、`Predecessors`プロパティに文字列を代入する場合、デフォルトではタスク名やタスクIDが解釈されてしまうことがある。これを回避し、確実にユニークIDベースでリンクを張るためには、プレフィックスとして `U` を付与するか、あるいはマッピング用の一時コレクションを活用するのがプロの作法である。
以下に、実業務で耐えうる堅牢な依存関係設定ルーチンの実装を示す。
‘ ==============================================================================
‘ 担当: チーフアーキテクト
‘ 概要: ユニークIDを用いた安全なタスク間依存関係の設定
‘ ==============================================================================
Public Sub SetDependencyByUniqueID(ByVal predecessorUID As Long, ByVal successorUID As Long, Optional ByVal lagTime As String = “0d”)
Dim tSucc As Task
Dim targetPredecessor As Task
Dim linkString As String
On Error GoTo ErrorHandler
‘ ユニークIDからタスクオブジェクトをO(1)に近い効率で取得
‘ ※大規模プロジェクトではUniqueID2Taskメソッド等のラップが有効
Set tSucc = GetTaskByUniqueID(successorUID)
Set targetPredecessor = GetTaskByUniqueID(predecessorUID)
If tSucc Is Nothing Or targetPredecessor Is Nothing Then
Err.Raise vbObjectError + 1000, “SetDependencyByUniqueID”, “指定されたユニークIDのタスクが見つかりません。”
End If
‘ MS Project VBAの仕様上、UniqueIDでリンクを指定する場合は “UID
‘ 例: “U105FS+2d”
linkString = “U” & predecessorUID & “FS+” & lagTime
‘ 既存の前提条件に追加（既存を上書きしないための配慮）
If tSucc.Predecessors <> “” Then
tSucc.Predecessors = tSucc.Predecessors & “,” & linkString
Else
tSucc.Predecessors = linkString
End If
Exit Sub
ErrorHandler:
MsgBox “依存関係の設定に失敗しました: ” & Err.Description, vbCritical
End Sub
‘ — ヘルパー関数: ユニークIDからタスクを検索 —
Private Function GetTaskByUniqueID(ByVal uid As Long) As Task
Dim t As Task
For Each t In ActiveProject.Tasks
If Not t Is Nothing Then
If t.UniqueID = uid Then
Set GetTaskByUniqueID = t
Exit Function
End If
End If
Next t
Set GetTaskByUniqueID = Nothing
End Function
—
3. 大規模WBSにおけるメモリ最適化とオブジェクト解放の極意
数千行を超える巨大なWBSをVBAで操作する場合、MS ProjectのCOMオブジェクトモデルはメモリリークやパフォーマンス低下の温床となる。特に `For Each` ループや不必要なオブジェクト変数の保持は、VBAランタイムに多大な負荷をかける。
ここで、シニアエンジニアが知るべきメモリ最適化の知見を共有する。
1. `For Each` とオブジェクトの明示的破棄
VBAのガベージコレクションは即時的ではない。ループ内で生成されるCOMラッパーオブジェクトは、明示的に `Nothing` を代入して解放しなければ、Projectのプロセス空間にメモリゴミが蓄積し、や労働プロセスが肥大化する。
2. 配列（Array）による一括処理とキャッシュ
タスクの検索や構造変更を毎回COM経由で行うと、IPC（プロセス間通信）のオーバーヘッドで実行時間が数倍に膨れ上がる。
大規模な階層構造（WBS）を構築・変更する際は、一度データをVBAのメモリ内配列（Variant配列）やDictionaryにキャッシュし、処理を完結させてから一括書き込みするアーキテクチャが望ましい。
以下は、メモリ管理を意識したタスク一括登録・依存関係構築のフレームワークの骨子である。
‘ ==============================================================================
‘ 概要: 大規模WBS一括生成時のメモリ最適化パターン
‘ ==============================================================================
Public Sub OptimizedWBSGeneration()
Dim prj As Project
Set prj = ActiveProject
‘ 画面描画と自動再計算を停止し、パフォーマンスを極限まで引き上げる
Application.ScreenUpdating = False
Application.Calculation = pjManual
On Error GoTo CleanUp
‘ — ここに高速なタスク追加・ユニークID取得のロジックを記述 —
‘ 例: 外部DBから取得したレコードセットをループし、タスクをバッチ追加
Dim tNew As Task
Set tNew = prj.Tasks.Add(“フェーズ1”)
‘ ユニークIDをキーとしてDictionaryに保持し、後続の依存関係構築に備える
CleanUp:
‘ 確実に設定を復元する（エラー時も必ず通す）
Application.Calculation = pjAutomatic
Application.ScreenUpdating = True
If Err.Number <> 0 Then
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical
End If
End Sub
—
4. システム間連携（Excel / DB / WebAPI）におけるIDハンドリングの鉄則
基幹システムやExcel、あるいはクラウド上のPMツール（JiraやRedmineなど）とMS Projectを連携させる場合、「外部システム側のIDと、MS ProjectのどのIDをマッピングするか」という設計課題に直面する。
結論から言えば、外部システムとの連携キーとして用いるべきは、絶対に `UniqueID` である。
連携アーキテクチャの設計指針
1. 外部IDの退避先:
MS Projectの標準フィールドである `Text1` 〜 `Text30`、あるいは拡張カスタムフィールド（`TextX`など）に、外部システムのプライマリキー（例: UUIDや外部タスクID）を格納する。
2. 同期プロセスのアルゴリズム:
- 同期バッチが走った際、まずMS Project側の全タスクをスキャンし、`Text1`（外部ID）と `UniqueID` のマッピング辞書（`Scripting.Dictionary`）をメモリ上に構築する。
- 外部からの更新データを受け取った際、タスクID（行番号）ではなく、`Text1` をキーにして該当タスクを特定する。
- 新規タスク追加時は、タスクを追加して得られた `UniqueID` と外部IDを紐付けてプロジェクトに保存する。
この設計を守ることで、ユーザーがMS Project上でタスクの順番を入れ替えようとも、外部システムとのデータ整合性が崩れることは永久になくなる。
—
5. 総括：レガシーの呪縛を断ち切るために
Project VBAの開発において、「動けばいい」という安易なコードは、プロジェクトが巨大化した瞬間に破綻する。タスクIDの変動という仕様の罠を見据え、常に `UniqueID` を主軸に据えたオブジェクト指向的なアプローチを貫くこと。
メモリのライフサイクルを制御し、画面描画や計算のロックを適切に管理するエンジニアリングこそが、現場の混乱を防ぎ、真に信頼性の高い自動化基盤を築き上げる唯一の道である。
技術者としての矜持を持ち、コードの隅々にまで意図を宿せ。
