「VBScriptが廃止されるらしい。うちは使っているのか」。この質問に即答できる管理者は多くありません。ログオンスクリプト、タスクスケジューラ、業務アプリのインストーラー、Excelのマクロ。VBScriptは目立たない場所に入り込んでいて、書いた本人がもう社内にいないことも珍しくないからです。

先に結論を書きます。いまのWindows 11で、VBScriptがある日突然動かなくなるわけではありません。 次に起きるのは、2027年ごろに予定されている「既定で無効」への切り替えで、このときもオプション機能から有効に戻せます。本当に使えなくなるのはその先で、時期はまだ示されていません。

ただし、無効化で止まるのは**「誰も使っていると思っていなかった処理」です。だからいまやることは、移行より先に使っている場所を見つけること**です。そして見つけ方は1つではありません。.vbs ファイルを検索するだけでは、インストーラーの中やマクロの中に埋め込まれたVBScriptは見つからないからです。

この記事は、MicrosoftのWindows IT Pro Blogの2本の記事を読み解いた無料動画を素材にしています。日付と仕様は、2026年10月17日時点で公開されているMicrosoftの公式記事で確認しました。

VBScript廃止はいつ？ 3段階のタイムライン

Microsoftは2023年10月にVBScriptの非推奨を発表し、2024年5月の「VBScript deprecation: Timelines and next steps」（英語）で、廃止を3段階で進めると示しました。Microsoft Learnの「Windows クライアントの非推奨機能」にもVBScriptが載っています。

段階 時期 何が起きるか 自分の環境への影響
フェーズ1 Windows 11 24H2から（現在） VBScriptがOSの部品から「オプション機能（FOD）」に変わる。既定で有効 これまでどおり動く。オプション機能から外すこともできる
フェーズ2 2027年ごろ オプション機能が既定で無効になる 使い続けるには、オプション機能で有効に戻す必要がある
フェーズ3 未定 VBScriptのDLLがOSから削除される VBScriptに頼る処理はすべて止まる

動画では、この図を1分12秒から、2027年ごろの既定無効化を1分45秒から説明しています。フェーズ2の時期は「around 2027」とだけ書かれていて、正確な日付はこの記事を書いた時点で確認できた公式記事にはありません。

いまの端末がどの段階にいるかは、設定 > システム > オプション機能 で確かめられます。インストール済みの一覧に「VBScript」があれば、有効な状態です。

「有効に戻せるなら、2027年まで待てばいい」の落とし穴

フェーズ2で有効に戻せるのは事実です。動画でも2分52秒から、「ここで初めて気づく人がたくさん出て、有効化して助かったという話になるだろう」と話しています。

問題は、有効に戻すには、まず止まったことに気づく必要があることです。Microsoftの検出ガイドは、VBScriptを無効にしたときの影響として「VBScriptに頼るスクリプトは、エラーを出すか、何も言わずに失敗する」と書いています。夜間に動く集計、月に一度だけ動く処理、新しいPCのセットアップでだけ動くインストーラー。止まったことに誰かが気づくまでに、数週間かかる処理もあります。

もう1つ、フェーズ2で有効に戻すのは延命でしかありません。削除（フェーズ3）は時期が決まっていないだけで、来ないわけではありません。

使っている場所の調べ方：4つの方法と、それぞれの死角

Microsoftは2025年5月に「VBScript deprecation: Detection strategies for Windows」（英語）を公開し、組織内でVBScriptを見つける方法を4つ挙げました。動画では4分53秒から、この記事を順に読んでいます。

4つは「どれか1つを選ぶ」ものではなく、それぞれ違う場所を照らすものです。先に、何が見つかって何を見落とすかを並べます（記事の4つの方法を、死角の観点で整理したものです）。

方法 見つかるもの 見落とすもの 手間
1. Sysmonで実行を記録する 実際にVBScriptを読み込んだプロセス。マクロやアプリ内部の利用も含む 監視している期間に動かなかった処理（月次・年次・セットアップ時だけの処理） 大きい。全台への配布とログ収集が要る
2. 管理者が配った仕組みを見る ログオン／スタートアップスクリプト、タスクスケジューラ、Intuneで配ったスクリプト 利用者が自分で置いたもの、アプリに同梱されたもの 小さい。管理用の1台から調べられる
3. .vbs ファイルを検索する 端末に置かれたスクリプトファイル ファイルになっていないVBScript（インストーラーの中、マクロの中） 中くらい。検索の範囲を絞る必要がある
4. MSIのカスタムアクションを調べる インストーラーに埋め込まれたVBScript MSI以外の形式のインストーラー 小さい。配布用の共有フォルダーを調べる

順番の目安は、手間の小さい2と4で明らかなものを先に拾い、3で端末側を広く見て、1で「実際に動いているもの」を確かめるです。1は確かな証拠が取れる代わりに、準備が最も重い方法です。

1. Sysmonで「vbscript.dllを読み込んだプロセス」を記録する

VBScriptの処理の本体は vbscript.dll で、VBScriptが動くときにはこのDLLが読み込まれます。SysinternalsのSysmonは、DLLの読み込みをイベントとして記録できるので、ここを見張ればどのプロセスが、いつVBScriptを使ったかが分かります。

Microsoftの記事が示す設定は、vbscript.dll の読み込みだけを記録する最小限のものです。

<Sysmon schemaversion="4.50">
  <EventFiltering>
    <ImageLoad onmatch="include">
      <ImageLoaded condition="contains">vbscript.dll</ImageLoaded>
    </ImageLoad>
  </EventFiltering>
</Sysmon>

管理者権限のコマンドプロンプトで Sysmon64.exe -c sysmon-config.xml を実行して読み込ませると、イベントビューアーの「アプリケーションとサービス ログ > Microsoft > Windows > Sysmon > Operational」に、**イベントID 7（イメージの読み込み）**が記録されます。動画では5分50秒から、記録されたイベントの例を見ながら、どのプロセスがVBScriptを読み込んだかを読み取っています。

イベントID 7だけでは「誰が呼んだか」までは分かりません。プロセスの起動を記録するイベントID 1と組み合わせると、親プロセスをたどれます。wscript.exe や cscript.exe が出てきたら、その親がタスクスケジューラなのか、ログオン処理なのか、業務アプリなのかが、直す人を決める手がかりになります。

注意点は2つあります。

  • いきなり全台に入れない。 Microsoftの記事は、大規模に入れると性能と運用の負荷がかかるとして、少数の端末で試してから広げるよう求めています。動画でも7分13秒から、ログの量が組織によってまったく違うこと（ほぼゼロの組織もあれば、ログオンのたびに10件も20件も出る組織もある）を挙げて、少人数から様子を見るよう勧めています
  • Webサーバーはイベントが多すぎる。 IISで古いASPを動かしている環境では、ページを開いただけで vbscript.dll が読み込まれ、イベントがあふれます。Sysmonのイベントには、どのURLが原因かは出ません。IISのアクセスログと時刻で突き合わせる必要があります

記録したイベントは、1台ずつ見ていては終わりません。Windowsイベント転送やSIEMで1か所に集めて分析することになります。全台からイベントを集める仕組みの選び方は、NTLMの監査でもまったく同じ問題として出てきます。メンバー限定のNTLMv1の回の19分59秒からでは、イベントがアクセスされた側の端末にしか残らないときに、SIEM、Windowsイベント転送、PowerShellをログオンスクリプトで配る方法のどれで集めるかを、図を使って整理しています。何千台ものログを集める手段がまだ無い組織にとっては、VBScriptの調査より先に整えるべき土台です。参加していない場合は、リンク先でメンバーシップの案内が表示されます。同じ「全台のログを集めて、廃止の影響を洗い出す」作業を、NTLMについて書いたのがNTLM廃止の時期と使っている場所の調べ方です。

2. 管理者が配った仕組みを、管理用の1台から調べる

VBScriptが特に多く残っているのは、管理者が一元的に配った仕組みの中です。Microsoftの記事は、次の場所を挙げています（動画では8分19秒から）。

  • グループポリシーのログオン／ログオフ／スタートアップ／シャットダウンスクリプト
  • 古いスクリプトを起動するタスクスケジューラのタスク
  • Intuneで配ったPowerShellスクリプトの中から、cscript.exe などで .vbs を呼んでいるもの

これらは管理者が設定したものなので、利用者の端末を1台ずつ見なくても、ドメインコントローラーや管理用の端末から調べられます。 4つの方法の中で、最初に手を付けるべきところです。

グループポリシーのスクリプトは、\\<ドメイン名>\SYSVOL の中を .vbs、wscript.exe、cscript.exe で検索します。ここで迷いやすいのが、スクリプトの実体がどこにあるかです。グループポリシーの画面に表示されるのはスクリプトの名前だけで、ファイルはポリシーごとのフォルダー（GUIDの名前が付いた分かりにくいフォルダー）に置かれ、古い運用では NETLOGON 共有に置かれていることもあります。メンバー限定のSYSVOLの回では、2分6秒からで net share を使ってSYSVOLとNETLOGONの共有がディスク上のどこにあるかを確かめ、8分51秒からでスタートアップスクリプトをポリシーに登録するときに、ファイルがどのフォルダーに入るのかを実際の画面で追っています。検索で見つかった .vbs が「どのポリシーから呼ばれているのか」を逆にたどるときに、この構造が分かっていると迷いません。

なお、SYSVOLの中身はドメインコントローラーの間で複製されます。複製が止まっていると、ドメインコントローラーごとに中身が違うことがあります。1台だけ調べて済ませる前に、複製が正常かを確かめておくと安心です。確認の仕方はdcdiagでエラーが出るときの見方にまとめています。

タスクスケジューラは、PowerShellでタスクの一覧と、それぞれが実行するコマンドを取り出せます。Microsoftの記事は、組織で作ったフォルダーに加えて、\Microsoft\Windows の下のタスクも見るよう書いています。

3. .vbs ファイルを、場所を絞って検索する

管理者が配ったもの以外、たとえば利用者が自分で置いたスクリプトや、アプリが一緒に置いていったスクリプトは、端末側を検索するしかありません（動画では9分30秒から）。

Microsoftの記事は、次の場所を検索対象に挙げています。

  • C:\Users\
  • C:\ProgramData\
  • C:\Program Files\ と C:\Program Files (x86)\
  • C:\Scripts\ のような、組織でスクリプトを置いている場所
  • C:\Windows\（関係の無いファイルも多く拾うので、必要に応じて）

そして、本番環境で C:\ 全体をやみくもに検索しないよう注意しています。性能の問題やアクセスエラーの原因になるからです。数千台に一斉に全ドライブ検索をかければ、業務時間中の端末が重くなるのは想像がつきます。検索用のPowerShellは記事に例があり、結果を端末ごとのCSVに書き出して1か所に集める形になっています。配る手段は、Intune、グループポリシーのスタートアップスクリプト、Invoke-Command、Configuration Managerのどれでも構いません。

4. MSIのカスタムアクションに埋め込まれたVBScriptを調べる

4つの中で、いちばん見落としやすいのがこれです。動画でも10分46秒から、「そんなことがあるのかと思った」と話しています。

MSI形式のインストーラーは、インストールの途中で独自の処理（カスタムアクション）を実行できます。古い業務アプリでは、この処理をVBScriptで書くのがよくある作り方でした。インストーラーの中に埋め込まれているので、.vbs ファイルとしてはどこにも現れません。 そして、このVBScriptが動くのはインストール、修復、アンインストールのときだけです。普段の業務では一度も動かないので、Sysmonで数週間見張っていても記録に出ないことがあります。

止まって困るのは、たとえば次のような運用です。

  • 利用者が必要なときに自分でアプリを入れられるよう、MSIを共有フォルダーに並べている
  • 新しいPCを用意するとき、フォルダーにあるMSIを順に実行してセットアップしている

フェーズ2の後にこうした作業をすると、そのアプリだけがインストールできないという形で問題が表に出ます。

調べ方は、MSIの中にある「CustomAction」というテーブルを読み、種類（Type）が6、38、50のものを探します。これがVBScriptのカスタムアクションです。Microsoftの記事にPowerShellの例があり、配布用の共有フォルダーにあるMSIをまとめて調べられます。動画では12分2秒から、この結果の読み方（VBScriptのカスタムアクションが出力されたら使われている）を説明しています。種類の番号の意味は、Microsoft Learnの「CustomAction テーブル」から各種類の説明へたどれます。

1つ注意があります。インストール済みのアプリを一覧にするとき、Win32_Product（WMIのクラス）を使ってはいけません。Microsoftの記事によると、MSIでインストールしたすべてのアプリの修復を引き起こすことがあります。インストール済みのアプリを調べるなら、レジストリの Uninstall キーから読みます。

見つかったときの対応は、作った人で分かれます。自社で作ったMSIなら、Orcaなどのツールで作り直してカスタムアクションを置き換えます。他社製品なら、VBScriptを使わない版を出してもらうようベンダーに依頼するしかありません（動画では12分24秒から）。ベンダーの対応には時間がかかるので、MSIの調査は早めに済ませておく価値があります。

Excelのマクロ（VBA）も対象になる

VBScriptは、OfficeのVBAからも使われています（動画では4分27秒から）。Microsoftの「Prepare your VBA projects for VBScript deprecation in Windows」（英語）によると、使い方は2つです。

  • VBAから .vbs ファイルを実行している
  • 正規表現のために「Microsoft VBScript Regular Expressions」を参照設定している、または CreateObject("VBScript.RegExp") を使っている

2つ目は、VBScriptを使っている自覚がないまま書かれていることが多い使い方です。この記事によると、Microsoft 365のOfficeのバージョン2508以降では、正規表現のクラスがVBAに標準で入りました。 2508以降に更新しておけば、CreateObject("VBScript.RegExp") のままでも、VBScriptが無効になったWindowsで動きます。逆に、2508より古いOfficeを、VBScriptを無効にしたWindowsで使うと動きません。

マクロの中のVBScriptは、.vbs ファイルとしては見つかりません。Excelのファイルを1つずつ開いて調べるより、Officeのバージョンを2508以降にそろえるほうが確実な対策です。そのうえで、VBScriptを無効にした端末でマクロを試して、隠れた依存が残っていないかを確かめます。

見つかったら：移行先と、新しく作らないこと

見つかったVBScriptの移行先として、Microsoftはスクリプトや自動化にはPowerShell、Webページ（ブラウザーで動くVBScript）にはJavaScriptを勧めています。

PowerShellに移すとき、最初につまずきやすいのが実行ポリシーです。.vbs はダブルクリックすれば動いていたのに、.ps1 は「スクリプトの実行が無効になっている」と言われて動かない、ということがよく起きます。原因と、スクリプトを配るときの考え方はPowerShellで「スクリプトの実行が無効」と出る原因と対処にまとめています。保存した .ps1 の呼び出し方そのものは、無料動画の「PowerShellスクリプトの実行方法」で確かめられます。

そして、これから新しくVBScriptで仕組みを作らないことです。動画では3分24秒から、この判断基準を話しています。「2027年までに必ず使い終わる、期間限定の仕組み」なら、VBScriptで書くのが最も手早い場合に限って選択肢に残る。いつまで使われるか分からないものは、PowerShellで書く。いま新しく書かれたVBScriptが、数年後に「誰も使っていると思っていなかった処理」になるからです。

使っていないと分かったら、先に無効にしておく

4つの方法で調べて、VBScriptを使っていないことが確かめられた端末は、フェーズ2を待たずに自分で無効にしておくのも手です。動画では13分23秒から、その理由を「いま使っていなくても、これから誰かがVBScriptで新しい仕組みを作ってしまうのを防げる」と説明しています。

Microsoftの検出ガイドが示しているコマンドは次のとおりです。

Dism /Online /Remove-Capability /CapabilityName:VBSCRIPT~~~~

Intune、グループポリシーのスタートアップスクリプト、Configuration Managerで配れます。ただし、Microsoftの記事は、大規模に配る前にテスト環境で確かめるよう念を押しています。オプション機能の状態や動作は、構成やビルドによって違うからです。まず少数の端末で無効にし、業務に影響が出ないことを確かめてから広げます。止まる処理があれば、それは調査で見落としていた依存が見つかった、ということでもあります。

まとめ

  • いまのWindows 11でVBScriptが突然止まるわけではない。2027年ごろに既定で無効になり、その後、時期未定で削除される
  • 既定で無効になっても有効に戻せる。ただし、止まったことに気づかなければ戻せない。VBScriptに頼る処理は、何も言わずに失敗することがある
  • 使っている場所の調べ方は4つあり、それぞれ死角が違う。管理者が配った仕組み（SYSVOL・タスク・Intune）とMSIの中身を先に調べ、.vbs の検索で端末側を広く見て、Sysmonで実際の実行を確かめる
  • MSIのカスタムアクションとExcelのマクロは、.vbs ファイルとしては見つからない。前者は種類6・38・50を探し、後者はOfficeを2508以降にそろえる
  • 新しくVBScriptで作らない。使っていないと確かめた端末は、テストのうえで先に無効にしておく

VBScriptの廃止は、期限がまだ先に見える話です。それでも、配布用の共有フォルダーにあるMSIとSYSVOLの中を調べるところまでは、管理用の端末1台から今日始められます。