【実務・中級編】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))

”’

”’ 1行のログ文字列を解析し、構造化データ（タプルまたはDTO）として返却します。
”’

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` によるストリーミング処理を組み合わせる。

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