【実務・中級編】【中級者向け】巨大なプロジェクトファイルを開く際の「計算モード」を制御して高速化する手法 – Project VBA解析バイブル

Project VBA

2026.08.27

巨大なProjectファイルを「秒速」で開く：計算負荷を制御するエンジニアの作法

業務でMS Projectを扱っている諸君。数万行に及ぶWBS、複雑な依存関係、そして無数のカスタムフィールドが絡み合う「重量級プロジェクトファイル」を開く際、プログレスバーを眺めながらコーヒーを淹れに行く習慣は捨てろ。

Projectのファイルオープンは、単なるデータの読み込みではない。ファイルを開いた瞬間に走る「スケジューリングエンジン」が、全タスクの依存関係を再計算し、クリティカルパスを導き出そうと全CPUを食い尽くす。これが起動を遅延させる真犯人だ。

今日は、Project VBAのAPIを叩き、この「不要な自動計算」を制御することで、起動時間を劇的に短縮するプロフェッショナルな手法を伝授する。

—

通常、`Application.FileOpen` を使用すると、Projectは「読み込み」と同時に「全タスクの再計算」を開始する。巨大なファイルになればなるほど、この計算負荷は指数関数的に増大する。

我々エンジニアがとるべき戦略はシンプルだ。
1. 計算モードを一時的に手動へ切り替える
2. ファイルを読み込む
3. 必要な設定やデータ操作を終えた後に、明示的に再計算を行う

このプロセスを徹底するだけで、数分かかっていたファイルオープンを、物理的なI/O時間に近いレベルまで短縮できる。

—

以下に、エラーハンドリングを考慮した堅牢なコードを提示する。これを単なる「おまじない」ではなく、君のツールキットの中核として組み込んでほしい。

‘ プロジェクトファイルを高速オープンするためのラッパー関数
Public Sub OptimizedFileOpen(ByVal filePath As String)
Dim originalCalcMode As PjCalculation

‘ 1. 現在の計算モードを退避（環境を汚さないのがプロの流儀）
originalCalcMode = Application.Calculation

‘ 2. 計算モードを手動に切り替え（重要：読み込み時の負荷を極小化）
Application.Calculation = pjManual

On Error GoTo ErrorHandler

‘ 3. ファイルを開く
‘ ※ReadOnlyモードやMergeなど、用途に合わせてフラグを調整せよ
Application.FileOpen Name:=filePath, ReadOnly:=False

‘ — ここにデータ編集やレポート生成のロジックが入る —
Debug.Print “ファイル読み込み完了: ” & Now

‘ 4. 処理終了後に計算を再開し、一括で整合性を担保する
Application.CalculateAll

‘ 5. 計算モードを元に戻す
Application.Calculation = originalCalcMode
Exit Sub

ErrorHandler:
‘ 異常終了時も必ず計算モードを復旧させる（重要）
Application.Calculation = originalCalcMode
MsgBox “エラーが発生しました: ” & Err.Description, vbCritical
End Sub

—

コードをコピペして満足するな。実務でバグを埋め込まないための設計思想を理解せよ。

上記のコードで最も重要なのは `originalCalcMode` を退避させている点だ。これを怠り、計算モードを「手動」にしたままユーザーにファイルを返せば、ユーザーは「Projectが計算してくれない」という不具合に遭遇する。自分の手で汚した環境は、必ず自分の手で元に戻せ。

外部DBからProjectへデータを流し込む際、1レコード更新するたびに `Calculate` が走るような設計は、殺人的なパフォーマンス低下を招く。必ずバルク更新を行い、最後に一度だけ `Application.CalculateAll` を叩く。これが大規模開発における定石だ。

ベースラインの保存は、全タスクの依存関係が確定している必要がある。計算モードを制御している期間中に無理やりベースラインを保存しようとすると、計算が不完全な状態でスナップショットが取られるリスクがある。必ず `CalculateAll` が完了し、整合性が保証された状態で実行すること。

—

巨大なプロジェクトファイルは、管理者の未熟さを映す鏡だ。しかし、ツールで扱う以上、その重さをテクニカルに制御するのは我々エンジニアの責務である。

今回紹介した「計算モードの制御」は、自動化の第一歩に過ぎない。しかし、この些細な気遣いの積み重ねが、チーム全体の生産性を底上げし、君自身を「ただコードを書く人」から「システムを支配するアーキテクト」へと変貌させる。

さあ、今すぐコードを書き換え、コーヒーを淹れる時間を「次の自動化の設計」に充てるとしよう。健闘を祈る。