VBAの制約と置き換え先の知識マップ(知識グラフ)
VBAはOfficeデスクトップアプリの内側で動くイベント駆動言語で、Excel for the webでは作成・実行・編集ができず、インターネット由来ファイルのマクロは既定でブロックされます。このブロックは信頼できる場所・信頼済みサイト・信頼された発行元とコード署名証明書といった仕組みで個別に回避できます。VBAはOfficeのサーバー側自動化には向かず、Microsoftは無人での帳票生成にOpen XML形式による直接生成を推奨しています。古いDeclare文は64bitのOfficeで動かないことがあり、外部.vbsの実行やVBScript.RegExpへの依存はVBScriptの段階的廃止の影響を受け得ます。置き換え先は一つではなく、重い業務ロジックは.NET DLLへ、クロスプラットフォーム拡張はOffice Add-insへ、M365上のワークフローはOffice ScriptsとPower Automateへと、責務ごとに分けるのが現実的です。
VBA(Visual Basic for Applications)
Officeアプリケーションに組み込まれたBASIC系のマクロ言語で、ExcelやAccessなどからCOMコンポーネントを呼び出せる。
Excel for the web
ブラウザ上で動くExcelのWeb版で、VBAマクロの作成・実行・編集はできない。
インターネット由来マクロの既定ブロック
インターネット由来のOfficeファイルに含まれるVBAマクロの実行を、既定でブロックするMicrosoftのセキュリティ既定値。
Macros from the internet are blocked by default
Zone.Identifier(Mark of the Web)
ブラウザーなどでダウンロードしたファイルに付与される代替データストリーム。ファイルの出所(インターネット由来など)を記録し、SmartScreenや保護ビューの判定材料になる。
信頼できる場所
指定したフォルダーに置いたOfficeファイルは、Mark of the Webの確認を飛ばしてマクロを実行できるようにする設定。
信頼済みサイト/ローカル イントラネット ゾーン
ファイルサーバーやSharePointのドメインをInternet Explorerセキュリティゾーンへ登録し、そこに置かれたOfficeファイルのマクロブロックを回避する設定。
信頼された発行元ストア
信頼する発行元のコード署名証明書を登録する論理ストア。
コード署名証明書
ソフトウェアの発行元を証明し、改ざんを検出するための証明書。
Authenticode証明書
サーバーサイドのOffice自動化
ASP.NET、DCOM、NTサービスなど無人・非対話のクライアントアプリケーションやコンポーネントからOfficeアプリを自動操作すること。Microsoftは推奨せずサポートもしないと明言している。
無人・非対話のOffice Automation
Open XML形式
Excelアプリを起動せずに、Officeファイルの中身を直接組み立てるためのファイル形式。無人での帳票生成の代替手段として推奨される。
無人帳票生成
夜間バッチやサービスなど、人手を介さずにExcel帳票などを大量生成する要件。
夜間バッチでの帳票大量生成
bitness一致要件
ネイティブモジュール(in-procのCOMコンポーネント、P/Invokeで呼ぶDLL、ベンダー提供SDKのDLLなど)を読み込むホストプロセスと、そのモジュールのビット構成(32bit/64bit)が一致していなければならないという制約。
32bit/64bitの一致
VBAの64bit対応(PtrSafe/LongPtr)
WindowsAPIをDeclareで呼ぶ古いVBAコードを、PtrSafe・LongPtr・LongLongなどで32bit/64bitの差を吸収できるよう書き直す対応。
64-bit VBA対応
COM(コンポーネントオブジェクトモデル)
公開インターフェース、レジストリ登録、Apartment Modelなどを土台にした、Windowsのバイナリ互換コンポーネントモデル。
ActiveX
実務ではCOMベースのコントロールやその周辺資産をまとめて指す言葉として使われる技術群。特に.ocx形式のUIコントロールやIE/コンテナへ埋め込む部品を含むことが多い。
ActiveXコントロール
OCX
ActiveXコントロールの実体を持つ.ocx形式のファイル。in-procの形態でホストプロセスに読み込まれる。
.ocxファイル
OLEカスタムコントロール
クロスプラットフォームのOffice拡張
Windows/Mac/iPad/ブラウザなど複数プラットフォームをまたいで同じ拡張機能を使いたいという要件。
Office Add-ins
HTML/CSS/JavaScriptで構築し、Windows/Mac/iPad/ブラウザをまたいで動作しつつ中央配布にも向く、Officeのクロスプラットフォーム拡張の仕組み。
M365上のクラウドワークフロー
OneDrive・SharePoint・Teams・Outlook・FormsなどM365上のブックやデータを回す業務フロー。
OneDrive/SharePoint上のブックを回すワークフロー
Officeスクリプト(Office Scripts)
TypeScriptでExcelを操作するスクリプト機能で、Excel専用でブックにのみアクセスでき、Power Automateのクラウドフローから呼び出せる。
Power Automate
Microsoft Formsなどのトリガーから、SharePointへの転記や通知などのアクションを自動化するMicrosoftのクラウドフローサービス。Formsコネクタにはトリガー「新しい応答が送信されるとき」とアクション「応答の詳細を取得」がある。
クラウドフロー
VBScript.RegExp/外部.vbs依存
VBAプロジェクトが外部の.vbsファイルを実行したり、VBScript.RegExpを参照設定または遅延バインディングで使ったりしている状態。
VBScript.RegExp参照
VBScriptの段階的廃止
Windowsにおいて進められている、VBScriptを段階的に廃止していく取り組み。
.NET(Core以降)
.NET Frameworkの後継となる、クロスプラットフォーム対応の.NETランタイム(.NET 5以降)。
モダンな.NET
Excel for the webではVBAマクロの作成・実行・編集ができない
インターネット由来のOfficeファイルに含まれるVBAマクロの実行は、既定でブロックされる
ダウンロードしたファイルに付与されるMark of the Web(Zone.Identifier)が、Officeの既定のマクロブロックが働く判定材料になる
信頼できる場所に置いたファイルは、Mark of the Webの確認を飛ばしてVBAマクロを実行できるよう構成できる
信頼済みサイトやローカル イントラネット ゾーンへドメインを登録すると、そこに置かれたファイルのVBAマクロブロックを回避できる
マクロにコード署名し、その証明書を信頼された発行元へ登録することでも、既定のマクロブロックを回避してVBAを実行できる
信頼された発行元によるマクロ実行の許可は、マクロへのコード署名証明書の付与を前提とする
Officeは対話的なデスクトップとユーザープロファイルを前提に設計されており、VBAを介したサーバー側自動化は無人環境で不安定やデッドロックを起こし得るため推奨されない
無人での帳票大量生成には、Excelアプリを起動する自動化ではなくOpen XML形式などでファイルを直接組み立てる方法が推奨される
Officeアプリを起動するサーバー側自動化は、無人帳票生成の手段としては推奨されない
Declareで32bit専用の外部DLLやin-proc COMコンポーネントを呼んでいるVBAコードに限り、Office 2019/Microsoft 365の既定64bit環境でこのbitness一致要件の対象になる。そうした依存を持たないVBAコード一般には当てはまらない
Declareで外部APIを呼ぶ古いVBAコードを64bit環境で動かすには、PtrSafe・LongPtr・LongLongなどによる対応が前提となる
古いVBAコードは、COMコンポーネントへの依存を持つことがある
古いVBAコードは、ActiveXコントロールへの依存を持つことがある
古いVBAコードは、OCXコントロールへの依存を持つことがある
VBAはデスクトップ版Officeの内側でのみ動く技術で、複数プラットフォームをまたぐ拡張の実現手段にはならない
複数プラットフォーム向けの拡張を作りたい場合は、Office Add-insを見るべきとされている
デスクトップ中心のVBAは、OneDrive/SharePoint上のブックをM365ワークフローで回す用途には向かない
Office Scriptsは、安全でクロスプラットフォームなクラウドベースのソリューション向けとしてM365上のワークフローに推奨される
VBAからの移行先としてExcelブックの処理をフローに組み込む場合、Power AutomateはRun scriptアクションなどを通じてOffice Scriptsを呼び出して実行できる
外部.vbsの実行やVBScript.RegExpの参照設定・遅延バインディングに依存しているVBAプロジェクトに限り、この依存が前提となる
外部.vbsの実行やVBScript.RegExpへの依存は、進行中のVBScript段階的廃止の影響を受け得る。RegExpについてはMicrosoft 365 Version 2508以降でVBA側に既定で含める対応が進んでいる
VBAに残す範囲を薄くし、重い業務ロジックやHTTP・暗号・CSV/JSON処理は.NET DLLや別プロセスへ出す構成が、本記事の推奨である