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

エグゼクティブサマリー

「VBScriptが廃止されると、Excelマクロも全部作り直す必要があるのか」。最初に切り分けたいのは、VBAそのものと、VBAから利用しているVBScriptは別だということです。全面書き換えを始める前に、どこに依存が残っているかを確認します。

本記事の結論は、次の3点です。

• まず依存を棚卸しします。 VBAからの外部 .vbs 実行と VBScript.RegExp などのライブラリ参照を分け、GPO・タスク・Intune・MSIまで対象に含めます。
• 代替先は処理の役割で選びます。 Excel内部で完結する処理と、OS・ファイル・業務フローを扱う処理を分けます。RegExpはOffice更新で依存の一部を解消できますが、旧Officeが残る混在環境は別途確認が必要です。
• 移行完了は、コードが動くだけでは判断しません。 署名、セキュリティポリシー、実行ログ、互換性、ロールバックまで含め、本番相当の条件で確認します。

進める順番は、棚卸し → 静的検出 → 実行ログ収集 → 代替先の選定 → テスト → 段階展開です。廃止の段階と時期の注意を先に整理し、その後で具体的な点検方法を説明します。

この記事で点検する「社内ツール」の範囲

対象は、Excelマクロや手元の .vbs ファイルだけではありません。

自分でVBScriptを書いた覚えがなくても、これらに依存が埋まっていれば対象です。

目的別の読み方とサンプル

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

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

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

用語ミニ辞書

以降の章では、Windowsのセキュリティ機能の略語が続けて出てきます。「Windowsに機能があるか」「実行を許可するか」「Officeがどう扱うか」を混同しないよう、先に用語を確認します。

変化の整理

廃止されるのはVBScriptであり、VBAそのものではない

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

2026年4月時点の公開情報を、3段階に分けると次のようになります。

切替の確定日は公表されていません。 MicrosoftのVBA向け案内では、Phase 2を「2026〜2027年ごろ」、Phase 3を「TBD（未定）」としています。これは確定した締切ではなく、日付だけから移行完了日を逆算できる話ではありません。

Windows 11 24H2以降の端末が増えるほど切替への備えが必要になる、という前提で、棚卸しは先に済ませます。ロードマップはWindows側の案内とVBA向けの案内で確認できます。

優先して調べる依存パターン

実務上の優先順位は、次の表で整理できます。VBScriptを直接使う箇所だけでなく、置換後の外部プロセス起動も点検対象です。

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

RegExpはOffice更新と組み合わせて判断する

RegExpには、Office側で対応できる部分があります。Office version 2508（Build 19127.20154）以降ではRegExpクラスがVBEに標準搭載され、RegExp用途に限れば、VBScript依存の一部をOffice更新で解消できるようになりました。

ただし、旧Officeクライアント、更新チャネルが遅い環境、古い端末イメージが残っていれば、自動的に全端末が解決するわけではありません。同じVBAでも、動く端末と動かない端末が生じます。

台帳では、「Officeのバージョン・更新チャネル」と「Windows側の段階切替」を一緒に管理します。具体的な構文の選び方は「代替技術の選定」で扱います。

PowerShellへ置き換えても、運用上の制約は残る

移行を難しくするのは、言語の書き換えだけでなく周辺の運用です。Excelから powershell.exe を起動するように置き換えても、次の制御により本番では動かないことがあります。

移行計画には、コード変換、ポリシー、署名、ログ監査をまとめて含めます。

棚卸しの進め方

台帳を「依存・運用・移行計画」の3組で作る

ファイル名の検索だけでは、移行計画は作れません。次の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パッケージも別系統で確認することが推奨されています。

次は、指定したテキストファイルの中から呼び出し候補を拾う例です。検索結果は点検の入口であり、これだけで全依存を検出できたとは判断しません。

# 端末・共有フォルダ上のスクリプト依存をざっくり洗う
$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

このタスク一覧だけで、GPO、Intuneの配布内容、MSI内部のCustom Actionまで確認できたことにはなりません。それぞれを別系統の点検結果として台帳へ戻します。

VBAコード解析

参照設定と、文字列によるCOM呼び出しを分けて調べる

VBA側は、参照設定だけを見ても不十分です。CreateObject や GetObject は文字列でCOMを利用できるため、参照設定に何も出なくても依存が残ることがあります。MicrosoftのVBA/Officeドキュメントでも CreateObject はCOMオブジェクト生成の基本手段として説明されており、FileSystemObject や Scripting.Dictionary もその形で使われます。

VBAプロジェクトを読む前提を確認する

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のImage Load監視は有効ですが、ログ量と運用負荷が大きくなります。まず小規模パイロットで収集量と負荷を検証し、いきなり全社へ広げないことが重要です。

# 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

このコード例の抽出範囲には注意が必要です。 8005 / 8006 はAppLockerの許可・監査イベントであり、同じログに出るApp Controlのイベントを一括で取得する条件ではありません。App Controlの監査では、たとえば 8028 を別途確認します。AppLockerのイベント一覧とApp Controlのイベント一覧を分けて参照してください。

集めたいのは、「動いている」記録だけではありません。監査モードで実行は許可されたが、強制適用なら止まっていた処理も確認します。また、この例は各ログの直近2000件を取得してから絞り込むため、結果が0件でも未使用の証明にはなりません。業務の実行周期と収集条件を合わせて判断します。

置換の最小サンプル

ここでは、小さな置換例を役割ごとに示します。方式全体の比較は、次の「代替技術の選定」で整理します。

簡単なCSV出力は、VBA内で完結させる

外部 .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

OSや共有フォルダを扱う処理は、PowerShellへ分ける

Excelから外部処理を呼ぶ必要があり、OS、共有フォルダ、AD、インストーラー、ログ収集まで含むなら、PowerShellへ寄せるほうが現実的です。MicrosoftはVBScriptの代替として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

呼び出す Normalize.ps1 側では、CSVを読み込み、コード順に並べて出力します。

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ワークブック処理に向きます。.NET / VSTOは厚いデスクトップ統合、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の残存を確認してから決める

Office version 2508以降だけが揃っている環境なら、Dim re As RegExp / Set re = New RegExp への整理が有効です。

ただし、旧Officeが1台でも残るなら、そのコードはコンパイル互換性の壁に当たります。混在環境では、「新構文」「旧構文」「分岐ラッパー」のどれを採用するかを先に決めます。Officeのバージョンと更新チャネルを台帳化し、2508未満の残存を把握する作業がここで効きます。

テストと運用

テスト計画

本番相当の条件で、試験の合格基準を分ける

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監視は、企業全体へ無計画に広げるとログ量が増えやすい。

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

本番切替の前に、次の項目を点検します。「未使用」の根拠を揃えず、先にVBScript FODを無効化しないことが重要です。

• .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日で終わっても、「先月と同じ結果になるか」は月末を1回またいで確認する必要があります。年次処理を含むツールなら、待ち時間はさらに伸びます。

計画は、工数だけでなく、確認できるタイミングから逆算します。

移行後：Excel内部・外部処理・業務フローを分ける

このケースでは、処理を次のように分割します。

こうすると、1本の .vbs にまとめていた責務を整理できます。先の想定には2508未満の端末があるため、RegExpについてはOffice更新または混在環境向けの方針を先に決めます。

移行後の構成例は次のとおりです。

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