【ストリームパイプ処理】CScript 実行における WScript.StdIn 逐次読み込みと超高速テキストフィルタリング
レガシーシステムの深部、あるいは現代のWindows自動化スクリプトの裏側において、VBScript（Visual Basic Scripting Edition）とWSH（Windows Script Host）は依然としてインフラストラクチャの接着剤として機能し続けている。
特に `CScript.exe` を用いたコンソール実行環境において、他のネイティブコマンド（PowerShell、`findstr`、`icacls`、あるいは自作のC++製バイナリなど）とパイプライン（`|`）で接続されたストリーム処理は、システム管理者がマスターすべき極限のスキルの一つである。
本稿では、数GBに及ぶ巨大なログファイルやストリームデータをメモリに一括ロード（全読み込み）してVBScriptをクラッシュさせる愚を犯さず、`WScript.StdIn` を用いて「1行ずつ逐次処理」し、極限までメモリフットプリントを削ぎ落とした超高速テキストフィルタリングのアーキテクチャを解説する。
—
1. なぜ「一括読み込み（`ReadAll`）」は悪手なのか
VBScriptで標準入力を扱う際、多くの開発者は以下のようなコードを書く。
‘ 【アンチパターン】全データを一度にメモリへ読み込む
Dim allText, lines
allText = WScript.StdIn.ReadAll()
lines = Split(allText, vbCrLf)
For i = 0 To UBound(lines)
‘ 処理ロジック
Next
このアプローチは、小規模なデータであれば動く。しかし、対象が 100万行を超えるIISのログ や 巨大なCSV/JSONストリーム になった瞬間、以下の致命的な問題を引き起こす。
1. メモリの爆発的消費（OOMエラー）: `ReadAll` はストリーム全体をBSTR（Unicode文字列）としてメモリ上に展開する。さらに `Split` 関数は、その文字列の数倍のメモリ領域を一時配列として要求するため、あっさり「メモリ不足（Out of memory）」でスクリプトが即死する。
2. レイテンシの増大: すべてのデータが流し終わるまで後続の処理が1行も実行されないため、パイプライン全体のスループットが著しく低下する。
真のプロフェッショナルであれば、「流れてきたデータをその場で受け止め、即座に流す（Stream Processing）」 以外の選択肢を排除すべきである。
—
2. `WScript.StdIn.AtEndOfStream` と `ReadLine` による真のストリーム処理
メモリ効率を極限まで高める唯一の解は、`WScript.StdIn` のイテレーティブな読み込みである。`AtEndOfStream` プロパティを監視し、`ReadLine` で1行ずつメモリ上にスワップしながら処理を回す。
ここに、余計なオブジェクト生成を排し、ガベージコレクタ（VBScriptの内部リファレンスカウンタ）に無駄な負荷をかけない極限のコードを示す。
実装コード: `StreamFilter.vbs`
Option Explicit
‘ ==============================================================================
‘ 高速ストリームフィルタ・エンジン (CScript 専用)
‘ 用途: 標準入力から受け取ったテキストを1行ずつ評価し、条件に合致するものだけを標準出力へ流す
‘ 実行例: type massive.log | cscript //nologo StreamFilter.vbs “ERROR”
‘ ==============================================================================
Sub Main()
‘ 引数の検証
If WScript.Arguments.Count < 1 Then
WScript.StdErr.WriteLine "[ERROR] 検索キーワードが指定されていません。"
WScript.Quit 1
End If
Dim targetKeyword
targetKeyword = WScript.Arguments(0)
' 高速化のためのオブジェクト参照のローカル変数化（VBScriptの最適化手法）
Dim stdIn, stdOut
Set stdIn = WScript.StdIn
Set stdOut = WScript.StdOut
Dim currentLine
Dim lineCount
lineCount = 0
' 【核心】ストリームの終端に達するまで1行ずつ読み込む（メモリ消費量は常に1行分のみ）
Do While Not stdIn.AtEndOfStream
currentLine = stdIn.ReadLine
lineCount = lineCount + 1
' 簡易フィルタリングロジック（必要に応じて正規表現などに拡張可能）
If InStr(1, currentLine, targetKeyword, vbTextCompare) > 0 Then
stdOut.WriteLine lineCount & “: ” & currentLine
End If
Loop
‘ 明示的なオブジェクトの解放（ライフサイクル管理の徹底）
Set stdOut = Nothing
Set stdIn = Nothing
End Sub
‘ エントリポイントの呼び出し
Call Main()
WScript.Quit 0
—
3. チーフアーキテクトが教えるパフォーマンス最適化の極意
上記のコードはシンプルに見えるが、VBScriptの内部挙動とCOM（Component Object Model）の制約を知り尽くしたエンジニアの知見が凝縮されている。現場で生きる3つの最適化指針を伝授する。
① オブジェクト参照のローカル変数キャッシュ
VBScriptにおいて `WScript.StdIn` や `WScript.StdOut` といったグローバルオブジェクトへのアクセスは、背後でCOMのプロパティ呼び出し（IDispatch経由の遅延バインディング）が発生するため、ループの内部で直接呼び出すと深刻なオーバーヘッドになる。
上記コードのように、ループに入る前にローカル変数へ参照を格納（キャッシュ）する ことで、ディスパッチのコストを最小化し、数万行/秒の処理速度を実現できる。
② `WScript.StdErr` を用いたロギングの分離
パイプライン処理において、ステータスやデバッグメッセージを `WScript.StdOut` に出力すると、後続のコマンド（例: `| findstr` やファイルへのリダイレクト `> output.txt`）のデータを汚染してしまう。
エラーや進捗状況の出力は必ず `WScript.StdErr` を経由させること。これにより、データストリームとコントロールストリームの完全な分離（Unix哲学の継承）が達成される。
③ 文字コード（CP932 / UTF-8）の罠への対策
Windows環境の `CScript.exe` は、デフォルトの入出力エンコーディングとしてアクティブコードページ（日本語環境であれば CP932 / Shift-JIS）を採用する。
もしパイプ元のコマンドが UTF-8（BOMなし）などでデータを流してき文字化けが発生する場合は、スクリプト内で強引に解決しようとせず、実行時にラッパーコマンドを使用するのが鉄則である。
REM UTF-8の出力をSJISに変換しつつVBScriptのストリームパイプに流す例
chcp 65001 > nul
type utf8_source.log | powershell -Command “$input | foreach {$_}” | cscript //nologo StreamFilter.vbs “Keyword”
(※あえてPowerShell等を挟むよりも、純粋なバイナリ/テキストストリームを維持したい場合は、ADO.Stream等を用いた標準入力のバイナリフックを実装するアプローチもあるが、それはまた別の極限領域の話となる)
—
4. レガシーとモダンを繋ぐ価値
「なぜ今さらVBScriptなのか」と嘲笑する者は、インフラストラクチャの多様性と、サードパーティ製ランタイム（.NETやPythonなど）を持ち込めない厳格なサンドボックス環境の現実を知らない者だ。
どのWindowsマシン（Windows 2000から最新のWindows 11まで）にも標準で搭載されており、追加のインストールやパス設定なしでミリ秒単位の起動を果たす `CScript.exe` とストリーム処理の組み合わせは、システム管理における「究極の軽量武器」である。
メモリを支配し、ストリームを制圧せよ。この知見が、あなたのレガシーシステムの寿命を延ばし、圧倒的な自動化パフォーマンスをもたらすことを確信している。
