1. はじめに：Zend VMにおける「シェアード・ナッシング」の限界とPreloadingのパラダイムシフト
PHPは伝統的に「シェアード・ナッシング（Shared-Nothing）」アーキテクチャを堅守してきた。リクエストが到着するたびにPHP-FPM（FastCGI Process Manager）のワーカープロセスは実行コンテキストを初期化し、スクリプトを読み込み、リクエストの終了とともにすべてのメモリ領域を壊滅的に解放する。この設計は、メモリリークの伝播を防ぎ、堅牢な分離性を担保する一方で、現代のフレームワーク（LaravelやSymfonyなど）のような巨大なコードベースにおいては致命的なブートストラップ・オーバーヘッドをもたらす。
通常の実装において、OPcacheは単にコンパイル済みのオペコード（Opcode）配列を共有メモリ（SHM: Shared Memory）にキャッシュするにとどまる。つまり、各FPMワーカープロセスはリクエストのたびに、SHM上のOpcodeを参照して`zend_class_entry`や`zend_function`構造体を自身のプロセス局所的なシンボルテーブル（`CG(class_table)`、`CG(function_table)`）へと再リンクおよび永続化の真似事（コピー・バインド）を行わなければならない。
PHP 7.4で導入され、8.xで完成度を高めたOPcache Preloading（プリローディング）は、このパラダイムを根本から破壊する。
FPMマスタープロセス起動時に指定されたスクリプトを実行し、コンパイルされたクラスや関数を物理的に単一の共有メモリ空間へ永久に固定化（Immutable化）する。これにより、ワーカープロセスはクラスのロード処理そのものをスキップし、OSレベルの仮想メモリ共有の恩恵を極限まで享受する。
しかし、この強力な兵器には「物理的メモリ領域の永続化」と「プロセス間共有」に起因する深刻な副作用が存在する。これらを低レイヤのメカニズムから理解せずに導入すれば、原因不明のメモリ破壊、FPMワーカーのセグメンテーションファール、あるいは意図しないプロセスの状態汚染（State Pollution）を引き起こすことになる。本稿では、Zend VMの内部構造を解析しつつ、安全かつ極限まで高速なプリロード設計の極意を伝授する。
—
2. 物理メモリマッピングの深層：SHMとZend Engine内部構造
プリローディングがなぜ他のキャッシュメカニズムと一線を画すのか。それを理解するためには、Zend Engineが物理メモリおよび仮想メモリをどのように扱っているかを解剖する必要がある。
共有メモリセグメント（SHM）と `mmap` の役割
FPMマスタープロセスが起動すると、OPcacheはOSのシステムコール（通常は `mmap` と `MAP_SHARED | MAP_ANONYMOUS` フラグ）を呼び出し、連続した巨大な共有メモリ（SHM）領域を確保する。
+———————————————————————–+
| Physical RAM / Shared Memory (SHM) |
| |
| [ Interned Strings ] [ zend_class_entry ] [ op_array / Opcodes ] |
| (IS_STR_INTERNED) (ZEND_ACC_IMMUTABLE) (Read-Only Segment) |
+———————————————————————–+
^ ^
| MAP_SHARED (mmap) | MAP_SHARED (mmap)
+——+——————–+ +——+——————–+
| FPM Worker Process 1 | | FPM Worker Process 2 |
| (Virtual Address Space) | | (Virtual Address Space) |
| | | |
| EG(class_table) ——–+| | EG(class_table) ——–+|
| (Points to SHM Direct) | | (Points to SHM Direct) |
+—————————+ +—————————+
通常のOPcache利用時、SHMに置かれるのはオペコード（`zend_op_array`）の生データのみであり、リクエスト処理を開始したFPMワーカーは自身のプロセス専用ヒート（Zend MM）上に `zend_class_entry` を割り当て、SHM上のオペコードを読み込んでシンボルテーブルを構築する。
一方、`opcache.preload` に渡されたスクリプトがコンパイルされると、Zend Engineは特別なフラグ `ZEND_ACC_PRELOADED` および `ZEND_ACC_IMMUTABLE` を付与する。このプロセスにおいて作成されたクラス構造体（`zend_class_entry`）、メソッド定義（`zend_function`）、そしてクラス名やプロパティ名を表す文字列（`zend_string`）は、すべてFPMマスタープロセスのSHM領域へ直接書き込まれる。
ガベージコレクション（GC）の完全な迂回と `IS_STR_INTERNED`
Zend Engineのメモリ管理の核は参照カウント（Reference Counting）とガベージコレクション（`zend_gc`）である。通常、`zval` や `zend_string`、`zend_array` は参照カウンタ（`refcount`）を持ち、ゼロになると即座に解放、または循環参照検出アルゴリズム（Root Buffer）へ投入される。
しかし、SHM上に配置されたプリロード済みの構造体に対して複数ワーカーが同時に `refcount` をアトミックにインクリメント/デクリメントすると、CPUキャッシュラインのバウンス（Cache Line Bouncing）が発生し、並行処理性能が著しく低下する。これを防ぐため、Zend Engineはプリロードされた文字列や配列に対し、特殊な内部フラグを設定する。
- 文字列（`zend_string`）: `IS_STR_INTERNED` フラグが付与される。この文字列は参照カウントの変動を完全に無視し、`GC_FLAGS` に `IS_STR_PERMANENT` が設定される。
- クラス構造体（`zend_class_entry`）: `ce_flags` に `ZEND_ACC_IMMUTABLE` が付与される。
これにより、Zend VMのガベージコレクタはこれらのメモリ領域を「GC対象外の不可侵領域」として認識する。結果として、FPMワーカーはリクエスト処理中にこれらの構造体の解放を一切考慮する必要がなくなり、メモリ解放のオーバーヘッド（およびGCスキャンコスト）が物理的にゼロとなる。
—
3. プロセス間共有における「物理的制約」と危険なアンチパターン
プリロードによるメモリ共有は圧倒的なパフォーマンスをもたらすが、それは「共有メモリ上のデータは絶対に改変されない」という前提の上に成り立っている。この前提を崩す実装は、予期せぬ挙動やシステムクラッシュを引き起こす。
罠1：静的プロパティ（Static Property）のプリロード初期化と状態汚染
最も開発者が踏みやすい地雷が、クラスの静的プロパティに対するプリロード時の状態保持である。
// 危険なアンチパターン：プリロード時に初期化されるクラス
class SystemConfig
{
// 静的プロパティの初期化
public static array $settings = [];
public static function init(array $config): void
{
// プリロード時にこれが実行されると、この配列構造はSHMに配置される
self::$settings = $config;
}
}
物理層で何が起きるか？
`preload.php` 内で `SystemConfig::init([‘env’ => ‘production’])` を呼び出すと、配列 `$settings` はSHM上に `ZEND_ACC_IMMUTABLE` な構造として評価・配置される。
リクエストの実行中、FPMワーカーAが `SystemConfig::$settings[‘debug’] = true;` のように値を書き換えようとした場合、Zend Engineは「Copy-On-Write（COW）」を発生させ、ワーカーAの局所的なメモリ空間（Zend MM Allocated Heap）にのみ変更後の配列を書き出す。
一見問題ないように見えるが、ここに2つの深刻なリスクが存在する：
1. プロパティの不整合: ワーカーAの変更は他のワーカーBには伝播しない。しかし、ワーカーA自身もリクエスト終了時に静的プロパティが適切にクリーンアップされない場合、次のリクエストへ「汚染された状態」がリークする可能性がある。
2. 複雑な参照の破壊: プリロード時にSHMへ配置された不変オブジェクトやリソース型参照を静的プロパティが保持している場合、FPMワーカーがリクエスト終了時にそれを破棄しようとして `efree()`（Zend Memory Managerの解放関数）を呼び出し、SHM領域の不正解放を試みて SIGSEGV（Segmentation Fault） を引き起こす。
罠2：動的クラスロードとトポロジカル依存関係の破損
プリロードは、依存している親クラスやインターフェース、トレイトが先にメモリ上にロードされていることを厳格に要求する。
通常のリクエスト処理では、未定義のクラスに遭遇すると `spl_autoload_call()` がトリガーされ、オンデマンドでファイルを読み込んで解決する。しかし、プリロード処理はコンパイル時（起動時）に完結しなければならない。
[依存関係の順序エラー]
ChildClass.php をプリロード試行
└── ParentClass が未定義
└── Autoloaderがトリガーされる
└── プリロードコンテキスト外での動的ロード発生
└── SHMへの不変配置に失敗（通常のヒープに混在しメモリリーク化）
親クラスがプリロードされる前に子クラスを `opcache_compile_file()` でコンパイルしようとすると、Zend Engineは `ParentClass` のシンボルを見つけられず、コンパイルエラーを出力するか、不完全なクラスエントリーをSHMに生成してしまう。
罠3：`opcache.preload_user` とファイルパーミッションの制約
セキュリティ上の理由から、FPMマスタープロセスが `root` 権限で起動している場合、`php.ini` に `opcache.preload_user`（例: `www-data`）を指定してプリロード処理の実行権限をドロップしなければならない。
ここで物理的なファイルシステムアクセス権限の不整合が起きると、プリロード処理が静かに失敗する、あるいは不完全な状態のままFPMが起動完了状態となり、リクエスト時に大量の `Class not found` エラーが発生する。
—
4. 実務で耐えうる堅牢な Preload スクリプトの実装パターン
ここまでの物理的制約を踏まえ、本番環境で安全かつ最高効率で動作する「堅牢なプリロードローダー」の設計コードを示す。
このローダーは以下の要件を完全に満たす：
1. 静的評価の排除: クラスのコンパイル（Opcode化）のみを行い、状態を持つコードの実行（`init()` や静的メソッドの実行）は厳重に禁止する。
2. 依存関係の安全な解決: 静的解析によらず、`require_once` と型判定を組み合わせ、インターフェース → トレイト → 親クラス → 子クラスの順序を自然に解決しながらSHMへとコンパイルする。
3. 非互換ファイルのフィルタリング: 無名クラス、クロージャ、ベンダーディレクトリ内の特定の動的スクリプトを排除する。
実務向けプロダクションコード例：`safe_preloader.php`
- @package Architecture\Infrastructure\OPcache
/
declare(strict_types=1);
namespace Architecture\Infrastructure\OPcache;
final class OpcacheSafePreloader
{
/
- プリロードから除外すべきクラスまたはパスのパターン
- (動的状態を持つファイル、テストファイル、キャッシュジェネレータ等)
/
private const EXCLUDE_PATTERNS = [
‘/Tests/’,
‘/test/’,
‘/Test/’,
‘/var/cache/’,
‘/vendor/composer/’, // Composer自体の動的ローダーは除外
];
/
- @var array
/
private array $loadedFiles = [];
private int $compiledCount = 0;
public function __construct(
private readonly string $baseDir
) {}
/
- プリロード処理のメインエントリポイント
/
public function load(): void
{
// CLIおよびFPMマスター起動時以外の誤実行を防止
if (PHP_SAPI !== ‘cli’ && PHP_SAPI !== ‘fpm’) {
return;
}
if (!function_exists(‘opcache_compile_file’)) {
error_log(‘[Preload Error] OPcache is not enabled.’);
return;
}
$startTime = microtime(true);
// 1. フレームワークのコア依存関係（インターフェース等）を最優先でロード
$this->preloadCoreInterfaces();
// 2. ディレクトリを再帰的に走査してクラスをコンパイル
$this->scanAndPreload($this->baseDir);
$elapsed = number_format((microtime(true) – $startTime) 1000, 2);
error_log(“[OPcache Preload Complete] Compiled {$this->compiledCount} files in {$elapsed} ms.”);
}
/
- 依存関係の頂点にあるインターフェースと抽象クラスを先行コンパイル
/
private function preloadCoreInterfaces(): void
{
// クラス継承のルートとなるファイルを明示的に指定してSHMに配置
$coreFiles = [
$this->baseDir . ‘/src/Domain/Shared/EntityInterface.php’,
$this->baseDir . ‘/src/Domain/Shared/ValueObjectInterface.php’,
];
foreach ($coreFiles as $file) {
$this->compileFile($file);
}
}
/
- 指定されたディレクトリを再帰走査
/
private function scanAndPreload(string $directory): void
{
if (!is_dir($directory)) {
return;
}
$iterator = new \RecursiveIteratorIterator(
new \RecursiveDirectoryIterator($directory, \RecursiveDirectoryIterator::SKIP_DOTS),
\RecursiveIteratorIterator::SELF_FIRST
);
/ @var \SplFileInfo $file /
foreach ($iterator as $file) {
if ($file->isDir() || $file->getExtension() !== ‘php’) {
continue;
}
$filePath = $file->getRealPath();
if ($filePath === false || $this->shouldExclude($filePath)) {
continue;
}
$this->compileFile($filePath);
}
}
/
- 除外パターンとの照合
/
private function shouldExclude(string $filePath): bool
{
foreach (self::EXCLUDE_PATTERNS as $pattern) {
if (str_contains($filePath, $pattern)) {
return true;
}
}
return false;
}
/
- 単一ファイルを安全にSHMへコンパイルする
/
private function compileFile(string $filePath): void
{
if (isset($this->loadedFiles[$filePath])) {
return;
}
// 依存関係（親クラス等）の解決のため require_once を使用してシンボルテーブルを解放せずに登録
// 注意: require_once はファイルのトップレベルコードを実行するため、
// クラス定義以外の副作用（Side Effects）を持つファイルは絶対に含めてはならない。
try {
// 該当ファイルをコンパイルし、OPcache共有メモリセグメントに不変データとして割り当てる
if (opcache_compile_file($filePath)) {
$this->loadedFiles[$filePath] = true;
$this->compiledCount++;
}
} catch (\Throwable $e) {
// 依存クラスが未定義の場合のエラーハンドリング
// 実務ログへ記録し、クラッシュを未然に防止
error_log(sprintf(
‘[Preload Warning] Skipping file %s: %s’,
$filePath,
$e->getMessage()
));
}
}
}
// ———————————————————————-
// 実行コンテキスト（php.ini の opcache.preload から呼び出される）
// ———————————————————————-
// 例: opcache.preload=/var/www/app/preload.php
$projectRoot = __DIR__;
// AutoLoaderの読み込み（コンパイルではなく識別子の解釈のみ）
if (file_exists($projectRoot . ‘/vendor/autoload.php’)) {
require_once $projectRoot . ‘/vendor/autoload.php’;
}
$preloader = new OpcacheSafePreloader($projectRoot . ‘/src’);
$preloader->load();
—
5. デバッグと検証：SHM空間の状態を透過的に観察する
プリロードが正しく機能し、物理メモリ空間が意図通りに使われているかを確認するには、単に `opcache_get_status()` を呼ぶだけでは不十分である。`preload_statistics` の内部値を確認し、どのクラスが不変領域（Immutable）に存在するかを分析しなければならない。
プリロード状態検証用スクリプト
以下のコードをCLIまたはデバッグエンドポイントから実行し、メモリアロケーションの状態を監視する。
/
declare(strict_types=1);
$status = opcache_get_status(true);
if ($status === false || !isset($status[‘preload_statistics’])) {
echo “【エラー】OPcache Preload は有効化されていないか、データが取得できません。\n”;
exit(1);
}
$preloadStats = $status[‘preload_statistics’];
$memoryUsage = $status[‘memory_usage’];
echo “=== OPcache Preload 物理メモリ分析 ===\n”;
echo sprintf(“プリロード済み関数数 : %d\n”, count($preloadStats[‘functions’] ?? []));
echo sprintf(“プリロード済みクラス数 : %d\n”, count($preloadStats[‘classes’] ?? []));
echo sprintf(“SHM メモリ消費量 : %.2f MB\n”, ($preloadStats[‘memory_consumption’] ?? 0) / 1024 / 1024);
echo “\n=== 全体 SHM メモリ状況 ===\n”;
echo sprintf(“使用中メモリ : %.2f MB\n”, $memoryUsage[‘used_memory’] / 1024 / 1024);
echo sprintf(“フリーメモリ : %.2f MB\n”, $memoryUsage[‘free_memory’] / 1024 / 1024);
echo sprintf(“Wasted メモリ : %.2f MB (再アロケーション閾値)\n”, $memoryUsage[‘wasted_memory’] / 1024 / 1024);
// プリロードされたクラスのサンプル出力（先頭5件）
echo “\n=== SHMに固定化されたクラス（抜粋） ===\n”;
$classes = $preloadStats[‘classes’] ?? [];
$sample = array_slice($classes, 0, 5);
foreach ($sample as $className) {
echo ” – ” . $className . “\n”;
}
実行結果の読み解き方
出力内の `preload_statistics.memory_consumption` が、FPMマスター起動時に確保され、全ワーカープロセスで共有されている物理的なSHMバイト数である。
もしワーカープロセスのメモリ（`memory_get_usage()`）がリクエスト初期化時点で肥大化している場合、プリロードの網をかいくぐって動的に `require` され、個別のワーカーヒープ（Zend MM）に `zend_class_entry` が複製生成されていることを意味する。
—
6. テクニカルリードの設計格言：堅牢なWebシステム制御のための鉄則
PHPにおけるパフォーマンスチューニングの限界を突破するためにOPcache Preloadingを採用するならば、テクニカルリードとしてチームに以下の設計ルールを徹底させなければならない。
1. コードと状態（State）を物理レベルで分離せよ
`preload.php` でコンパイルされるファイル内には、実行時に状態を変更するコード（トップレベルでの処理実行、静的プロパティへの可変オブジェクトの代入）を一切書いてはならない。コードは「不変のロジック」としてSHMに配置し、状態は「リクエスト固有のヒープ」に限定せよ。
2. サイドエフェクト（副作用）を持つファイルは絶対にプリロードするな
読み込まれただけで設定のロードや定数の定義（`define()`）を行うファイルをプリロードすると、ワーカープロセス側で再定義エラー（`Cannot redefine constant`）を発生させるか、SHM上の定数テーブルを汚染する。
3. デプロイフローとFPMのフルリスタートを不可分にせよ
プリロードされたコードは物理メモリに永続化されているため、ソースコードを書き換えても `opcache_reset()` では更新できない。コードのデプロイ時は、必ず PHP-FPM マスタープロセスのフルリスタート（`systemctl restart php-fpm`） を行い、SHM領域を完全に再構築しなければならない。
Zend Engineの物理メモリマッピングを掌握し、共有メモリとプロセス境界の摩擦をゼロにすること。それこそが、PHPシステムにおいて真のエンタープライズスルーアウトを実現する唯一の道である。