OPcacheプリローディングの物理構造：Zend Engineのメモリ空間を共有・永続化する低レイヤの真実
PHPは「リクエストごとにすべてをゼロから解釈し、捨て去る言語」だという神話は、Zend OPCacheの登場と、PHP 7.4で導入された「プリローディング（Preloading）」によって完全に過去のものとなった。
多くのWebエンジニアは、OPcacheを「スクリプトのバイトコードをメモリにキャッシュし、パースとコンパイルのオーバーヘッドを削減する仕組み」程度に理解している。しかし、システムアーキテクトの視点から言えば、OPcacheの本質は「マルチプロセス（あるいはマルチスレッド）環境における、OSのページキャッシュと共有メモリ（Shared Memory）を駆使した、Zend VMの物理メモリ空間の支配」に他ならない。
本稿では、OPcacheプリローディングがどのようにOSのメモリマップトファイル（`mmap`）にフックし、親プロセスから子プロセスへとZend Engineの内部構造体（`zend_op_array`や`zend_class_entry`）を継承させるのか、その物理構造とメモリの生死の境界を極限まで解き明かす。
—
1. Zend VMのメモリ空間とOPcacheの役割
PHPの1リクエストは、歴史的に見れば「プロセスの起動 ➔ スクリプトの読み込み ➔ レクサーによるトークナイズ ➔ パーサーによるAST（抽象構文木）生成 ➔ オペコードへのコンパイル ➔ Zend VMによる実行 ➔ プロセス終了とメモリ破棄」という激しいエントロピーの消耗戦の繰り返しであった。
OPcacheはこのフローのうち、前半の「読み込みからコンパイルまで」を完全に排除する。
通常モードのOPcacheであっても、一度コンパイルされた`zend_op_array`は共有メモリ（SHM）上に保持され、リクエストを跨いで再利用される。しかし、ここには依然として「リクエストごとのシンボルテーブルの構築」や「ファイル依存関係の解決（インクルードのオーバーヘッド）」というコストが残存している。
プリローディングがもたらすパラダイムシフト
プリローディング（`opcache.preload`）は、PHPの起動時（FPMであればマスタープロセスの起動時）に指定されたスクリプトを読み込み、永続化された共有メモリ空間上に完全にリンクされたクラス、関数、定数を構築する。
ここで重要なのは、生成された`zend_class_entry`（クラスのエントリ構造体）や関数ポインタが、リクエスト毎の動的なメモリ割り当て（emalloc）ではなく、永続的メモリ割り当て（pemalloc）によって共有メモリ上に固定化されるという点だ。
+————————————————————-+
| OS Shared Memory (SHM) – OPcache Shared Segment |
| |
| [ zend_class_entry (User Class A) ] |
| ├── methods: zend_op_array (Precompiled Opcode) |
| └── properties_info |
| [ zend_class_entry (User Class B – Extends A) ] |
| └── linked via persistent pointers |
+————————————————————-+
▲ ▲
│ (Copy-on-Write / Direct Mapping) │
+——–┴——–+ +——–┴——–+
| FPM Child W1 | | FPM Child W2 |
| (Request Space) | | (Request Space) |
+—————–+ +—————–+
親プロセス（FPM Master）のメモリ空間上でこれらが構築された後、`fork()`システムコールが実行される。Linuxの仮想記憶管理機構（Virtual Memory Management）とCopy-on-Write（CoW）により、子プロセス（FPM Worker）は物理メモリを追加消費することなく、親プロセスが構築した共有メモリ空間をそのままマクロなアドレス空間として共有・継承する。
—
2. プリロード時の物理構造：ポインタの解決と「リロケーション」の罠
OPcacheプリローディングの内部実装において最もアークテクチャ的に美しい、同時に最も危険な課題が「ポインタの永続化（Relocation / Pointer Fixing）」である。
Zend Engineの内部において、クラス、関数、オペコードの配列（`zval`や`zend_op`）は、無数のメモリアドレスへのポインタで蜘蛛の巣のように繋がっている。例えば、あるメソッドのオペコード内にある定数や、スーパークラスへの参照は、メモリ上の絶対アドレス（あるいは相対アドレス）として保持される。
もし、通常のプロセス空間でこれらを単にメモリ上に展開しただけでは、`fork()`後に子プロセス側でアドレス空間がずれたり、リクエストごとにメモリマップのアドレスが変わる（ASLR: Address Space Layout Randomizationの影響）と、ポインタが無効になり、即座にSegmentation Fault（セグフォ）を引き起こす。
永続化ストレージ上の相対ポインタ表現
OPcacheは、プリロードされたデータを共有メモリへ書き込む際、絶対アドレスを「ベースアドレスからのオフセット（相対ポインタ）」に変換して保持する。
これにより、どのプロセスがどの仮想アドレス空間に共有メモリをアタッチ（`shmat` または `mmap`）したとしても、基準アドレスにオフセットを加算するだけで、正確に目的の構造体へアクセスできるようになる。
しかし、この物理構造ゆえに、「プリロードされたスクリプト内でリソース（データベース接続、ファイルハンドル、ソケットなど）をグローバルスコープでオープンしてはならない」という絶対的な制約が生じる。
3. OPcacheプリローディングの実装と検証コード
理論を実証するため、実際にプリロード環境を構築し、メモリ上で何が起きているのかをコードレベルで確認する。
プリロードスクリプトの設計
以下のスクリプトを `/var/www/html/preload.php` として配置し、PHP-FPMの設定で読み込ませる。
/
declare(strict_types=1);
// プリロード対象のベースディレクトリ
$baseDir = __DIR__ . ‘/src’;
if (!is_dir($baseDir)) {
return;
}
// 再帰的にファイルを走査し、すべてのクラスをロードする
$iterator = new RecursiveIteratorIterator(
new RecursiveDirectoryIterator($baseDir, RecursiveDirectoryIterator::SKIP_DOTS)
);
foreach ($iterator as $file) {
if ($file->isFile() && $file->getExtension() === ‘php’) {
$filePath = $file->getRealPath();
// opcache_compile_file を用いてパースとコンパイルを強制し、
// zend_op_array をOPcacheの共有メモリ空間にマウントする
if (opcache_compile_file($filePath)) {
// 必要に応じてログ出力（本番環境では無効化推奨）
// error_log(“Preloaded: ” . $filePath);
}
}
}
// プリロードされたクラスの数を確認
$status = opcache_get_status(false);
$preloadedCount = count($status[‘preload_hash’] ?? []);
error_log(“OPcache Preloading Complete. Total preloaded scripts: {$preloadedCount}”);
`php.ini` の極限チューニング
OPcacheプリローディングを本番環境で真価を発揮させるための `php.ini` 設定。
[opcache]
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
; 共有メモリのサイズ（アプリケーションの規模に応じて 256M〜512M以上を指定）
opcache.memory_consumption=512
; 内部文字列バッファ
opcache.interned_strings_buffer=64
; 最大Cachedファイル数
opcache.max_accelerated_files=100000
; プリロードスクリプトの指定
opcache.preload=/var/www/html/preload.php
; プリロードを実行するユーザー（FPMの実行ユーザーと一致させること）
opcache.preload_user=www-data
; 本番環境では検証を完全に切る（変更時は必ずFPMをリロード）
opcache.validate_timestamps=0
opcache.revalidate_freq=0
; ファイルのハッシュチェックを省き、高速化
opcache.fast_shutdown=1
—
4. OPcacheとFiber（ファイバー）の交差点：非同期並行処理におけるメモリの罠
PHP 8.1で導入された Fiber（ファイバー） は、スタックフルコルーチンをユーザースペースで実現し、I/Oバウンドなタスクの並行処理において革命を起こした。しかし、OPcacheプリローディング環境下でFiberを運用する場合、Zend VMのコールスタックとメモリ管理の境界線を深く理解していないと、致命的なメモリリークや未定義動作を引き起こす。
Fiberは独自の実行スタック（コールスタックフレームの集合）をヒープ上に動的に確保する。
一方、OPcacheによってプリロードされたクラスのメソッド（`zend_op_array`）は、共有メモリ（読み取り専用に近い永続領域）上に存在する。
ここで、Fiber内で実行されるクロージャやオブジェクトのメソッドが、プリロードされたクラスのインスタンスプロパティに対して非同期に状態を書き換える際、Zend VMのオブジェクトプロパティテーブル（`zend_object` の `properties` ハッシュテーブル）へのアクセスが複数のFiber間でどのように調停されるかが問題になる。
+————————————————————-+
| Fiber A (Context 1) ──┐ |
| ▼ |
| [ Zend VM Stack ] |
| │ |
| ▼ |
| [ Shared Preloaded Opcode (OPcache) ] |
| ▲ |
| │ |
| [ Zend VM Stack ] |
| ▲ |
| Fiber B (Context 2) ──┘ |
+————————————————————-+
PHPのFiberはノンプリエンプティブ（協調的マルチタスク）であるため、単一のスレッド上で明示的にサスペンド（`Fiber::suspend()`）とレジュームが行われる。そのため、C10K問題で見られるようなプリミティブなマルチスレッド競合（Race Condition）は基本的には発生しない。
しかし、OPcacheプリロードされたコード内で静的プロパティ（`public static $counter` など）を使用している場合、それは全Fiber、全リクエスト（プロセスが共有する範囲内）でグローバルに共有されることになる。
「ステートレス（状態を持たない）」であることを強制し、リクエスト固有の状態やFiberごとのコンテキストは必ずインスタンスプロパティ（`$this->…`）として、各リクエストが所有するヒープ領域（`emalloc`）に閉じ込めなければならない。共有メモリ上の永続領域にミュータブルな状態を置くことは、アーキテクチャ上の最大の禁忌である。
—
5. セキュリティハックの観点：OPcacheの物理構造を狙う脆弱性
最後に、ここまで解説したOPcacheの低レイヤ構造が、攻撃者にとってどのように映るか、セキュリティハックの文脈から防衛の知見を述べておきたい。
オブジェクトインジェクションとGadget Chainの永続化
PHPにおけるオブジェクトインジェクション（`unserialize()`の脆弱性）は、悪意あるデータから任意のオブジェクトを復元し、マジックメソッド（`__destruct` や `__wakeup`）をトリガーしてGadget Chainを構築、最終的にリモートコード実行（RCE）に至るクラシックかつ強力な攻撃手法である。
もし、アプリケーション内に脆弱な `unserialize()` が存在し、さらにOPcacheプリローディングによって広範囲のクラスが共有メモリ上にロードされている環境では、攻撃者にとって「利用可能なGadget（クラス群）のカタログ」が常にメモリ上に完璧に揃っている状態を作り出してしまう。
通常、動的なオートローダー環境では、攻撃者が特定のクラスをロードさせるためにファイルインクルードのトリガーが必要になる場合があるが、プリロード環境では主要なフレームワークのコンポーネントがすでにメモリ上に実体化（`zend_class_entry` が解決済み）しているため、攻撃の成功確率と実行速度が飛躍的に跳ね上がる。
防御の要諦
1. `unserialize()` の完全な廃止: 代わりに `ext-json` などの安全なシリアライザを使用する。やむを得ず使用する場合は、`allowed_classes` オプションを厳格に指定する。
2. `opcache.validate_timestamps=0` のリスク管理: 本番環境でのパフォーマンス追求のためにタイムスタンプ検証を切るのは定石だが、万が一Webサーバーのファイルパーミッションに不備があり、攻撃者が任意のPHPファイルをアップロード・上書きできた場合、OPcacheがそれを検知できず古いキャッシュを保持し続ける（あるいは再起動するまで反映されない）という挙動を引き起こす。コードのデプロイパイプラインは、不変インフラストラクチャ（Immutable Infrastructure）の原則に則り、ファイルの書き換えが一切不可能な堅牢な権限管理下で行う必要がある。
—
結言
OPcacheプリローディングは、単なる「高速化のスイッチ」ではない。それは、Zend VMのメモリ空間、OSの仮想記憶、そしてPHPのライフサイクルそのものをアーキテクトの意図通りにコントロールするための、極めて強力な低レイヤインターフェースである。
ポインタの相対化、共有メモリの物理構造、プロセスフォーク時の挙動、そしてFiberとの共存におけるステートレスの原則。これらすべてを掌握した者だけが、真にスケーラブルで堅牢なPHPシステムを設計する資格を持つ。エンジンの鼓動を感じ取れ。コードの裏側にあるメモリの躍動を支配せよ。