正規表現デバッグワークフロー

信頼できる regex 作業は テスト駆動 です。パターンをコードのように扱い: 入力例と期待マッチをセットにします。

ステップ 1: 代表的 fixture を集める

マッチすべき入力と マッチしてはいけない 入力を集めます。

• 本番ログからの happy path サンプル（秘密を redact）
• エッジケース: 空文字列、Unicode、余分な空白、欠落フィールド
• 以前遭遇した既知の false positive

デモ文字列 1 つの緑ハイライトはテストスイートではありません。

ステップ 2: パターンを段階的に絞る

アンカー付きで厳しく始め、緩めます。

1. ^ で固定プレフィックスにマッチ
2. 可変セグメントに文字クラスを追加
3. 長さが本当に可変な箇所にのみ量指定子を追加
4. 要件が求めるときだけ i や u を有効化

マッチが多すぎるなら、negative lookahead で除外を足す 前に 絞り込んでください。

ステップ 3: キャプチャグループを検査

各マッチでグループ値が解析したいフィールドに対応するか確認します。置換テンプレートの off-by-one $n バグはよくあります。

すべての fixture 行で並べ替え出力を確認する replace プレビューを使います。

ステップ 4: 壊滅的バックトラッキングに注意

(.*)* のようなネスト量指定子は大入力でエンジンを停止させます。症状:

• 貼り付けでブラウザタブが固まる
• CI lint ステップがタイムアウト

修正には possessive/lazy 量指定子、atomic グループ（サポート時）、.* サンドイッチの書き換えがあります。

よくある誤りチェックリスト

誤り	症状
g 忘れ	最初の行だけハイライト
s なしの .	複数行 JSON が失敗
replace で $ 未エスケープ	誤ってリテラル $1 が挿入
国際化テキストに \w	有効な名前を見逃す
ネスト形式の解析	HTML/JSON で false positive

要点

fixture、文書化されたフラグ、実サイズ貼り付けでの replace プレビュー と共に regex を出荷してください。複雑さが増えたらパーサーへ—regex は scalpel のままにし、hammer にしないでください。