こんにちは。普段、Node.jsやGo、あるいはJavaあたりの非同期・常駐型の世界からPHPに入ってきた優秀なエンジニアの多くが、ある日突然、この壁にぶつかります。
「あれっ？ リクエストをまたいで静的プロパティの値が残ってる……？」
「SwooleやRoadRunnerに移行したら、ユーザーAのセッション情報がユーザーBに見える瞬間があるんだけど、これってPHPのバグ？」
……ふふ、落ち着いてください。これはバグではなく、PHPという言語の歴史と、Zend VMのメモリモデルが持つ「常駐プロセス」における宿命なんです。
今回は、従来の「1リクエスト＝1プロセス消滅」という甘い幻想を捨て、SwooleやRoadRunnerといったモダンな常駐型PHP環境でどうやってリクエストを分離し、堅牢なアプリケーションを設計すべきか、その裏側のエンジン挙動を含めて優しく紐解いていきましょう。ここを理解すると、PHPの裏側がまるでガラス細工のように美しく見通せるようになりますよ。
—
1. 伝統的PHP（FPM）と常駐型PHP（Swoole等）の決定的な違い
まずは、PHPの実行モデルの基本裏話を少しだけ。
これまでのPHP（PHP-FPM + Apache/Nginx）の基本は、「共有ード・ナッシング（Shared-Nothing）」アーキテクチャでした。
ブラウザからリクエストが来ると、OSが新しいプロセス（またはワーカー）をフォークし、Zend VMが起動してスクリプトを読み込み、グローバル変数（`$_GET`, `$_POST`, `$_SESSION` など）やユーザー定義のクラスをメモリ上に展開し、レスポンスを返した瞬間にプロセスごとすべて綺麗さっぱり消滅していました。
[従来のPHP-FPM]
1リクエスト到来 ➔ プロセス起動 ➔ 実行 ➔ プロセス消滅（メモリ完全解放）
だからこそ、開発者はメモリリークやグローバル変数の汚染をそこまで意識する必要がなかったのです。「リクエストが終われば全部リセットされる」という強力な安心感があったからですね。
しかし、SwooleやRoadRunnerといった常駐型ランタイム（Application Server）の世界では、この前提が180度ひっくり返ります。
[常駐型ランタイム (Swoole等)]
プロセス起動 ➔ 永続ループ待機
├─ 1リクエスト目到来 ➔ ワーカー処理 ➔ 待機に戻る（メモリ保持！）
├─ 2リクエスト目到来 ➔ ワーカー処理 ➔ 待機に戻る（メモリ保持！）
Zend VMは一度起動したらプロセスを落とさず、メモリ上にOPcacheが生成したオペコード（中間コード）やシンボルテーブルを保持したまま、数千、数万ものリクエストを同じプロセスで処理し続けます。これが爆発的な高速化を生む源泉ですが、同時に「リクエスト間でグローバルな状態が残留する」という致命的なリスクを孕むことになるのです。
—
2. なぜ『グローバル変数』はリクエスト間汚染を引き起こすのか
Node.jsやGoを書いたことがある人なら、「モジュールスコープの変数やグローバル変数はリクエスト間で共有されるから、リクエストごとのデータを入れてはいけない」という鉄則を本能的に知っているはずです。
PHPでも、常駐環境ではまったく同じ現象が起きます。
例えば、次のようなコードをSwoole環境で動かしたとしましょう。
on(‘request’, function ($request, $response) {
// クエリパラメータからユーザー名を取得して設定
$username = $request->get[‘user’] ?? ‘guest’;
RequestContext::setUser($username);
// 何らかの非同期処理やサービス層の呼び出しをシミュレート
Co::sleep(0.1);
// レスポンスを返す
$response->end(“Hello, ” . RequestContext::getUser());
});
一見、何の問題もないシンプルなコードに見えますよね。しかし、このサーバーに対して、次のようなリクエストがほぼ同時に飛んできたと想像してください。
1. リクエストA (`?user=Alice`) が到達し、`RequestContext::setUser(‘Alice’)` が走る。
2. その直後（非同期の待ち時間中）、リクエストB (`?user=Bob`) が到達し、`RequestContext::setUser(‘Bob’)` が上書き実行される。
3. リクエストAの処理が再開し、`RequestContext::getUser()` を呼び出す。
……お分かりいただけたでしょうか？ リクエストAのレスポンスには、なんと `Hello, Bob` と返ってきてしまいます。これが、常駐プロセスにおける「リクエスト間汚染（Cross-Request Contamination）」の正体です。
Zend VMの視点から見れば、staticプロパティ `$currentUser` はひとつのプロセス空間に存在するただのグローバルな `zend_property_info` であり、リクエストの境界なんてものを勝手に認識してクリアしてはくれないのです。
—
3. リクエストスコープを安全に分離する『Contextパターン』の設計
では、この恐怖のメモリ共有地獄から逃れるにはどうすればよいのでしょうか？
答えはシンプルです。「リクエストごとの独立したスコープ（Context）」を明示的に生成し、そのライフサイクルをフレームワークやワーカーのイベントに完全に同期させることです。
モダンなPHPフレームワーク（Hyperf、Swoole向けのLaravel拡張など）や、堅牢なRoadRunnerアプリケーションでは、「コルーチンID」や「リクエストID」をキーにした局所的なストレージ（Context Container）を実装しています。
自前でこのContextマネージャーを設計する場合の、実用的な実装イメージを見てみましょう。
/
class RequestContext
{
/
- リクエストごとのデータを保持するストレージ
- キーには Swooleなら Coroutine::getuid() などを使用する
/
private static array $storage = [];
/
- 現在のリクエストスコープにデータを設定する
/
public static function set(string $key, mixed $value): void
{
$cid = self::getCoroutineId();
self::$storage[$cid][$key] = $value;
}
/
- 現在のリクエストスコープからデータを取得する
/
public static function get(string $key, mixed $default = null): mixed
{
$cid = self::getCoroutineId();
return self::$storage[$cid][$key] ?? $default;
}
/
- リクエスト終了時に必ずメモリを破棄（クリーンアップ）する
/
public static function destroy(): void
{
$cid = self::getCoroutineId();
unset(self::$storage[$cid]);
}
/
- 現在の実行コンテキスト（コルーチンID等）を一意に特定する
/
private static function getCoroutineId(): int
{
// Swoole環境であれば Co::getuid() を使用
// 厳密な非同期を使わないRoadRunnerや純粋な常駐スクリプトならリクエストごとに一意のUUIDでも可
if (class_exists(‘Swoole\Coroutine’)) {
return \Swoole\Coroutine::getuid();
}
// フォールバック（通常実行）
return 0;
}
}
フレームワークのライフサイクルと連携させる
この `RequestContext` を使うだけでは不十分です。肝心なのは、「いつ `destroy()` を呼ぶか」です。
SwooleやRoadRunnerのイベントループにおいて、必ず「リクエストの処理が完全に終わり、クライアントへレスポンスを送信し切った瞬間（Deferフェーズやfinallyブロック）」に、このクリーンアップ処理をフックさせなければなりません。
on(‘request’, function ($request, $response) {
try {
// 1. コンテキストの初期化（必要であれば）
// コルーチンごとに独立した空間が確保される
// 2. リクエスト固有の情報をコンテキストにバインド
RequestContext::set(‘request_id’, uniqid(‘req_’, true));
RequestContext::set(‘user_agent’, $request->header[‘user-agent’] ?? ”);
// 3. アプリケーションのビジネスロジックを実行
$controller = new \App\Controllers\HomeController();
$output = $controller->handle($request);
$response->end($output);
} catch (\Throwable $e) {
// エラー時も例外を投げっぱなしにせずハンドリング
$response->status(500);
$response->end(“Internal Server Error”);
} finally {
// 【最重要】リクエスト終了の確実なタイミングでメモリを完全に掃除する
// これを忘れるとメモリリークの温床になります。
RequestContext::destroy();
}
});
—
4. アーキテクトからの実践的アドバイス：『避けるべきコード』と『進むべき道』
常駐型PHPの世界へ踏み出すあなたへ、Zend VMの挙動を知り尽くした私からのアドバイスをいくつか授けておきましょう。
1. `$_GET`, `$_POST`, `$_SERVER` の直接参照を断つ
常駐環境では、これらのスーパーグローバル変数はフレームワーク側がラップし、リクエストごとに上書きまたはモック化されるべきです。ビジネスロジックの深部で `$_GET[‘id’]` のような直接参照を書くのは、時限爆弾を抱えるようなものだと心得てください。
2. シングルトン（`getInstance()`）の濫用を見直す
「データベース接続」や「ロガー」などをシングルトンで保持するのは基本ですが、そのインスタンスが「リクエスト固有の状態（認証ユーザー、トランザクションの状態など）」を持っていないかを厳しく監査してください。状態を持つオブジェクトは、常にリクエストスコープでインスタンス化（またはリセット）されるべきです。
3. メモリリークの恐怖に怯えず、適切に道具を使う
「常駐化＝メモリリークが怖い」と及び腰になる必要はありません。PHP 8以降のエンジンは非常に堅牢であり、GC（ガベージコレクター）も十分に洗練されています。循環参照さえ気をつければ、適切にスコープ管理された常駐アプリケーションは、驚異的なスループットと低いレイテンシをあなたにもたらしてくれます。
—
おわりに
いかがでしたでしょうか？
PHPは単なる「お手軽なスクリプト言語」から、Zend VMとOPcache、そしてSwooleやRoadRunnerといった強力なエコシステムを纏い、真の意味での「ハイパフォーマンス・アプリケーションサーバー」へと進化を遂げました。
「なぜこの変数がここに残っているのか？」
「今、Zend VMのメモリ空間で何が起きているのか？」
この視点さえ持っていれば、どんなに複雑な非同期・常駐アーキテクチャであっても、コードの挙動を完全に脳内でトレースし、美しく安全なシステムを設計できるようになります。
さあ、古い常識を脱ぎ捨てて、極限まで最適化されたモダンなPHPの世界を心ゆくまで堪能してください。あなたの設計するWebシステムが、美しく軽快に疾走することを心から応援しています。