【実務・中級編】VB.NETでの正規表現（System.Text.RegularExpressions）活用術：複雑な文字列パターンマッチングと入力値検証の実装 – Visual Basic (VB / VB.NET)解析バイブル

【VB.NET極限活用】正規表現エンジンを飼い馴らせ：バグゼロの入力値検証と超高速パターンマッチングの極意

開発現場でこんなコードを見たことはないか？

.net
‘ 【アンチパターン】String操作の連打による脆弱で非効率なバリデーション
If inputStr.Contains(“@”) AndAlso inputStr.Contains(“.”) AndAlso inputStr.Length >= 5 Then
‘ メールアドレスらしき何かを通す
End If

笑い事ではない。いまだに業務システムの現場では、このようなナイーブな文字列判定が蔓延し、不正データの混入や予期せぬパースエラーを引き起こしている。

文字列操作は、業務アプリケーションの「玄関口」だ。ここが脆弱であれば、データベースの汚染、セキュリティインシデント、そして何よりユーザーからの信頼失墜という致命傷につながる。

今回は、VB.NETにおける `System.Text.RegularExpressions` 名前空間を完全に手なずけ、「堅牢」「高速」「保守性抜群」な入力値検証とパターンマッチングを実装するための知見を、チーフアーキテクトの私から授けよう。

—

1. なぜVB.NETの正規表現は「重い」と言われるのか？

正規表現は強力だが、使い方を誤るとガベージコレクション（GC）の嵐を引き起こし、CPUを焼き尽くす。
最大の悪手は、ループ内で毎回 `Regex` インスタンスを生成することだ。

.net
‘ 【絶対にやるな】ループ内でのRegexインスタンス生成
For Each line As String In hugeTextLines
‘ ループのたびにコンパイルとメモリ割り当てが発生し、パフォーマンスが崩壊する
If System.Text.RegularExpressions.Regex.IsMatch(line, “^[A-Z]{3}-\d{4}$”) Then
‘ 処理…
End If
Next

【アーキテクトの知見】`Regex` オブジェクトは「重いコンパイル済みオブジェクト」である

正規表現エンジンは、渡されたパターン文字列を内部で中間言語にコンパイルしている。これを毎回行うのは、毎回車輪の再発明をしているようなものだ。

• 対策1: `Shared`（C#でいう `static`）なフィールドとして保持するか、`RegexOptions.Compiled` を付与してJITコンパイルを最適化する。
• 対策2: .NETの進化恩恵を受けよ。.NET Core / .NET 6以降であれば、C#同様に `GeneratedRegex` 属性（VB.NETではソースジェネレータの構文制約があるため、静的インスタンス＋Compiledオプションが定石）を活用する。

—

2. 【実践】プロダクション品質のバリデーションクラス設計

実際の業務システムでは、単発の正規表現チェックではなく、共通関数としてカプセル化し、かつ「タイムアウト処理」を仕込む必要がある。悪意あるユーザーが仕掛けた「Catastrophic Backtracking（カタストロフィック・バックトラッキング / 正規表現DoS攻撃）」によって、アプリケーションがフリーズするのを防ぐためだ。

以下のコードは、現場でそのまま使える、堅牢性を極めたバリデーション用のモジュールである。

.net
Imports System.Text.RegularExpressions

Public Module RegexValidator
‘ タイムアウト設定（正規表現の無限ループを防ぐため、デフォルトで250ミリ秒に制限）
Private ReadOnly MatchTimeout As TimeSpan = TimeSpan.FromMilliseconds(250)

‘ 【型番パターン】 例: ABC-1234-X (英字3桁-数字4桁-英字1桁)
‘ 静的かつコンパイル済みで保持し、パフォーマンスを極限まで高める
Private ReadOnly ModelNumberRegex As New Regex(
“^[A-Z]{3}-\d{4}-[A-Z]$”,
RegexOptions.Compiled Or RegexOptions.CultureInvariant,
MatchTimeout
)

‘ 【郵便番号パターン】 例: 123-4567 または 1234567
Private ReadOnly PostalCodeRegex As New Regex(
“^\d{3}-?\d{4}$”,
RegexOptions.Compiled Or RegexOptions.CultureInvariant,
MatchTimeout
)

‘ 【メールアドレスパターン】 RFC5322完全準拠は逆にバグの元となるため、実用的な厳格パターンを採用
Private ReadOnly EmailRegex As New Regex(
“^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$”,
RegexOptions.Compiled Or RegexOptions.CultureInvariant,
MatchTimeout
)

”’

Public Function IsValidModelNumber(input As String) As Boolean
If String.IsNullOrWhiteSpace(input) Then Return False
Return ModelNumberRegex.IsMatch(input)
End Function

”’

Public Function TryFormatPostalCode(input As String, ByRef normalizedOutput As String) As Boolean
normalizedOutput = String.Empty
If String.IsNullOrWhiteSpace(input) Then Return False

Dim m As Match = PostalCodeRegex.Match(input)
If Not m.Success Then Return False

‘ ハイフンが含まれていない場合は挿入する（例: 1234567 -> 123-4567）
Dim rawValue As String = input.Trim()
If rawValue.Length = 7 AndAlso Not rawValue.Contains(“-“c) Then
normalizedOutput = rawValue.Insert(3, “-“)
Else
normalizedOutput = rawValue
End If

Return True
End Function

”’

Public Function IsValidEmail(input As String) As Boolean
If String.IsNullOrWhiteSpace(input) Then Return False

‘ 長さ制限のチェック（DB制約やセキュリティ対策）
If input.Length > 254 Then Return False

Return EmailRegex.IsMatch(input)
End Function
End Module

—

3. 複雑な文字列抽出：グループ化と名前付きキャプチャの魔力

単なる「合っている・間違っている」の判定だけが正規表現ではない。ログファイルやCSV、レガシーな固定長データから、必要な情報を「削り出す」ときにも正規表現は真価を発揮する。

ここで、位置依存の泥臭い `Mid()` や `Substring()` を使うのは今日で終わりにしよう。名前付きキャプチャを使えば、保守性の高い美しいコードが書ける。

シナリオ：ログファイルからの構造化データ抽出

例えば、以下のようなフォーマットのログ行から、「日時」「ログレベル」「コード」「メッセージ」を抽出したいとする。
`[2023-10-25 14:30:05] [ERROR] [ERR_DB_01] Connection timeout to database.`

これを実装したコードが以下だ。

.net
Imports System.Text.RegularExpressions

Public Class LogParser
‘ 名前付きキャプチャグループ (?…) を用いた極めて読みやすいパターン
Private Const LogPattern As String =
“^\[(?\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})\]\s+” &
“\[(?\w+)\]\s+” &
“\[(?[\w_-]+)\]\s+” &
“(?.)$”

Private ReadOnly _parserRegex As New Regex(LogPattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(100))

”’

Public Function ParseLogLine(logLine As String) As (Success As Boolean, Timestamp As DateTime, Level As String, ErrCode As String, Message As String)
‘ デフォルト値の定義
Dim defaultResult = (Success:=False, Timestamp:=DateTime.MinValue, Level:=String.Empty, ErrCode:=String.Empty, Message:=String.Empty)

If String.IsNullOrWhiteSpace(logLine) Then Return defaultResult

Dim match As Match = _parserRegex.Match(logLine)
If Not match.Success Then Return defaultResult

‘ 名前付きグループから安全に値を取り出す
Dim tsStr As String = match.Groups(“Timestamp”).Value
Dim level As String = match.Groups(“Level”).Value
Dim errCode As String = match.Groups(“ErrCode”).Value
Dim message As String = match.Groups(“Message”).Value

Dim parsedTime As DateTime
If DateTime.TryParse(tsStr, parsedTime) Then
Return (True, parsedTime, level, errCode, message)
End If

Return defaultResult
End Function
End Class

この設計が優れている理由

1. マジックナンバーの排除: `Match.Groups(1)` のようなインデックスアクセスは、正規表現の微修正でズレてバグの温床になる。`Match.Groups(“Timestamp”)` のように名前でアクセスすることで、構造の変更に極めて強いコードになる。
2. 型安全性の確保: VB.NETのタプル構文（`ValueTuple`）を利用することで、軽量かつ明示的な戻り値を定義でき、呼び出し側のコードが劇的にすっきりする。

—

4. ファイルおよびデータベース連携における「罠」

業務アプリで正規表現を使う際、避けて通れないのが外部リソースとの境界線だ。

① データベース（SQL Server等）との役割分担

「DBに登録する前に、すべてのバリデーションをVB.NET側ですべきか？」
答えは Yesであり、Noでもある。

• アプリケーション側（VB.NET）の責務: ユーザービリティの担保。不正な入力を即座に検知し、画面上で赤字エラーを出す。不要なネットワークラウンドトリップを防ぐ。
• データベース側の責務: データの完全性の担保。アプリケーションがバイパスされた場合（API直接叩き、バッチ処理など）を考慮し、DB側でもチェック制約（`CHECK` 制約）やデータ型制約を必ずかけること。

② 大容量ファイル読み込み時のメモリ枯渇対策

ギガバイト級のCSVやテキストログに対して、ファイル全体をメモリに読み込んで `Regex.Matches` をかける愚行は慎んでほしい。OutOfMemoryExceptionでシステムがクラッシュする。

大容量ファイルを扱う場合は、必ず `System.IO.File.ReadLines`（遅延評価ストリーミング）を使い、1行ずつストリーム処理せよ。

.net
‘ 【メモリ効率を極めたファイル走査】
Public Sub ProcessLargeLogFile(filePath As String)
‘ ReadLinesはファイルを一気に読み込まず、1行ずつ遅延列挙する（メモリ消費量ほぼゼロ）
For Each line As String In System.IO.File.ReadLines(filePath, System.Text.Encoding.UTF8)
‘ ここで先ほどのバリデーションやパースを適用する
If RegexValidator.IsValidModelNumber(line) Then
‘ 該当行の処理
End If
Next
End Sub

—

5. チーフアーキテクトからの総括

正規表現は、使いこなせばVB.NETのコードベースを劇的にスリムにし、堅牢性を高める「最強のメス」となる。しかし、設計思想なき実装は、パフォーマンス低下やメンテナンス不可能な「スパゲッティ・パターン」を生む諸刃の剣だ。

今日からあなたのプロジェクトで以下のルールを徹底してほしい：

1. `Regex` インスタンスは `Shared ReadOnly` で隠蔽し、コンパイルオプションを有効化する。
2. インデックスによるグループ参照を禁止し、名前付きキャプチャを使用する。
3. 無限ループ（ReDoS）を防ぐため、必ずタイムアウト時間を設定する。
4. 巨大なファイルには `File.ReadLines` によるストリーミング処理を組み合わせる。

この知見を胸に、美しく、そして鉄壁の信頼性を持つ業務システムを構築してほしい。健闘を祈る。