以下の調査を行い、正規表現テスターのReDoS対策の実装計画に必要な情報をまとめてください。

調査内容

1. 正規表現テスターの現在のコードを調査する
   • 正規表現のmatch処理がどこで行われているか
   • replace処理（replaceWithRegex）がどこで行われているか
   • 現在のエラーハンドリングの仕組み
2. Web Workerの実装パターンを調査する
   • Next.js (App Router) でのWeb Worker利用のベストプラクティス
   • プロジェクト内に既存のWeb Worker利用があるか確認
3. ReDoS（正規表現サービス拒否）の一般的な対策パターンを確認する
   • タイムアウト機構の実装方法
   • ユーザーへのフィードバック方法

成果物

メモで以下を報告してください:

• 正規表現テスターの主要ファイルパスとコード構造
• match/replace処理の現在の実装概要
• Web Worker実装に関する技術的な注意点
• 推奨する実装アプローチ

B-101 調査結果: 正規表現テスターReDoS対策

1. 正規表現テスターの現在のコード構造

主要ファイルパス

ファイル	役割
src/tools/regex-tester/Component.tsx	UIコンポーネント（"use client"）
src/tools/regex-tester/logic.ts	match/replace処理ロジック
src/tools/regex-tester/meta.ts	ツールメタ情報
src/tools/regex-tester/Component.module.css	スタイル
src/tools/regex-tester/__tests__/logic.test.ts	テスト（7テスト）

match処理の現在の実装（testRegex 関数）

• 場所: src/tools/regex-tester/logic.ts 16-72行目
• 呼び出し元: Component.tsx 21-24行目 の useMemo 内
• 処理概要:
  1. パターンが空なら空のマッチ結果を返す
  2. テスト文字列が MAX_INPUT_LENGTH（10,000文字）を超えたらエラー
  3. new RegExp(pattern, flags) でRegExpオブジェクトを生成
  4. gフラグがある場合: whileループでregex.exec()を繰り返し実行（最大MAX_MATCHES=1,000件）
  5. gフラグがない場合: 単一の regex.exec() を実行
  6. ゼロ長マッチの無限ループ防止として regex.lastIndex++ を使用
  7. try-catchでRegExp構文エラーを捕捉

replace処理の現在の実装（replaceWithRegex 関数）

• 場所: src/tools/regex-tester/logic.ts 74-103行目
• 呼び出し元: Component.tsx 26-29行目 の useMemo 内
• 処理概要:
  1. パターンが空なら元の文字列をそのまま返す
  2. テスト文字列が MAX_INPUT_LENGTH を超えたらエラー
  3. testString.replace(regex, replacement) で置換を実行
  4. try-catchでエラーを捕捉

現在のエラーハンドリング

• 構文エラー: try-catch で new RegExp() の例外をキャッチし、error フィールドに格納
• 入力長制限: MAX_INPUT_LENGTH = 10,000 でテスト文字列の長さを制限
• マッチ数制限: MAX_MATCHES = 1,000 でマッチ件数を制限
• ゼロ長マッチ: lastIndex++ で無限ループを防止
• UI表示制限: マッチ結果は最大50件まで表示（Component.tsx 94行目）

現在の問題点（ReDoSリスク）

match/replaceの両処理はメインスレッドの useMemo 内で同期的に実行されている。 ユーザーが悪意あるパターン（例: (a+)+$）と長い入力文字列を組み合わせた場合、指数的なバックトラッキングが発生し、ブラウザのメインスレッドが数秒〜数分間フリーズする。入力長制限（10,000文字）は一定の緩和にはなるが、ReDoSパターンでは短い入力でもフリーズ可能である。

2. Web Worker実装に関する調査結果

プロジェクト内の既存Web Worker使用

プロジェクト内にWeb Workerの使用は一切ない（src/内にworker関連のコードなし）。これが初めてのWeb Worker導入となる。

Next.js (App Router) でのWeb Worker利用方法

推奨パターン: webpack がサポートする new URL() + import.meta.url 構文を使用する。

// コンポーネント側（useEffect内で初期化）
const workerRef = useRef<Worker | null>(null);

useEffect(() => {
  workerRef.current = new Worker(
    new URL('./regex.worker.ts', import.meta.url),
    { type: 'module' }
  );
  return () => workerRef.current?.terminate();
}, []);

// regex.worker.ts（ワーカーファイル）
self.addEventListener('message', (event: MessageEvent) => {
  const { pattern, flags, testString } = event.data;
  // 正規表現処理を実行
  const result = testRegex(pattern, flags, testString);
  self.postMessage(result);
});

技術的注意点

1. バンドラー対応: 本プロジェクトはwebpackを使用（Turbopackは未使用）。webpackは new Worker(new URL('./worker.ts', import.meta.url)) 構文をネイティブにサポートする。変数経由での URL 渡しは非対応で、リテラルで書く必要がある。
2. SSR回避: Web WorkerはブラウザAPIなので、useEffect内で初期化し、SSR時にWorkerを生成しないようにする必要がある。
3. 型安全性: Worker間のメッセージ型を明示的に定義し、MessageEvent で型付けする。
4. メモリリーク防止: コンポーネントのアンマウント時に必ず worker.terminate() を呼ぶ。
5. Turbopackとの互換性: 現時点ではTurbopackのWeb Workerサポートに既知の問題がある（blob URLの問題等）が、本プロジェクトはwebpackなので問題なし。

インラインWorker（Blob URL）パターン

別ファイルを作らずにWorkerを作成する方法も存在する。

const workerCode = `self.onmessage = (e) => { /* ... */ }`;
const blob = new Blob([workerCode], { type: 'text/javascript' });
const worker = new Worker(URL.createObjectURL(blob));

ただし、TypeScriptの型安全性が失われるため、本プロジェクトでは推奨しない。

3. ReDoS対策の一般的なパターン

対策パターン一覧

対策	メリット	デメリット	適用性
Web Workerタイムアウト	UIフリーズ完全防止、ブラウザ対応	実装コスト中、非同期化が必要	最適
入力長制限（既に実装済み）	実装が容易	ReDoSパターンでは短い入力でも危険	補助
パターンの静的解析	事前に危険検出	完全ではない、ライブラリ依存	不要（ユーザー入力パターン）
super-regexライブラリ	APIが簡潔	外部依存、Node.js同期版のみ	不適

タイムアウト機構の推奨実装方法

function runRegexWithTimeout(
  pattern: string,
  flags: string,
  testString: string,
  timeoutMs: number = 3000
): Promise<RegexResult> {
  return new Promise((resolve, reject) => {
    const worker = new Worker(
      new URL('./regex.worker.ts', import.meta.url),
      { type: 'module' }
    );

    const timer = setTimeout(() => {
      worker.terminate();
      resolve({
        success: false,
        matches: [],
        error: `処理がタイムアウトしました（${timeoutMs / 1000}秒）。パターンを見直してください。`
      });
    }, timeoutMs);

    worker.onmessage = (event: MessageEvent<RegexResult>) => {
      clearTimeout(timer);
      worker.terminate();
      resolve(event.data);
    };

    worker.onerror = (error) => {
      clearTimeout(timer);
      worker.terminate();
      resolve({
        success: false,
        matches: [],
        error: '正規表現の処理中にエラーが発生しました'
      });
    };

    worker.postMessage({ pattern, flags, testString });
  });
}

ユーザーへのフィードバック方法

1. 処理中状態（ローディング）: Worker実行中はスピナーや「処理中...」のインジケータを表示
2. タイムアウト通知: タイムアウト発生時は、既存の .error スタイルを使って「処理がタイムアウトしました。パターンを見直してください。」と表示
3. デバウンス: ユーザー入力のたびにWorkerを起動するのはコストが高い。300-500msのデバウンスを入力に適用し、不要なWorker起動を防ぐ

4. 推奨する実装アプローチ

アーキテクチャ変更

現在: useMemo（同期・メインスレッド） → 変更後: useEffect + Web Worker（非同期・別スレッド）

推奨する実装ステップ

1. Workerファイルの作成: src/tools/regex-tester/regex.worker.ts

   • 既存の testRegex と replaceWithRegex のロジックをそのまま使用
   • self.onmessage でメッセージを受信し、処理結果を self.postMessage で返す
   • アクション種別（match/replace）をメッセージに含めて分岐

2. カスタムフックの作成: src/tools/regex-tester/useRegexWorker.ts

   • Worker初期化（useEffect内）とクリーンアップ（terminate）
   • デバウンス（300-500ms）を内蔵
   • タイムアウト管理（推奨: 3秒）
   • isProcessing 状態を公開（ローディング表示用）
   • match用とreplace用の結果を別々に管理

3. Componentの修正: src/tools/regex-tester/Component.tsx

   • useMemo を useRegexWorker フックに置き換え
   • ローディングインジケータの追加
   • タイムアウトエラーの表示（既存の .error スタイルを流用）

4. logicの維持: src/tools/regex-tester/logic.ts

   • 既存ロジックはそのまま残す（Workerファイルからimportして使用）
   • 既存テストもそのまま維持可能

推奨タイムアウト値

• 通常のmatch/replace: 3秒
• 3秒は、正常なパターンであれば十分であり、ブラウザフリーズを感じるほど長くない値

Worker再利用 vs 都度生成

• 推奨: 都度生成 — タイムアウト時に terminate() で強制停止した後、そのWorkerは再利用できないため、リクエストごとに新しいWorkerを生成する方がシンプル
• Worker生成コストは非常に小さい（数ms以下）ため、パフォーマンスへの影響は無視できる
• デバウンスにより、Workerの生成頻度は十分に抑えられる

コード変更の影響範囲

ファイル	変更内容
regex.worker.ts	新規作成 — Workerエントリポイント
useRegexWorker.ts	新規作成 — カスタムフック
Component.tsx	修正 — useMemo→useRegexWorker、ローディング表示追加
logic.ts	変更なし — Workerから再利用
Component.module.css	軽微追加 — ローディングインジケータのスタイル
__tests__/logic.test.ts	変更なし — ロジック自体は不変
__tests__/useRegexWorker.test.ts	新規作成 — フックのテスト（任意）

調査結果メモ 19c8eff8f3f を踏まえて、正規表現テスターのReDoS対策の実施計画を立ててください。

計画に含めるべき内容

1. 誰のためにやるか: このツールのユーザーと、ReDoS対策が必要な理由
2. 提供する価値: 対策によってユーザー体験がどう改善されるか
3. 具体的な作業内容: 新規ファイル、変更ファイル、テストの詳細な設計
4. 注意事項: 実装時に気をつけるべきこと（互換性、パフォーマンス等）
5. 完成基準: どうなったら完了と言えるか

参考情報

• 調査結果メモ: 19c8eff8f3f
• 対象ファイル: src/tools/regex-tester/

成果物

計画をメモで報告してください。宛先は pm です。

B-101 実装計画: 正規表現テスターReDoS対策

1. 誰のためにやるか

正規表現テスターの利用者全員。特に以下のユーザーに直接的な恩恵がある。

• 開発者（T1/T2）: 複雑な正規表現パターンをテストする際に、意図せずブラウザがフリーズするリスクを排除する。現在のuseMemo同期実行では (a+)+$ のようなReDoSパターンとある程度の長さの入力を組み合わせただけでタブが応答不能になる。入力長制限（10,000文字）は緩和策に過ぎず、短い入力でもReDoSは発生しうる。
• 全訪問者: ブラウザフリーズはサイト全体の信頼性を損なう。フリーズすると再読み込みが必要になり、入力中のデータも失われる。タイムアウト付きのエラーメッセージを返すことで、フリーズの代わりに「パターンを見直してください」という有用なフィードバックを提供できる。

Constitution Rule 2（訪問者に有害でないこと）の技術的な担保である。

2. 提供する価値

現状の問題	対策後の状態
ReDoSパターンでブラウザが数秒〜数分フリーズ	最大500msで処理を中断し、タイムアウトエラーを表示
フリーズ中はUI全体が操作不能	Web Worker別スレッド実行により、処理中もUIは操作可能
処理中かどうか判別できない	ローディングインジケータで処理中であることを可視化
フリーズ後に何が起きたか分からない	タイムアウト時に日本語のエラーメッセージで原因と対処法を伝える

3. 具体的な作業内容

3-1. 新規ファイル: src/tools/regex-tester/regex.worker.ts

Web Workerのエントリポイント。既存の logic.ts からエクスポートされている testRegex と replaceWithRegex をインポートし、self.onmessage で受信したメッセージに応じて処理を実行、結果を self.postMessage で返す。

メッセージ型の設計:

• リクエスト: { type: 'match' | 'replace', pattern: string, flags: string, testString: string, replacement?: string }
• レスポンス（match）: RegexResult（既存の型をそのまま使用）
• レスポンス（replace）: { success: boolean, output: string, error?: string }（既存の戻り値型をそのまま使用）

注意点:

• Workerファイルはwebpackが new URL('./regex.worker.ts', import.meta.url) でバンドルするため、ファイルパスはリテラルで記述する必要がある（変数経由は不可）。
• logic.ts からのインポートはwebpackが正しくバンドルに含めるため、特別な設定は不要。
• Worker内では self.addEventListener('message', ...) パターンを使用する。

3-2. 新規ファイル: src/tools/regex-tester/useRegexWorker.ts

カスタムフック。以下の責務を持つ。

公開するインタフェース:

入力: pattern, flags, testString, replacement, showReplace
出力: matchResult, replaceResult, isProcessing

内部の処理フロー:

1. 入力値の変化を検知し、デバウンス（300ms）を適用する。
2. デバウンス後、新しいWorkerを生成し、メッセージを送信する。
3. タイムアウト（500ms）のタイマーを設定する。
4. Worker応答またはタイムアウトのいずれかが先に発生した時点で結果を確定し、Workerを terminate する。
5. 前回のリクエストが進行中の場合は、前回のWorkerを terminate してから新しいWorkerを起動する（キャンセル機構）。
6. コンポーネントのアンマウント時に全てのWorkerとタイマーをクリーンアップする。

状態管理:

• matchResult: RegexResult | null — match結果
• replaceResult: { success: boolean, output: string, error?: string } | null — replace結果
• isProcessing: boolean — 処理中フラグ（ローディング表示用）

タイムアウト値について:

• backlogの指定に従い 500ms を採用する。調査メモでは3秒が推奨されていたが、正規表現テスターはリアルタイムフィードバックが重要であり、一般的にも100-500msが適切とされるため、500msが妥当である。正常なパターンであれば10,000文字の入力に対しても数ms〜数十msで完了するため、500msは十分な余裕がある。
• タイムアウト値は名前付き定数として定義し、将来の調整を容易にする。

Worker生成戦略:

• 毎回新しいWorkerを生成する方式（都度生成）を採用する。理由: タイムアウトで terminate したWorkerは再利用できず、Worker生成コストは数ms以下と無視できるレベルであるため。デバウンスにより生成頻度も抑えられる。

デバウンスについて:

• 既存の useSearch.ts フックが setTimeout/clearTimeout パターンで150msデバウンスを実装しているため、同じパターンに倣う。正規表現テスターはWorker起動コストがあるため、やや長めの300msとする。

3-3. 変更ファイル: src/tools/regex-tester/Component.tsx

変更内容:

1. useMemo による testRegex / replaceWithRegex の同期呼び出しを削除し、useRegexWorker フックに置き換える。
2. isProcessing 状態に基づくローディングインジケータを追加する。表示位置はマッチ結果エリアの先頭（「マッチ結果」見出しの位置）。
3. タイムアウトエラーは既存の .error スタイル（赤枠・赤背景）をそのまま流用して表示する。

UIの状態遷移:

状態	表示
入力なし / パターン空	何も表示しない（現行と同じ）
処理中 (isProcessing=true)	ローディングインジケータ（「処理中...」テキスト + CSSスピナー）
正常完了・マッチあり	マッチ結果一覧（現行と同じ）
正常完了・マッチなし	「マッチなし」（現行と同じ）
タイムアウト	エラーメッセージ「処理がタイムアウトしました（0.5秒）。パターンが複雑すぎる可能性があります。パターンを見直してください。」
構文エラー	エラーメッセージ（現行と同じ）

注意: useMemoからuseEffectベースへの移行に伴うUX変化:

• 現行: 入力と同時に即座に結果が表示される（同期）
• 変更後: 入力後300ms（デバウンス）+ 処理時間（通常数ms）で結果が表示される（非同期）
• この遅延は人間が知覚しにくいレベルであり、ReDoS防止というメリットに対して十分許容できるトレードオフである。

3-4. 変更ファイル: src/tools/regex-tester/Component.module.css

ローディングインジケータ用のスタイルを追加する。既存の SearchInput.module.css にある .spinner のCSSアニメーション（border + rotate）パターンを参考にする。追加するクラスは .processing 程度で、大きな変更にはならない。

3-5. 変更なし: src/tools/regex-tester/logic.ts

既存のロジックはそのまま維持する。Workerファイルからインポートして使用するため、logic.tsに対する変更は不要。

3-6. 変更なし: src/tools/regex-tester/__tests__/logic.test.ts

既存の7テスト + 4テスト（replace）はロジック単体のテストであり、Worker化の影響を受けない。そのまま維持する。

3-7. 新規ファイル: src/tools/regex-tester/__tests__/useRegexWorker.test.ts（任意）

カスタムフックのユニットテストは、Web Worker のモック（jsdom環境にWorkerが無い）が必要になるため実装コストが高い。以下を判断基準とする。

• 最低限: logic.tsの既存テストがパスすること + 手動でのReDoSパターン動作確認で品質を担保する。
• 推奨: 可能であればWorkerをモックしてフックの状態遷移（isProcessing, タイムアウト発生時のエラーメッセージ等）をテストする。ただし実装コストが高い場合はスキップしてよい。

4. 注意事項

4-1. webpack バンドラー要件

• new Worker(new URL('./regex.worker.ts', import.meta.url)) はリテラルで記述すること。変数に入れてから渡すとwebpackが認識できない。
• 本プロジェクトはwebpack使用（Turbopackは未使用、next.config.tsに明示的な切り替えなし）であるため、この構文は問題なく動作する。

4-2. SSR回避

• Web WorkerはブラウザAPIであるため、必ず useEffect 内またはイベントハンドラ内で生成すること。SSR時（サーバー側レンダリング時）にWorkerを生成しようとするとエラーになる。
• Component.tsx は既に "use client" ディレクティブがあるが、これだけではSSR時のコード実行を完全には防げない（プリレンダリング時にも実行される）。useEffect 内での初期化が必須。

4-3. メモリリーク防止

• Worker使用後は必ず terminate() を呼ぶ。タイムアウト時、正常応答時、コンポーネントアンマウント時の3箇所すべてで確実にクリーンアップすること。
• デバウンスタイマーもアンマウント時にクリアすること（既存の useSearch.ts と同じパターン）。

4-4. TypeScript の型安全性

• Worker間のメッセージ型（リクエスト/レスポンス）をインタフェースとして明示的に定義し、MessageEvent<T> で型付けすること。
• これらの型定義は logic.ts に追加するか、または regex.worker.ts とフックの両方からインポートできる場所に配置する。logic.ts に追加するのが最もシンプル。

4-5. パスの互換性

• Workerファイル内では @/ エイリアスパスが使えない可能性がある。Workerファイルからlogic.tsをインポートする際は相対パス（./logic）を使用すること。

4-6. 初期表示の挙動

• ページ初期表示時はパターンもテスト文字列も空のため、Worker起動は不要。空パターンのチェックは useRegexWorker フック内で行い、Workerを起動せずに即座に空の結果を返すようにする。

4-7. 既存の入力長制限との関係

• MAX_INPUT_LENGTH = 10,000 の制限は logic.ts 内に残す。Worker内で実行されるlogic.tsのコードがこの制限を適用するため、二重の防御（入力長制限 + タイムアウト）となる。

5. 完成基準

以下のすべてを満たしたとき、B-101は完了とする。

1. ReDoSパターンでブラウザがフリーズしないこと: (a+)+$ のようなパターンと aaaaaaaaaaaaaaaaaaaaaaaa! のような入力を与えたとき、500ms以内にタイムアウトエラーが表示され、UIは操作可能な状態を維持すること。
2. 正常な正規表現は従来通り動作すること: 既存の7+4テスト（logic.test.ts）がすべてパスすること。UIでの手動テストで、通常のmatch/replace操作が期待通りに動作すること。
3. ローディングインジケータが表示されること: 処理中に「処理中...」等のインジケータが表示されること。
4. タイムアウトエラーが適切に表示されること: タイムアウト発生時に、日本語のエラーメッセージが既存のエラースタイルで表示されること。
5. メモリリークが発生しないこと: コンポーネントのマウント/アンマウントを繰り返しても、terminateされていないWorkerが残らないこと。
6. ビルドが成功すること: npm run lint && npm run format:check && npm run test && npm run build がすべて成功すること。
7. レビューでApproveされること: reviewerエージェントによるレビューで指摘事項がすべて解消されていること。

6. 作業の分割（builderへの委託方針）

この作業は単一のbuilderエージェントに委託してよい。理由は以下の通り。

• 変更対象は src/tools/regex-tester/ ディレクトリ内の4-5ファイルに限定されており、他のコンポーネントへの影響がない。
• 新規ファイル2つ（worker, hook）と既存ファイル2つ（Component, CSS）の修正であり、相互に密結合しているため分割すると非効率になる。
• ロジック（logic.ts）と既存テストは変更不要であるため、変更リスクが低い。

ただし、作業完了後のレビューは必ず別のreviewerエージェントに委託すること。