正規表現を生成AIで作るプロンプト｜言語の指定とテスト方法

正規表現を生成AIに頼むときは、「使う言語と処理系」「マッチさせたい例と除外したい例を5件ずつ」「全体一致か部分一致か」の3点を渡し、出てきた式は必ずテストで確かめます。 正規表現は言語によって同じ式でも結果が変わるため、頼み方と確かめ方をセットにしておくと、安心して使える式になります。

この記事では、4本のプロンプトテンプレートと、例の表をそのまま流し込める検証コードを載せています。同じ式を Python と JavaScript で実行すると結果が分かれる例も、実行結果つきで示します。記号の一覧ではなく、AI への頼み方と検証に絞った内容です。

確認環境：Python 3.11.15（re、pytest 9.1.1）、Node.js 22.22.2、OpenJDK 21.0.10、Go 1.24.7。掲載したコードと出力は、この環境で実行したものです。確認日 2026-10-05。

この記事の結論

• 渡すのは3点です。言語と処理系（例：Python 3.11 の re）、マッチさせたい例と除外したい例を5件ずつ、全体一致か部分一致か。
• 同じ式でも言語で結果が変わります。 備品コードの式 ^[A-Z]{2}-\d{4}$ は、JavaScript では13件すべて期待どおり、Python では2件が期待と違う結果でした。
• 確かめ方は、例の表をテストに流し込むことです。Python は pytest の parametrize、JavaScript は配列を回すだけで足ります。
• 量指定子の入れ子は計測します。 ^(a+)+$ は26文字の入力で約3秒かかり、入れ子を外した式は一瞬で終わりました。

正規表現を AI に頼むときの早見表

プロンプトテンプレート4本

題材は架空の「備品コード」（英大文字2字、ハイフン、数字4桁）です。角かっこの部分を置き換えて使います。

1. 作成用

正規表現を1つ作ってください。

# 使う場所
- 言語と処理系：[Python 3.11 の re モジュール]
- 呼び出し方：[re.fullmatch]
- 一致の範囲：[文字列全体が一致すること／文の中から抜き出すこと]

# 条件
[英大文字2字、半角ハイフン、半角数字4桁。数字は 0〜9 だけで、全角は認めない]

# マッチさせたい例
[EQ-0001]
[PC-2026]
[AB-9999]
[ZZ-0000]
[MN-1234]

# 除外したい例
[eq-0001（小文字）]
[EQ-001（桁が足りない）]
[XEQ-0001（前に余分な文字）]
[EQ-１２３４（全角の数字）]
[EQ-0001 の後ろに改行]

# 決まり
- 入力は最大 [200] 文字。量指定子を入れ子にしない（例：グループの中と外の両方に + や * を付けない）。
- 指定した処理系で使えない機能は使わない。
- 例だけでは決められない点があれば、式を出す前に質問する。

# 出力形式
1. 正規表現（コードブロック1つ）
2. 部分ごとの説明（表）
3. 上の例それぞれについて、一致する／しないの見込み

2. 解説用

次の正規表現が何に一致するかを説明してください。

# 正規表現
[式をそのまま貼る]

# 使う場所
- 言語と処理系：[JavaScript（Node.js 22）]
- フラグ：[なし／i／m／u など]

# 出力形式
1. ひとことで言うと何に一致する式か
2. 左から順に、部分ごとの意味（表：部分、意味、例）
3. 一致する文字列の例を3つ、一致しない文字列の例を3つ
4. 指定した処理系で意味が変わる箇所、他の言語に移すときに書き換えが必要な箇所
5. 量指定子が入れ子になっている箇所の有無

3. 修正用

次の正規表現が、テストの一部で期待と違う結果になります。直してください。

# 現在の式と使い方
- 式：[^[A-Z]{2}-\d{4}$]
- 言語と処理系：[Python 3.11 の re モジュール]
- 呼び出し方：[PATTERN.match(text)]

# 期待と違った例（文字列、期待、実際の結果）
[EQ-１２３４、一致しない、一致した]
[EQ-0001 の後ろに改行、一致しない、一致した]

# 期待どおりだった例（直した後も変えないこと）
[EQ-0001 など、通っている例を貼る]

# 出力形式
1. 原因（どの部分が、なぜその結果になるか）
2. 直した式と、呼び出し方の変更があればその内容
3. 直す前と後の違い（表）

4. テストケース生成用

次の条件の正規表現を確かめるためのテストケースを作ってください。式は書かないでください。

# 条件
[英大文字2字、半角ハイフン、半角数字4桁。文字列全体が一致すること]

# 作ってほしい例
- マッチさせたい例：5件以上
- 除外したい例：10件以上。次の観点を必ず含める。
  - 桁や長さが1つ足りない、1つ多い
  - 大文字と小文字、全角と半角の違い
  - 前後に余分な文字、空白、改行が付いたもの
  - 空文字
  - 区切りの記号が違うもの

# 出力形式
タブ区切りで「文字列、期待する結果（True か False）、観点」の3列。見出し行を付ける。

式より先にテストケースを作ってもらい、内容を自分で見直してから式を頼むと、条件の抜けに早く気づけます。

例の表をそのまま流し込める検証コード

例の表（タブ区切り）

文字列 期待する結果  観点
EQ-0001 True    基本の形
PC-2026 True    別の英字
AB-9999 True    数字の最大
ZZ-0000 True    数字の最小
MN-1234 True    基本の形
eq-0001 False   小文字
EQ-001  False   桁が足りない
EQ-00012    False   桁が多い
XEQ-0001    False   前に余分な文字
EQ_0001 False   区切りが違う
EQ-１２３４ False   全角の数字
EQ-0001（末尾に改行）  False   末尾の改行
（空文字）   False   空文字

Python：re と pytest の parametrize

# test_regex.py  （pip install pytest → pytest -q test_regex.py）
import re
import pytest

# AI が出した式をここに貼る。備品コード：英大文字2字、ハイフン、数字4桁
PATTERN = re.compile(r"^[A-Z]{2}-\d{4}$")

def is_valid(text: str) -> bool:
    return PATTERN.match(text) is not None

# マッチさせたい例と除外したい例の表（文字列, 期待する結果）
CASES = [
    ("EQ-0001", True),
    ("PC-2026", True),
    ("AB-9999", True),
    ("ZZ-0000", True),
    ("MN-1234", True),
    ("eq-0001", False),        # 小文字
    ("EQ-001", False),         # 桁が足りない
    ("EQ-00012", False),       # 桁が多い
    ("XEQ-0001", False),       # 前に余分な文字
    ("EQ_0001", False),        # 区切りが違う
    ("EQ-１２３４", False),     # 全角の数字
    ("EQ-0001\n", False),      # 末尾に改行
    ("", False),               # 空文字
]

IDS = [f"{i:02d}" for i in range(1, len(CASES) + 1)]   # 表の何行目かを名前にする

@pytest.mark.parametrize("text, expected", CASES, ids=IDS)
def test_pattern(text, expected):
    assert is_valid(text) is expected

実行結果です。

$ pytest -q test_regex.py
..........FF.                                                            [100%]
=================================== FAILURES ===================================
_______________________________ test_pattern[11] _______________________________

text = 'EQ-１２３４', expected = False

    @pytest.mark.parametrize("text, expected", CASES, ids=IDS)
    def test_pattern(text, expected):
>       assert is_valid(text) is expected
E       AssertionError: assert True is False
E        +  where True = is_valid('EQ-１２３４')

test_regex.py:32: AssertionError
_______________________________ test_pattern[12] _______________________________

text = 'EQ-0001\n', expected = False

    @pytest.mark.parametrize("text, expected", CASES, ids=IDS)
    def test_pattern(text, expected):
>       assert is_valid(text) is expected
E       AssertionError: assert True is False
E        +  where True = is_valid('EQ-0001\n')

test_regex.py:32: AssertionError
=========================== short test summary info ============================
FAILED test_regex.py::test_pattern[11] - AssertionError: assert True is False
FAILED test_regex.py::test_pattern[12] - AssertionError: assert True is False
2 failed, 11 passed in 0.02s

13件のうち2件が期待と違いました。 原因は2つです。

直した式と呼び出し方です。変えたのは2行だけです。

PATTERN = re.compile(r"[A-Z]{2}-[0-9]{4}")

def is_valid(text: str) -> bool:
    return PATTERN.fullmatch(text) is not None

$ pytest -q test_regex_fixed.py
.............                                                            [100%]
13 passed in 0.01s

JavaScript：配列を回して確かめる

// check_regex.js  （node check_regex.js）
// AI が出した式をここに貼る。備品コード：英大文字2字、ハイフン、数字4桁
const PATTERN = /^[A-Z]{2}-\d{4}$/;

// マッチさせたい例と除外したい例の表 [文字列, 期待する結果]
const CASES = [
  ["EQ-0001", true],
  ["PC-2026", true],
  ["AB-9999", true],
  ["ZZ-0000", true],
  ["MN-1234", true],
  ["eq-0001", false],
  ["EQ-001", false],
  ["EQ-00012", false],
  ["XEQ-0001", false],
  ["EQ_0001", false],
  ["EQ-１２３４", false],
  ["EQ-0001\n", false],
  ["", false],
];

let ng = 0;
for (const [text, expected] of CASES) {
  const actual = PATTERN.test(text);
  const mark = actual === expected ? "OK" : "NG";
  if (mark === "NG") ng++;
  console.log(`${mark}\t${JSON.stringify(text)}\t期待=${expected}\t結果=${actual}`);
}
console.log(`${CASES.length - ng}/${CASES.length} 件が期待どおり`);
process.exitCode = ng === 0 ? 0 : 1;

$ node check_regex.js
OK  "EQ-0001"   期待=true 結果=true
OK  "PC-2026"   期待=true 結果=true
OK  "AB-9999"   期待=true 結果=true
OK  "ZZ-0000"   期待=true 結果=true
OK  "MN-1234"   期待=true 結果=true
OK  "eq-0001"   期待=false    結果=false
OK  "EQ-001"    期待=false    結果=false
OK  "EQ-00012"  期待=false    結果=false
OK  "XEQ-0001"  期待=false    結果=false
OK  "EQ_0001"   期待=false    結果=false
OK  "EQ-１２３４"   期待=false    結果=false
OK  "EQ-0001\n" 期待=false    結果=false
OK  ""  期待=false    結果=false
13/13 件が期待どおり

同じ式 ^[A-Z]{2}-\d{4}$ が、JavaScript では13件すべて期待どおりでした。 JavaScript の \d は半角の 0〜9 だけに一致し、m フラグのない $ は末尾の改行の前には一致しないためです。式を別の言語に持っていくときは、同じ表でもう一度テストします。最後の行で終了コードを 0 か 1 にしているので、自動のチェックにも組み込めます。

match・search・fullmatch の違い

処理が終わらなくなる式の見分け方と計測コード

量指定子（+ や *）を付けたグループの中に、さらに量指定子がある式は、一致しない入力に対して組み合わせを何通りも試すことになり、入力が少し長くなるだけで時間が大きく伸びます。OWASP の解説ページは、こうした式の特徴を「繰り返しの付いたグループ」の中に「繰り返し」または「重なりのある選択」があること、と説明しています。

計測コード（Python）

# redos.py  入力を1文字ずつ長くして、かかる時間の伸び方を見る
import re
import time

PATTERNS = {
    "入れ子の量指定子": r"^(a+)+$",
    "入れ子を外した式": r"^a+$",
}

for label, pattern in PATTERNS.items():
    regex = re.compile(pattern)
    print(label, pattern)
    for n in range(18, 27, 2):
        text = "a" * n + "!"            # 最後の1文字で一致しなくなる入力
        start = time.perf_counter()
        regex.match(text)
        elapsed = time.perf_counter() - start
        print(f"  {n}文字\t{elapsed:.4f}秒")

入れ子の量指定子 ^(a+)+$
  18文字  0.0122秒
  20文字  0.0477秒
  22文字  0.1881秒
  24文字  0.8197秒
  26文字  3.1657秒
入れ子を外した式 ^a+$
  18文字  0.0000秒
  20文字  0.0000秒
  22文字  0.0000秒
  24文字  0.0000秒
  26文字  0.0000秒

入力が2文字増えるたびに、かかる時間が約4倍になっています。 計測で見るのは時間の絶対値ではなく、この伸び方です。同じ計測を Node.js 22.22.2 で行うと、26文字で 0.4547 秒、入れ子を外した式は 0.0000 秒でした。

もう少し身近な形の式でも同じことが起きます。単語の並びを表す ^(\w+\s?)+$ は、Python で20文字 0.0908 秒、24文字 1.4608 秒、28文字 23.1939 秒でした。^\w+(\s\w+)*\s?$ に書き直すと、3つとも 0.0000 秒で、通常の入力（reserve the projector）にはどちらの式も一致しました。

後戻りをしない処理系（RE2 系）での結果

Go の regexp パッケージは RE2 と同じ文法を受け付け、入力の長さに比例する時間で動くことがパッケージの説明に書かれています。同じ式を Go 1.24.7 で計測した結果です。

package main

import (
    "fmt"
    "regexp"
    "strings"
    "time"
)

func main() {
    re := regexp.MustCompile(`^(a+)+$`)
    for _, n := range []int{18, 26, 1000, 100000} {
        text := strings.Repeat("a", n) + "!"
        start := time.Now()
        re.MatchString(text)
        fmt.Printf("%d文字\t%.4f秒\n", n, time.Since(start).Seconds())
    }
}

18文字    0.0000秒
26文字    0.0000秒
1000文字  0.0001秒
100000文字    0.0061秒

10万文字でも 0.0061 秒でした。その代わり、RE2 系では後方参照や先読み・後読みが使えません（次の章の表）。

計測を AI に頼むときの一文

作成用プロンプトの「決まり」に次の一文を足すと、式と一緒に確認用の入力も出してもらえます。

この式で最も時間がかかりそうな入力（一致しそうで最後に一致しなくなる文字列）を1つ挙げ、長さを変えて計測するコードも付けてください。

処理系ごとの差の対応表

同じ内容の式を4つの処理系で実行した結果です。「エラー」は式の読み込み時にエラーになったことを表します。

実際に表示されたエラー文です。AI に修正を頼むときは、この文をそのまま貼ります。

処理系 式   エラー文
Python  (?<=No\.\s*)\d+ look-behind requires fixed-width pattern
Python  (?<y>\d{4})-(?<m>\d{2}) unknown extension ?<y at position 1
Python  \p{Han}+    bad escape \p at position 0
JavaScript  (?P<y>\d{4})-(?P<m>\d{2})   Invalid regular expression: /(?P<y>\d{4})-(?P<m>\d{2})/: Invalid group
JavaScript  a++b    Invalid regular expression: /a++b/: Nothing to repeat
Java    (?P<y>\d{4})-(?P<m>\d{2})   Unknown inline modifier
Go  \d+(?=円)    error parsing regexp: invalid or unsupported Perl syntax: `(?=`
Go  (?<=No\.)\d+    error parsing regexp: invalid named capture: `(?<=No\.)\d+`
Go  (\w)\1  error parsing regexp: invalid escape sequence: `\1`
Go  a++b    error parsing regexp: invalid nested repetition operator: `++`

RE2 の文法の一覧（公式 Wiki）でも、後方参照、先読み、後読み、強欲な量指定子、アトミックグループは NOT SUPPORTED と書かれています。RE2 系の処理系を使うときは、プロンプトに「RE2 で使える機能だけで書く。先読み・後読み・後方参照は使わない」と書き添えます。

正規表現で書くか、文字列関数や解析器に任せるかの判断基準

「形は正規表現、意味は専用の関数」の例です。

# parser.py  形は正規表現、意味は専用の関数で確かめる
import re
from datetime import date

DATE_SHAPE = re.compile(r"[0-9]{4}-[0-9]{2}-[0-9]{2}")

for text in ["2026-10-05", "2026-02-30", "2026-13-01", "2026/10/05"]:
    shape_ok = DATE_SHAPE.fullmatch(text) is not None
    try:
        date.fromisoformat(text)
        real_ok = True
    except ValueError:
        real_ok = False
    print(f"{text}\t正規表現={shape_ok}\tdate.fromisoformat={real_ok}")

2026-10-05  正規表現=True   date.fromisoformat=True
2026-02-30  正規表現=True   date.fromisoformat=False
2026-13-01  正規表現=True   date.fromisoformat=False
2026/10/05  正規表現=False  date.fromisoformat=False

2月30日や13月は、形としては合っていても日付としては存在しません。こうした確認まで正規表現に持たせると式が長くなるので、日付の関数に任せます。

CSV も同じです。引用符の中にカンマがある行を split で分けると列がずれ、csv モジュールでは正しく3列になりました。

import csv, io
line = 'EQ-0001,"プロジェクター, 小型",第2会議室'
print(line.split(","))
print(next(csv.reader(io.StringIO(line))))

['EQ-0001', '"プロジェクター', ' 小型"', '第2会議室']
['EQ-0001', 'プロジェクター, 小型', '第2会議室']

AI に頼む前に、次の一文で方法そのものを相談するのも有効です。

次の処理をしたいです。正規表現、文字列関数、専用の解析器のどれが合うかを1つ選び、理由を2文で答えてください。コードはまだ書かないでください。

[やりたい処理と、入力の例を3つ]

確かめて分かったこと

• 同じ式と同じ13件の表で、JavaScript は全件が期待どおり、Python は2件が期待と違いました。 言語を伝えずに頼むと、この差がそのまま残ります。
• Python の \d と \w は、全角の数字や日本語にも一致しました。 JavaScript、Java、Go では一致しませんでした。半角だけにしたいときは [0-9] と書くのが、どの処理系でも同じ結果になる書き方です。
• 名前付きグループの書き方は2通りあり、処理系によって受け付ける形が違いました。 P ありは Python と Go、P なしは JavaScript と Java と Go です。
• 長さが変わる後読みは、JavaScript と Java 21 では一致し、Python ではエラーでした。
• $ の扱いは2つに分かれました。 Python と Java は末尾の改行の前にも一致し、JavaScript と Go は一致しませんでした。全体一致は、Python なら fullmatch を使うと確実です。
• 入れ子の量指定子は、Python と Node.js の両方で入力が2文字増えるごとに約4倍の時間になりました。 Go では10万文字でも一瞬でした。

よくある質問

Q. ChatGPT や Claude で正規表現は作れますか？ A. 作れます。言語と処理系、マッチさせたい例と除外したい例、全体一致か部分一致かの3点を渡すと、条件に合った式になりやすくなります。出てきた式は、例の表をテストに流して確かめてから使います。

Q. AI が作った正規表現が動かないときは？ A. まず、使っている言語と処理系を伝えたかを確かめます。エラー文が出ている場合はその文を、結果が期待と違う場合は「文字列、期待、実際の結果」の3つを修正用プロンプトに貼ります。

Q. 正規表現のテストはどうやって行いますか？ A. マッチさせたい例と除外したい例を表にして、1件ずつ結果を比べます。Python なら pytest の parametrize、JavaScript なら配列を回すコードで、表をそのまま使えます。

Q. 全体一致と部分一致の違いは？ A. 全体一致は文字列の最初から最後までが式に合うこと、部分一致は文字列のどこかに式に合う部分があることです。入力チェックには全体一致、文章からの抜き出しには部分一致を使います。

Q. 正規表現の処理が遅いときは？ A. 量指定子が入れ子になっていないかを確かめます。一致しない入力を1文字ずつ長くして時間を測り、伸び方が急なら、外側か内側の量指定子を1つにする形へ書き直します。

まとめ

• 言語と処理系、例を5件ずつ、全体一致か部分一致かの3点を渡して頼みます。
• プロンプトは作成用・解説用・修正用・テストケース生成用の4本を使い分けます。
• 出てきた式は、例の表をテストに流して確かめます。 期待と違った行が、そのまま修正用プロンプトの材料になります。
• 同じ式でも処理系で結果が変わります。 \d、$、後読み、名前付きグループは特に差が出るところです。
• 量指定子の入れ子は、入力の長さを変えて計測します。 伸び方が急なら書き直します。
• 形は正規表現、値の正しさや入れ子の構造は専用の関数や解析器に任せます。

参考・出典

• Python 公式ドキュメント「re — Regular expression operations」 https://docs.python.org/3/library/re.html
• RE2 公式 Wiki「Syntax」 https://github.com/google/re2/wiki/Syntax
• OWASP「Regular expression Denial of Service - ReDoS」 https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
• Go 標準ライブラリ regexp パッケージの説明（go doc regexp、Go 1.24.7）

（いずれも 2026-10-05 に確認）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。