【実務・中級編】『Phantom Types』によるコンパイル時の状態保証：型システムでビジネスルールを表現する – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

ファントムタイプ（Phantom Types）によるコンパイル時の状態保証：型システムでビジネスルールを表現する

コードレビューをしていて、次のようなメソッドを見かけるたびに私は深い絶望を覚える。

// 典型的な「実行時チェック」に依存した危ういコード
public function processOrder(Order $order): void {
if (!$order->isAuthorized()) {
throw new UnauthorizedException(“Order is not authorized!”);
}
if ($order->isShipped()) {
throw new InvalidStateException(“Order is already shipped!”);
}
// ここでやっとビジネスロジック…
}

おい、ちょっと待て。なぜ「コンパイル時に防げるはずのバグ」を、わざわざ本番環境のCPUサイクルを消費して例外投げさせなければならないのか？

HHVMの厳格な静的型システム（Strict Mode）と型チェッカーを舐めてもらっては困る。ランタイムのガードclause（条件分岐）は、最後の砦であって第一選択ではない。「不正な状態のオブジェクトが存在すること自体を型レベルで不可能な状態にする」――これこそが、Hack言語を極めたエンジニアが到達すべきパラダイムシフトだ。

今回は、ファントムタイプ（Phantom Types）を駆使し、ビジネスルールを型システムにコンパイルして、バグの余地をゼロにする極限の設計パターンを授けよう。

—

1. ファントムタイプとは何か：HHVM型チェッカーを欺く（利用する）技術

ファントムタイプ（幽霊型）とは、データ構造自体には保持されないが、型パラメータ（Generics）としてのみ存在するダミーの型を指す。

Hack（およびPHP）のオブジェクトは通常、保持するプロパティによって型が決まる。しかし、型パラメータに「現在の状態」を表すマーカー型をバインドすることで、同じデータ構造でありながら「状態ごとに完全に別物の型」として型チェッカーに認識させることができる。

HHVMの型チェッカーは非常に強力だ。実行時には余計なメモリオーバーヘッドを一切発生させず、コンパイル時のみ厳密に型の整合性を検証する。つまり、ゼロコストの安全性が手に入る。

—

2. 実践：注文ステータスを型で完全に制御するプロダクションコード

百聞は一見にしかず。ECサイトの注文処理を例に取ろう。
「未決済（Pending）」「決済完了（Authorized）」「出荷済み（Shipped）」という状態遷移を、ファントムタイプを使って完全に型安全に表現したコードを示す。

<<__STRICT>>

namespace App\Order;

// ==========================================
// 1. 状態を表すマーカー型（インスタンス化はしない）
// ==========================================
interface OrderState {}

final class Pending implements OrderState {}
final class Authorized implements OrderState {}
final class Shipped implements OrderState {}

// ==========================================
// 2. ファントムタイプを持つドメインモデル
// ==========================================
/

@template Tstate as OrderState

/
final class Order {
// 外部から直接生の状態を触らせない
private function __private_construct(
private int $id,
private float $amount,
) {}

新規作成時は強制的に Pending 状態の Order を返す

/
public static function create(int $id, float $amount): Order {
return new self($id, $amount);
}

public int getID(): int {
return $id;
}

public float getAmount(): float {
return $amount;
}

// ==========================================
// 3. 状態遷移と型変換（Transition Methods）
// ==========================================

Pending -> Authorized へ遷移
呼び出し元が Order であることを型で強制する

/
public function authorize(string $gatewayTransactionId): Order {
// 実際の決済処理（Gateway連携など）がここに入る想定
// …

// 状態が変化した新しい型（Order）のインスタンスを返す
return new Order($this->id, $this->amount);
}

Authorized -> Shipped へ遷移
未決済のまま出荷することは、型レベルで構文エラーになるため不可能

/
public function ship(string $trackingNumber): Order {
// 配送伝票発行処理…
return new Order($this->id, $this->amount);
}
}

// ==========================================
// 4. 各状態に特化したサービス層
// ==========================================
final class OrderProcessor {
/

このメソッドは「決済済みの注文」しか受け付けない。
未決済の注文を渡そうものなら、HHVMの型チェッカーが容赦なくコンパイルエラーを吐く。

/
public static function processFulfillment(Order $order): void {
echo “Fulfilling order ID: ” . $order->getID() . “\n”;
}
}

// ==========================================
// 5. 実行フローの検証
// ==========================================
function main(): void {
// ステップ1: 注文作成 (Order)
$cart = Order::create(10015, 5980.0);

// 【コンパイルエラーになる例】
// 未決済のままフルフィルメントを呼ぼうとすると…
// OrderProcessor::processFulfillment($cart);
// -> Typechecker Error: Expected Order, got Order!

// ステップ2: 決済実行 (Order -> Order)
$paidOrder = $cart->authorize(“TXN_XYZ_999888”);

// ステップ3: 決済済みなので正常に処理できる
OrderProcessor::processFulfillment($paidOrder);

// ステップ4: 出荷 (Order -> Order)
$shippedOrder = $paidOrder->ship(“TRACK_JP_123456”);

// 【コンパイルエラーになる例】
// 一度出荷した注文を再度authorizeしようとしても型がないのでエラーになる
// $shippedOrder->authorize(“TXN_AGAIN”);
}

—

3. なぜこの設計がプロダクションで最強なのか

コードレビューで「なぜここまで厳密にする必要があるのか」と問われたら、私はこう答える。

1. 「存在してはならないバグ」のコンパイル時絶滅
ロジックの書き漏らしによる「未払いのまま出荷完了ステータスに更新されてしまった」という致命的なインシデントは、テストコードを書くまでもなく、エディタ上（Typechecker常時実行）で完全に防がれる。
2. ドキュメントいらずの型シグネチャ
メソッドの引数を見るだけで、「この処理はどの状態のエンティティを要求しているのか」が1秒で理解できる。JSDocや冗長なコメントを読む必要はもうない。
3. リファクタリングへの圧倒的な耐性
ビジネス仕様が変わり「新しいステータス」が追加された場合でも、型マーカーを追加してコードを修正すれば、型チェッカーが「修正すべき箇所」をすべて網羅して教えてくれる。

—

4. パフォーマンス上の注意点とアーキテクトからの助言

「ファントムタイプを使うと、オブジェクトのインスタンス生成が増えてメモリを圧迫するのではないか？」
鋭いエンジニアならそう懸念するだろう。

答えは「No」だ。
HHVMのJITコンパイラは非常に優秀である。プライベートコンストラクタ経由で内部データを引き回すimmutableな設計にしておけば、不要なアロケーションは最適化され、実行時パフォーマンスへの悪影響は実質的に無視できるレベルに抑えられる。むしろ、実行時における無駄な`if`分岐や例外ハンドリングのコストが消えるため、コードベース全体としては高速化するケースが多い。

設計上のアンチパターン

ミュータブル（可変）なオブジェクトへの適用: ファントムタイプは原則としてImmutable（不変）なオブジェクト構造と組み合わせるべきだ。状態が途中で書き換わるオブジェクトにこれを適用すると、型の整合性が崩れ、型チェッカーが単なる飾りと化す。
過度な細分化: すべての状態をファントム化する必要はない。ドメインの整合性において「絶対にバグらせたくないクリティカルな状態遷移（決済、認証、権限昇格など）」に絞って導入するのが最もROIが高い。

—

結びにかえて

Hack言語を選ぶ理由は、まさにこの「妥協のない静的型付けの美しさ」にある。
PHPの動的な泥臭さを引きずったコードから脱却し、型システムをあなたの最強のビジネスガードドッグへと仕立て上げろ。

次のコードレビューで、もし`if (!$status->isValid())`という冗長なガード節を見かけたら、こう言って突き返してほしい。
「おい、そのバリデーション、型で表現してこい」と。