VBScript廃止に備えるVBA・社内ツール点検ガイド

エグゼクティブサマリー

2026年4月時点で、MicrosoftはVBScriptを段階的に廃止する方針を公開しており、Windows 11 バージョン 24H2 ではまず Feature on Demand として既定有効、次の段階では既定無効、最終段階では将来のWindowsリリースから削除する計画を示しています。つまり、いま本当にやるべきことは「全面書き換え」より先に、「どこがVBScript依存なのかを可視化すること」です。

VBA・Excelマクロの現実的な論点は大きく二つです。ひとつは .vbs を外部実行しているケース、もうひとつは VBScript.RegExp のようなVBScript型ライブラリ参照です。後者については、Office version 2508（Build 19127.20154）以降でRegExpクラスがVBEに標準搭載され、少なくともRegExp依存の一部は移行しやすくなりました。一方で、旧Officeクライアントが残る混在環境では、同じVBAでも動く端末と動かない端末が発生しやすくなります。

移行を難しくするのは、VBScriptそのものより「周辺の運用」です。たとえばExcelから powershell.exe を起動するように置き換えても、攻撃面の減少ルールである「Officeアプリによる子プロセス作成のブロック」や「OfficeマクロからのWin32 API呼び出しブロック」、AppLocker、App Control for Business、PowerShell実行ポリシー、署名運用、MOTW付きファイルのマクロ制御に引っかかると、本番では動きません。移行計画はコード変換だけでなく、ポリシーと署名、ログ監査まで含めて設計すべきです。

最短ルートは、棚卸し → 静的検出 → 実行ログ収集 → 代替先の選定 → テスト → 段階展開です。本記事では、その順で実務向けに整理します。

なお、この記事に登場するコードは、実行・テストできるサンプル一式（PowerShell 監査スクリプト、置換サンプル、VBA・Office Scripts の参照用コード、Pester テスト）として GitHub で公開しています。

vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide - komurasoft-blog-samples (GitHub)

変化の整理

まず押さえるべきなのは、今回の論点が「VBAが廃止される」話ではないことです。Microsoftが公開しているのはあくまでVBScriptの段階的廃止であり、VBAプロジェクトへの影響は、主に 外部 .vbs の実行 と VBScript系ライブラリ参照 に集中します。Microsoft 365 Developer Blog でも、VBAからの .vbs 実行と VBScript.RegExp 利用が代表的な影響点として整理されています。

実務上の優先順位は、この表の形で考えると判断しやすくなります。

この優先順位は、Windows側のVBScript廃止計画、公式の検出戦略、ASR/AppLocker/App Controlの仕様を踏まえた実務判断です。

RegExpだけは少し事情が違います。Office version 2508 以降では、VBE側にRegExpクラスが標準で含まれるため、RegExp用途に限れば「VBScript依存の一部をOffice更新で解消できる」 ようになりました。ただし、これは旧Officeや更新チャネルが遅い環境、混在環境、古い端末イメージが残る組織で自動的に解決する話ではありません。「Officeの更新」と「Windowsの段階切替」の両方を台帳に入れること が重要です。

棚卸しの進め方

棚卸しは、ファイル名の検索だけでは足りません。最低でも、次の10観点を案件単位・ツール単位・業務単位で列として持つことを勧めます。

• ① VBScript依存箇所の検出方法 ファイル検索、コード解析、ログ分析を分けて記録する。
• ② VBA内での CreateObject / GetObject / Execute / ExecuteGlobal 等の利用 依存先が文字列に隠れるため、静的検索漏れが起きやすい。
• ③ Excelマクロでの外部スクリプト呼び出し WScript.Shell、Shell 関数、wscript.exe / cscript.exe、.vbs / .js / .ps1 を別々に持つ。
• ④ 社内バッチ・ツールのスクリプト依存 Scheduled Task、GPO、Intune、共有フォルダ上の運用スクリプト、インストーラーを含める。
• ⑤ セキュリティ・権限・署名・ポリシー AppLocker、App Control for Business、ASR、PowerShell実行ポリシー、デジタル署名、管理者権限の要否。
• ⑥ 代替技術と移行コスト比較 VBAネイティブ、PowerShell、.NET/VSTO、Office Scripts、Power Automateで比較する。
• ⑦ テスト計画 単体、結合、ユーザ受入、ポリシー適用後の再試験を分ける。
• ⑧ 運用手順とロールバック 何を戻せば復旧するのか、どこまで自動化するのかを明記する。
• ⑨ 互換性とパフォーマンス Officeバージョン差、32/64bit、端末性能、ログ収集負荷、クラウドフローのタイムアウト。
• ⑩ サンプル移行ケーススタディ 現場への説明に使える代表例を1つ作っておく。

この10項目のうち、特にGPO、Scheduled Task、Intune配布スクリプト、MSI Custom Action、Sysmon/AppLocker/App Controlによる検知は、Microsoftの公式ガイダンスでも重点領域として明示されています。

移行全体の流れは、図のように考えるとブレません。

flowchart TD
    A[資産棚卸し] --> B{依存の種類}
    B -->|外部 .vbs 実行| C[PowerShell または VBAネイティブへ置換]
    B -->|VBScript.RegExp| D[Office 2508+ の組み込み RegExp へ整理]
    B -->|GPO / タスク / MSI| E[中央管理設定と配布物を修正]
    B -->|不明・埋もれた依存| F[Sysmon / AppLocker / App Control で実行ログ収集]
    C --> G[単体試験]
    D --> G
    E --> H[結合試験]
    F --> H
    H --> I[監査モードでパイロット展開]
    I --> J[VBScript FOD の段階的無効化]

この順番にしておくと、「まず書き換えたのに、後からGPOやASRで落ちた」という典型的なやり直しをかなり減らせます。

実践的な検出とコード例

ファイル検索と構成情報の洗い出し

Microsoftの検出ガイダンスでは、C:\Users、C:\ProgramData、C:\Scripts などの用途が明確なパスを優先して .vbs を再帰検索し、GPO、Scheduled Task、Intune配布スクリプト、MSIパッケージも別系統で確認することが推奨されています。Sysmonの vbscript.dll 監視は有効ですが、Image Load監視はログ量と運用負荷が大きいため、まず小規模パイロットで検証すべきです。

# 端末・共有フォルダ上のスクリプト依存をざっくり洗う
$paths = @("C:\Users", "C:\ProgramData", "C:\Scripts")
$patterns = @(
  'wscript\.exe',
  'cscript\.exe',
  '\.vbs(\s|$)',
  'VBScript\.RegExp',
  'WScript\.Shell',
  'CreateObject\("VBScript\.RegExp"\)',
  'ExecuteGlobal'
)

$hits = foreach ($path in $paths) {
  if (Test-Path $path) {
    Get-ChildItem -Path $path -Recurse -File `
      -Include *.vbs,*.ps1,*.bat,*.cmd,*.wsf,*.hta,*.txt `
      -ErrorAction SilentlyContinue |
      Select-String -Pattern $patterns -AllMatches |
      Select-Object Path, LineNumber, Line
  }
}

$hits | Export-Csv .\vbscript-dependency-hits.csv -NoTypeInformation -Encoding UTF8

次に、タスクスケジューラを洗います。社内ツールはファイルよりも、タスク定義の中に wscript.exe / cscript.exe / .vbs が埋まっている ことが多いからです。

# Scheduled Task から VBScript 呼び出しを抽出
Get-ScheduledTask | ForEach-Object {
  foreach ($a in $_.Actions) {
    if ($a.Execute -match 'wscript|cscript|mshta' -or $a.Arguments -match '\.vbs\b') {
      [pscustomobject]@{
        TaskName  = $_.TaskName
        TaskPath  = $_.TaskPath
        Execute   = $a.Execute
        Arguments = $a.Arguments
      }
    }
  }
} | Export-Csv .\task-vbscript-dependencies.csv -NoTypeInformation -Encoding UTF8

VBAコード解析

VBA側は、参照設定だけ見ても不十分 です。CreateObject や GetObject は文字列でCOMを起動できるので、参照設定に何も出なくても依存していることがあります。MicrosoftのVBA/Officeドキュメントでも CreateObject はCOMオブジェクト生成の基本手段として説明されており、FileSystemObject や Scripting.Dictionary もその形で使われます。また、VBAプロジェクトをプログラムから読むには「VBA プロジェクト オブジェクト モデルへのアクセスを信頼する」が必要です。

' 前提:
'  - [トラスト センター] の「VBA プロジェクト オブジェクト モデルへのアクセスを信頼する」を有効化
'  - 保護されたプロジェクトは別途ソース輸出や担当者確認が必要
Sub ScanProjectForVbScriptRisks()

    Dim comp As Object
    Dim cm As Object
    Dim ws As Worksheet
    Dim nextRow As Long
    Dim patterns As Variant
    Dim p As Variant
    Dim i As Long
    Dim lineText As String

    patterns = Array( _
        "CreateObject(""VBScript.RegExp"")", _
        "VBScript.RegExp", _
        "WScript.Shell", _
        "Shell(", _
        ".vbs", _
        "wscript.exe", _
        "cscript.exe", _
        "ExecuteGlobal", _
        "Execute(" _
    )

    Set ws = ThisWorkbook.Worksheets.Add
    ws.Range("A1:D1").Value = Array("Module", "Line", "Pattern", "Code")
    nextRow = 2

    For Each comp In ThisWorkbook.VBProject.VBComponents
        Set cm = comp.CodeModule

        For i = 1 To cm.CountOfLines
            lineText = cm.Lines(i, 1)
            For Each p In patterns
                If InStr(1, lineText, CStr(p), vbTextCompare) > 0 Then
                    ws.Cells(nextRow, 1).Value = comp.Name
                    ws.Cells(nextRow, 2).Value = i
                    ws.Cells(nextRow, 3).Value = p
                    ws.Cells(nextRow, 4).Value = lineText
                    nextRow = nextRow + 1
                End If
            Next p
        Next i
    Next comp

    ws.Columns.AutoFit
    MsgBox "Scan finished: " & (nextRow - 2) & " hits"

End Sub

このスキャンでは、CreateObject("VBScript.RegExp")、WScript.Shell、Shell(、.vbs、ExecuteGlobal を最低限拾います。特に Execute / ExecuteGlobal のような文字列実行は、依存先や実行コードが動的に組み立てられるため、棚卸し漏れの温床です。

ログ分析

実行ログを見る段階では、Sysmon + AppLocker/App Control の組み合わせが強いです。Sysmonでは vbscript.dll のロードを Event ID 7 で追跡でき、AppLockerはスクリプト/MSIに対する許可・監査イベントをEvent Viewerで確認できます。App Control for Business を監査モードで動かすと、スクリプトとMSIは AppLocker\MSI and Script ログに記録されます。

# Sysmon: vbscript.dll を読み込んだプロセスを確認
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 2000 |
  Where-Object { $_.Id -eq 7 -and $_.Message -match 'vbscript\.dll' } |
  Select-Object TimeCreated, MachineName, Message

# AppLocker / App Control: スクリプト・MSI 関連の監査ログを確認
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/MSI and Script" -MaxEvents 2000 |
  Where-Object { $_.Id -in 8005, 8006 } |
  Select-Object TimeCreated, Id, Message

ここで重要なのは、「動いている」ログだけでなく、「監査なら止まるはずだった」ログも集めること です。AppLockerの監査イベントやApp Controlの監査モードは、本番ブロック前の安全確認に向いています。

置換の最小サンプル

外部 .vbs を呼んでCSVを書き出す程度の処理なら、まずはVBAネイティブで置き換えるのが最短です。

Sub ExportCsvNativeVba()

    Dim f As Integer
    Dim outPath As String

    outPath = ThisWorkbook.Path & "\out.csv"
    f = FreeFile

    Open outPath For Output As #f
    Print #f, "Code,Name"
    Print #f, "1001,Tokyo"
    Print #f, "1002,Osaka"
    Close #f

    MsgBox "CSV exported: " & outPath

End Sub

Excelから外部処理を呼ぶ必要があり、OSや共有フォルダ、AD、インストーラー、ログ収集まで含むなら、PowerShellへ寄せるほうが現実的です。MicrosoftはVBScriptの代替としてPowerShellを推奨しており、PowerShell側には実行ポリシー、署名、Authenticode検証の公式運用手段があります。なおVBAの Shell は既定で非同期なので、順序制御が必要な処理はフロー設計か待機処理を別途考える必要があります。

Sub RunModernPs()

    Dim cmd As String
    cmd = "powershell.exe -NoProfile -File """ & ThisWorkbook.Path & "\Normalize.ps1""" & _
          " -InputFile """ & ThisWorkbook.Path & "\in.csv""" & _
          " -OutputFile """ & ThisWorkbook.Path & "\out.csv"""

    Shell cmd, vbNormalFocus

End Sub

param(
  [string]$InputFile,
  [string]$OutputFile
)

Import-Csv $InputFile |
  Sort-Object Code |
  Export-Csv $OutputFile -NoTypeInformation -Encoding UTF8

# 署名の付与と確認
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath .\Normalize.ps1 -Certificate $cert
Get-AuthenticodeSignature -FilePath .\Normalize.ps1

Excelの処理がブック内部の整形・集計・変換だけで完結するなら、Office Scriptsも有力です。Office ScriptsはExcel向けで、クラウドベース・クロスプラットフォーム・Power Automate連携に向いています。

function main(workbook: ExcelScript.Workbook) {
  const sheet = workbook.getActiveWorksheet();
  const used = sheet.getUsedRange();
  used.getFormat().autofitColumns();

  const tables = workbook.getTables();
  if (tables.length > 0) {
    tables[0].getSort().apply([{ key: 0, ascending: true }], true);
  }
}

代替技術の選定

代替先は「何で書けるか」ではなく、どこまでの責務を持たせるか で選ぶべきです。PowerShellはWindows・ファイル・タスク・インストーラー寄り、VBAネイティブはOffice内部寄り、Office ScriptsはExcelワークブック処理寄り、VSTO/.NETは厚いデスクトップ統合寄り、Power Automateはオーケストレーション寄りです。以下の表は、公式に公開されている各方式の特性を土台にした実務見積もりです。工数は筆者目安です。

選定の目安を、もう少し直感的に描くとこうなります。

flowchart TD
    A[見つかったVBScript依存] --> B{Excelブック内で完結するか}
    B -->|はい| C[VBAネイティブ]
    B -->|はい かつ 共有/クラウド重視| D[Office Scripts]
    B -->|いいえ| E{OS・ファイル・タスク・ADに触るか}
    E -->|はい| F[PowerShell]
    E -->|いいえ| G{厚いUI統合や長寿命アドインか}
    G -->|はい| H[.NET / VSTO]
    G -->|フロー起点や承認中心| I[Power Automate]

RegExpについてだけ付け加えると、Office version 2508 以降だけが揃っている環境なら、Dim re As RegExp / Set re = New RegExp への整理がかなり有効です。ただし、旧Officeが1台でも残るならそのコードはコンパイル互換性の壁に当たります。混在環境では、移行方針を「新構文」「旧構文」「分岐ラッパー」のどれにするか を先に決めるべきです。

テストと運用

テスト計画

VBScript移行は、単体試験だけでは足りません。セキュリティポリシーが有効な本番相当条件で再試験しないと、置換後のPowerShellや.NETスクリプトが別理由で止まります。Microsoftの資料でも、PowerShell実行ポリシー、AppLocker、App Control監査モード、ASR、MOTW付きマクロ制御を別個のルールとして扱っています。

特に見落としやすいのは、このあたりです。

• ExcelからPowerShellを起動する置換は、ASRの「Officeアプリによる子プロセス作成ブロック」 に引っかかる可能性がある。
• VBAの宣言やAPI呼び出しを残していると、ASRの「OfficeマクロからのWin32 API呼び出しブロック」 に引っかかる可能性がある。
• ダウンロードファイルやメール添付から配布したテスト用 .xlsm / .ps1 は、MOTWや署名状態により挙動が変わる。
• Office Scripts と Power Automate の組み合わせは便利ですが、大きいCSVや大量セルではタイムアウトやデータ転送制限を意識する必要がある。
• SysmonのImage Load監視は便利な反面、企業全体で雑に広げるとログ量が増えやすい。

移行手順のチェックリスト

• .vbs、wscript.exe、cscript.exe、VBScript.RegExp、WScript.Shell、Shell(、ExecuteGlobal を静的検索した
• GPO、Scheduled Task、Intune、共有フォルダ運用、MSI を別系統で棚卸しした
• Officeバージョンと更新チャネルを台帳化し、2508未満の残存を把握した
• 置換先を「VBAネイティブ / PowerShell / .NET / Office Scripts / Power Automate」で決めた
• 署名方針と証明書配布方針を決めた
• AppLocker / App Control / ASR / 実行ポリシーの影響を試験した
• パイロット部門で監査ログを収集した
• ロールバック手順を文書化した
• VBScript FOD を無効化する前に「未使用」の根拠を残した

リスクと対策

この表の対策は、Microsoftの公式資料にある設計上の制約を、社内運用に落とし込んだものです。

ロールバックは「コードを戻す」だけでは不十分です。最低でも、配布物の旧版復元、ポリシーの戻し、オプション機能の再有効化余地、ログ収集継続 をセットで考えてください。VBScriptがまだFODとして存在する段階であれば、Phase 2の案内どおりオプション機能として再有効化できる余地がありますが、Phase 3で削除された後はその逃げ道はなくなります。

サンプル移行ケーススタディ

典型例として、経理部の月次集計マクロ を想定します。現状は、Excelマクロが WScript.Shell 経由で cleanup.vbs を起動し、CSV整形後に VBScript.RegExp でコードを検証して、最後に共有フォルダへ出力しているとします。この構成は、VBScript廃止の直撃を受けるうえ、PowerShellへ単純置換してもASRや署名運用で再び止まりやすい構成です。

このケースでは、分割して考えるのが正解です。Excel内部で完結する検証や書式・集計はVBAネイティブかOffice 2508+の組み込みRegExpへ寄せる。ファイル変換や共有フォルダへの入出力はPowerShellへ寄せる。実行起点が「ファイル到着」や「毎日定時」ならPower Automateへ寄せる。こうすると、1本の .vbs に押し込めていた責務を整理できます。

移行後の構成例はこうです。

• Excelマクロ: 入力チェック、画面操作、ユーザー向けメッセージ
• PowerShell: CSV正規化、共有フォルダI/O、ログ出力
• 署名運用: PowerShellスクリプトにAuthenticode署名
• セキュリティ: AppLocker/App Controlを監査モードで先行確認、ASR例外の要否を判断
• 将来拡張: Excel内部の定型処理はOffice Scriptsへ段階移行

このやり方の利点は、VBScriptランタイム依存を早く切り離しながら、全部を一気に作り直さなくて済むこと です。RegExpはOffice更新で吸収し、運用スクリプトはPowerShellへ、業務フローはPower Automateへというように、責務ごとに分割すれば、障害範囲も小さくなります。

推奨ツールと参考リンク

• この記事のサンプルコード一式（PowerShell 監査スクリプトと Pester テスト） https://github.com/gomurin0428/komurasoft-blog-samples/tree/main/vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide

公式資料は、この順番で読むのがおすすめです。

• VBScript deprecation: Timelines and next steps 全体ロードマップとPhaseの意味を確認するための起点。
• VBScript deprecation: Detection strategies for Windows Sysmon、GPO、Scheduled Task、Intune、MSI Custom Actionまで含めた実践的な検出指針。
• Prepare your VBA projects for VBScript deprecation in Windows VBA観点で最重要。RegExpの組み込み化、Office 2508以降の扱い、互換表が整理されています。
• Office スクリプトと VBA マクロの違い Excel中心の処理をOffice Scriptsへ寄せるべきか判断しやすい資料。
• about_Execution_Policies / about_Signing / Set-AuthenticodeSignature / Get-AuthenticodeSignature PowerShell移行時の署名・実行ポリシー運用の基本セット。
• Using Event Viewer with AppLocker / Use audit events to create App Control policy rules / App Control for Business を使用したスクリプトの適用 監査モード設計、イベント収集、スクリプト適用挙動の理解に必要。
• 攻撃面の減少ルールの参照 Office子プロセス、Win32 API、JS/VBSダウンロード実行のブロックルールを確認するための資料。
• インターネットからのマクロは、Officeで既定でブロックされます テスト配布や本番展開時のMOTW問題を理解するために必読。

補助ツールとしては、このあたりを実務でよく使います。

• Sysmon vbscript.dll のロード監視やプロセス系イベント収集の基本。
• GitHub上の Sysmon 設定テンプレート SwiftOnSecurity の sysmon-config は高品質な初期テンプレート、Olaf Hartong の sysmon-modular はモジュール型で運用しやすい出発点です。
• oletools / olevba OfficeファイルからVBAソースを抽出し、怪しいキーワードや自動実行マクロを検出する補助に向いています。

結論として、VBScript廃止への備えは「VBScriptを探してPowerShellに置き換える」だけでは不十分です。Office更新、コード解析、運用構成、署名、ASR/AppLocker/App Control、UATまで一枚の台帳で管理すること が、最短で確実な進め方です。RegExpのようにOffice更新で救える領域は早めに救い、.vbs 実行やGPO/タスク/MSI依存のようにWindows側の段階切替で破綻しやすい領域は、優先的に切り離してください。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。