こんにちは。普段、JavaやGo、TypeScriptといった厳格な型システムを持つ言語からPHPへ入ってきた優秀なエンジニアほど、こんな疑問を持ったことはありませんか？
「PHP 8で待望のUnion Types（共用体型）が導入され、`int|string` のように柔軟な型定義ができるようになったけれど……これ、実行時に重くなっていないのだろうか？ 動的型付け言語のオーバーヘッドがそのまま残っているのでは？」
とても鋭い着眼点ですね。他のモダン言語の裏側を知っているからこそ浮かぶ、極めてエンジニアリング的な疑問です。結論から言いましょう。その直感は大正解です。PHPがどれほどJITコンパイラを搭載し、モダンに進化しても、動的言語である以上、型チェックのコストとは常に背中合わせです。
今回は、PHP 8.xにおけるUnion Typesが、Zendエンジン内部のメモリ空間（HashTableやzval）でどのように表現され、実行時にどれほどの型チェックコストを支払っているのかを、一緒に覗いてみましょう。ここを理解すると、PHPコードのパフォーマンスチューニングに対する視野がガラリと変わりますよ。
—
1. PHPの基本単位 `zval` と型情報の正体
まず、PHPのメモリ管理の基本である `zval`（Zend Value）構造体についておさらいしましょう。PHPの変数はすべて、この `zval` というC言語の構造体に包まれてメモリ上に存在します。
Zend VMの内部において、`zval` は「値そのもの」と「型のフラグ（u1.v.type）」をセットで持っています。PHP 7以降、`zval` は64ビット（8バイト）のポインタサイズまたはプリミティブ値を格納できるように最適化され、非常にスマートになりました。
// Zend/zend_types.h の概念的なイメージ
typedef struct _zval_struct {
zend_value value; //実際の値（8バイト：整数、ポインタ、double等）
union {
struct {
ZEND_ENDIAN_LOHI_4(
zend_uchar type, // 現在の型（IS_LONG, IS_STRING など）
zend_uchar type_flags, // ガベージコレクション等のフラグ
zend_uchar u1,
zend_uchar u2
)
} v;
uint32_t type_info;
} u1;
union {
uint32_t next; // ハッシュ衝突時のチェイン等
uint32_t cache_slot; // キャッシュ用スロット
} u2;
} zval;
通常のスカラ値であれば、この `type` フィールドを見るだけで、エンジンは一瞬で型を判別できます。C言語的なswitch文のジャンプテーブルで処理できるため、極めて高速です。
—
2. Union Types (`int|string`) が導入されたときの内部の苦悩
では、ここに `int|string` のようなUnion Typesが絡むと、何が起きるでしょうか。
例えば、次のような厳密に型付けされた関数があるとします。
function processId(int|string $id): void {
// 処理
}
この関数に引数が渡された瞬間、Zendエンジンは以下のステップを踏む必要があります。
1. 渡された引数の `zval` の `type` を確認する。
2. その型が、関数のシグネチャで定義されたUnion Types（`int` または `string`）の許容リストに含まれているかを判定する。
3. もし含まれていなければ、`TypeError` 例外をスローする。
実行時コストの正体：分岐の増加
ここがポイントです。単一の型（例：`int` のみ）であれば、エンジンの型チェックは「一致するかどうか」の1回の比較（ビット演算など）で終わります。
しかし、Union Typesになると、可能性が複数（AまたはB、あるいはそれ以上）に広がります。C言語レベルの実行パスにおいて、以下のような条件分岐（if-elseの連鎖やビットマスク判定）がどうしても必要になります。
// 内部的な型チェックのイメージ（疑似Cコード）
if ((arg->u1.v.type == IS_LONG) || (arg->u1.v.type == IS_STRING)) {
// 合格：処理続行
} else {
// 失敗：TypeErrorを投げるコストが発生
}
「たったこれだけの分岐なら大したことないのでは？」と思われるかもしれません。しかし、これが何百万回とループするホットパス（Hot Path）や、フレームワークのルーティング層、ORMのデータ水揚げ処理の内部で大量に実行されると、CPUの分岐予測（Branch Prediction）ミスを誘発し、確実にパフォーマンスの足枷になります。
—
3. JITコンパイラはこれをどう最適化するか？
「じゃあ、PHP 8のJITが有効なら、このオーバーヘッドは消してくれるの？」という疑問がわきますよね。
JIT（Just-In-Time Compiler）は、バイトコード（Opcode）をネイティブの機械語（x86/ARMのCPU命令）に翻訳します。
単一の型が保証されている場合、JITは型チェックを完全にスキップし、直接CPUの加算命令やメモリ参照命令に置き換えることができます（これをType Specializationと呼びます）。
しかし、Union Typesの場合、JITであっても「どちらの型が来ても対応できるようにガード（Guard）を張る」か、「型ごとの処理に分岐するコード（Polymorphic Inline Cache的なもの）を生成する」必要があります。
結果として、Union Typesを使うことで、JITが生成するネイティブコードのサイズが膨らみ、CPUキャッシュ（L1iキャッシュ）のヒット率が下がるというトレードオフが生じるのです。
—
4. アーキテクトとして知っておくべき実務上の設計指針
「なんだ、じゃあUnion Typesは遅いから使わないほうがいいの？」という極端な話ではありません。PHPという言語が提供する開発者体験（DX）の向上と、実行時コスト（Performance）のバランスをどう取るかという、Webアーキテクトの腕の見せ所です。
現場で意識すべき実践的なプラクティスをいくつか共有しましょう。
① ホットパスでの過剰なUnion Typesを避ける
例えば、数万件のレコードを処理するバッチ処理の内部関数や、毎リクエスト必ず通過する低レイヤのミドルウェア層では、無駄に `int|string|null` のような広いUnion Typesを使わず、型をシャープに絞り込みましょう。
// 改善前：何でも受け取れるが、エンジン内部の判定コストが増える
function calculate(int|float|string $val) { … }
// 改善後：極力型を統一し、呼び出し側で正規化する
function calculate(int $val) { … }
② `mixed` 型の濫用は最大の敵
`mixed` は、実質的に「すべての型のUnion Types」と同義です。これを多用すると、Zendエンジンは最適化の放棄を余儀なくされ、あらゆる箇所で動的な型チェックのオーバーヘッドが発生します。型安全性を高めるためのUnion Typesと、単なる怠惰な `mixed` は、内部的な負荷が全く異なることを覚えておいてください。
—
最後に：PHPの裏側を愛するということ
いかがでしたでしょうか？
「なぜこの書き方をすると少し遅くなるのか」「エンジンはメモリ上でどう動いているのか」。こうした低レイヤのストーリーを知っていると、コードを書くときの視点が変わってきますよね。
PHPは、動的言語の手軽さを持ちながら、裏側ではC言語の限界と戦いながら必死に高速化を成し遂げている、非常にエキサイティングなプロダクトです。
「ここをこう書けば、Zend VMが微笑んでくれるはずだ」——そんな職人技的な視点を持ちながら、ぜひ次のモダンなPHPコードを書いてみてください。あなたのWebアプリケーションは、一歩先を行く洗練されたシステムに生まれ変わるはずです。