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

VBScript (Visual Basic Scripting Edition)

2026.10.29

「動けばいい」は素人の思考だ。FSOの読み込みメソッドを使い分け、メモリを支配する極限の設計論

「動けばいい」は素人の思考だ。FSOの読み込みメソッドを使い分け、メモリを支配する極限の設計論

業務自動化の現場において、VBScript（FileSystemObject）は今なお強力な武器だ。しかし、多くの開発者が「とりあえず動くコード」を書き、本番環境で予期せぬメモリ不足（Out of Memory）や処理速度の低下に直面し、プロジェクトを停滞させている。

ファイル操作において、最も致命的なミスは「ファイルサイズとメモリ消費量の相関関係を無視すること」だ。

本稿では、FSOが提供する3つの読み込みメソッド——`ReadAll`、`ReadLine`、`Read`——の挙動を、アーキテクトの視点から徹底的に解剖する。君が「ただのスクリプト作成者」から「信頼されるエンジニア」へと脱皮するための、設計指針を伝授しよう。

1. 三者三様の挙動：リソース消費のメカニズム

FSOでテキストファイルを読み込む際、君が選択するメソッドは、単なる「読み方の違い」ではない。それは「メモリ空間をどのように占有するか」という設計判断そのものだ。

`ReadAll`：利便性と引き換えの「全メモリ占有」

`ReadAll`は、ファイルの内容をすべて一括で一つの巨大な文字列変数に格納する。

メリット: コードが極めて簡潔。ファイル全体を一度に正規表現で検索したい場合などに圧倒的な記述速度を誇る。
デメリット: ファイルサイズがメモリ（RAM）の空き容量に近づくと、即座にスクリプトはクラッシュする。また、巨大な文字列の確保自体がOSに負荷をかける。
適正: 設定ファイル（Config）、数KB〜数百KB程度の小さなマスタファイル。

`ReadLine`：スケーラビリティを担保する「逐次処理」

`ReadLine`は、改行コード（CRLF/LF）を見つけるまでを一行ずつ読み込む。

メリット: メモリ消費量が「一行の最大長」に依存するため、ファイルが1GBであろうと10GBであろうと、メモリ使用量はほぼ一定（定数時間 $O(1)$）に保てる。
デメリット: 行数が多い場合、ループ処理のオーバーヘッドが発生する。
適正: ログファイル、CSV、大規模なデータセット。実務における「基本戦略」はこれだ。

`Read`：精密機械のような「バイト/文字制御」

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

メリット: 改行を無視して、決まった文字数（固定長フォーマット）を正確に切り出せる。
デメリット: 文字数計算を自前で行う必要があり、ロジックが複雑化しやすい。
適正: 固定長テキスト、バイナリに近い構造を持つ特殊なデータ形式。

2. メモリ消費量とファイルサイズの相関図

設計判断を下すためのマトリクスを提示する。これを頭に叩き込んでおけ。

メソッド	ファイルサイズ	メモリ消費量	推奨される用途	リスク
ReadAll	極小 ( < 1MB )	ファイルサイズと同等	設定値の取得、小規模解析	メモリ枯渇 (OOM)
ReadLine	中〜大 ( > 1MB )	極めて低い (一定)	ログ解析、CSV処理	ループ回数による速度低下
Read	特殊	指定した文字数分	固定長データの抽出	読み込み位置の管理ミス

3. 【実践】プロダクション品質のコード実装

ここからは、現場でそのまま使える、堅牢な設計に基づいたコード例を示す。
単に読み込むだけでなく、「ファイルが存在するか」「読み取り権限があるか」といった例外処理を組み込むのがプロの仕事だ。

悪い例（アンチパターン）

' --- 初心者がやりがちな、壊れやすいコード ---
Set fso = CreateObject("Scripting.FileSystemObject")
Set ts = fso.OpenTextFile("C:\large_log.txt", 1)
strData = ts.ReadAll ' ← ここで巨大なファイルだと死ぬ
ts.Close

プロフェッショナルな例（堅牢な設計）

以下のコードは、ファイルサイズを事前に判定し、適切なメソッドを選択する「戦略的読み込み」のテンプレートだ。

''' <summary>
''' ファイルの性質に応じて最適な読み込みを行う高信頼性関数
''' </summary>
''' <param name="filePath">対象ファイルのフルパス</param>
''' <returns>ファイル内容（ReadAllの場合）または処理結果</returns>
Function SmartReadFile(filePath)
    Dim fso, ts, fileSize, content
    Set fso = CreateObject("Scripting.FileSystemObject")

    ' 1. 存在チェック（ガード節）
    If Not fso.FileExists(filePath) Then
        Err.Raise 1, "SmartReadFile", "Target file not found: " & filePath
    End If

    ' 2. ファイルサイズの取得
    fileSize = fso.GetFile(filePath).Size

    ' 3. 戦略的分岐
    ' 1MB (1,048,576 bytes) を閾値として判断
    If fileSize < 1048576 Then
        ' 小規模ファイルならReadAllで高速化
        Set ts = fso.OpenTextFile(filePath, 1) ' 1 = ForReading
        content = ts.ReadAll
        ts.Close
        SmartReadFile = content
    Else
        ' 大規模ファイルならReadLineでメモリを保護
        ' ※ここでは例として、一行ずつ処理して結果を返す構造にする
        ' 実際の実務では、ここで「行ごとの解析ロジック」を呼び出す
        Set ts = fso.OpenTextFile(filePath, 1)
        
        ' 【重要】大規模ファイルで文字列結合 (str = str & line) は厳禁！
        ' 文字列の再割り当てが頻発し、処理時間が指数関数的に増大する。
        ' 本来は、ここで配列に格納するか、直接DBや別ファイルへ書き出す。
        
        Do Until ts.AtEndOfStream
            Dim line
            line = ts.ReadLine
            ' --- ここに解析ロジックを実装 ---
            ' 例: Debug.Print line (VBScriptではWScript.Echo)
            ' ----------------------------
        Loop
        
        ts.Close
        SmartReadFile = "PROCESSED_SUCCESSFULLY"
    End If

    Set ts = Nothing
    Set fso = Nothing
End Function

' --- 実行セクション ---
On Error Resume Next ' エラーハンドリングの開始
    Dim result
    result = SmartReadFile("C:\Logs\server_log.txt")
    
    If Err.Number <> 0 Then
        WScript.Echo "Critical Error: " & Err.Description
    Else
        WScript.Echo "Process Completed: " & result
    End If
On Error GoTo 0

4. アーキテクトからの最終警告：文字列結合の罠

最後に、これだけは絶対に忘れるな。
`ReadLine` を使ってメモリを節約しているつもりでも、ループ内で以下のような記述をしていたら、君の設計は台無しだ。

' 致命的なパフォーマンス低下を招く書き方
Do Until ts.AtEndOfStream
    line = ts.ReadLine
    bigString = bigString & line & vbCrLf ' ← これが「死のコード」だ
Loop

VBScriptにおいて、文字列はイミュータブル（不変）に近い振る舞いをする。`&` で結合するたびに、コンピュータはメモリ上に「新しい、より大きな領域」を確保し、古い内容をコピーするという、極めて重い作業を繰り返す。ファイルが大きくなればなるほど、処理速度は指数関数的に（$O(n^2)$ で）悪化していく。

解決策：
1. 可能であれば、読み込んだ行をその場で処理（DB保存やファイル出力）し、メモリに溜め込まない。
2. どうしてもメモリに保持する必要があるなら、一度 `Array` に格納し、最後に `Join` 関数で一括結合せよ。

まとめ

`ReadAll` は「小規模な設定ファイル」専用。
`ReadLine` は「大規模なログ・データ」の標準。
`Read` は「固定長フォーマット」の外科手術用。
文字列の累積結合は、メモリとCPUを破壊する。

設計とは、妥協ではなく、「リソースの配分を決めること」だ。この知見を武器に、堅牢な自動化システムを構築してほしい。