VBA とは何か - 制約、将来性、置き換えるべき場面と現実的な移行パターン

小村 豪

doi:10.5281/zenodo.21589720

VBA とは何か - 制約、将来性、置き換えるべき場面と現実的な移行パターン

2026年03月23日 01:00 · 更新日: 2026年08月02日 · 小村豪 · VBA, Excel, Office, 既存資産活用・移行, Windows開発

更新履歴(4件・最終更新 2026年08月02日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

2026年08月02日: 記事の冒頭に「この記事の知識マップ」節を追加しました。本文で扱っている概念とその関係を、要約・図・詳細ページへのリンクにまとめたものです。本文の主張は変えていません。
2026年08月01日: 外部レビュー(1283件)への対応として本文を更新しました。個々の変更内容は、この下の履歴を参照してください。
2026年08月01日: 置き換え先の比較表を7章の冒頭に追加しました。Office Scriptsの利用条件を表にし(対象ライセンス、OneDrive for Business必須、Power Automateから使う場合の要件とE1・F3の制限)、マクロブロックの回避策の表、最小の`Sub`の例、VBScript依存の確認手順を追加しました。プレミアムコネクタの要件は一次情報で裏が取れなかったため書いていません。
2026年07月31日: 本文中の関連記事へのリンクの文言が、リンク先の現在のタイトルと食い違っていたのを、実際のタイトルに揃えました。本文の内容は変えていません。
2026年03月23日: 初版公開

この記事を引用する(DOI: 10.5281/zenodo.21589720)

この記事はZenodoにアーカイブされています。常に最新版へ解決されるDOIと、いま表示している版に固定されたDOIの両方を下に示します。

小村豪(2026)「VBA とは何か - 制約、将来性、置き換えるべき場面と現実的な移行パターン」合同会社小村ソフト. https://doi.org/10.5281/zenodo.21589720 https://staging.comcomponent.com/blog/2026/03/23/000-what-is-vba-limits-future-replacement/

DOI(最新版): 10.5281/zenodo.21589720
DOI(この版): 10.5281/zenodo.21732739

VBA の相談では、こういう話がよく混ざります。

そもそも VBA って何なのか
マクロは危ないと言われるが、もう使うべきではないのか
これから使えなくなるのか
Office Scripts や Power Automate に全部移せばよいのか
既存の .xlsm や Access 資産は残すべきか、捨てるべきか
Excel を夜間バッチやサーバーで動かしてもよいのか

このへんは、1 つの答えで全部きれいに片づくテーマではありません。最初に見るべきなのは、新しいか古いか よりも、どこで実行するのか、誰が使うのか、Excel / Access そのものが UI なのか、無人実行なのか です。

この記事では、VBA とは何か、どこに制約があるのか、これから使えなくなるのか、置き換えるべき場面はどこか、どう段階移行すると現実的か、という順番で整理します。なお、内容は 2026 年 3 月時点 で確認できる Microsoft の公式情報を前提にしています。¹²³⁴⁵

1. まず結論

先に結論だけ並べておきます。

VBA は Office デスクトップアプリを拡張するためのイベント駆動言語 です。Excel や Word、PowerPoint、Access などの中で動くことが前提の技術です。¹
少なくとも 2026 年 3 月時点で、Microsoft の公式情報として 「VBA 自体を近いうちに終了する」 という明確なアナウンスは確認できません。いま起きているのは「突然の全廃」よりも、使える場所と前提条件がはっきりしてきた という変化です。¹²³⁴
具体的には、Excel for the web では VBA を作成・実行・編集できません。また、インターネット由来ファイルのマクロは既定でブロック されます。²³
したがって、いまの論点は「VBA を全部捨てるか」ではなく、どの領域を VBA に残し、どの領域を外へ出すか です。
特に、無人実行、サーバー実行、複数人運用、ブラウザ対応、中央配布、厳しい監査 が必要な処理は、VBA だけで抱え込まないほうが自然です。Microsoft も、Office のサーバー側自動化を推奨・サポートしていません。⁶
置き換え先は 1 つではありません。 Excel を残すなら .NET DLL や別プロセスへ処理を逃がす、Microsoft 365 上の業務フローなら Office Scripts + Power Automate、クロスプラットフォーム拡張なら Office Add-ins、そもそも Excel が UI ではなくなっているなら Windows アプリや Web アプリへ出す、という分け方が現実的です。⁴⁵⁶

要するに、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へと、責務ごとに分けるのが現実的です。

flowchart LR
    accTitle: VBAの制約と置き換え先の知識マップ
    accDescr: VBAがOfficeデスクトップの内側に閉じた拡張言語であること、Excel for the webとの非互換、既定のマクロブロックと信頼できる場所・信頼済みサイト・信頼された発行元による回避、サーバー側自動化の非推奨とOpen XMLへの代替、bitnessやVBScript依存という制約、Office ScriptsやOffice Add-insや.NETへの責務ごとの置き換え先を示す図
    vba["VBA(Visual Basic for Applications)"]
    excel_for_the_web["Excel for the web"]
    macro_block_policy["インターネット由来マクロの既定ブロック"]
    zone_identifier["Zone.Identifier(Mark of the Web)"]
    trusted_location["信頼できる場所"]
    trusted_site_zone["信頼済みサイト/ローカル イントラネット ゾーン"]
    trusted_publisher_store["信頼された発行元ストア"]
    code_signing_cert["コード署名証明書"]
    server_side_office_automation["サーバーサイドのOffice自動化"]
    open_xml_format["Open XML形式"]
    unattended_report_generation["無人帳票生成"]
    bitness_match_requirement["bitness一致要件"]
    vba_64bit_migration["VBAの64bit対応(PtrSafe/LongPtr)"]
    com["COM(コンポーネントオブジェクトモデル)"]
    activex["ActiveX"]
    ocx["OCX"]
    cross_platform_office_extension["クロスプラットフォームのOffice拡張"]
    office_addins["Office Add-ins"]
    m365_cloud_workflow["M365上のクラウドワークフロー"]
    office_scripts["Officeスクリプト(Office Scripts)"]
    power_automate["Power Automate"]
    vbscript_regexp_dependency["VBScript.RegExp/外部.vbs依存"]
    vbscript_deprecation["VBScriptの段階的廃止"]
    dotnet[".NET(Core以降)"]
    vba -->|"両立しない"| excel_for_the_web
    macro_block_policy -.->|"防止する"| vba
    zone_identifier -->|"原因になり得る"| macro_block_policy
    vba -->|"で構成できる"| trusted_location
    vba -->|"で構成できる"| trusted_site_zone
    vba -->|"で構成できる"| trusted_publisher_store
    trusted_publisher_store -->|"前提とする"| code_signing_cert
    vba -->|"用いるのは非推奨"| server_side_office_automation
    open_xml_format -->|"推奨される対応"| unattended_report_generation
    server_side_office_automation -->|"用いるのは非推奨"| unattended_report_generation
    vba -.->|"前提とする"| bitness_match_requirement
    vba -.->|"前提とする"| vba_64bit_migration
    vba -.->|"利用する"| com
    vba -.->|"利用する"| activex
    vba -.->|"利用する"| ocx
    vba -->|"両立しない"| cross_platform_office_extension
    office_addins -->|"推奨される対応"| cross_platform_office_extension
    vba -->|"用いるのは非推奨"| m365_cloud_workflow
    office_scripts -->|"推奨される対応"| m365_cloud_workflow
    power_automate -.->|"利用する"| office_scripts
    vba -.->|"前提とする"| vbscript_regexp_dependency
    vbscript_regexp_dependency -.->|"両立しない"| vbscript_deprecation
    dotnet -->|"推奨される対応"| vba

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

2. VBA とは何か

VBA は Visual Basic for Applications の略で、Microsoft Office に付属する Visual Basic の一種です。Microsoft の公式ドキュメントでも、Office アプリケーションを拡張するためのイベント駆動型プログラミング言語 と説明されています。¹⁷

ここで重要なのは、VBA を 汎用のアプリ開発基盤 として見るより、Office アプリの内側に差し込む拡張言語 として見るほうが実態に近い、という点です。

たとえば Excel なら、こうした対象に近い場所で動きます。

Workbook
Worksheet
Range
ボタンやフォーム
ブックを開いたとき、保存したとき、セル変更時のイベント

つまり VBA の強みは、Excel や Access の画面・帳票・ブック構造にとても近い ことです。利用者がデスクトップの Office を開いて、ボタンを押して、ローカルファイルや共有フォルダのデータを処理して、そのまま帳票を出す。そういう 「利用者の手元で完結する自動化」 には今でも強みがあります。¹

実際のコードは、たとえばこれくらいの短さです。シート上のボタンに割り当てて使う、いちばん小さい形です。

' Excel の標準モジュールに置く。シート上のボタンから呼び出す想定
Option Explicit

Public Sub ClearMeisai()
    Dim ws As Worksheet
    Set ws = ThisWorkbook.Worksheets("明細")

    If MsgBox("明細シートの 2 行目以降を消します。よろしいですか。", _
              vbOKCancel + vbQuestion, "確認") <> vbOK Then
        Exit Sub
    End If

    ws.Rows("2:" & ws.Rows.Count).ClearContents
End Sub

シートに図形やフォームコントロールのボタンを置き、右クリックの「マクロの登録」でこの ClearMeisai を選べば、押すたびにこの処理が走ります。ここで見てほしいのは、ThisWorkbook、Worksheets、Rows といった Excel のオブジェクトが、変換や API 呼び出しをはさまずそのまま出てくる ことです。「Office の内側で動く言語」というのは、具体的にはこの近さのことです。逆に言えば、この近さが失われる置き換え先では、同じ手数では書けません。

逆に言うと、VBA の本来の守備範囲は、最初から サーバー、ブラウザ、モバイル、マルチテナントな Web システム ではありません。

3. なぜ今でも使われるのか

VBA が今でも現場に残り続ける理由は、単に「古いから惰性で残っている」だけではありません。

まず、Excel や Access には、単なるデータではなく 業務手順そのもの が入り込みやすいです。

帳票の見た目
印刷設定
入力チェック
月次処理の順番
部門ごとの例外ルール
現場が長年慣れた操作手順

このへんは、別システムへ移すときに「コード移植」だけでは済みません。 見た目、操作、例外、運用 が一体になっているので、VBA 資産は見た目以上に仕様を抱えています。

また、VBA は Office のオブジェクトモデルに近いため、利用者の目の前にある Excel そのものを操作して結果を返す、という用途では手数が少ないです。この近さは、後継候補を考えるときにも大事で、単に新しい技術へ書き換えればそれで終わり とは限りません。

実務では、こう考えるのが自然です。

Excel が UI であり続けるなら、VBA を一部残す価値がある
Excel は入出力だけでよいなら、中身のロジックは外へ出しやすい
Excel 自体がもう本来の UI ではないなら、作り直しの候補になる

4. VBA の主な制約

4.1 デスクトップ前提である

一番大きい制約はこれです。 VBA は、基本的に デスクトップ版 Office の内側 で動く技術です。

Microsoft の公式情報でも、Excel for the web では VBA を作成・実行・編集できず、マクロ付きブックを開いて編集はできても、VBA の実行はできない とされています。²⁸

この時点で、こういう要件とは相性が悪くなります。

ブラウザで完結したい
Mac / iPad / Web をまたいで同じ拡張を使いたい
管理者が中央配布したい
ローカルの Excel デスクトップアプリに依存したくない

Microsoft 自身も、複数プラットフォーム向けの拡張を作りたいなら Office Add-ins を見るべき と VBA のドキュメント側で案内しています。⁹⁵

4.2 セキュリティと配布の摩擦が大きい

VBA が「使えなくなった」と誤解されやすい理由の大きな部分は、実は セキュリティ強化 です。

Microsoft は、インターネット由来のファイルに含まれる VBA マクロを既定でブロック するようにしています。メール添付やダウンロードした .xlsm をそのまま開いても、昔より素直には実行されません。³

これはセキュリティとしては正しい方向です。ただし運用側から見ると、

添付で配ると動かない
社外サイトから落としたテンプレートが動かない
OneDrive / SharePoint / ネットワーク経由での扱いが分かりにくい
「有効化してください」という案内が運用の弱点になる

という摩擦が増えます。

ただし、「動かないので終わり」ではありません。Microsoft は同じドキュメントで、信頼するファイルのマクロを動かすための手段 も整理しています。運用でよく使うのは次の 4 つです。³

手段	何をするか	向いている場面
Mark of the Web を外す	ファイルのプロパティで「ブロックの解除」にチェックを入れる。PowerShell の `Unblock-File` でも同じことができます	単発のファイル、少人数
信頼できる場所	指定したフォルダーに置いたファイルは、Mark of the Web の確認を飛ばして開きます	定期的に配られる帳票、テンプレート、社内配布物
デジタル署名 + 信頼された発行元	マクロにコード署名し、その証明書を利用者の「信頼された発行元」へ配ります	継続的に配布する社内マクロ、ベンダー製マクロ
信頼済みサイト / ローカルイントラネットゾーン	ファイルサーバーや SharePoint のドメインをゾーンへ登録します	共有フォルダーや SharePoint に集約されている場合

同時に、注意点もはっきりしています。³

信頼できる場所と信頼済みサイトは、そこに置かれたものを丸ごと信頼する ことになります。「誰が書き込めるか」を管理できる場所に限る必要があります。
信頼された発行元は Windows 全体の設定 で、Office だけの話ではありません。
Excel のアドイン（.xla / .xlam）は、Mark of the Web が付いていると 署名して発行元を信頼しても動きません。この場合は Mark of the Web を外すか、信頼できる場所へ置くかのどちらかです。
ネットワーク共有を IP アドレスで開いていると、それだけで信頼済みサイトにもローカルイントラネットにも当たらず、ブロックされることがあります。

言い換えると、VBA を残す判断をするなら、コードの話とは別に 「どこへ置いて、どう信頼させるか」を配布設計として決める 必要があります。ここを決めないまま .xlsm をメール添付で配り続ける運用が、いちばん摩擦の大きい形です。

つまり、VBA の問題は「言語機能」だけではなく、配布と信頼の設計 でも起きます。

4.3 32bit / 64bit の壁がある

Office は 32bit 版と 64bit 版があり、Office 2019 と Microsoft 365 では既定が 64bit です。⁷

そのため、古い VBA コードのうち、特に Windows API を Declare で呼んでいるもの は、64bit 環境でそのまま動かないことがあります。 Microsoft も、PtrSafe、LongPtr、LongLong などを使って 32bit / 64bit の差を吸収する必要があると案内しています。⁷

ここでつらいのは、コードだけでなく、こうした依存も一緒に問題になりやすいことです。

古い COM / ActiveX / OCX
32bit 前提の外部 DLL
レジストリ登録前提の部品
Office の参照設定ずれ

つまり、VBA の移行は 言語の書き換え というより、Office bitness と外部依存の整理 になることがかなり多いです。

4.4 無人実行・サーバー実行に向かない

ここはかなり重要です。 Microsoft は、Office アプリケーションのサーバー側自動化を推奨・サポートしていない と明言しています。Office は、対話的なデスクトップとユーザープロファイルを前提に設計されており、無人環境では不安定やデッドロックが起き得ます。⁶

なので、こういう構成は危険寄りです。

Windows サービスから Excel を起動する
ASP.NET や DCOM から Office を自動化する
タスクスケジューラ上で見えない Excel を延々回す
サーバー上の Excel に帳票生成を丸投げする

「たまに動く」ことはあります。ただ、動いていることと、支えられる構成であることは別 です。

無人実行が必要なら、まず疑うべきは VBA ではなく、Excel アプリ自体を運転する構成 のほうです。

4.5 保守性・テスト性・差分管理で不利になりやすい

VBA は、ブックや Access ファイルの中にコードが閉じ込みやすいです。その結果、こうした問題が起きやすくなります。

どのファイルが正本なのか曖昧になる
フォーム、シート、標準モジュールに責務が散る
参照設定や ActiveX 依存が環境ごとにずれる
コードレビューや差分確認がしにくい
単体テストを作りにくい
Excel のセル番地そのものが仕様化していく

これは VBA という言語だけの問題ではなく、「Office ファイルの中に業務ロジックを持つ」構造の問題 です。小さな自動化では大きな問題にならなくても、業務システム化していくと急に効いてきます。

4.6 VBScript 依存がある場合は別の注意が必要

2025 年には、Microsoft 365 Developer Blog で Windows における VBScript の段階的廃止が、VBA プロジェクトにも影響し得る ことが案内されました。特に、外部 .vbs を実行しているケース や、VBScript.RegExp の参照に依存しているケース は影響対象になります。¹⁰

一方で Microsoft は、Microsoft 365 Version 2508（Build 19127.20154）以降の Windows 版 Office では RegExp クラスを VBA に既定で含める 形でも対応を進めています。¹⁰

自分の資産が影響を受けるかどうかは、次の 3 点を探せば判断できます。VBE の「編集」メニューにある検索でも、.bas / .cls へ書き出したテキストへの grep でも構いません。

探すもの	具体的な文字列	見つかったときの意味
遅延バインディングでの RegExp 利用	`CreateObject("VBScript.RegExp")`	VBScript のライブラリに依存しています
事前バインディングでの RegExp 利用	参照設定の「Microsoft VBScript Regular Expressions 5.5」、コード上の `New RegExp`	同上。参照設定の一覧側にも出ます
外部 `.vbs` の実行	`WScript.Shell` の `Run` / `Exec` に `.vbs` を渡している箇所、`cscript` / `wscript` という文字列	VBScript ホストそのものに依存しています

参照設定の一覧は、VBE の「ツール」メニューの「参照設定」で確認できます。

このうち RegExp については、前述のとおり Microsoft 365 Version 2508（Build 19127.20154）以降の Windows 版 Office では、RegExp クラスが VBA 側に既定で含まれる 形で手当てが進んでいます。¹⁰ 影響が重いのは 3 行目の「外部 .vbs を実行している」パターンで、こちらは処理そのものを VBA 側か別の実行基盤へ寄せる検討が必要になります。資産台帳を作るとき（8.1）に、この 3 点も一緒に記録しておくと二度手間になりません。

ここで大事なのは、VBScript の廃止と VBA の廃止は同じ話ではない ということです。 VBA そのものが消える話ではなく、VBA からぶら下がっていた一部の外部依存を見直す必要がある、という理解のほうが正確です。

5. VBA はこれから使えなくなるのか

まず、「明日から全部使えなくなる」という話ではありません。ただし、「どこでも何にでも使える」時代でもありません。

少なくとも Microsoft の公式情報の読み方として、いま強く見えるのはこの方向です。

デスクトップ Office の拡張としての VBA は引き続き存在する¹
Web / クロスプラットフォーム側は Office Scripts や Office Add-ins を使い分ける⁴⁵⁹
マクロ配布の安全性は以前より厳しく扱う³
VBScript 依存のような周辺部品は将来の影響を受け得る¹⁰

さらに、Microsoft は Office Scripts について、VBA はデスクトップ中心、Office Scripts は安全でクロスプラットフォームなクラウドベースのソリューション向け だと明示しています。同時に、デスクトップクライアントで使える Excel 機能のカバー範囲は、現時点では VBA のほうが広い とも説明しています。⁴

この 2 つを並べると、かなり実務的な見え方になります。

デスクトップ Excel の深い操作 では、まだ VBA の守備範囲が広い
ブラウザ / M365 / 共有ワークフロー では、Office Scripts や Add-ins のほうが自然
だから、「全部 Office Scripts に変えればよい」でも、「VBA を永久に中心に置けばよい」でもない

VBA の将来は、消滅よりも境界の明確化 と見るのが自然です。

6. 置き換えるべきケース / 置き換えなくてよいケース

まずは雑だけれど役に立つ判断表を置きます。

状況	判断の目安	理由
利用者が自分の PC の Excel / Access を開いて使う、小規模な自動化	そのまま使う、または軽く整理する	VBA の守備範囲にかなり合っています
Excel は UI と帳票だけ残したいが、ロジックが重くなっている	ハイブリッド化する	VBA は薄く残し、重い処理は `.NET` や別プロセスへ出したほうが保守しやすいです
ブラウザ、Mac、iPad でも使いたい	VBA を中心にしない	VBA はデスクトップ前提で、Office Add-ins はクロスプラットフォームです⁵
OneDrive / SharePoint 上のブックを、M365 ワークフローで回したい	Office Scripts + Power Automate を検討	Office Scripts はクロスプラットフォーム / クラウド側の自動化向けです⁴¹¹
夜間バッチ、サーバー、サービスで無人実行したい	Excel 自動化をやめる	Microsoft は Office のサーバー側自動化を推奨・サポートしていません⁶
複雑な業務フロー、権限管理、監査、DB 連携が中心になっている	アプリ化 / システム化を検討	Office ファイル内ロジックでは限界が来やすいです

表の 2 行目に出てくる ハイブリッド化 は、この記事では 「Excel / Access を UI と帳票の入口として残したまま、業務ロジックや I/O だけを外の実行単位へ出す」 という意味で使っています。全面リプレイスとの違いは、利用者から見える画面と操作を変えないこと です。具体的な形は 7.1 で扱います。

この表で大事なのは、置き換えの判断軸が「VBA は古いから」ではない ことです。本当に見るべきなのは、実行環境、運用、配布、依存、監査、拡張性 です。

7. 現実的な置き換え先

具体的な話に入る前に、候補を 1 枚に並べておきます。6 章の判断表で「どちらへ寄せるか」を決めたら、この表で「その先が何を要求するか」を確認する、という順番で使ってください。

候補	どこで動くか	言語	前提・ライセンス	向く用途	詳細
VBA を残す	デスクトップ版 Office の内側	VBA	デスクトップ版 Office	Excel / Access が UI そのものである自動化	2 章・3 章
`.NET` DLL や別プロセスへ出す	利用者の PC。Excel から呼ぶか、別プロセスで動かす	C# など	.NET ランタイム。COM 公開するなら登録の設計も要る	重い業務ロジック、HTTP、暗号、CSV / JSON	7.1
Open XML などで直接生成	サーバーやバッチの実行基盤	C# / Python など	Office のインストールは不要	無人での帳票大量生成	7.2
Office Scripts + Power Automate	Microsoft 365 のクラウド側	TypeScript	M365 のビジネス / 教育向けライセンスと OneDrive for Business	OneDrive / SharePoint 上のブックを回すワークフロー	7.3
Office Add-ins	Windows / Mac / iPad / ブラウザ	HTML / CSS / JavaScript	Web でホストする場所と配布の仕組み	クロスプラットフォームの UI 拡張、中央配布	7.4
Windows / Web アプリ化	自前のアプリ	C# など	開発と運用の体制	権限、監査、DB が中心になった領域	7.5

いちばん見落とされやすいのは「前提・ライセンス」の列です。特に Office Scripts は条件がはっきりしているので、7.3 で個別に整理します。

7.1 Excel を残して、中身だけ `.NET` や別プロセスへ出す

いちばん現実的で失敗しにくいのは、これです。

画面や帳票の入口は Excel / Access のまま
ボタンや入力フォームも当面そのまま
ただし、業務ロジック、HTTP、暗号、CSV / JSON、重い計算、ファイル処理は外へ出す
VBA は「橋渡し」と「UI 操作」だけに寄せる

この構成の利点は、利用者の見た目と操作を壊しにくい ことです。全面リプレイスよりも、まず 責務を薄くする 方向で進められます。

7.2 無人実行や帳票生成は、Office アプリ自動化ではなくファイル直接生成へ寄せる

Excel 帳票を夜間バッチやサービスで大量生成したいなら、まず疑うべきは「VBA が古いか」ではなく、Excel アプリを起動していること自体 です。

Microsoft は、サーバー側での Office Automation を推奨していません。代わりに、Open XML 形式などを使って Office ファイルを直接扱う方法 を推奨しています。⁶

つまり、要件が

.xlsx を作りたい
定型帳票を大量に出したい
PDF 化したい
夜間バッチで回したい

のようなものなら、選ぶべき軸は Excel を運転するか ではなく、Excel ファイルを組み立てるか です。

7.3 Microsoft 365 上の業務フローなら Office Scripts + Power Automate

業務がすでに OneDrive / SharePoint / Teams / Outlook / Forms の上に寄っているなら、Office Scripts はかなり候補になります。

Microsoft は、Office Scripts を安全でクロスプラットフォームなクラウドベースのソリューション向け と説明しています。また、Power Automate と組み合わせることで、メールやフォームやスケジュールをトリガにして Excel 処理を自動化できます。⁴¹¹

ただし、その前に 利用条件 を確認する必要があります。ここはコストと環境の前提そのものなので、後から必ず効いてきます。¹²¹³

前提	内容
ライセンス	Office 365 Business / Business Premium / ProPlus / A3 / A5 / Enterprise E1 / E3 / E5 / F3 のいずれかが必要です。個人・家族向けサブスクリプションでは preview 扱いです
クライアント	Excel on the web、Excel for Windows の Version 2210 以降、または Excel for Mac
保存先	OneDrive for Business が必要です。スクリプトは `.osts` ファイルとして OneDrive の `/Documents/Office Scripts/` 配下に置かれ、SharePoint へ移すこともできます
共有設定	「組織内のユーザー」向けの共有リンクが有効になっている必要があります
ネットワーク	インターネット接続と、接続エクスペリエンスが有効であること
Power Automate から使う場合	Microsoft 365 のビジネスライセンスが必要です。Enterprise E1 と F3 は Power Automate 経由なら使えますが、Excel の中から直接 Power Automate 連携を使うことはできません
対象外	GCC High 以上の政府向けクラウドではサポートされません

つまり、Office Scripts は 「無料で付いてくる VBA の代わり」ではありません。ローカルの .xlsm を配って回していた運用と比べると、OneDrive / SharePoint と M365 ライセンスという前提が増えます。ここを見落としたまま「Office Scripts へ移行」と決めると、移行の途中でライセンス調達の話へ戻ることになります。

そのうえで、機能面も万能ではありません。

Office Scripts は Excel レベルのイベントをサポートしません
実行は 手動開始 または Power Automate からの呼び出し が基本です⁴
Power Automate 連携には Microsoft 365 のビジネスライセンス が必要です¹¹
Run script アクションには、1 ユーザーあたり 1 日 1,600 回、同期処理 120 秒 などの制限があります¹²

つまり、Office Scripts は「VBA の置換物」より、M365 上の自動化部品 と見たほうが正確です。

7.4 クロスプラットフォーム拡張が欲しいなら Office Add-ins

Word、Excel、Outlook などを Windows / Mac / iPad / ブラウザ で拡張したいなら、Office Add-ins が第一候補です。

Microsoft の公式ドキュメントでも、Office Add-ins は HTML / CSS / JavaScript で構築でき、複数プラットフォームで動作し、中央配布にも向く と説明されています。⁵

これは、たとえば次のような要件に向いています。

社内ポータルや基幹システムと Office をつなぎたい
Outlook / Excel / Word に同じ UI やコマンドを出したい
ユーザーの PC ごとのマクロ配布ではなく、管理者配布したい
ローカルな .xlsm 配布モデルから離れたい

VBA とは土俵が違うので、Excel の中にコードを書く 感覚とはかなり変わります。その代わり、運用と配布は整理しやすくなります。

7.5 Excel / Access 自体が本来の UI ではなくなっているなら、Windows アプリや Web アプリへ出す

こういう状態まで来ているなら、VBA の延命より アプリとして作り直す ほうが自然です。

画面遷移や権限制御が増えすぎている
DB、監査ログ、承認フロー、ユーザー管理が中心
外部機器連携や長時間処理がある
Excel のセルやフォームが業務仕様書の代わりになってしまっている
ブックを閉じたら状態管理が消えること自体がつらい

この場合、Windows 前提の業務ツールなら C# / .NET のデスクトップアプリ、利用者や端末が広いなら Web アプリ のほうが構造を素直にできます。

8. 段階移行の進め方

VBA の置き換えで一番危ないのは、最初から全部を 1 つの新技術へ寄せようとすること です。実務では、これから書く順番で段階を踏むほうがだいたい安全です。

8.1 まず資産台帳を作る

最初に洗い出したいのは、コード量そのものより 依存関係 です。

どの .xlsm / .xlam / .accdb / .mdb があるか
どれが実運用の入口か
参照設定に何が入っているか
Declare、外部 DLL、COM / ActiveX / OCX は何か
32bit / 64bit の前提はどうなっているか
どのマクロが誰のどの手順で使われているか
出力物は何か（Excel、CSV、PDF、印刷、メール送信など）

ここを曖昧にしたまま置き換えると、あとで「誰も触っていないと思ったマクロが月末だけ生きていた」みたいな事故が起きます。

8.2 コードを責務で分ける

次にやるのは、ファイル単位ではなく 責務単位 で分けることです。

Excel / Access の UI 操作
シート入出力
帳票レイアウト
業務ルール
外部 API / ファイル / DB I/O
バッチ処理
印刷 / 配布

この分け方をすると、残すもの、薄くするもの、外へ出すものが見えやすくなります。

8.3 置き換え先を責務ごとに決める

おすすめしやすい分け方はこうです。

UI とシート操作: 当面 VBA に残す
業務ロジック: .NET DLL、別プロセス、サービスへ出す
無人帳票生成: Open XML や直接生成へ寄せる
M365 ワークフロー: Office Scripts + Power Automate
クロスプラットフォーム UI: Office Add-ins
業務システム化した領域: Windows / Web アプリへ分離する

重要なのは、移行先を 1 つに統一しないこと です。 VBA 資産の中身は、だいたい複数の責務が混ざっています。

8.4 先にインターフェイスを固める

移行を始める前に、最低限ここは決めておいたほうがよいです。

入力は何か
出力は何か
エラー時にどう返すか
どのシート、どの名前付き範囲、どのファイルパスを契約にするか
どの時点で結果が確定したとみなすか

ここを決めないまま進めると、セル番地そのものが API になって壊れやすくなります。

8.5 並行稼働で比較する

特に帳票や集計は、いきなり切り替えないほうが安全です。

旧 VBA 版と新実装版を並行で出す
出力された .xlsx / CSV / PDF を比較する
日付、丸め、書式、印刷範囲の差を確認する
例外系と空データ系も試す

VBA 置き換えの事故は、たいてい「動くかどうか」ではなく、数字や書式が静かにずれる 形で起きます。

9. よくある失敗

9.1 「VBA は古いから、全部 Office Scripts へ」で始める

Office Scripts は有力ですが、Microsoft 自身が VBA のほうがデスクトップ Excel 機能のカバー範囲が広い と説明しています。さらに、Office Scripts は Excel レベルのイベントをサポートしません。⁴

なので、深い Excel デスクトップ依存のマクロを、そのまま横移しする発想は危険です。

9.2 無人実行なのに Excel 自体を起動し続ける

これはかなり多いです。動いている間は便利に見えますが、Microsoft は Office のサーバー側自動化を推奨していません。⁶

夜間バッチやサービスなら、Excel を運転する のではなく、Excel ファイルを組み立てる ほうへ寄せたほうが安全です。

9.3 画面、帳票、業務ルールを同時に全部変える

VBA 置き換えで本当に怖いのは、コード変換そのものより 業務仕様の取り落とし です。 Excel のシートや Access フォームには、コードに書かれていない運用ルールがかなり埋まっています。

全部を一気に変えると、「見た目は近いが月末だけ違う」みたいな事故が起きやすいです。

9.4 32bit / 64bit と外部参照を後回しにする

移行案件では、VBA コードそのものより、

Declare
外部 DLL
COM / ActiveX / OCX
Office bitness
参照設定

が先に爆発することがよくあります。ここを後ろに回すと、実装の終盤で一気につらくなります。⁷

9.5 VBScript の話と VBA の話を混同する

VBScript の段階的廃止は、VBA から見れば 一部依存の見直し の話です。 VBA 全体の終了と同じ意味ではありません。¹⁰

ここを混ぜると、「VBA が終わるらしい」という雑な社内情報だけが独り歩きしやすくなります。

10. まとめ

VBA をひとことで言うと、Office デスクトップアプリに密着した拡張言語 です。 Excel や Access のすぐそばで、利用者の手元の業務を自動化するには、今でもかなり実用的です。¹

ただし、これからの実務で大事なのは、VBA を 万能な中心技術として扱わない ことです。

ブラウザ / クロスプラットフォーム が欲しいなら、Office Scripts や Office Add-ins を見る⁴⁵
無人実行 / サーバー処理 なら、Office Automation を避ける⁶
重いロジックや外部連携 は .NET や別プロセスへ出す
Excel / Access がもう UI として苦しい なら、Windows アプリや Web アプリへ出す

答えは 「全部置き換える」でも「何も変えない」でもなく、「責務ごとに分けて、段階的に薄くする」 です。

VBA 資産は、雑に見ると古く見えます。ただ、実務ではその中に 業務仕様、運用手順、帳票設計、現場の慣れ がかなり詰まっています。

だからこそ、置き換えは翻訳ではなく、整理として進めるのが一番安全です。

11. 関連記事

12. 参考資料

Microsoft Learn, Office VBA Reference. “Office Visual Basic for Applications (VBA) is an event-driven programming language that enables you to extend Office applications.” ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Microsoft Support, Work with VBA macros in Excel for the web. Excel for the web では VBA の作成・実行・編集はできません。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Macros from the internet are blocked by default in Office. インターネット由来ファイルの VBA マクロは既定でブロックされます。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Microsoft Learn, Differences between Office Scripts and VBA macros. VBA はデスクトップ中心、Office Scripts は安全でクロスプラットフォームなクラウドベースのソリューション向けであり、現時点ではデスクトップ Excel 機能のカバー範囲は VBA のほうが広いと説明されています。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰
Microsoft Learn, Office Add-ins platform overview. Office Add-ins は HTML / CSS / JavaScript ベースで、Windows、Mac、iPad、ブラウザをまたいで動作し、中央配布にも向きます。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Microsoft Support, Considerations for server-side Automation of Office. Microsoft は Office のサーバー側自動化を推奨・サポートしておらず、Open XML などの代替手段を勧めています。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Microsoft Learn, 64-bit Visual Basic for Applications overview. Office 2019 / Microsoft 365 では 64bit が既定で、PtrSafe、LongPtr などの対応が必要になる場合があります。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Office for the web service description. Excel for the web では VBA マクロの作成・実行はできませんが、VBA を保持したブックの編集は可能です。 ↩
Microsoft Learn, Visual Basic for Applications (VBA) の言語リファレンス. 複数プラットフォーム向けの拡張を作る場合は Office Add-ins を参照するよう案内されています。 ↩ ↩²
Microsoft 365 Developer Blog, Prepare your VBA projects for VBScript deprecation in Windows. VBScript の段階的廃止が .vbs 実行や VBScript.RegExp 依存の VBA プロジェクトへ与える影響、および Office Version 2508 以降での RegExp 対応について。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Run Office Scripts with Power Automate. Power Automate と Office Scripts を組み合わせた自動化、および必要ライセンスについて。 ↩ ↩² ↩³
Microsoft Learn, Platform limits, requirements, and error messages for Office Scripts. 対象クライアント、OneDrive for Business、必要な Microsoft 365 ライセンス、Power Automate 連携時の呼び出し回数やタイムアウトなどの制限について。 ↩ ↩²
Microsoft Learn, Office Scripts file storage and ownership. スクリプトは .osts として OneDrive の /Documents/Office Scripts/ 配下に保存され、SharePoint へ移動もできます。 ↩

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

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

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

既存資産活用・移行支援

Excel や Access の既存 VBA 資産を残す部分と外へ出す部分に分けて考えるテーマは、既存資産活用・移行支援と相性がよいです。

サービスを見るお問い合わせ

技術相談・設計レビュー

VBA、Office Scripts、Office Add-ins、.NET、サーバー実行の境界をどう切るかは、技術相談・設計レビューとして先に整理しておく価値があります。