壊れたProjectファイルは「死」ではない。バイナリ的直観で救出する極限のリカバリ術
MS Projectのファイル（.mpp）がオープン不能に陥る瞬間――それはシステム管理者の悪夢であり、同時にそのプロジェクトの歴史が霧散する瞬間だ。多くのエンジニアはここで「バックアップからの復元」という安易な逃げ道を探す。だが、そのバックアップさえも破損していたら？
私はこれまで、数千のタスクを持つ巨大な工程表が「不明なエラー」で沈黙する現場を幾度も目撃してきた。本稿で解説するのは、Projectのオブジェクトモデルが死に体であっても、その残骸からタスクデータを抽出・再構築するための、いわば「デジタルフォレンジック」に近いアプローチだ。
—
1. 破損の本質を見極める：DOMの限界とストリームの深淵
MS Projectの.mppファイルは、単なるドキュメントではない。複雑なオブジェクトグラフをシリアライズしたバイナリの集合体だ。`Application.FileOpen` が失敗する時、多くの場合、メタデータやインデックス情報の整合性が崩れている。
ここで重要なのは、「GUIレベルの開閉を諦め、低レイヤーのアプローチへ切り替える」という判断の速さだ。オブジェクトモデルが完全に破綻している場合、標準的な `Project.Open` を連呼してもメモリリークとアプリケーションのフリーズを招くだけである。
—
2. 極限の救出戦略：アーキテクチャの再構築
我々が狙うのは、破損したファイルから「生存しているタスクオブジェクト」を1つずつ抽出することだ。幸いなことに、バイナリの一部が破損していても、タスク個別のプロパティ（GUID, Name, Start, Finish）がメモリ上に保持されている可能性は高い。
以下のコードは、通常の `FileOpen` での読み込みをバイパス（あるいは最小限の読み取り）し、安全なメモリ領域に新規タスクを流し込むための骨子だ。
‘ 警告: 本コードはメモリ管理に厳格な制約を課すため、VBAのガベージコレクションを信頼してはならない。
‘ 以下のプロシージャは、オブジェクトの明示的解放を徹底している。
Public Sub RescueTaskData(ByVal targetPath As String)
Dim app As MSProject.Application
Dim proj As MSProject.Project
Dim targetProj As MSProject.Project
Dim tsk As MSProject.Task
Set app = New MSProject.Application
‘ 非表示で開き、イベントを抑制してメモリ消費を最小化する
app.Visible = False
On Error Resume Next
‘ ReadOnlyモードで開くことが生存率を高める鍵
Set proj = app.FileOpenEx(Name:=targetPath, ReadOnly:=True)
If proj Is Nothing Then
Debug.Print “致命的: プロジェクトの構造自体が崩壊しています。バイナリ抽出フェーズへ移行してください。”
Exit Sub
End If
‘ 新規プロジェクトへのデータマイグレーション
Set targetProj = app.Projects.Add
For Each tsk In proj.Tasks
If Not tsk Is Nothing Then
‘ 破損した属性を回避し、生存している主要データのみを転記する
Call targetProj.Tasks.Add(tsk.Name)
targetProj.Tasks(targetProj.Tasks.Count).Start = tsk.Start
targetProj.Tasks(targetProj.Tasks.Count).Finish = tsk.Finish
‘ ここで必要に応じてリソースやリンク情報を再構築する
End If
Next tsk
‘ メモリの解放：Projectオブジェクトを明示的にNothingに設定
Set tsk = Nothing
Set proj = Nothing
Set targetProj = Nothing
app.Quit
Set app = Nothing
MsgBox “救出完了。新規ファイルを確認してください。”
End Sub
—
3. パフォーマンスとメモリの最適化：シニアの矜持
このリカバリプロセスにおいて、最も避けるべきは「巨大なオブジェクトグラフを一度に展開すること」だ。
- 明示的なメモリ解放: VBAの `Set obj = Nothing` は単なるマナーではない。COMの参照カウントを確実にデクリメントし、OSにリソースを返還させるための儀式だ。特にループ処理内でのオブジェクト生成は、リークの温床となる。
- イベント抑制: `Application.EnableEvents = False` を忘れてはならない。破損ファイルを開く際、自動計算イベントや保存イベントがトリガーされると、処理が無限ループに陥るか、スタックオーバーフローを引き起こす。
- Windows APIの活用: ファイルのロック状態を確認するために `CreateFile` (Kernel32) を呼び出し、共有違反が発生していないかを事前にチェックする等の「事前防衛」は、大規模プロジェクトを扱うエンジニアの嗜みだ。
—
4. 最後に：レガシーを飼いならす者へ
破損した.mppファイルとの対話は、まさに砂漠で遺物を掘り出す作業に近い。一度のコード実行で全てが解決することはない。何度も失敗し、その都度デバッグトレースを読み、どのタスクで例外が発生するかを特定する。
「エラーが出たから諦める」のは素人だ。プロフェッショナルは、エラーそのものを解析の糸口にする。Project VBAを掌握するということは、Microsoftが隠した仕様の裏側にあるバイナリの論理構造を、あなたの指先で再構築することと同義なのだ。
この知見が、あなたのプロジェクトを絶望の淵から救い出す一助となれば幸いである。健闘を祈る。
