Project VBA 掌握術：カスタムフィールドの数式を「動的に」書き込む際の致命的な罠と、堅牢な設計思想
プロジェクト管理の自動化において、MS Projectのカスタムフィールド（Task/Resource Custom Fields）をVBAから操作することは、業務効率化ツールの「心臓部」を作ることに等しい。
しかし、多くの開発者がここで躓く。`Formula` プロパティに数式を代入しようとした瞬間、原因不明の構文エラー（Syntax Error）に襲われ、実行時エラーの泥沼に沈んでいくのだ。
なぜ、単純な文字列の代入がこれほどまでに難しいのか？
それは、VBAの文字列リテラルと、MS Projectエンジンが解釈する数式構文という、二つの異なる言語レイヤーを同時に制御しなければならないからだ。
本稿では、単なる「書き方」の解説はしない。バグを未然に防ぎ、保守性の高いプロダクションレベルのコードを設計するための、アーキテクトとしての視点を伝授する。
1. 致命的な罠：ダブルクォーテーションの「二重構造」
初心者が最も陥りやすいミス、それはエスケープ処理の誤解だ。
MS Projectの数式内で文字列を扱う場合、数式自体は `”Completed”` のようにダブルクォーテーションで囲む必要がある。しかし、これをVBAの文字列として記述しようとすると、VBAの構文規則によってダブルクォーテーションをエスケープしなければならない。
失敗するコード（アンチパターン）
' これはエラーになる、あるいは意図しない挙動を生む
Task.Text1.Formula = "[Text2] = "Done""正解のロジック
VBAにおいて、文字列内のダブルクォーテーションを表現するには `””` と書く必要がある。
したがって、「数式として `”Done”` を渡したい」場合は、VBA上では `”””Done”””` と記述しなければならない。
この「引用符の入れ子構造」を理解していないと、数式が複雑になった瞬間にデバッグは不可能になる。
2. アーキテクトの設計思想：数式の「テンプレート化」と「注入」
現場で通用するツールを作るなら、VBAのコード内に直接、長い数式をハードコードしてはならない。それは保守性を著しく低下させ、将来的な仕様変更（フィールドの追加や計算ロジックの変更）に対応できない「死んだコード」を生む。
我々が取るべき戦略は、「数式の骨組み（テンプレート）」と「動的なパラメータ」を分離することだ。
設計の3原則
1. フィールド名のブラケット化: `[Text1]` のように、必ずフィールド名を `[]` で囲む。これにより、予約語や特殊文字による解析エラーを回避できる。
2. エスケープ専用関数の分離: 文字列のクレンジングをビジネスロジックから切り離す。
3. データ型の一致: `Formula` プロパティに代入する数式が、対象フィールドのデータ型（Text, Number, Date等）と矛盾していないかを設計段階で保証する。
3. プロダクション・グレードのコード実装例
以下に、実務でそのまま利用できる、堅牢な設計に基づいた実装例を示す。このコードは、特定の条件に基づいてカスタムフィールドに数式を動的に生成・注入するプロセスをモデル化している。
Option Explicit
' ==============================================================================
' Module: CustomFieldManager
' Description: MS Projectのカスタムフィールドへ安全に数式を書き込むためのユーティリティ
' ==============================================================================
''' <summary>
''' タスクのカスタムフィールドに動的な数式を設定する
''' </summary>
''' <param name="t">対象のTaskオブジェクト</param>
''' <param name="fieldIdx">カスタムフィールドのインデックス (1-30)</param>
''' <param name="targetValue">数式内で比較に用いる文字列定数</param>
Public Sub SetDynamicFormula(ByRef t As Task, ByVal fieldIdx As Integer, ByVal targetValue As String)
On Error GoTo ErrorHandler
Dim targetField As CustomField
Dim formulaTemplate As String
Dim escapedValue As String
' 1. フィールドの特定 (Text1, Text2... のインデックスから取得)
' ここでは簡略化のため、直接プロパティへアクセスする設計とする
' 本来はフィールド名を定数管理すべき
' 2. 文字列のエスケープ処理
' VBAの文字列として、MS Projectの数式内で使うための "" を生成する
escapedValue = """" & targetValue & """"
' 3. 数式のテンプレート構築
' [Text1] = "Value" という構文を、安全に組み立てる
' フィールド名は必ず [] で囲むのが鉄則
formulaTemplate = "[Text1] = " & escapedValue
' 4. 書き込み実行
' ※実際の実装では、フィールドの種類（Text型かNumber型か）のチェックを推奨
Select Case fieldIdx
Case 1: t.Text1.Formula = formulaTemplate
Case 2: t.Text2.Formula = formulaTemplate
' ... 他のケースも同様
Case Else
Err.Raise vbErr_InvalidParameter, "SetDynamicFormula", "Unsupported field index."
End Select
Debug.Print "Successfully applied formula: " & formulaTemplate
Exit Sub
ErrorHandler:
' ログ出力やエラーハンドリングの実装
MsgBox "Error in SetDynamicFormula: " & Err.Description, vbCritical, "Critical Failure"
' 業務アプリケーションでは、ここで詳細なログをDBやファイルに書き出す
End Sub
''' <summary>
''' テスト実行用メインルーチン
''' </summary>
Public Sub TestRunner()
Dim t As Task
Set t = ActiveProject.Tasks(1) ' 最初のタスクを対象とする
If t Is Nothing Then
MsgBox "No task found."
Exit Sub
End If
' 「完了」という文字列が入っている場合にTrueを返す数式をText2にセットする例
' Text2の型がText型であることを前提としている
Call SetDynamicFormula(t, 2, "完了")
End Sub4. 外部データ（DB/Excel）連携時の極意
実務では、数式のロジック自体をSQL ServerやExcelのマスターシートから取得することが多い。この際、最も危険なのは「外部から来た文字列を無批判に `Formula` に流し込むこと」だ。
データベース連携におけるチェックリスト
1. サニタイズ（無害化）:
DBから取得した文字列に、予期せぬダブルクォーテーションや特殊記号が含まれていないか確認せよ。`Replace(dbValue, “”””, “”””””)` を通す工程を忘れるな。
2. 構文検証（Syntax Validation）:
DBから取得した数式が、MS Projectの構文として成立しているかを事前に検証する仕組みを持て。可能であれば、一度別のダミープロジェクトで `Formula` を適用し、エラーが出ないかテストするフェーズを自動化フローに組み込むべきだ。
3. 型定義の同期:
DB側の列定義（例：`formula_logic`）と、MS Project側のカスタムフィールドのデータ型（例：`Number`）が一致していることを、設計ドキュメントで厳格に管理せよ。ここがズレると、実行時にプロジェクトファイルが破損（論理的な意味での）する。
まとめ：プロフェッショナルの仕事とは
カスタムフィールドの操作は、一見すると単純な文字列操作に見える。しかし、その裏側には「言語の境界線」が存在する。
- エスケープのルールを物理的に理解する。
- ハードコードを避け、テンプレート駆動の設計を行う。
- 外部データに対しては、常に「悪意ある（あるいは壊れた）データ」が来ることを想定して防御を固める。
これらを徹底して初めて、あなたの作ったツールは「単なる便利ツール」から、企業の基幹業務を支える「堅牢なシステム」へと昇華するのだ。
