Hack型チェッカーの深淵：Nullable伝播のメカニズムと連鎖型エラーを断つ設計術
こんにちは。コードレビューの現場で「なぜこのコードは冗長で、HHVMの型システムにとって有害なのか」を説いて回っているテクニカルリードだ。
今日のテーマは、Hack言語における `<
型安全性を極限まで高めたはずの Strict モードで、なぜかあちこちに `?`（Nullable）が伝播し、コードベース全体が `if ($foo !== null)` の防壁だらけになっていないか？ 「とりあえず `io/` や外部 API からの入力を受け取るレイヤーだから」と、思考停止で `?` を下流へ垂れ流しているなら、今すぐその手を止めてほしい。
HHVMの型チェッカー（Typechecker）が裏側でどのように `null` のフローを追跡しているのか、その数学的・アーキテクチャ的背景を理解すれば、連鎖的な型エラーを最小化し、ランタイムのオーバーヘッドを削ぎ落とした美しいコンポーネント設計が見えてくるはずだ。
—
1. 型チェッカーは Nullable をどう追跡しているか？（フロー感応型解析の本質）
Hackの型チェッカーは、単なる静的な型アノテーションの突き合わせマシンではない。Flow-sensitive typing（フロー感応型解析） を実行し、コードの実行パス（Control Flow Graph: CFG）に沿って変数の型の状態変化を追跡している。
例えば、次のようなコードを考えてみよう。
<
namespace App;
function process_payload(?Payload $payload): void {
// この時点では $payload は ?Payload (Payload または null)
if ($payload === null) {
return;
}
// ここから先、型チェッカーは $payload を Payload と確定させる（Narrowing）
// だが、この後で別メソッドを挟むとどうなるか？
}
型チェッカーは、スコープ内での厳格な比較（`=== null`, `is` 演算子など）を検知すると、その分岐のコンテキストにおいて型の範囲を絞り込む（Type Narrowing）。
しかし、実務で問題になるのは 「Nullable の伝播（Propagation）」 だ。
データクラスやドメインモデルのプロパティに1箇所でも `?` が混入すると、それがゲッターを経由してサービス層、さらにプレゼンテーション層へと連鎖的に伝播していく。これが、いわゆる 「Nullable のドミノ倒し現象」 である。
—
2. なぜ「Nullable のドミノ倒し」は悪なのか？
1. 認知的負荷の増大: あらゆる場所で `null` チェックが必要になり、本質的なビジネスロジックがボイラープレートに埋もれる。
2. HHVMの最適化阻害: JITコンパイラ（Region JIT）は、型が完全に確定しているコードパス（Monomorphicな状態）に対して最も агрессивな（攻撃的な）最適化を行う。無駄な Nullable が残ると、型ガードのたびに分岐命令が増え、プロファイル情報の精度が落ちる。
3. 「存在しないはずの状態」の許容: ドメイン上、絶対に `null` であってはならない値が `?` で表現されている場合、それは設計の敗北を意味する。
—
3. 実践：連鎖的エラーを防ぐための型ガード配置と設計パターン
では、どのようにこの伝播を断ち切るべきか。
プロダクションコードで即座に使える、「境界での即時昇格（Immediate Promotion）」 パターンを示す。
外部入力やリポジトリ層という「汚染された境界（Dirty Boundary）」では `?` を許容するが、ドメインロジックの入り口で確実にバリデーションを行い、非 Nullable なオブジェクトへと昇格させる設計だ。
プロダクションコード例
<
namespace App\Domain;
/
- ユーザーのドメインモデル
- 不変（Immutable）であり、内部のプロパティは絶対に null を許容しない。
/
final class User {
public function __construct(
public string $id,
public string $email,
) {}
}
/
- 外部APIやDBからのレスポンス構造体（Nullableを許容する境界モデル）
/
type RawUserdataShape = shape(
‘id’ => ?string,
‘email’ => ?string,
);
class UserAssembler {
/
- 境界値（Nullableまみれの形状）を受け取り、
- 厳格なドメインモデルへ変換する。
- ここで Nullable の伝播を完全に断ち切る。
/
public static function fromRaw(RawUserdataShape $raw): User {
// 型ガードによる即時昇格と異常系ハンドリング
$id = $raw[‘id’];
if ($id === null || $id === ”) {
throw new InvalidUserPayloadException(‘User ID cannot be null or empty.’);
}
$email = $raw[‘email’];
if ($email === null || !self::isValidEmail($email)) {
throw new InvalidUserPayloadException(‘Invalid or missing email format.’);
}
// この瞬間に ?string から string へ確定し、
// 以降の下流コード（ドメイン層）に null が漏れ出すのを防ぐ
return new User($id, $email);
}
private static function isValidEmail(string $email): bool {
// 簡易的なバリデーションロジック
return C\contains($email, ‘@’);
}
}
class InvalidUserPayloadException extends \Exception {}
この設計の優位性
1. 型チェッカーの負担軽減: `User` インスタンスが生成された瞬間から、型チェッカーは `$user->id` が `string` であることを完全に把握できるため、下流のメソッドで無駄な `if ($user->id !== null)` を書く必要がなくなる。
2. Fail-Fast 原則の徹底: 不正なデータは境界の最前線で弾かれるため、アプリケーションの深部で予期せぬ `NullPointerException`（Hackでは `Typehint violation` や未定義プロパティアクセス）が発生するリスクを構造的に排除できる。
—
4. パフォーマンス上の注意点と HHVM アーキテクチャの視点
チーフアーキテクトとして、パフォーマンスについても言及しておこう。
Hackの型チェッカーは静的なものであり、コンパイル時（hhvmによるバイトコード生成時）に型情報は基本的に消去される（Erasure）。しかし、Strict モードにおける厳密な型アノテーションは、HHVMの TC（Translation Cache） において最適化ヒントとして強力に機能する。
- Nullable を放置した場合: 変数が `T` または `Null` のunion型として扱われ続けるため、メソッド呼び出し時に型チェックのオーバーヘッド（あるいはボックス化/アンボックス化のコスト）がブラックボックス的に発生しやすくなる。
- 早期に Nullable を排除した場合: JITコンパイラはそれを具象クラス（Concrete Class）またはプリミティブ型として直接レジスタに割り当てやすくなり、インライン化（Inlining）のチャンスが増大する。
—
5. リードからのまとめ：コードレビューで意識すべきチェックリスト
明日からのコードレビューでは、以下のポイントをチームメンバーに問いかけてほしい。
- [ ] 「この `?` は本当にドメイン上、存在しうる null か？」（単に「DBに入ってるかもしれないから」という理由で付けていないか？）
- [ ] 「境界から内部へデータが侵入する際、最初の防壁（Assembler/Validator）で非 Nullable に昇格できているか？」
- [ ] 「下流のメソッド群が、防衛的プログラミングの名のもとに無駄な `null` チェックを連鎖させていないか？」
型システムは、単にバグを防ぐためのガードレールではない。コードの意図を明確にし、HHVMのパフォーマンスを極限まで引き出すための最強の武器だ。
厳格な型とともに、美しいアーキテクチャを築き上げてくれ。