【実務・中級編】初心者向け：ConstraintDateプロパティへの日付代入におけるシリアル値の罠 – Project VBA解析バイブル

Project VBA

2026.10.28

【極限の知見】MS Project VBAにおける「日付制約」の崩壊を防ぐ：ConstraintDateとシリアル値の不可視な罠

【極限の知見】MS Project VBAにおける「日付制約」の崩壊を防ぐ：ConstraintDateとシリアル値の不可視な罠

プロジェクトの自動化ツールを開発しているエンジニア諸君。
君たちが作成したツールが、特定の条件下で「計算結果が1日ずれる」「制約が正しく適用されない」「スケジュールが意図しない方向に流れる」といった不可解な挙動を示したことはないだろうか？

もし、その原因が「日付の代入」にあるとしたら、君たちの設計思想には致命的な欠陥がある。

MS Projectのスケジュール計算エンジンは、単なる「カレンダー」ではない。極めて精密な数値演算エンジンだ。本稿では、初心者が見落としがちな `ConstraintDate` プロパティへの日付代入における「シリアル値の罠」を解剖し、プロフェッショナルが実践すべき堅牢な実装設計を伝授する。

1. なぜ「日付を代入しただけ」でバグが起きるのか

結論から言おう。VBAの `Date` 型と、MS Projectが内部で保持する「日付時刻シリアル値」の解釈の乖離が原因だ。

浮動小数点数の恐怖

VBAにおける `Date` 型は、内部的には `Double`（倍精度浮動小数点数）として管理されている。日付の整数部分が「日」を、小数部分が「時刻」を表す。

問題は、Excelやデータベース（SQL Server等）から値を取得した際、目に見えない「微小な時刻成分」が混入することだ。

期待値: `2023/10/01 00:00:00` （シリアル値: `45200.0`）
現実: `2023/10/01 00:00:00.0000001` （シリアル値: `45200.0000001`）

MS Projectの計算エンジンにこの「微小なゴミ」が含まれた値を `ConstraintDate` に放り込むと、エンジンはこれを「その日の開始時刻を過ぎた瞬間」と判断する。その結果、制約条件（Must Start Onなど）が適用された際、タスクが意図せず翌日にシフトしたり、計算ループに陥ったりする。

これが、「見た目は正しいのに、挙動が狂う」という悪夢の正体だ。

2. 破綻する設計 vs 堅牢な設計

現場で見かける「未熟なコード」と、我々プロフェッショナルが書くべき「プロダクションコード」の違いを比較せよ。

【NG】素人レベルの直接代入

外部ソースから取得した値を、そのままプロパティに叩き込むスタイルだ。

' --- 危険なコード例 ---
Sub BadPractice_SetConstraint()
    Dim t As Task
    Set t = ActiveProject.Tasks(1)
    
    ' ExcelのセルやDBから取得した「日付っぽいもの」をそのまま入れる
    ' 時刻成分が含まれていると、スケジュール計算が狂う原因になる
    t.ConstraintDate = Range("A1").Value 
    t.ConstraintType = pjTaskMustStartOn
End Sub

【OK】アーキテクトレベルの設計思想

プロフェッショナルは、外部データを「信頼しない」。
外部から入ってきたデータは、必ず「自社の正規化プロセス（Sanitization）」を通し、エンジンの期待する純粋な形式に変換してから適用する。

1. 入力の抽象化: `Variant` 型で広く受け入れる。
2. 正規化（Normalization）: 時刻成分を完全に抹消し、日付の整数部分のみを抽出する。
3. 型安全性の確保: 明示的に `Date` 型へキャストし、エンジンの演算精度を保護する。

3. 実戦投入用：堅牢なデータ変換ユーティリティ

以下に、そのままプロジェクトの共通モジュールとして採用できる、防御的プログラミングに基づいたコードを示す。

''' <summary>
''' MS Projectの計算エンジンに最適化された日付への正規化を行う。
''' 時刻成分を完全に排除し、日付の整数部分のみを抽出する。
''' </summary>
''' <param name="rawInput">外部（Excel/DB/User）から取得した未検証の値</param>
''' <returns>時刻成分が 00:00:00 に正規化された Date 型</returns>
Public Function NormalizeProjectDate(ByVal rawInput As Variant) As Date
    On Error GoTo ErrorHandler

    ' 1. Nullまたは空文字のチェック
    If IsEmpty(rawInput) Or IsNull(rawInput) Or rawInput = "" Then
        Err.Raise vbObjectError + 513, "NormalizeProjectDate", "入力値が空です。"
    End If

    ' 2. 日付型への変換試行
    Dim dteValue As Date
    If IsDate(rawInput) Then
        dteValue = CDate(rawInput)
    Else
        Err.Raise vbObjectError + 514, "NormalizeProjectDate", "入力値が有効な日付形式ではありません。"
    End If

    ' 3. 【核心】時刻成分の抹消
    ' DateValue関数を使用することで、時刻部分を切り捨て、
    ' 純粋な「日付の整数値」のみを保持した Date 型を返す。
    ' これにより、MS Projectの計算エンジンへの「ゴミ」の混入を防ぐ。
    NormalizeProjectDate = DateValue(dteValue)

    Exit Function

ErrorHandler:
    ' 実務ではログ出力やユーザーへの警告をここに実装する
    Debug.Print "Error in NormalizeProjectDate: " & Err.Description
    Err.Raise Err.Number, Err.Source, Err.Description
End Function

''' <summary>
''' タスクに日付制約を安全に適用する。
''' </summary>
Public Sub ApplySafeConstraint(ByRef targetTask As Task, ByVal constraintType As PjTaskConstraintType, ByVal rawDate As Variant)
    On Error GoTo ErrorHandler

    ' タスクが存在しない場合はスキップ
    If targetTask Is Nothing Then Exit Sub

    ' 正規化プロセスを通す
    Dim safeDate As Date
    safeDate = NormalizeProjectDate(rawDate)

    ' トランザクション（再計算の抑制）を検討すべき場面だが、
    ' ここではシンプルにプロパティを適用
    With targetTask
        .ConstraintType = constraintType
        .ConstraintDate = safeDate
    End With

    Exit Sub

ErrorHandler:
    MsgBox "制約の設定に失敗しました。入力値を確認してください。" & vbCrLf & _
           "Error: " & Err.Description, vbCritical, "Architecture Error"
End Sub

このコードがなぜ「強い」のか

`DateValue` の戦略的利用: `CDate` は時刻を保持するが、`DateValue` は時刻を捨て去る。この使い分けが、計算エンジンの精度を守る防波堤となる。
防御的エラーハンドリング: 不適切なデータ（文字列、Null、不正な日付）が流れてきた瞬間に、エラーを検知してプロセスを止める。これにより、汚染されたデータがプロジェクトファイルに書き込まれるのを防ぐ。
単一責任の原則 (SRP): 「変換する関数」と「適用するサブプロシージャ」を分けることで、保守性とテストの容易性を確保している。

4. 開発リーダーからのアドバイス：設計の極意

諸君、覚えておいてほしい。
業務自動化ツールの価値は、「動くこと」ではない。「どんなデータが来ても、予測可能な結果を出し続けること」にある。

MS Projectのような複雑な依存関係を持つアプリケーションを扱う場合、君たちは「単なるプログラマ」ではなく「データの整合性を守る衛兵」でなければならない。

1. 外部データは常に「汚染されている」と仮定せよ。
2. 計算エンジンに値を渡す直前で、必ず「型」と「精度」を検閲せよ。
3. 「たぶん動く」というコードは、将来のプロジェクト遅延という名の負債を積み上げている。

この原則を胸に、次回の設計に取り組んでほしい。健闘を祈る。