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

Hackの『Phantom Types』で実現する、コンパイル時に「状態」を刻み込む技術

こんにちは。HHVMの深淵を覗き込み、Hackの型システムと日々対話しているチーフアーキテクトです。

今日は、Hackという言語が持つ「静的型付けの真髄」とも言えるPhantom Types（ファントム型）についてお話ししましょう。多くの言語では「実行時にif文で状態チェック」をするような場面を、Hackでは「コンパイルが通る＝ビジネスルールが守られている」という、極めて堅牢な状態へ昇華させることができます。

「なぜそんなことが可能なのか？」そのロジックを、一緒に解き明かしていきましょう。

—

1. Phantom Typesとは何か？

Phantom Typeを一言で言えば、「実行時には存在しない、型チェックのためだけに存在するラベル」です。

通常、クラスにはデータ（プロパティ）が入っていますよね？しかしPhantom Typeとして使うクラスは、中身が空っぽであることが多い。なぜなら、そのクラスの「役割」は、コンパイル時に型チェッカー（HHVMの強力な守護者）に「今、これはどういう状態なのか」を伝えることにあるからです。

概念図：型のラベルによる状態管理

[未登録ユーザー] –(認証)–> [登録済みユーザー] –(決済)–> [購入完了ユーザー]
↑ ↑ ↑
Phantom型A Phantom型B Phantom型C

この矢印の遷移を、コード上で「型が合わないとコンパイルエラーになる」ように強制します。

—

2. 実践：注文ステータスの状態遷移を保証する

例えば、ECサイトの注文処理を考えてみましょう。「注文作成済み」の状態でなければ「配送処理」に進んではいけませんよね。これを型システムで縛ります。

<<____Strict>> // Hackの真骨頂、厳格モードは必須です

// 1. 状態を表現する空のクラス（これらがPhantom型です）
final class Created {}
final class Shipped {}

// 2. 状態を持つコンテナクラス
// TStateという型引数が、この注文の状態を表すラベルになります
final class Order {
public function __construct(private string $orderId) {}
}

// 3. 状態遷移を伴う関数
// Created状態の注文しか受け付けない！
function shipOrder(Order $order): Order {
// ここで配送ロジックを実行…
return new Order($order->getOrderId());
}

<<__EntryPoint>>
function main(): void {
$order = new Order(“ORD-001”);

// OK: Created状態なので通る
$shippedOrder = shipOrder($order);

// NG: すでに配送済み(Shipped)になった注文を、再度 shipOrder に渡すと…
// shipOrder(shippedOrder); // ← ここで型チェッカーが “Order は Order に代入できない” と吠えます！
}

なぜこれが強力なのか？

このコードで `shipOrder($shippedOrder)` を書くと、HHVMの型チェッカーは容赦なくエラーを吐きます。「配送済みの注文をもう一度配送する」というバグが、本番環境に到達する前に、エディタ上で発見できるのです。

—

3. 陥りやすい「罠」と解決のヒント

初心者がPhantom Typeを使い始めると、必ず一度は「型が合わない！」と悩むポイントがあります。

罠：型の不変性（Invariance）

Hackのジェネリクスはデフォルトで「不変（Invariant）」です。つまり、`Order` は `Order` のような親クラスに暗黙的にキャストされません。

解決策：
状態遷移を明確にするために、あえて不変であることを利用して「意図しない型の混合」を防ぐのがHack流です。もしどうしても柔軟性が必要な場合は、`<<__Covariant>>`（共変）などのアノテーションを検討しますが、状態保証が目的であれば、デフォルトのままの方が安全で堅牢です。

—

4. なぜ「実行時チェック」ではダメなのか？

「いやいや、実行時に `if ($order->status == ‘CREATED’)` と書けばいいのでは？」と思うかもしれません。しかし、これには2つの大きなリスクがあります。

1. カバレッジの穴： テスト漏れがあれば、本番環境でそのロジックが通るまでバグに気づけません。
2. 認知負荷： コードを読む際、「この変数は本当にその状態なのか？」をプログラマが脳内で追跡し続ける必要があります。

Phantom Typeを使えば、「型が通っている＝状態遷移は正しい」という確信を持ってコードを書けます。これは大規模開発において、エンジニアの精神衛生を守る最高の盾になります。

—

最後に：Hackの型システムは「設計図」そのもの

Phantom Typeを使いこなすことは、単にエラーを防ぐことではありません。「ビジネスルールをコードの構造に刻み込む」という、究極の設計手法を身につけることです。

Hackの厳格な静的型付けは、決して開発者の自由を奪う鎖ではありません。むしろ、正しく使えば、どんなに複雑なビジネスロジックであっても、HHVMという頼もしい相棒が「それはルール違反ですよ」と教えてくれる、最強のナビゲーターになります。

まずは、小さなクラスの「状態」をPhantom型で括ってみることから始めてみてください。その瞬間から、あなたの書くコードの「信頼性」は劇的に向上するはずです。

ここをクリアすれば、あなたはもうHackの初級者ではありません。次は、`Type Constants` や `Shapes` を組み合わせた、さらに深遠な型設計の世界へ飛び込んでいきましょう。応援しています！