こんにちは。プロダクトの規模が拡大するにつれて、なぜかCPU使用率がじわじわと上がり、APM（Application Performance Monitoring）のプロファイルを見ると、常に上位に居座っている見慣れた犯人がいますよね。
そう、`mb_substr` や `mb_convert_encoding` といったマルチバイト文字列関数です。
「PHPの文字列処理は重い」という都市伝説まがいの噂を耳にしたことがあるかもしれませんが、それは言語の仕様そのものが悪いのではなく、Zend VMのメモリ管理と内部エンコーディング変換のメカニズムをハックせずに、ナイーブ（素朴）なコードを書き続けているからに他なりません。
他の高水準言語（Node.jsやPythonなど）の経験がある優秀なエンジニアほど、「文字列なんてどれも同じ抽象化されたオブジェクトだろう」と油断しがちですが、PHPの裏側では、C言語レベルのメモリ再割当てと文字コードの妥当性検証（Validation）が泥臭く行われています。
今回は、PHPの心臓部であるZend VMと `mbstring` 拡張モジュールが、1リクエストの中で裏で何をやっているのか。その実行メカニズムを紐解き、高負荷環境でも息切れしない文字列処理の極意を、優しく丁寧に紐解いていきましょう。
—
1. Zend VMの文字列（zend_string）と mbstring の隠されたコスト
まず、PHPの根底にあるメモリ表現を理解する必要があります。PHP 7以降、文字列は単なるC言語の `char` ではなく、最適化された `zend_string` という構造体として管理されています。
struct _zend_string {
zend_refcounted_h gc;
zend_ulong h;
size_t len;
char val[1];
};
ここで重要なのは、`len` が保持しているのは「バイト数（Byte Length）」であり、「文字数（Character Count）」ではないという点です。ここが、マルチバイト文字列処理における悲劇の始まりです。
UTF-8という「可変長」の罠
私たちが普段何気なく使う `UTF-8` は、1文字を1〜4バイトで表現する可変長エンコーディングです。
ASCII文字（英数字）であれば1バイトで済みますが、日本語の漢字などは3〜4バイトを消費します。
もしあなたが、内部エンコーディングを適切に設定していない状態、あるいは `mbstring.internal_encoding` が曖昧な環境で文字列関数を呼び出すと、Zend VMと `mbstring` は以下のような重い処理を毎回実行することになります。
1. 文字コードの正当性チェック（Validation）: 渡されたバイト列が本当にそのエンコーディングとして正しいものか、不正なバイトシーケンスが含まれていないかをスキャンします。
2. 文字境界の特定（O(N)の走査）: 「3文字目を切り出す」という操作であっても、UTF-8は可変長なので、先頭から順にバイトを舐めていき、「どこからどこまでが1文字なのか」を数え直す必要があります。これはC言語のポインタ演算だけでは完結せず、文字エンコーディングの規則に基づいたデコード処理を伴います。
3. メモリの再アロケーション: 変換後の文字列長に応じて、ヒープ領域（zend_stringのallocator）への再割り当てとコピーが発生します。
つまり、`mb_` 系関数をループ内で多用するということは、「毎回Cのレベルで文字列全体をデコードし、メモリを再確保し直す」という、CPUとメモリバスにとって非常に贅沢な遊びを毎リクエスト行っていることになるのです。
—
2. 現場でやりがちな「静かなるボトルネック」
次のコードを見てください。よくあるAPIレスポンスの整形や、長文のサニタイジング処理の一コマです。
$maxLength) {
// 切り出しのたびに新しい zend_string がヒープ上に生成・破棄される
$result[] = mb_substr($comment, 0, $maxLength, ‘UTF-8’) . ‘…’;
} else {
$result[] = $comment;
}
}
return $result;
}
このコード、動くには動きますし、小規模なアクセスであれば何の問題もありません。しかし、1秒間に数千リクエストをさばく高負荷なWeb APIや、数万件のレコードを一度に処理するバッチ処理において、このコードは確実にCPUのボトルネック（特にCプールのCPUバウンド）を引き起こします。
なぜなら、第4引数に毎回 `’UTF-8’` を渡していることに原因があります。PHPは「毎回同じエンコーディングを指定されている」というコンテキストを最適化しきれず、毎回設定値のルックアップや文字エンコーディングハンドラの解決を行ってしまうのです。
—
3. 高速化の極意：コストを劇的に削減する3つのアプローチ
ここからが腕の見せ所です。Zend VMの挙動をハックし、このオーバーヘッドを極限まで削ぎ落とすための実践的なテクニックを共有します。
アプローチ A: 内部エンコーディングのグローバル定義と引数の省略
`php.ini` または `mbstring.internal_encoding`（※PHP 8.0以降では非推奨化が進んでいますが、明示的な設定は重要です）を活用し、コード中の明示的なエンコーディング指定を省略します。
// php.ini または 実行時設定
mb_internal_encoding(‘UTF-8’);
エンコーディング引数を省略すると、`mbstring` 内部のキャッシュやデフォルトハンドラが効率的に働き、無駄な文字列の文字コード解決コストをバイパスできます。
アプローチ B: バイト単位で処理できる部分は「ネイティブ関数」に逃げる
ここが最大の知見です。「すべての文字列操作を `mb_` で行う必要があるか？」を疑ってください。
例えば、文字列の「前方一致・後方一致」「特定のプレフィックスの削除」「単純な長さのチェック（バイト数で十分な場合）」など、ASCII文字の範囲やバイト単位の操作で完結するものは、通常のPHPネイティブ関数（`strlen`, `substr`, `strpos` など）を使いましょう。
Zend VMにとって、ネイティブの文字列関数はオペコードレベルで非常に高速に処理されます（C言語の関数を直接叩く感覚に近い最適化がなされます）。
1024) {
// どうしてもマルチバイトが必要な境界線を超えたときだけ mb_ を召喚する
return mb_substr($str, 0, 256, ‘UTF-8’) . ‘…’;
}
return $str;
}
アプローチ C: OPcacheとJITの恩恵を受けるための型宣言
PHP 8以降のJIT（Just-In-Time）コンパイラは、型が完全に静的に確定しているコードにおいて、ネイティブマシンコードを生成し、Zend VMのインタプリタ実行コストをゼロに近づけます。
文字列処理を行う関数には必ず厳格な型宣言（`declare(strict_types=1);`）と、明確な型ヒントを付与してください。
4. アーキテクトからのメッセージ
いかがでしたでしょうか？
「PHPの文字列処理は重い」のではなく、「Zend VMが裏で文字コードの正当性や可変長の境界を解決するために払っている代償を知らずに、無駄な演算をさせていた」という真実が見えてきたはずです。
フレームワークが提供する便利なヘルパーメソッドの裏側で、何回 `mb_` 系関数が呼ばれているか。その1回1回が、Cレベルのメモリ操作を伴っているというディテールに想像力を働かせること。それこそが、単なる「PHPを書けるプログラマー」から、PHPという実行エンジンを掌の上で操る「真のWebシステムアーキテクト」への飛躍の第一歩です。
次のコードレビューの際には、同僚の書いたコードの中にある「不要な `mb_` の乱用」を見抜き、優しく導いてあげてくださいね。「ここ、ネイティブ関数に置き換えるだけで、FPMのCPU使用率がスッと下がりますよ」と。