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

静的型システムを極限まで飼い慣らせ：Hackの『Phantom Types（幽霊型）』によるコンパイル時の状態保証

我々がPHPのレガシーな動的型付けを捨て、HHVM（HipHop Virtual Machine）の上でHackを走らせている真の理由を、君は日々のコーディングで意識しているだろうか。

もし君が、未だに「関数の冒頭でオブジェクトの状態を `if` 文でチェックし、不正なら `InvalidArgumentException` を投げる」という、2010年代初頭の防御的プログラミングにしがみついているのだとしたら、手元の型チェッカー `hh_client` に謝罪しなければならない。それは静的型システムの敗北であり、HHVMのJITコンパイラに対する冒涜でもある。

本稿では、Hackの厳格な静的型システム（Strict Mode）の極致である「Phantom Types（幽霊型）」を用い、ビジネスルールを実行時ではなく「コンパイル時（型チェック時）に100%強制する」極限の設計パターンを伝授する。

—

1. 実行時チェックという「敗北」：なぜ `if` によるガードは悪なのか

まずは、多くのWebアプリケーションで見られる、一見「丁寧」に書かれた以下のアンチパターンを見てほしい。

// 典型的な「状態フラグ」に依存した、脆弱なアンチパターン
final class User {
public function __construct(
private string $email,
private bool $isVerified = false,
) {}

public function verify(): void {
$this->isVerified = true;
}

public function getEmail(): string {
return $this->email;
}

public function isVerified(): bool {
return $this->isVerified;
}
}

final class MarketingMailer {
// 検証済みユーザーにのみ、特別なオファーを送信したい
public function sendPromotion(User $user): void {
// 実行時のチェック。これが「敗北」の証拠だ
if (!$user->isVerified()) {
throw new InvalidOperationException(“未検証のユーザーには送信できません！”);
}

// 送信処理…
}
}

このコードが抱える3つの大罪

1. バグの検知が本番環境まで遅延する
開発者が `sendPromotion` に「たまたま未検証の `User`」を渡してしまった場合、バグが牙をむくのはプロダクション環境の実行時である。
2. 無駄な「実行時オーバーヘッド」と「JITへの悪影響」
HHVMは高度なJIT（Just-In-Time）コンパイルを実行するが、不要な条件分岐（`if`）や例外スローのパスは、トレースキャッシュの肥大化を招き、投機的最適化（Speculative Optimization）を阻害する。
3. コードベースの認知的負荷の増大
このメソッドを呼び出す側は、常に「事前に検証済みかどうか」をドキュメントやコードを追って確認しなければならない。

我々が目指すべきは、「未検証のユーザーを `sendPromotion` に渡そうとした瞬間に、型チェッカーがビルドを拒絶する」世界である。

—

2. Phantom Types（幽霊型）の極意と「ゼロコスト抽象化」

Phantom Types（幽霊型）とは、「クラスのジェネリクス（型パラメータ）として定義されているが、実行時のプロパティやメモリ空間には一切現れない型」のことである。

HHVMにおいて、型パラメータは実行時には消去（Type Erasure）される。つまり、幽霊型をどれだけ複雑に定義しようとも、実行時のメモリ消費やパフォーマンスへの影響は完全にゼロである。型チェッカー `hh_client` の脳内だけで厳格に計算され、実行時には極限までスリムなマシンコードに変換される。これこそが「ゼロコスト抽象化」だ。

幽霊型の設計思想

ユーザーオブジェクトに「状態」というスタンプ（幽霊）を押す。

`User` という型を定義する。
`$user` をインスタンス化した直後は `User` 型となる。
メール検証プロセスを通過すると、新たなインスタンス `User` が返される。
`sendPromotion` は `User` のみを受け取るように宣言する。

これにより、ビジネスルール（「検証済みユーザーにしかメールを送れない」）が、Hackの型システムそのものによって担保される。

—

3. 実践：Phantom Typesによる状態遷移の完全固定化

以下に、実務の現場でそのまま通用する、不変（Immutable）かつ型セーフなプロダクションコードを示す。

namespace HackArchitect\PhantomTypes;

1. 状態を表す「幽霊（Phantom）」インターフェース群の定義
これらは実行時にはインスタンス化されず、静的型チェックのためだけに存在する。

/
interface UserState {}
final class Unverified implements UserState {}
final class Verified implements UserState {}

2. 状態を型パラメータ `TState` で縛った User クラス

/
final class User {
// コンストラクタを private にし、不正な直接生成を完全に封じる
private function __construct(
private string $id,
private string $email,
) {}

スマートコンストラクタ（静的ファクトリメソッド）
生成時は強制的に「Unverified（未検証）」状態となる。

/
public static function create(string $id, string $email): User {
return new User($id, $email);
}

public function getId(): string {
return $this->id;
}

public function getEmail(): string {
return $this->email;
}

状態遷移メソッド：Unverified から Verified への変換

このメソッドは `User` のコンテキストでのみ呼び出し可能とし、
戻り値として `User` を返す。
インスタンスを不変（Immutable）に保つことで、マルチスレッドや
非同期（async）処理におけるデータ競合を根本から排除する。

/
public function verify(this: User): User {
// 内部的には同じプロパティを持つ新しいインスタンスを生成するが、
// 型パラメータを Verified にアップグレードして返す。
return new User($this->id, $this->email);
}
}

3. 状態を型で強制するサービス層

/
final class MarketingMailer {
/

このメソッドは `User` しか受け付けない。
`User` を渡そうとするコードは、コンパイルすら通らない。

/
public function sendPromotion(User $user): void {
// 実行時の状態チェック（isVerified() など）は一切不要！
// ここに到達した時点で、型システムによって「検証済み」であることが100%保証されている。
\printf(“Sending promotion to verified user: %s\n”, $user->getEmail());
}
}

—

4. この設計がもたらす『コンパイル時の鉄壁の防御』

この設計を導入したとき、開発者が犯すミスを `hh_client` がどのように一撃で粉砕するかを見てみよう。

<<__EntryPoint>>
async function run_demo_async(): Awaitable {
// 1. ユーザーの新規作成（この時点では User）
$newUser = User::create(“usr_999”, “architect@example.com”);

$mailer = new MarketingMailer();

【アンチパターン：未検証ユーザーへの送信】
もし、ジュニアデベロッパーが間違って検証前のユーザーにメールを送ろうとしたら？

/
// $mailer->sendPromotion($newUser); // <-- コメントアウトを外すと、型チェッカーが瞬時に牙をむく！ / 型エラーの例： Invalid argument Expected User
But got User
/

【正しいフロー】
明示的に検証を行い、`User` を取得してから処理に回す。

/
$verifiedUser = $newUser->verify();

// これは何の淀みもなく、極めて安全に型チェックを通過する。
$mailer->sendPromotion($verifiedUser);
}

なぜこの設計が美しいのか？

`verify()` メソッドのシグネチャ `this: User` に注目せよ。

これは、すでに `Verified` になったオブジェクトに対して、再度 `verify()` を呼び出すという無意味な二重処理を型レベルで禁止する。

ビジネスルールの「可視化」

コードの型シグネチャそのものが、完璧な仕様書として機能する。ドキュメントを読まなくとも、「どの状態でどのAPIが呼べるか」がエディタ上で一目瞭然となる。

—

5. HHVMアーキテクチャの視点：JITと型消去、そしてガードの最小化

我々がこの「Phantom Types」を推す最大の理由は、単なる安全性の確保にとどまらない。HHVM/JITコンパイラの性能を限界まで引き出すためである。

HHVMの「型ガード（Type Guard）」を理解する

HHVMは、実行時にPHP/Hackコードをアセンブリに翻訳する際、変数や引数の型が「本当に期待通りか」を検証する「ガード（Guard）」と呼ばれる命令をマシンコードに挿入する。

もし実行時に複数の型（`User` だったり `null` だったり、あるいは未検証状態を表す異なるクラス）が頻繁に入り乱れると、HHVMのJITは「多態的（Polymorphic）」なコードであると判断し、最適化のレベルを下げてしまう。最悪の場合、最適化されたアセンブリパスから外れ、低速なインタープリタや汎用パスにフォールバックする（これを JIT Bailout と呼ぶ）。

幽霊型による「ガードの消滅」

幽霊型（`User`）を採用すると、HHVMのランタイムから見れば、実体はすべて単一の `User` クラスに集約される。

1. JITの単一化（Monomorphizationの擬似効果）
HHVMにとっては、`User` も `User` も、実行時には「まったく同じ `User` クラスのレイアウト」である。そのため、オブジェクトのメモリ表現が変わらず、JITは単一の最適化されたパス（Monomorphic Path）を極めて効率的に生成できる。
2. 分岐予測の最適化
メソッド内部での `if (!$user->isVerified())` のような実行時チェックが消滅するため、CPUの分岐予測（Branch Predictor）ミスが激減する。パイプラインハザードが発生せず、CPUのクロックサイクルをダイレクトにビジネスロジックの実行に捧げることができる。

—

6. まとめ：型システムを信じよ、防御的コードを駆逐せよ

堅牢なシステムを構築するテクニカルリードとして、メンバーにはこう伝えてほしい。

> 「実行時に例外を投げるコードを書いた時点で、我々は型システムとの戦いに敗北している。静的型チェッカー `hh_client` を、単なるシンタックスエラー検出器として使うな。ビジネスルールそのものを型定義に落とし込み、コンパイル時にバグを完全に蒸発させるのだ。」

Hackの厳格モードとPhantom Typesの組み合わせは、Webアプリケーション開発における「堅牢性と超高速性の両立」を約束する最強の武器である。今日から君のプロジェクトでも、このゼロコストで最高に美しい設計パターンを導入し、型安全の真の恩恵を享受してほしい。