Hackにおける『Phantom Types』の実装：コンパイル時に状態遷移を保証する
テックリードの私だ。コードレビューのたびに「なぜこのドメインモデルは実行時例外でしか状態異常を検知できないのか」「なぜ無効な状態のオブジェクトがAPI層に漏れ出しているのか」と嘆くのは、今日で終わりにしよう。
HHVMの厳格な静的型システム（Strict Mode）とHackの高度な型チェッカーを使いこなせば、「不正な状態のオブジェクトを生成すること自体を型エラーとしてコンパイル時に弾く」ことが可能だ。それが今回解説する Phantom Types（ファントム型） パターンである。
世の中の甘い動的言語や、型システムが骨抜きにされた言語では、状態遷移のミスはすべて「実行時エラー（Runtime Exception）」という名の爆弾として本番環境に仕込まれる。しかし、我々はHackエンジニアだ。コンパイラを最強の守護神として使おう。
—
1. なぜ「実行時チェック」は破滅を招くのか
実務の現場で、次のようなコードを見たことはないだろうか？
<<__Strict>>
// ⚠️ 悪臭を放つアンチパターン
class Order {
private string $status = ‘created’;
public function pay(float $amount): void {
if ($this->status !== ‘created’) {
throw new InvalidStateException(“Already paid or shipped.”);
}
$this->status = ‘paid’;
}
}
この設計の何がクソなのか。
1. 認知負荷の増大: 開発者は「今、この `Order` インスタンスはどの状態なのか？」を常に脳内メモリーに保持し続けなければならない。
2. テストの爆発: すべての不正な順序でのメソッド呼び出しをテストするために、無駄な例外アサージョンを書かされる。
3. リファクタリングの恐怖: 状態が追加・変更された途端、コードベース全体の条件分岐が崩壊する。
状態は「値」ではなく「型」で表現すべきだ。ここでPhantom Typesの出番となる。
—
2. HackにおけるPhantom Typesの核心
Phantom Typeとは、ランタイムのメモリ上には一切存在しない（幽霊のような）型パラメータを構造体に持たせ、型チェッカーにのみ状態の正当性を検証させるテクニックである。
HHVMのジェネリクスは単なるシンタックスシュガーではない。JITコンパイラの最適化パイプラインにおいて、型パラメータは厳密に静的解析され、不要なボックス化（Boxing）や実行時オーバーヘッドは極限まで排除される。つまり、Phantom Typesは「実行時コストゼロの安全性」をもたらす究極のアーキテクチャなのだ。
—
3. 実装：コンパイル時に保証される堅牢な決済パイプライン
百聞は一見にしかず。ECドメインにおける「注文（Order）」のライフサイクル（作成 -> 支払い完了 -> 発送済み）を、Phantom Typesで完全に型安全に制御するプロダクションコードを見てほしい。
<<__Strict>>
namespace Domain\Order;
// ==========================================
// 1. 状態を表すマーカークラス（インスタンス化不可）
// ==========================================
interface OrderState {}
final class Created implements OrderState {}
final class Paid implements OrderState {}
final class Shipped implements OrderState {}
// ==========================================
// 2. ファントム型を持つ注文ドメインモデル
// ==========================================
// TState がファントム型。プロパティとしては保持されず、型レベルでのみ機能する。
final class Order
private int $id;
private float $amount;
// コンストラクタはプライベート。ファクトリーメソッド経由でのみ生成を許す。
private function __construct(int $id, float $amount) {
$id = $id;
$amount = $amount;
}
// 初期状態の注文を生成
public static function create(int $id, float $amount): Order
return new Order
}
// Created -> Paid への遷移
// 呼び出し元の Order は消費され、新しい状態の Order が返却される（イミュータブル設計）
public function pay(PaymentGateway $gateway): Order
// 決済処理のモック
$gateway->charge($this->amount);
// 型安全に次の状態へキャストして返却
return UNSAFE_CAST
}
// Paid -> Shipped への遷移
public function ship(ShippingService $shipper): Order
$shipper->dispatch();
return UNSAFE_CAST
}
public function getId(): int {
return $this->id;
}
}
// ダミーのサービス群
interface PaymentGateway { public function charge(float $amount): void; }
interface ShippingService { public function dispatch(): void; }
チーフアーキテクトからのコード解説：
- `TState as OrderState`: 型パラメータに制約をかけ、無効な型が紛れ込むのを防いでいる。
- イミュータブルな状態遷移: 状態が変化するたびに新しいジェネリック型を持ったオブジェクト（例：`Order
` から `Order `）を返す。これにより、古い状態のオブジェクトを誤って再利用するバグ（Aliasing bugs）を根絶する。 - `UNSAFE_CAST` のカプセル化: 内部的な状態の型書き換えはクラス内部に閉じ込め、外部のクライアントコードには一切露出させない。
—
4. クライアントコード：型チェッカーによる絶対的な防衛線
では、このモデルを実際のアプリケーション層（APIコントローラーや非同期ワーカー）でどのように使うか。
<<__Strict>>
namespace App\Controller;
use namespace Domain\Order;
class OrderController {
public function checkoutFlow(
int $orderId,
float $amount,
Order\PaymentGateway $gateway,
Order\ShippingService $shipper,
): void {
// 1. 注文作成 (Order
$order = Order\Order::create($orderId, $amount);
// 2. 決済実行 (Order
$paidOrder = $order->pay($gateway);
// 3. 発送処理 (Order
$shippedOrder = $paidOrder->ship($shipper);
// ————————————————–
// 🛑 ここでコンパイルエラーになる例（バグの防止）
// ————————————————–
// $order->ship($shipper);
// -> Error: Method ship() undefined on Order
// 「作成されたばかりの注文を発送しようとするな」と型チェッカーが即座に怒る。
// $paidOrder->pay($gateway);
// -> Error: Method pay() undefined on Order
// 「すでに支払い済みの注文を二重決済するな」
}
}
素晴らしい。もし開発者がうっかり順序を間違えたり、不正なメソッドチェーンを組んだりした場合、実行時例外が起きる前に、HHVMの静的型チェッカー（hh_client）がビルドを即座に失敗させる。CI/CDパイプラインの初期段階で不良コードを完全にシャットアウトできるのだ。
—
5. パフォーマンス上の注意点とHHVMの裏側
「イミュータブルにオブジェクトを生成し直すなら、メモリ効率やGC（ガベージコレクション）の負荷が高いのではないか？」
優秀なエンジニアであれば、そう懸念するはずだ。しかし、ここがHHVMの真骨頂である。
1. JITコンパイラの最適化: HHVMのトレーシングJITは、ファントム型を持つクラスのインスタンス化やキャストを最適化し、多くの場合において単なるポインタ操作やインライン展開レベルまでコストを削ぎ落とす。
2. アロケーションの排除: 必要であれば、状態遷移メソッド内で `this` を直接ミューテートするアプローチ（ビルダーパターン的な内部状態の書き換え）を取りつつ、戻り値の型だけを `Order
—
6. まとめ：型システムを味方につけた者だけが勝つ
動的言語のノリで「動けばいいや」と書かれたコードベースは、事業のスケールとともに破綻する。型システムとは、単なる「型の補完ツール」ではない。「ビジネスのルール（仕様）をコードの構造に強制し、誤った実装を物理的に不可能にするための最強の契約書」である。
Hackの静的型付けとPhantom Typesを組み合わせることで、あなたの書くコードは圧倒的な堅牢性を手に入れ、コードレビューの指摘事項は「ロジックの美しさ」に集中できるようになる。
さあ、今すぐ既存のフラグ管理だらけのモデルを捨て、型による秩序を構築しよう。