結論：正規表現は「自分でゼロから書く」より「やりたいマッチを言葉でClaude Codeに伝えて作らせ、人間がテストで検証する」運用に切り替えると、書く時間も読む時間も大きく縮む。ただしAIが生成した正規表現はそのまま信じてはいけません。誤マッチ・取りこぼし・ReDoS（後述）を必ずテストケースで確かめる前提で使うのが鉄則です。
① やりたいマッチを言葉で伝えて正規表現を作らせる：「半角英数とハイフンだけのスラッグにマッチ」のように仕様を自然言語で渡す。
② 既存の正規表現を読み解かせる：他人が書いた呪文のような \d{4}-\d{2}-\d{2} が何を意図しているかを説明させる。
③ テストケースで検証する：マッチすべき例・してはいけない例を並べ、誤マッチと取りこぼしを潰す。
対象読者：ログ整形・入力バリデーション・置換スクリプトなどで日常的に正規表現を書く／読むアプリ・バックエンドエンジニア、データ処理担当、SRE。今日できること：手元の1つの正規表現タスクで「言葉で仕様を伝える→生成→テストで検証→必要なら別手段も検討」を1周通す。
※本記事は2026年6月時点の Claude Code 公式ドキュメントに基づきます。バージョン・仕様は更新されるため、最終挙動は各自の環境で確認してください。AIが生成した正規表現は誤りやすく、もっともらしく見えて取りこぼす・余計にマッチすることがあります。必ず実データやテストケースで検証し、複雑になりすぎたら正規表現に固執せず別の手段（パーサ・分割処理）も検討してください。
「この入力チェック、正規表現でいけるよな……あれ、ハイフンを含めると壊れる？」とエスケープの沼にハマって30分溶かした経験、エンジニアなら一度はあるはずです。正直、正規表現は「読む」のも「書く」のもしんどい。\d なのか [0-9] なのか、. はエスケープが要るのか、貪欲マッチで余計に食っていないか──頭の中のスタックがすぐ溢れます。
Claude Code が効くのは、まさにこの「自然言語の意図」と「正規表現という記号列」の往復です。やりたいことを言葉で渡せば叩き台を出してくれるし、逆に既存の呪文を渡せば日本語で解説してくれる。ただしAIの正規表現は誤りやすいので、生成物を必ずテストで裏取りする運用にするのがコツです。この記事では、その具体的な手順を6つの観点＋落とし穴つきでまとめます。
なぜ正規表現づくりに Claude Code を使うのか
正規表現の作業は大きく「①意図を記号列に翻訳する」「②他人の記号列を意図に逆翻訳する」「③想定外のマッチを潰す」の3つに分かれます。このうち①と②は人間の脳内変換コストが高く、③は地道なテストの繰り返しです。Claude Code はこの「翻訳」と「テストケースの列挙」を一緒に回してくれます。
Claude Code はターミナルで動くエージェント型のツールで、プロジェクト内のファイルを読み、必要に応じてコマンドを実行できます。つまり「この正規表現を作って」だけでなく「このテストデータに対して実際に走らせて、マッチ結果を見せて」まで一気通貫で頼める点が、ブラウザのチャットだけで完結する使い方との違いです（公式の概要はClaude Code overviewを参照）。
注意点を先に言っておくと、AIが出す正規表現は「それっぽいけど微妙にズレている」ことが珍しくありません。だからこそ、生成して終わりにせず、必ずテストで検証する運用とセットにするのが本記事の一貫した立場です。
①やりたいマッチを言葉で伝えて正規表現を作らせる
最初のコツは、正規表現の構文を考える前に「何にマッチさせ、何にマッチさせないか」を日本語で書き切ることです。あいまいな指示は、あいまいな正規表現を生みます。
たとえば「日本の郵便番号にマッチさせたい」だけだと不十分です。ハイフンありなしの両方か、全角は許すか、前後に余計な文字があってもいいのか──ここを詰めるほど精度が上がります。Claude Code に渡す指示の例がこちらです。
あなたは正規表現の設計者です。次の仕様にマッチする正規表現を作ってください。
【マッチさせたいもの】
- 日本の郵便番号（例: 123-4567, 1234567）
【マッチさせたくないもの】
- 桁数が違うもの（例: 12-345, 12345678）
- 前後に文字がくっついたもの（例: a123-4567）
【条件】
- 言語/エンジンは JavaScript（ECMAScript）
- 全角数字は対象外（半角のみ）
- 文字列全体が郵便番号であること（部分一致ではなく完全一致）
不足している情報があれば、最初に質問してから作業を開始してください。
作った正規表現は、マッチ例・非マッチ例つきで検証結果も示してください。このように「させたいもの」「させたくないもの」「エンジン」「完全一致か部分一致か」を明示すると、出てくる正規表現の質が安定します。出力例としては次のような形になります（あくまで叩き台。必ず②③で検証します）。
// JavaScript（完全一致・ハイフンは任意）
const postalCode = /^\d{3}-?\d{4}$/;
postalCode.test("123-4567"); // true
postalCode.test("1234567"); // true
postalCode.test("12-345"); // false
postalCode.test("a123-4567");// falseポイントは、^ と $ で文字列全体を縛っていること、ハイフンを -? で「あってもなくてもよい」にしていることです。「完全一致にして」と指示しないと、Claude Code が部分一致の正規表現を出してきて、想定外の文字列まで通してしまうことがあります。
②既存の正規表現を読み解かせる・説明させる
正規表現の本当の地獄は、自分が半年前に書いた（あるいは前任者が残した）呪文を読むときです。(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*) のような塊を前にして固まる前に、Claude Code に解説させましょう。
指示はシンプルで構いません。
次の正規表現が「何にマッチするか」を、構成要素ごとに日本語で分解して説明してください。
想定しているマッチ例・非マッチ例も3つずつ挙げてください。
潜在的なバグ（取りこぼし・余計なマッチ・パフォーマンス上の懸念）があれば指摘してください。
正規表現: ^\d{4}-\d{2}-\d{2}$たとえば ^\d{4}-\d{2}-\d{2}$ なら、Claude Code は「先頭から、数字4桁・ハイフン・数字2桁・ハイフン・数字2桁・末尾、という日付らしき形式（YYYY-MM-DD）に完全一致する」と分解してくれます。ここで重要なのが、AIが「潜在的なバグ」として「これは形式チェックであって、2026-13-40 のような存在しない日付も通してしまう」と指摘できる点です。
「形式は合っているが意味的に正しくない」という落とし穴は、正規表現だけでは塞げません。月や日の範囲チェックまで正規表現に詰め込むと可読性が崩壊するので、「形式は正規表現、妥当性はコード（日付パース）で」と役割分担する判断材料を、解説を通じて得られます。
③テストケースで検証する（誤マッチ・取りこぼし）
ここが本記事で最も強調したいステップです。AIが生成した正規表現は、必ずマッチすべき例（positive）とマッチしてはいけない例（negative）の両方でテストしてから採用してください。
手順はシンプルです。
- テストデータを列挙させる — 「この仕様の境界値・例外を含むテストケースを positive と negative に分けて出して」と頼む。人間が思いつかない境界（空文字、前後の空白、似て非なる形式）を拾ってくれます。
- 実際に走らせる — Claude Code にテストデータと正規表現を渡し、その場でスクリプトを実行させて、各ケースの期待値と実結果が一致するかを表で出させる。
- ズレを潰す — 取りこぼし（マッチすべきなのにしない）や誤マッチ（マッチすべきでないのにする）が出たら、その失敗ケースを正規表現に反映して再生成。
たとえば Python なら、こういう検証スクリプトを書かせて回します。
import re
pattern = re.compile(r"^\d{3}-?\d{4}$")
cases = [
("123-4567", True),
("1234567", True),
(" 123-4567", False), # 先頭に空白
("123-4567 ", False), # 末尾に空白
("12-34567", False), # 桁の区切りが違う
("１２３-４５６７", False), # 全角
]
for text, expected in cases:
got = bool(pattern.fullmatch(text))
status = "OK" if got == expected else "NG"
print(f"{status}: {text!r} expected={expected} got={got}")「NG」が出た行が、まさに修正すべきポイントです。AIに「このNGケースを通らないように直して」と渡せば、原因を踏まえた修正版を返してくれます。この「失敗ケース駆動」の往復が、正規表現の品質を一番効率よく上げる方法です。テスト全体の自動生成についてはClaude Codeでデバッグ・障害調査を効率化する実践ガイドの考え方も併せて使えます。
④よくあるパターンの作り方（メール・日付・URL）
実務で頻出するパターンは、いきなり「完璧な正規表現」を狙わず、「どこまで厳密にやるか」を先に決めるのがコツです。Claude Code には、その厳密度をセットで伝えます。
メールアドレス：RFC 5322 完全準拠の正規表現は数百文字の怪物になり、可読性も保守性も最悪です。実務では「@ を1つ含み、前後に文字がある」程度の緩いチェックにして、本当の確認は確認メール送信で行うのが定石です。
// 実務向けの「ゆるい」メール形式チェック（完全準拠は狙わない）
const mail = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
mail.test("[email protected]"); // true
mail.test("user@example"); // false（TLDなし）
mail.test("a@[email protected]"); // false日付（YYYY-MM-DD）：前述のとおり形式は正規表現、妥当性はコードで。形式チェックはこれで十分です。
const ymd = /^\d{4}-\d{2}-\d{2}$/;
// 妥当性（実在する日付か）は Date でパースして確認するURL：こちらも完全な正規表現は地獄なので、まずスキームとホストの存在を緩くチェックします。
// http/https で始まるURLの簡易チェック
const url = /^https?:\/\/[^\s/$.?#].[^\s]*$/i;
url.test("https://uravation.com/media/"); // true
url.test("ftp://example.com"); // false
url.test("not a url"); // falseここで Claude Code に頼むときのコツは、「完璧を目指さず、誤判定が出たときのリスクが小さい方に倒して」と伝えることです。バリデーションは厳しすぎると正当な入力を弾き、緩すぎると無効な入力を通します。どちらのリスクが業務上痛いかを言葉で渡すと、適切な厳密度の正規表現を提案してくれます。エスケープ記号の扱いを含むコード規約の固定はClaude Codeでコメント・docstringを整備する実践ガイドの進め方も参考になります。
⑤落とし穴：検証なしの採用・複雑化・ReDoS
正規表現でClaude Codeを使うとき、踏みやすい地雷が3つあります。
❌ AIが出した正規表現をテストせずにそのまま本番投入する
⭕ positive/negative の両テストを通してから採用する
→ AIの正規表現は「もっともらしいけど境界でズレる」ことが多い
❌ 1本の巨大な正規表現に全部の条件を詰め込む
⭕ 形式チェックは正規表現、意味的な妥当性はコードに分ける
→ 読めない・直せない正規表現は将来の事故の元
❌ ユーザー入力に対して危険な正規表現を無防備に使う
⭕ ReDoS（後述）の懸念を必ずレビューするReDoS（Regular expression Denial of Service）は特に重要です。(a+)+$ のように「繰り返しの中に繰り返し」がある正規表現は、特定の入力に対してマッチ判定が指数関数的に遅くなり、サーバーを固められてしまう脆弱性です。ユーザーから受け取る文字列に正規表現をかける場合、Claude Code に「この正規表現に ReDoS のリスクはあるか、あるなら安全な書き換えを提案して」と必ずレビューさせてください。
// ❌ ネストした繰り返しで catastrophic backtracking を起こしやすい
const danger = /^(\w+\s?)*$/;
// ⭕ 量指定子のネストを避け、必要なら入力長制限や別手段と併用する「正規表現が複雑になりすぎたら、それは正規表現の仕事ではないサイン」というのも覚えておく価値があります。HTMLのパースやネストした構造の解析は、正規表現ではなく専用パーサに任せるべきです。Claude Code に「これは正規表現でやるべきか、別の手段が適切か」を聞くと、率直に「ここは分割処理にした方がいい」と返してくれることもあります。
⑥チームの正規表現運用を CLAUDE.md に固定する
個人の使い方が固まったら、チームの標準にしておくと再現性が上がります。プロジェクトルートの CLAUDE.md に、正規表現に関する方針を書いておくと、Claude Code がそれを踏まえて提案してくれます。
# 正規表現の方針（CLAUDE.md 抜粋）
- 正規表現を新規作成・変更したら、positive/negative のテストを必ず追加する
- メール・URL は RFC 完全準拠を狙わず、緩い形式チェック＋実地確認で運用する
- 日付・数値の「妥当性」は正規表現でなくコード（パース）で確認する
- ユーザー入力にかける正規表現は ReDoS レビューを必須にする
- 量指定子のネスト（例: (a+)+）は原則禁止こうしておくと、新しいメンバーが正規表現を追加するときも、Claude Code が「テストも一緒に書きますか」「ここは ReDoS のリスクがあります」と方針に沿って動いてくれます。設定や運用の標準化全般はClaude Code 実践テクニック完全ガイドも参照してください。CLAUDE.md やワークフローの基本は公式のCommon workflowsにまとまっています。
よくある失敗パターンと対策
❌「いい感じの正規表現作って」と丸投げする
⭕ マッチさせたいもの・させたくないもの・エンジン・完全一致か部分一致かを明示する。あいまいな指示はあいまいな正規表現を生み、テストで気づくまで本番に潜みます。
❌ AIの正規表現を「動いたっぽい」で採用する
⭕ 必ず negative ケース（マッチしてはいけない例）でも検証する。positive だけ通して安心すると、余計な文字列まで通すバグを見逃します。
❌ 全角・空白・前後の余計な文字を考慮し忘れる
⭕ 境界値テスト（空文字、前後の空白、全角、似た形式）を Claude Code に列挙させる。実データには必ず例外が混ざっています。
❌ ユーザー入力に無防備な正規表現を使う
⭕ ReDoS レビューを通す。量指定子のネストを避け、必要なら入力長を制限する。公開サービスでは正規表現1本がサービス停止の原因になり得ます。
まとめ：作るのはAI、信じるのはテスト
正規表現でClaude Codeが速くなるのは、「自然言語の意図」と「記号列」の翻訳を肩代わりしてくれるからです。やりたいことを言葉で渡して叩き台を作らせ、既存の呪文は解説させ、テストケースで誤マッチと取りこぼしを潰す。この往復を回すと、エスケープの沼で溶かしていた時間が現実的に短くなります。
ただし一線だけは守ってください。AIが生成した正規表現は、テストで裏が取れるまで信じない。作るのはAIに任せ、信じる根拠はテストで取る。複雑になりすぎたら正規表現に固執せず別の手段も検討する。これさえ徹底すれば、正規表現は怖い呪文ではなく、安心して使える道具になります。今日、手元の1つの正規表現で「言葉で仕様を伝える→生成→positive/negativeテスト→必要なら別手段」を1周だけ通してみてください。次から、正規表現との付き合い方が変わります。
Claude Codeをチームで使いこなしたい方へ
正規表現に限らず、Claude Code を「個人の便利ツール」から「チームの標準ワークフロー」に引き上げるには、CLAUDE.md の設計やテスト運用の型づくりが鍵になります。今日からできる3アクションはこちらです。
- 手元の1つの正規表現で1周試す — 言葉で仕様を伝える→生成→positive/negativeテスト→必要なら別手段、を体験する。
- CLAUDE.md に正規表現の方針を1行書く — 「正規表現を変えたらテストを追加」だけでも、チームの事故が減ります。
- ReDoS レビューを習慣化する — ユーザー入力にかける正規表現は、安全性を必ずClaude Codeに確認させる。
Uravation では、Claude Code の現場導入を個別指導・チーム研修の形で支援しています。「自社のコードベースでどう使い始めればいいか」を具体的に相談したい方は、お問い合わせからお気軽にどうぞ。次回は「シェルスクリプト・コマンド自動化をClaude Codeで」を予定しています。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載を7回執筆。Claude Code を使った開発・自動化の現場知見を発信している。
