こんにちは。普段からPHPのフレームワークを使いこなし、「どうすればもっとリクエストを高速に捌けるか」「メモリ効率の良い設計にできるか」と日夜コードに向き合っていることと思います。
他のモダンな言語（JavaやGoなど）の経験がある方ほど、PHPの「1リクエストごとにプロセス（あるいはスレッド）が動いては消える」というシェアード・ナッシング（Shared-nothing）なアーキテクチャに、ある種の潔さと、同時に「毎回ファイルを読み込んでパースして実行しているなら、非効率なのでは？」という疑問を持ったことがあるのではないでしょうか。
実は、近年のPHP（PHP 7.4以降、そして8系）は、そのイメージを大きく覆す進化を遂げています。特にOPcacheプリローディング（Preloading）という仕組みを理解すると、PHPが単なる「スクリプト言語の枠」を超え、ネイティブアプリケーションに近い領域へと踏み込んでいることがよく分かります。
今回は、このOPcacheプリローディングが、OSやZendエンジン内部のメモリ空間でどのように動き、なぜ圧倒的な高速化をもたらすのか。その物理構造と低レイヤの真実を、一緒に紐解いていきましょう。ここを理解すると、PHPの裏側の世界が本当に美しく見えてきますよ。
—
1. 従来のOPcacheと「プリローディング」の決定的な違い
まず、従来のOPcacheが何をやっていたかをおさらいしておきましょう。
通常のOPcacheは、PHPスクリプトを初回リクエスト時（またはfilemtimeのチェック時）にパースし、Zendエンジンの実行可能な中間コードである「オペコード（Opcode）」に変換して共有メモリ（Shared Memory）にキャッシュします。
これにより、「ディスクからのファイル読み込み（I/O）」と「Lexer/Parserによる字句・構文解析」のコストが消え去り、劇的に高速化しました。
しかし、従来のOPcacheには1つだけ弱点がありました。それは「リクエストが来てから、共有メモリ上のオペコードをプロセス固有のメモリ空間にリンク（シンボリック解決）するコスト」が、わずかながら毎リクエスト発生していた点です。
クラスの依存関係解決というオーバーヘッド
例えば、AというクラスがBというクラスを継承しており、さらにインターフェースCを実装しているとします。OPcacheは個別のファイルをキャッシュしていますが、「リクエストが走った瞬間、Zendエンジンはそれらのクラス間の親子関係やメソッドテーブル（zend_class_entry）の結びつきを毎回メモリ上で再構築（あるいは確認）」していました。
この「クラス間リンクの解決」や「グローバル関数・定数の登録」を、リクエストを受け付ける前の段階（PHP-FPMの起動時）に完全に終わらせてしまい、共有メモリに焼き付けてしまおうというのが、OPcacheプリローディングの正体です。
—
2. 物理構造の核心：SHM（共有メモリ）とCOW（Copy-on-Write）
では、プリロードされたスクリプトは、OSやPHPプロセスのメモリ上でどのように扱われているのでしょうか。ここが今回の最もエキサイティングな部分です。
リンカと親プロセス（Master）による事前ロード
PHP-FPMのマスタープロセスが起動する際、設定ファイル（`php.ini`）で指定された単一のエントリポイントとなるPHPファイル（通常はプリロード用のスクリプト）を読み込みます。
このスクリプト内で `require` や `include` を使って巨大なフレームワークのクラス群を読み込ませると、Zendエンジンはそれらを解釈し、共有メモリ（SHM）上に完全にリンクされた状態のクラスエントリ（`zend_class_entry`）やオペコードを構築します。
子プロセス（Worker）へのマッピング
マスタープロセスがこれらをメモリ上に展開し終えた後、PHP-FPMは実際にリクエストを処理する子（ワーカー）プロセスたちを `fork()`（フォーク）して生成します。
Linuxの `fork()` の仕組みを思い出してください。プロセスがフォークされるとき、メモリ領域は即座にコピーされるわけではありません。COW（Copy-on-Write: 書き込み時コピー）というメカニズムにより、親プロセスが持っているメモリ空間は、子プロセスから「読み取り専用」としてそのまま共有されます。
[ PHP-FPM マスタープロセス ]
┗ 共有メモリ (SHM)
┣ プリロードされたクラス定義 (zend_class_entry)
┣ 最適化済みオペコード
┗ 定数・関数テーブル
▲
┣━━ (fork & COW) ━━ [ 子プロセス A (リクエスト処理中) ]
┣━━ (fork & COW) ━━ [ 子プロセス B (リクエスト処理中) ]
┗━━ (fork & COW) ━━ [ 子プロセス C (リクエスト処理中) ]
つまり、何十個、何百個と立ち並ぶPHP-FPMの子プロセスたちは、フレームワーク全体の巨大なクラス定義やオペコードを、物理的に同じメモリ領域を指したまま共有しているのです。各プロセスが個別にメモリを消費することがないため、RSS（Resident Set Size：実メモリ使用量）が劇的に削減されます。
—
3. 実践：プリローディング設定と注意すべき「罠」
理屈が分かったところで、実際にどのように設定し、どんな点に気を付けるべきかを見ていきましょう。
設定手順（php.ini）
プリローディングを有効にするには、`php.ini` に以下のディレクティブを記述します。
[opcache]
opcache.enable = 1
; プリロード用スクリプトのパスを指定
opcache.preload = /var/www/html/config/preload.php
; プリロードを実行するシステムユーザーを指定（セキュリティ上、rootでの実行を避ける）
opcache.preload_user = www-data
プリロードスクリプトの書き方
フレームワーク（例：SymfonyやLaravel、あるいは独自のカスタムフレームワーク）のクラスを安全に読み込ませるスクリプトの例です。
アーキテクトが教える「絶対に踏んではいけない地雷」
プリローディングは魔法の弾丸のように聞こえますが、Zendエンジンの内部構造を知らないと、本番環境で悪名高い「セグメンテーション違反（Segmentation Fault）」や、「コードを更新したのに反映されない幽霊バグ」の餌食になります。
1. 状態（State）を持つオブジェクトをプリロードしてはならない
プリロードされたクラスの「静的プロパティ（Static Properties）」は、すべてのリクエスト、すべてのワーカープロセス間で完全に共有されます。もし静的プロパティにリクエストごとのユーザーデータなどを書き込んでしまうと、別の人間のデータが別のリクエストに漏洩する（致命的なセキュリティインシデント）か、予期せぬ状態汚染を引き起こします。
原則：プリロードするのは「振る舞い（メソッド）」を持つクラス定義のみに留め、ミュータブルな状態を静的プロパティに持たせないこと。
2. コードを修正したらPHP-FPMの再起動が必須
通常のOPcacheであれば、ファイルのタイムスタンプを見て自動でキャッシュが無効化されますが、プリロードされたコードはFPMマスタープロセスの起動時にメモリに焼き付けられているため、ファイルを書き換えても実行時には古いコードが動き続けます。
デプロイパイプラインの中に `systemctl reload php-fpm`（あるいはそれに類するプロセス再起動）を必ず組み込む必要があります。
—
4. まとめ：低レイヤを知ることで、PHPは「別次元の武器」になる
いかがでしたでしょうか？
普段私たちが何気なく書いている `class` や `require` が、OPcacheプリローディングによってどのようにZendエンジンの共有メモリに配置され、OSの `fork()` と COW によって効率よく子プロセスに共有されているのか。その物理的なイメージが掴めたかと思います。
PHPは「遅いスクリプト言語」ではありません。その内部挙動を正しく理解し、メモリとプロセスのライフサイクルをコントロール下に対象を置くことで、GoやRustなどのコンパイル言語のWebサーバーに匹敵する、あるいはそれ以上のスループットを引き出すことが可能な、極めて洗練されたモダンランタイムです。
「なぜこの設定が必要なのか」「裏で何が起きているのか」をエンジンの視点から脳内トレースできるようになると、コードの書き方やアーキテクチャの設計思想がガラリと変わります。
ぜひ、次回のパフォーマンスチューニングの引き出しに、この「OPcacheプリローディングの物理構造」を加えてみてください。あなたの構築するWebシステムが、一段上の領域へと飛躍することを確信しています。