VBAはオワコンなのか?

VBAがオワコンなのか?という話題がTwitterで流れていたので、私の考えを纏めておこうと思う。

VBAの生い立ち

Visual Basic for Applications(以下VBA)の話しをするときに、Visual Basic(以下VB)のことを抜きにすることはできません。VBAは、いまはサポートが終了しているVBという開発言語を元にして生まれました。VBは、いまもMicrosoftが提供しているVisual Basic.NET(以下VB.NET)とはまったく異なる開発言語です。VBはWindows専用の開発言語として広く支持を集めました。その開発の平易さから、特に受託開発の現場で多く使われてきました。利用者がが増えれば、対応する事業者も増えます。多くのサードベンダーがVB用のコンポーネントを提供しており、当時としては開発しやすい環境が整っていたのです。

VB最後のバージョンとなるVB6.0はComponent Object Model(以下COM)に準拠し、Microsoft開発言語の中核となりました。どのような言語であってもにCOMに準拠したコードを書けば、使用する言語によらず機能を呼び出せるようになります。オーバーヘッドも比較的小さく、単にライブラリを呼び出せるだけでは無く、プロセス間の通信や、ネットワークを介してサーバー間の呼び出しも行えるものでした。多くのコンポーネントがCOMに準拠したものに置き換わり、様々なサードベンダーが提供するようになっていきました。

ところがその後にCOMの欠点が問題になっていきます。VB 6.0の発売された1998年はインターネットの黎明期にあたりました。今ほどセキュリティへの要求は厳しくない時代に設計されたため、セキュリティへの設計面での配慮がほとんど無かったのです。Microsoftはその後に多くのセキュリティ問題に苦しむことになります。

VB 6.0の発売から4年後、セキュリティを強化して再設計したVB.NET 7.0がリリースされます。Microsoftはそれまで、二年ごとに新バージョンを提供していたことを考えると、相当に苦労したことがうかがえます。ですがVB.NETにはVB6.0との互換性は全くありませんでした。互換性の問題からVB6.0からVB.NET7.0への移行は進まず、Windows 11となった今もVB6.0のランタイムライブラリがOSと共に提供され続けています。

VB.NET7.0が発表された後、当然ながらVBAについても多くの議論が巻き起こりました。セキュリティを考慮するならVB.NET7.0を基礎としたものに作り替えた方が良いのは分かっています。でも現実問題として互換性の全くない言語への移行は困難を極めるのは明らかでした。それに対する結論として現在の状況があります。

MicrosoftはVBAはその互換性を維持して提供し続けることを選択しました。同時に、セキュリティの問題に対応するためにデフォルト設定ではマクロ機能を無効にし、また電子署名を付けた出所の明確なマクロ以外では警告を表示するようにしました。拡張子もxlsx(マクロ無し)とxlsmx(マクロ有り)と分ける事でユーザーがマクロの有無を意識しやすくしました。ユーザーはマクロを利用するために設定を変更する事になりますが、それに伴うリスクはユーザーが負うものとなりました。

最近でもセキュリティ強化は続いていて、インターネットからダウンロードしたファイルや、共有フォルダ上のファイルについては、デフォルトではマクロが実行されないような改善が行われています。

VBAに変わる機能を提供する試みも繰り返し行われています。ファイル仕様が公開されオープン化したことにより、xlsxファイルを編集する事のできるライブラリが様々な言語で利用できるようになりました。またOffice製品を操作するために、Microsoft Office Interop、Visual Studio Tools for Office、Apps for Office、Excel REST APIと何度か新たなツールを提供を試みていますが普及には至っていません。Windows OSに比較的容易に使える開発言語としてPythonを組み込むと言ったことも行われています。最近あらたに提供しているのはPower Automateですね。

VBAを使い続ける事の何が問題なのか?

セキュリティ上のリスク

マクロの実行を許可することに伴ってキュリティリスクが発生します。VBAが含まれたファイルがコンピューターウィルスの感染経路となっている事は知られていることと思います。リスクを認識して電子署名の無いマクロの実行を禁止する等の対策を取っているなら良いのでしょう。ですが、VBAを使っている企業では利便性を優先して、どんなマクロも実行許可しているのが実情でしょう。

機能面の貧弱さ

VB6.0の頃には様々なベンダーがCOMコンポーネントを提供していました。これにより2008年頃までは拡張性の高いパワフルな言語となっていましたが、今は殆どのベンダーがCOMコンポーネントの提供から撤退しています。VBAで出来る事が縮小していっているのが実態です。

VBAの言語機能どのものの拡張も20年単位で行われていません。この20年間で多くの言語に取り込まれてきたような機能、完全なオブジェクト指向や無名関数、並列化などの機能が追加される見込は無いでしょう。ソースコード管理システムとの連携が極めて困難なのも生産性を大きく下げてしまいます。

本当に何処でも実行出来るのか?

VBAを利用する理由のひとつに「Excelはどのパソコンにもインストールされており、どのパソコンでも利用できる」というのが有る。Microsoftはサブスクリプションモデルへの移行を目指しており、従来の買切り型ライセンスのOffice製品は2025年でサポートを終了することになっている。現在はデバイスライセンス下で複数の従業員が共有しているパソコンについても、2025年移行はユーザーライセンスに移行する事が求められる。例え利用時間が月に30分でも、アルバイトが20人いれば20ライセンスを購入することになるが、はたして購入し続けるだろうか?

また年々セキュリティ意識が高まっていく中、VBAを実行するためにセキュリティ設定を緩めて貰う事が、いつまで受け入れられるでしょうか?VBAを完全に禁止している会社も少なからずあるのが実情です。

またランタイムを追加で導入する必要が無く、何処でも実行可能であることがVBAを選択する理由なら、JavaScriptでもPythonでも良いはずです。

VBAを使い続ける上で必要なこと

VBAを使い続ける上で必要なことは、リスクを正しく認識する事だと考えて居ます。以下の様な問題があることを踏まえた上で、バランスを取りつつVBAと付き合っていく必要があるわけです。

  • VBAを使うためにセキュリティリスクを高めていること。
  • VBAの生産性を高めるような言語機能の拡張は20年ほど行われておらず、多言語と比較して生産性の低い開発言語となりつつあること。
  • VBAには将来に向けたロードマップが無く、今後もサポートが縮小していく可能性が高いこと。
  • セキュリティ問題、ソフトウェア資産管理上の問題から、VBAの利用を禁止している企業も少なくない。

少なくとも僕個人の方針として、今から積極的にVBAで書かれたソフトウェア資産を増やしたり、今からVBAを学ぶというのは、リスクに対してベネフィットが合わなくなる可能性が高いと捉えています。

VBAによるソフトウェア資産の総量を、VBAを止める必要が生じたときに速やかに他の開発言語に移植できる程度の量に納める必要があるでしょう。ソースコードの総量をメンテナンス可能な範囲に納める必要があるいのはVBAに限った話しではありませんが、VBAの場合には生産性の低さや将来性のなさから、より少ない量に抑える必要があるはずです。

マクロの実行を有効にする上で、セキュリティリスクを下げるため、ウィルス対策ソフトを使用するのは当然として、それ以外にもアクセス権管理やコンテンツフィルタなど、多層防御できる態勢を整えておく必要があるでしょう。新しいウィルスがウィルス対策ソフトのパターンファイルをすり抜ける事は珍しく無いのです。

Excelのパスワードを解除する方法

Excelのパスワードを解除する裏技を求めて、当WEBに来る方が少なくない。 「ブックの保護を強制的に解除する」は保護をすることで安全に隠せている気になっている記事への警告の意味で書いたので、パスワードが分からなくて困っている人へと補足情報を載せておこうと思う。

避けては通れない法律的な話し

まず法律的なことを覚えておいて欲しい。

何らかの方法でパスワードを調べたり、調べたパスワードを保管したりする行為は「不正アクセス行為の禁止等に関する法律」に抵触し、刑事罰の対象となる。例えファイルの中味を閲覧しなかったとしても、パスワードを調べたり、保管しているだけで処罰の対象となる。

裏技などを使ってパスワード(技術的利用制限手段)を迂回したりする行為は「著作権法」に抵触し、これまた刑事罰の対象となる。 著作権侵害の多くは親告罪だが、技術的利用制限手段の回避は非親告罪となる。

また裏技をつかってパスワード (技術的利用制限手段) を迂回するためのツールを提供する行為は「不正競争防止法」に抵触する。平成30年からはツールを提供するだけではなく、依頼を受けて役務を提供する事も処罰の対象となる。

以上のような法律があるので、いくら探しても「パスワードを解除して欲しい」という依頼を受けてくれる人は見つからない。Excelのファイルを解析してパスワードを解除するようなツールも見つからない。仮に技術的かつ予算的に可能であっても、家族や親友からの依頼でも無い限り、リスクが大きすぎて受けられないのだ。

とはいえ、パスワードが分からなくて途方に暮れている様もよく分かる。解決方法はただひとつしかない。技術的な知識と、法律的な知識を自ら身につけ、自らの手で作業するしかないのだ。

裏技による迂回方法

ブックやシートの保護パスワードや、VBAのソースコード閲覧パスワードなどは裏技的な方法で解除できる。実際に解除する方法は「Excel の各種パスワードを突破する方法まとめ」に良くまとまっている。新たに追記することはしない。

読み取りパスワードの解除

読み取りパスワードだけは総当たりで解除するしかない。だが、辞書に載っているような単語だけであるとか、あるいは6~7文字程度のパスワードであれば、解除できなくもない。

パスワードの解析によく使われるのは「John the Ripper password cracker」と言うツールだ。

私の使っている20万程度のパソコンでもGPUを使うと3,000パスフレーズ/秒程度のスピードで解析を進めてくれる。英数だけで構成される5文字程度のパスワードなら、最悪でも60時間程度で解析が終わる計算になる。辞書に載っているような単語、十万語程度を対象とするならば、数分で終わってしまう。

最高スペックのGPUを使うなら1桁程度は早くなる。IaaSで高速なサーバを複数台レンタルするなら2桁程度は早くなる 。6文字程度のパスワードなら総当たりでも 数日程度で 割り出すことが出来るし、そのために発生する費用は10万円にもみたない。

Postscript #1

そんな分けだからパスワードの分からなくなったファイルのことはキッパリと諦めて、ファイルをゼロから作り直すことを第一選択肢として考えたほうが良い。

Postscript #2

いまどき7文字程度のパスワードしか設定していないのは、実効性が無いので止めておいたほうが良い。無駄な仕事を増やしているだけに過ぎない。

Access Runtimeをインストールしようとしたら32bit版も64bit版もエラーになる

Access Runtime 2016 64bit版のインストールを行おうとすると「次の32ビットバージョンのOfficeプログラムががインストールされているため、64ビットバージョンのOfficeはインストールできません:Office 16 Click-to-Run Extensibility Component」とのエラーになる。

この環境は32bit版だったかと思い直し、 Access 2016 Runtime 32bit版のインストールを行おうとすると 「次の64ビットバージョンのOfficeプログラムががインストールされているため、32ビットバージョンのOfficeはインストールできません:Office 16 Click-to-Run Extensibility Component」とのエラーになる。

・・・どうしろとorz

Access Runtimeインストールの基本制約

Office 2016(2019にも)にはClick-to-Runインストール版 (以下C2R版) とMSIインストール版(以下MSI版)がある。ライセンス上はどちらをインストールしても構わないが、それぞれインストール方法が異なる。プレインストールの場合、昔はMSI版が多かったが、最近は C2R版が入って居ることが多い。そしてC2R版とMSI版には、それぞれ32bit版と64bit版がある。

Access RuntimeにもC2R 版とMSI版がある。C2R版はOffice 365 Access Runtimeと言う名称で、MSI版はAccess 2016 Runtime (ないし2019)と言う名称で提供されており、それぞれ32bit版と64bit版がある。

Access RuntimeをインストールするにはC2R版かMSI版か、32bit版か64bit版かの区分が完全に一致している必要がある。さらにMSI版の場合には2013と2016、2019は混在できないのでバージョンを統一する必要がある。

過去にプレインストール版が入っていた

当該環境はプレインストール版(C2R版)でインストールされていたため、アンインストールしてMSI版を入れ直していた。だが、どうもC2R版の残骸が残ってしまっているのが原因のようである。

アンインストールが完全に行われていないためにトラブルが発生することが度々あるようで、Microsoftのホームページに完全にアンインストールするための方法が書かれている。

PC から Office をアンインストールするの「オプション 2 – アンインストール サポート ツールを使用して Office を完全にアンインストールする」に従って、アンインストール補助用の実行プログラムをダウンロードして、実行することで残骸も含めて消せるようである。無論現在インストールされているMSI版も含めてアンインストールされてしまうのであろうけど・・・

余り褒められた話しではないが、作業時間も押してきているので、Access Runtime 2010のインストールでお茶を濁してしまった。でも恐らくは上記手順でOffice 2016の残骸を削除すればインストール出来るものと思われる。

「VBAを覚えようと思うんだけど」と聞かれた話の続き

日付をまたいで「『VBAを覚えようと思うんだけど』と聞かれた話」の続きなど。

VBAを進められない理由・・・それは2025年以降、Microsoft Officeが月額制ライセンスのみとなることで、どのパソコンにもExcelが入っている時代が終わりそうだからだ。現在のMicrosoft Officeのライセンスは大きく分けて2種類、月額制ライセンスと買切りライセンスにわけられる。このうち買切りライセンスはOffice 2019を最後のバージョンとして2025年10月にサポートが終了する。

Microsoft Officeの買切りライセンスにはユーザーライセンスとデバイスライセンスの2種類に分かれる。ユーザーライセンスは使うユーザが同じなら複数台にインストールできるが、1台のPCを複数人で共有するなら人数分のライセンスが必要だ。デバイスライセンスはインストールするPCの台数分購入する必要があるが、1台のPCを複数人で共有してもOKだ。

対して月額制ライセンスはユーザーライセンスしか用意されていない。 PCの台数より従業員の人数の方が多いという職場は少なくない。小売業とか、製造業とか。1台のPCを10人程度で共有していた場合、デバイスライセンスだったら5万円で済んだのが、月額制ライセンスだと5年で50万円くらいに膨れ上がる。この金額増を避けるためMicrosoft Officeを全部のPCにはインストールしなくなると考えている。

一般家庭向けだと法人ライセンスより高くて年間1万2千円。4人家族なら年間4万8千円。現在はプレインストールモデルのOffice Personalを1万7千円の価格差で買えるから大抵の人はインストールしている。ライセンス料が5年で24万円と言われたら、利用頻度の低いだろう一般家庭は躊躇するのではなからろうか。海外だともうちょっと安いファミリー向けライセンスもあるらしいのだが、そうだとしても結構厳しい。

僕は 上記の理由から2025年になるとMicrosoft Officeの利用が減り、比較的安いコストで使える互換製品に移る動きが再び起こると思っている。互換OfficeソフトはMicrosoft Officeのファイルをほぼ問題なく扱うことが出来る。だがVBAだけは互換ソフトで動作しない。今むやみにVBAでプログラムを作りすぎると、5年後に追い詰められる予感がするのだ。

「VBAを覚えようと思うんだけど」と聞かれた話

事務系の同僚女子に「VBAを覚えようと思うんだけど」と言われて唸ったことがある。

ITリテラシーの高い従業員が増えることや、業務が効率化されること自体は喜ばしいのだが、ことVBAだけは手放しで勧められないのだ。

VBAはVisual Basicという言語が元になっている。このVisual Basicは1998年発売の6.0を最後に、2008年4月にサポートを終了している。Office製品の一部として提供されているためセキュリティアップデートこそ提供されているが、機能面では更新されていない。20年前で進化が止まっている。

そのためVBAでは、新しいバージョンのDB利用や、WEBサービスとの連携に無理が出ているのだ。MicrosoftのSQLServerで扱うデータ型の一部は取り扱えないし、WEB APIを呼び出そうとすると恐ろしく冗長なコードを書かざる得ない。

さらにVBAはインターネットが普及してセキュリティが重要視される以前の設計なので、セキュリティ面がどうしても弱い。標準では電子署名なしのマクロを実行できないように設定されているのは、セキュリティ的に弱く攻撃の対象にされやすいためだ。

セキュリティ面ではVBAを電子署名必須として運用するか、それが出来ないなら社内から無くしたいのが実情だ。でも実態は彼方此方で活用しているので、止めるに止められないので、セキュリティ担当者は困っていたりする。

ではどうしたら良いかというと、実は代案がない。ExcelやWordのファイルを扱うことができて、ライセンス料がかからず、平易に学習できて、完璧に日本語化されていて、どのWindowsパソコンでもそのまま動かせる言語・・・というのが見当たらない。

というわけで、VBAに関する愚痴でした。ちなみに私自身は、VBAを使って、新規にはマクロを作らないことにしています。 新たに作るときにはC#+Closed XMLで書きます。もしくはPower Query+Excelの数式だけで作ります。

Microsoftにも早く今後のLoadmapを考えてほしい。

ブックの保護を強制的に解除する

【Excel】見積書の価格表を載せたシートは顧客に見られたくない!エクセルで特定のシートを非表示にしてパスワードをかけるテク

ブック保護のパスワードが分からなくなっても、強制的に解除することは可能です。

1. Excelのファイルをxlsxで保存する

2. ファイルの拡張子をxlsxからzipに変更する
実はxlsx形式のファイルは、zipファイルの中にxml形式のデータが格納したものです。

3. Explzhなどの解凍ツールを用いて開く

4. xl\workbook.xmlをメモ帳などで編集し「<workbookProtection~/>」を削除

5. zipファイルのxl\workbook.xmlを編集したもので置き換える。
必ず元のzipファイルに対して操作を行い、ファイルを置き換えてください。新規にzipファイルを作成して、拡張子をxlsxに変えても、プロパティ情報などの違いからxlsxファイルをは認識されません。

6. 拡張子をzipからxlsxに戻す

7. Excelでファイルを開く
Excelでファイルを開くときに、ファイルが壊れている旨の警告が表示されますが「はい」を選択して、ファイルを修復してください。これでパスワードが解除された状態になります。

BookやSheetの保護パスワードは、元データを暗号化しているわけではありません。もし暗号化していたら、Excelの式で参照することもできなくなりますからね。パスワードは暗号化されているので元のパスワードは分かりませんが、パスワードを設定するという属性ごと削除してしまえば、パスワードを解除できます。

内容を見たいだけなら「非表示のシート名!A1」といった式を書くだけでも、簡単に内容を確認できます。

顧客に見られても良い情報と、見られて困る情報を混在させる、良い方法というのはありません。仮にデータが暗号化されて保存される使用だったとしても、パスワードが漏洩している可能性だってあります。無駄にリスクを増やすよりも、素直に削除するなり、ExcelならPDF形式にエクスポートするなりといった方法を選びましょう。

PS…
zipファイルとして解凍してしまうテクニックは「複雑な正規表現置換をしたい」といった用途にも使えますので、知ってると便利です。

Officeのタイトルバーに表示されるユーザー名をAD環境下で変更するには

Office 2013以降はタイトルバーの右上にユーザー名が表示されています。ここに表示されているユーザー名はOneDriveのユーザー名であったり、ActiveDirectory(以下AD)のユーザー名であったり環境によって異なります。ところがAD環境下の場合にはADサーバ側でユーザーの登録内容を変更しても、Officeのタイトルバーに表示されている氏名には反映されません。

AD以外の環境・・・例えばOneDriveのユーザー名ならばファイルメニューのアカウントを開き、サインアウトを実施します。その後にあらためてファイルメニューのアカウントを開き、サインインする事でOneDriveのユーザー名を反映することが出来ます。ですが、Active Directory環境下の場合には、ファイルメニューのアカウントからサインアウトを選択するとサインアウトできますが、もう一度ファイルメニューのアカウントからログインし直すことが出来ない為に、ログアウトしたままになってしまいます。

Active Directory環境下の場合にはレジストリを直接編集して名前を変更する必要があります。レジストリエディタを起動して「HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Identity\Identities」を開きます。ここにADユーザアカウント名でフォルダが作成されていますので、「FriendlyName」および「Initials」を変更します。この後Officeを起動すると、新しい名前が反映されるようになります。

参考:https://technet.microsoft.com/en-us/library/jj683102.aspx#Bkmk_4_DeleteCreds

OfficeClickToRun.exeで障害が発生して、Officeアプリケーションが強制終了してしまう

Microsoft Excelで特定のファイルを開いたときに、Excelが何のメッセージも出さずに終了指定しまう現象が発生しました。イベントログを確認してみるとアプリケーションにはOfficeClickToRun.exeのアプリケーションエラーが、システムにはMicrosoft Office ClickToRun Serviceが不正終了したエラーが残されていました。

アプリケーションイベントログ

障害が発生しているアプリケーション名: OfficeClickToRun.exe、バージョン: 15.0.4641.1002、タイム スタンプ: 0x53db083a
障害が発生しているモジュール名: unknown、バージョン: 0.0.0.0、タイム スタンプ: 0x00000000
例外コード: 0xc0000005
障害オフセット: 0x00000000
障害が発生しているプロセス ID: 0x1db8
障害が発生しているアプリケーションの開始時刻: 0x01d23f9ff27ee023
障害が発生しているアプリケーション パス: C:\Program Files\Microsoft Office 15\ClientX86\OfficeClickToRun.exe
障害が発生しているモジュール パス: unknown

ClickToRunはOfficeの標準ではインストールされない機能を、必要になったときに非同期的にインストールする機能です。原因はわかりませんが標準ではインストールされない機能を用いたExcelファイルを開こうとすると、ClickToRun Serviceが差分機能のインストールを行おうとして、落ちているのではないかと推測されます。

幸いなことにOfficeの修復インストールを行う事で直りました。Officeの修復インストールの時にはプロダクトIDを求められる場合があるので、事前に用意しておきましょう。

C#でExcelに画像データを埋め込む

※追記…ClosedXML v0.88移行は標準で画像の埋め込みに対応しており、ClosedXMLImageSupportを使う必要がなくなりました。

OpenXML SDKで画像を埋め込んだExcelファイルを作成しようとすると、ステップ数が一気に増えてしまって現実的ではありません。ClosedXMLはExcelファイルを作るのにとっても便利なのですが、画像データを扱う機能がありません・・・・と思ったら、ClosedXMLをForkして画像データを扱う機能を追加している方が、ここは感謝して使わせていただきましょう。

ClosedXML.DLLをビルドする

NuGetでダウンロードできるCloseXMLは画像データを扱えませんから、自分でソースコードからビルドします。Fork: ajwhiteway/ClosedXMLImageSupportからソースコードをダウンロードします。
ClosedXML_for_image_download
ダウンロードしたzipファイルを解凍するとソースコードが得られるので、ClosedXML.slnファイルを開いてビルドします。ClosedXML\bin\Releaseに生成されるClosedXML.dllを参照設定します。

これで準備は出来ました。

using BarcodeLib;
using ClosedXML.Excel;
using ClosedXML.Excel.Drawings;
<<中略>>
            var book = new XLWorkbook();
            var sheet = book.AddWorksheet("sheet1");

            // 画像データを指定
            XLPicture pic = new XLPicture
            {
                NoChangeAspect = true,
                NoMove = true,
                NoResize = true,
                ImageStream = File.OpenRead("sample.png")
            };

            // 表示位置を指定
            XLMarker fMark = new XLMarker
            {
                ColumnId = 1,
                RowId = 1
            };
            pic.AddMarker(fMark);

            // 画像データを追加
            sheet.AddPicture(pic);
            book.SaveAs("sample.xlsx");
<<中略>>

と、かなりシンプルに記述できます。
こんなに便利なのだから是非mainに取り込んで欲しいよね。

VBAを今後どのように扱ったら良いか?

VBAはエンドユーザーコンピューティングとして優れたプロダクトだと思っている。ほとんどのユーザーが購入して持っているであろうOfficeアプリケーションさえインストールされていれば開発できる。高価なミドルウェアを購入したり、面倒なコーディングをしなくても標準でレポーティングツールや、データベースだって利用できる。このような言語は中々代替えがないのだが、VBAと離別すべき時も刻一刻と近づいている。

今VBAが置かれている現状を整理したい。

ActiveX Data Object(ADO)

VBAから直接データベースに接続するにはADOぐらいしか選択肢がありません。にもかかわらずADOのサポートは停滞したままで、ADO2.8がリリースされて以降は新たなリリースがありません。機能的にはSQLServer2005で止まっていて、それ以降に追加された型には対応していません。たとえばXML型とかGEOMETRY型を扱うことができません。特にSQL Azureの動作対象リストからはADOやDAOが外されており、別の方法で接続する事を求められます。
唯一幸いなことは、ADOのコンポーネントはOSとともに配布されているので、OSのサポートが終了するまではセキュリティアップデートが提供され続けることです。

ADO以外の方法でデータベースに接続しようとすると、VBA以外の言語でコードを書く必要が出てきます。どんな手段が考えられるでしょうか?

XML WEBサービス

Visual Studio .NETでは容易にXML WEBサービスを作成する事ができます。これをVBAから呼び出す方法が考えられます。
しかし残念なことに無償で使用できるExpress版ではWEBサービスを開発できません。最も安価なVisual Studio 2015 Professionalでも6万円台になります。エンドユーザーコンピューティングを考えたときに6万円超の負担は避けたいところです。Community版があるじゃないかと考えるかもしれませんが、ライセンス的に業務利用は難しいので対象外とします。
もうひとつ問題となるのがXMLパーサー部分です。XML WEBサービスを使用するクライアント用にMicrosoft SOAP Toolkitが配布されています。しかしながら、このコンポーネントは標準ではインストールされていないため「Officeさえインストールされていれば動作する」と言う利点を失います。
Windowsに標準でインストールされているMSXMLをパーサーとして使用する方法もありますが、MSXMLはInternet Explorerのモジュールです。そしてMicrosoft EDGEはMSXMLに対応しないことがアナウンスされています。将来性を考えるとこれも避けたいところです。

根本的な問題はVBAがCOMを基幹技術としているところです。Microsoftの基幹技術は既にとっくに.NETに移行しており、旧技術であるCOMは完全においていかれています。もういっそ、VBAは完全にあきらめて、VB.NET等の他言語で作成するというのはどうでしょうか?

Microsoft Office Interop

Visual Studioで作成したアプリケーションからMicrosoft Office Interopを使用してOfficeアプリケーションを操作する方法があります。幸いなことにOffice InteropはExpressエディションからも使用できるので追加投資も不要です。.Net Frameworkのバージョンを適切に選択すれば、実行ファイルをコピーするだけでも動作することが多く、展開も手軽です。
しかしながらOffice Interopはお世辞にも使いやすいlibraryではありません。単純なCOMのラッパーなのでインスタントの解放はプログラマーの責任で記述する必要があります。実際にコードを書くとインスタンスの生成と解放ばかりになって効率が悪いです。ライブラリが不出来なのが要因でコーディングの難易度が上がるのは、エンドユーザーコンピューティングでは避けたいところです。

Visual Studio Tools for Office(VSTO)

.NETでOfficeのプラグインを作成するために提供されたミドルウェアです。作成したプラグインを動作させるにはインストール作業が必要になるため展開はやや面倒になります。残念なことにVSTOもExpress版では使用できません。

Apps for Office

.NETでOfficeのプラグインを作成するために提供されたミドルウェアです。作成したプラグインを動作させるにはインストール作業が必要になるため展開はやや面倒になります。残念なことにApps for Office もExpress版では使用できません。

ClosedXML

ClosedXMLは Microsoft Open XML Formatのファイルを読み書きできるオープンソースの.NET用のミドルウェアです。Office2007以降ファイル拡張子がXMLXやDOCXに変更され、ファイル仕様が完全に公開されるようになりました。もちろんExpress版からも使えます。
この辺りが現実解では無いでしょうか。VBAを扱っていた経験があるなら、VB.NETに慣れるのもそれ程時間はかからないでしょう。Powersellから呼び出すのも面白いかもしれません。PowersellはWindows7以降に追加された、OSの操作に使用する言語です。Powersellからしか設定できない項目などもあり、Windowsを使う上で覚えておくととても便利です。

Excel REST API

https://channel9.msdn.com/Events/Visual-Studio/Connect-event-2015/315
まだPublic preview段階ですが、OneDriveやOffice365のクラウドストレージに保存したExcelファイルを編集するためのWebAPIです。現在、新しいOffice製品はクラウドストレージとの連携を前提として開発されています。WebAPI経由なら言語は選びませんし、各種のオープンデータとの連携も取りやすくなります。もしかしたらエンドユーザスクリプトの主流になるかもしれまけん。

VSTOやApps for Officeには無償でProfessional相当の機能を使えるCommunity版という選択もあるのですが、商用利用は著しく制限されているため、業務でのエンドユーザーコンピューティングには使いにくいです。私の場合には、ぐるっと回って「C#デスクトップアプリケーション + LINQ for MSSQL + ClosedXML」で組んでいくことにしてみました。

参考:
Roadmap for Apps for Office, VSTO, and VBA(http://blogs.msdn.com/b/vsto/archive/2013/06/18/roadmap-for-apps-for-office-vsto-and-vba.aspx)