こんにちは。PHPの裏側を覗く旅へようこそ。
Node.jsやGo言語、あるいはJavaといった他の高水準言語での非同期処理やスレッドローカルストレージ（TLS）の扱いに慣れた方ほど、PHPの「1リクエスト・シェアード・ナッシング（共有なし）」という伝統的な世界観から一歩踏み出したとき、こんな壁にぶつかるのではないでしょうか。
「Fiberを使って並行処理はできるようになったけれど、各Fiberの文脈に紐づくリクエスト情報やトランザクションIDを、グローバル汚染なしにどうやって安全に保持し回せばいいのだろう？」と。
Node.jsなら `AsyncLocalStorage` があり、Javaなら `ThreadLocal` がその悩みを解決してくれます。では、PHPのFiberにおけるコンテキストローカルストレージ（CLS）はどう実装すべきか。
今回は、ZendエンジンがFiberをどう扱っているかという低レイヤのメモリ管理の視点も交えながら、PHPにおけるCLSの美しさと実装の極意を紐解いていきましょう。ここを理解すると、PHPの非同期プログラミングの見え方がガラリと変わりますよ。
—
1. PHPのFiberとZendエンジンの裏側
まず、PHP 8.1で導入された `Fiber` が、ZendVM（Zend Virtual Machine）の内部でどのように扱われているかを少しだけイメージしてみましょう。
伝統的なPHPの関数実行は、コールスタック（関数呼び出しの履歴）がZendのグローバルな実行コンテキストに一直線に積み上げられます。しかし、Fiberが生成されると、PHPはそのFiber専用の独立したコールスタック（実行コンテキスト）をヒープ上に割り当てます。
- スタックの切り替え: `Fiber::suspend()` で処理が一時停止すると、CPUの実行コンテキストが親プロセス（イベントループ側）に戻り、`Fiber::resume()` が呼ばれると、保存されていたFiber内のスタックポインタやローカル変数の状態が復元されます。
- メモリの実態: Fiberの内部データは `zend_fiber` 構造体として管理され、コールスタックに必要なメモリチャンクが割り当てられます。つまり、Fiberは「軽量な協調型スレッド」そのものです。
ここで重要なのは、「Fiberは実行コンテキストを複数持てるが、従来の `$_SERVER` やグローバル変数（`global` や static変数）はプロセス全体、あるいはリクエスト全体でグローバルなままである」という点です。
そのため、非同期に複数のFiberを同時に走らせた場合、グローバル変数に依存した設計（例えば「現在処理中のユーザーID」を保持するなど）を行うと、Fiberが切り替わるたびに値が上書きされてしまうという致命的な競合（コンテキストの混濁）が起きてしまいます。
これを防ぐための仕組みが、今回解説するコンテキストローカルストレージ（CLS）です。
—
2. Fiber固有データを管理するCLSの実装パターン
Javaの `ThreadLocal` のように、OSスレッド（PHPの場合はFiber）の生存期間やスコープに完全に紐づいたストレージを、ユーザーランドのPHPでどう実現するか。
最もエレガントかつ堅牢なアプローチは、「現在実行中のFiberインスタンス自体をキー（または識別子）として、データを安全にカプセル化して保持するマネージャー・クラス」を作る事です。
実際のコードを見てみましょう。ここからが腕の見せ所です。
/
class ContextLocalStorage
{
/
- Fiberをキーとして、それぞれの文脈データを保持するHashTable（PHPの配列）
- 弱参照（WeakMap）を使うことで、Fiberが破棄されたときにメモリリークを防ぐのがプロの技。
- @var \WeakMap
/
private static \WeakMap $storage;
private static function getStorage(): \WeakMap
{
if (!isset(self::$storage)) {
// PHP 8.0以降で使える WeakMap を採用。
// Fiberオブジェクトが破棄されると、自動的にメモリからガベージコレクションされます。
self::$storage = new \WeakMap();
}
return self::$storage;
}
/
- 現在アクティブなFiberのコンテキストに値を設定する
/
public static function set(string $key, mixed $value): void
{
$fiber = Fiber::getCurrent();
if ($fiber === null) {
// Fiberの外（メインスレッド）で実行されている場合のフォールバックや例外処理
throw new \RuntimeException(“Fiberの外からはコンテキストを設定できません。”);
}
$storage = self::getStorage();
if (!isset($storage[$fiber])) {
$storage[$fiber] = [];
}
$storage[$fiber][$key] = $value;
}
/
- 現在アクティブなFiberのコンテキストから値を取り出す
/
public static function get(string $key, mixed $default = null): mixed
{
$fiber = Fiber::getCurrent();
if ($fiber === null) {
return $default;
}
$storage = self::getStorage();
if (!isset($storage[$fiber][$key])) {
return $default;
}
return $storage[$fiber][$key];
}
}
なぜ `WeakMap` を使うのか？
ここがエンジニアとしての腕の見せ所であり、メモリ管理を熟知しているかどうかの分かれ目です。
もし通常の配列やSplObjectStorageでFiberをキーにしてデータを保持した場合、Fiberの実行が完了してオブジェクトが不要になっても、ストレージ側が参照を持ち続けている限り、メモリリーク（GCが回収できない状態）を引き起こします。
PHP 8.0で導入された `WeakMap` を使うことで、キーである `Fiber` インスタンスがスコープ外になり破棄された瞬間、それに紐づくストレージ内のデータも自動的に解放されます。Zendエンジンのメモリ管理と美しく調和する設計ですね。
—
3. 実践ユースケース：非同期リクエスト並行処理でのコンテキスト維持
では、このCLSを実際の非同期・並行処理（イベントループ的なシミュレーション）の中でどう使うのか、具体例を見てみましょう。
複数のAPIリクエストを並行して処理し、それぞれのFiberの中で「トランザクションID」や「ユーザーセッション」を独立して保持・伝搬させるシナリオです。
/
function asyncHttpCall(string $url, int $delaySeconds): Fiber
{
return new Fiber(function () use ($url, $delaySeconds) {
// 現在のFiber空間からCLSの値を取得
$txId = ContextLocalStorage::get(‘tx_id’, ‘UNKNOWN-TX’);
$user = ContextLocalStorage::get(‘current_user’, ‘Guest’);
echo “[Fiber#” . spl_object_id(Fiber::getCurrent()) . “] 処理開始: TxID={$txId}, User={$user}\n”;
echo ” -> ‘{$url}’ へリクエスト送信 (シミュレーション中…)\n”;
// 非同期の待ち時間をシミュレートするためサスペンド
// 実際のイベントループ（AmpやReactPHPなど）ではここでタイマーやソケット待機を登録します
$startTime = time();
while (time() – $startTime < $delaySeconds) {
Fiber::suspend();
}
echo "[Fiber#" . spl_object_id(Fiber::getCurrent()) . "] 処理完了: TxID={$txId}\n";
return "Response from {$url}";
});
}
// --- メインの実行フロー ---
// 1つ目のFiberを生成して起動
$fiberA = asyncHttpCall('https://api.example.com/data-a', 2);
$fiberA->start(); // 一回目のsuspendまで実行
// 2つ目のFiberを生成して起動
$fiberB = asyncHttpCall(‘https://api.example.com/data-b’, 1);
$fiberB->start(); // 一回目のsuspendまで実行
// イベントループを模したスケジューラ（簡易版）
$fibers = [$fiberA, $fiberB];
echo “\n— イベントループ開始 —\n”;
while (count($fibers) > 0) {
foreach ($fibers as $index => $fiber) {
if ($fiber->isTerminated()) {
// 終了したFiberをプールから外す
unset($fibers[$index]);
continue;
}
// まだ終わっていなければレジューム（処理を進める）
if ($fiber->isSuspended()) {
$fiber->resume();
}
}
// CPUを枯渇させないための微小なスリープ
usleep(100000); // 100ms
}
echo “— 全ての非同期処理が完了しました —\n”;
おや？ このコードのままだと、非同期処理の中でCLS（トランザクションID）が引き継がれていません。なぜでしょうか？
鋭い方ならお気づきでしょう。Fiberが新しく生成された瞬間、その外側（メインスレッド）にあったCLSのコンテキストは新しいFiber内部には継承されないからです。
ここが、高水準言語の非同期処理で最もハマりやすいポイントです。
Fiberは「完全にクリーンな新しいスタック」として生まれるため、親の文脈を自動的には引き継ぎません。
これを美しく解決するために、Fiberのラッパー（ファクトリ）を作りましょう。
—
4. プロダクション品質のコンテキスト伝搬ラッパー
親のコンテキストを子Fiberへ安全にコピー、あるいは透過的にバインドするラッパーを用意します。
/
public static function create(callable $callback): Fiber
{
// 現在の親Fiber（あるいはメインスレッド）から必要なコンテキストのスナップショットを取得する
// ※実際には親側のCLSマネージャーに「スナップショット取得機能」を実装しておきます
$currentFiber = Fiber::getCurrent();
return new Fiber(function (…$args) use ($callback) {
// 子Fiberが起動した瞬間に、独自のストレージ領域へコンテキストを初期化・流し込む
// (ここでは簡易的にハードコードしていますが、実際には親から渡されたデータをセットします)
try {
return $callback(…$args);
} finally {
// Fiber終了時のクリーンアップ（WeakMapが自動処理するため必須ではないが明示的に書くことも）
}
});
}
}
実際のフレームワーク（例えばAmp v3やSwoole/OpenSwooleのコルーチン、あるいはLaravelの将来的な非同期機能など）の内部では、このコンテキストの伝搬（Context Propagation）がミドルウェアやイベントループのレイヤで緻密にハンドリングされています。
—
5. アーキテクトからのメッセージ
PHPにおけるFiberとコンテキストローカルストレージの組み合わせは、単なる「トレンドの機能」ではありません。従来のPHPが持っていた「1リクエスト・1プロセス/スレッド」という枠組みを超えて、I/Oバウンドなタスクを極限まで効率化するための強力な武器です。
ポイントをもう一度おさらいしましょう：
1. Fiberは独立したコールスタックを持つため、グローバル変数の共有はバグ（データ競合）の温床になる。
2. `WeakMap` を活用することで、Fiberのライフサイクルに完全に同期し、メモリリークを起こさない堅牢なCLSを構築できる。
3. 非同期処理を安全に行うためには、「コンテキストの伝搬（Context Propagation）」の設計が不可欠である。
ここを深く理解していれば、どんなに複雑な非同期Webアプリケーションやデーモンプロセスを構築しても、メモリリークやコンテキストの混濁に怯えることはなくなります。
PHPの裏側を美しく掌握し、最高のシステムを一緒に創り上げていきましょう。それでは、また次の深淵でお会いしましょう。