こんにちは。普段から大規模なトラフィックをさばくWebシステムの設計や、パフォーマンスチューニングに頭を悩ませていることと思います。他の言語、例えばGoやNode.js、Pythonなどの経験がある方なら、「遅延評価（Lazy Evaluation）」や「ジェネレータ（Generator）」という概念自体は、すでに日常の武器として使いこなしているはずです。
しかし、「PHPでそれをやったとき、裏のZend VM（Zend Engine）やメモリ空間で何が起きているのか？」というレイヤまで深く潜ったことはあるでしょうか。
「PHPはリクエストが終わったらメモリが全開放されるから、多少のメモリリークや力技の配列処理でも動く」——そう思っていませんでしたか？
もし、数百万件のレコードを扱うバッチ処理や、巨大なCSVのストリーミング処理で、ある日突然 `Allowed memory size exhausted` のエラーに直面したなら、まさに今がPHPの内部エンジンと向き合うべきタイミングです。
今回は、PHPの `Generator` が内部でどのようにステートマシン化され、Zend VMのコールスタックやメモリ（HashTable）をハックしているのか。そのメカニズムを、私と一緒に紐解いていきましょう。ここを理解すると、PHPの裏側の動きが驚くほど美しく見えてきますよ。
—
1. 従来の「配列（Array）リターン」が抱えるメモリの爆弾
まずは、私たちが普段やりがちな、ごく普通のコードから考えてみます。
例えば、DBから100万件のログデータを取得して処理するバッチを想像してください。
$i, ‘message’ => “Log entry {$i}”];
}
return $records;
}
foreach (getLogRecords() as $log) {
// 何らかの重い処理
processLog($log);
}
このコード、動かした瞬間にPHPのメモリ使用量が跳ね上がりますよね。なぜでしょうか？
PHPの「配列」は、私たちが他の言語で想像する連続したメモリ領域（C言語のネイティブ配列など）ではありません。その実体は、Zend Engineの内部で実装された強力かつ複雑なハッシュテーブル（`HashTable`）です。
配列の各要素は、キーと値、そしてハッシュ衝突を防ぐためのポインタなどを維持するために、メタデータを含めて数バイト〜数十バイトのオーバーヘッドを消費します。100万件ものデータを一度に配列に詰め込もうとすると、数ギガバイトのメモリが容赦なく消費され、`php.ini` の `memory_limit` に阻まれてプロセスが強制終了（SIGKILL）されます。
「じゃあ、少しずつLIMITをかけながらループさせよう」——それも一つの手ですが、DBとのラウンドトリップが増え、コードの複雑性が増してしまいます。ここで登場するのが、Generator（遅延評価）です。
—
2. Generatorの正体：Zend VMにおける「中断可能な関数」
PHPの `Generator` は、`yield` キーワードを使用することで、関数の一連の実行を「一時停止（Suspend）」し、呼び出し元に値を返して、あとから「再開（Resume）」できる仕組みです。
他の言語では「コルーチン（Coroutine）」や「イテレータブルなクロージャ」として実装されていることが多いですが、PHP（Zend VM）においては、関数呼び出しそのものをステートマシン（状態機械）へと変貌させる特異な仕組みとして実装されています。
Zend VMの裏側：何が起きているのか？
通常、PHPの関数が呼び出されると、Zend VMは新しい「実行コンテキスト（Execute Data / 呼び出しスタックフレーム）」をメモリ上に生成し、ローカル変数やオペコードのポインタ（`opline`）を管理します。関数が `return` すると、そのフレームは破棄され、メモリは解放されます。
しかし、関数内に `yield` が存在する場合、Zend VMのコンパイル段階（ASTからOpcodeへの変換時）で、その関数は通常の関数とは異なる特別なハンドラを持つようにマークされます。
1. 実行の中断とステートの退避:
`yield $value` に到達すると、Zend VMは現在の関数の実行状態（ローカル変数の値、現在のオペコードの位置、スタックの状態など）を、ヒープ上に生成された `zend_generator` オブジェクトに丸ごと保存します。そして、関数の実行権を呼び出し元（`foreach` ループなど）へ返します。
2. 実行の再開（Resume）:
呼び出し元が次の要素を要求すると（`$iterator->next()` や `foreach` の次のイテレーション）、Zend VMは保存されていた `zend_generator` オブジェクトから状態を復元し、前回 `yield` した直後のオペコードから処理を再開します。
つまり、関数がメモリ上に「生き延びたまま眠る」ような状態を作り出しているのです。
—
3. 実装コードで見るメモリ効率の差
実際に、Generatorを使った書き換え版を見てみましょう。
[‘id’ => $i, ‘message’ => “Log entry {$i}”];
}
}
// メモリ使用量を監視しながら実行
echo “初期メモリ: ” . memory_get_usage(true) . ” bytes\n”;
foreach (getLogRecordsGenerator() as $id => $log) {
// 1件ずつ処理されるため、メモリはほとんど増えない
// processLog($log);
// デバッグ用に10万件おきにメモリを表示
if ($id % 100000 === 0) {
echo “処理件数: {$id}, 現在のメモリ: ” . memory_get_usage(true) . ” bytes\n”;
}
}
このコードを実行すると、100万件という膨大なデータを扱っているにもかかわらず、メモリ使用量は驚くほどフラットなまま推移します。なぜなら、Zend VMのメモリ空間には、「今まさに処理している1件分のレコード」しか展開されていないからです。
これが、大規模データセット処理におけるGeneratorの強力な武器の根拠です。
—
4. アーキテクトが知るべきGeneratorの「落とし穴」と注意点
ここまで聞くと、「すべての配列返却をGeneratorに置き換えれば最強ではないか」と思われるかもしれませんが、それは少し早計です。Zend VMの内部構造を知るアーキテクトとして、光があれば影もあることをお伝えしておかなければなりません。
① ランダムアクセスができない（前進のみ）
Generatorは本質的に「ストリーム（一方向のパイプライン）」です。配列のように `$logs[500000]` のようにインデックスを指定してランダムに要素をフェッチすることはできません。常に先頭から順番に読み進める（Forward-only）必要があります。
② デストラクタや外部リソースの解放タイミング
Generator内部でデータベースのコネクションやファイルハンドルを開いている場合、注意が必要です。`foreach` が途中で `break` や例外（Exception）で抜けたとき、Generatorオブジェクトがスコープ外に出て破棄されるタイミングまで、リソースが保持される可能性があります。
確実にリソースを閉じたい場合は、try-finally構文を駆使するか、明示的にイテレータのライフサイクルを制御する必要があります。
5. まとめ：PHPの裏側を想像しながらコードを書く
いかがでしたでしょうか？
今回は、PHPの `Generator` が内部でどのようにステートマシン化され、Zend VMの実行コンテキストを保持しているのか、そしてそれがなぜメモリ効率の劇的な改善につながるのかを解説しました。
- 配列返却: 100万件のデータを一気に `HashTable` に詰め込むため、爆発的なメモリを消費する。
- Generator（yield）: 関数そのものを一時停止可能なステートマシンに変え、Zend VM上に「現在の1件分」の状態だけを保持して省メモリを実現する。
私たちが日々何気なく叩いているPHPのコードも、一歩レイヤーを下げてエンジン側の視点に立つと、非常に美しく、洗練されたメカニズムで動いていることが分かります。「なぜこの書き方が速いのか」「なぜこの書き方だとメモリリークするのか」。その理由がロジカルに説明できるようになると、あなたの書くコードの質は一段も二段も跳ね上がります。
ぜひ、次のバッチ処理や巨大なペイロードを扱うロジックを設計する際には、Zend VMの呼吸を感じながら `yield` を選択肢に入れてみてください。PHPの裏側が、きっとこれまで以上に綺麗に見えるはずです。