【極限の知見】巨大ログを制する「逆走パース」技術：メモリを食いつぶさないプロフェッショナルの設計思想
業務自動化の現場において、エンジニアの力量が最も残酷な形で露呈するのが「ファイルサイズ」という壁だ。
「数MBのログを解析するスクリプト」は、誰でも書ける。しかし、「数GBに達する膨大なアプリケーションログの末尾から、最新のエラーを瞬時に特定するスクリプト」を書ける者は、そう多くはない。
もし君が、`FileSystemObject` (FSO) の `ReadAll` メソッドを、サイズが不確定なファイルに対して安易に使っているとしたら、今すぐその設計を捨てろ。それは「動くコード」ではあっても、「堅牢なプロダクションコード」ではない。メモリを食いつぶし、サーバーのパフォーマンスを低下させ、最悪の場合、実行環境をダウンさせる爆弾を抱えているのと同じだ。
本稿では、中級者から上級者へとステップアップするために不可欠な、「バッファ制御によるテキスト逆走パース」の極意を伝授する。
1. なぜ `ReadAll` は「エンジニアの敗北」を意味するのか
まず、なぜ君の書いたコードが、本番環境で悲鳴を上げるのかを論理的に理解せよ。
メモリ・スワッピングの恐怖
`FSO.OpenTextFile(path).ReadAll` を実行した瞬間、ファイルの内容はすべて物理メモリ上に展開される。ファイルが2GBあれば、スクリプトプロセスは2GB以上のメモリを要求する。
現代のサーバーは潤沢なメモリを持っているように見えるが、他のプロセスとの競合、そしてVBScript（32bitプロセスの場合が多い）の扱えるアドレス空間の限界を考慮すれば、これは極めてリスクの高い設計だ。
I/Oオーバーヘッドの非効率性
巨大なファイルを一度に読み込むことは、ディスクI/Oに巨大な負荷をかける。ログの解析において、我々が知りたいのは「ファイル全体」ではなく、「最新の数行」であることがほとんどだ。全体を読み込むのは、目的地にたどり着くために地球を一周するような、愚かな回り道である。
2. アーキテクチャ設計：バッファリングと逆走（Reverse Seeking）
プロフェッショナルが取るべき戦略は、「ファイルの後ろから、必要な分だけ、小刻みに読み進める」ことだ。
アルゴリズムの要諦
1. ファイルサイズの取得: ターゲットファイルの最終位置を特定する。
2. ポインタの逆走設定: ファイル末尾から「一定のバッファサイズ（例: 64KB）」分だけ戻った位置にシーク（Seek）する。
3. チャンク読み込み: バッファ単位でテキストを読み込む。
4. キーワード検索: 読み込んだチャンク内にターゲットキーワードが存在するか判定する。
5. ループと後退: キーワードが見つからなければ、さらにバッファ分だけポインタを戻し、手順3へ。
技術的選択：FSOではなく `ADODB.Stream` を使え
ここで一つ、重要な設計上のアドバイスがある。
実は、標準的な `FileSystemObject` の `TextStream` オブジェクトには、任意のバイト位置に直接ジャンプする `Seek` メソッドが貧弱（あるいは存在しない）だ。
真に効率的な逆走パースを行うには、`ADODB.Stream` を活用せよ。これはバイナリ・テキスト双方の扱いにおいて極めて強力で、任意のオフセットへのシークをサポートしている。FSOは「ファイルの存在確認や属性取得」に使い、実データのパースは `ADODB.Stream` に任せる。これがプロの使い分けだ。
3. プロダクション・コード例：堅牢な逆走検索エンジン
以下に、実務でそのまま利用可能な、バッファ制御を用いた検索ロジックを示す。
' **
' Module: ReverseLogSearcher
' Description: 巨大ログファイルから末尾に向かってキーワードを高速検索する
' Author: Chief Architect
' **
Option Explicit
' 定数定義
Const BUFFER_SIZE = 65536 ' 64KBのバッファを使用 (I/O効率とメモリのバランス)
Const ADODB_TYPE_BINARY = 1
Const ADODB_TYPE_TEXT = 2
Const ADODB_CHARSET_UTF8 = "UTF-8"
''' <summary>
''' 指定したファイル内の末尾からキーワードを検索する
''' </summary>
''' <param name="filePath">対象ファイルのフルパス</param>
''' <param name="keyword">検索する文字列</param>
''' <returns>見つかった場合はその行の内容、見つからない場合はEmpty</returns>
Function FindLastOccurrence(filePath, keyword)
Dim fso, stream, fileSize, pos, chunk, found
Dim currentLine, searchPos
Set fso = CreateObject("Scripting.FileSystemObject")
' 1. ファイルの存在確認（FSOの役割）
If Not fso.FileExists(filePath) Then
Err.Raise 1, "FindLastOccurrence", "File not found: " & filePath
End If
fileSize = fso.GetFile(filePath).Size
If fileSize = 0 Then
FindLastOccurrence = Empty
Exit Function
End If
' 2. ADODB.Streamによるストリーム制御
Set stream = CreateObject("ADODB.Stream")
stream.Type = ADODB_TYPE_TEXT
stream.Charset = "Shift-JIS" ' ログのエンコードに合わせて変更せよ
stream.Open
stream.LoadFromFile filePath
' ファイル末尾から探索を開始
' 注意: 実際には「末尾からバッファ分戻った位置」から読み始める
pos = fileSize
found = False
Do While pos > 0
' 読み込み開始位置を計算（ファイル末尾からバッファ分戻る）
Dim readSize
If pos < BUFFER_SIZE Then
readSize = pos
pos = 0
Else
readSize = BUFFER_SIZE
pos = pos - BUFFER_SIZE
End If
' ポインタを移動
stream.Position = pos
' 指定したサイズ分だけ読み込み
chunk = stream.Read(readSize)
' 3. キーワードの判定
' 簡易化のためInStrを使用。より厳密には行の境界を考慮する必要がある。
If InStr(chunk, keyword) > 0 Then
' キーワード発見！
' ここでは見つかったチャンクを返す（実務ではここから行の切り出しを行う）
FindLastOccurrence = ExtractLineFromChunk(chunk, keyword)
found = True
Exit Do
End If
' ループ継続：さらに後ろへ
If pos = 0 Then Exit Do
Loop
If Not found Then FindLastOccurrence = Empty
stream.Close
Set stream = Nothing
Set fso = Nothing
End Function
''' <summary>
''' チャンクの中からキーワードを含む行を特定する（補助関数）
''' </summary>
Function ExtractLineFromChunk(chunk, keyword)
Dim lines, i
' 改行コードで分割（CRLF/LF両対応を考慮）
Dim cleanChunk
cleanChunk = Replace(chunk, vbCrLf, vbLf)
cleanChunk = Replace(cleanChunk, vbCr, vbLf)
lines = Split(cleanChunk, vbLf)
' チャンク内を後ろから走査
For i = UBound(lines) To 0 Step -1
If InStr(lines(i), keyword) > 0 Then
ExtractLineFromChunk = Trim(lines(i))
Exit Function
End If
Next
ExtractLineFromChunk = ""
End Function
' --- テスト実行 ---
Dim targetFile, searchWord, result
targetFile = "C:\Logs\app_server.log" ' 実在するパスに変更してテストせよ
searchWord = "ERROR"
On Error Resume Next
result = FindLastOccurrence(targetFile, searchWord)
If Err.Number <> 0 Then
WScript.Echo "Error: " & Err.Description
ElseIf IsEmpty(result) Then
WScript.Echo "キーワードは見つかりませんでした。"
Else
WScript.Echo "最新のエラー検出: " & result
End If
On Error GoTo 04. 実務における「堅牢性」への注意点
このコードをプロダクション環境に投入する際、以下の3点を必ず検討せよ。これらが抜けていると、設計の甘さが露呈することになる。
① エンコーディングの不一致
`ADODB.Stream` の `.Charset` 指定は極めて重要だ。UTF-8のログに対し `Shift-JIS` で読み込めば、キーワード検索は確実に失敗する。対象となるログのエンコーディングを事前に特定し、動的に切り替えられる設計にせよ。
② キーワードの「分断」問題
バッファサイズ（例：64KB）の境界線上で、ターゲットキーワード（例：`ERROR`）が `ER` と `ROR` に分かれてしまう可能性がある。
解決策: チャンクを読み込む際、前回のチャンクの末尾数バイトをオーバーラップさせて読み込むか、あるいは検索時に「境界を跨ぐパターン」を考慮したロジックを組み込む必要がある。上記のサンプルコードは簡略化しているが、ミッションクリティカルな環境ではこの「境界問題」への対策が必須だ。
③ ファイルロックのハンドリング
ログファイルは、アプリケーション本体が書き込み中のものであることが多い。`ADODB.Stream` はデフォルトで読み取り専用として開こうとするが、書き込み中のファイルに対してアクセスする場合、OSレベルのファイルロックによって拒否されるケースがある。
実務では、`Open` メソッドのオプションや、リトライロジック（数ミリ秒待機して再試行）を検討すべきだ。
結論
巨大なデータを扱うとき、エンジニアに求められるのは「力技」ではなく「制御」だ。
`ReadAll` という甘えを捨て、メモリ消費を最小限に抑え、I/Oを最適化する。この「逆走パース」の思考プロセスこそが、君のスクリプトを単なる「自動化ツール」から「プロフェッショナルなエンジニアリング・ソリューション」へと昇華させるのだ。
