Constructor Property Promotionの裏側：Zend VMとオペコードが暴くプロパティ昇格の真実
PHP 8.xで導入された「Constructor Property Promotion（コンストラクタプロパティ昇格）」は、長年ボイラープレートコードの温床であったコンストラクタの冗長性を劇的に排除した。
// 昇格前（PHP 7.x以前の伝統的記述）
class Point {
public float $x;
public float $y;
public function __construct(float $x, float $y) {
$this->x = $x;
$this->y = $y;
}
}
// 昇格後（PHP 8.x）
class Point {
public function __construct(
public float $x,
public float $y
) {}
}
この糖衣構文（Syntactic Sugar）は、開発者のタイポを減らし、コードベースを美しく保つ。だが、生粋のアーキテクトであれば問わなければならない。「この美しい糖衣構文は、Zend Engineの内部において、どのようなコストとオペコードの変態を経て実行されているのか？」と。
ネットの表面的なチュートリアルは「コードが短くなります」で終わる。しかし、我々はZend VMのメモリ空間、zend_class_entry、そしてオペコード（Opcode）の奔流を直視しなければならない。本稿では、プロパティ昇格がコンパイル時にどのように通常のクラス構造と代入処理に展開されるのか、その内部メカニズムを極限まで暴き出す。
—
1. コンパイルフェーズ：ASTからZend VMオペコードへの不可逆変換
PHPソースコードは、Lexer（字句解析器）とParser（構文解析器）を経て、抽象構文木（AST: Abstract Syntax Tree）に変換される。PHP 8のパーサは、コンストラクタシグネチャ内に可視性修飾子（`public`, `protected`, `private`）を持つ引数を発見すると、AST構築の段階で静的な魔術を行う。
AST上において、プロパティ昇格を持つコンストラクタは、以下の2つの要素に分解・再構築される。
1. クラススコープへのプロパティ定義の自動追加：クラスのメンバ変数として、該当する型と名前のプロパティが暗黙的に宣言される。
2. コンストラクタ本体への代入オペコードの自動挿入：メソッドブロックの先頭（正確には内部的なエントリポイント）に、引数を対応するプロパティへ代入する操作が挿入される。
これをZend VMのオペコードレベルで確認しよう。`opcache`拡張機能が有効な環境において、`php -d opcache.enable_cli=1 -d opcache.opt_level_passes=1 -R` などのツールや、内部の`zend_fetch_debug_backtrace` / 独自拡張モジュールを用いて生成されるオペコードを覗くと、プロパティ昇格を用いたクラスは、手動でプロパティと代入を書いたクラスと、完全に一言一句同じオペコード列へとコンパイルされていることがわかる。
つまり、実行時（Runtime）において、プロパティ昇格によるパフォーマンスのペナルティは一切存在しない。これは完全なコンパイル時展開（Compile-time Expansion）である。
—
2. 内部構造：`zend_class_entry` とプロパティのメモリレイアウト
Zend Engineの内部において、すべてのクラスは `zend_class_entry`（通称 `ce`）という巨大なC構造体としてヒープ上に表現される。
プロパティ昇格が指定されたクラスがロードされるとき、コンパイラは `zend_declare_property` 系の内部関数を自動的に呼び出し、`ce->properties_info` という `HashTable` にプロパティのメタデータを登録する。
/ Zend/zend_compile.h の概念的イメージ /
typedef struct _zend_property_info {
zend_access_flags flags; // public, protected, private
u32 offset; // オブジェクト構造体からのオフセット
zend_string name; // プロパティ名
zend_string doc_comment;
zend_class_entry ce; // 定義元クラス
// …
} zend_property_info;
ここで重要なのは、昇格されたプロパティも、通常のプロパティとまったく同じメモリ管理の仕組み（Properties Table / Properties HashTable）に乗るという点だ。
インスタンス（`zend_object`）が生成される際、オブジェクトのバッキングストア（メモリ領域）には、暗黙的に追加されたプロパティ分のスロットが確実に確保される。
—
3. 応用と罠：プロパティ昇格におけるアーキテクチャ上の注意点
この強力な糖衣構文の内部挙動を知ることで、フレームワーク設計や高度なオブジェクト指向設計における「罠」が見えてくる。
A. 可視性（Visibility）と型の強制（Type Hinting）
プロパティ昇格では、すべての可視性修飾子が利用できる。さらに、PHP 7.4以降の型宣言、PHP 8.0以降のUnion TypesやIntersection Typesもそのまま適用可能である。
class HttpRequest {
public function __construct(
public readonly string|array $payload,
protected int $timeout = 30,
private ?LoggerInterface $logger = null
) {}
}
ここで `readonly` 修飾子（PHP 8.1+）を組み合わせた場合、Zend VMは書き込みガード（`ZEND_ACC_READONLY` フラグ）を `zend_property_info` に付与する。初回の代入（コンストラクタ内での自動代入を含む）以降に、何者かが書き込みオペコード（`ASSIGN_OBJ` 等）を実行しようとすると、Zend VMは即座に致命的エラー（Fatal Error）をスローする。このガード機構も、通常のプロパティ宣言と完全に同等に機能する。
B. アトリビュート（Attributes）の付与とReflection APIの挙動
プロパティ昇格を用いた場合、引数自体にアトリビュートを付与できる。
use App\Attributes\Validate;
class UserDto {
public function __construct(
#[Validate(‘email’)]
public string $email
) {}
}
このとき、リフレクション（`ReflectionParameter` および `ReflectionProperty`）をどう扱うべきか？
PHPのReflection APIは非常に洗練されており、コンストラクタのパラメータに付与されたアトリビュートは、自動的に生成されたクラスプロパティ側のリフレクション（`ReflectionProperty::getAttributes()`）へシームレスにマッピングされる。
しかし、DIコンテナやシリアライザを自作するアーキテクトは、「コンパイル時に生成されたプロパティ」と「コンストラクタ引数」がメタデータ上でどのように結びついているかを正確に把握しておく必要がある。一部の古いライブラリやカスタムバリデータは、プロパティ昇格されたメンバを走査する際に `ReflectionClass::getProperties()` を使うべきところを `ReflectionMethod::getParameters()` を見てしまい、メタデータの取りこぼしを起こすバグを踏むことがある。
—
4. セキュリティとオブジェクトインジェクションの文脈
ここで、セキュリティ・ハックの文脈に目を向けよう。
PHPセキュリティの悪名高い脆弱性の一つに 「PHPオブジェクトインジェクション（PHP Object Injection）」 がある。信頼できないデータに対して `unserialize()` を実行した際、攻撃者が巧妙に構築されたGadget Chain（ガジェットチェーン）を通じて任意のコード実行やプロパティの書き換えを引き起こす脅威だ。
プロパティ昇格を用いたクラスが `unserialize()` されるとき、Zend Engineはどのように振る舞うか？
1. `unserialize()` は、対象クラスのインスタンスをコンストラクタを呼び出さずに（`__construct` をスキップして）インスタンス化する。
2. その後、シリアライズデータに含まれるプロパティ名を `ce->properties_info` と突合させ、メモリ上のプロパティスロットに直接値を書き込む。
3. この際、`readonly` プロパティであっても、`unserialize()` 内部の低レイヤ処理（またはマジックメソッド `__wakeup` / `__unserialize`）を経由する過程で、Zend VMの書き込み制限が一時的にバイパスされる、あるいはデシリアライズ特有の挙動を示すケースが存在した（PHPのバージョンによって挙動の微修正が繰り返されている領域である）。
もしプロパティ昇格されたクラス内に、バリデーションロジックやサニタイズ処理が「コンストラクタ内のみ」に記述されていた場合、`unserialize()` によってコンストラクタがバイパスされると、不正な型や範囲外の値を持ったオブジェクトがメモリ上に誕生することになる。
class SecureToken {
public function __construct(
public string $token
) {
// コンストラクタでバリデーションを行っているつもり
if (strlen($token) !== 64) {
throw new \InvalidArgumentException(“Invalid token length”);
}
}
}
// 攻撃者が不適切な長さを持ち、かつ強制的にシリアライズされたデータを送り込むと…
// unserialize() は __construct を呼ばないため、バリデーションをすり抜けてインスタンスが生成される。
教訓: プロパティ昇格はコードを簡素化するが、「コンストラクタにバリデーションを記述すれば安全」という安易な設計は、デシリアライズやリフレクション（`ReflectionClass::newInstanceWithoutConstructor()`）のコンテキストにおいて致命的な脆弱性の温床となる。真に堅牢なアーキテクチャでは、バリデーションはコンストラクタだけでなく、DTO自体のセッター、あるいは専用のバリデーションレイヤー（マーシャラー）で担保されなければならない。
—
5. OPcacheプリローディングとメモリ効率の極意
本稿の締めくくりとして、OPcacheのプリローディング（Preloading）とプロパティ昇格の関係性に触れておこう。
PHP 7.4で導入され、PHP 8.xでさらに洗練されたOPcacheプリローディングは、スクリプトの起動時に指定したスクリプト群をパースし、共有メモリ（SHM: Shared Memory）上に永続的なASTおよびオペコードとして常駐させる機能である。
プロパティ昇格を持つクラスがプリロードされると、以下のメリットが生まれる。
- パースおよびコンパイルコストの完全なゼロ化：リクエストごとにASTを構築するオーバーヘッドが消滅する。
- メモリの最適化：`zend_class_entry` および `zend_property_info` の実体がSHM上に配置され、Workerプロセス間で共有される（Copy-on-Writeの恩恵を受ける）。
だが、ここでアーキテクトが意識すべきは「アロケーションの局所性」である。
大規模なエンタープライズアプリケーションにおいて、数千のDTOクラスでプロパティ昇格を乱用し、それぞれが複雑なUnion Typeやアトリビュートを持っている場合、起動時のOPcache共有メモリの消費量は無視できない規模に膨れ上がる。
`opcache.memory_consumption` のチューニングを怠ると、メモリ断片化（Memory Fragmentation）を引き起こし、OOM（Out of Memory）エラーの遠因となる。
高負荷なWebシステムを極限までチューニングする際、我々はただ「コードが綺麗になるから」という理由で糖衣構文を受け入れるのではなく、それがZend VMのメモリ空間とOPcacheの共有メモリにどのようなフットプリントを残すかを常に計算に入れなければならない。
—
結び
Constructor Property Promotionは、単なる「書きやすさのための機能」ではない。それはZend VMのコンパイルパイプラインに深く統合された、極めて合理的かつ効率的な最適化の成果である。
しかし、その裏にある内部構造（オペコードの展開、メモリレイアウト、デシリアライズ時の挙動、OPcacheの挙動）を理解していないエンジニアは、思わぬバグやセキュリティホールに足元をすくわれることになる。
コードの表層を書くだけのプログラマーから、Zend VMの鼓動を感じ取る真のシステムアーキテクトへ。PHPの限界を突破する知見は、いつだってソースコードの「裏側」に眠っている。