正規表現(Regular Expression、文字列のパターンを記述する小さな言語)は、入力チェック・ログ解析・置換処理など日々の開発で欠かせません。一方で「動くけれど読めない」「特定の入力で固まる」といった事故も起きやすい領域です。ここでは2026年の実装事情に合わせて、安全に書くための要点をまとめます。

2026年のJavaScript正規表現で使える機能

ここ数年でJavaScriptの正規表現は大きく拡張されました。かつて「他言語にあるのにJSでは使えない」と言われた後読みやUnicodeプロパティも、現在は主要ブラウザで安定して利用できます。まず全体像を押さえましょう。

機能構文仕様2026年の対応状況
名前付きキャプチャ(?<name>...)ES2018全モダンブラウザ
後読み(?<=...) / (?<!...)ES2018Safari 16.4以降を含め対応
dotAllフラグ/sES2018全モダンブラウザ
Unicodeプロパティ/u, \p{...}ES2018全モダンブラウザ
マッチ位置取得/d + .indicesES2022全モダンブラウザ
集合演算 (vフラグ)/vES2024/2025Chrome 117+ / Firefox 119+ / Safari 17.4+ / Node 20.12+

新しいvフラグ(unicodeSetsモード)は、文字クラスの入れ子・差集合 --・積集合 && を書けるのが特徴です。たとえば「ギリシャ文字のうち記号を除く」を [\p{Script=Greek}--\p{Symbol}] のように表現できます。V8の解説によれば、これは2023年9月以降に主要ブラウザへ展開されました。

先読み・後読み(lookaround)の使い分け

先読み(lookahead)と後読み(lookbehind)は、条件を確認するが文字を消費しない「ゼロ幅アサーション」です。マッチ位置を進めずに前後の文脈だけを判定できるため、置換や抽出で重宝します。4種類の違いを整理します。

種類構文意味
肯定先読み(?=...)直後が … にマッチする
否定先読み(?!...)直後が … にマッチしない
肯定後読み(?<=...)直前が … にマッチする
否定後読み(?<!...)直前が … にマッチしない
例: 金額 "1234567" に 3桁ごとカンマを入れる 先読みで桁位置を判定 /\B(?=(\d{3})+(?!\d))/g で位置だけ取得 1,234,567 先読みは文字を消費しないので、カンマを「挿入」したい位置だけを安全に特定できる
図1: 先読みで「桁区切りの位置」だけを検出する流れ

後読みは長く非対応が続きましたが、2026年現在は主要ブラウザすべてで利用できます。懸念があるのはSafari 16.3以前(2023年初頭)程度で、可変長後読みの完全対応もSafari 16.4以降です。

現場で頻出する実用パターン

毎回ゼロから書く必要はありません。よく使う形を関数化しておくと安全です。名前付きキャプチャを使うと、結果を位置ではなく意味で取り出せて可読性が上がります。

// 日付 YYYY-MM-DD を意味付きで抽出
const re = /(?<y>\d{4})-(?<m>\d{2})-(?<d>\d{2})/;
const { groups } = "2026-06-22".match(re);
// groups.y === "2026", groups.m === "06"

// 全角・絵文字も1文字として数える(vフラグ)
[..."🇯🇵あ".matchAll(/\p{RGI_Emoji}/v)].length; // 1

// 3桁区切り(先読み)
"1234567".replace(/\B(?=(\d{3})+(?!\d))/g, ","); // "1,234,567"

「完璧なメール正規表現」を追わない

メールアドレスの厳密な検証は、実は正規表現に向かない代表例です。RFC 5322の文法を忠実に表すと6000文字超の巨大な式になり、しかも現実には誰も入力しない「コメント付きアドレス」まで通してしまいます。

つまり目的は「形式の妥当性を完璧に判定する」ことではなく、「空欄や明白な誤りを防ぎ、最終判断はバックエンドと確認メールに委ねる」ことです。電話番号や住所も同様で、国・桁数の揺れが大きいほど正規表現単独での完全検証は破綻します。

ReDoS:正規表現がサーバーを止める

ReDoS(Regular expression Denial of Service)は、正規表現の処理が膨大なバックトラッキング(後戻り探索)を起こし、CPUを食い潰す攻撃です。(a+)+ のような入れ子の量指定子が主因で、「破滅的バックトラッキング」と呼ばれます。

入力長に対する処理ステップ数(イメージ) 線形(RE2など) 指数関数的(脆弱な式) 入力が少し伸びるだけで処理時間が爆発する
図2: 安全な式は入力長に比例、脆弱な式は急激に増大する

2024年の調査では、人気OSSの10%超がReDoSに脆弱なパターンを含むと報告されています。AngularのCVE-2024-21490など、実際の脆弱性も継続して報告されています。対策は次の通りです。

  • 入れ子の量指定子を避ける:(a+)+ のような構造を平易な形に書き換える。
  • 原子グループ/所有量指定子:一度マッチしたら後戻りしない構文で爆発を防ぐ(対応エンジンで)。
  • 実行時間の上限:タイムアウトやステップ数制限で最悪ケースを抑える。
  • 静的解析:ReDoSチェッカーで危険なパターンを事前検出する。

WebToolBoxで試す

正規表現は「書いて、当てて、直す」の反復が学習の近道です。正規表現テスターでマッチ結果やキャプチャグループをその場で確認し、思った通りに動くか検証してから本番コードに移しましょう。置換の検証にはテキスト置換、Unicodeの確認にはUnicodeエスケープが便利です。差分確認にはテキスト差分、抽出結果の整形にはJSON整形も合わせて使えます。