【テクニカル・上級編】 String.prototype.match()と正規表現の基本 – JavaScript実践ガイド

こんにちは。フロントエンドの現場で日々、JavaScriptエンジンとメモリのせめぎ合いに興じているチーフアーキテクトだ。

今回は、JavaScriptの文字列操作の中でも、一歩間違えるとパフォーマンスのボトルネックになり、セキュリティ上のリスクや予期せぬメモリリークを引き起こす魔女の宅急便のようなメソッド――`String.prototype.match()`と、それに寄り添う正規表現（RegExp）の深淵について語ろう。

「単に文字列から特定の部分を抜き出すだけだろ？」
そう思って安易に`match()`を多用しているなら、今すぐその手を止めてほしい。V8エンジンなどのモダンJSエンジンが内部でどのように正規表現をコンパイルし、どのようにメモリを割り当てているかを知れば、夜も眠れなくなるはずだ。上級エンジニアとして、泥臭い実務を華麗に裁くための「本物の知見」を授けよう。

—

1. `match()` の本質：配列か、`null`か、それとも隠された罠か

まず、大前提のおさらいだ。`String.prototype.match(regexp)` は、引数に渡された正規表現オブジェクト（または暗黙的に変換される文字列）と文字列を照合し、一致した結果を返す。

だが、ここで最初の落とし穴がある。正規表現のフラグに `g`（グローバルサーチ） が付いているかどうかで、返り値のデータ構造が劇的に変化するのだ。

const log = console.log;
const text = “202X年、フロントエンド界隈に突如として現れたA案と、B案。”;

// パターンA: ‘g’ フラグなし
const matchWithoutG = text.match(/[AB]案/);
log(matchWithoutG);
// 出力例: [‘A案’, index: 19, input: ‘…’, groups: undefined]

// パターンB: ‘g’ フラグあり
const matchWithG = text.match(/[AB]案/g);
log(matchWithG);
// 出力例: [‘A案’, ‘B案’]

この仕様の違い、アーキテクチャの観点から見逃してはならない。
`g` がない場合、返されるのは「最初に見つかったマッチの詳細情報（キャプチャグループやインデックス、入力文字列への参照を含む拡張配列）」だ。一方、`g` がある場合は、「マッチした文字列の単純な配列」が返る。

ここで何が起きるか？
`g` なしの場合、返り値のオブジェクトは元の巨大な文字列インスタンス（`input`）への参照を内部に保持し続ける。もしこのマッチ結果をグローバルな状態管理（ReduxやZustandなど）に永続化したり、不要に長くスコープに留めたりすると、元の巨大文字列全体のガベージコレクション（GC）が阻害され、メモリリークの温床になる。
実務でログ解析やマークダウンパーサーを書く際、この「参照の連鎖」によるメモリ肥大化に泣かされたエンジニアを、私は何人も見てきた。

—

2. パフォーマンスの暗黒面：ReDoS（正規表現サービス拒否攻撃）とエンジンの挙動

正規表現を扱う上で、避けて通れないのが ReDoS（Regular Expression Denial of Service） だ。
特に `match()` を含む正規表現の評価は、書き方一つでV8エンジンのバックトラッキング（総当たり的な再試行）を爆発させ、メインスレッドを完全にフリーズさせる。

以下のコードを見てほしい。一見、何気ないメールアドレスやパスワードのバリデーションに見えるかもしれない。

// 【危険なアンチパターン】悪意ある入力によってバックトラッキングが爆発する例
const dangerousRegex = /^([a-zA-Z0-9]+)$@example\.com/;
const maliciousInput = “a”.repeat(30) + “X”; // 30文字の ‘a’ と末尾の ‘X’

console.time(“ReDoS Attack”);
// この一行がブラウザのタブをクラッシュさせる可能性がある
maliciousInput.match(dangerousRegex);
console.timeEnd(“ReDoS Attack”);

量指定子（`+` や “）のネストや、重複する選択肢（`|`）を含む正規表現に対し、マッチしない文字列を与えると、エンジンは無限に近い組み合わせを試行し始める。UIスレッドがブロックされるため、ユーザーの入力が完全にフリーズし、最悪の場合はブラウザタブ全体がクラッシュする。

堅牢なアーキテクチャのための防衛策

1. 複雑な正規表現を避ける: 可能であれば、`String.prototype.includes()` や `indexOf()` といった、O(n) の単純な文字列探索を組み合わせて前処理（フィルタリング）を行う。
2. Atomic Groups（アトミックグループ）や Possessive Quantifiers（強欲量指定子）の活用: JavaScript（ECMAScript 2025以降など）でも提案が進んでいるが、無駄なバックトラッキングを防ぐ書き方を意識する。
3. Web Workerへのオフロード: もし膨大なテキストデータ（数MB単位のログやJSON文字列）に対して複雑な `match()` を実行し続ける必要があるなら、メインスレッドを絶対にブロックしてはならない。処理を `Web Worker` に切り出し、非同期で結果を受け取るアーキテクチャを構築せよ。

—

3. 実務で光る！ `match()` と他のメソッドのスマートな使い分け

「文字列から特定のパターンを探したい」と思ったとき、脊髄反射で `match()` を使っていなか？
実は、目的に応じて最適なメソッドは異なる。それぞれの特性を理解し、無駄なオブジェクト生成を避けるのがプロの技だ。

`matchAll()` を使ったスマートな遅延評価の例

もしあなたが大量のマッチ結果を処理しつつ、メモリ効率を極限まで高めたいなら、`match()` ではなく `matchAll()` とイテレータの組み合わせを採用すべきだ。

大規模テキストから特定のパターン（例: UUID）を効率的に抽出し処理する関数
@param {string} hugeText – 数メガバイトに及ぶ可能性のあるテキスト

/
function processUUIDs(hugeText) {
// UUID v4 の正規表現（必ず ‘g’ フラグが必要）
const uuidRegex = /\b[0-9a-f]{8}-[0-9a-f]{4}-[4][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}\b/gi;

// matchAll() は Iterator を返すため、この時点では全マッチの配列を作らない（メモリに優しい）
const matches = hugeText.matchAll(uuidRegex);

for (const match of matches) {
// 必要な分だけを逐次処理する
console.log(`検出されたUUID: ${match[0]} (インデックス: ${match.index})`);

// 巨大な配列を作らないため、GCのプレッシャーを大幅に軽減できる
}
}

このアプローチの美しさは、「必要な瞬間までメモリ上に配列を生成しない（遅延評価）」という点にある。V8エンジンのメモリヒープを圧迫しないコードこそが、プロダクション環境で生き残る堅牢なフロントエンドの条件だ。

—

4. チーフアーキテクトからの提言

JavaScriptの文字列操作や正規表現は、一見すると初学者が最初に学ぶような基礎的なトピックに見える。しかし、だからこそ、その背後にあるエンジンの挙動、メモリ管理、そして非同期・マルチスレッドの文脈を見落としがちだ。

「とりあえず `match()` で配列を取っておけばいいや」という安易な実装は捨てる。
バリデーションなら `RegExp.prototype.test()`。
大量データの詳細な抽出なら `String.prototype.matchAll()` によるイテレータ処理。
複雑で重いパース処理なら、メインスレッドを救うために Web Worker への逃げ道を確保する。

このレベルの解像度を持ってコードを書く人間だけが、ユーザーのデバイスのバッテリーを消耗させず、カクつかない、真に信頼性の高いWebアプリケーションを構築できる。

さあ、君のIDEを開き、プロジェクト内の無駄な正規表現と `match()` の実装を見直してこい。コードの向こう側で、ブラウザが軽やかに微笑むはずだ。