こんにちは。普段から大規模なWebシステムの裏側を支えていると、「PHPの配列って、何でも入って本当に便利だけど、メモリをどれだけ食っているんだろう？」とふと気になるときはありませんよね。
他の言語、例えばJavaやGo、あるいはTypeScriptなどを深く触ってきた優秀なエンジニアほど、「PHPの `array` はハッシュマップなのか、動的配列なのか、一体どっちなんだ？」という疑問にぶつかりがちです。そしてネットで調べると「PHPの配列はハッシュテーブルです」というお馴染みの説明に行き着くわけですが、実はPHP 7以降のZendエンジンにおいて、その説明は半分正しくて半分古いのです。
今回は、PHP 7で劇的な進化を遂げ、現代のPHPを高速なモンスターに仕立て上げている「Packed Array（密な配列）」と、従来の「Hash Array（ハッシュ配列）」の裏側の世界を、メモリとZend VMの挙動に焦点を当てながら、優しく紐解いていきましょう。ここを理解すると、あなたの書くコードのメモリ効率は劇的に変わり、PHPの裏側が美しく透けて見えるようになりますよ。
—
1. PHPの配列の正体：すべての裏にある `Bucket` と `HashTable`
まず前提として、PHPの配列のC言語レベルでの実体を確認しておきましょう。Zendエンジンにおいて、変数は `zval`（Zend Value）という構造体で管理されています。そして、配列（`array`）の実体は、`HashTable` というデータ構造です。
従来のPHP（PHP 5時代）の配列は、純粋なハッシュテーブルでした。数値のキーであれ、文字列のキーであれ、すべてをハッシュ関数に通し、衝突解決のための連結リスト（Linked List）を持つ `Bucket` 構造体の配列にデータを配置していました。
// 概念的なイメージ（PHP 5風のハッシュテーブル）
[Hash値] -> Bucket (Key: “name”, Value: “Katsura”) -> Next Bucket (Collision)…
このアプローチは「何でもキーにできる（連想配列として完璧）」という強烈なメリットを生んだ一方で、ポインタを辿るオーバーヘッドと、メモリの非連続性（キャッシュミスの多発）という、パフォーマンス上の大きな代償を払っていました。「ただ順番にデータを格納していくだけのリスト」であっても、裏側では無駄にハッシュ計算を行い、メモリ上のあちこちに散らばった `Bucket` をポインタで繋いでいたのです。
「これを何とかできないか？」
そうしてPHP 7のコア開発者たちが生み出したのが、「Packed Array（密な配列）」という最適化機構です。
—
2. 奇跡の最適化：Packed Array（密な配列）の正体
では、Packed Arrayとは一体何でしょうか。一言で言うと、「キーが 0 から始まる連続した整数であり、順番に追加されただけの配列」において、ハッシュテーブルとしての機能をあえて捨て、C言語の「ただのネイティブな配列（連続したメモリ領域）」に化ける最適化のことです。
Zendエンジンは、配列が生成された瞬間、あるいは要素が追加された瞬間を常に監視しています。もし以下の条件が満たされている場合、エンジンは配列を Packed Array として扱います。
1. キーがすべて整数（Integer）である。
2. キーが `0, 1, 2, 3…` と、隙間なく連続している。
3. キーが追加された順序が、インデックスの順序と完全に一致している。
この条件が揃った瞬間、Zendエンジンはハッシュ計算用のテーブルをすっぽり省略し、`zval` の値だけをメモリ上に隙間なく（Contiguousに）ズラリと並べます。
【Packed Array のメモリイメージ】
[ zval ] [ zval ] [ zval ] [ zval ] <-- メモリ上に連続して並ぶため、CPUキャッシュ効率が極めて高い！
[0] [1] [2] [3]
ハッシュの衝突解決も、文字列のハッシュ値計算も、ポインタの追跡もいりません。CPUのキャッシュヒット率は劇的に跳ね上がり、メモリ消費量も限界まで圧縮されます。これが、現代のPHPが爆速である理由の大きな一角を占めているのです。
---
3. 堕落の瞬間：Packed Array から Hash Array へのフォールバック
しかし、PHPの配列の柔軟性は魔力のようなものです。私たちはうっかり、この Packed Array の最適化を台無しにするコードを書いてしまいます。
Zend VMは非常にシビアです。Packed Array の条件から外れる操作が1つでも行われた瞬間、エンジンは即座に Hash Array（従来のハッシュテーブル）へとフォールバック（格下げ）させます。
具体的に、どのようなコードを書くと Packed Array から Hash Array に落ちてしまうのか、実例を見てみましょう。
‘first’,
1 => ‘second’,
‘status’ => ‘active’ // 文字列キーが混入！
// 判定: 整数キーの連続性ルールが崩壊するため、Hash Array に強制変更されます。
];
ここで知っておくべき重要な事実があります。一度 Hash Array に落ちた配列は、たとえ後からその原因となった要素を `unset()` で削除したとしても、二度と Packed Array には戻りません。 Zendエンジンは配列のライフサイクル途中で「やっぱり最適化し直そう」という無駄なコストを払わない設計になっているためです。
—
4. アーキテクトが教える、メモリとパフォーマンスを守る実践知見
実際のWebアプリケーション開発において、この挙動を意識することがなぜ重要なのでしょうか。
例えば、数万件のレコードをデータベースから取得し、メモリ上で処理するバッチスクリプトや、巨大なJSONレスポンスを組み立てるAPIエンドポイントを考えてみてください。
もし、ループ内で以下のようなコードを書いているとしたら……。
// アンチパターン例：巨大なループでの不規則な代入
$processedData = [];
foreach ($rawRows as $row) {
// もし何らかの条件でキーを明示的に指定し、それが連続していなかったり文字列が混ざると…
$key = $row[‘is_special’] ? ‘special_’ . $row[‘id’] : $row[‘id’];
$processedData[$key] = expensive_function($row);
}
このコードが実行されるとき、`$processedData` は早々に Hash Array へとフォールバックし、それぞれの要素に対してハッシュバケットのオーバーヘッド（メモリの余分な消費、ポインタの維持コスト）がのしかかります。配列の要素数が数百万規模に膨れ上がったとき、この小さな違いがFPMプロセスのメモリ上限（`memory_limit`）を直撃し、突然の `Allowed memory size exhausted` エラーを引き起こす原因になります。
最適化のための設計指針
1. ただのリスト（順番に処理するデータ）なら、キーを明示的に指定しない
`$array[] = $value;` という構文を徹底してください。Zendエンジンが自動的に `0, 1, 2…` の連番を綺麗な Packed Array として安全に構築してくれます。
2. 連想配列とシーケンス（リスト）を混ぜない
「IDをキーにしたマップ構造」と「ただ並べただけのリスト構造」を一つの変数の中でごちゃ混ぜに再利用しないこと。データ構造の性質ごとに変数を分けるのが、PHPのエンジン特性を活かす最大のコツです。
3. OPcacheとJITの恩恵を最大化する
PHP 8以降では、JIT（Just-In-Time）コンパイルによって、こうした配列アクセスの最適化がさらにネイティブコードレベルで加速されます。土台となるデータ構造が Packed Array で美しく保たれているほど、JITが生成する機械語の効率も跳ね上がります。
—
おわりに
いかがでしたでしょうか。普段私たちが何気なく使っている `[]` という記号の裏側で、Zendエンジンはメモリの連続性を保とうと必死にパズルを解いています。
「PHPの配列は遅い」という神話は、もはや過去のものです。内部の仕組み（Packed Array と Hash Array の境界線）を正しく理解し、エンジンが機嫌よく高速化できるようなコードを書いてあげれば、PHPは驚くほど省メモリでキビキビと動作してくれます。
裏側のメカニズムに思いを馳せながらコードを書く。それこそが、凡百のプログラマから一歩抜け出した、真のWebシステムアーキテクトの視点です。ぜひ、今日のコードから意識してみてくださいね。