Fixture、Flag、Replace プレビューによる Regex デバッグ
正規表現をテストする実践ワークフロー: サンプル行、global/multiline flag、capture group、regex を使うのをやめるべきタイミング。
regex バグの多くは構文エラーではなく、flag、改行、エンジンにおける「match」の意味についての誤った前提です。デモ文字列 1 つでハイライトされるパターンが、本番ログ、CSV export、国際化された名前では失敗することがよくあります。
このガイドは、基本的な \d や [a-z] 構文は知っているが、リファクタや検証ルールを ship する前に信頼できる match が必要な開発者向けの再現可能なワークフローです。
パターンではなく fixture から始める
括弧を調整する前に、must-match と must-not-match 行を集めます。
- 実ログ行を数行（secret は redact）
- 空または空白のみの入力
- アプリが国際化対応なら Unicode 名や slug
- 以前 false positive を起こした行
Regex Tester に貼り付け、編集中もセットを開いたままにします。緑のハイライト 1 つはテストスイートではありません。
複雑さを足す前に flag を確認する
1 行では動くがファイル全体では動かないとき、flag が原因であることが多いです。
| 症状 | 試す flag |
|---|---|
| 最初の match だけハイライト | g (global) |
^ / $ が行頭を無視 | m (multiline) |
. が改行で止まる | s (dotAll) |
| 大文字小文字の意外な挙動 | i (ignore case) |
surrogate pair / \p{...} の問題 | u (Unicode) |
ship する flag をコードコメントや runbook に記録してください。将来の自分は /^ERROR/m が必要だった理由を覚えていません。
パターンをレイヤーで構築する
- 存在が分かる安定 prefix を anchor する（
^timestamp=など） - 可変部分は greedy な
.*サンドイッチではなく character class で置き換える - extract または replace するフィールドだけ capture group を追加する
- sed や IDE の replace-all を実行する前に、すべての fixture 行で replace 出力をプレビューする
意図の例: user_id=123 を userId: 123 に変える。$1 が間違った group に入るなら、本番データに触れる前に grouping を直す。
regex が間違ったツールであるタイミングを知る
regex はテキスト内の局所構造に向いています。入力が次の場合は parser を検討します。
- ネストした HTML や XML
- JSON や YAML ドキュメント全体
- プログラミング言語
より大きな行内の URL query string では、まず URL Encoder で正規化し、期待する encoded 形状を match することを検討してください。
5 分レビューチェックリスト
- すべての fixture が期待どおり match または reject される
- flag が記録されている（
gimsuまたはその部分集合） - 複数行 paste で replace プレビューを確認した
- 最悪ケース入力サイズをテストした（大きなログ paste）
- パターンを Python、Java、PCRE にコピーする場合は engine を記録した
関連学習
フィールドごとの文法、capture group、backtracking リスクについては Regular Expressions コース を参照してください。
まとめ
regex をコードのように扱います。fixture、flag、プレビュー、そして ship。 最速の修正は、ネストした quantifier を足すことではなく、しばしば g や m を toggle することです。