【指数バックオフ再試行】MSXML2.ServerXMLHTTP によるHTTP通信障害の自動リトライとバックオフ制御の実装
レガシーシステムの深部、あるいは厳格なオンプレミス環境において、VBScript（Visual Basic Scripting Edition）とWSH（Windows Script Host）はいまだにインフラの血液として機能している。モダンな言語が敬遠される環境であっても、Windows標準コンポーネントだけで完結するVBScriptは、タスクランペッターやバッチ処理の自動化において代えがたい存在だ。
しかし、ネットワークは本質的に信頼できない。社内APIや外部SaaSへの連携において、ルータの瞬断、ロードバランサーのタイムアウト、あるいはリクエスト過多による `429 Too Many Requests` や `500 Internal Server Error` は日常茶飯事である。
ここで「一度失敗したら終わり」の脆弱なスクリプトを書くか、あるいはただ思考停止で同じ間隔でループする「愚直なリトライ」を実装するか。シニアエンジニアであれば、後者がネットワークの輻輳（ふくそう）をさらに悪化させる悪手であることを知っているはずだ。
本稿では、`MSXML2.ServerXMLHTTP.6.0` を用い、「指数バックオフ（Exponential Backoff）とジッター（Jitter）」を完備した、エンタープライズグレードの堅牢なHTTP通信モジュールをVBScriptで実装する極限の知見を公開する。
—
1. なぜ「MSXML2.ServerXMLHTTP.6.0」なのか
レガシーなVBScriptのサンプルコードにはいまだに `Microsoft.XMLHTTP` や `MSXML2.ServerXMLHTTP.3.0` が散見されるが、現代のアーキテクチャにおいてこれらは選択肢に入らない。
- セキュリティプロトコル: 3.0系はデフォルトでTLS 1.2/1.3の強制やSNI（Server Name Indication）の制御において近代的なWeb APIの要件を満たさない場合がある。
- スレッドモデル: `ServerXMLHTTP` はサーバーサイドでの利用を想定して設計されており、非同期通信の制御やタイムアウト設定（`setTimeouts`）が確実に機能する。
必ず `MSXML2.ServerXMLHTTP.6.0` を明示的に指定し、プロキシやSSLのハンドシェイクエラーを回避する下地を作ること。
—
2. 指数バックオフとジッター制御の理論
ネットワーク障害が発生した際、即座にリクエストを再送すると、サーバーの復旧を妨げる「ドトール効果（Thundering Herd Problem）」を引き起こす。これを防ぐのが指数バックオフだ。
待機時間 $T$ は試行回数 $n$ に対して指数関数的に増加する。
$$T = \text{Base} \times 2^{n-1}$$
さらに、複数のクライアントが同時にリクエスト失敗した場合、一斉に同じタイミングで再試行するのを防ぐために「ジッター（ランダムな揺らぎ）」を付加する。VBScriptの `Rnd` 関数を組み合わせることで、工業用レベルの耐障害性をスクリプトに宿すことができる。
—
3. 実装コード：堅牢なHTTPリトライ・モジュール
以下のコードは、エラーハンドリング、タイムアウト設定、HTTPステータスコードの厳密な判定、そして指数バックオフによる待機をカプセル化した実用スクリプトである。
Option Explicit
‘ ==============================================================================
‘ 処理名: HTTP POST/GET 指数バックオフ自動リトライモジュール
‘ 依存関係: MSXML2.ServerXMLHTTP.6.0
‘ ==============================================================================
Private Const c_MaxRetryCount = 4 ‘ 最大リトライ回数
Private Const c_BaseDelayMs = 1000 ‘ 基本待機時間 (1秒)
Private Const c_TimeoutResolve = 5000 ‘ 決議タイムアウト (ミリ秒)
Private Const c_TimeoutConnect = 5000 ‘ 接続タイムアウト (ミリ秒)
Private Const c_TimeoutSend = 10000 ‘ 送信タイムアウト (ミリ秒)
Private Const c_TimeoutReceive = 15000 ‘ 受信タイムアウト (ミリ秒)
Sub Main()
Dim targetUrl, requestBody, responseText, statusCode
targetUrl = “https://api.example.com/v1/data-submit”
requestBody = “{“”action””:””sync””,””id””:1001}”
‘ 乱数ジェネレータの初期化（ジッター生成のため必須）
Randomize
Dim isSuccess
isSuccess = HttpPostWithBackoff(targetUrl, requestBody, responseText, statusCode)
If isSuccess Then
WScript.Echo “通信成功 [Status: ” & statusCode & “]”
WScript.Echo “Response: ” & responseText
Else
WScript.Echo “致命的エラー: 最大リトライ回数を超過しました。処理を中断します。”
End If
End Sub
‘ ——————————————————————————
‘ 指数バックオフ付き HTTP POST 実行関数
‘ ——————————————————————————
Function HttpPostWithBackoff(ByVal url, ByVal body, ByRef outResponseText, ByRef outStatusCode)
Dim attempt, delay, http, success
attempt = 0
success = False
Do While attempt < c_MaxRetryCount
attempt = attempt + 1
' オブジェクトのライフサイクル管理: ループごとにインスタンスを完全に破棄・再生成する
' ※COMコンポーネントのメモリリークやステート残留を防ぐための鉄則
Set http = Nothing
On Error Resume Next
Set http = CreateObject("MSXML2.ServerXMLHTTP.6.0")
If Err.Number <> 0 Then
WScript.Echo “[警告] ServerXMLHTTP.6.0 のインスタンス化に失敗: ” & Err.Description
Err.Clear
Exit Do
End If
With http
‘ タイムアウトの設定 (resolve, connect, send, receive)
.setTimeouts c_TimeoutResolve, c_TimeoutConnect, c_TimeoutSend, c_TimeoutReceive
.Open “POST”, url, False
.setRequestHeader “Content-Type”, “application/json; charset=utf-8”
.setRequestHeader “Accept”, “application/json”
‘ リクエスト送信
.send body
If Err.Number <> 0 Then
‘ ネットワーク層レベルのエラー (DNS名前解決失敗、接続拒否など)
WScript.Echo “[試行 ” & attempt & “/” & c_MaxRetryCount & “] ネットワーク例外発生: ” & Err.Description
Err.Clear
Else
outStatusCode = .status
‘ ステータスコードによる判定
If IsRetryableStatus(outStatusCode) Then
WScript.Echo “[試行 ” & attempt & “/” & c_MaxRetryCount & “] リトライ対象のステータスコード検知: ” & outStatusCode
ElseIf outStatusCode >= 200 And outStatusCode < 300 Then
' 成功
outResponseText = .responseText
success = True
Exit Do
Else
' リトライしないクライアントエラー (400, 401, 403, 404等)
WScript.Echo "[警告] リトライ対象外のエラーコードを受信: " & outStatusCode
outResponseText = .responseText
Exit Do
End If
End If
End With
On Error GoTo 0
' 最大試行回数に達していなければバックオフ待機
If attempt < c_MaxRetryCount Then
delay = CalculateBackoffDelay(attempt)
WScript.Echo " -> ” & delay & “ミリ秒後に再試行します…”
WScript.Sleep delay
End If
Loop
Set http = Nothing
HttpPostWithBackoff = success
End Function
‘ ——————————————————————————
‘ リトライすべきHTTPステータスコードか判定
‘ ——————————————————————————
Function IsRetryableStatus(ByVal statusCode)
Select Case statusCode
Case 429, 500, 502, 503, 504
IsRetryableStatus = True
Case Else
IsRetryableStatus = False
End Select
End Function
‘ ——————————————————————————
‘ 指数バックオフ ＋ ジッター値の計算
‘ ——————————————————————————
Function CalculateBackoffDelay(ByVal attempt)
Dim exponentialBase, jitter, finalDelay
‘ 2^(attempt-1) BaseDelay
exponentialBase = c_BaseDelayMs (2 ^ (attempt – 1))
‘ ジッターの付加 (0.8 ～ 1.2 の係数を乗算して同期を分散させる)
‘ Rnd は 0 以上 1 未満の値を返す
jitter = 0.8 + (Rnd 0.4)
finalDelay = Int(exponentialBase jitter)
‘ 安全装置: 最大でも 30秒 (30000ms) を上限とする
If finalDelay > 30000 Then
finalDelay = 30000
End If
CalculateBackoffDelay = finalDelay
End Function
‘ エントリポイントの実行
Main
—
4. チーフアーキテクトが解説するコードの急所と極意
① COMオブジェクトのライフサイクル管理（メモリ最適化）
VBScriptの `ServerXMLHTTP` をループ内で使い回す（`Open` と `Send` を何回も同じインスタンスで叩く）ことは、内部バッファの肥大化やコネクションプールの異常な挙動、さらにはメモリリークを引き起こす最大の温床となる。
上記のコードでは、ループの先頭で必ず `Set http = Nothing` を行い、インスタンスを完全に破棄して再生成している。パフォーマンスへの影響は微小である一方、レガシー環境特有の「リソース枯渇クラッシュ」を完全に予防できる。
② `On Error Resume Next` の厳格なスコープ管理
VBScriptの例外処理は非常にプリミティブである。`On Error Resume Next` を宣言した後は、エラーが発生した瞬間に `Err.Number` をチェックし、処理が終わったら即座に `On Error GoTo 0` でデフォルト挙動に戻さなければならない。グローバルにエラーを無視するコードは、デバッグ不能なゴーストバグの元凶となる。
③ クライアントエラー（4xx系）とサーバーエラー（5xx系）の厳密な切り分け
すべてのHTTPエラーをリトライしてはならない。例えば `400 Bad Request` や `404 Not Found` をリトライしても、リクエスト内容やURLが間違っている限り永遠に失敗し、無駄にAPIサーバーを攻撃し続けることになる。
リトライ対象は、一時的な負荷や過負荷を示す `429 (Too Many Requests)` および `5xx系 (Server Error)` に限定するのが、システムインテグレーションの鉄則である。
—
5. 総括
VBScriptは「古い言語」として片付けられがちだが、OSの標準機能だけで動作し、外部ランタイムのインストールすら不要という圧倒的な機動力を持つ。その特性ゆえに、インフラストラクチャの自動化や、基幹システムを繋ぐ泥臭いバッチ処理の現場では今後も生き残り続けるだろう。
だが、レガシーな環境だからこそ、書くコードにはモダンなアーキテクチャの知見（耐障害性、指数バックオフ、適切なリソース管理）を宿さなければならない。本稿で示した実装をあなたのシステムに組み込むことで、夜間バッチのネットワークエラーによる「翌朝の絶望」を過去のものにできるはずだ。エンジニアリングの美しさは、コードの古さではなく、その堅牢さに宿る。
