Fiberを跨いだ例外伝播の罠：Zend VMのスタック破壊を防ぐ非同期エラーハンドリングの極意
コードレビューをしていて、最近よく見かける光景がある。PHP 8.1で導入された`Fiber`を使い、「これぞモダンな非同期PHPだ」とばかりに協的マルチタスクを実装し、その実、例外ハンドリングの設計を根本から誤っているコードだ。
「Fiberの中で投げられた例外は、外側の`try-catch`で拾えるでしょ？」
もし君がそう思っているなら、今すぐその認識を改めなければならない。Zend VMのメモリ空間とコールスタックの仕組みを理解していれば、それがどれほどナイーブで危険な期待であるかが分かるはずだ。
今回は、Fiberを用いた非同期並行処理において、例外がどのように伝播し、なぜ標準のスタックトレースが破綻するのか。そして、実務のプロダクション環境で耐えうる堅牢な非同期エラーハンドリングの設計解を、Zend VMの挙動を踏まえて徹底的に解説する。
—
1. なぜFiberの例外は「普通のtry-catch」で制御できないのか
PHPの伝統的な同期実行モデルでは、関数呼び出しはZend VMのコールスタック（`zend_execute_data`の連結リスト）上でリニアに行われる。例外（`Throwable`）が発生すると、VMは現在の実行コンテキストから親のスコープへスタックを巻き戻し（Unwinding）、適切な`catch`ブロックを探す。
しかし、Fiberは独自のコールスタックを持つ。
Fiberの内部で発生した例外が処理されずにFiberの境界（`Fiber::suspend()`やFiberのクロージャの終端）を越えようとするとき、例外は自動的に外側のファイバーを呼び出した側（Caller）へ伝播するわけではない。Fiberの実行コンテキスト内にある未キャッチの例外は、Fiberを強制終了させ、呼び出し元での `Fiber::resume()` や `Fiber::start()` の呼び出し時に `FiberError` として再スロー（あるいは致命的なエラー） される。
ここで致命的な問題が起きる。
`Fiber::resume()` を呼んだ親コンテキストの `try-catch` でそれをキャッチしたとしても、スタックトレース（Backtrace）の整合性が完全に破壊されているのだ。
通常の例外であれば、`getTrace()` をたどることで「どこで何が起きて、どの経路で呼ばれたか」が完璧に復元できる。しかし、Fiberを跨いだ例外は、サスペンド（中断）とレジューム（再開）の過程でZend VMの実行コンテキストが切り替わっているため、トレースがFiberの境界で寸断される。ログを見ただけでは、どの非同期タスクのどのコンテキストで起きたバグなのか、完全に迷宮入りすることになる。
—
2. Fiber空間を安全に航海する：設計の3原則
プロダクション環境でFiberを扱う場合、以下の3つの原則を絶対に守らなければならない。
1. Fiber内部の例外は絶対に外に漏らさない（内部で捕捉し、Result/Either型として包む）
2. スタックトレースの断絶を防ぐため、コンテキストID（Fiber ID）をログに伝播させる
3. イベントループ（タスクランナー）側で未処理例外のライフサイクルを完全に管理する
これらを満たすための「実務でそのまま使える非同期タスクランナーと例外ハンドリング」のコードを見ていこう。
—
3. 実装例：堅牢な非同期タスク・マネージャーとエラー伝播機構
以下のコードは、Fiberを用いた非同期タスク群を安全に実行し、例外が発生してもスタックトレースとコンテキストを完全に維持してハンドリングするための実用的なリファレンスだ。
declare(strict_types=1);
namespace App\Async;
use Fiber;
use Throwable;
use Exception;
/
- 非同期タスクの実行結果をカプセル化するクラス（Eitherモナドの概念）
- 例外をスローする代わりに値として保持し、コールスタックの断絶を防ぐ。
/
readonly class TaskResult
{
private function __construct(
public mixed $value,
public ?Throwable $exception,
public int $fiberId
) {}
public static function success(mixed $value, int $fiberId): self
{
return new self($value, null, $fiberId);
}
public static function failure(Throwable $exception, int $fiberId): self
{
return new self(null, $exception, $fiberId);
}
public function isSuccess(): bool
{
return $this->exception === null;
}
}
/
- Fiberを安全に管理・実行する非同期タスクランナー
/
class AsyncScheduler
{
/ @var array
private array $tasks = [];
/
- 新規の非同期タスクを登録する
/
public function addTask(callable $task): void
{
$fiber = new Fiber(function () use ($task): mixed {
try {
// タスクを実行し、結果を返す
return $task();
} catch (Throwable $e) {
// 【重要】Fiber内部で起きた例外は外に投げず、ファイバーIDと共にキャッチする
// これによりZend VMの不意な巻き戻しを防ぐ
return TaskResult::failure(
new Exception(
sprintf(“Fiber Async Error [ID: %d]: %s”, Fiber::getCurrent()?->getId() ?? 0, $e->getMessage()),
(int)$e->getCode(),
$e // 内部例外を保持してチェインを切らない
),
Fiber::getCurrent()?->getId() ?? 0
);
}
});
$this->tasks[] = [
‘fiber’ => $fiber,
‘original_callback’ => $task
];
}
/
- 全てのタスクを協調的に実行し、結果の配列を返す
- @return array
/
public function run(): array
{
$results = [];
$activeTasks = $this->tasks;
// シンプルな協調型イベントループの模擬
while (!empty($activeTasks)) {
foreach ($activeTasks as $index => $taskData) {
/ @var Fiber $fiber /
$fiber = $taskData[‘fiber’];
try {
if (!$fiber->isStarted()) {
// 初回起動
$result = $fiber->start();
} elseif ($fiber->isSuspended()) {
// サスペンドからの再開（I/O待ちなどを想定）
$result = $fiber->resume();
}
// ファイバーが終了している場合
if ($fiber->isTerminated()) {
$fiberId = $fiber->getId();
// ファイバーの戻り値がすでに TaskResult ならそのまま、でなければ成功値としてラップ
if ($result instanceof TaskResult) {
$results[$fiberId] = $result;
} else {
$results[$fiberId] = TaskResult::success($result, $fiberId);
}
// 完了したタスクをキューから除外
unset($activeTasks[$index]);
}
} catch (Throwable $e) {
// 想定外の致命的エラー（FiberErrorなど）
$fiberId = $fiber->getId();
$results[$fiberId] = TaskResult::failure($e, $fiberId);
unset($activeTasks[$index]);
}
}
// 配列のキーを振り直す
$activeTasks = array_values($activeTasks);
}
return $results;
}
}
// ==========================================
// 【実行・検証スクリプト】
// ==========================================
$scheduler = new AsyncScheduler();
// タスク1：正常系
$scheduler->addTask(function () {
echo “タスク1: 開始\n”;
Fiber::suspend(); // 一度処理を中断（非同期I/Oの擬似再現）
echo “タスク1: 再開して終了\n”;
return “データA”;
});
// タスク2：異常系（例外発生）
$scheduler->addTask(function () {
echo “タスク2: 開始\n”;
// データベース接続エラーや外部APIタイムアウトを想定
throw new \RuntimeException(“外部APIとの通信に失敗しました”);
});
echo “=== 非同期スケジューラ起動 ===\n”;
$executionResults = $scheduler->run();
echo “=== 全タスク完了 ===\n\n”;
// 結果の検証とログ出力
foreach ($executionResults as $fiberId => $result) {
if ($result->isSuccess()) {
printf(“[SUCCESS] Fiber #%d 戻り値: %s\n”, $fiberId, $result->value);
} else {
printf(“[FAILURE] Fiber #%d エラー検知: %s\n”, $fiberId, $result->exception->getMessage());
// 開発環境やログ出力ではここで完全なトレースを出力する
// print_r($result->exception->getTraceAsString());
}
}
—
4. この設計がプロダクションで絶対に必要である理由
上記のコードを見れば、単に「エラーをキャッチしているだけ」ではないことが分かるはずだ。
1. Zend VMのスタック保護
Fiber内で発生した例外をそのまま外側へ露出させると、PHPのエンジン側で未処理例外ハンドラが発動するか、意図せぬクラッシュを引き起こす。内部で`try-catch`し、それを`TaskResult`というオブジェクトに包むことで、エラーを「値」として安全にハンドリングしている。
2. Fiber IDによるトレーサビリティの確保
非同期処理では、複数のリクエストやタスクがインターリーブ（錯綜）して実行されるため、単なるファイル名と行数だけでは「どの非同期コンテキストで起きたバグか」が特定できない。例外メッセージに明示的にFiber IDを付与することで、分散トレーサビリティの基礎を作ることができる。
3. メモリリークの防止
Fiberはインスタンスごとに独自のコールスタックやローカル変数をZendのヒープ上に保持する。例外発生時に適切にライフサイクルを閉じ、参照を切る（スコープから外す）ことで、PHP-FPMの1リクエスト内におけるメモリ肥大化やリークを防ぐ。
—
アーキテクトからの最後のアドバイス
Fiberは魔法の杖ではない。PHPにおけるFiberは、あくまで「同期的コードを非同期的に見せるためのプリミティブ（協調型マルチタスクの土台）」に過ぎない。
これを使いこなすには、言語仕様の表面的な機能だけでなく、Zend VMがどのようにスタックを管理し、どのように例外の巻き戻しを行っているのかという「エンジンの内部挙動」に対する深い洞察が不可欠だ。
非同期処理を導入する際は、必ず例外の境界線（Boundary）を意識し、エラーがどこで生まれ、どこで回収されるべきかを設計の段階でコードに語らせること。それができるエンジニアだけが、大規模トラフィックに耐える堅牢なPHPシステムを構築できる。