突如止まったExcelマクロ ─ 全国を襲った「正規表現クラッシュ」
2025年8月末、全国の企業で長年稼働してきたExcelマクロが、ある日突然エラーを吐き出して動かなくなった。
「Assertion Failed!」──普段は見慣れないエラーメッセージに、現場は騒然とした。
原因はMicrosoftが配信した Office Version 2508 の自動更新だった。
このバージョンから、28年間Windowsに組み込まれてきた VBScriptの廃止プロセス が本格的に進められ、Excel VBAから呼び出していた VBScript.RegExp オブジェクトが正常に動作しなくなったのである。
多くの企業では、正規表現を使った文字列処理が請求書生成や帳票整理、ログ解析といった“日常業務の奥底”に埋め込まれていた。
その基盤が、一夜にして崩れ落ちたのだ。
この障害は一過性の不具合ではない。
むしろ「これから始まる本番」の幕開けにすぎない。
Microsoftはすでに 2026年以降にVBScriptを完全削除する計画 を公式に発表している。
今回の正規表現クラッシュは、その予兆にすぎず、次はもっと広範囲で深刻な被害が生じることはほぼ確実だ。
自動更新の罠 ─ “便利さ”が招いた致命傷
Office 365 をはじめとする Microsoft 製品は、いまやクラウド連携を前提に「常に最新」を押し出している。
利用者は更新を意識することなく、毎月のようにセキュリティパッチや機能強化が降ってくる。
それは一見すると安心・安全に見えるが、裏を返せば「検証の余地がない強制アップデート」ということでもある。
今回の正規表現クラッシュは、まさにその裏側が突き刺さった事例だった。
多くの企業では 検証環境を用意せず、本番に直撃でアップデートを受け入れていた。
「いつも通り更新したら、次の日からマクロが動かなくなった」──そんな声がSNSやコミュニティに溢れた。
本来であれば、こうした更新は 検証環境で互換性確認を行い、その後に段階的に展開 するべきだ。
ところが現実はどうか。中小企業はもちろん、大手企業ですら「Officeのアップデート＝勝手に適用されるもの」と思い込んでいる。
情報システム部門も工数不足から「ノーガード運用」を容認し、結果として 自動更新が業務停止のトリガー になってしまった。
この構図は、単なる偶然や運の悪さではない。
むしろ必然だ。
「検証環境なしでの自動更新」は、いずれ大事故を招くと分かりきっていた。
もしこれが大手企業で顕在化すれば、システム統括責任者（ITO）の重過失として、辞職や更迭に直結してもおかしくない。
自動更新は便利さの象徴であると同時に、企業ITにとっては 最も危険な“時限爆弾” なのだ。
2026年に控えるカタストロフ ─ 本当の爆弾はまだ先にある
今回の不具合は、Excel マクロの一部で使われていた VBScript.RegExp が動かなくなったことに端を発する。
しかしこれはあくまで「警告弾」にすぎない。
Microsoft が公表しているロードマップでは、2026年以降にVBScriptコンポーネントそのものが完全に削除される。
つまり、今回のように「正規表現が一部おかしい」というレベルではなく、
VBScriptに依存している全てのマクロやシステムが、一夜にして動作不能になる のだ。
どんな影響が予想されるか──。
- ファイル操作系のマクロ
取引データやログをファイル分割・結合する処理が動かなくなり、システム連携が途絶。 - 帳票生成やレポート系のマクロ
大量のデータを成形して提出する仕組みが全滅し、納期や監督官庁への報告が即アウト。 - Access や独自アドインとの連携
VBScript COM オブジェクトを裏で呼んでいる場合は、利用者が気付かぬうちに全面停止。
そして何より深刻なのは、多くの企業でマクロ資産がブラックボックス化していることだ。
「誰が書いたか分からない」「担当者はすでに退職した」「ソースコードは散逸している」。
そのような状態で VBScript が削除されれば、改修どころか原因特定すら不可能になる。
今回の正規表現クラッシュで「想定外の停止」に震えた企業も、
本当の“カタストロフ”は2026年にやってくる ことを忘れてはならない。
Microsoftの思惑 ─ サブスク囲い込みか、それとも功労者の引退か
VBScript 廃止の背景には、Microsoft が進める「最新環境への統一」という明確な意図がある。
表向きの理由は「セキュリティ強化とモダナイゼーション」だが、実際には Microsoft 365 サブスクリプションへの誘導 という戦略的側面が透けて見える。
近年の Windows 11 でも、システム要件を厳しく設定して古いハードウェアを切り捨てたり、強制的にアカウント連携を求めたりと、ユーザーを困惑させるような動きが散見される。
今回の VBScript 廃止も、現場にとっては「またMicrosoftが勝手に決めた変更に振り回されている」という印象が強いだろう。
しかし一方で、冷静に振り返れば VBScriptは28年間もWindowsに組み込まれ続けてきた のだ。
1996年に登場した技術を、2020年代半ばまで後方互換のために維持してきたこと自体、営利企業としては異例の粘り強さである。
セキュリティリスクを抱えながらも、多くの企業ユーザーの資産を守るために数十年サポートを継続した、という見方もできる。
つまり、VBScript 廃止は 「冷酷な囲い込み戦略」でもあり、同時に「長年の功労者の引退」 でもある。
企業にとっては痛みを伴う決断だが、Microsoft にとっては避けられない進化の一歩なのだ。
ノーコード／OSSの逆襲 ─ Excel依存からの逃避路
Microsoft は VBScript 廃止をきっかけに、ユーザーを最新Officeとサブスクリプションモデルへと誘導しようとしている。
だが、その思惑がすんなりと実現するとは限らない。
なぜなら、いま世界は 「Excelに縛られない選択肢」 を急速に手に入れつつあるからだ。
1. ノーコード／ローコードツールの台頭
Airtable、Notion、Zapier、Power Automate──これらのツールはブラウザ上で直感的に操作でき、データ処理や業務フローを自動化できる。
かつてはVBAマクロでしか実現できなかった業務効率化を、非エンジニアでも構築可能にしてしまった。
2. OSSとクラウドサービスの普及
Google Sheets と Apps Script、Python＋pandas、RPA系のオープンソースフレームワーク。
これらは無料または低コストで利用でき、しかもコミュニティの支援も厚い。
「Excelでなければならない」という理由がどんどん薄れている。
3. 若い世代の意識
新卒エンジニアやデータサイエンティストの多くは、もはやVBAを学んでいない。
彼らにとって「データ処理＝Python」「業務効率化＝SaaS連携」であり、VBScriptどころかVBAすら「時代遅れ」の印象だ。
VBScript廃止は、Microsoftにとって「囲い込みのチャンス」であると同時に、
ユーザーがExcel依存から脱却するきっかけにもなり得る。
もし自動更新で痛い目を見た企業が、ノーコードやOSSの魅力に気付き、資産を丸ごと移行してしまえば、Microsoft の目論見は裏目に出る。
「VBScript廃止でサブスク収益ウッシッシ」と考えていたら、逆に “Excel離れ”が加速するシナリオ も十分にあり得るのだ。
Accessゾンビプログラムの罠 ─ 真の時限爆弾
Excelマクロの停止は派手に表面化した。
だが現場に潜むもっと深刻な爆弾は、Access上で動き続けるゾンビプログラムだ。
1990年代から2000年代にかけて、多くの中小企業や自治体は「基幹システムを外注する余裕がない」現実の中で、Accessを使って独自の受発注管理や顧客台帳、売掛・買掛処理システムを構築してきた。
それらは一見便利な内製アプリケーションだが、内部ではVBScriptやActiveX、COM呼び出しに深く依存している。
問題は、それらの資産が 完全に属人化し、ブラックボックス化している ことだ。
- 開発者はすでに退職
- ドキュメントは存在しない
- コードの全容は誰も把握していない
それでも業務が止められないため、「触れないけど動かし続ける」しかない。こうしてシステムは“ゾンビ化”する。
2026年、VBScriptコンポーネントが完全削除されれば、これらのゾンビプログラムは一斉に息絶える。
Excelマクロの停止が“業務フローの一部の混乱”で済むなら、Accessゾンビの崩壊は 業務基盤そのものの崩壊 に直結する。
企業ガバナンスへの問い ─ 放置されたブラックボックスの代償
VBScript 廃止の衝撃は、単なる技術的トラブルでは終わらない。
むしろ浮かび上がったのは、企業のITガバナンスがいかに脆弱であるかという現実だ。
多くの組織では、業務を支えるExcelマクロやスクリプト資産が「ブラックボックス化」している。
- 誰が書いたか分からない
- ドキュメントが存在しない
- 担当者はすでに退職済み
- 改修もテストもされず、惰性で動き続けている
こうした“属人化した遺産”が、ミッションクリティカルな業務フローを静かに支えている。
その脆さを突き破ったのが、今回の自動更新とVBScript廃止だった。
本来なら、2000年問題を経験した世代は「技術的負債を放置すると大事故につながる」ことを痛感しているはずだった。
しかし実際には、「どうせ誰かが直してくれる」という安易な期待のもと、ブラックボックスは放置され続けてきた。
もしこれが大手企業で顕在化すれば、単なるIT部門の不具合では済まない。
情報システム統括責任者（ITO）の重過失として、辞職や更迭が現実味を帯びる。
取引先や株主からの信用失墜は計り知れず、経営リスクに直結するのだ。
VBScript 廃止は、企業に対してこう問いかけている。
- IT資産を把握しているか？
- 自動更新に備えた検証プロセスを持っているか？
- 属人化を排し、技術的負債を管理しているか？
これらに「Yes」と答えられない企業は、2026年以降の“カタストロフ”で確実に傷を負うことになる。
想定すべき“顕在化シナリオ”
今回の正規表現クラッシュは氷山の一角にすぎない。
実際にどんな現場で、どのような破綻が起こりうるのか──いくつかの典型例を挙げておく。
1. 製造業の生産ライン管理
- 現状：生産計画や作業手順を Excel マクロで自動生成。正規表現で品番やロット番号を処理。
- 破綻時：アップデート後、帳票生成が全停止。生産ラインがストップし、納期遅延が連鎖。取引先への違約金や信用失墜に直結。
- 放置の結末：「数十億円規模の損害が、一晩で顕在化する。」
2. 金融・保険のレポート業務
- 現状：膨大な取引ログや契約データを Excel マクロで集計・加工。CSV → Excel → 帳票化がルーチン化。
- 破綻時：定期報告が提出不能。監督官庁への報告遅延は、業務停止命令や行政処分につながる。
- 放置の結末：「たかが正規表現の崩壊で、ライセンス停止リスクが現実化する。」
3. 医療・福祉分野の請求システム
- 現状：診療報酬明細や介護保険請求をマクロで整形し、国保連へ電子提出。VBScript COM に依存。
- 破綻時：請求データが提出できず、数千万円単位のキャッシュフローが一ヶ月単位で途絶。中小病院・施設なら即経営危機。
- 恐怖の結果：「“VBScript廃止”は診療報酬の未払いという形で直撃する。」
4. 中小企業の受発注・在庫管理
- 現状：Access＋Excel マクロで在庫照合や受注書発行。担当者が独自に組んだ VBScript 処理に依存。
- 破綻時：伝票発行が止まり、納品ができず売上が消える。しかも担当者はすでに退職済み、ソース不明で修復不能。
- 放置の結末：「“たった一本のマクロ”が倒産の引き金になる。」
5. 行政・自治体の内部事務
- 現状：予算執行や住民税処理で使う内製ツールが VBA＋VBScript ベース。
- 破綻時：税や補助金の計算がストップし、市民サービスの遅延・混乱が報道沙汰に。
- 放置の結末：「公共サービスが止まるのは“IT担当の怠慢”という烙印になる。」
結論 ─ 放置か、行動か
今回の正規表現クラッシュは偶然に起きた天災ではない。
Microsoft 自身が、すでに VBScript 廃止のロードマップ を公式に発表しているからだ。
2024年5月、Microsoft Tech Community の Windows IT Pro Blog に掲載された記事
「VBScript deprecation: Timelines and next steps」
そこで示されたのは、三段階の明確な計画だった。
- VBScript を “Feature on Demand” として段階的に切り離す
- デフォルトで無効化し、互換性利用は制限付きにする
- 2026年以降、コンポーネントを完全削除する
さらに、Microsoft 365 Developer Blog では「VBAプロジェクトのVBScript依存部分を置き換えるための具体策」まで解説されている。
つまり、Microsoft は公式に「消します」と宣言している のだ。
いま取るべき行動
- 資産の棚卸し：どの業務でVBScriptが使われているのかを洗い出す
- 検証プロセス：更新を本番に直撃させないテスト環境を整える
- 代替ロードマップ：PowerShell・.NET・Python、あるいはノーコードツールへの移行計画を立てる
- 属人化の解消：ブラックボックス化したマクロ資産を可視化・共有する
最後の警告
2000年問題は、世界が総力を挙げて備えたから大きな混乱を避けられた。
だが今回の VBScript 2026年問題は、ほとんどの企業が「誰かが解決してくれるだろう」と放置している。その他責志向を自責思考に転換できなければ、会社を救うことは難しい。
放置は資産ではない。放置は負債だ。
そしてその負債は、2026年に確実に利子を付けて跳ね返ってくる。
選択肢は二つしかない。
いま行動して危機を回避するか、それとも破綻を待つか。
未来を決めるのは、企業自身の姿勢である。
参考：Microsoft の公式発表
- 「VBScript deprecation: Timelines and next steps」（Windows IT Pro Blog, Microsoft Tech Community, 2024年5月）
Microsoft が VBScript 廃止の全体ロードマップ（三段階フェーズ）を、まず発表した中心記事です。TECHCOMMUNITY.MICROSOFT.COM ここでは、VBScript を Windows の“Feature on Demand（FOD）”として提供しつつ段階的に無効化 → 最終的に完全削除する流れが整理されており、影響を受けうる VBA プロジェクトやシステム運用者へのアラートも明記されています。TECHCOMMUNITY.MICROSOFT.COM - 「VBScript deprecation: Detection strategies for Windows」（Windows IT Pro Blog, 2025年5月）
第2フェーズ（FODをデフォルト無効化）に備えて、組織内で VBScript がどこで使われているかを検知し、移行準備を始めるための具体的な手法（Sysmon や DLLロード監視、DISM による機能削除など）が提示されています。TECHCOMMUNITY.MICROSOFT.COM - 「Prepare your VBA projects for VBScript deprecation in Windows」（Microsoft 365 Developer Blog, 2025年9月）
VBA 開発者向けに、「VBScript廃止後にどう対応すればいいか」という移行ガイダンスが示されています。特に、Office 2508 以降で提供される VBA 内蔵の RegExp クラスの活用や、VBS 呼び出し部分の書き換え案などが具体的に説明されています。Microsoft for Developers
