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

小村 豪

doi:10.5281/zenodo.21589720

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

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

更新履歴(5件・最終更新 2026年08月23日)

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

2026年08月23日: VBAの制約、置き換え先の使い分け、段階移行の進め方を図でも追えるように、Mermaid図を25点追加しました(地の文500〜750字につき1図の規約に合わせたものです)。本文の文章は変えていません。
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://comcomponent.com/blog/2026/03/23/000-what-is-vba-limits-future-replacement/

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

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

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

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

flowchart TB
    accTitle: VBAの判断で最初に見る軸
    accDescr: VBAを続けるか置き換えるかの判断では、新しいか古いかよりも、どこで実行するのか、誰が使うのか、ExcelやAccessそのものがUIなのか、無人実行なのかを最初に見るべきであることを示す図。
    a0["新しいか古いか"] -.-> a1["最初に見る軸ではない"]
    b0["最初に見るべき軸"] --> b1["どこで実行するのか"]
    b0 --> b2["誰が使うのか"]
    b1 --> b3["Excel / Access自体が UIなのか"]
    b2 --> b4["無人実行なのか"]

図1: VBAの判断軸は新旧ではなく、実行場所・利用者・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 は「即死する技術」ではなく、「適材適所が明確な技術」 として見るのが実務的です。

flowchart TB
    accTitle: いま起きている変化の見方
    accDescr: いま起きているのは突然の全廃ではなく、使える場所と前提条件がはっきりしてきたという変化であり、論点はVBAを全部捨てるかではなく、どの領域をVBAに残しどの領域を外へ出すかであることを示す図。
    c1["突然の全廃"] -.-> c2["公式情報では 確認できない"]
    d1["使える場所と前提条件の明確化"] --> d2["論点が変わる"]
    d2 --> d3["どの領域をVBAに残すか"]
    d2 --> d4["どの領域を外へ出すか"]

図2: 論点は「全部捨てるか」ではなく、残す領域と外へ出す領域の分担。

この記事の知識マップ

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 アプリの内側に差し込む拡張言語 として見るほうが実態に近い、という点です。

flowchart TB
    accTitle: VBAの正しい見方
    accDescr: VBAは汎用のアプリ開発基盤として見るより、Officeアプリの内側に差し込むイベント駆動の拡張言語として見るほうが実態に近いことを示す図。
    v1["VBA"] --> j1{"どう見るか"}
    j1 -.->|"実態から遠い"| a1["汎用のアプリ開発基盤"]
    j1 -->|"実態に近い"| a2["Officeアプリの内側に 差し込む拡張言語"]
    a2 --> a3["Officeの中で動く イベント駆動言語"]

図3: 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 システム ではありません。

flowchart TB
    accTitle: VBAの守備範囲
    accDescr: VBAはExcelやAccessの画面・帳票・ブック構造に近く、利用者の手元で完結する自動化には今でも強い一方で、サーバー・ブラウザ・モバイル・マルチテナントなWebシステムは最初から本来の守備範囲ではないことを示す図。
    s1["Excelのオブジェクトに そのまま近い"] --> s2["利用者の手元で 完結する自動化"]
    s2 --> s3["今でも強い領域"]
    t1["サーバー / ブラウザ / モバイル / Webシステム"] -.-> t2["最初から本来の 守備範囲ではない"]

図4: Officeへの近さが強みで、その近さが要らない場所は最初から守備範囲外。

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

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

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

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

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

flowchart TB
    accTitle: VBA資産が抱えているもの
    accDescr: ExcelやAccessには帳票の見た目・印刷設定・入力チェック・処理の順番・例外ルール・操作手順といった業務手順そのものが入り込みやすく、見た目・操作・例外・運用が一体になっているため、コード移植だけでは移行が済まないことを示す図。
    e1["Excel / Accessの資産"] --> e2["業務手順そのものが 入り込んでいる"]
    e2 --> f1["帳票の見た目・印刷設定"]
    e2 --> f2["入力チェック・処理の順番"]
    e2 --> f3["例外ルール・操作手順"]
    f2 --> g1["コード移植だけでは済まない"]

図5: VBA資産はコードだけでなく、業務手順と運用を丸ごと抱えている。

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

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

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

flowchart TB
    accTitle: ExcelのUIとしての位置づけで考える
    accDescr: ExcelがUIであり続けるならVBAを一部残す価値があり、Excelは入出力だけでよいなら中身のロジックは外へ出しやすく、Excel自体がもう本来のUIではないなら作り直しの候補になるという実務での考え方を示す図。
    q1{"Excelはどういう 位置づけか"}
    q1 -->|"UIであり続ける"| r1["VBAを一部残す価値"]
    q1 -->|"入出力だけでよい"| r2["ロジックは外へ 出しやすい"]
    q1 -->|"もう本来のUIではない"| r3["作り直しの候補"]

図6: ExcelがUIかどうかで、残す・外へ出す・作り直すの方向が分かれる。

4. VBA の主な制約

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

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

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

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

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

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

flowchart TB
    accTitle: デスクトップ前提という制約
    accDescr: VBAはデスクトップ版Officeの内側で動く技術で、Excel for the webでは作成・実行・編集ができないため、ブラウザ完結やプラットフォームをまたぐ要件とは相性が悪く、複数プラットフォーム向けの拡張はOffice Add-insが案内されていることを示す図。
    h1["VBA"] --> h2["デスクトップ版Officeの 内側で動く"]
    h2 --> h3["Excel for the webでは 作成・実行・編集が不可"]
    h3 --> h4["ブラウザ完結や 中央配布の要件と相性が悪い"]
    h4 -.-> h5["複数プラットフォームなら Office Add-insを見る"]

図7: いちばん大きい制約はデスクトップ前提であること。

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

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

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

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

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

という摩擦が増えます。

flowchart TB
    accTitle: 既定のマクロブロックが生む摩擦
    accDescr: インターネット由来のファイルに含まれるVBAマクロは既定でブロックされるため、メール添付やダウンロードしたファイルが昔のようには実行されず、配布や運用の摩擦が増えることを示す図。
    m1["インターネット由来のファイル"] --> m2["VBAマクロは 既定でブロック"]
    m2 --> m3["添付やダウンロードでは 素直に動かない"]
    m3 --> m4["配布と運用の摩擦が増える"]
    m2 -.-> m5["セキュリティとしては 正しい方向"]

図8: 「使えなくなった」と誤解される大きな部分は、既定のマクロブロック。

ただし、「動かないので終わり」ではありません。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 の問題は「言語機能」だけではなく、配布と信頼の設計 でも起きます。

flowchart TB
    accTitle: VBAを残すなら配布設計まで決める
    accDescr: VBAを残す判断をするなら、コードの話とは別に、どこへ置いてどう信頼させるかを配布設計として決める必要があり、決めないまま.xlsmをメール添付で配り続ける運用がいちばん摩擦の大きい形であることを示す図。
    p1["VBAを残す判断"] --> p2["コードの話"]
    p1 --> p3["配布設計の話"]
    p3 --> p4["どこへ置くか"]
    p3 --> p5["どう信頼させるか"]
    p4 -.-> p6["決めずに.xlsmを添付配布 =いちばん摩擦が大きい"]

図9: 残すと決めたら、コードとは別に「置き場所と信頼のさせ方」を設計する。

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 と外部依存の整理 になることがかなり多いです。

flowchart TB
    accTitle: 32bit / 64bitの壁
    accDescr: Office 2019とMicrosoft 365では64bitが既定のため、Windows APIをDeclareで呼ぶ古いコードはPtrSafeやLongPtrでの対応が要り、古いCOMやActiveX、32bit前提の外部DLL、参照設定のずれも一緒に問題になるため、移行は言語の書き換えより外部依存の整理になることを示す図。
    b1["Office 2019 / M365は 64bitが既定"] --> b2["古いDeclare呼び出しが そのまま動かないことがある"]
    b2 --> b3["PtrSafeやLongPtrで 差を吸収する"]
    b2 -.-> b4["COM / ActiveX / OCXや 32bit前提DLLも一緒に問題化"]
    b4 --> b5["移行の実態はbitnessと 外部依存の整理"]

図10: 64bit移行では、コードよりも外部依存が先に問題になりやすい。

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

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

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

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

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

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

flowchart TB
    accTitle: 無人実行・サーバー実行に向かない理由
    accDescr: Officeは対話的なデスクトップとユーザープロファイルを前提に設計されており、サーバー側自動化は推奨・サポートされず、無人環境では不安定やデッドロックが起き得るため、疑うべきはVBAではなくExcelアプリ自体を運転する構成であることを示す図。
    u1["サービスやバッチから Excelを起動する構成"] --> u2["Officeは対話的な デスクトップ前提の設計"]
    u2 --> u3["無人環境では不安定や デッドロックが起き得る"]
    u3 --> u4["サーバー側自動化は 推奨・サポート外"]
    u4 -.-> u5["疑うべきはVBAではなく Excelを運転する構成"]

図11: 「たまに動く」ことと「支えられる構成」は別で、無人実行では構成自体を疑う。

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

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

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

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

flowchart TB
    accTitle: Officeファイルの中にロジックを持つ構造の問題
    accDescr: VBAはブックやAccessファイルの中にコードが閉じやすく、正本が曖昧になる、責務が散る、差分確認やテストがしにくいといった問題が起き、小さな自動化では目立たなくても業務システム化すると急に効いてくることを示す図。
    k1["Officeファイルの中に コードが閉じ込む"] --> k2["正本が曖昧・責務が散る"]
    k1 --> k3["差分確認・テストが しにくい"]
    k2 --> k4["小さな自動化では 目立たない"]
    k3 --> k4
    k4 --> k5["業務システム化すると 急に効いてくる"]

図12: 言語ではなく「ファイルの中に業務ロジックを持つ」構造が問題を生む。

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 からぶら下がっていた一部の外部依存を見直す必要がある、という理解のほうが正確です。

flowchart TB
    accTitle: VBScript廃止とVBAの関係
    accDescr: WindowsにおけるVBScriptの段階的廃止は、外部.vbsを実行しているケースやVBScript.RegExpの参照に依存しているケースに影響し得るもので、RegExpは新しいOfficeでVBAに既定で含まれる形の手当てが進んでおり、VBA全体の終了と同じ話ではないことを示す図。
    w1["VBScriptの段階的廃止"] --> w2["外部.vbsの実行に依存"]
    w1 --> w3["VBScript.RegExpに依存"]
    w2 --> w4["別の実行基盤へ寄せる検討"]
    w3 -.-> w5["新OfficeはVBAに既定で同梱"]
    w1 -.-> w6["VBA全体の終了とは別の話"]

図13: 影響を受けるのはVBScriptにぶら下がる依存だけで、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 の将来は、消滅よりも境界の明確化 と見るのが自然です。

flowchart TB
    accTitle: 消滅ではなく境界の明確化
    accDescr: デスクトップExcelの深い操作ではまだVBAの守備範囲が広く、ブラウザやM365や共有ワークフローではOffice ScriptsやAdd-insのほうが自然であり、全部を一方へ寄せるのではなく境界が明確になっていく変化であることを示す図。
    z1{"どこで使うか"}
    z1 -->|"デスクトップExcelの 深い操作"| z2["まだVBAの守備範囲が広い"]
    z1 -->|"ブラウザ / M365 / 共有ワークフロー"| z3["Office Scriptsや Add-insが自然"]
    z2 --> z4["境界の明確化"]
    z3 --> z4

図14: 「全部Office Scriptsへ」でも「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 は古いから」ではない ことです。本当に見るべきなのは、実行環境、運用、配布、依存、監査、拡張性 です。

flowchart TB
    accTitle: 置き換え判断の軸
    accDescr: 置き換えの判断軸は「VBAは古いから」ではなく、実行環境・運用・配布・依存・監査・拡張性という要素を見るべきであり、ハイブリッド化では利用者から見える画面と操作を変えずにロジックとI/Oだけを外へ出すことを示す図。
    j0["VBAは古いから"] -.-> j1["判断軸にしない"]
    j2["本当に見るべき軸"] --> j3["実行環境・運用・配布"]
    j2 --> j4["依存・監査・拡張性"]
    j3 --> j5["残す / ハイブリッド化 / 外へ出すを選ぶ"]
    j4 --> j5

図15: 判断の軸は古さではなく、実行環境・運用・配布・依存・監査・拡張性。

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 操作」だけに寄せる

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

flowchart TB
    accTitle: Excelを残して中身だけ外へ出すハイブリッド構成
    accDescr: 画面や帳票の入口はExcelやAccessのまま残し、業務ロジックやHTTP・暗号・重い計算・ファイル処理は.NETや別プロセスへ出して、VBAは橋渡しとUI操作だけに寄せることで、利用者の見た目と操作を壊さずに責務を薄くできることを示す図。
    x1["画面・帳票の入口は Excel / Accessのまま"] --> x2["VBAは橋渡しと UI操作だけに寄せる"]
    x2 --> x3["重いロジックやI/Oは .NETや別プロセスへ"]
    x3 -.-> x4["利用者の見た目と 操作を壊さない"]

図16: いちばん失敗しにくいのは、入口を残して中身だけ外へ出す形。

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

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

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

つまり、要件が

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

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

flowchart TB
    accTitle: 無人の帳票生成はファイル直接生成へ
    accDescr: 帳票を夜間バッチやサービスで大量生成したいとき、まず疑うべきはExcelアプリを起動していること自体で、サーバー側のOffice Automationは推奨されず、Open XML形式などでOfficeファイルを直接組み立てる方法が推奨されていることを示す図。
    y1["帳票を無人で大量生成したい"] --> y2{"どちらの軸で考えるか"}
    y2 -.->|"非推奨"| y3["Excelアプリを運転する"]
    y2 -->|"推奨される方向"| y4["Open XMLなどで ファイルを直接組み立てる"]

図17: 無人実行の要件では、「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 へ移行」と決めると、移行の途中でライセンス調達の話へ戻ることになります。

flowchart TB
    accTitle: Office Scripts移行で先に確認する前提
    accDescr: Office Scriptsは無料で付いてくるVBAの代わりではなく、ローカルの.xlsmを配って回していた運用と比べてOneDriveやSharePointとM365ライセンスという前提が増えるため、見落としたまま移行を決めると途中でライセンス調達の話へ戻ることを示す図。
    o1["ローカルの.xlsmを 配って回す運用"] --> o2["Office Scriptsへ 移行を検討"]
    o2 --> o3["OneDrive / SharePointと M365ライセンスの前提が増える"]
    o3 -->|"先に確認する"| o4["移行計画に前提を織り込む"]
    o3 -.->|"見落とすと"| o5["途中でライセンス調達の 話へ戻る"]

図18: Office Scriptsは「無料のVBAの代わり」ではなく、前提条件の確認が先。

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

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

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

flowchart TB
    accTitle: Office Scriptsの実行のされ方
    accDescr: Office ScriptsはExcelレベルのイベントをサポートせず、実行は手動開始かPower Automateからの呼び出しが基本で、呼び出し回数や同期処理時間の制限もあるため、VBAの置換物というよりM365上の自動化部品と見るのが正確であることを示す図。
    a1["Office Scripts"] --> a2["手動で開始する"]
    a1 --> a3["Power Automateから 呼び出す"]
    a1 -.-> a4["Excelレベルのイベントは サポートしない"]
    a2 --> a5["M365上の自動化部品 として見る"]
    a3 --> a5

図19: イベント駆動の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 の中にコードを書く 感覚とはかなり変わります。その代わり、運用と配布は整理しやすくなります。

flowchart TB
    accTitle: Office Add-insが向く形
    accDescr: Office Add-insはHTML・CSS・JavaScriptで構築でき、Windows・Mac・iPad・ブラウザをまたいで動作して中央配布にも向くため、PCごとのマクロ配布やローカルの.xlsm配布モデルから離れたい要件に合うことを示す図。
    d1["HTML / CSS / JavaScript で構築する"] --> d2["Windows / Mac / iPad / ブラウザで動く"]
    d2 --> d3["管理者による中央配布"]
    d3 --> d4["ローカルの.xlsm 配布モデルから離れる"]

図20: クロスプラットフォームと中央配布が要件なら、Add-insの土俵になる。

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、印刷、メール送信など）

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

flowchart TB
    accTitle: 資産台帳で洗い出すもの
    accDescr: 段階移行の最初にやるのはコード量よりも依存関係の洗い出しで、どのファイルが実運用の入口か、参照設定や外部DLLやbitness前提はどうか、どのマクロが誰のどの手順で使われ何を出力するかを台帳にし、曖昧なままだと月末だけ生きていたマクロのような事故が起きることを示す図。
    r1["ファイルの洗い出し"] --> r2["依存の洗い出し （参照設定・DLL・bitness）"]
    r2 --> r3["使われ方の洗い出し （誰が・どの手順で・出力は）"]
    r3 -.-> r4["曖昧なままだと月末だけ 生きていたマクロ事故"]

図21: 台帳で見るのはコード量ではなく、依存関係と使われ方。

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 資産の中身は、だいたい複数の責務が混ざっています。

flowchart TB
    accTitle: 責務ごとに移行先を決める
    accDescr: コードをファイル単位ではなく責務単位で分けると、残すもの・薄くするもの・外へ出すものが見えやすくなり、UIとシート操作は当面VBAに残し、業務ロジックは.NETへ、無人帳票生成はOpen XMLへ、M365ワークフローはOffice Scriptsへと責務ごとに移行先を決められることを示す図。
    m1["コードを責務単位で分ける"] --> m2["残す / 薄くする / 外へ出すが見える"]
    m2 --> n1["UI・シート操作は 当面VBAに残す"]
    m2 --> n2["業務ロジックは .NETや別プロセスへ"]
    n1 --> n3["無人帳票生成は Open XMLへ"]
    n2 --> n4["M365ワークフローは Office Scriptsへ"]

図22: ファイル単位ではなく責務単位で分けると、移行先は自然に複数になる。

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

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

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

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

8.5 並行稼働で比較する

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

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

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

flowchart TB
    accTitle: 並行稼働で比較してから切り替える
    accDescr: 帳票や集計はいきなり切り替えず、旧VBA版と新実装版を並行で出し、出力されたファイルの日付・丸め・書式・印刷範囲の差を確認し、例外系や空データ系も試してから切り替えることで、数字や書式が静かにずれる事故を防ぐことを示す図。
    h1["旧VBA版と新実装版を 並行で出す"] --> h2["出力を比較する （日付・丸め・書式・印刷範囲）"]
    h2 --> h3["例外系・空データ系も試す"]
    h3 --> h4["差が無いことを 確認して切り替え"]
    h2 -.-> h5["事故は数字や書式が 静かにずれる形で起きる"]

図23: いきなり切り替えず、新旧の出力を並行して比較してから移す。

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 フォームには、コードに書かれていない運用ルールがかなり埋まっています。

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

flowchart TB
    accTitle: 同時に全部変えると起きること
    accDescr: VBA置き換えで本当に怖いのはコード変換より業務仕様の取り落としで、ExcelのシートやAccessフォームにはコードに書かれていない運用ルールが埋まっており、画面・帳票・業務ルールを同時に全部変えると見た目は近いのに月末だけ違うような事故が起きやすいことを示す図。
    g1["画面・帳票・業務ルールを 同時に全部変える"] --> g2["コードに書かれていない 運用ルールを取り落とす"]
    g2 --> g3["見た目は近いが 月末だけ違う事故"]
    g2 -.-> g4["怖いのはコード変換より 業務仕様の取り落とし"]

図24: 一気に全部を変えると、コードの外にある業務仕様を取り落としやすい。

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 アプリへ出す

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

flowchart TB
    accTitle: 置き換えの答え
    accDescr: VBAへの答えは全部置き換えることでも何も変えないことでもなく、責務ごとに分けて段階的に薄くすることであり、置き換えは翻訳ではなく整理として進めるのが安全であることを示す図。
    q0{"VBA資産をどうするか"}
    q0 -.->|"極端"| e1["全部置き換える"]
    q0 -.->|"極端"| e2["何も変えない"]
    q0 -->|"実務的な答え"| e3["責務ごとに分けて 段階的に薄くする"]
    e3 --> e4["翻訳ではなく 整理として進める"]

図25: 答えは両極端ではなく、責務ごとに分けて段階的に薄くすること。

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、サーバー実行の境界をどう切るかは、技術相談・設計レビューとして先に整理しておく価値があります。