こんにちは。普段、JavaやGo、あるいはTypeScriptといった静的型付けのモダンな言語からPHPに入ってきた優秀なエンジニアほど、「PHPのクラス定数や静的プロパティ（`static`）って、裏側でどうメモリを食って、どう動いているんだろう？」と疑問に思うことが多いですよね。
「動的言語だから、アクセスするたびにハッシュマップをゴリゴリ検索して遅いんじゃないの？」
「クラス定数と静的プロパティって、結局メモリのどこに同居しているの？」
そんな疑問を持ったあなたは、もう一段深いPHPの世界に踏み込む準備ができています。今回は、PHP 8.xのZendエンジンが、クラス定数と静的プロパティをメモリ上でどう扱い、いかにして無駄なオーバーヘッドを削ぎ落としているのか、その内部構造の核心を一緒に紐解いていきましょう。
ここを理解すると、書いたコードがZend VM上でどう実行されるかが頭の中で鮮明にイメージできるようになり、パフォーマンスのボトルネックを嗅ぎ分ける鋭い嗅覚が身につきますよ。
—
1. そもそもクラス定数と静的プロパティは、メモリのどこにいるのか？
PHPの実行プロセス（通常はPHP-FPM）がリクエストを受け取ると、スクリプトはパースされ、Zendオプコード（バイトコード）に変換されます。このとき、クラスの定義情報は `zend_class_entry` (ce) という巨大なC言語の構造体として、共有メモリ（OPcacheが有効な場合）またはプロセス内のヒープ上に構築されます。
ここで重要なのは、「クラス定数」と「静的プロパティ」の性質は、メモリ配置の観点から全く異なるということです。
クラス定数：コンパイル時に確定する「イミュータブル（不変）な実体」
クラス定数（`const`）は、その名の通り値が変わりません。そのため、PHP 8.xでは、クラスのエントリである `zend_class_entry` が持つ定数用の内部ハッシュテーブル（`constants_table`）に、値そのものが最適化された形で直置き（または参照解決済み）されます。
特筆すべきは、PHP 8.xで導入された様々な最適化により、コンパイル時やオプコード生成の段階で定数の評価が可能な限り終わらせられている点です。アクセス時に動的なルックアップ（ハッシュキーの文字列比較など）が発生せず、Zend VMのオペコードレベルでダイレクトに定数値へアクセスできるケースが非常に増えています。
静的プロパティ：リクエストごとに状態を持つ「可変の領域」
一方、静的プロパティ（`public static $foo`）は、値が書き換わりますよね。ここが定数との決定的な違いです。
クラスの定義自体は全リクエスト（あるいはOPcache共有メモリ）で共有されますが、静的プロパティの「値」はリクエストごとに汚染されては困ります。
そのため、Zendエンジンはクラス定義（`zend_class_entry`）の中に静的プロパティの「デフォルト値のテンプレート」を持たせておき、リクエストが走ってプロセスが動き出すタイミングで、各プロセス（またはリクエストスコープ）の専用メモリ領域に静的プロパティ用の実体コンテナ（`default_static_members_count` および `static_members_table`）をalloc（確保）します。
—
2. PHP 8.xにおけるアクセス速度の進化：何が速くなったのか？
「定数や静的プロパティにアクセスするコードなんて、どれも同じでしょ？」と思っていませんか？ 実はPHP 8.x（特に8.0から8.3にかけて）は、このアクセスのオーバーヘッドを劇的に削減する改良が加えられています。
キャッシュとポインタ直撃の最適化
以前のバージョンや、通常の動的なプロパティアクセスでは、シンボルテーブル（HashTable）をハッシュ値で引く処理（`zend_hash_find` 等）が必要でした。文字列のハッシュを計算し、衝突解決を行い、メモリをたどる……この一連の動作は、CPUのパイプラインにとって小さな負担になります。
しかし、PHP 8.xのモダンなJITコンパイラや、Zend VMのオプコード（例えば `FETCH_CONSTANT` や `FETCH_STATIC_PROP` 系）では、一度解決したプロパティや定数のメモリアドレスを「キャッシュ（プロパティ・キャッシュ）」としてオプコード自体の構造体に埋め込む（Inline Cache）アプローチが強化されています。
これにより、2回目以降のアクセスでは、ハッシュ検索の旅に出ることなく、「あのメモリアドレスの場所を直接読む」という、C言語のポインタアクセス並みに爆速な処理を実現しているのです。
—
3. 実践：コードで挙動の違いとメモリ効率を意識する
百聞は一見にしかず。クラス定数と静的プロパティをどのように使い分けるべきか、内部の仕組みを踏まえたコードの書き方を見てみましょう。
/
class PaymentGateway
{
// 【クラス定数】
// メモリ上のクラスエントリに直接埋め込まれ、ハッシュ検索なしで最速でアクセスされます。
// 状態を持たない設定値やフラグは、必ず定数として定義すべきです。
public const STATUS_PENDING = ‘pending’;
public const STATUS_COMPLETED = ‘completed’;
// 【静的プロパティ】
// リクエストごとに値が変化する「状態」を保持します。
// 書き込みが発生するため、内部のstatic_members_tableが書き換わります。
private static int $transactionCount = 0;
/
- 定数へのアクセス
- Zend VMは最適化されたパスを通るため、オーバーヘッドが極めて低いです。
/
public static function getPendingStatus(): string
{
// 文字列キーのハッシュ検索をスキップし、ダイレクトに定数バッファを参照
return self::STATUS_PENDING;
}
/
- 静的プロパティへのアクセスとインクリメント
- 状態を持つため安全に管理する必要がありますが、
- PHP 8.xではプロパティキャッシュにより高速化されています。
/
public static function incrementTransaction(): int
{
// 内部的に static_members_table のオフセット位置を直接インクリメント
return ++self::$transactionCount;
}
}
// — 実行と検証 —
echo PaymentGateway::getPendingStatus() . “\n”; // 出力: pending
echo PaymentGateway::incrementTransaction() . “\n”; // 出力: 1
echo PaymentGateway::incrementTransaction() . “\n”; // 出力: 2
このコードを実行したとき、Zend VMの裏側では次のようなことが起きています。
1. `PaymentGateway::getPendingStatus()` を呼び出した際、`STATUS_PENDING` はクラスの定数テーブルから一発で取得されます。定数は不変（Immutable）であることが保証されているため、エンジン側も安心してキャッシュやインライン展開を行えます。
2. `PaymentGateway::incrementTransaction()` では、`self::$transactionCount` という「可変の箱」のメモリ位置を特定し、値を書き換えています。PHP 8.xのオプコードキャッシュとスロット最適化のおかげで、この変数の場所を特定するコストも昔に比べて大幅に軽減されています。
—
4. アーキテクトとしての設計指針：どちらを使うべきか？
内部構造の仕組みがわかると、私たちがコードを書くときの判断基準が非常にクリアになります。
- 「定数（`const`）」を選ぶべき場面
ビジネスロジック上の魔法の文字列、設定値、ステータスコード、上限値など、「実行中に絶対に値が変わらないもの」。これらはZendエンジンの定数テーブルに載るため、メモリ効率の面でも速度の面でも最強です。
- 「静的プロパティ（`public static $…`）」を選ぶべき場面
シングルトンパターンのインスタンス保持、キャッシュのローカル保持、リクエスト内でのカウンターなど、「アプリケーションのライフサイクルやリクエストの文脈中で状態が変化するもの」。ただし、マルチスレッド（SwooleやRoadRunnerなどの常駐型APM環境）を使用する際は、リクエストを跨いで静的プロパティの値が残り続ける（データ汚染）という致命的なバグの温床になりやすい点に注意してください。常駐型環境では、静的プロパティのライフサイクル管理はアーキテクチャ設計の最重要項目になります。
—
おわりに
いかがでしたでしょうか？
普段何気なく書いている `const` や `static` も、PHPのコアであるZendエンジンのメモリ管理や、PHP 8.xでのオプコード最適化、プロパティキャッシュというレンズを通して見ると、全く違った景色に見えてきたはずです。
「なぜこの書き方が速いのか」「メモリの裏側でどうデータが保持されているのか」。この低レイヤの視点を持つだけで、あなたの書くPHPコードは、ただ動くだけのコードから、スケーラブルで洗練された高パフォーマンスなシステムへと生まれ変わります。
ここを理解したあなたなら、もうフレームワークの表面的な仕様に惑わされることはありません。ぜひ、次の設計やコードレビューの現場で、この知見を活かしてみてくださいね。