こんにちは。普段からモダンなフロントエンドや、Java、Goといった静的型付け言語の設計に慣れ親しんでいるあなたなら、PHP 8で導入された「Constructor Property Promotion（コンストラクタのプロパティ昇格）」を見たとき、こう感じたはずです。
「あ、これ、TypeScriptやC#にあるやつだ。ボイラープレート（お決まりのコード）が減ってスッキリ書けて便利だな」と。
確かに、DTO（Data Transfer Object）やバリューオブジェクトを定義する際、同じプロパティ名を何度も書かなくてよくなるのは快適ですよね。しかし、私たちWebシステムアーキテクトとしては、この糖衣構文（シンタックスシュガー）がZend Engineの内部でどのように解釈され、メモリ上でどう扱われているか気になるところです。
今回は、このプロパティ昇格がPHPの内部（Zend VM）でどう展開されるのか、オペコードの世界まで潜って一緒に紐解いていきましょう。ここを理解すると、PHPのコードが一段と美しく、そして「構造的に」見えてきますよ。
—
1. 表面的な便利さの裏側で何が起きているのか
まずは、私たちが普段書くモダンなPHP 8のコードを見てみましょう。
「これは従来の書き方に展開すべき糖衣構文だ」と判断します。
脳内だけで処理を済ませず、PHPのコンパイルフェーズでこのコードがどう変形されるか、等価な従来のコードに書き換えてみましょう。
id = $id;
$this->name = $name;
$this->email = $email;
}
}
「なんだ、結局同じことなのか」と思いましたか？
はい、機能としては完全に同じです。しかし、「プログラマが書く手間を減らしているだけで、Zend VMにとっては全く同じ労力で実行されている」という事実を知ることに、アーキテクトとしてのロマンと、パフォーマンスチューニングのヒントが隠されています。
—
2. オペコード（Opcode）の世界を覗いてみる
PHPのソースコードは、Zend Engineによって「オペコード」と呼ばれる仮想マシンの機械語にコンパイルされます。OPcacheが有効な環境では、このオペコードが共有メモリ上にキャッシュされ、2回目以降のリクエストではコンパイルステップが丸ごとスキップされます。
プロパティ昇格を使ったクラスのインスタンス化と代入が、Zend VM上でどのような命令（Opcode）に変換されているか、イメージしてみましょう。
次のようなインスタンス化コードを実行したとします。
$user = new UserDto(1, ‘Alice’, ‘alice@example.com’);
Zend VMの実行レイヤでは、大まかに以下のステップを踏んでいます。
1. `ZEND_NEW`: `UserDto` クラスのインスタンスをヒープ上に生成し、オブジェクト用のメモリ空間（`zend_object`）を確保。
2. `ZEND_DO_FCALL`（または専用のコンストラクタ呼び出しハンドラ）: `__construct` メソッドを呼び出し。このとき、引数 `1`, `’Alice’`, `’alice@example.com’` がスタックに積まれる。
3. `ZEND_ASSIGN_OBJ`: コンストラクタのスコープ内で、渡された引数をそれぞれのプロパティスロット（オブジェクトが持つ `HashTable`）へバインド・代入。
4. `ZEND_DECLARE_PROPERTY`（クラス定義時）: クラスのエントリ（`zend_class_entry`）に対して、展開されたプロパティのメタデータ（型情報、可視性など）を登録。
ここで重要なのは、「プロパティ昇格を使ったからといって、実行時オーバーヘッドが増減することはない」という点です。構文解析器（Parser）の段階でパース木（AST: Abstract Syntax Tree）が生成される際、通常のプロパティ宣言＋代入文のASTへと綺麗に変換（Desugaring）されるため、実行性能は従来の書き方と完全に等価になります。
—
3. メモリ管理と「readonly」の罠
PHP 8.1以降では `readonly` 修飾子をプロパティ昇格と組み合わせることが増えていると思いますが、ここでZend VMのメモリ管理の仕様に少しだけ踏み込んでみましょう。
public function __construct(
public readonly string $token,
) {}
`readonly` が付いたプロパティは、Zend Engineの内部において「一度だけ書き込みが許可される（Once-writable）」というフラグが `zend_property_info` に立てられます。
コンストラクタの実行中、Zend VMは内部的に「このオブジェクトは現在初期化フェーズ（construction phase）にある」と認識しています。そのため、コンストラクタ内部での最初の代入（`$this->token = …`）のみが特別に許可され、コンストラクタのスコープを抜けた瞬間にそのフラグがロックされます。
もしコンストラクタの外から直接書き込もうとしたり、コンストラクタ内で二重代入を行おうものなら、Zend VMは容赦なく致命的なエラー（Fatal Error）をスローします。
Fatal Error: Cannot modify readonly property UserDto::$token
この「イミュータブル（不変）なオブジェクトを安全かつ高速に作る仕組み」が、複雑な構文を書くことなく、たった1行のプロパティ昇格の記述で安全に担保されているのは、PHPコアエンジニアたちの絶妙な設計の賜物と言えます。
—
4. アーキテクトが知るべき、実務での注意点
プロパティ昇格は非常に強力ですが、他の言語（TypeScriptなど）の感覚のままPHPで乱用すると、いくつかの「PHP特有の罠」にハマることがあります。現場でレビューをする際、ぜひ以下の点に気を配ってみてください。
① すべての引数を昇格させない
コンストラクタの引数すべてに `public` などを付ける人がいますが、依存性注入（DI）のコンテナに渡す一時的なサービスや、内部で加工するための引数までプロパティにしてしまうと、意図しない公開プロパティ（あるいはオブジェクトの肥大化）を招きます。
「外部から見える状態（State）を保持するもの」だけに絞るのが、美しいドメインモデル設計のコツです。
② デフォルト値と型の組み合わせ
プロパティ昇格でもデフォルト値を設定できますが、型安全性を担保するために `declare(strict_types=1);` との併用は必須です。
public function __construct(
public string $status = ‘active’, // デフォルト値の指定
) {}
これがどのように展開されるか、もう頭の中でZend VMの動きと合わせてスラスラと思い描けるはずです。
—
おわりに
いかがでしたでしょうか？
普段私たちが何気なく使っている「便利な新機能」も、一歩引いてZend VMのコンパイルプロセスやオペコード、メモリ管理の視点から眺めてみると、その設計思想の美しさがより深く見えてきます。
「PHPは単なる動的スクリプト言語ではなく、最適化された仮想マシン上で動く堅牢なWebアプリケーションプラットフォームである」——この感覚を掴んでおくと、パフォーマンスチューニングや大規模なアーキテクチャ設計を行う際の自信に繋がります。
次回のコードレビューや設計の場では、ぜひこの「裏側の仕組み」を意識してみてください。きっと、ワンランク上のコードが書けるようになるはずです。それでは、また次回の深掘りでお会いしましょう。