PHPの『Generator』による遅延評価の内部構造：イテレータのステートマシン化とメモリ効率
コードレビューの場で、数百万件のレコードを扱うバッチ処理や巨大なCSVパーサに対して、何の疑いもなく全件を配列に収容しているコードを見かけるたび、私はエンジニアとしての危機感を覚える。
`$results = $pdo->query(‘SELECT FROM massive_table’)->fetchAll();`
このコードが本番環境で何を引き起こすか。Zend Engineのメモリ管理の仕組み、そしてOSの物理メモリとスワップ領域の限界を理解していれば、絶対に書けない悪手だ。数百万行のデータがPDOのバッファからZendの `zval`（PHPの変数コンテナ）の海へと変換され、`HashTable` の構造体オーバーヘッドと共にメモリを食いつぶす。結果、OOM（Out of Memory） Killerにプロセスが慈悲なく刈り取られる。
この絶望的なメモリ枯渇問題に対する最も優雅で、かつZend VMの低レイヤを味方につけた特効薬が `Generator`（ジェネレータ） による遅延評価（Lazy Evaluation）である。
今回は、Generatorが内部でどのようにZend VMのステートマシンをハックし、関数コンテキストを「中断・再開」させているのか。その深淵なるメカニズムと、実務で絶対に外せない設計ルールを解き明かそう。
—
1. Zend VMの裏側：なぜGeneratorはメモリを喰わないのか
通常のPHP関数は、呼び出されるとZend VM上に新しい「実行コンテキスト（Stack Frame）」がスタックされ、処理が完結して `return` した瞬間にそのフレームは破棄され、ローカル変数などの `zval` はGC（ガベージコレクション）の対象となるか即座に解放される。
しかし、`yield` キーワードが出現した瞬間、Zend VMの挙動は劇的に変わる。
ステートマシンとしての Generator
Generatorを導入した関数は、PHPのコンパイル時に通常のOPコード（オペコード）列とは異なり、「中断・再開が可能なステートマシン（状態機械）」へとコンパイルされる。
1. 実行のサスペンド（中断）: `yield` に到達すると、Zend VMはその時点でのローカル変数、実行ポインタ（OPeline）、スタックの状態をすべて内包した `Generator` オブジェクト（C言語レベルでは `zend_generator` 構造体）をヒープ上に生成し、呼び出し元へ制御を返す。
2. スタックフレームの退避: 通常の関数であれば消滅するはずのローカルスコープが、ヒープ上の `zend_generator` にアタッチされた状態で「生きたまま」保持される。
3. レジューム（再開）: 外部から `$generator->next()` または `foreach` による駆動がかかると、Zend VMは保存されていた `zend_generator` のコンテキストを復元し、前回停止したOPコードの次の行から実行を再開する。
この仕組みにより、「必要な瞬間に、必要な1レコード分の `zval` だけを生成し、メモリ上に常に1件分しか存在させない」 という遅延評価が成立する。メモリ使用量が $O(N)$ から $O(1)$ へと劇的に最適化される根拠はここにある。
—
2. 【実務設計】数百万件を安全に処理する堅牢なジェネレータ・パイプライン
では、実務の現場でどのようにGeneratorを設計・実装すべきか。
単に `yield` を使うだけでなく、データベースのカーソル制御、メモリリークを防ぐための構造化、そして型安全性を担保したプロダクションコードのテンプレートを提示しよう。
実装例：メモリ消費量固定型の巨大CSV/DBストリーミング・プロセッサ
/
class StreamableDatasetReader
{
public function __construct(
private readonly PDO $pdo,
private readonly LoggerInterface $logger
) {}
/
- データベースからカーソルベースでデータを1件ずつ遅延ロードする。
- @param string $sql
- @param array
- @return Generator
/
public function lazyFetch(string $sql, array $params = []): Generator
{
// 事前注意: PDOのバッファードクエリ(デフォルト)は全件メモリに載るため、
// 必ずUnbuffered Query（MySQLの場合はPDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false）を使用する。
$stmt = $this->pdo->prepare($sql, [
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false,
]);
$stmt->execute($params);
$fetchCount = 0;
try {
// fetch(PDO::FETCH_ASSOC)により、Zend VM上には常に1行分のzvalしか展開されない
while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
$fetchCount++;
// yieldによって呼び出し元へ制御とデータを渡し、VMの状態をサスペンドする
yield $fetchCount => $row;
}
} catch (\Throwable $e) {
$this->logger->error(“データストリーミング中に異常が発生しました: {$e->getMessage()}”, [
‘processed_count’ => $fetchCount,
exception: $e,
]);
throw $e;
} finally {
// イテレーションが途中で破棄された（breakされた）場合でも、
// クリーナップ処理が確実に走るようにfinallyを記述する。
$stmt->closeCursor();
$this->logger->info(“データストリーミングが正常終了しました。総処理件数: {$fetchCount}”);
}
}
}
呼び出し側のコード（アプリケーション層）
get(StreamableDatasetReader::class);
$sql = “SELECT id, payload, created_at FROM heavy_log_table WHERE status = :status”;
$generator = $reader->lazyFetch($sql, [‘status’ => ‘pending’]);
// foreach は内部で Generator の rewind(), valid(), current(), next() を美しく隠蔽する
foreach ($generator as $index => $row) {
// メモリを圧迫することなく、1件ずつ外部APIへ送信したりファイルへ書き出す
processBusinessLogic($row);
// 1万件ごとにガベージコレクションの明示的実行やメモリ使用量のロギングを行うとさらに堅牢
if ($index % 10000 === 0) {
unset($row);
// gc_collect_cycles(); // 循環参照がない場合は不要だが、重いオブジェクトを扱う場合は有効
}
}
—
3. シニアエンジニアが警鐘を鳴らす：Generator設計の「3大アンチパターン」
Generatorは強力だが、Zend VMの内部挙動を理解していないプログラマが実装すると、かえってバグの温床となる。コードレビューで必ず指摘すべき3つの罠を挙げる。
アンチパターンA: バッファードクエリとの併用による「意味のない遅延」
前述のコードでも触れたが、データベースドライバ側（PDOやMySQLクライアントライブラリ）が結果セットを全件メモリ上にバッファリングする設定（Buffered Query）のままGeneratorを回しても、データベースからのネットワーク転送とメモリ消費の時点で全てを抱え込んでいるため、PHP側でのメモリ節約には全く意味がない。
必ず `PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false` などの非バッファモード（ストリーミングモード）と組み合わせる必要がある。
アンチパターンB: `return` 値の誤解とキャッチ漏れ
PHP 7以降、Generator内でも `return $value;` を使って値を返すことができるようになった。これは `Generator::getReturn()` で取得できる。
しかし、通常の `foreach` 構文では、この `return` 値はループのイテレーションに含まれず完全に無視される。最終的な集計結果やステータスを `return` で返そうとして、「値が取れない」というバグに直面するジュニアエンジニアが後を絶たない。集計値やメタ情報を渡したい場合は、`yield` を用いて最後に流すか、引数として渡したミュータブルなオブジェクト（DTOや配列）の状態を書き換えるアプローチをとるべきである。
アンチパターンC: 例外ハンドリングとリソース解放の放置
Generatorが途中で `break` されたり、例外によってスコープ外に弾き出された場合、Zend VMはデストラクタのタイミングでGeneratorオブジェクトを破棄するが、外部リソース（DBのカーソル、オープンされたファイルハンドルなど）が即座に解放されるとは限らない。
先ほどのサンプルコードのように、必ず `try…finally` 構文を網羅し、イテレーションが途中で途切れたとしてもリソースリーク（カーソルのロックやメモリリーク）が起きない防衛的プログラミングを徹底すること。
—
4. OPcacheとZend VMの最適化観点
OPcache（JIT含む）が有効な環境下において、Generatorを用いたコードは非常に高い親和性を持つ。
Zend VMはOPコードの実行において、関数呼び出しのオーバーヘッド（スタックフレームの構築・破棄のコスト）をGeneratorのサスペンド・レジューム機構によって最小限に抑え込む。
しかし、JIT（Just-In-Time Compiler）の観点から言えば、Generator内の処理が複雑なポリモーフィズムや動的な型変更（Type Juggling）を含んでいると、ネイティブコードへの最適化（Tracesの生成）が阻害される。大規模な数値計算やバイナリパースをGenerator内で行う場合は、厳格な型宣言（`declare(strict_types=1);`）とスカラー型の維持を怠らないことが、JITの恩恵を最大限に引き出す極意となる。
結びにかえて
PHPは「手軽に動くスクリプト言語」から、堅牢で高スループットなWebシステムを支える「エンタープライズ・ランタイム」へと進化した。その進化の中心にあるのが、Zend VMの洗練されたメモリ管理と、今回解説したGeneratorに代表される遅延評価の概念だ。
「動けばいい」という甘えを捨て、Zend VMのメモリ空間とステートマシンの挙動を脳内でトレースしながらコードを書くこと。それこそが、真にスケーラブルなWebシステムを構築するプロフェッショナルの条件である。