Toolish Utility インフラ運用
セキュリティ補助

ログ用正規表現テスター

正規表現をログ本文に適用し、マッチ件数、行番号、名前付き/番号グループをブラウザ内で確認します。

いつ使うか

いつ使うか ログ向け正規表現を専用 Worker で実行し、750ms を超えた処理を停止します。
誰向けか ネットワーク・インフラ運用で、外部送信せずに下準備や確認をしたい担当者向けです。
何が分かるか 最大1,000件のマッチ一覧、名前付き/番号グループ、打ち切り注記を表示します。
次に使う関連ツール ログ前処理・トークン概算 AI投入前マスク config区間抽出・正規化

入力

フラグ
結果

出力

正規表現テスト結果


    

      
実務で使う場面

      
    
        
  • log抽出patternを運用へ入れる前にsampleで確認するとき。
  • 番号付きcaptureとnamed capture groupの値を確認するとき。
  • multiline logでi、m、s flagによるmatchの違いを確認するとき。
  • patternが想定外の行までmatchしないかを確認するとき。
    • 
      

    

    

      
入力例と期待される出力

      

        
          

            
大文字小文字を区別しないlevel抽出

            

              

                
入力

                
pattern: (?<level>error|warn)
flags: i
text:
INFO ok
WARN retry
ERROR failed

              

              

                
期待される出力

                
2 matches。L2 @8 WARNはgroup 1とnamed group levelがWARN、L3 @19 ERRORはgroup 1とnamed group levelがERRORです。

              

            

          

        
          

            
multiline anchorでmessage抽出

            

              

                
入力

                
pattern: ^(?<level>WARN|ERROR)\s+(?<message>.+)$
flags: m
text:
INFO ready
WARN retry scheduled
ERROR request failed

              

              

                
期待される出力

                
2 matches。L2 @11はlevel=WARN、message=retry scheduled、L3 @32はlevel=ERROR、message=request failedです。m flagにより^と$を各行へ適用します。

              

            

          

        
      

    

    

      
結果の読み方

      
    
        
  • 件数はruntimeが収集したmatch数で、L<n>はline番号、@<n>はtext先頭からのindexです。
  • group objectには番号付きcaptureとnamed captureの値を表示します。
  • 上限で打ち切りと表示された場合は全件を返しておらず、pageのmatch一覧は先頭50件までです。
  • UIで選んだi、m、sに加え、全match走査のためglobal処理を内部で行います。
    • 
      

    

    

      
注意事項

      
    
        
  • JavaScript RegExpを使用するため、PCRE、RE2、Grokと同じsyntaxや動作ではありません。
  • 750ms timeoutはReDoS耐性やproduction利用時の安全性を保証しません。
  • match件数、result文字数、capture group数、page表示件数の上限により、全件を確認できない場合があります。
  • sample logへのmatchだけでは、productionの全logで意図どおり動くことを確認できません。
  • greedy patternやnested quantifierは、想定外のmatchや処理遅延を起こす場合があります。
  • 秘密情報を含むlogは入力せず、画面共有、copy、browser履歴にも注意してください。
  • zero-length matchを含むpatternは件数が増えやすく、syntax成功だけでは抽出意図の正しさを確認できません。
    • 
      

    

    

      
関連ツールと次の流れ

      
    
        
  1. ログ前処理・トークン概算重複行や低severity行を整理してからpatternを確認します。
  2. config区間抽出・正規化logではなくconfigの関連blockをkeywordで抽出します。
  3. AI投入前マスク相談用sampleに残る識別子を外部共有前にマスクします。
  4. AI相談プロンプトビルダーpattern、sample、期待結果、確認事項を相談文へ整理します。
    5. 
      

    

  
    
  
利用メモ
  • 入力内容は保存せず、ブラウザ内で処理します。
  • 外部APIやCDNへ送信しません。

    

      
実務上の注意

      
    
        
  • 対象テキストは200KBを上限に検査します。
  • ReDoSを完全に防ぐものではありません。大きい入力は分割してください。
    • 
      

    

  
    

      
関連ツール