PHP 8.x Union Typesの内部構造と実行時コスト：Zend VMの視点から紐解く型安全の代償
コードレビューの場で、若手エンジニアから「PHP 8でUnion Types（共用体型）が導入されたおかげで、型安全かつ柔軟なドメインモデルが書けるようになりました！」という誇らしげなプルリクエストが提出されたとする。君ならどう返す？
「素晴らしい、これで保守性が上がるね」とマージボタンを押すなら、君はまだアプリケーション層のエンジニアに留まっている。Webシステムアーキテクトであれば、その背後でZend Engineが支払っている「実行時の代償」に思いを馳せなければならない。
PHP 8.xにおけるUnion Types（例: `int|string|null`）は、開発者の認知負荷を下げる一方で、Zend VMの内部表現と型チェック機構に確実なオーバーヘッドを持ち込んでいる。今回は、PHPコアのメモリ空間とオペコードの挙動を低レイヤから解剖し、実務でパフォーマンスを殺さないための設計ルールを伝授する。
—
1. 内部表現（Zend Engine）におけるUnion Typesの正体
PHPは動的型付け言語として産声を上げ、長年進化を続けてきた。その根幹にあるのが、あらゆる変数（Zval）を包み込むC言語の共用体（`union`）と構造体である。
PHP 8以前のZvalは、単一の型情報（`u1.v.type`）と値（`value`）を保持していた。しかし、PHP 8で導入されたUnion TypesやIntersection Typesにより、Zend Engineは「複数の型を同時に許容するメタデータ」を扱わなければならなくなった。
内部構造（Conceptual C-level representation）
Zend VM内部において、静的解析やリフレクション、そして実行時の型アサーションのために、型情報はビットマスクや専用の型情報構造体（`zend_type`）としてコンパイル時に解決される。
// 概念的なZend Engine内部の型定義イメージ
typedef struct _zend_type {
zend_string name; // クラス名やインターフェース名（スカラーの場合はNULL）
uint32_t type_flags; // IS_LONG, IS_STRING, IS_OBJECT などのビットフラグ
uint32_t kind; // 単一型か、Union型か、Intersection型か
} zend_type;
Union Type（例: `int|string`）が定義されたプロパティや引数は、単一の `IS_LONG` のようなフラグでは収まらない。`ZEND_TYPE_IS_SET(zend_type)` から派生し、許可された複数の型フラグの論理和（Bitwise OR）またはポインタ配列として評価される。
この結果、何が起きるか？
1. メモリフットプリントの増大: 型定義メタデータを保持するためのヒープ領域がわずかに拡大する。
2. キャッシュミスの増加: 複雑な型情報を解決するためにCPUキャッシュラインが圧迫される。
—
2. 実行時型チェック（Type Hinting / Coercion）のオーバーヘッド
PHPはJITコンパイラ（Tracing JIT）を搭載したが、PHPの動的性質ゆえに、厳密な型が保証されない限り、実行時にオペコード（例: `ZEND_RECV_INIT` や関数呼び出し時の型アサーション）が型チェックを行う。
スカラー型における暗黙の型変換（Coercion mode）の悲劇
厳格な型宣言（`declare(strict_types=1);`）が有効でない場合、`int|string` を受け取る関数に数値形式の文字列を渡すと、Zend VMは以下のような分岐地獄（Branch Prediction失敗の温床）を実行時に通過する。
function process(int|string $data): void {
// 内部で IS_LONG か IS_STRING かを判定し、
// 必要であれば暗黙の型変換（Coercion）のコストが発生する
}
この型チェックは、関数呼び出しのたびに発生する。もしこれが高頻度で呼ばれるホットパス（Hot Path）、例えば数万件のループ内やフレームワークのルーター内部であれば、わずか数ナノ秒のオーバーヘッドが積もり積もって、スループットを確実に低下させる。
—
3. 実務で爆死しないための設計ルールとリファレンスコード
では、Union Typesを使うべきではないのか？答えは「ノー」だ。ドメイン層の境界（DTOやバリデーション層）では表現力の高さゆえに極めて有効である。しかし、パフォーマンスが要求されるインフラ層やホットパスでは厳に慎むべきである。
以下に、実務のコードレビューで即座に指摘・リファクタリングできる「美しく堅牢な設計」のコード例を示す。
悪例：ホットパスで過剰なUnion Typesを使用しているアンチパターン
declare(strict_types=1);
namespace App\Performance;
class BadCalculator
{
/
- あらゆる型を受け入れようとしてUnion Typeの嵐になっている。
- 実行時にZend VMが型解決とフォールバックのコストを支払わされる。
/
public function compute(int|float|string|null $value): int|float
{
if ($value === null) {
return 0;
}
if (is_string($value)) {
$value = is_numeric($value) ? (float)$value : 0;
}
return $value 2;
}
}
なぜ危険か: 引数・戻り値の双方でUnionが多用されており、JITコンパイラがネイティブなマシン語（Machine Code）へ最適化（Type Specialization）しにくくなる。結果としてインタプリタ実行へのフォールバックが増加する。
—
改善案：型を絞り込み、Zend VMの最適化を誘発するクリーンアーキテクチャ
ホットパスにおけるUnion Typesを排除し、ポリモーフィズムや明確な型規約に落とし込む設計。
declare(strict_types=1);
namespace App\Performance;
interface ComputableInterface
{
public function value(): float;
}
final class NumericValue implements ComputableInterface
{
private float $value;
// プリミティブな単一型に絞ることで、Zend VMおよびJITが型を完全追跡可能にする
public function __construct(float|int $value)
{
// コンストラクト時に型を確定させ、実行時の分岐を排除する
$this->value = (float)$value;
}
public function value(): float
{
return $this->value;
}
}
final class NullValue implements ComputableInterface
{
public function value(): float
{
return 0.0;
}
}
class OptimizedCalculator
{
/
- 引数をインターフェース（単一型）に固定。
- 実行時の動的な型チェック（is_string 等）を完全に排除する。
/
public function compute(ComputableInterface $input): float
{
// 仮想メソッド呼び出し（ポリモーフィズム）となり、JITのインラインキャッシュが効きやすくなる
return $input->value() 2.0;
}
}
4. アーキテクトからの最終提言
PHP 8.xのUnion Typesは強力な武器だ。しかし、それは「どこでも使ってよい万能薬」ではない。
1. ドメイン境界（DTO, APIリクエストの受け口など）: 柔軟性が優先されるため、Union Typesを積極的に採用して表現力を高めるのは正しい。
2. アプリケーションの内部ロジック・ホットパス（ドメインサービス、計算処理、データマッパー）: ここではUnion Typesの排除を検討せよ。単一型（Scalar/Object）への事前キャスト、あるいはポリモーフィズム（インターフェースの活用）を用いることで、Zend VMの型解決コストを最小化し、JITの恩恵を最大限に引き出すことができる。
「なぜこの型定義にしたのか？」をコードベースのレイヤごとに説明できるエンジニアであれ。それこそが、PHPを真に掌握したプロフェッショナルの姿だ。