はじめに：なぜ `mixed` は「悪魔の囁き」なのか
PHPからHackへの移行期において、多くの開発者が甘美な妥協点として利用するのが `mixed` 型です。
「とりあえずコンパイルを通したい」「サードパーティのAPIレスポンスの構造が不安定だから」といった理由で `mixed` を散りばめることは、一時的な鎮痛剤にはなります。しかし、それは型安全性の破滅へのスライディングスタートに過ぎません。
Hackの静的型チェッカー（`hh_client`）は、世界最高峰の推論エンジンを持っています。しかし、型チェッカーに `mixed` を渡した瞬間、チェッカーは思考を放棄します。`mixed` とは「何が来ても文句は言わないが、そこから先は一切の保証をしない」という、静的型付けの世界におけるアナーキズム（無政府状態）の表明だからです。
さらに深刻なのは、HHVM（HHVM Virtual Machine）のJITコンパイラに対する裏切りです。HHVMは、静的型情報を手がかりにして極限まで最適化されたネイティブマシンコードを生成します。`mixed` の乱用は、このJITコンパイラの翼を捥ぎ取るに等しい行為です。
本稿では、レガシーなPHPコードベースから `mixed` を徹底的に排除し、完全な Strict Mode へと引き上げるための実践的かつ極限のロードマップを提示します。HHVMの内部構造にまで踏み込み、なぜ `mixed` が悪なのか、そしてそれをどうエレガントに駆逐すべきかを解説します。
—
1. HHVMの深淵：`mixed` が引き起こすパフォーマンスの代償
リファクタリングの手を動かす前に、まずは「なぜ `mixed` が遅いのか」をメモリとCPU命令のレベルで理解しましょう。
1.1 `TypedValue` のオーバーヘッド
HHVMの内部において、すべての変数は `TypedValue` というC++の構造体で表現されます。
// HHVM内部における概念的な値の表現
struct TypedValue {
Value m_data; // 実際のデータ（ポインタ、64bit整数など）
DataType m_type; // 型を示す1バイトのタグ（KindOfString, KindOfInt64 など）
};
静的型チェッカーによって型が完全に1つ（例えば `int` や `string`）に特定されている場合、HHVMのJITコンパイラは `m_type` のチェック（型ガード：Type Guard）を省略し、直接 `m_data` をCPUレジスタにロードして演算命令を発行できます。
しかし、型が `mixed` の場合、JITコンパイラは実行時に毎回 `m_type` を検証する条件分岐コード（Type Guard）を挿入せざるを得ません。
mixed型の場合にJITが生成せざるを得ない冗長なアセンブリ命令のイメージ
cmp byte ptr [rdi+8], KindOfInt64 ; 型がIntかチェック
jne .L_bailout ; 違っていれば型復元スローパス（低速）へジャンプ
mov rax, [rdi] ; 実際の値を取り出す
この分岐予測ミス（Branch Misprediction）の頻発と、命令キャッシュの汚染こそが、`mixed` がシステム全体の静かなボトルネックとなる主因です。
—
2. `mixed` 排除のための3ステップ・ロードマップ
レガシーコードから `mixed` を排除するプロセスは、外科手術と同じです。無計画に型を厳しくすれば、コンパイルエラーの津波に溺れることになります。以下の3つのステップを戦略的に適用してください。
[Step 1: nonnull とジェネリクスによる境界画定]
│
▼
[Step 2: Shape型とDictによる構造化]
│
▼
[Step 3: Reified Genericsによる実行時・コンパイル時ハイブリッド防御]
Step 1: `nonnull` への段階的移行とジェネリクスによる境界画定
完全に型を特定できない場合でも、それが「`null` ではない何か」であることは保証できるケースが多々あります。その場合は `mixed` ではなく `nonnull` を使用します。
また、コレクションに対して `mixed` を使うのは今すぐやめましょう。ジェネリクス（`vec
Step 2: Shape型（`shape(…)`）による「構造なき連想配列」の破壊
PHPレガシーコードの諸悪の根源は `array`（連想配列）です。Hackではこれを `dict
キーと値のペアが静的に決まっているデータ構造は、すべて Shape型 に置き換えます。Shapeはコンパイル時にキーの存在と型を完全に検証します。
Step 3: Reified Generics と `as` / `is` 演算子による動的境界の突破
外部APIのレスポンスなど、どうしても実行時まで型が不確定な境界線（デシリアライズ処理など）では、Reified Generics（具現化されたジェネリクス） を使用します。これにより、コンパイル時の型消去（Type Erasure）を防ぎ、実行時にも厳密な型チェックをゼロ・オーバーヘッドに近い形で実現します。
—
3. 極限のプロダクションコード例：APIデシリアライザのリファクタリング
ここでは、実務で頻出する「外部APIから取得したJSON（不確定なデータ）をパースし、型安全なドメインオブジェクトに変換する」というユースケースを実装します。
❌ Before: レガシーなPHP臭の残る `mixed` 塗れのコード
まずは、リファクタリング対象の「悪いコード」です。一見動くように見えますが、型チェッカーを騙すための `/ UNSAFE_EXPR /` や、実行時エラーの危険が潜む危険なコードです。
After: Strict Modeに準拠し、`mixed` を徹底排除した極限のHackコード
以下が、Strict Mode（`
/
namespace HackHq\Refactoring;
/
- ユーザーデータの構造を静的に定義するShape。
- PHPの「なんでも入る連想配列」から「厳密な契約（Contract）」への昇華。
/
type UserProfile = shape(
‘id’ => int,
‘username’ => string,
‘email’ => string,
‘is_active’ => bool,
// オプションのフィールドは ? を付与し、nullを許容する
‘avatar_url’ => ?string,
);
/
- 実行時型検証を汎用化するためのヘルパークラス。
- Reified Generics（reify）を使用することで、ジェネリクスの型情報を実行時まで維持する。
/
final class TypeValidator {
/
- 与えられた値が、指定された型 T に適合するかを実行時に厳密に検証する。
- 適合しない場合は例外を投げる。これにより mixed を型安全な具体的な型 T に昇華させる。
/
public static function assertType
// is 演算子は reify されたジェネリクスに対して実行時に機能する
if ($value is T) {
return $value;
}
throw new \InvalidArgumentException(
\sprintf(
‘Type validation failed. Expected %s, got %s’,
// 実行時型情報を文字列として取得
\HH\ReifiedGenerics\get_type_structure
|> \HH\TypeStructure\to_string($$),
\gettype($value),
),
);
}
}
/
- APIレスポンスパーサーの極限形。
- mixedの侵入を玄関（エントリーポイント）で防ぎ、内部は100%型安全に保つ。
/
final class UserParser {
/
- 外部からの入力は string に制限。
- 返り値は `mixed` ではなく、厳密に定義された `UserProfile` Shape型。
/
public static function parseResponse(string $jsonRaw): UserProfile {
// json_decode の返り値は、Hackの標準ライブラリでは dynamic または mixed になる。
// これを即座に構造化された dict に変換する。
$decoded = \json_decode(
$jsonRaw,
/ associative = / true,
/ depth = / 512,
\JSON_FB_HACK_ARRAYS, // HHVM独自の高速なHack Array（dict/vec）返却フラグ
);
// デコード失敗、または dict でない場合は即座に排除
if ($decoded === null || !$decoded is dict<_, _>) {
throw new \RuntimeException(‘Invalid JSON response format.’);
}
// ここで、不確定な dict から UserProfile Shape へのマッピングを行う。
// Shapeのコンストラクタ内で、各要素の型チェックを静的かつ動的に行う。
try {
return shape(
‘id’ => TypeValidator::assertType
‘username’ => TypeValidator::assertType
‘email’ => TypeValidator::assertType
‘is_active’ => TypeValidator::assertType
// nullを許容するオプションフィールドの処理
‘avatar_url’ => $decoded[‘avatar_url’] is string ? $decoded[‘avatar_url’] : null,
);
} catch (\Exception $e) {
throw new \RuntimeException(
\sprintf(‘Failed to parse UserProfile: %s’, $e->getMessage()),
0,
$e,
);
}
}
}
—
4. なぜこの設計が圧倒的に優れているのか？（コード解説）
このリファクタリングコードには、HHVMとHackの型システムを掌握するためのエッセンスが凝縮されています。
① `reify`（具現化ジェネリクス）による型消去（Type Erasure）の克服
通常のジェネリクスは、コンパイルが通った後に「ただの `mixed`」に消去されてしまいます。しかし、`reify` キーワードを付与することで、HHVMは実行時にもその型情報を保持します。
`TypeValidator::assertType
② `JSON_FB_HACK_ARRAYS` の活用
`json_decode` の第4引数に指定した `JSON_FB_HACK_ARRAYS` は、HHVM特有の非常に強力な最適化フラグです。PHP由来のレガシーな `array` ではなく、ネイティブな `dict` / `vec` を直接生成するため、メモリフットプリントを最小限に抑え、その後の型判定の処理速度を劇的に向上させます。
③ Shape型による静的契約
戻り値を `UserProfile` というShape型に束縛したことで、このメソッドを呼び出す側は以下のような「型安全な恩恵」を100%享受できます。
$user = UserParser::parseResponse($json);
echo $user[‘username’]; // 100% stringであることが保証されている。IDEの補完も完璧に効く。
// echo $user[‘typo_key’]; // <- このコードは hh_client が静的にコンパイルエラーとしてはじく！
---
おわりに：テクニカルリードからあなたへ
`mixed` をコードベースから追放する作業は、一見すると地味で、時にコンパイルエラーとの果てしない戦いに見えます。
しかし、`mixed` を一つ消すごとに、あなたのアプリケーションは堅牢になり、実行速度が向上し、何より「予測可能」なシステムへと進化します。
「動いているから触らない」は、レガシーを放置する言い訳に過ぎません。テクニカルリードとして、私はチームにこう求めます。「境界線で型を縛れ。不確実性をドメインの内部に持ち込むな」。
このロードマップと設計パターンを武器に、あなたのコードベースを真の型安全（Strict Mode）へと導いてください。HHVMはその圧倒的なパフォーマンスをもって、あなたの挑戦に報いてくれるはずです。