【テクニカル・上級編】【大容量ファイルパース】StdIn / StdOut ストリームパイプライン処理による低メモリ消費ログ解析 – VBScript (Visual Basic Scripting Edition)解析バイブル

【大容量ファイルパース】StdIn / StdOut ストリームパイプライン処理による低メモリ消費ログ解析

レガシーシステムの現場において、数ギガバイトに及ぶIISのログ、統合監査ログ、あるいは巨大なCSVデータの解析は、しばしばインフラエンジニアの頭痛の種となる。
「`FileSystemObject` (FSO) の `OpenTextFile` でファイルを一気に読み込み、`ReadAll` や `ReadLines` でメモリに展開する」——もしあなたが未だにこのようなコードを書いているなら、今すぐその手を止めてほしい。

32bit版の制約、ガベージコレクションの不確実性、そして容赦なく発生する `Out of memory` (エラー 7) の恐怖。これらはレガシー環境特有の呪いではない。メモリ管理のセマンティクスを無視した、怠惰なコードが生み出す必然の悲劇に過ぎず、VBScriptそのものの限界ではない。

今回は、WSH (Windows Script Host) の `StdIn` / `StdOut` ストリームパイプラインを極限までドライヴし、理論上、数テラバイトのファイルであっても「数キロバイトのメモリ消費量」で秒速パースを完結させるための極意を伝授する。

—

1. なぜFSOの「一括ロード」は現場を殺すのか

多くの中級プログラマは、ファイルを処理する際に次のようなコードを書く。

‘ 【アンチパターン】絶対にやってはいけない実装
Set fso = CreateObject(“Scripting.FileSystemObject”)
Set ts = fso.OpenTextFile(“C:\Logs\huge_massive.log”, 1)
allText = ts.ReadAll ‘ ← ここでファイル全体がBSTRとしてメモリ上に展開される
ts.Close

lines = Split(allText, vbCrLf)
For i = 0 To UBound(lines)
‘ 処理…
Next

このコードの何が致命的か。
1. メモリの2重・3重消費: ファイルサイズが 2GB の場合、BSTR（VBScriptの文字列型）としてメモリ上に約2GB、さらに `Split` 関数によって生成された配列がポインタ配列と文字列のコピーを含めて数倍のメモリを喰らい尽くす。
2. OSの仮想メモリの暴走: 結果としてページファイルへのスワップが発生し、CPU使用率が100%に張り付いたままシステムが応答しなくなる（いわゆるフリーズ状態）。

ストリーム処理というパラダイムシフト

我々が目指すべきは「ファイルをコンテナとしてメモリにロードする」ことではない。「データが流れるパイプ（Stream）の上に立ち、流れてくる一滴（Line）をその場で評価し、不要なものを捨て、必要なものだけをバケツ（StdOut）にすくい上げる」ことだ。

WSHの `WScript.StdIn.AtEndOfStream` と `SkipLine` / `ReadLine` は、まさにこのストリームパラダイムのために存在する。

—

2. アーキテクチャ設計：パイプライン・ストリーミング

今回のアーキテクチャは、UNIXのパイプ思想（`cat huge.log | cscript //nologo parser.vbs | findstr …`）を完全に踏襲する。

• 入力: `cscript //nologo` の標準入力 (`StdIn`) から、1行ずつ遅延評価（Lazy Evaluation）で読み込む。
• 処理: 正規表現や文字列比較を用い、メモリ上でオブジェクトを肥大化させずにフィルタリング。
• 出力: 抽出した結果のみを標準出力 (`StdOut`) へ流す。

これにより、VBScriptホストプロセス (`cscript.exe`) のメモリフットプリントは、数MB（メガバイト）のままで安定し続ける。

—

3. 実装コード：極限最適化ストリームパーサ

以下のスクリプトは、数GBのログから特定のキーワード（例: `[ERROR]` や特定のIPアドレス）を含む行だけを抽出し、メモリリークを完全に排除しながら超高速に処理するプロダクションコードである。

‘ ==============================================================================
‘ Script Name: StreamLogParser.vbs
‘ Description: StdIn/StdOutを使った低メモリ消費・超高速ログパーサ
‘ Usage: cscript //nologo StreamLogParser.vbs < "C:\Logs\huge.log" > “C:\Logs\filtered.log”
‘ ==============================================================================
Option Explicit

Sub Main()
‘ パフォーマンスとメモリ管理の定数定義
Const TARGET_KEYWORD = “CRITICAL_ERROR”

Dim objStdIn, objStdOut
Set objStdIn = WScript.StdIn
Set objStdOut = WScript.StdOut

Dim strLine
Dim lngTotalLines, lngMatchedLines
lngTotalLines = 0
lngMatchedLines = 0

‘ 【極意】WScript.StdIn.AtEndOfStream を用いたストリーミングループ
‘ ファイルサイズに依存せず、常に1行分のメモリ（数バイト〜数KB）しか消費しない
Do While Not objStdIn.AtEndOfStream
strLine = objStdIn.ReadLine
lngTotalLines = lngTotalLines + 1

‘ 高速フィルタリング（InStrは正規表現よりもオーバーヘッドが圧倒的に少ない）
If InStr(1, strLine, TARGET_KEYWORD, vbBinaryCompare) > 0 Then
objStdOut.WriteLine strLine
lngMatchedLines = lngMatchedLines + 1
End If

‘ 大規模ループにおけるVBScriptのメモリ肥大化（BSTRキャッシュ）を防ぐため、
‘ 数万行ごとに文字列変数を明示的にリセットする（必要に応じた防衛策）
If (lngTotalLines Mod 50000 = 0) Then
‘ 参照の切断とガベージコレクションの誘発
strLine = Empty
End If
Loop

‘ 処理結果をエラー出力（StdErr）へ流す（標準出力を汚さないためのプロの技）
WScript.StdErr.WriteLine “— パース完了 —”
WScript.StdErr.WriteLine “総スキャン行数: ” & FormatNumber(lngTotalLines, 0)
WScript.StdErr.WriteLine “抽出ヒット数: ” & FormatNumber(lngMatchedLines, 0)

‘ オブジェクトの明示的解放（VBScriptの作法）
Set objStdOut = Nothing
Set objStdIn = Nothing
End Sub

‘ エントリポイントの呼び出し
Call Main()

—

4. チーフアーキテクトが教える「現場の知見」とパフォーマンスチューニング

このコードを実際のミッションクリティカルな環境で運用するにあたり、知っておくべき極限の知見を共有する。

1. `InStr` vs `RegExp` の使い分け

多くのエンジニアは、条件複雑化を恐れてすぐに `VBScript.RegExp` オブジェクトを生成しがちだ。しかし、`RegExp` の生成と内部コンパイルのオーバーヘッドは、数百万行のループ内では無視できない性能劣化を引き起こす。

• 単純なキーワード検索: `InStr` (バイナリ比較 `vbBinaryCompare`) を使え。C言語レベルの最適化が効いており、爆速で動作する。
• パターンマッチング（IPアドレス、日付など）: やむを得ず `RegExp` を使う場合は、ループの外で一度だけインスタンスを生成し、`Global` や `Pattern` プロパティをループ内で使い回せ。ループ内で `New RegExp` を呼ぶ愚行は、メモリフラグメンテーションの元凶となる。

2. `StdErr` の活用によるパイプラインの汚染防止

標準出力 (`StdOut`) は、最終的な「データ」を流すためのパイプラインである。処理の進捗状況 (Progress) やログ件数などを画面に出力したい場合、`WScript.Echo` を使うと標準出力に混ざり、後続のプログラム（あるいはPowerShellやバッチファイル）のパースエラーを誘発する。
必ず `WScript.StdErr.WriteLine` を使用し、データチャネルとログチャネルを厳格に分離すること。これがプロのシステム間連携の作法である。

3. VBScriptのメモリモデルと `Empty`

VBScriptの文字列変数はBSTRとして管理されており、長寿命のループ内で文字列を結合・代入し続けると、メモリ上に細切れのフラグメント（断片）が残ることがある。
今回のコードで入れている `If (lngTotalLines Mod 50000 = 0) Then strLine = Empty` は、巨大な文字列参照を定期的にお掃除するための防衛的プログラミングのテクニックである。これにより、何十時間走り続けるバッチ処理でもメモリリークを完全にゼロに抑え込むことができる。

—

5. まとめ

VBScriptは「古い言語」として片付けられがちだ。しかし、OSの根幹に深く組み込まれ、追加のランタイムを一切必要とせず、Windows環境において数行のコードでパイプライン処理を実現できるその圧倒的な軽快さは、現代においても代替不可能な価値を持つ。

メモリの制約を言い訳にする時代は終わった。StdIn/StdOutを掌握した者だけが、レガシーシステムの限界を突破し、巨大なデータの大海をエレガントに航海することができるのだ。