正規表現テスター
正規表現が、文章のどこに当たるかを確かめます。
無料・登録不要
使い方
- 1「正規表現パターン」を入れます
- 2「テスト文字列」に確かめたい文章を入れます
- 3「テストする」を押し、当たった部分を確認します
例
入力例
パターン: \d{3}-\d{4} / テスト文字列: 郵便番号は123-4567です。電話番号は090-1234-5678です。
結果の例
パターン: /\d{3}-\d{4}/g
マッチ数: 2
[1] "123-4567" (位置: 5)
[2] "090-1234" (位置: 21)
あわせて使えるツール
使い方と例文
正規表現テスターの使い方
- 1正規表現パターンを入力欄に入力します
- 2テスト対象の文字列を入力します
- 3「生成する」ボタンをクリックしてマッチした文字列と位置の一覧を確認します
正規表現テスターの例文・サンプル
正規表現マッチの例
パターン: \d{3}-\d{4} / テスト文字列: 郵便番号は123-4567です。電話番号は090-1234-5678です。パターン: /\d{3}-\d{4}/g
マッチ数: 2
[1] "123-4567" (位置: 5)
[2] "090-1234" (位置: 21)
よくある質問
正規表現テスターは無料ですか?
スマートフォンでも使えますか?
入力したコードやデータは安全ですか?
判断基準と失敗例
良い正規表現テスターの判断基準
正規表現をプログラムや設定に組み込む前に、本ツールでマッチ結果を確認し、下の判断基準でテストの抜けがないかを点検してください。正規表現は「動いたように見えて、想定外の文字列で誤動作する」ことが多いため、テストの幅が品質を決めます。
意図した箇所「だけ」にマッチしているか
マッチした件数と位置の一覧で確認し、拾いたいものが全部拾えているかに加えて、拾ってはいけないものまでマッチしていないかを見ます。過剰マッチは本番データで初めて発覚しがちです。
マッチすべきでない文字列でも試したか
正しい例だけでなく、形式の崩れた例・紛らわしい例を貼って「マッチしないこと」を確認します。入力チェックに使う式ほど、この除外側のテストを省かないでください。
エッジケースを試したか
空文字・行の先頭や末尾・全角と半角の混在・記号入りなど、境界になりやすいパターンを意識的に混ぜます。テスト文字列が綺麗な例 1 件だけだと、エッジケースの穴に気づけません。
貪欲マッチと最小マッチを使い分けたか
「.*」は可能な限り長くマッチし、「.*?」は最短でマッチします。タグや引用符など区切りに挟まれた部分を取り出す時に結果が大きく変わるため、どちらの挙動が必要かを決めてから書きます。
組み込み先の言語との方言差を確認したか
正規表現には言語・ツールごとの方言があり、ここで動いた式がそのまま動くとは限りません。組み込み先の言語のドキュメントで、使っている記法が対応しているかを確認します。
式が複雑になりすぎていないか
入れ子の繰り返しを多用した複雑な式は、特定の入力で処理が極端に遅くなることがあります。シンプルな式に分割できないかを検討し、長めの文字列でも結果がすぐ返るかを確認します。
ありがちな失敗例(NG → 改善)
NG正常なデータ 1 件だけでテストして、そのままプログラムに組み込む。
改善マッチすべき例とマッチすべきでない例を複数件ずつ貼り、両方の結果を確認してから組み込む。
正規表現は想定外の文字列に過剰マッチしやすく、1 件のテストでは誤動作の芽を見つけられません。
NG「".*"」で引用符の中身を取ろうとして、1 行に複数ある引用符の最初から最後までが丸ごとマッチする。
改善最小マッチの「".*?"」にするか、「"[^"]*"」のように引用符以外の文字だけを許す書き方にする。
貪欲マッチは可能な限り長い範囲を取るため、区切り文字が複数回現れる文字列では意図より広くマッチします。
NGこのツールで動いた式を別の言語にそのまま貼り付けて、エラーや違う結果になる。
改善組み込み先言語の正規表現ドキュメントで記法の対応を確認し、組み込み後にもう一度同じテストをする。
正規表現には方言があり、同じ式でも言語によって解釈や対応機能が異なります。
くわしい説明
正規表現パターンをテスト文字列に対して検証。マッチした文字列と位置を一覧表示で確認できます。
正規表現テスターをコードに組み込む前の下見に使う
正規表現(Regex)はテキスト処理に便利ですが、書いた式が意図通りに動作するかを試行錯誤しながら確認することになります。プログラムに組み込んでから動作確認すると時間がかかります。IDE 内で試す場合も、環境の準備が要ります。本ツールは正規表現と対象テキストを入力して生成するボタンを押すと、マッチした文字列とその位置を一覧で返します。グループに名前を付けた式なら、グループごとの中身も一覧に並びます(名前を付けないグループの表示は今回試していません)。学習・デバッグ・本番投入前のテストに使えます。
入力欄は「正規表現パターン」と「テスト文字列」の2つだけです。会員登録もインストールも要らず、開いてすぐ試せます。
学習中の確認と、データ抽出パターンの検証に効く場面
【1. 正規表現の学習】学習教材を読みながら「この式は何にマッチする?」を即座に確認できます。
【2. データ抽出のロジック検証】メールアドレス・電話番号・URL などのパターン抽出を、実データで試せます。
【3. プログラム組み込み前のテスト】Python・JavaScript・Ruby などの正規表現を、コード組み込み前にブラウザでパターン確認できます。
この3つに共通するのは、式を書く前ではなく書いた後に効くという点です。手元のデータを丸ごと貼り、拾いたい箇所が全部拾えているか、拾ってはいけない箇所まで拾っていないかを、マッチ数と位置の一覧で数える使い方が実用的でした。ただし本ツールが解釈するのは JavaScript の正規表現です。他の言語へ持っていくときは、同じ式が同じ結果になるとは限りません。
郵便番号と電話番号が並ぶ文に \d{3}-\d{4} をかけた実処理結果
編集部で4パターンを実際に処理し、画面に返ってきたテキストをそのまま記録しました。処理はブラウザの中で完結し、今回の検証中にサイトの AI 処理窓口へ送られた通信は1件もありませんでした。
【入力】パターン: \d{3}-\d{4} / テスト文字列: 郵便番号は123-4567です。電話番号は090-1234-5678です。
【返ってきた結果】 パターン: /\d{3}-\d{4}/g マッチ数: 2 [1] "123-4567" (位置: 5) [2] "090-1234" (位置: 21)
読みどころは2つあります。1つ目は、電話番号 090-1234-5678 のうち先頭の 090-1234 だけが拾われ、後ろの -5678 が残ったことです。式が3桁と4桁の組み合わせしか指定していないためで、ツールの不具合ではありません。自分の式が途中までしか拾えていないかどうかは、この一覧で気づけます。2つ目は位置の数え方です。123-4567 の位置が 5 と出ています。文字列の先頭を0として数えた位置なので、6文字目から始まっている、という読み方になります。
[a-z]+ を ABC abc AbC に当てて分かった、フラグが g 固定という作り
2つ目のパターンです。
【入力】パターン: [a-z]+ / テスト文字列: ABC abc AbC
【返ってきた結果】 パターン: /[a-z]+/g マッチ数: 2 [1] "abc" (位置: 4) [2] "b" (位置: 9)
大文字の ABC は1つも拾われず、AbC の中の小文字 b だけが1文字として拾われました。画面には大文字と小文字を区別しない設定(i フラグ)の切り替えが無く、式には常に g(見つかった箇所を全部拾う)だけが付いて実行されます。つまり「ABC も abc も両方拾いたい」という指定は、この画面からは選べません。同じことをしたい場合は、式の側を [A-Za-z]+ のように書き分けることになります。
大文字小文字の混在は、氏名・型番・メールアドレスの検証でよく出てきます。手元では動いたのに本番で漏れる、という食い違いが起きやすいのはこの部分です。
名前付きグループの表示と、開きカッコだけを入れたときのエラー文
3つ目と4つ目のパターンです。
【入力】パターン: (?<area>\d{3})-(?<local>\d{4}) / テスト文字列: 123-4567
【返ってきた結果】 パターン: /(?<area>\d{3})-(?<local>\d{4})/g マッチ数: 1 [1] "123-4567" (位置: 0) グループ "area": "123" グループ "local": "4567"
グループに名前を付けると、名前ごとに中身が分かれて表示されました。市外局番と加入者番号、年と月と日のように、1回のマッチから複数の値を取り出したいときは、この書き方が確認しやすいです。
【入力】パターン: ( / テスト文字列: test
【返ってきた結果】正規表現エラー: Invalid regular expression: /(/g: Unterminated group
閉じカッコを忘れた式は、処理される前にエラーで止まりました。日本語の「正規表現エラー:」の後ろに、ブラウザが返した英語がそのまま続く形です。Unterminated group は閉じていないグループがあるという意味ですが、英語のまま出るため、原因にたどり着くには読み解きが要りました。
4パターンを通して見えた正規表現テスターのクセと弱点
【クセ1】結果は必ず「パターン: /式/g」と「マッチ数: N」の2行で始まり、その下にマッチした文字列と位置が番号付きで並びます。名前付きグループがあるときだけ、その下に字下げでグループ名と中身が続きます。
【クセ2】位置は0から数えます。1文字目は位置0です。エディタの行番号や桁番号とは数え方が違うので、そのまま突き合わせると1つずれます。
【クセ3】式の誤りは結果ではなくエラー文で返り、ブラウザが出す英語がそのまま表示されます。
弱点は、大文字と小文字の区別を切り替えるフラグを画面から選べないことです。今回の4パターンでは、処理が固まる・結果が壊れるといった崩れは出ませんでした。ただしこれは4パターンで見えた範囲であって、どんな式とどんな文字列でも同じように返る保証ではありません。構造上の限界としてもう1つ、極端に長い文字列と入れ子の多い式を組み合わせたときの処理時間は今回測っていません。処理は自分のブラウザの中で走るため、重い式を入れれば待たされるのは自分の端末です。
この正規表現テスターに向かない使い方と、方言・貪欲マッチの落とし穴
1つ目の失敗は、正規表現の方言を意識しないことです。JavaScript / Python / Ruby / PHP など、言語ごとに微妙に文法が異なります。本ツールは JavaScript 標準の正規表現を採用しているため、他言語に組み込む時は文法差を確認してください。
2つ目は、貪欲マッチ(greedy)と最小マッチ(lazy)の違いです。「.*」と「.*?」では結果が大きく変わるため、意図に合わせて選んでください。
3つ目は、実行時間です。複雑な式に長文を入力すると、Catastrophic Backtracking で処理が止まることがあります。シンプルなパターンから組み立てるのが原則です。
向かない使い方もはっきりしています。顧客名簿や個人情報そのものを貼って試すのは避けてください。処理自体はブラウザの中で終わりますが、業務データを外部サイトの入力欄に貼る行為が社内規程で禁じられている会社は珍しくありません。形の似たダミーデータで十分に検証できます。もう1つ、大文字小文字をまたぐ検証、複数行モードや置換結果の確認は、フラグと置換欄が無い以上この画面だけでは完結しません。
日本語画面で完結する点と、Regex101 などとの使い分け
Regex101 などの本格的な正規表現テスターもありますが、英語UIで日本語ユーザーには敷居が高い側面があります。本ツールは日本語UIで、ブラウザ内で完結し、サーバー送信なしでマッチ結果がすぐ出ます。会員登録もログインも不要です。
使い分けの目安は、フラグを触るかどうかです。大文字小文字の無視、複数行、置換の確認まで必要なら、フラグと置換欄を持つ専用サービスの方が早く終わります。式を1つ書いて「何件、どこに当たるか」を数えるだけなら、入力2欄とボタン1つで終わる本ツールが最短です。
組み込む前にこの画面で見るのは2点です。マッチ数が想定と一致しているか。位置の並びに不自然な飛びが無いか(拾えていない箇所があると、位置の間隔が大きく空きます)。この2点を確認してから、組み込み先の言語で同じテスト文字列をもう一度通してください。