PHP 8.xにおけるクラス定数と静的プロパティのメモリ配置とアクセス速度の極意
コードレビュー中、クラス定数（`const`）を使うべき場面で安易に静的プロパティ（`public static $var`）が使われているコードを見かけたら、私は技術的負債の匂いを嗅ぎ取る。
「動的な値じゃないんだから、静的プロパティでも同じだろう」
もしチームの誰かがそう口にしたら、即座に修正を要求してほしい。表面的には「クラスに紐づく値」という点で同じに見えるこの二つは、PHPの内部エンジン（Zend VM）のメモリ空間において、まったく異なるルールで扱われている。
今回は、PHP 8.xのJITコンパイラやZend Engineの内部構造（HashTable、CE構造体、オペコード）まで踏み込み、なぜクラス定数が圧倒的に速く、静的プロパティがボトルネックになり得るのか、その本質を解き明かす。
—
1. 内部構造の比較：なぜ定数は速く、静的プロパティは遅いのか
PHPスクリプトが実行されるとき、ソースコードはLexer（字句解析）とParser（構文解析）を経て、Opcodes（オペコード）へとコンパイルされる。この時、クラス定義は `zend_class_entry`（通称 CE）という巨大なC言語の構造体としてメモリ上にキャッシュされる（OPcacheが有効な場合は共有メモリへ永続化される）。
ここからの挙動が、定数と静的プロパティで運命的な分岐を迎える。
クラス定数（`const`）：コンパイル時解決の極致
クラス定数は、コンパイル時（あるいはOPcacheのロード時）に値が確定し、`zend_class_entry` が持つ定数用の内部 HashTable（`constants_table`）に直接埋め込まれる。
コード中で `ClassName::MY_CONST` が呼び出されると、Zend VMは以下のプロセスで値を取り出す。
1. クラスエントリへのポインタを直接参照する。
2. ハッシュテーブルからO(1)の極めて高速なルックアップ、あるいはJITによる直接的なメモリインライン展開が行われる。
3. 値は不変（Immutable）であることが保証されているため、コピーや書き込み保護のオーバーヘッドが一切存在しない。
静的プロパティ（`public static $var`）：実行時解決とスコープの呪縛
一方、静的プロパティは名前こそ「静的」だが、実態は「グローバル変数のクラス版」に過ぎない。
静的プロパティの値は、クラス定義そのものではなく、実行時に生成される静的プロパティ用テーブル（`default_static_members` およびインスタンスごとの実行時テーブル）に格納される。
コード中で `ClassName::$myStaticVar` が呼び出されると、Zend VMは以下の重い処理を実行する。
1. クラスエントリを辿り、静的プロパティのテーブルにアクセスする。
2. 可視性（`public`, `protected`, `private`）の動的なチェックが行われる。
3. 値が変更可能（Mutable）であるため、Zendエンジンは値の型や変更に備えたZval（PHPの値を表現する内部構造体）のコンテナ管理・参照カウントの考慮を行う必要がある。
4. 継承関係がある場合、親クラスとの静的プロパティの共有とシャドウィング（上書き）の解決コストが発生する。
この「動的に書き換え可能である」という仕様こそが、静的プロパティのアクセス速度を低下させ、JITによる最適化の足を引っ張る最大の要因なのだ。
—
2. 大規模アプリケーションにおけるパフォーマンスへの影響
数千のリクエストを秒速で処理するモダンなWebアプリケーションやAPI基盤において、この差は塵も積もれば山となる。
1. CPUキャッシュヒット率の低下: 静的プロパティは参照と可視性チェックのステップが多く、CPUのパイプラインハザードやキャッシュミスの確率が上がる。
2. JITコンパイラの最適化阻害: PHP 8のJIT（Tracing JIT）は、変数が不変（Constants / Immutaables）であると確信できるとき、ネイティブマシン語へのインライン展開（定数畳み込み）を積極的に行う。静的プロパティは実行時に値が書き換わる可能性があるため、この最適化の恩恵を受けにくい。
3. 並行処理・リクエスト間の汚染リスク: フレームワークの常駐化（RoadRunnerやSwooleなど）環境下において、静的プロパティの不適切な変更は、リクエスト間で状態が漏洩する致命的なバグ（データ競合）の温床となる。
—
3. 実務で迷わないための設計ルールとリファレンス実装
「設定値」「マジックナンバー」「ステートレスな許容値」は、すべてクラス定数、あるいはPHP 8.1以降であれば列挙型（Enum）で表現すべきだ。静的プロパティを使うべきは、「アプリケーションのライフサイクル内で、どうしても状態（State）を保持・変更しなければならない特例ケース」に限られる。
以下に、安全で高速な定数設計と、静的プロパティを排除したリファクタリングの模範コードを示す。
declare(strict_types=1);
namespace App\Core;
/
- 企業向けAPI基盤における設定・ステータス管理の模範実装
- 【設計指針】
- – 変更されないドメイン定数は `const`（内部で高速に解決され、JITの最適化対象となる）
- – 状態を持つ必要がある場合は、ミュータブルな静的プロパティではなく、
- DIコンテナを通じたインスタンスプロパティ、またはイミュータブルなオブジェクトとして設計する。
/
final class ApiConstants
{
// —————————————————————–
// 1. クラス定数（コンパイル時解決・イミュータブル）
// —————————————————————–
/ 最大リクエストサイズ（バイト） /
public const int MAX_REQUEST_SIZE_BYTES = 10485760; // 10MB
/ サポートするAPIのメジャーバージョン /
public const string API_VERSION = ‘v1.0’;
/ デフォルトのタイムアウト秒数 /
public const float DEFAULT_TIMEOUT_SEC = 5.0;
// ※外部からのインスタンス化を完全に防ぐ（名前空間としての利用）
private function __construct() {}
}
/
- PHP 8.1+ Enumを活用したスマートな定数管理
- 内部的には最適化されたクラスエントリとして扱われ、安全性と速度を両立。
/
enum ApiStatus: string
{
case PENDING = ‘pending’;
case PROCESSING = ‘processing’;
case COMPLETED = ‘completed’;
case FAILED = ‘failed’;
/
- 内部で定数的なマッピングを高速に返すメソッド
/
public function isTerminal(): bool
{
return match($this) {
self::COMPLETED, self::FAILED => true,
default => false,
};
}
}
/
- 【アンチパターン例】静的プロパティによる設定・状態管理
- ⚠️ 危険な理由:
- 1. 外部から書き換えが可能（`ApiConfig::$timeout = 999;` などがどこからでも実行可能）
- 2. 永続化環境（RoadRunner/Swoole）でリクエストを跨いで値が残留するバグの原因になる
- 3. Zend VMのプロパティ検索コストにより、アクセスが定数に比べて確実に遅い
/
class DangerousConfigExample
{
// 絶対にやってはいけない実装
public static int $timeout = 5;
}
コードレビュー時のチェックリスト
チームメンバーが書いたコードをレビューする際は、以下の観点をシャープに指摘してほしい。
- [ ] 「その値は、リクエストのライフサイクル中に変化するか？」 -> 変化しないなら絶対に `const`（または `enum`）を使うこと。
- [ ] 「静的プロパティをグローバル変数の代わりに使っていないか？」 -> 常駐型アプリ（Swoole/FrankenPHP等）では致命的なメモリリークやデータ汚染を引き起こすため、DI（依存性注入）を利用したインスタンスプロパティへリファクタリングさせること。
—
結びにかえて
PHPは「手軽に動く言語」から、JITやOPcacheの進化により「極限までチューニングされた高パフォーマンス言語」へと変貌を遂げた。そのエンジン内部の挙動――Zend VMがどうメモリを割り当て、どうオペコードを処理しているかを知るエンジニアと、ただ動くコードを書くだけのエンジニアの間には、作られるシステムの堅牢性とスケーラビリティにおいて圧倒的な差が生まれる。
「定数で済むものは定数で書く」。
たったこれだけの規律が、あなたのアプリケーションを数ミリ秒速くし、予期せぬバグから守り抜く盾となるのだ。