【テクニカル・上級編】【初心者向け】ReadAll・ReadLine・Readメソッドの挙動比較とファイルサイズに応じた使い分けガイド – VBScript (Visual Basic Scripting Edition)解析バイブル

VBScript (Visual Basic Scripting Edition)

2026.10.29

TextStreamの真実：ReadAll、ReadLine、Readの挙動差とメモリ管理の極限

TextStreamの真実：ReadAll、ReadLine、Readの挙動差とメモリ管理の極限

レガシーシステムの保守、あるいは大規模なデータ連携の自動化において、VBScript（FileSystemObject）は今なお現場の「脊髄」として機能している。しかし、多くのエンジニアがこの「脊髄」の扱いを誤り、突如として発生する `Out of Memory` エラーや、処理速度の致命的な低下に頭を抱えている。

VBScriptの `TextStream` オブジェクトが提供する読み込みメソッド——`ReadAll`、`ReadLine`、そして `Read(n)`。これらは一見、似たような機能を果たすように見えるが、その内部的なメモリ確保の挙動、およびI/Oオーバーヘッドの設計思想は全く異なる。

本稿では、単なるリファレンスの解説ではない。オブジェクトのライフサイクルとメモリ消費の動態を掌握し、ファイルサイズに応じた「最適解」を選択するためのアーキテクチャ的知見を提示する。

1. 三つのメソッドの特性とメカニズム

`FileSystemObject` を通じて取得される `TextStream` オブジェクトにおける、各メソッドの挙動を再定義する。

ReadAll：全量一括ロードの罠

`ReadAll` は、対象ファイルの内容をすべて一つの巨大な `BSTR`（Basic String）としてメモリ上に展開する。

メリット: メソッド呼び出し回数が最小限であり、ファイル全体を正規表現で一括走査する場合などの処理速度は極めて高い。
リスク: ファイルサイズが物理メモリ、あるいはVBScriptが扱える文字列長の限界に近づくと、メモリ割り当ての失敗によりスクリプトが即座にクラッシュする。また、文字列の操作（置換や分割）を行う際、一時的に元の文字列の数倍のメモリを消費する「メモリのスパイク」が発生する。

ReadLine：逐次行読み込みの安全性

`ReadLine` は、改行コード（CRLF/LF）を境界として、一行ずつ文字列を返却する。

メリット: メモリ消費が極めて安定している。ファイルが数GBであっても、メモリ上に保持されるのは「現在処理中の一行」のみである。
リスク: 行数が多いファイル（例えば数百万行のログファイル）に対して実行すると、メソッド呼び出しのオーバーヘッドが累積し、実行時間が指数関数的に増大する。

Read(n)：バッファ制御による精密操作

`Read(n)` は、指定した文字数 `n` だけを読み込む。

メリット: `ReadLine` の安全性と `ReadAll` の速度の「中間」を制御できる。固定長フォーマットの解析や、巨大なファイルのチャンク（塊）処理において、最もエンジニアのコントロールが効くメソッドである。
リスク: 適切なバッファサイズ（例：4KB, 64KB）を設計しなければ、単なる非効率な実装に陥る。

2. メモリ消費とパフォーマンスの相関図

ファイルサイズが増大した際の、各手法の挙動を以下に整理する。

メソッド	メモリ消費量	I/O 回数	適したファイルサイズ	主な用途
ReadAll	$\text{O}(\text{FileSize})$	極小	数MB以下	設定ファイル、小規模なテンプレート
ReadLine	$\text{O}(\text{MaxLineSize})$	大	全サイズ（行数依存）	CSV、ログファイル、構造化テキスト
Read(n)	$\text{O}(n)$	中	全サイズ（制御可能）	バイナリ混在、巨大な非構造化データ

3. 実装パターン：状況に応じた最適解

以下に、現場で即座に適用可能な、プロフェッショナルな実装パターンを示す。

パターンA：小規模設定ファイルの高速読み込み

設定ファイルのような、確実にメモリに収まることが保証されているファイルには `ReadAll` を使用する。

' --- Configuration Loader Pattern ---
Function LoadConfig(filePath)
    Dim fso, ts, content
    Set fso = CreateObject("Scripting.FileSystemObject")
    
    If Not fso.FileExists(filePath) Then
        Err.Raise 1, "LoadConfig", "File not found: " & filePath
    End If

    ' 読み取り専用でオープン
    Set ts = fso.OpenTextFile(filePath, 1) ' 1 = ForReading
    
    ' 全量を一括取得。小規模ならこれが最速
    content = ts.ReadAll
    
    ' オブジェクトの明示的な解放（重要）
    ts.Close
    Set ts = Nothing
    Set fso = Nothing
    
    LoadConfig = content
End Function

パターンB：大規模ログファイルの安全な解析

メモリを圧迫せず、かつ行単位のロジックを適用する場合、`ReadLine` によるストリーム処理が鉄則である。

' --- Large Log Processor Pattern ---
Sub ProcessLargeLog(filePath)
    Dim fso, ts, lineCount, currentLine
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set ts = fso.OpenTextFile(filePath, 1)

    lineCount = 0

    ' ファイルの終端(EOF)に達するまで一行ずつ処理
    Do Until ts.AtEndOfStream
        currentLine = ts.ReadLine
        lineCount = lineCount + 1
        
        ' 特定のキーワードが含まれる行のみ抽出する等のロジック
        If InStr(currentLine, "ERROR") > 0 Then
            ' ここでエラー処理を実行
            ' WScript.Echo "Line " & lineCount & ": " & currentLine
        End If
    Loop

    ts.Close
    Set ts = Nothing
    Set fso = Nothing
    
    WScript.Echo "Total lines processed: " & lineCount
End Sub

パターンC：巨大なデータのチャンク処理（高度な制御）

`ReadLine` では行が長すぎてメモリを食いつぶす、あるいは改行コードに依存したくない場合は、`Read(n)` によるバッファリングを行う。

' --- Chunked Stream Reader Pattern ---
Sub ProcessInChunks(filePath)
    Dim fso, ts, buffer, chunkSize
    chunkSize = 65536 ' 64KB バッファ
    
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set ts = fso.OpenTextFile(filePath, 1)

    Do Until ts.AtEndOfStream
        ' 指定したサイズ分だけ読み込む
        buffer = ts.Read(chunkSize)
        
        ' ここでバッファに対する高度な解析（例：部分的なパース）を行う
        ' 注意: バッファの境界でデータが分断される可能性があるため、
        ' 境界値の処理（残りの文字列を次に回す等）が必要になる場合がある
        Call AnalyzeBuffer(buffer)
    Loop

    ts.Close
    Set ts = Nothing
    Set fso = Nothing
End Sub

Sub AnalyzeBuffer(data)
    ' 解析ロジック（プレースホルダー）
End Sub

4. アーキテクトの視点：メモリ解放とCOMオブジェクトの生存期間

VBScriptにおいて、`Set obj = Nothing` は単なる作法ではない。これは、COM（Component Object Model）の参照カウントを減らし、リソースを OS に返還するための必須業務である。

特に、ループ内で `FileSystemObject` や `TextStream` を生成・破棄する場合、明示的な解放を怠ると、参照カウントがゼロにならず、メモリリークを引き起こす。これは、長時間稼働するWindowsサービスや、大量のバッチ処理を行うスクリプトにおいて、最終的にシステム全体を不安定化させる致命的な要因となる。

また、極めて巨大なファイルを扱う場合、FSOの限界を感じることもあるだろう。その時は、`ADODB.Stream` を検討せよ。`ADODB.Stream` は、バイナリモードでの読み込みや、より高度な文字コード（UTF-8等）の制御を可能にし、FSOよりも低レイヤーに近い操作を提供してくれる。

総括

`ReadAll` は、速度を優先するが、メモリの爆発を許容できる小規模ファイル限定。
`ReadLine` は、安全性を最優先するが、行数が多い場合のオーバーヘッドに注意。
`Read(n)` は、メモリと速度のバランスをエンジニアが完全に掌握したい時のための武器。

エンジニアが、対象となるデータの「物理的な重み」を理解したとき、コードは初めて真の堅牢性を獲得する。