こんにちは。普段から「どうすればPHPのパフォーマンスを極限まで引き出せるか」を考え、Zend Engineの挙動やメモリ管理の隅々まで目を光らせているシニア・アーキテクトの私です。
Node.jsやGo言語、あるいはJavaなどで非同期処理や協調的マルチタスク（GoroutineやAsync/Await）の恩恵を受けてきた優秀なエンジニアほど、PHPのコードを書くときに「1リクエスト・1スレッドの同期処理の限界」を感じて壁にぶつかりがちですよね。
「PHPでも非同期I/Oやノンブロッキングな並行処理をやりたい！」
そう思ったとき、PHP 8.1で導入された Fiber（ファイバー） はまさにゲームチェンジャーとなります。しかし、ネット上の解説の多くは「関数の実行を中断・再開できる機能です」といった表面的なお話に終始しています。
今回は、このFiberがPHPの内部エンジン（Zend VM）およびメモリ空間において、物理的に何をやっているのかを徹底的に解き明かしていきましょう。ここを理解すれば、PHPの裏側が驚くほど美しく、そしてクリアに見えるようになりますよ。
—
1. そもそもFiberとは何か？ 〜スレッドとの決定的な違い〜
私たちが普段使っているOSスレッドは、コンテキストスイッチのたびにカーネルモードへの遷移が発生し、CPUキャッシュのフラッシュやメモリ管理のオーバーヘッドが伴います。だから「何千ものリクエストを同時に捌くためにスレッドを立てまくる」のは、物理的なリソースの無駄遣い（C10K問題）になりますよね。
一方、Fiberが提供するのはユーザーランド（ユーザースペース）での協調的マルチタスクです。
OSはFiberの存在を知りません。すべてはPHPのプロセス（より正確にはZend Engineの実行コンテキスト）の内部で、メモリ上のコールスタックを巧妙に付け替えているだけなのです。
物理的なメモリ空間の仕組み
PHPの1リクエストは、通常、ひとつの「メインの実行コンテキスト」上で動いています。関数が呼ばれるたびに、Zend VMのコールスタック（`zend_execute_data` の連結リスト）がグローバルあるいはプロセス固有のヒープメモリ上に積み上がっていきます。
Fiberを生成すると、エンジンはそのFiber専用の独立したコールスタック領域と実行コンテキスト（`zend_fiber_context`）を新しくアロケートします。これが、スレッドを使わずに「別の処理の流れ」を同居させられる物理的なカラクリです。
—
2. Fiberのライフサイクルとコールスタックの退避・復帰
百聞は一見にしかず。まずは実際にFiberを使ったコードを見てみましょう。イベントループや非同期I/Oライブラリ（AmpやReactPHPなど）が内部でやっている処理のミニチュア版です。
{$valueFromMain}\n”;
// 3. 処理を完了して値を返す
// 戻り値は Fiber::start() または Fiber::resume() の返り値になる
});
echo “— メイン: Fiberを起動します —\n”;
// Fiberをスタートさせ、最初の suspend() まで実行する
$valueFromFiber = $fiber->start(‘Worker-1’);
echo “メイン: Fiberから中断値を受け取りました: ‘{$valueFromFiber}’\n”;
echo “— メイン: 外部で何らかの非同期処理（I/O待ちなど）を実行中と仮定 —\n”;
echo “— メイン: Fiberに値を渡して再開させます —\n”;
// suspend() の位置に値を注入し、Fiberの残りの処理を最後まで走らせる
$fiber->resume(‘特製データ（MySQLのクエリ結果など）’);
echo “— メイン: すべての処理が完了しました —\n”;
実行の裏側で何が起きているか？（Zend VMの視点）
1. `new Fiber(…)`
Zend Engineは、このクロージャを実行するための独立したスタック（通常は数キロバイトから必要に応じて拡張されるメモリチャンク）を確保します。まだZend VMの実行ポインタ（OPeline）はこのFiberの内部を指していません。
2. `$fiber->start()`
メインの実行コンテキストが一時停止し、CPUレジスタや現在のZend VMのスタックポインタ（`execute_data`）の状態を退避させます。そして、実行ポインタをFiber側のコンテキストへスワップ（切り替え）します。これでFiber内部のコードが動き始めます。
3. `Fiber::suspend()`
ここが最も美しいポイントです。Fiberの内部から、親であるメインコンテキストへ実行権とデータを「投げ返す」ことができます。Zend VMは再びスタックをメイン側にスワップし、メインスクリプトの `start()` の次の行へと処理を戻します。
4. `$fiber->resume()`
メイン側で準備できたデータ（例えば、非同期で取得できたデータベースのレスポンスなど）を `resume()` の引数としてFiber内部に送り込み、中断した `suspend()` の返り値として処理を再開させます。
この一連の切り替えには、OSのコンテキストスイッチのような重いカーネルモードへの往復が一切ありません。純粋なメモリ上のポインタ書き換えとスタックの切り替えだけで完結するため、極めて高速に動作するのです。
—
3. 非同期I/Oイベントループとの連携処理
「なるほど、一時停止と再開ができるのは分かった。でも、これをどう実務のWebアプリケーションで活かすのか？」
ここが重要です。Fiber単体では、ただの「行ったり来たりできるサブルーチン」に過ぎません。真価を発揮するのは、非同期I/Oイベントループ（例: RevoltライブラリやAmp v3など）と組み合わせたときです。
実務でよくある「外部APIへのHTTPリクエストをノンブロッキングで並行処理する」イメージを、擬似的なコードで紐解いてみましょう。
start(…$args);
if (!$fiber->isTerminated()) {
$this->fibers[] = [‘fiber’ => $fiber, ‘yield_value’ => $value];
}
}
public function run(): void {
// イベントループの模擬：すべてのファイバーが終了するまでループを回す
while (!empty($this->fibers)) {
foreach ($this->fibers as $index => $task) {
$fiber = $task[‘fiber’];
// ここで本来は非同期I/O（ストリームの読み込み可能判定など）を待つ
echo “[イベントループ] I/O待ちをシミュレート: {$task[‘yield_value’]}\n”;
usleep(100000); // 100ms待つふり
if (!$fiber->isTerminated()) {
// I/Oが完了したと仮定してFiberを再開
$fiber->resume(“APIレスポンスデータ”);
}
}
// 完了したFiberを配列から掃除する
$this->fibers = array_filter($this->fibers, fn($t) => !$t[‘fiber’]->isTerminated());
}
}
}
$manager = new AsyncManager();
// タスク1
$task1 = new Fiber(function () {
echo “タスク1: 外部API-Aへリクエスト送信\n”;
$res = Fiber::suspend(“API-AのURL”);
echo “タスク1: 取得完了 -> {$res}\n”;
});
// タスク2
$task2 = new Fiber(function () {
echo “タスク2: 外部API-Bへリクエスト送信\n”;
$res = Fiber::suspend(“API-BのURL”);
echo “タスク2: 取得完了 -> {$res}\n”;
});
// マネージャーに登録して協調的マルチタスクを実行
$manager->addTask($task1);
$manager->addTask($task2);
$manager->run();
このアーキテクチャの強みは、「ブロッキングが発生するI/O待ちの間に、CPUを他のリクエスト（Fiber）の処理に明け渡せる」という点にあります。従来のPHPでは、cURLのマルチハンドルのような特殊な機構を使わないと難しかった非同期処理が、通常の同期コードを書くようなフラットな記述力で実現できるようになるのです。
—
4. アーキテクトが警鐘を鳴らす「Fiberの落とし穴」
ここまでFiberの美しさと物理メカニズムを語ってきましたが、実務の現場で使う際には、Zend VMとメモリの仕様上、絶対に頭に入れておかなければならない注意点があります。
1. ブロッキングな関数（PDOやfile_get_contentsなど）の扱い
PHPの伝統的な標準関数の多く（特に従来の`PDO`による同期クエリや`file_get_contents()`など）は、OSのソケットに対してブロッキングI/Oを行います。
もしFiberの内部で普通のブロッキング関数を呼んでしまうと、その瞬間にPHPプロセス全体の実行がその場でフリーズします。せっかくFiberで並行処理を書いても、イベントループ自体が止まってしまうため意味がありません。
そのため、Fiberを活かすには Amp v3やReactPHPなどの非同期ドライバーに対応したドライバ（AmpのMySQLクライアントなど）を使う必要がある という点を忘れないでください。
2. 参照カウントとメモリリークの危険性
Fiberは独自のコールスタックやローカル変数、クロージャを保持するため、通常のスコープよりもオブジェクトや変数の生存期間が長くなりがちです。
特に、Fiberのクロージャ内で外部変数を `use` し、その中でさらに循環参照を作ってしまうと、Fiberインスタンスが破棄されるまでメモリが解放されません。PHPのガベージコレクション（GC）は強力ですが、ロングランで動く非同期ワーカープロセス（RoadRunnerやFrankenPHPなど）の上でFiberを大量に使い捨てる設計にする場合、メモリリークの温床になりやすいので、スコープと参照のライフサイクルには細心の注意を払いましょう。
—
5. おわりに：PHPの未来を掌握する者へ
PHP 8.xのFiberは、単なる「便利な新機能」ではありません。長年PHPが抱えてきた「I/Oバウンドな処理における非同期の壁」を、言語コアのレベルで、かつ美しくエレガントに突破するための強力な武器です。
裏側で何が起きているのか――
- 独立した `zend_fiber_context` によるメモリスタックの切り替え
- OSスレッドを使わない、ユーザーランドでの高速なコンテキストスイッチ
- イベントループと協調したノンブロッキングな実行制御
これらを脳内で完全にトレースできるようになったあなたなら、もうフレームワークの裏側の挙動で迷うことはないはずです。
ぜひ、この深遠なPHPのエンジン内部の知見を武器に、次世代の高速なWebアプリケーション設計に挑戦してみてください。ここを理解したあなたなら、必ず素晴らしいシステムを築き上げられると私は確信しています。