【キュー構造活用】System.Collections.Queue を利用した FIFO型タスク処理パイプラインの構築
レガシーシステムの維持、あるいはWindows環境における軽量なバッチ処理の自動化において、VBScript（WSH）は今なお現役のインフラストラクチャとして静かに、しかし確実に稼働し続けている。
しかし、安易に組まれたVBScriptは、膨大なデータの並行処理や非同期的なイベントドリブン処理において、メモリリークや処理順序の崩壊という致命的な破綻を引き起こす。
今回は、VBScriptの限界を突破し、堅牢なエンタープライズ品質のタスク処理を実現するための極限の知見を公開する。.NET Frameworkの `System.Collections.Queue` をVBScriptからブリッジし、完全なFIFO（First-In, First-Out：先入れ先出し）型タスクパイプラインを構築する手法を解説する。
—
1. なぜVBScriptで「Queue構造」が必要なのか？
VBScriptのネイティブ配列（`Array`）やDictionaryオブジェクトは、データの蓄積には向いていても、「順序を保証した動的な出し入れ（Enqueue / Dequeue）」を高速かつ安全に行うようには設計されていない。特に、配列の要素を動的にリサイズする `ReDim Preserve` をループ内で多用すると、メモリの再割り当てとコピーが頻発し、O(N^2) の計算量に起因する深刻なパフォーマンス劣化（メモリフラグメンテーション）を引き起こす。
ここに `.NET Framework（COM互換クラス）` の `System.Collections.Queue` を導入する。
これにより、以下のメリットがもたらされる。
- O(1) の高速なキュー操作: データの追加（Enqueue）と取り出し（Dequeue）が定数時間で実行される。
- 厳密な順序保証: 多重ループや非同期的なイベント発火が絡む複雑な処理でも、投入された順序（FIFO）が絶対に崩れない。
- ガベージコレクションの恩恵: .NETのマネージドメモリ上で動作するため、VBScript側のメモリ管理の負担が軽減される。
—
2. アーキテクチャ設計：堅牢なパイプラインの全体像
今回構築するタスク処理パイプラインは、以下の3層構造を持つ。
1. データプロデューサー（生産者）: 処理すべきタスク（ファイルパス、APIのエンドポイント、DBのレコードIDなど）を動的に生成し、キューに投入（Enqueue）する。
2. キューマネージャー（緩衝地帯）: `System.Collections.Queue`。メモリ上でタスクを安全に保持し、順序を制御する。
3. データコンシューマー（消費者）: キューからタスクを1件ずつ安全に取り出し（Dequeue）、実際の業務処理を実行する。
—
3. 実装コード：System.Collections.Queue 活用パイプライン
以下のコードは、エラーハンドリング、オブジェクトのライフサイクル管理、パフォーマンス最適化を極限まで高めた実用スクリプトである。そのまま `.vbs` ファイルとして保存して実行可能である。
Option Explicit
‘ ==============================================================================
‘ スクリプト名: TaskPipelineEngine.vbs
‘ 概要: System.Collections.Queue を利用した FIFO型タスク処理パイプライン
‘ 著者: チーフアーキテクト
‘ ==============================================================================
Main
Sub Main()
Dim objQueue
Dim i, taskData, processedCount
WScript.Echo “=== タスク処理パイプライン 起動 ===”
‘ 1. .NETのQueueオブジェクトの生成
‘ ※レジストリ依存を排除するため、CreateObject経由でCOM Callable Wrapperを利用
Set objQueue = CreateObject(“System.Collections.Queue”)
On Error Resume Next
‘ ==========================================================================
‘ フェーズ 1: プロデューサー（タスクの投入 / Enqueue）
‘ ==========================================================================
WScript.Echo vbCrLf & “[Phase 1] タスクの生成とキューイングを開始…”
For i = 1 To 10
taskData = “Task_ID_” & Right(“00” & i, 3) & “_DataPath: C:\Logs\target_” & i & “.log”
objQueue.Enqueue(taskData)
WScript.Echo ” -> Enqueued: ” & taskData
Next
WScript.Echo “総タスク数 (Queue Count): ” & objQueue.Count
‘ ==========================================================================
‘ フェーズ 2: コンシューマー（タスクの順次処理 / Dequeue）
‘ ==========================================================================
WScript.Echo vbCrLf & “[Phase 2] パイプライン処理（FIFO実行）を開始…”
processedCount = 0
‘ キューが空になるまでループ
Do While objQueue.Count > 0
‘ 先頭のデータを取得し、同時にキューから削除する
taskData = objQueue.Dequeue()
If Err.Number <> 0 Then
WScript.Echo “[CRITICAL ERROR] Dequeue失敗: ” & Err.Description
Err.Clear
Exit Do
End If
‘ — 実業務処理のシミュレーション —
Call ExecuteBusinessLogic(taskData)
processedCount = processedCount + 1
Loop
On Error GoTo 0
WScript.Echo vbCrLf & “=== パイプライン処理完了 ===”
WScript.Echo “処理成功件数: ” & processedCount & ” 件”
‘ ==========================================================================
‘ フェーズ 3: 厳格なメモリ解放（ライフサイクル管理）
‘ ==========================================================================
‘ VBScriptにおけるCOMオブジェクトの参照破棄は明示的に行うのが鉄則
objQueue.Clear()
Set objQueue = Nothing
WScript.Echo “リソースの解放が正常に完了しました。”
End Sub
‘ ——————————————————————————
‘ 業務ロジック実行関数
‘ ——————————————————————————
Sub ExecuteBusinessLogic(ByVal task)
‘ ここに実際のファイル操作、API通信、DB書き込み等を記述する
‘ 例としてコンソール出力と擬似的なウェイトを置く
WScript.Echo ” [Executing] 処理中 –> ” & task
‘ パフォーマンス調整・CPUスパイク防止のための極小ウェイト（必要に応じて）
‘ WScript.Sleep 100
End Sub
—
4. チーフアーキテクトが解説する「極限の知見」
① .NET COM互換オブジェクトのメモリ管理とライフサイクル
VBScriptから `CreateObject(“System.Collections.Queue”)` を呼び出した瞬間、背後では .NET FrameworkのCLR（Common Language Runtime）がホストされ、COM Callable Wrapper (CCW) を通じてオブジェクトがインスタンス化される。
ここで注意すべきは、VBScript側で `Set obj = Nothing` を実行しただけでは、マネージドヒープ上のメモリが即座に解放されるとは限らないという点だ。
大規模なバッチ処理で何万回もオブジェクトの生成・破棄を繰り返す場合、ループ内でインスタンスを乱用してはならない。上記コードのように、「キュー自体は1度だけ生成し、内部の `.Clear()` メソッドで要素を全削除してから `Nothing` を代入する」というライフサイクル設計が、メモリリークを防ぐ唯一にして最善の防衛策となる。
② エラーハンドリングとパイプラインの頑健性 (Resilience)
レガシー環境における最大の敵は「予期せぬ外部要因（ファイルのロック、ネットワーク切断など）」である。
キューから `Dequeue` した後にエラーが発生した場合、処理中のタスクがロストする危険性がある。
本番運用において極めて高い信頼性を求める場合は、`Dequeue` の代わりに、一度キューの先頭を覗き見る（しかし削除はしない）ようなラッパー構造、あるいは処理失敗時に「リトライ用デッドレターキュー（Dead Letter Queue）」へタスクを退避させる高度なステート管理を実装すべきである。
③ スレッドセーフティに関する現実解
`System.Collections.Queue` 自体はマルチスレッド環境においてスレッドセーフではない（`Synchronized` ラッパーメソッドが存在するものの、VBScriptのシングルスレッド実行モデルにおいては基本的に競合が発生しない）。
WSH環境（cscript.exe）で複数プロセスから同一のキューを操作させるような狂気じみた設計は避け、「1つのCscriptプロセス＝1つの独立したパイプライン」として完結させ、プロセス間のデータ授受が必要な場合はファイルやデータベースを介在させるのが、VBScriptを安全に運用するための黄金律である。
—
総括
VBScriptは「古い言語」として片付けられがちだが、OSの深部（Windows Script Host）とダイレクトに結合し、追加のインストールパッケージなしで動作するという唯一無二の機動性を持っている。
今回解説した `System.Collections.Queue` を用いたFIFOパイプラインパターンをマスターすれば、混沌としたレガシーバッチ処理を、予測可能で堅牢なエンタープライズ・ワークフローへと昇華させることが可能だ。
現場のインフラストラクチャを支えるエンジニア諸賢の武器として、この知見を最大限に活用してほしい。
