エクセル雑感
生成AIが暴いた「VBAオワコン説」の盲点
問われるのは言語ではなく評価軸

「VBAは時代遅れだ。」
「これからはPythonやTypeScriptの時代。」
「VBAはもうオワコン。」
数年前まで、このような言説はIT界隈で珍しいものではありませんでした。
その根拠として挙げられていたのは、主に「言語仕様の古さ」と「マクロのセキュリティリスク」の二点です。
しかし、生成AIの登場、そして現在のExcel製品群を見ると、Microsoftは各技術を異なる用途で共存させる方向を選んだことが分かります。
この事実は、こうした議論の前提が十分ではなかったことを示しています。
ここで論じたいのは、「VBAは優れた言語だから生き残った」という話ではありません。
むしろ、「VBAは終わる」と断言していた人たちが、技術の本質ではなく、当時の評価軸しか見ていなかったということです。

VBA批判の中心には、常に言語仕様の古さがありました。

• クラスモジュールが扱いづらい
• モダンな構文ではない
• オブジェクト指向が弱い

他言語と比較して見劣りするという指摘は、確かに一面の事実です。
しかし、その議論には一つの大きな前提が隠れていました。
「人間が直接コードを書く」という前提です。
この前提こそが、当時のVBA批判を支えていた土台でした。
だからこそ、「どの言語が人間にとって書きやすいか」「どの言語が美しく、効率的にタイピングできるか」という静的な指標が絶対視されていました。

生成AIの登場は、この前提を根底から覆しつつあります。
現在でも、人間がコードを読み、レビューし、保守する場面は少なくありません。
しかし、AIはすでに、多くの場面で高い精度でコード生成、リファクタリング、テストコード作成、バグ修正の支援までを担うようになっています。
この流れが進めば、人間はコードを書く主体から、「何を実現したいか」を定義する主体へと役割を移していくでしょう。
すると重要になるのは、「人間が書きやすい言語」ではなく、「AIが安定してコード生成しやすい言語やエコシステム」という新しい評価軸です。
生成AIはVBAだけを有利にしたわけではありません。むしろ、多くのプログラミング言語において、「人間が書きやすいこと」の重要性を相対的に低下させました。
その上で、言語ごとの特徴やエコシステムが、新たな評価対象になりつつあります。
歴史が長くコード資産が豊富なVBAは、生成AIでも比較的安定したコードを生成しやすいと考えられます。
その背景には、長年にわたり蓄積されたサンプルコードや技術情報が豊富であり、さらにExcelのオブジェクトモデル（API）も長期間にわたって大きく変化していないため、学習済みモデルが参照できる知識量が多いことが挙げられます。
ここで重要なのは、言語仕様そのものだけではありません。
Workbook、Worksheet、Rangeといった、長期間にわたり仕様が大きく変わらないExcelのオブジェクトモデル（API）の存在も、AIにとっての「迷わなさ」となり、安定したコード生成を支える重要な要素となっています。
もちろん、これはVBAの言語仕様が新しくなったという意味ではありません。
重要なのは、「言語仕様の古さという弱点そのものが、人間と言語の距離感が変わることで、大幅に相対化された」という点です。
かつて決定的だと思われていた弱点は、技術のパラダイムシフトによって、実務上の影響が大きく低下しました。
今後、自律的にタスクを遂行する「AIエージェント」がさらに発達すれば、この評価軸の変化はさらに加速する可能性が高いと言えます。
AIにとって構造が安定している言語やエコシステムは、コード生成や保守の効率を高める可能性があります。
その結果、現場での運用コストが下がり、長期的には言語の競争力を支える要因の一つになり得ます。
これは、これからの時代における一つの将来像として十分に考えられるシナリオです。

現在のExcel製品群を見ると、Microsoftはどの言語も排除せず、それぞれの特性を活かして配置していることが分かります。

注目すべきは、PythonはVBAを置き換える存在にはならず、Office Scriptsもデスクトップ版VBAを駆逐したわけではないという点です。
なぜなら、これらは動作環境が異なるからです。
クラウドとの親和性を重視するOffice Scriptsには、ローカルファイルやPC内の別アプリケーションを直接操作する権限が与えられていません。
一方で、VBAはそのローカル環境における強力な連携力こそが最大の強みです。
Microsoftが現在採用している製品構成は、「一つの言語で全てを置き換える」という発想ではありません。
それぞれの言語を異なる評価軸のもとで最適化し、共存させるという設計思想です。
これは、「勝者が一つになる」という従来の言語論争とは異なる現実を示しています。

かつてVBA批判のもう一つの柱であった「セキュリティリスク」についても、同様の視野狭窄が見られます。
確かに、VBAマクロは強力な権限を持つため、不正なコードが実行されれば危険です。
しかし、その対策は「VBAという言語を廃止すること」ではありませんでした。
実際には、

• インターネットから取得したファイルのマクロを既定でブロックする製品設計の変更
• 信頼済み発行元や組織ポリシーによる管理
• 保護ビューの徹底

など、運用と製品設計のレイヤーにおける多層的な防御によって、リスクは大幅に低減されています。
つまり、問題の本質は「VBAという言語」そのものの欠陥ではなく、どのように境界を防御し、権限を管理するかという設計の問題だったのです。
これを言語の寿命と結びつけて語っていた点に、当時の批判論の論理的飛躍がありました。

「VBAは終わる」と語っていた人たちは、VBAそのものを見誤ったのではありません。
「技術の評価軸そのものが流動的に変化し、その重み付けが変わる」という未来の動態を想定できませんでした。
彼らは、「現在の開発環境と、現在の評価基準」という固定されたフレームワークの中で、言語のスペックを比較することには長けていました。
しかし、「生成AIのような技術革新によって、人間とプログラミングとの関わり方が変わり、評価軸の重み付けが書き換わる」という可能性までは、想像の範囲外だったと言えます。
技術を評価するとき、人は現在の課題や制約を前提に考えがちです。
しかし、その前提そのものが技術革新によって変化することは少なくありません。
評価軸は固定されたものではなく、技術や社会の変化に応じて常に更新され続けるものです。
VBA批判者の多くは、「言語仕様」や「セキュリティ」という個々の論点について議論していました。
しかし、それらの重要度そのものが変化する可能性までは十分に考慮していませんでした。
つまり、個々の技術を評価することには長けていても、「何を重視すべきか」という評価基準そのものが変わることを見落としていたのです。

テクノロジーの未来を予測するときに最も危険なのは、現在の評価軸が未来でもそのまま続くと考えてしまうことです。
生成AIは、単に新しい開発ツールを生み出しただけではありません。
「優れたプログラミング言語とは何か」「価値あるエコシステムとは何か」という評価軸そのものを変え始めています。
彼らが見誤ったのはVBAではありません。
技術そのものでもありません。
見誤ったのは、「技術が進歩すれば、技術を評価する物差しそのものも変わる」という事実だったのです。
そして、この教訓は決してVBAだけに留まりません。
生成AIが前提条件を揺るがし、評価軸そのものを書き換えていく現象は、今後、他の技術分野でも形を変えて繰り返されることになるでしょう。

同じテーマの記事
新着記事
アクセスランク