こんにちは。PHPの裏側を覗く旅へようこそ。
普段、LaravelやSymfonyといったモダンなフレームワークを使いこなし、「リクエストを受けてレスポンスを返す」という一連の流れを美しく構築しているあなたなら、Node.jsのAsync/AwaitやGoのGoroutineのような「非同期・並行処理」の概念に触れたことがあるはずです。
そしてPHP 8.1で導入されたFiber（ファイバー）を見たとき、こう思ったのではないでしょうか。
「おっ、PHPでもついにユーザーランドで協調的マルチタスク（Cooperative Multitasking）ができるようになったぞ」と。
しかし、いざ実務の非同期処理やストリーム処理の中でFiberを導入し、ふと例外（Exception）に直面した瞬間、頭の中に冷や汗が流れた経験はありませんか？
「あれ……？ スタックトレースが途切れている？ 一体どこからこの例外が投げられたんだ？」
今回は、このFiber環境下における「スタックトレースの整合性とデバッグの闇」について、Zend VMのメモリ管理と実行コンテキストの裏側を紐解きながら、優しく、そして深く解説していきたいと思います。ここを理解すれば、PHPのランタイムの動きが手に取るように見えてきますよ。
—
1. そもそもFiberとは何か？ Zend VMの視点から見る「実行の巻き戻し」
他の言語（例えばJavaScriptやPython）の非同期機構に慣れていると、Fiberも単なる「使いやすいコールバックの糖衣構文」に見えるかもしれません。しかし、Zend VMのアーキテクチャにおいて、Fiberの本質は全く異なります。
PHPの通常の関数実行は、コールスタック（Call Stack）と呼ばれるLIFO（Last In, First Out）のメモリ構造の上で上から下へと流れます。関数Aが関数Bを呼ぶと、Zend VMは新しい`zend_execute_data`（実行コンテキスト）をスタックに積み、CPUレジスタや仮想マシンのポインタを移動させます。
しかし、Fiberはこのコールスタックの概念を「ユーザーランド（PHPコード側）で自由に切り替える」ための機構です。
[ 通常の実行 ]
main() -> fetch_api() -> parse_json() (一本の直線的なスタック)
[ Fiberを用いた実行 ]
Fiber::start()
└─ $fiber->suspend() ── (ここで一度スタックの状態をヒープへ退避！)
│
▼ （別の処理を実行中…）
└─ $fiber->resume() ── (ヒープからスタックの状態を復元して再開！)
重要なのは、Fiberが中断（suspend）されたとき、その時点のスタックフレームはコールスタックから消え、ヒープメモリ上に退避（シリアライズではなく、構造体のまま保持）されるという点です。この仕組み自体は驚異的なパフォーマンスと柔軟性をもたらしますが、ここに「デバッグの罠」が潜んでいます。
—
2. 整合性の課題：なぜFiber内の例外トレースは歪むのか？
さて、本題です。Fiberの中で例外が発生したとき、なぜ私たちはデバッグに苦労することになるのでしょうか。
次のコードを見てください。一見、何気ないFiberの利用例です。
start();
} catch (\Throwable $e) {
// ここでキャッチされた例外のトレースはどうなる？
echo “例外を捕捉: ” . $e->getMessage() . “\n”;
echo $e->getTraceAsString();
}
function callApiRiskFunction(): string {
// 何らかの意図しないバグ（あるいは例外）
throw new \RuntimeException(“API接続タイムアウトまたは致命的エラー！”);
}
このコードを実行したとき、キャッチされた例外の `$e->getTraceAsString()` を出力すると、多くの開発者が違和感を覚えます。
通常であれば、`main() -> try catch -> $fiber->start() -> callApiRiskFunction()` という一連の綺麗な呼び出し履歴（コールスタック）がズラリと並ぶはずです。しかし、Fiberの境界を跨いだ瞬間、「Fiberの内部で何が起きて、どこからresumeされたのか」というコンテキストの繋がりが、標準の例外トレースから綺麗に抜け落ちる、あるいは分断される現象が発生します。
なぜ分断されるのか？
Zend VMにおいて、例外オブジェクト（`zend_class_entry`に基づく`Exception`インスタンス）が生成される際、その時点のスタックトレース（`debug_backtrace()`相当の情報）がスナップショットとして記録されます。
しかし、Fiberは「親のコンテキスト（呼び出し元）」から「子のコンテキスト（Fiber内）」へ制御が移る際、コールスタックの物理的な連続性が断たれます。Zend VMの実行ループ（`execute_ex`）から見れば、Fiberの再開は「全く別の独立した実行ストリームの始まり」のように扱われる瞬間があるため、例外が持つトレースの文脈が、Fiberの呼び出し側（Caller）とFiberの内部（Callee）で分断されてしまうのです。
結果として、プロダクション環境でエラーログを見たときに、「あれ？ このエラー、どのFiberの、どのリクエスト処理の文脈で起きたんだっけ？」と迷子になってしまうわけですね。
—
3. 実践：Fiberの例外をハンドリングし、トレースの整合性を保つアプローチ
この課題に対して、私たちはどう立ち向かえばよいでしょうか？
「Fiberを使うな」というのは簡単ですが、それではモダンな非同期I/Oの恩恵を捨ててしまいます。
ここでは、実務で使える「Fiberの例外を安全に包み込み、失われたトレースの文脈を復元・補正するデザインパターン」を紹介します。
アプローチ：Fiberラッパーと例外の再スロー（Contextual Exception Wrapping）
Fiberのライフサイクルを直接ベタ書きするのではなく、専用のランナー（Runner）クラスやラッパー関数で包み、Fiber内で発生した例外を一度キャッチして「親のコンテキスト情報」を付与した上で再スローする手法が最も堅牢です。
以下のコードを見てください。
fiber = new Fiber(function () use ($task) {
try {
// Fiber内の処理を実行
$this->fiberResult = $task();
} catch (\Throwable $e) {
// 【重要】Fiber内で起きた例外を逃さずキャッチし、
// 親コンテキストへ安全に持ち帰るためのプロキシに格納する
$this->catchedException = $e;
}
});
}
public function run(): mixed {
try {
$this->fiber->start();
} catch (\Throwable $e) {
// Fiberの初期化や起動時に発生した例外
$this->handleException($e);
}
// Fiber内で例外が起きていた場合は、親のスコープ（元のコールスタック）で再スローする
if ($this->catchedException !== null) {
$this->handleException($this->catchedException);
}
return $this->fiberResult;
}
private function handleException(\Throwable $e): never {
// ここで元の例外をラップしつつ、現在のスタックトレース（親の文脈）を統合する
// または、カスタム例外に前後の情報をコンテキストとして埋め込む
throw new \RuntimeException(
sprintf(“Fiber実行中にエラーが発生しました [%s]: %s”, get_class($e), $e->getMessage()),
0,
$e // 以前の例外をPreviousとして保持し、トレースのチェインを維持する
);
}
}
// — 実際の利用例 —
try {
echo “— 非同期処理のシミュレーション開始 —\n”;
$runner = new SafeFiberRunner(function () {
echo “Fiberの内部処理に入りました。\n”;
// 危険な関数を呼ぶ
return callApiRiskFunction();
});
$result = $runner->run();
echo “結果: {$result}\n”;
} catch (\Throwable $masterException) {
echo “\n=== キャッチされた統合例外 ===\n”;
echo “メッセージ: ” . $masterException->getMessage() . “\n”;
echo “— 内部例外（Previous）のメッセージ —\n”;
echo $masterException->getPrevious()?->getMessage() . “\n”;
echo “\n— 完全なスタックトレース（親と子のチェイン） —\n”;
echo $masterException->getTraceAsString();
}
function callApiRiskFunction(): string {
throw new \RuntimeException(“データベースへの接続がタイムアウトしました。”);
}
この設計が優れている理由
1. 例外のチェイン（Previous Exception）の維持
PHPの `Exception` constructorの第3引数 (`$previous`) を使うことで、Zend VMのスタックトレースが分断されても、論理的なエラーの系譜（「どこで起きて、どのFiberランナーを経由したか」）を綺麗に繋ぎ止めることができます。
2. デバッグの容易性
プロダクションのSentryやDatadogなどのエラー監視ツールの多くは、この `getPrevious()` のチェインを辿ってエラーレポートを構築します。この書き方を守るだけで、Fiber環境下であっても見慣れた美しいスタックトレースを取り戻すことができます。
—
4. アーキテクトからのメッセージ：裏側を知ればPHPはもっと楽しくなる
PHPのFiberは、Node.jsのイベントループやGoのゴルーチンに比べると、まだローレベルで、開発者自身が並行性のライフサイクルを丁寧に管理してあげる必要があります。
しかし、それは逆に言えば、「Zend VMがメモリ上でどのようにコンテキストをスイッチしているか」を意識しながら、より堅牢で予測可能なアーキテクチャを自分の手で設計できるという、エンジニアとしての最高な知的遊園地でもあります。
「動くからいいや」ではなく、「なぜこのスタックトレースはこうなるのか？」と一歩踏み込んでエンジンレベルの挙動を想像する。その積み重ねこそが、あなたを単なるフレームワークの使用者から、真の「Webシステムアーキテクト」へと引き上げてくれるはずです。
さあ、次のコードを書くときは、裏側で動くZend VMの鼓動に少しだけ耳を澄ませてみてください。きっと、美しいコードが書けるはずですよ。