こんにちは！Hack言語の世界へようこそ。フルスタックエンジニアの先輩として、今日は皆さんにHackの静的型システムの真髄、そしてプロダクトの安全性を極限まで高める『Phantom Types（ファントム型）』という強力な武器についてお伝えしますね。
他の言語からHackに来た開発者の中には、「なんでこんなに型にうるさいんだろう？」と感じる人もいるかもしれません。でも大丈夫。ここをクリアすれば、あなたの書くコードの安全性と美しさは見違えるほど跳ね上がりますよ。
今日も一緒に、Hackの深淵を楽しく覗いていきましょう！
—
1. 実行時チェックの限界と、私たちが抱えるモヤモヤ
Webアプリケーションを作っていると、こんなコードをよく書きませんか？
<<__Strict>>
namespace HackMaster;
class Order {
// 状態を文字列やフラグで管理しているよくある例
private string $status = ‘cart’;
public function addItem(string $item): void {
if ($this->status !== ‘cart’) {
throw new \Exception(“カートに入っている時しか商品を追加できません！”);
}
// 商品追加処理…
}
public function checkout(): void {
if ($this->status !== ‘cart’) {
throw new \Exception(“すでにチェックアウト済みです！”);
}
$this->status = ‘completed’;
// 決済処理…
}
}
このコード、一見普通に見えますよね。でも、型チェッカーの視点から見ると「何も保証されていない状態」です。
`$status` というたった一つの文字列変数に頼っているため、開発者がうっかり「決済済みの注文に対して商品を追加するメソッド」を別の場所で呼んでしまっても、型チェッカーはスルーしてしまいます。結果として、本番環境で例外が爆発する（あるいは最悪の場合、不正なデータがDBに書き込まれる）という悲劇が起きるわけです。
「この不正な操作、コンパイル（型チェック）の時点で絶対に検知できたらいいのに……」
それを鮮やかに解決するのが、Phantom Types（ファントム型）です。
—
2. Phantom Types（ファントム型）とは何か？
ファントム（幻影）という名前の通り、「実行時には何の意味も持たない（メモリ上にも存在しない）、しかし型チェッカーの目には厳然と映る型パラメータ」を指します。
イメージ図で考えてみましょう。
[通常のクラス]
Order —> 状態は実行時にif文でチェック（脆弱）
[ファントム型を適用したクラス]
Order
Order
Hackの強力なジェネリクス（Generics）と組み合わせることで、「状態が変わるたびに、全く別の型を持つ新しいオブジェクトに生まれ変わらせる」ことが可能になります。もちろん、不要になった古いオブジェクトはHHVMの優秀なガベージコレクタが適切に処理してくれますよ。
—
3. 実装コード：Hackで型による状態遷移を完全保証する
それでは、実際にHackの厳格モード（`<<__Strict>>`）でファントム型を実装してみましょう。ここが今日のハイライトです！
<<__Strict>>
namespace HackMaster;
// — 1. 状態を表すための「マーカー用クラス（ファントム）」 —
// これらはインスタンス化されることはありません。型チェックのためだけに存在します。
interface OrderState {}
class Cart implements OrderState {}
class Paid implements OrderState {}
// — 2. 状態を型パラメータ TState で縛った Order クラス —
class Order
// プライベートなコンストラクタで、外から直接インスタンス化させない
private function __construct(private vec
// 初期状態（カート）の注文を作るファクトリーメソッド
public static function createEmpty(): Order
return new Order(vec[]);
}
// カート状態の時だけ呼べるメソッド
public function addItem(string $item): Order
// 注目！内部で新しい Order を返しつつ、型は Cart のまま維持します
$newItems = Vec\concat($this->items, vec[$item]);
return new Order($newItems);
}
// カート状態から支払済み状態へ「遷移」させるメソッド
public function pay(): Order
// 支払い処理のシミュレーション…
// ここで Order
return new Order($this->items);
}
public function getItems(): vec
return $this->items;
}
}
// — 3. 実際の利用シーンと型チェッカーの挙動 —
function main(): void {
// カート状態の注文が誕生 (Order
$order1 = Order::createEmpty();
// 商品を追加 (Order
$order2 = $order1->addItem(‘Hack言語入門書’);
// 支払い完了！ ここで型が Order
$order3 = $order2->pay();
// 【コンパイルエラーになる例】
// 支払い済みの $order3 に対して、さらに addItem を呼ぼうとしてみる：
// $order4 = $order3->addItem(‘ステッカー’);
// -> エラー: No method ‘addItem’ in Order
}
このコードの美しさが伝わるでしょうか？
`$order3` は `Order
実行時エラーにおびえる日々は、今日で終わりです。
—
4. 陥りやすい文法エラーと注意点
Hackでファントム型や高度な型制約を扱う際、初心者がハマりがちなポイントをいくつかシェアしておきますね。
① 型制約（`as`）を忘れることによるバグ
`class Order
② ミュータブル（破壊的変更）とイミュータブル（不変）の混同
ファントム型は、基本的にイミュータブルな設計（状態を変えるたびに新しいインスタンスを返すスタイル）と非常に相性が良いです。
もし `$this->items[] = $item;` のようにオブジェクトの内部状態をその場で書き換えてしまうと、型が変わっているのに中身が壊れるという矛盾が生じます。Hackの標準ライブラリ（`vec` や `ImmMap` など）の不変性をうまく活用しましょう。
—
まとめ：型は「ドキュメント」であり「ガードレール」である
今回は、Hackの静的型システムとジェネリクスを応用した『Phantom Types』について解説しました。
- ビジネスルールやオブジェクトの状態を型レベルに昇華させる
- 不正な状態遷移をコンパイルエラーで完全にブロックする
- 実行時例外の不安から解放され、リファクタリングに圧倒的な自信を持てるようになる
Hackの厳格モード（`<<__Strict>>`）と型チェッカーは、あなたの邪魔をする厳しい上司ではありません。あなたの背中をガッチリと支えてくれる、世界で一番頼もしい相棒です。
ここをマスターしたあなたなら、どんなに複雑なドメインロジックが来ても怖くないはず。
さあ、次のコードではどんな状態を型で表現してみますか？ 一緒にHackの旅を楽しみましょう！