こんにちは。普段からPHPを使った大規模なWebシステムの設計や、パフォーマンスチューニングに頭を悩ませていることと思います。他の言語（TypeScriptやJava、Goなど）を深く経験したエンジニアほど、PHP 8.xで導入された「共用体（Union Types）」を使うときに、「これって実行時にどれくらいのペナルティがあるんだろう？」と気になってしまうものですよね。
今回は、このUnion TypesがPHPのエンジン内部（Zend VM）でどのように扱われ、型チェックがどのようなコストを生んでいるのか、低レイヤのメモリ構造から徹底的に解き明かしていきましょう。ここを理解すると、PHPの裏側が驚くほど綺麗に見えるようになりますよ。
—
1. PHP 8のUnion Types：表面的な便利さの裏側
まずは、私たちが普段書いているコードを確認してみましょう。PHP 8.x以降、次のように複数の型を許容するシグネチャを平然と書けるようになりました。
/
public function process(int|string|Order $identifier): void
{
// 実行時に $identifier の型に応じた分岐が必要になる
if ($identifier instanceof Order) {
$identifier->execute();
} else {
// int または string の場合の処理
echo “Processing ID: ” . $identifier;
}
}
}
このコード自体は非常に直感的で、開発体験（DX）を大きく向上させてくれます。しかし、C言語で書かれたZendエンジン（Zend VM）の視点に立ってみると、話は少し変わってきます。動的言語であるPHPに「静的な型制約」を持ち込むということは、エンジンに対して「実行時の型安全性を担保するための追加コスト」を支払わせているということなのです。
—
2. Zend VMにおける変数の正体：`zval` と型情報の密な関係
PHPのすべての変数は、Zendエンジン内部において `zval`（Zend Value） というCの構造体（struct）としてメモリ上に存在します。
PHP 7以降の `zval` は16バイトに最適化されており、その構造は概ね以下のようになっています。
- 値自体（8バイト）: 整数、浮動小数点、あるいはポインタ（文字列、配列、オブジェクトなど）
- 型情報・フラグ（4バイト）: この変数が何であるかを示す識別子（`IS_LONG`, `IS_STRING`, `IS_OBJECT` など）
- ガベージコレクション等の管理情報（4バイト）
PHP 5時代のような「何でも入る重いコンテナ」から脱却し、現代のPHPは `zval` の型タグ（Type Tag）を高速に参照することでパフォーマンスを維持しています。
Union Typesが指定されたときのZendエンジンの挙動
では、`int|string|Order` のようなUnion Typeが関数やメソッドの引数に指定された場合、Zendエンジンはコンパイル時（オペコード生成時）と実行時（オペコード実行時）に何を行っているのでしょうか。
1. コンパイル時:
関数やメソッドの内部構造体（`zend_function`）に、許容される型情報のビットマスクや型リストがメタデータとして記録されます。
2. 実行時（コール時）:
引数が渡された瞬間、Zend VMは「渡された `zval` の型タグ」と「あらかじめ定義されたUnionの型リスト」を照合（Type Check）します。
もし厳格な型付け（`declare(strict_types=1);`）が有効な場合、エンジンは暗黙の型変換（ coercion ）をスキップするため、チェック処理自体は比較的シンプル（単純な型の一致判定）で済みます。しかし、これが無効な場合、PHPは伝統的な「柔軟な型変換」を試みようとするため、内部で複雑なフォールバック判定が走り、確実にCPUサイクルを消費します。
—
3. 型チェックのオーバーヘッドは実務で無視できるのか？
「じゃあ、Union Typesを多用するとサイトが遅くなるの？」という疑問が湧くはずです。
結論から言いましょう。一般的なWebアプリケーションのリクエストライフサイクルにおいて、Union Types自体の型チェックによるオーバヘッドは、データベースのI/Oや外部API通信、あるいはフレームワークのコンテナ解決コストと比較すれば、完全に「誤差」の範囲です。
しかし、次のような極限のパフォーマンスが求められるホットスポット（Hotspot）では話が変わってきます。
- 数万件のループ内で毎回呼び出されるドメインモデルのゲッターやセッター
- ハイパフォーマンスなフレームワークのルーターやDIコンテナの内部処理
- シリアライザやパーサーなど、CPUバウンドな処理のコアロジック
ベンチマーク的な思考：単一型 vs Union型
次のような2つのメソッドを比較してみましょう。
「型ガード（Type Guard）」と呼ばれる分岐コードを生成せざるを得なくなります。結果として、CPUの分岐予測が外れるリスク（Branch Misprediction）や、生成される機械語のフットプリント（コードサイズ）が増大し、キャッシュ効率がわずかに低下するのです。
—
4. アーキテクトとして心得ておきたい設計の極意
ここまでの低レイヤの挙動を踏まえて、私たちWebシステムアーキテクトはどのようにコードを設計すべきでしょうか。
1. 「何でも受け取れる便利さ」の代償を意識する
Union Typesは、異なるレイヤーの境界（例えば、外部からのリクエスト入力を受け取るコントローラーやDTOなど）で使う分には、コードの表現力を高める素晴らしい機能です。しかし、アプリケーションのコアロジック（ドメイン層など）の奥深くまでUnion Typesを持ち込むのは避けるべきです。コアロジックは常に「型が綺麗に保たれた単一の世界」であるべきです。
2. オーバーヘッドの発生場所を見極める
「Union Typesを使うと遅くなるから使うな」という極端な話ではありません。ボトルネックになるのは「数百万回実行される極限のループ内」であって、通常のWebリクエストごとの数回の関数呼び出しではありません。プロファイラ（XdebugやBlackfireなど）で計測し、本当にそこがホットスポットである場合を除いては、DX（開発効率）と保守性を優先して問題ありません。
3. JITと静的解析の恩恵を最大化する
PHP 8.xのJITや、PHPStan / Psalmといった静的解析ツールを組み合わせる場合、Union Typesを適切に使うことで、実行時ではなく「静的解析の段階」でバグを潰すことができます。実行時のわずかなオーバーヘッドを恐れてコードの意図が曖昧になる（例えば、mixedや余計なキャストを乱用する）方が、結果としてバグの温床になり、システム全体の品質を下げてしまいます。
—
まとめ
いかがでしたでしょうか？
- PHPの変数は `zval` という構造体で管理されており、Union Typesは実行時に型の照合コストを生む。
- 厳格な型付け（`declare(strict_types=1);`）を併用することで、無駄な暗黙の型変換コストを排除できる。
- JITコンパイラは型が単一であるほど強力な最適化を行えるため、Union Typesは「適用する場所（境界）」を意識することが重要。
PHPは単なる「お手軽なスクリプト言語」から、内部構造を理解して使いこなすことで極限までパフォーマンスを引き出せる「洗練されたWebアプリケーションプラットフォーム」へと進化しています。
裏側の仕組みを解き明かしていくと、日々のコーディングがさらに楽しく、そして確信に満ちたものになりますよね。あなたのアーキテクチャ設計の引き出しに、今日の知識が少しでも役立てば幸いです。