こんにちは。日々のWebアプリケーション開発、本当にお疲れ様です。
JavaやC#、あるいはTypeScriptといった静的型付けの世界からやってきた開発者の多くが、PHP 8で導入された「共用体（Union Types）」を見て、こう思うかもしれません。「これでやっと安全なコードが書けるようになった」と。
function process(int|string $value): void {
// …
}
たしかに、開発時のIDE補完や静的解析の恩恵は計り知れません。しかし、Webシステムアーキテクトとして一歩踏み込み、「このコードがPHPのランタイム（Zend Engine）の内部で、1リクエストあたりのCPUサイクルをどれだけ消費しているか」を考えたことはあるでしょうか？
「たかが型チェックの分岐くらい、大したオーバーヘッドにはならないだろう」
そう高をくくっていると、秒間数千リクエストをさばく高負荷なAPIサーバーを構築した際、CPU使用率の壁に直面することになります。
今回は、PHP 8.xにおけるUnion Typesが、内部のZend VM（Zendバーチャルマシン）でどのようにオペコード（Opcode）に翻訳され、JIT（Just-In-Time）コンパイラによっていかにしてマシン語に落とし込まれるのか。その低レイヤの真実を、一緒に紐解いていきましょう。ここを理解すれば、PHPの裏側が驚くほど美しく見えてきますよ。
—
1. Zend VMの視点：Union Typesは「実行時コスト」の塊である
まず大前提として知っておくべきなのは、PHPは動的言語であるという事実です。たとえ私たちが `int|string` と厳格に型を宣言しても、Zend Engineは実行時（Runtime）までその変数の具象型を完全に確定させることはできません。
PHPの内部において、すべての変数は `zval`（Zend Value）というC言語の構造体で表現されています。PHP 8の `zval` は16バイトの固定長ですが、その中には値の実体（あるいはポインタ）と、それが今どの型であるかを示す `u1.v.type` というフラグが含まれています。
Union Typesを指定した関数に引数が渡されたとき、Zend VMは裏側で何をしているでしょうか？ 単純な単一型（例: `int` のみ）であれば、エンジンの型チェックはC言語レベルのビット演算（マスク比較）一発で終わります。しかし、Union Typesになると話が変わります。
オペコードレベルでの型チェックの迷宮
次のようなコードを考えてみましょう。
function calculate(int|float $a): int|float {
return $a 2;
}
このコードがコンパイルされると、Zend VMの実行プロセスにおいて、引数の受渡し時に次のような判定ロジック（概念的な疑似コード）が毎回実行されます。
1. 変数 `$a` の `zval` の型フラグを見る。
2. それが `IS_LONG`（整数）か？ → YESならそのまま演算へ。
3. NOなら、それが `IS_DOUBLE`（浮動小数点数）か？ → YESなら演算へ。
4. どちらでもなければ、`TypeError` 例外をスローするためのハンドラを呼び出す。
つまり、許容する型が増えれば増えるほど、VMが評価すべき条件分岐のパスが線形（あるいはそれ以上）に増加するのです。特に、深いループの中で何度も呼び出されるヘルパー関数や、シリアライズ処理の内部でUnion Typesを多用すると、この「型のゆらぎを解決するためのコスト」が積もり積もって、確実にCPUキャッシュを圧迫します。
—
2. JITコンパイラはUnion Typesをどう救うのか？
「じゃあ、PHP 8のJITを有効にすれば、このオーバーヘッドはすべて消えるの？」
という疑問が湧くはずです。答えは「条件付きで、劇的に速くなる」ですが、JITの挙動原理を知らないと恩恵を受けることはできません。
PHP 8で導入されたJIT（DynASMをベースにしたもの）は、トレーシングJIT（Tracing JIT）と呼ばれる方式を採用しています。これは、プログラムの実行プロファイルを監視し、「何度も繰り返し実行されるホットループ（Hot Trace）」を見つけ出すと、そのパスをネイティブのマシンコード（x86_64の機械語など）にコンパイルしてCPUに直接実行させる仕組みです。
プロファイルガイド最適化（PGO）の魔術
JITが有効な環境下で、先ほどの `int|float` のようなUnion Typesを持つ関数が繰り返し呼び出されると、JITは次のような最適化を行います。
1. 型のプロファイリング: 最初はZend VM上で実行されますが、JITは「この関数に渡される `$a` は、99%のケースで `int` である」という実行時統計を収集します。
2. ガード（Guard）の生成: マシンコードの先頭に、「もし `$a` が `int` なら最適化された高速パスへ進む。もし `int` 以外（例: `float`）だったら、安全なスローパス（元のVMの処理）へフォールバックする」という軽量なガード命令を埋め込みます。
この状態になると、`int` が渡される限り、C言語の関数呼び出しや重い型判定のオーバーヘッドは完全に消え去り、CPUのパイプラインを止めることなく超高速に処理されます。
しかし、ここに大きな罠があります。
もしあなたが、1つの関数に対して `int`、`string`、さらにはカスタムオブジェクトなどをランダムに混ぜて渡し続けた場合（真の意味でのポリモーフィックな呼び出し）、JITのプロファイラは「型が特定できない（Monomorphic化できない）」と判断します。結果として、JITは高速なマシンコードの生成を諦め、遅い汎用的なコードにフォールバックするか、あるいはコンパイルのオーバーヘッドだけが残る最悪のシナリオ（Megamorphic状態）に陥ります。
—
3. 実務で活かす：パフォーマンスを極限まで引き出す設計指針
ここまでの低レイヤの挙動を踏まえると、モダンなPHP 8アプリケーションにおいて、Union Typesとどう向き合うべきかが見えてきます。
指針 A: ホットパス（Hot Path）での複雑なUnion Typesを避ける
フレームワークのコアロジック、ORMのマッピング層、あるいは毎リクエスト何千回も回るドメインロジックのループ内では、極力Union Types（特に `int|string|object` のような異質な型の混合）を避けてください。
// 悪い例：ホットパス内で毎回型のゆらぎが発生し、JITの恩恵を受けにくい
function processRecord(int|string|null $id): void {
// …
}
// 良い例：型をあらかじめ正規化（Casting）するか、メソッドを分割する
function processRecordInt(int $id): void {
// …
}
function processRecordString(string $id): void {
// …
}
指針 B: 「値オブジェクト（Value Object）」への昇華
もし複数の型を受け入れる必要がある場合、それをプリミティブなUnion Typesでダラダラと処理するのではなく、カプセル化された小さなオブジェクト（値オブジェクト）として抽象化することを検討してください。
// プリミティブなUnion Typesの乱用
function setCoordinate(int|float $x, int|float $y): void {}
// 堅牢なオブジェクト指向（JITにとっても、型がオブジェクトとして静的に確定しやすくなる）
readonly class Coordinate {
public function __construct(
public float $x,
public float $y
) {}
}
function setCoordinate(Coordinate $coordinate): void {}
「オブジェクトにするほうがメモリやインスタンス生成のコストが高そう」と思われるかもしれませんが、PHP 8.xの `readonly` クラスやコンストラクタプロモーションは非常に最適化されており、JITの型推論（Type Inference）の精度を大きく向上させるため、結果的にトータルの実行時間が短縮されるケースが多々あります。
—
おわりに
PHPのUnion Typesは、コードの安全性と開発者体験を飛躍的に高めてくれた素晴らしい機能です。しかし、それは魔法の杖ではありません。
その背後では、Zend VMが懸命に `zval` の型タグを読み解き、JITが実行時プロファイルから「型の予測」という名の賭けを行っています。
「なぜこのコードは少し遅いのか？」
「どうすればこのループをJITに最速でコンパイルさせられるか？」
頭の中でZend Engineのメモリ空間とオペコードの流れをトレースできるようになれば、あなたはもう単なる「PHPプログラマー」ではなく、PHPという仮想マシンを手の内で操る真のWebシステムアーキテクトです。
今日の知見が、あなたの書くコードを一段上のレイヤへと導くスパイスになれば幸いです。それでは、また次回の深淵な世界でお会いしましょう。