一文で言うと
正規表現（「regex」とも呼ばれる）とは、検索パターンを定義する特殊な文字列のことで、外科手術のような精度でテキストの検索、置換、バリデーションができます。
こいつが解決する問題
想像してみてください。巨大なログファイルがあって、過去1時間に特定IPアドレスから来たエラーメッセージをすべて見つけ出す必要があるとします。「error」で単純にテキスト検索すると、役に立たない情報が洪水のように押し寄せてきます。たくさんのif文と文字列分割ロジックでスクリプトを書くこともできますが、それは脆く、書くのに時間がかかり、デバッグも面倒です。
これが、正規表現が生まれた原生スープです。昔々、Ken ThompsonのようなUnixのパイオニアたちは、テキストを扱うためのより良い方法を必要としていました。彼らはgrep（Global Regular Expression Print）やテキストエディタedのようなツールを開発していました。単純なCtrl+Fではもう力不足だったのです。彼らは、探しているテキストそのものではなく、そのテキストを記述するための言語を必要としていました。
正規表現が解決する問題は、「どうやって見つけるか」という命令的なアプローチ（行をループし、この文字列が含まれているかチェックし、次にそれがあれも含まれているかチェックする…）から、「それがどんな見た目か」という宣言的なアプローチへの移行です。コンピュータに一つのコンパクトなパターンを与えれば、その記述に一致するすべてのテキストを見つけるという重労働をやってのけてくれます。これは、誰かに曲がり角ごとの道順を教えるのと、目的地の写真を見せるのとの違いのようなものです。
内部の仕組み
正規表現は一見するとカオスな記号の寄せ集めに見えますが、実は高度に構造化されたミニプログラムです。「正規表現エンジン」と呼ばれる特殊なソフトウェアがあなたの書いたパターンを読み込み、それを使って入力テキストをスキャンします。この魔法の呪文を分解してみましょう。
構成要素：リテラルとメタ文字
正規表現パターンの核心は、2種類の文字で構成されています。
- リテラル: これらは自分自身にマッチする普通の文字です。パターン
catは、「c」、「a」、「t」という文字の並びそのものを見つけます。ちょろいもんですね。 - メタ文字: これが秘伝のスパイスです。これらは自分自身にはマッチせず、スーパーパワーを持っています。ドット（
.）はその典型例です。これは任意の1文字（通常は改行を除く）にマッチするワイルドカードです。なので、c.tは「cat」、「cot」、「c_t」、さらには「c!t」にもマッチします。
他のスタープレイヤーには、*（直前のものを0回以上繰り返す）、+（1回以上繰り返す）、?（0回または1回）などがあります。これらは量指定子と呼ばれます。
文字クラスと短縮記法
任意の母音にマッチさせたい場合はどうでしょう？ (a|e|i|o|u)と書くこともできますが、ちょっと野暮ったいですよね。代わりに、文字クラス[aeiou]を使うことができます。角括弧を使うと、許可する文字の独自のセットを定義できます。
これは範囲指定でさらに便利になります。任意の小文字にマッチさせたいなら[a-z]。任意の数字なら[0-9]です。
さらにタイピングを節約するために、正規表現には一般的なクラスの短縮記法があります：
\d: 任意の数字（[0-9]）\w: 任意の「単語」構成文字（英数字とアンダースコア）（[a-zA-Z0-9_]）\s: 任意の空白文字（スペース、タブ、改行）\D,\W,\S: その逆！それぞれ、数字以外、単語構成文字以外、空白文字以外にマッチします。
量指定子：何回？
先ほど*、+、?に出会いましたね。これらはエンジンに、直前の文字やグループに何回マッチさせるかを伝えます。
| 量指定子 | 意味 | 例 | マッチする文字列 |
|---|---|---|---|
? |
0回または1回 | colou?r |
"color", "colour" |
* |
0回以上 | goa*l |
"gl", "gol", "goooal" |
+ |
1回以上 | goa+l |
"goal", "goooal" |
{n} |
ちょうどn回 | \d{4} |
"1984" |
{n,} |
n回以上 | \w{3,} |
"cat", "tiger" |
{n,m} |
n回からm回まで | [a-z]{5,7} |
"regex", "pattern" |
一つ重要なのは、これらの量指定子はデフォルトで「貪欲（greedy）」であるということです。できるだけ多くのテキストにマッチしようとします。もし<p>first</p><p>second</p>というテキストに対して/<p>.*</p>/というパターンを使うと、貪欲な.*は最初の<p>から最後の</p>まで全てマッチしてしまいます。これを「怠惰（lazy）」（可能な限り短い文字列にマッチ）にするには、?を追加します：/<p>.*?</p>/。これで、各<p>...</p>タグに個別にマッチするようになります。
アンカーと境界
アンカーは文字にはマッチせず、位置にマッチします。
^: 文字列の先頭（または複数行モードでは行の先頭）の位置を表明します。^catは、「cat」がまさに先頭にある場合にのみマッチします。$: 文字列の末尾（または行の末尾）の位置を表明します。cat$は、「cat」がまさに末尾にある場合にのみマッチします。\b: 「単語境界」を表明します。これは単語構成文字（\w）と非単語構成文字（\W）の間の位置です。パターン\bcat\bは "the cat sat" の中の "cat" にはマッチしますが、 "concatenate" の中の "cat" にはマッチしません。これは単語全体にマッチさせたい場合に信じられないほど便利です。
グループ化とキャプチャ
丸括弧()は2つのことをします：
- グループ化: パターンの一部をグループ化し、それに量指定子を適用できるようにします。
(ha)+は "ha"、"haha"、"hahaha"などにマッチします。 - キャプチャ: 括弧の内部でマッチしたテキストを「キャプチャ」します。これはスーパーパワーです。"ID: 12345" というテキストに
ID: (\d+)というパターンをマッチさせると、エンジンはマッチを見つけたと教えてくれるだけでなく、キャプチャした文字列 "12345" も渡してくれます。これらのキャプチャしたグループ（しばしば$1、$2や\1、\2と呼ばれる）を置換操作で使ったり、処理のために抽出したりできます。
正規表現エンジン：NFA vs. DFA
これはちょっとマニアックな話ですが、なぜ一部の正規表現が壊滅的に遅くなるのかを説明します。あなたが使うほとんどのエンジン（JavaScript、Python、Perl、Javaなど）は、「非決定性有限オートマトン（NFA）」に基づいています。これらは、パターンを通る全ての可能なパスを試すことで動作します。これは「後方参照」（以前にグループでキャプチャされたのと同じテキストにマッチさせる）のような高度な機能を可能にするため強力です。しかし、指数関数的なステップ数を引き起こす可能性もあり、「破滅的なバックトラッキング」と呼ばれる問題につながることがあります。これは、たちの悪い文字列に対して下手に書かれたパターンが、アプリをハングアップさせる原因となる現象です。
古いツール（やGoogleのRE2のような一部の現代的な特殊ツール）は、「決定性有限オートマトン（DFA）」を使用します。DFAははるかに高速で、バックトラッキングのループに陥ることはありませんが、表現力は劣り、NFAの気の利いた機能のすべてをサポートしているわけではありません。
実社会での事例
ログファイル探偵
あるWebサーバーがランダムに500エラーを吐き始め、DevOpsチームはてんやわんやになっていました。ログファイルは、ギガバイト単位の通常のアクセスログと、クリティカルなエラーメッセージが混ざった情報の洪水でした。手動でgrepしても、堂々巡りになるばかり。コンピュータサイエンスの授業を思い出した一人の若手開発者が、サッと正規表現を書き上げました：^\[.*?\] \[error\].*?client: (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})。このパターンは、タイムスタンプで始まる行^\[.*?\]にジャンプし、[error]を含み、そしてクライアントのIPアドレスをキャプチャしました。数秒後には、エラーを引き起こしていた一握りのIPアドレスのリストが手に入りました。原因は、特定のAPIエンドポイントを叩きまくっていたバグのあるWebスクレイパーでした。
教訓: 正規表現は、テキストデータの干し草の山から瞬時に針を見つけ出し、圧倒的な問題を的を絞った調査に変えることができます。
大規模リファクタリング救出作戦
あるスタートアップが、コードベースの中核概念をリブランディングすることにしました。関数create_legacy_widget()を、あらゆるところでbuild_standard_component()にリネームする必要がありました。単純な検索・置換は大惨事を招くもとでした。異なるスペースのケースを見逃したり、最悪なことに、コメントやドキュメンテーション文字列の中身を誤って変更してしまう可能性があったのです。ある開発者は、エディタの正規表現検索・置換機能を使いました。create_legacy_widget\s*\(\s*(\w+)\s*\)を検索し、build_standard_component($1)に置換しました。このパターンは、任意個の空白（\s*）を賢く処理し、関数に渡された引数（(\w+)）をキャプチャして、置換後の文字列に再挿入（$1）しました。この大規模なリファクタリング全体が、1分もかからずに安全に完了しました。
教訓: 正規表現は、基本的な検索ツールでは不可能な、文脈を認識した外科手術的なコード修正を可能にします。
フォームの門番
ある開発者が新しいユーザー登録フォームを作っていました。プロダクトマネージャーからは、ユーザー名に「3から15文字で、英字、数字、アンダースコアのみ」という具体的なルールがありました。最初の試みはif文の連鎖でした。長さをチェックし、次に文字列をループして各文字をチェックする、というものです。それは醜く、非効率的でした。別の開発者が割って入り、そのコードブロック全体をたった一行に置き換えました：if ( /^[a-zA-Z0-9_]{3,15}$/.test(username) )。パターン^...$はマッチを文字列全体に固定し、余計な文字が許されないことを保証し、[a-zA-Z0-9_]{3,15}は文字セットと長さのルールを一度に強制しました。
教訓: データバリデーションにおいて、正規表現はフォーマットルールを定義し、強制するための最も簡潔で強力な方法です。
よくある間違いと落とし穴
- 貪欲さは常に善とは限らない。
*や+のような量指定子は貪欲であることを忘れないでください。"<b>bold</b>and<b>strong</b>"というテキストから<b>.*</b>でHTMLタグにマッチさせようとすると、最初の<b>から最後の</b>までの文字列全体にマッチしてしまいます。最短のテキストにマッチさせるには、怠惰な量指定子*?を使いましょう：<b>.*?</b>。 - 特殊文字のエスケープ忘れ。 リテラルなドット
.やプラス記号+にマッチさせたい場合は、バックスラッシュでエスケープする必要があります：\.、\+。1+1というパターンで1+1を検索しようとすると失敗します。なぜなら+は量指定子だからです。1\+1とする必要があります。 - 「ドットはすべてにマッチする」という落とし穴。
.メタ文字は強力なワイルドカードですが、デフォルトでは改行文字にはマッチしません。これは複数行のテキストを解析する際にハマる原因になります。ほとんどの正規表現エンジンには、「dotall」モードや「single line」モード（しばしばsのようなフラグで有効化される）があり、これを使うと.が改行にもマッチするようになります。 - 破滅的なバックトラッキング。
(a+)+bのような正規表現は単純に見えますが、"aaaaaaaaaaaaaaaaaaaaaaaaaaac"のような文字列に対して実行すると、NFAエンジンはaのグループ化の方法の組み合わせが天文学的な数になり、迷子になることがあります。これによりプログラムがフリーズする可能性があります。ネストされた量指定子、特に内側のグループが複数の方法で同じテキストにマッチできる場合は注意してください。 - 複数行モードでのアンカーの混同。 複数行モード（
mフラグ）を有効にすると、^と$の意味が変わります。もはや文字列全体の絶対的な先頭/末尾ではなく、任意の行の先頭/末尾にマッチするようになります。これを忘れると、予期せぬマッチや非マッチにつながることがあります。
なぜ知っておくべきか
予測可能な構造を持つテキストに関する問題に直面したときはいつでも、正規表現を思い浮かべるべきです。これはテキストの意味を理解するためのツールではなく、そのパターンを理解するためのツールです。次のような場面のために、懐に忍ばせておきましょう：
- バリデーション: これは有効なメールアドレスか？有効な電話番号か？有効な16進数カラーコードか？有効なURLか？正規表現はあなたのデータの門番です。
- パーシング: ぐちゃぐちゃで非構造化なテキストから構造化データを引き出す。ウェブサイトのスクレイピング、サーバーログの分析、レポートの処理などを考えてみてください。
- コード変換: コードベース（codemods）や設定ファイルで複雑な検索・置換操作を実行する。
- ルーティングと書き換え: NginxやApacheのようなWebサーバーは、URLを書き換えたり、受信リクエストをアプリケーションの適切な部分にルーティングしたりするために正規表現を多用します。
正規表現を学ぶことは、開発者のスーパーパワーです。それはプラットフォームを問わず、言語に依存しないスキルであり、あなたのキャリア全体にわたって利益をもたらしてくれるでしょう。
さらに深く
- MDN Web Docs: Regular expressions - JavaScript正規表現の決定版ガイドですが、コンセプトはほぼどこでも通用します。
- Wikipedia: Regular expression - コンピュータサイエンスの理論と歴史への深いダイブ。
- Regular-Expressions.info - 信じられないほど詳細で包括的なチュートリアル兼リファレンスサイト。
- Google RE2 Syntax - パフォーマンスに焦点を当てた人気のDFAベース正規表現エンジンに関する興味深い考察。
- PCRE Man Pages - 多くの現代の正規表現フレーバーに影響を与えた、Perl互換正規表現（PCRE）のシンタックスマニュアル。