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

エグゼクティブサマリー

この記事でいう「社内ツール」は、Excelマクロや .vbs ファイルだけではありません。GPOのログオンスクリプト、タスクスケジューラに登録したタスク、Intuneで配布しているスクリプト、MSIのVBScript Custom Actionまで含みます。自分でVBScriptを書いた覚えがなくても、これらのどれかに .vbs が埋まっていれば対象です。

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

時期については、確定日が公表されていません。MicrosoftのVBA向け案内では、Phase 2（FODを既定無効）を「2026〜2027年ごろ」、Phase 3（削除）を「TBD（未定）」としています。つまり、この件は「いつまでに終わらせるか」を日付から逆算できません。Windows 11 24H2以降の端末が増えるほど期限が近づく、という前提で、棚卸しだけは先に済ませておくべきです。

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)

この記事の知識マップ

MicrosoftはVBScriptをFeature on Demandとしての既定有効から既定無効、将来の削除へと段階的に廃止する方針を示しており、VBAからの外部.vbs実行やVBScript系ライブラリ参照、GPOログオンスクリプト・タスクスケジューラ・Intune配布スクリプト・MSIのCustom Actionがその影響を受けます。代替先はOS・ファイル・タスクに触る処理ならPowerShell、Excelブック内で完結する処理ならVBAネイティブやOffice Scripts、複雑な業務ロジックなら.NET/VSTO、フロー起点ならPower Automateというように責務で選び分けます。ただし置換後のPowerShellやマクロは、攻撃面の減少ルール(ASR)やAppLocker、App Control for Businessのポリシー次第でブロックされ得るため、SysmonやAppLockerイベントログでの監査ログ収集、実行ポリシーとAuthenticode署名の運用まで含めて移行を設計する必要があります。

flowchart LR
    accTitle: VBScript廃止とVBA・社内ツール移行の知識マップ
    accDescr: VBScriptの段階的廃止がVBA・GPO・タスクスケジューラ・Intune・MSIにどう影響し、PowerShellやOffice Scripts等の代替技術がAppLockerやASRといったセキュリティ機能とどう関わるかを示す図
    vbscript["VBScript"]
    vba["VBA(Visual Basic for Applications)"]
    powershell["PowerShell"]
    feature_on_demand["Feature on Demand(FOD)"]
    group_policy["グループポリシー"]
    task_scheduler["タスクスケジューラの無人実行"]
    intune["Microsoft Intune"]
    msi_custom_action["MSI Custom Action"]
    zone_identifier["Zone.Identifier(Mark of the Web)"]
    attack_surface_reduction_rules["攻撃面の減少ルール(ASR)"]
    powershell_execution_policy["PowerShellの実行ポリシー"]
    authenticode_signing["Authenticode署名(PowerShellスクリプト)"]
    applocker_log["AppLockerイベントログ"]
    app_control_for_business["App Control for Business(旧WDAC)"]
    audit_mode["監査モード"]
    applocker["AppLocker"]
    sysmon["Sysmon"]
    office_scripts["Officeスクリプト(Office Scripts)"]
    vsto["VSTO(Visual Studio Tools for Office)"]
    power_automate["Power Automate"]
    powershell -->|"の後継"| vbscript
    vba -.->|"利用する"| vbscript
    vbscript -->|"前提とする"| feature_on_demand
    group_policy -.->|"前提とする"| vbscript
    task_scheduler -.->|"前提とする"| vbscript
    intune -.->|"前提とする"| vbscript
    msi_custom_action -.->|"前提とする"| vbscript
    vba -.->|"両立しない"| zone_identifier
    vba -.->|"利用する"| powershell
    powershell -.->|"両立しない"| attack_surface_reduction_rules
    vba -.->|"両立しない"| attack_surface_reduction_rules
    powershell -->|"前提とする"| powershell_execution_policy
    powershell_execution_policy -.->|"前提とする"| authenticode_signing
    powershell -->|"で構成できる"| authenticode_signing
    powershell -.->|"で確認できる"| applocker_log
    app_control_for_business -.->|"で構成できる"| audit_mode
    applocker -.->|"で構成できる"| audit_mode
    vbscript -.->|"で確認できる"| sysmon
    office_scripts -.->|"推奨される対応"| vbscript
    vba -->|"推奨される対応"| vbscript
    powershell -->|"推奨される対応"| vbscript
    vsto -.->|"推奨される対応"| vbscript
    power_automate -.->|"推奨される対応"| vbscript
    powershell -.->|"両立しない"| applocker
    vba -.->|"両立しない"| app_control_for_business

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全25件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

用語ミニ辞書

以降の章では、Windowsのセキュリティ機能の略語が続けて出てきます。先にここだけ押さえておくと読みやすくなります。

変化の整理

まず押さえるべきなのは、今回の論点が「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 の段階的無効化]

図が表示されない環境向けに、3行にまとめておきます。

1. 棚卸しで見つけた依存を、外部 .vbs 実行 / VBScript.RegExp / 中央管理設定（GPO・タスク・MSI）/ 不明の4つに仕分ける
2. 仕分けごとに置換先を決めて単体試験を通し、そこから結合試験へ合流させる
3. 監査モードでパイロット展開し、問題がなければ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はオーケストレーション寄りです。以下の表は、公式に公開されている各方式の特性を土台にした実務見積もりです。工数は筆者目安です。

工数目安のスケールは、ツール1本（マクロ1本、またはスクリプト1本）を移行するときの目安として、低＝数日、中＝数週間、高＝1〜数か月と読んでください。対象が10本あれば、その分だけ積み上がります。

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

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]

こちらも3行にすると、こうなります。

1. Excelブック内で完結するならVBAネイティブ。共有やクラウド実行を重視するならOffice Scripts
2. OS・ファイル・タスク・ADに触るならPowerShell
3. 厚いUI統合や長寿命アドインなら.NET / VSTO。フロー起点や承認中心なら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や署名運用で再び止まりやすい構成です。

規模感がないと稟議に載せにくいので、説明用に置いた仮の数字も並べておきます。実際の値は棚卸しの結果で決まりますが、この粒度で書き換えれば、そのまま計画表の下敷きになります。

期間が工数より長いのは、月次処理だからです。単体試験が1日で終わっても、「先月と同じ結果になるか」は月末を1回またがないと確かめられません。年次処理を含むツールなら、この待ち時間はさらに伸びます。計画では、工数ではなく 確認できるタイミング から逆算してください。

このケースでは、分割して考えるのが正解です。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側の段階切替で破綻しやすい領域は、優先的に切り離してください。

関連する記事

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

関連トピック

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

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

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

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

VBScriptはいつ廃止されるのですか？

2026年4月時点で、Microsoft は VBScript を段階的に廃止する方針を公開しています。Windows 11 バージョン 24H2 ではまず Feature on Demand（FOD）として既定有効、次の段階では既定無効、最終段階では将来の Windows リリースから削除する計画です。つまり、いま本当にやるべきことは全面書き換えより先に、どこが VBScript 依存なのかを可視化することです。FOD として存在する段階であればオプション機能として再有効化できる余地がありますが、削除された後はその逃げ道はなくなります。

VBScriptが廃止されると、VBAやExcelマクロも使えなくなりますか？

いいえ、今回の論点は「VBA が廃止される」話ではありません。Microsoft が公開しているのはあくまで VBScript の段階的廃止であり、VBA プロジェクトへの影響は、主に外部 .vbs ファイルの実行と、VBScript.RegExp のような VBScript 系ライブラリ参照に集中します。VBA / Excel から .vbs を直接実行している処理は段階切替以降に停止するリスクが高く、優先的に洗い出すべき対象です。GPO のログオンスクリプト、Scheduled Task、Intune 配布スクリプト、MSI の VBScript Custom Action も一斉障害になりやすい重点領域です。

VBScriptの代替には何を使えばよいですか？

代替先は「何で書けるか」ではなく、どこまでの責務を持たせるかで選びます。OS・ファイル・共有フォルダ・AD・タスク・インストーラーに触る処理は、Microsoft が推奨する PowerShell が本命で、署名と実行ポリシーの公式運用手段もあります。Excel ブック内で完結するセル操作や帳票は VBA ネイティブ、クラウド実行や Power Automate 連携を重視するなら Office Scripts、厚いデスクトップ統合や長寿命の社内アドインは .NET / VSTO、スケジュール実行や承認フロー起点なら Power Automate が候補です。置換後に ASR や AppLocker で止まらないか、ポリシーまで含めた試験が必要です。

VBAでVBScript.RegExpを使っている場合はどうすればよいですか？

Office version 2508（Build 19127.20154）以降では、RegExp クラスが VBE に標準搭載されたため、RegExp 用途に限れば VBScript 依存の一部を Office 更新で解消できるようになりました。ただし、旧 Office クライアントが残る混在環境では、同じ VBA でも動く端末と動かない端末が発生しやすくなります。2508 未満の端末が 1 台でも残るなら新構文はコンパイル互換性の壁に当たるため、Office バージョンと更新チャネルを台帳化して残存を把握し、移行方針を「新構文」「旧構文」「分岐ラッパー」のどれにするか先に決めるべきです。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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