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

静的検証の地平と実行時オーバーヘッドの排斥

大規模な分散システムやセキュリティ境界において、防御的プログラミングの名のもとに`invariant()`や実行時例外を乱発するアーキテクチャは、根本的な敗北を意味している。実行時チェックは、以下の2つの深刻なトレードオフを課すからだ。

1. JITコンパイラの分岐予測と投機的最適化の破壊（不要なガードコードとCold Blockの肥大化）
2. 潜在的バグの「実行時遅延爆発」（テストケースの網羅性に依存する脆弱性）

Hackの厳格モード（Strict Mode）と、その心臓部である型チェッカー（`hh_client` / `hh_server`）が目指すのは、ビジネスルール違反を物理的にコンパイル不可能にする世界である。これを達成する最高峰のイディオムの一つがPhantom Types（幽霊型）だ。

本稿では、Phantom Typesを用いてビジネスロジックの状態遷移を型システムへ昇華させる手法を解説する。さらに、HHVM（HipHop Virtual Machine）の内部アーキテクチャ、とりわけJITコンパイラとメモリレイアウトの観点から、この手法がいかに「実行時コストゼロ」で極限の安全性を担保するかを論証する。

—

Phantom Types（幽霊型）の理論的基盤と型健全性

Phantom Typeとは、「クラスの型パラメータ宣言に現れるが、そのクラスのメンバ変数（フィールド）の型としては一度も使われない型パラメータ」を指す。

// TState はプロパティとして保持されない。
// 単に型チェッカーの型推論コンテキストに状態ラベルを刻むためだけに存在する。
final class RequestContext {
private function __construct(
private string $payload,
) {}
}

この型パラメータ`TState`は、値の表現ではなく、型の状態（State）を標識する識別子として機能する。

変異性（Variance）の厳密な制御

Phantom Typesを設計する際、最も注意すべきは変異性（Variance）の指定だ。型引数が不変（Invariant）である場合、サブタイピング関係は厳格に固定される。

`+T`（共変 / Covariant）: 読み取り専用コンテキスト。`T_Sub`が`T_Super`の派生型であれば、`Container`は`Container`に代入可能。
`-T`（反変 / Contravariant）: 書き込み専用コンテキスト。
`T`（不変 / Invariant）: 代入を許さない。完全一致のみ。

状態遷移をモデル化する場合、状態間の暗黙的なアップキャストを防ぐため、原則として不変（Invariant）または意図的に設計された型階層を適用する。

—

実践：決済トランザクションの非可逆パイプライン

具体的な例として、セキュリティ欠陥が破滅を招く「決済トランザクション処理」を実装する。

要件は以下の通りだ。
1. トランザクションは `Draft` $\to$ `Authorized` $\to$ `Settled` の順でしか遷移できない。
2. `Authorized` 状態でなければ `capture()`（売上確定）を実行できない。
3. すべての不正な遷移は、コンパイル時（`hh_client`の実行フェーズ）に型エラーとして捕捉され、実行時バイナリは生成されない。

1. 状態マーカーとOpaque Type（不透明型）の定義

まず、状態を表現する幽霊型と、コンストラクタの不正呼び出しを防ぐための`newtype`を定義する。

//// States.hack
namespace Architecture\Security\Transaction;

// 状態マーカーインターフェース（インスタンス化は不要）
interface IState {}
abstract final class DraftState implements IState {}
abstract final class AuthorizedState implements IState {}
abstract final class SettledState implements IState {}

//// TransactionId.hack
namespace Architecture\Security\Transaction;

// TransactionIdをOpaque Typeとしてカプセル化（プリミティブ型への退行を阻止）
newtype TransactionId = string;

function createTransactionId(string $id): TransactionId {
// ここで正規表現バリデーション等の厳密なチェックを実施
return $id;
}

2. Phantom Typeを内包したコアエンジンの構築

//// Transaction.hack
namespace Architecture\Security\Transaction;

final class Transaction {
// 外部からの直接インスタンス化を完全に遮断
private function __construct(
private TransactionId $id,
private int $amountInCents,
private ?string $authCode = null,
) {}

// 1. 初期状態 (Draft) の生成
public static function createDraft(
TransactionId $id,
int $amountInCents,
): Transaction {
return new self($id, $amountInCents);
}

// 2. Draft -> Authorized への状態遷移
public static function authorize(
Transaction $tx,
string $authCode,
): Transaction {
// 状態を昇格させた新しい型インスタンスを返す
return new self(
$tx->id,
$tx->amountInCents,
$authCode,
);
}

// 3. Authorized -> Settled への状態遷移
public static function settle(
Transaction $tx,
): Transaction {
return new self(
$tx->id,
$tx->amountInCents,
$tx->authCode,
);
}

// 4. Authorized状態でしか呼べないビジネスロジック
public function getAuthorizationCode(
// 呼び出し元の型がAuthorizedStateであることを静的に強制
): string where TState = AuthorizedState {
return $this->authCode as nonnull;
}

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

public function getAmount(): int {
return $this->amountInCents;
}
}

3. 型検証による不正オペレーションの拒絶

このシステムを呼び出すクライアントコードを見てみよう。

//// Pipeline.hack
namespace Architecture\Security\Transaction;

function executePaymentPipeline(): void {
$id = createTransactionId(“tx_987293847293”);
$draftTx = Transaction::createDraft($id, 50000);

// 【正常系】コンパイルをパスする
$authorizedTx = Transaction::authorize($draftTx, “AUTH_TOKEN_XYZ_123”);
$settledTx = Transaction::settle($authorizedTx);

// —————————————————-
// 【異常系 1】未認可のDraftを直接Settleしようとする
// —————————————————-
// 型チェッカーは以下のエラーを吐いてビルドを即座に落とす:
// “Invalid argument: Expected Transaction, got Transaction”
/
Transaction::settle($draftTx); // <- 型チェッカーがコンパイルをブロック / // ---------------------------------------------------- // 【異常系 2】Draft状態から不正にAuthCodeを取得しようとする // ---------------------------------------------------- // "A where type constraint is violated here: Expected AuthorizedState, but got DraftState" / $draftTx->getAuthorizationCode(); // <- 型チェッカーがコンパイルをブロック / } ---

低レイヤ最適化とメモリフットプリント：HHVMの視点

シニアエンジニアが最も懸念するのは、「型を分けたことによるオブジェクトのアロケーションコストや、ランタイムの型解決オーバーヘッドではないか？」という点だろう。

結論から述べると、HHVMにおいてPhantom Typesの実行時オーバーヘッドは完全にゼロ（$0$ bytes / $0$ cycles）である。

1. 型消去（Type Erasure）とHHBC（HHVM Bytecode）

Hackの型検査は、ビルド時（`hh_client`）にのみ実行される。型チェッカーをパスすると、HHVMのコンパイラフロントエンドはジェネリクス型パラメータを完全に消去（Type Erasure）してバイトコード（HHBC）を出力する。

// compile: Transaction::createDraft のバイトコード概要
.main {
// …
FPushClsMethodD 2 “createDraft” “Architecture\\Security\\Transaction\\Transaction”
// …
FCall <> 2 1 “” – “”
// 返されるのは単なる Transaction オブジェクトであり、
// メモリ上に TState のメタデータは一切ロードされない
}

2. オブジェクトメモリレイアウトとTypedValue

HHVMのランタイムメモリにおいて、オブジェクトはC++の`ObjectData`構造体をベースにアロケートされる。

Phantom Typeのパラメータ（`TState`）はプロパティスロットを1ビットも消費しない。実行時のメモリフットプリントは、型パラメータを持たない素のPHP/Hackクラスと完全に同一である。

3. JITコンパイラ（Vas / Tracelet）による最適化

HHVMのJITエンジンは、Traceletと呼ばれる実行トレースを解析し、中間表現（IR）を経て最適化されたネイティブマシンコード（x86_64 / AArch64）を生成する。

Phantom Typeによる状態遷移パイプラインは、JITにとっては単なる「同一メモリレイアウトを持つオブジェクトの再構築、またはインライン化可能な参照の受け渡し」に過ぎない。

`authorize()` メソッド呼び出しは、JITのインライナによって完全に展開される。
新しいインスタンス生成において、不要な中間オブジェクトはHHVM JITのエスケープ解析（Escape Analysis）によって検知され、スタックアロケーションへの降格またはレジスタへの直接マッピングが行われる。

実行時に`if ($this->state !== ‘AUTHORIZED’)`のような動的ガードが存在しないため、CPUの分岐予測器（Branch Predictor）を一切汚染せず、命令キャッシュ（I-Cache）の局所性を最大化できる。

—

hh_serverの型推論機構とセキュリティ境界の突破防御

セキュリティアーキテクチャの観点において、型システムをバイパスしようとする悪意ある実装や、ヒューマンエラーをいかに防ぐかが極めて重要となる。

[ ソースコード ]
│
▼
┌───────────────────────────┐
│ hh_server: Decl フェーズ │ ── 型宣言の抽出
└───────────────────────────┘
│
▼
┌───────────────────────────┐
│ hh_server: Typing フェーズ│ ── Phantom Type & 制約の静的検証
└───────────────────────────┘
│
┌────────────────┴────────────────┐
[ 型エラー ] [ 検証通過 ]
│ │
▼ ▼
ビルド完全停止 ┌───────────────────┐
│ HHVM JIT コンパイラ │
└───────────────────┘
│
▼
ネイティブ機械語
(実行時型チェックなし・最速)

1. `HH_FIXME` やアンセーフキャストの無効化

開発者が意図的に型安全性を破壊する（例: `/ HH_FIXME[4110] /` の乱用）リスクに対しては、`.hhconfig`によるグローバルな規制を敷く。

// .hhconfig
strict_mode = true
disallow_unsafe_blocks = true
ignored_fixmes = 4110, 4341

これにより、Phantom Typesでカプセル化された不変条件の突破はコンパイル時に検知され、CI/CDパイプライン上で完全に遮断される。

2. デシリアライズ攻撃に対する多層防御

Phantom Typesの唯一の境界的弱点は、「外部入力（JSONやリレーショナルDB）からオブジェクトを再構築する瞬間」にある。型情報はランタイムに存在しないため、復元時に誤った状態型を付与するとシステムが汚染される。

これを防ぐため、デシリアライザは必ずファクトリ関数の閉包内に閉じ込め、バリデーションと型付与をアトミックに結合する。

namespace Architecture\Security\Transaction;

abstract final class TransactionFactory {
public static function restoreFromStorage(
TransactionId $id,
int $amount,
?string $authCode,
string $persistedState,
): (
(?Transaction) |
(?Transaction) |
(?Transaction)
) {
// 実行時の値の検証と、静的 Phantom Types の厳密なマッピング
switch ($persistedState) {
case ‘DRAFT’:
return tuple(Transaction::createDraft($id, $amount), null, null);
case ‘AUTHORIZED’:
if ($authCode is nonnull) {
$draft = Transaction::createDraft($id, $amount);
return tuple(null, Transaction::authorize($draft, $authCode), null);
}
break;
case ‘SETTLED’:
if ($authCode is nonnull) {
$draft = Transaction::createDraft($id, $amount);
$auth = Transaction::authorize($draft, $authCode);
return tuple(null, null, Transaction::settle($auth));
}
break;
}
throw new \UnexpectedValueException(“Invalid state transition in storage.”);
}
}

呼び出し側はHackの型推論（Type Refinement）によって、どの状態型が返されたかを網羅的に処理（Exhaustive Check）せざるを得なくなる。

—

結論: 型を計算資源として使い倒す

Phantom Typesは、単なるアカデミックな型理論の産物ではない。

それは、「実行時コストをゼロに抑え込みながら、プログラマの認知限界とセキュリティホールの発生をコンパイラレベルで完全に物理遮断する」ための、極めて実践的で強固なエンジニアリング・パラダイムである。

1. ビジネスルールの状態遷移を代数的データ構造として型チェッカーに教え込む。
2. 実行時バリデーションのオーバーヘッドをJITパイプラインから根絶する。
3. 不正なコードパスの生成そのものをコンパイル時に拒絶する。

Hackの厳格型システムを真に掌握したアーキテクトは、テストコードの量で品質を誇らない。「型チェックを通過した時点で、脆弱性が存在し得ない構造」を作り上げることこそが、極限のシステムアーキテクチャが目指すべき終着点である。