ネットワークの「迷い」を断つ。WMIによるメトリック制御で実現する極限の安定通信
現場でよくある話だ。「有線LANを繋いでいるのに、Wi-Fiの方が優先されてしまい、社内サーバーへのレスポンスが極端に遅い」。あるいは「VPN接続時にルーティングが混乱する」。
これらはOSの「自動メトリック」任せにしていることが原因だ。VBScriptとWMI（Windows Management Instrumentation）を駆使すれば、この「ネットワークの迷い」を強制的に矯正できる。今回は、業務自動化の現場で即戦力となる、ネットワーク優先度制御の極意を伝授する。
—
1. なぜ「自動メトリック」を信じてはいけないのか
Windowsのルーティングテーブルにおける「メトリック値」は、低いほど優先される。自動メトリックはOSが通信速度を推測して割り当てるが、これが時として裏目に出る。
特にノートPCをドックに接続した際や、仮想ネットワークアダプタが乱立する環境下では、OSの判断は信用に値しない。エンジニアの責務は、OSの気まぐれを許容することではなく、通信経路を「確定させる」ことにある。
2. WMI操作における「禁じ手」と「鉄則」
`Win32_NetworkAdapterConfiguration` を叩く際、以下の鉄則を守らないとスクリプトは不安定な挙動を見せる。
- 権限の壁: ネットワーク設定の変更は、例外なく「管理者権限」が必要だ。スクリプト実行時に `WScript.Shell` の `Run` を使い、`runas` で昇格させるか、タスクスケジューラで「最上位の権限で実行」させる設計が必須である。
- 非同期の罠: `SetIPConnectionMetric` メソッドは戻り値を返すだけで、反映にはOS側の処理時間がかかる。連続して設定を行う場合は、適度な待機（`WScript.Sleep`）を挟むのが定石だ。
- フィルタリングの重要性: 全てのアダプタを対象にするのは愚策である。`IPEnabled = True` であること、かつ特定の名前（”Wi-Fi”, “Ethernet”）を持つものだけを操作対象に絞り込むこと。
—
3. 実践：ネットワーク優先度一括設定スクリプト
このコードは、環境に合わせてメトリック値を強制上書きする。保守性を考慮し、設定値を変数で管理する構成にしている。
‘ ネットワークメトリック自動最適化スクリプト
‘ 実行には管理者権限が必要です。
Option Explicit
‘ — 設定エリア —
‘ 値が小さいほど優先度が高い（例: 有線=10, Wi-Fi=20）
Const METRIC_ETHERNET = 10
Const METRIC_WIFI = 20
‘ ——————
Dim objWMIService, colAdapters, objAdapter, errResult
Set objWMIService = GetObject(“winmgmts:\\.\root\cimv2”)
‘ IPが有効なアダプタのみを取得
Set colAdapters = objWMIService.ExecQuery(“SELECT FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = True”)
For Each objAdapter In colAdapters
‘ アダプタ名による判定（環境に合わせて調整すること）
If InStr(LCase(objAdapter.Description), “ethernet”) > 0 Or InStr(LCase(objAdapter.Description), “gigabit”) > 0 Then
errResult = objAdapter.SetIPConnectionMetric(METRIC_ETHERNET)
WScript.Echo “Ethernet メトリック設定: ” & errResult
ElseIf InStr(LCase(objAdapter.Description), “wi-fi”) > 0 Or InStr(LCase(objAdapter.Description), “wireless”) > 0 Then
errResult = objAdapter.SetIPConnectionMetric(METRIC_WIFI)
WScript.Echo “Wi-Fi メトリック設定: ” & errResult
End If
Next
‘ オブジェクトの解放はメモリ管理の基本
Set colAdapters = Nothing
Set objWMIService = Nothing
—
4. プロダクション環境へデプロイする際の注意点
このスクリプトを「ツール」として完成させるには、以下の視点が欠かせない。
1. ログ出力の設計: `WScript.Echo` はGUI環境では無視されることが多い。実務では `Scripting.FileSystemObject` を使い、`C:\Logs\NetworkConfig.log` などに実行時刻と結果を追記するように改良すべきだ。
2. エラーハンドリング: `errResult` が `0` 以外の場合、その原因はNICのドライバ制限である可能性が高い。`Select Case errResult` でエラー番号に応じた詳細なログを吐くようにしておけば、現場からの「繋がらない」という問い合わせに即座に対応できる。
3. データベースとの連携: 複数の拠点を持つ企業であれば、メトリック値をハードコーディングせず、INIファイルや共有フォルダのCSVから読み込む構成にするのが、真のエンジニアの流儀である。
最後に：自動化の真髄
「設定を変える」ことは容易い。しかし、「なぜその設定が必要なのか」「変更が失敗したときにどうリカバリするか」までをコードに落とし込むのが、我々自動化エンジニアの価値だ。
このスクリプトを単なる「コピペツール」で終わらせず、あなたの現場のネットワークインフラを支える「インテリジェントな自律システム」の一部へと進化させてほしい。成功を祈る。
