こんにちは。日々のWebシステム開発、本当にお疲れ様です。
JavaやGo、あるいはNode.jsといった他の高水準言語を経験されてからPHPの世界に入ると、その独特の実行モデルに驚くことしばしばですよね。「1リクエストごとにプロセス（またはスレッド）が破棄され、メモリがクリーンアップされる」という伝統的なShared-Nothingアーキテクチャは、メモリリークの恐怖から私たちを解放してくれた一方で、現代のリアルタイム処理や高スループット化の波においては、大きなボトルネックになってきました。
そこで登場したのが、Swoole Coroutineであり、PHP 8.1でネイティブ実装されたFiberです。
これらはどちらも「非同期プログラミングを同期的なコードの書き方で実現する」ための強力な武器ですが、Zend Engineの内部やOSのレイヤで何が起きているのかを正しく理解していないと、思わぬハマりドツボに嵌ることになります。
今回は、この2つの実行コンテキスト切り替えメカニズムの正体を、Zend VMとOSスレッドの境界線から紐解いていきましょう。ここを理解すると、PHPの裏側が驚くほど美しく見えてきますよ。
—
1. そもそも「コンテキスト切り替え」とはZend VMの視点で何か？
通常のPHPスクリプトは、Webサーバー（Nginx + PHP-FPMなど）のリクエストを受け取ると、OSプロセス上でZend VMが起動し、次のようなライフサイクルを辿ります。
1. スクリプトの読み込みとパース（ASTへの変換）
2. オペコード（Opcode）へのコンパイル
3. Zend VMによるオペコードの逐次実行
この実行中、Zend VMは現在の関数呼び出しやローカル変数の状態を保持するために、実行スタック（Execution Stack / `zend_execute_data`）をメモリ上に維持しています。
通常の関数呼び出しであれば、スタックが積まれ（PUSH）、終われば戻る（POP）という単純なツリー構造です。しかし、コルーチンやFiberが目指すのは、「この実行途中のスタック状態を丸ごと一時停止（Yield）し、別の処理を挟んでから、また全く同じ状態から再開（Resume）する」という離れ業です。
これをOSのスレッドに頼らず、ユーザーランド（PHPのコード空間）に近いレイヤで実現するのが、SwooleとFiberの本質になります。
—
2. PHP 8.1ネイティブFiber：ユーザーランドの「中断・再開可能な関数」
PHP 8.1で導入されたFiberは、いわゆる「スタックフル（正確には言語処理系レベルでスタックフレームを制御する）コルーチン」のプリミティブです。OSスレッドとは完全に切り離されており、1つのOSスレッド（PHP-FPMの1プロセスなど）の中で複数のFiberを協調動作（Cooperative Multitasking）させます。
Fiberの内部挙動イメージ
Fiberは、Zend VMの実行コンテキスト（`zend_execute_data`）をヒープ上に退避させる仕組みを持っています。百聞は一見にしかず、実際のコードを見てみましょう。
start(‘開発者’);
echo “2. メイン側: {$output1}\n”;
// メイン側からFiberに値を送り込んで再開させる
$output2 = $fiber->resume(‘お疲れ様です’);
echo “4. メイン側: ファイバーの最終状態 -> {$output2}\n”;
Fiberの限界と美しさ
このFiber、非常にシンプルで美しい設計ですが、「それ単体ではI/O多重化（ノンブロッキングI/O）を行えない」という大きな特徴があります。
Fiberはあくまで「実行のコンテキストを切り替えるスイッチ」に過ぎません。例えば、上記のコード内で `PDO` を使って重いSQLクエリを発行したり、`file_get_contents()` で外部APIを叩いたりすると、その瞬間、PHPプロセス全体がOSレベルでブロック（待機状態）してしまいます。
つまり、Fiberは非同期I/Oの「仕組み（器）」を提供しますが、I/O自体をノンブロッキングにするドライバやイベントループは、開発者が自前で（あるはReactPHPなどのライブラリを通じて）用意する必要があるのです。
—
3. Swoole Coroutine：OSとC拡張が生んだ「ハイパー・コンテキスト制御」
一方で、Swoole（特にSwoole Coroutine）は、PHPの拡張モジュール（C言語製）として実装されており、Fiberとはアプローチの深さが異なります。
Swooleは、内部に独自のC言語ベースのイベントループ（Epoll / Kqueue）を内蔵しています。さらに、PHPの標準的なI/O関数（ファイル読み書き、ソケット通信、PDO等）をフックし、開発者が意識することなく自動的にノンブロッキングI/Oへすり替える（フッキング機能）仕組みを持っています。
Swooleのコード例
OSスレッドとの関係性：M:Nモデルの実現
Swooleは、設定によって「1プロセス・1スレッド（Reactorモデル）」で何万ものコルーチンを回すことも、マルチプロセス／マルチスレッド構成（Manager-Workerモデル）をとることも可能です。
基本的には、1つのOSスレッド上で数千・数万のPHPコルーチンが時分割でZend VMのコンテキストを切り替えて動く（M:Nモデルのユーザーランドスレッド）形になります。これにより、PHPでありながらNode.jsやGo言語に匹敵する並行処理性能を発揮できるのです。
—
4. アーキテクト視点での比較まとめ：どちらを選ぶべきか？
ここまでの仕組みを整理すると、両者の立ち位置がクリアになります。
| 比較項目 | PHPネイティブ Fiber (8.1+) | Swoole Coroutine |
| :— | :— | :— |
| 実装レイヤ | PHPコア（言語機能として標準組込） | C拡張モジュール（サードパーティ） |
| イベントループ | 持たない（ユーザーランドで実装が必要） | 内部に高効率なイベントループを内蔵 |
| I/Oブロッキング | 自動フックしない（同期I/Oはブロックする） | 標準関数を自動フックし、ノンブロッキング化 |
| 環境依存度 | どのPHP環境（FPM等）でも動作可能 | Swooleサーバー環境（CLI）が必須 |
| エコシステム | 黎明期（ReactPHPやAmp v3等で活用が進む） | 独自エコシステム（Swoole/OpenSwoole） |
現場でどう判断すべきか？
- 既存のLaravel/Symfony等のFPM環境をベースに、一部の非同期処理やストリーム処理をきれいに書きたい場合
-> Fiberをベースにしたライブラリの活用が、デプロイの容易さやホスティングの選択肢の広さから現実的です。
- ミリ秒単位のレスポンスが求められるチャットサーバー、APIゲートウェイ、IoTバックエンドなど、完全に非同期・イベント駆動でシステムを設計する場合
-> Swoole（またはOpenSwoole）の採用により、PHPの常識を覆すパフォーマンスを引き出すことができます。ただし、Shared-Nothingではないため、グローバル変数の扱いやメモリリークへの厳密な配慮（Zendバグの踏み抜き注意など）という、新しいレイヤのアーキテクチャ設計スキルが求められます。
—
最後に
PHPは、単なる「Webのテンプレート言語」から、Zend VMと低レイヤのメモリ管理、そして今回解説したような高度なコンテキスト制御を手に入れた「モダンな高並行処理言語」へと進化を遂げました。
「なぜ動くのか」の裏側にあるZend VMのスタック構造や、イベントループの挙動をイメージできるようになると、エラーログに直面したときも、フレームワークのソースコードを読み解くときも、視界がパッとクリアになるはずです。
あなたの設計するシステムが、より堅牢で、より美しいものになることを応援しています。それでは、また次のアーキテクチャ談義でお会いしましょう。