VBAとLuaでのAI開発はどっちが現実的？自動化スクリプトと組み込み処理の限界をCS目線で考察

VBAとLuaのロゴを背景に、AI推論の歯車とExcelシート・マイコンが重なったアイキャッチ画像 プログラミング言語

VBAとLua――どちらも「軽量スクリプト」として親しまれてきた言語ですが、AI開発の文脈で語られることはまだ多くありません。
しかし、実務レベルでは「Excelで完結する機械学習モデルのプロトタイピング」や「ゲームエンジン内で推論を動かす組み込みAI」といった需要が確実に存在します。
そこで本稿では、自動化スクリプトと組み込み処理という二つのユースケースに絞り、CS（計算機科学）の視点から両言語の現実的な適用範囲を整理してみます。

まず大前提として、AI開発の中核を担う大規模な深層学習や分散処理には、どちらの言語も適しません。
PythonやC++エコシステムが圧倒的に優位であり、それはメモリ管理、ベクトル演算ライブラリ、GPU連携の各レイヤで歴然とした差があります。
では、なぜ今あえてVBAとLuaなのか。
それは「既存の業務プロセスやハードウェアに組み込む」という制約条件が強い現場において、導入コストと実行効率のトレードオフが無視できなくなるからです。

VBAの強みは、言うまでもなくMicrosoft Officeオートメーションとの親和性です。
業務データがExcelに蓄積されているケースでは、AIモデルの入力前処理から出力結果の可視化までを一貫してVBAで記述できるため、外部環境を一切用意する必要がありません。
しかし、その代償として以下の制約を甘受しなければなりません。

  • 配列操作が低速であり、数十万レコードの行列演算は実用的でない
  • 再帰呼び出しのスタック制限が厳しく、深い木構造の推論は難しい
  • 外部の機械学習ライブラリを呼ぶにはCOM経由でPythonなどを起動するしかなく、オーバーヘッドが大きい

つまりVBAは、「既存のExcelファイルを動かしながら軽量な分類ルールや回帰式を適用する」 という極めて局所的なAIタスクにのみ現実解を持ちます。
例えば、閾値ベースの異常検知や線形単回帰程度であれば、ワークシート関数と組み合わせて十分な応答性を発揮します。

一方、Luaは組込み処理における軽量性とポータビリティが最大の武器です。
特にゲーム開発や家電ファームウェアでは、C/C++で書かれたホストプログラムにスクリプトとして埋め込まれ、メモリフットプリントが数百KB単位で収まります。
AI的観点では、ONNX RuntimeやTensorFlow LiteのLuaバインディングを利用すれば、事前に量子化した推論モデルをエッジデバイス上で走らせることが技術的には可能です。
ただし、ここにも現実的な壁があります。

  • 数値計算ライブラリが貧弱であり、行列積すら自前実装が求められる場面がある
  • マルチスレッド非対応の処理系が多く、バッチ推論時にボトルネック化する
  • エコシステムが断片的で、モデルのシリアライズ形式に互換性がないことが珍しくない

つまりLuaは、「リアルタイム性が求められる組み込み環境で、あらかじめ固定化された軽量モデルをひたすら推論し続ける」 というシナリオに最もフィットします。
学習フェーズは完全にオフラインで行い、推論エンジンとしてだけLuaを利用するのが現実的です。

ここで、両言語の適用判断を簡単な表にまとめてみます。

評価軸 VBA Lua
実行速度（純粋演算） 遅い（インタプリタオーバーヘッド大） 中速（JIT処理系で改善可）
外部ライブラリ連携 COM経由に限定され煩雑 Cバインディングで柔軟に対応可
データ可視化・出力 Excel機能をフル活用可能 テキスト出力か簡易グラフに制限
導入・配布の容易さ Office環境で即利用可 実行環境への組み込み作業が必須
学習フェーズの実装 非推奨（時系列バッチ処理すら困難） 非推奨（勾配計算の効率が悪い）

この比較から見えてくる結論はシンプルです。
AIの「学習」は両言語とも現実的ではなく、「推論」に特化した場合でも、VBAは業務フロー内のアドホックな判定処理、Luaはハードウェア密着型の組み込み推論と、住み分けが明確です。
どちらかを汎用的なAI開発言語として選ぶのではなく、「自動化対象の既存システムがExcelか、それとも組込みファームか」という第一条件で決めるべきでしょう。

では、仮にそれでもVBAで機械学習らしいことをしようとすれば、行列演算を配列ループで書くことになります。
例えば、単純パーセプトロンの重み更新をVBAで実装すると、100サンプル・10特徴量でも体感できる遅延が生じます。
一方Luaで同様のコードを書けば、テーブル操作のオーバーヘッドはあるものの、C拡張で書かれた関数に処理を丸投げすることで実用域に到達できます。
この差は、言語自体の設計というより、ホスト環境との連携設計の差に起因しています。

最後に、将来性の観点も軽く触れておきます。
MicrosoftはVBAの後継としてOffice Scripts（TypeScriptベース）を推進しており、AI連携もAzure Functions経由でクラウド化される流れです。
Luaも同様に、WebAssemblyや組み込みAI向けの軽量ランタイムとして再注目される可能性はありますが、現時点ではエコシステムの拡大に懐疑的です。
結局のところ、AI開発の「現実的」さは、言語仕様ではなく、運用環境と保守期間で決まります。
あなたのプロジェクトが5年後もExcelマクロで動くべきなのか、それともバッテリー駆動のデバイスで動き続けるべきなのか。
その問いに答えることこそが、VBAかLuaかの選択より先にあります。

  1. なぜ今、VBAとLuaなのか――AI開発における二極化の背景
    1. AIワークロードの二極化とスクリプト言語の棲み分け
    2. エッジコンピューティングとレガシーシステムの交差点
    3. なぜ両言語が「AI開発」と見なされないのか
  2. VBAの強みと限界――Officeオートメーション上のAI処理はどこまで現実的か
    1. VBAで実装可能なAIタスクの具体例
    2. VBAにおける外部ライブラリ連携の現実――COM経由Python起動の代償
  3. Luaの強みと限界――組み込みシステムで推論を動かすための条件
    1. Luaで推論エンジンを構築する際の実装パターン
    2. ONNX RuntimeやTensorFlow LiteとLuaの接続ポイント
  4. 学習フェーズは両言語とも非現実的――その理由を計算複雑性から解説
    1. バックプロパゲーションが要求する演算特性と両言語のミスマッチ
    2. メモリアクセスパターンの違いがもたらすパフォーマンスギャップ
    3. 学習済みモデルのインポートという現実解
  5. 推論特化の比較表――速度・連携・可視化・導入コストで見る実力差
    1. 評価軸の定義と測定条件
    2. 比較結果の詳細解説
    3. プロジェクトタイプ別の選択基準
  6. ケーススタディ――Excel業務フロー内の異常検知 vs エッジデバイスでの画像分類
    1. ケース1：Excel業務フロー内での取引異常検知（VBA採用シナリオ）
    2. ケース2：エッジカメラでの製品画像分類（Lua採用シナリオ）
    3. 両ケースの対比から見える設計原則
  7. VBAとLuaの将来性――Office ScriptsとWebAssemblyの台頭が変える選択肢
    1. Office ScriptsがもたらすVBAの置き換え可能性
    2. WebAssemblyがLuaの組み込み領域に与える影響
    3. それでもLuaが生き残るシナリオ
    4. 総合的な将来予測
  8. 結論――プロジェクトのライフサイクルと運用環境で選ぶべき言語の基準
    1. 判断基準1：データの流れとユーザーインターフェースを定義する
    2. 判断基準2：モデルの更新頻度と運用ライフサイクルを評価する
    3. 判断基準3：既存システムとの依存関係とリソース制約を洗い出す
    4. 判断基準4：保守期間とスキルセットを考慮する
    5. 総合判断フローチャート

なぜ今、VBAとLuaなのか――AI開発における二極化の背景

VBAとLuaのロゴを並べて、AI開発における役割の違いを問いかけるイメージ図

AI開発と聞けば、多くのエンジニアは即座にPythonとそのエコシステムを思い浮かべるでしょう。
PyTorchにTensorFlow、scikit-learnにJupyter Notebook――これらがデファクトスタンダードであることは、もはや議論の余地がありません。
しかし、現場の実装においては、「Pythonを導入するほど大げさではないけれど、ちょっとした推論ロジックを既存の業務システムやデバイスに埋め込みたい」 というニーズが確実に存在します。
そこで浮上するのが、VBAとLuaという二つの「異端児」です。

では、なぜ今あえてこれらを取り上げるのか。
その理由は、AIの実装形態が「学習フェーズ」と「推論フェーズ」で完全に分離されつつあることと深く関係しています。
学習は大規模なGPUクラスタやクラウド環境で済ませ、推論だけを軽量スクリプトで現場にデプロイするというアーキテクチャが一般化した今、VBAやLuaが担える領域が明確に見えてきました。

AIワークロードの二極化とスクリプト言語の棲み分け

機械学習パイプラインを大まかに分解すると、以下の三つの段階に分けられます。

  • データ前処理と特徴量エンジニアリング
  • モデルの学習とハイパーパラメータチューニング
  • 学習済みモデルを用いた推論と結果の出力

このうち、第二段階の学習は絶対にVBAやLuaの守備範囲ではありません。
バックプロパゲーションの行列演算や自動微分は、BLASやcuBLASのような低レベル最適化ライブラリの上に構築されたフレームワークなしには実用速度が出ません。
しかし、第一段階と第三段階、特にデータがすでにExcelに存在するケースやハードウェアがリソース制約の強い組み込み環境であるケースでは、話が変わってきます。

ここで重要なのは、Pythonが必ずしも「軽量埋め込み」に適していないという事実です。
Pythonのインタプリタ自体が数MBから数十MBを消費し、依存ライブラリを含めれば簡単に数百MBに達します。
また、実行環境のバージョン管理や仮想環境の構築は、業務システムへの組み込みにおいては大きなオーバーヘッドです。
対してVBAは、Microsoft Officeがインストールされていれば追加コストゼロで動作し、Luaはインタプリタコアがわずか200KB前後で完結します。
この「導入コストの差」は、AI導入を検討する現場の制約条件と直結するため、決して無視できるものではありません。

エッジコンピューティングとレガシーシステムの交差点

もう一つ、背景として見逃せないのがエッジコンピューティングの拡大です。
工場のセンサーデータをリアルタイムで判定する、家電製品に搭載されたカメラで人物検出を行う、ドローンで障害物回避の推論を飛ばし続ける――こうしたシナリオでは、消費電力や応答レイテンシが厳しく制限されます。
Luaは、C/C++で記述されたホストプログラムに軽量に埋め込めるため、RTOSや組み込みLinuxの上で数ミリ秒単位の推論ループを実装するのに適しています。

一方で、金融機関や製造業のバックオフィスでは、今なおExcelを中心とした業務フローが健在です。
売上予測や在庫の異常検知といったAIタスクは、外部のPythonサーバーを呼び出すよりも、VBAマクロ内で完結させたいという要望が実際に存在します。
Excelアドインとして配布できる手軽さ、マクロの記録機能を使ったプロトタイピングの速さ、そして何よりユーザーインターフェースとしての表計算機能の強力さは、VBAならではの魅力です。

なぜ両言語が「AI開発」と見なされないのか

ここで冷静になるべきは、VBAもLuaも、そもそもAIを意識して設計された言語ではないという点です。
VBAはOfficeオートメーション、Luaは組み込みスクリプティングが主目的であり、いずれも数値計算やベクトル処理を高速化するための言語機能を標準では持ちません。
つまり、AI開発言語としてではなく、「AIを組み込む先の環境がたまたまVBAやLuaを話す」 という視点が正しい立ち位置です。

とはいえ、だからこそ両言語は、「Pythonが入れられない場所」でAIを動かすための現実的な選択肢となり得ます。
最近では、ONNX RuntimeのLuaバインディングや、Excelの新しいLAMBDA関数とVBAの連携など、両者のAI親和性を高める技術的進展も見られます。

以上の背景を踏まえると、VBAとLuaの比較は、単なる言語機能の優劣ではなく、「業務自動化」と「組み込み処理」という全く異なるドメインにおけるAI導入戦略の比較であることがお分かりいただけるでしょう。
次の章では、それぞれの言語の強みと限界を具体的な実装例を交えながら掘り下げていきます。

VBAの強みと限界――Officeオートメーション上のAI処理はどこまで現実的か

Excelのワークシート上で回帰分析のグラフとVBAコードが表示されているスクリーンショット

VBAをAI開発の文脈で語る際、まず認識すべきは、この言語が本質的に「Officeオートメーション」のために設計されたという事実です。
配列の動的確保は遅く、再帰はスタックを容易に消費し、オブジェクト指向も中途半端な実装に留まります。
しかし、それでもなおVBAが現役であり続ける理由は、Excelという圧倒的なデータプラットフォームの前面に立っているからに他なりません。

AI処理において、データの前処理と後処理は全体工数の半分以上を占めるとも言われます。
そして、そのデータが日々の業務でExcel上に蓄積されているならば、VBAは前処理から推論、可視化までを一貫して記述できる唯一のネイティブ言語です。
ここでは、VBAが現実的に担えるAIタスクの範囲と、外部連携の現実解を整理してみます。

VBAで実装可能なAIタスクの具体例

VBAで実装可能なAI処理は、「計算量がO(n)またはO(n log n)で収まり、かつ特徴量がせいぜい数十次元まで」 という問題に限定されます。
具体的には、以下のようなタスクが現実的なラインです。

  • 単純パーセプトロンやロジスティック回帰による二値分類
  • 線形回帰を用いた時系列トレンド予測（移動平均や指数平滑の拡張として）
  • k近傍法（k-NN）による簡易なパターンマッチング（ただしサンプル数は数百件が限界）
  • 決定木の深さを3〜4に制限したルールベースの異常検知
  • ベイズの定理を用いた簡易スパムフィルタや確率的判定

例えば、単純パーセプトロンの重み更新をVBAで書く場合、以下のようなループ構造になります。

For i = 1 To numSamples
    For j = 0 To numFeatures
        weights(j) = weights(j) + learningRate * error * features(i, j)
    Next j
Next i

このコード自体はシンプルですが、特徴量が100、サンプルが1万件を超えると、二重ループのオーバーヘッドが顕著になり、1エポックに数秒から数十秒を要するようになります。
つまり、VBAでのAI実装は「バッチ学習」ではなく「オンライン学習的な逐次更新」か、あらかじめ外部で計算した係数を読み込んで適用する「推論専用」が現実的です。

また、VBAの強力な特徴として、ワークシート関数との協調が挙げられます。
行列積や逆行列はExcelのMMULTやMINVERSE関数に任せ、VBAは制御ロジックと入出力のグルーコードに徹する。
このハイブリッド手法を使えば、回帰係数の推定程度であれば実用速度を確保できます。

VBAにおける外部ライブラリ連携の現実――COM経由Python起動の代償

では、どうしてもニューラルネットワークや勾配ブースティングが必要な場合はどうするか。
VBAから外部のライブラリを呼び出す最も一般的な手段は、COM（Component Object Model）経由での連携です。
具体的には、CreateObject関数を使ってPythonスクリプトを実行するためのCOMサーバー（例えばPyWin32のCOMオブジェクト）を起動し、データを渡して結果を受け取るというアプローチです。

しかし、この方法には無視できない三つの代償が伴います。

  • 起動オーバーヘッド：PythonインタプリタをCOM経由で起動するたびに数百ミリ秒から数秒のレイテンシが発生し、対話的な処理には不向き
  • データシリアライズのコスト：VBAの配列をCOMのVariant型経由でPythonに渡す際、型変換とメモリコピーが発生し、大規模データではボトルネック化
  • エラーハンドリングの複雑化：Python側の例外がVBAに正しく伝播せず、デバッグが著しく困難になる

これらの問題は、「Pythonを呼ぶくらいなら最初からPythonで全部書けばよい」 という結論に至る十分な理由です。
実際、筆者の経験では、COM経由の連携はバッチ処理や定期実行のような非対話型のタスクに限定し、かつデータ量が数百行程度に収まる場合だけに留めるべきだと判断しています。

では、VBAでAIを実装する現実的な戦略とは何か。
それは、「学習は外部のPythonスクリプトで済ませ、その結果として得られた係数やルールセットだけをVBAに埋め込む」 というハイブリッドアーキテクチャです。
例えば、Pythonで訓練したロジスティック回帰の重みをJSONやCSVで出力し、VBAで読み込んで推論式を計算する。
この方法なら、VBAは純粋な推論エンジンとして動作し、COM経由のオーバーヘッドも完全に回避できます。

また、最近のExcelでは、LAMBDA関数やLET関数を使った数式ベースの機械学習も可能になりつつありますが、これらはVBAを経由せずにワークシート内で完結する点で、むしろVBAより軽量な選択肢と言えるでしょう。
いずれにせよ、VBAでAIを扱う際の鉄則は、「VBAに学習をさせない」こと。
この前提を守る限り、VBAは業務フロー内でのAI実装において十分に実用的な選択肢となり得ます。

Luaの強みと限界――組み込みシステムで推論を動かすための条件

マイコンボードやゲームエンジン上でLuaスクリプトが推論処理を実行している概念図

LuaがAI推論の文脈で注目される理由は、一言で言えば「埋め込みやすさ」 です。
本言語はもともとC言語で記述されたホストプログラムへの組み込みを前提に設計されており、インタプリタコアはわずか数百KB程度に収まります。
この軽量性は、メモリ制約の厳しいエッジデバイスや、リアルタイム性が求められるゲームエンジン内での推論実行において、極めて戦略的なアドバンテージとなります。

ただし、Luaは数値計算やベクトル演算を高速化するための組み込み機能を一切持っていません。
動的型付けとテーブルベースのデータ構造は柔軟である反面、大規模な行列演算には根本的に不向きです。
LuaでAIを動かすとは、あくまで「学習済みモデルの推論処理を軽量スクリプトで制御する」 という意味であり、Pythonで行うような学習フェーズの実装は想定すべきではありません。

Luaで推論エンジンを構築する際の実装パターン

Luaを用いた推論エンジンの典型的な実装パターンは、「ホストプログラム（C/C++）が推論の重い処理を担い、Luaは制御フローとデータの前後処理を記述する」というものです。
具体的には、以下のようなアーキテクチャが現実的です。

  • ホスト側で推論セッションを初期化し、モデルファイルをロードしておく
  • Luaスクリプトからホスト側のC関数を呼び出し、入力データを渡して推論を実行
  • 推論結果を受け取ったLuaスクリプトが、後処理や条件分岐を実施

このパターンの実装において、LuaとCの連携は非常にスムーズです。
LuaのC APIを用いれば、Luaのスタックを介して数値や文字列、さらにはテーブル単位でデータをやり取りできます。
また、LuaJITを採用すれば、実行時コンパイル（JIT）による高速化も期待でき、特にループ処理が主体の前後処理では顕著な効果を発揮します。

加えて、Luaはテーブルという単一のデータ構造で配列・レコード・オブジェクトを統一的に表現するため、推論結果の加工や条件分岐の記述が非常に簡潔になります。
例えば、センサーデータの正規化や、推論結果に基づくアクチュエータ制御の分岐などは、数十行のLuaコードで実装可能です。

ONNX RuntimeやTensorFlow LiteとLuaの接続ポイント

では、実際の推論エンジンであるONNX RuntimeやTensorFlow LiteとLuaはどのように接続するのでしょうか。
ここが本稿の核心的な技術的ポイントです。

ONNX Runtimeは、クロスプラットフォームな機械学習モデル推論アクセラレータであり、PyTorchやTensorFlowなど多様なフレームワークで学習したモデルを実行できます。
Microsoft製品群での採用実績もあり、推論速度の平均2.9倍向上というデータも報告されています。
LuaからONNX Runtimeを利用する場合、C API経由でONNX RuntimeのセッションをラップしたLuaモジュールを作成し、Luaスクリプト内から推論関数を呼び出せるようにします。

具体的な実装イメージとしては、以下のような流れになります。

-- Lua側の呼び出し例（概念）
local onnx = require("onnxruntime")
local session = onnx.InferenceSession("model.onnx")
local input = {data = sensor_values}
local output = session:run(input)
local label = postprocess(output)

このとき、Luaはあくまで「呼び出し元」であり、実際のテンソル演算やハードウェアアクセラレーション（GPUやNPU）はONNX Runtime側が担当します。
ONNX RuntimeはAndroid Neural Networks APIやCore MLなどのデバイス固有のアクセラレータにも対応しているため、組み込み環境でも高いパフォーマンスを発揮可能です。

一方、TensorFlow Liteはモバイルや組み込みデバイス向けの軽量推論フレームワークであり、FlatBuffers形式のモデルファイルを用いて高速な推論を実現します。
TensorFlow LiteもC++ APIを提供しているため、Luaから利用するには同様にCバインディングを介します。
特に、TensorFlow Liteはマイクロコントローラ向けの「TensorFlow Lite Micro」も提供しており、メモリが数KBしかない環境でも動作する点で、Luaとの親和性は極めて高いと言えます。

重要なのは、Lua自体がONNX RuntimeやTensorFlow Liteのバインディングを標準で持っていないという点です。
つまり、これらの接続ポイントはユーザー自身がC/C++でラッパーを実装し、Luaから呼び出せる形に整備する必要があります。
その作業コストは無視できませんが、一度ラッパーを構築してしまえば、Luaスクリプトだけで推論処理を柔軟に制御できるようになるため、長期的なメンテナンス性は大きく向上します。

なお、ONNX RuntimeとTensorFlow Liteの選択基準としては、モデルのエコシステムとターゲットデバイスを優先すべきです。
既存のモデルがONNX形式で用意されているならONNX Runtime、TensorFlowエコシステムに強く依存しているならTensorFlow Lite、という棲み分けが現実的です。
いずれにせよ、Luaはその軽量なインタプリタとC連携の容易さにより、これらの推論エンジンを「制御する側」として十分に機能します。

学習フェーズは両言語とも非現実的――その理由を計算複雑性から解説

勾配降下法の反復計算がVBAとLuaで非効率になる理由を示すベンチマークグラフ

ここまでの議論で、VBAもLuaも「推論」を主体とした利用が現実的であり、「学習」には適さないという点を繰り返し強調してきました。
しかし、この主張は単なる経験則ではなく、計算複雑性理論とメモリアクセスパターンの観点から明確に説明することができます。
本項では、なぜ両言語が学習フェーズに致命的に不向きなのかを、コンピューターサイエンスの基礎に立ち返って掘り下げます。

バックプロパゲーションが要求する演算特性と両言語のミスマッチ

深層学習に限らず、ほとんどの機械学習アルゴリズムの学習プロセスは、大規模な行列積とその勾配計算の繰り返しです。
例えば、ニューラルネットワークの順伝播では、入力ベクトルに重み行列を乗算し、活性化関数を適用します。
逆伝播では、連鎖律に従って誤差を各層に伝播させながら、重みの偏微分を計算していきます。

これらの処理が効率的に行われるためには、以下の三つの条件が満たされる必要があります。

  • 連続メモリ上のブロック演算：行列の行と列がメモリ上に連続して配置され、キャッシュヒット率が高いこと
  • SIMD（単一命令複数データ）やベクトルレジスタの活用：同じ演算を複数のデータ要素に同時に適用できること
  • GPUや専用アクセラレータへのオフロード：数千ものコアで並列に行列積を計算できること

VBAはこれらの条件を満たすための言語機能を一切持ち合わせていません。
VBAの配列はCOMのSafeArrayとして実装されており、メモリレイアウトは不透明で、連続性も保証されません。
さらに、VBAの演算はすべてインタプリタが1命令ずつ解釈し、ネイティブコードに変換されるとしても、ループ内の個々の数値演算が逐一オーバーヘッドを伴います。
このため、1000次元の行列積をVBAで実装すると、C++の数十万倍の実行時間を要するケースが珍しくありません。

Luaも事情は似ています。
Luaのテーブルはハッシュテーブルと配列部分を併せ持つ柔軟な構造ですが、数値が格納される配列部分も、連続したメモリ領域としての保証は弱く、キャッシュに乗りにくいという問題があります。
LuaJITを使用すればFFI（Foreign Function Interface）経由でCの配列を直接操作できるため、ある程度の改善は見込めますが、それでもJITコンパイラが最適化できるのは純粋なLuaコードのみであり、テーブル間の行列演算のような複雑なパターンでは効果が限定的です。

メモリアクセスパターンの違いがもたらすパフォーマンスギャップ

学習フェーズで顕著になるもう一つのボトルネックは、メモリアクセスパターンの局所性です。
現代のCPUは、メインメモリからデータを読み込む際に、キャッシュライン（通常64バイト）単位でデータを先読みします。
このため、メモリ上で隣接する要素に順次アクセスする「ストライド1」のパターンが最も高速であり、ランダムアクセスや飛び飛びのアクセスはキャッシュミスを連発して性能が劇的に低下します。

行列積では、行優先と列優先のアクセスパターンを適切に設計することで、キャッシュヒット率を最大化できます。
例えば、C言語で記述されたBLASライブラリは、ブロック化（タイリング）と呼ばれる手法を用いて、キャッシュサイズに合わせた小ブロック単位で計算を進めることで、メモリスループットを限界まで引き上げます。

VBAで同様のブロック化を実装しようとすると、そもそも配列のインデックス操作自体が遅いうえに、Forループのネストが深くなればなるほどインタプリタの命令デコードオーバーヘッドが累積します。
また、Luaのテーブルは連続配列であっても、内部的にはオブジェクトの配列として管理されるため、数値データがボックス化（ヒープ上にオブジェクトとして格納）されるオーバーヘッドが避けられません。

このメモリ特性の差を具体的な数値で示すと、以下のようになります。

実装方法 メモリアクセス効率 演算速度（相対値） 実装難易度
VBA純正ループ 低（キャッシュミス多発） 1倍（基準） 簡単
LuaJIT + FFI配列 中（C配列で改善） 約5〜10倍 中程度
Python + NumPy（C実装） 高（BLAS最適化） 約100倍超 簡単
C++ + Eigen / cuBLAS 極高（GPU利用可） 約1000倍超 難しい

この表から明らかなように、VBAとLuaは学習処理において、言語自体のオーバーヘッドとメモリ管理の非効率性という二重のハンディキャップを負っています。
特に、バックプロパゲーションの各エポックで全サンプルを反復処理する必要がある点が致命傷です。
サンプル数1万、特徴量100、隠れ層が2層程度の小さなニューラルネットワークでも、VBAでは数十時間、Luaでも数時間を要するのに対し、Python+NumPyでは数秒で完了します。

学習済みモデルのインポートという現実解

以上を踏まえると、結論は明確です。
VBAやLuaで「学習」を実装しようとする試みは、時間的コスト対効果の観点から完全に非現実的です。
では、どうするのか。
現実的なアプローチは、学習をPythonやC++などの高速エコシステムで完遂させ、その成果物として得られた重みやパラメータをVBAやLuaに埋め込むことです。

たとえば、Pythonで訓練したロジスティック回帰の係数セットをJSONファイルに出力し、VBAでそれを読み込んでシグモイド関数を適用する。
あるいは、ONNX形式にエクスポートしたモデルを、LuaからCバインディング経由でONNX Runtimeに読み込ませて推論だけを行う。
こうした「学習オフライン・推論オンライン」の分離アーキテクチャこそが、両言語の限界を補い、かつ強みを活かす最適解です。

学習フェーズを軽視するのではなく、適切なツールを適切な段階に割り当てるというソフトウェア工学の基本原則に従うこと。
それが、VBAやLuaをAI開発に利用する際の鉄則と言えるでしょう。

推論特化の比較表――速度・連携・可視化・導入コストで見る実力差

VBAとLuaを速度・ライブラリ連携・可視化・導入の4軸で比較したテーブル画像

ここまでの各章で、VBAとLuaの特性を個別に深掘りしてきました。
しかし、実際のプロジェクトでどちらを選ぶかは、複数の評価軸を総合的に比較した上で判断する必要があります。
本項では、AI推論に特化したユースケースを想定し、速度・外部連携・可視化・導入コストという四つの主要な指標で両言語を定量的かつ定性的に比較します。
最終的には、あなたのプロジェクトがどの軸を最優先するかで選択肢が自ずと絞られるはずです。

評価軸の定義と測定条件

比較の公平性を保つため、以下の前提を設定します。

  • 推論タスクは、100次元の入力ベクトルから10クラスの確率分布を出力する全結合ニューラルネットワーク（隠れ層2層、各64ノード）を想定
  • モデルの重みは事前に学習済みで、バイナリ形式またはJSON形式で保存されている
  • VBAはExcel 365（64ビット版）、LuaはLuaJIT 2.1を実行環境とする
  • 外部連携は、VBAはCOM経由のPython呼び出し、LuaはCバインディング経由のONNX Runtime呼び出しを想定

この前提のもと、各評価軸を定義します。

速度（推論レイテンシ） ：単一サンプルの推論にかかる平均処理時間。
バッチ処理ではなく逐次処理を対象とします。

外部連携（ライブラリ・モデル形式の対応力） ：TensorFlow Lite、ONNX Runtime、PyTorch Mobileなどの主要推論エンジンとの接続容易性。
既存のエコシステムをどれだけ活用できるかを評価します。

可視化（結果の出力・表示のしやすさ） ：推論結果をチャートや表としてユーザーに提示する際の工数と表現力。

導入コスト（環境構築と配布の手間） ：実行環境をゼロから構築するための工数、およびエンドユーザーへの配布時に発生する依存関係の複雑さ。

比較結果の詳細解説

それでは、各項目の評価結果を総合表としてまとめ、その後で項目ごとに補足します。

評価軸 VBA（Excel 365） Lua（LuaJIT + ONNX Runtime） 勝者
速度（推論レイテンシ、ミリ秒） 約120〜200ms（純粋VBA実装）／約50〜80ms（ワークシート関数併用） 約5〜15ms（Cバインディング経由） Lua（圧倒的）
外部連携（対応モデル形式） CSV/JSONの係数読み込みのみ。ONNX・TFLiteはCOM経由で間接利用 ONNX・TFLite・PyTorch MobileにCバインディングで直接接続可 Lua
可視化（出力表現力） Excelのグラフ・条件付き書式・ピボットをフル活用可能 テキスト出力か簡易的なHTML生成が限界。GUIはホスト側に依存 VBA（圧倒的）
導入コスト（環境構築工数） Office標準搭載。アドオン不要で即利用可 インタプリタ＋バインディングのビルド・モデル配置が必要。数時間〜数日 VBA

この表から見える構図は非常に明確です。
速度と外部連携ではLuaが圧勝し、可視化と導入コストではVBAが圧勝する――まさにトレードオフの関係が成立しています。

速度の差は特に顕著です。
LuaがCバインディング経由でONNX Runtimeを呼び出す場合、推論の本体は最適化されたC++コードで実行されるため、レイテンシは数ミリ秒に収まります。
一方、VBAで純粋に配列ループを回してシグモイド関数やソフトマックスを実装する場合、サンプル1件あたり100ミリ秒超は覚悟しなければなりません。
ワークシート関数のMMULTを活用すればある程度は改善されますが、それでもLuaには遠く及びません。

外部連携においても、LuaはONNX RuntimeやTensorFlow LiteのC APIを直接呼び出せるため、量子化モデルやハードウェアアクセラレーションの恩恵を受けやすいのに対し、VBAはCOM経由でPythonを起動する以外に手段がなく、間接性とオーバーヘッドが常に付きまといます。

しかし、可視化の面ではVBAが圧倒的に強力です。
推論結果をヒートマップで表示したい、時系列予測を折れ線グラフで重ねたい、閾値を超えたデータに自動で色付けしたい――これらすべてがExcelのネイティブ機能として提供されており、VBAからそれらを制御するコードは極めて直感的に書けます。
Luaでは、結果をCSVに吐き出して別の可視化ツールで表示するか、ホストアプリケーションに描画機能を実装する必要があり、追加の開発工数が発生します。

導入コストに関しても、VBAはOfficeが入っているすべてのWindowsマシンで即座に動作するという「ゼロインストール」のアドバンテージを持ちます。
Luaはインタプリタ本体は軽量ですが、モデルファイルの配置やバインディングのビルド、パスの設定など、開発者側で事前に整備すべき項目が少なくありません。

プロジェクトタイプ別の選択基準

以上の比較を踏まえ、実際のプロジェクトの種類ごとに推奨される選択肢を整理します。

  • 業務レポート内での簡易判定（売上予測、異常値フラグなど） → VBAを選択。可視化と導入の容易さが最優先
  • 工場センサーやロボット制御でのリアルタイム推論 → Luaを選択。レイテンシとハードウェア連携が最優先
  • Office環境で高度な深層学習モデルを使いたい → VBAは非推奨。Pythonサーバーを別途立ててAPI連携する方が現実的
  • 組み込みLinuxボードでカメラ画像の推論を並列処理したい → Lua＋ONNX Runtimeが最適。メモリ消費も抑えられる

このように、速度を取るか、可視性と導入容易性を取るかは、あなたのユーザーが誰で、どのようなインターフェースで結果を受け取るのかによって決まります。
エンドユーザーがExcelを日常的に使うビジネスパーソンならVBA、ハードウェアエンジニアやゲーム開発者ならLuaという住み分けが、最も現実的な答えでしょう。

ケーススタディ――Excel業務フロー内の異常検知 vs エッジデバイスでの画像分類

左側にExcelダッシュボード、右側に小型カメラ付きエッジデバイスを配置した対比イラスト

理論的な比較だけでは、実際のプロジェクトでVBAとLuaのどちらを選ぶべきか、判断に迷う方も多いでしょう。
そこで本項では、二つの具体的なユースケースを想定し、それぞれの言語がどのように適用され、どのような制約とメリットが生じるのかをシミュレーションします。
一つは金融系バックオフィスで発生する「取引データの異常検知」、もう一つは製造現場の「エッジカメラを使った製品画像の分類」です。
両者はAI推論という共通項を持ちながら、要求される非機能要件が根本的に異なる点に注目してください。

ケース1：Excel業務フロー内での取引異常検知（VBA採用シナリオ）

ある資産運用会社では、日次で数千件の取引データがExcelシートに蓄積されています。
コンプライアンス部門は、過去の不正取引パターンを学習したロジスティック回帰モデルを用いて、新規取引に「異常スコア」を付与したいと考えています。
ただし、IT部門のポリシーにより、外部サーバーへのAPI呼び出しは認められておらず、すべての処理は社内のExcelファイル内で完結させる必要があります。

このケースでVBAを採用する場合の実装戦略は、以下の通りです。

  • Python環境で過去データを学習し、回帰係数と切片をJSONファイルにエクスポート
  • VBAマクロでJSONを読み込み、係数配列をメモリ上に保持
  • 新しい取引データがシートに入力されるたびに、VBAのシグモイド関数で異常確率を計算
  • 確率が閾値（例：0.85）を超えた行に赤色の条件付き書式を適用
  • 結果をピボットテーブルで集計し、異常取引の多い取引先ランキングを自動生成

このシナリオでのVBAのメリットは、エンドユーザーがExcelを開くだけで全てが動作する点です。
マクロの実行ボタンを押せば、データの読み込みから推論、可視化、レポート出力までが一連のフローで完了します。
また、条件付き書式やピボットテーブルといったExcelの標準機能をフル活用できるため、開発工数が大幅に削減されます。

一方で、制約も明らかです。
推論速度は1件あたり約100ミリ秒程度であり、数千件のバッチ処理には数分を要します。
また、モデルを更新するたびにJSONファイルを再配置する運用が発生し、バージョン管理が煩雑になります。
それでも、「Excelだけで完結する」という制約の下では、VBAが唯一の現実解であると言えるでしょう。

ケース2：エッジカメラでの製品画像分類（Lua採用シナリオ）

次に、製造業の工場ラインを考えます。
流れてくる製品をカメラで撮影し、表面の傷や欠陥をリアルタイムで分類する必要があります。
製品は1秒間に5個通過し、各画像は64×64ピクセルのグレースケールです。
推論は工場内のエッジコンピュータ（ARMベースのLinuxボード、メモリ512MB）で実行し、ネットワークが不安定なためクラウドは使えません。

このケースでは、Luaが極めて有効です。
実装戦略は以下の通りです。

  • 事前にPythonでCNN（畳み込みニューラルネットワーク）を訓練し、ONNX形式にエクスポート
  • ONNX RuntimeのC++ラッパーを作成し、Luaから呼び出せるバインディングを準備
  • Luaスクリプトでカメラドライバから画像データを取得し、正規化して推論関数に渡す
  • 推論結果（正常／軽微傷／重大傷）に基づき、製品を振り分ける信号をGPIO経由で出力
  • 1秒間の推論統計（合否件数、各クラスの割合）をログファイルに追記

このシナリオでのLuaの最大の強みは、推論レイテンシが約8ミリ秒と極めて高速であり、製品の流れに余裕を持って追随できる点です。
また、LuaスクリプトはCバインディング経由でハードウェア制御（GPIOやシリアル通信）ともシームレスに連携できるため、推論結果を即座に物理アクションに変換できます。
メモリ消費も、ONNX Runtimeのモデル読み込みで約80MB、Luaインタプリタとバインディングで数MBと、512MBの制限内に十分収まります。

制約としては、可視化機能が極めて貧弱なことが挙げられます。
ログファイルにテキスト出力する以外に、リアルタイムなグラフ表示はホスト側に別途Webサーバーを立てるなど追加実装が必要です。
また、Luaスクリプトのデバッグにはprint文を駆使するしかなく、本番環境でのトラブルシュートは容易ではありません。

両ケースの対比から見える設計原則

以上の二つのケーススタディを並べてみると、VBAとLuaの選択は「誰が使うか」と「どこで動くか」 に集約されることが分かります。

  • VBAは「ビジネスユーザーがExcel上で結果を視覚的に確認したい」ケースに最適
  • Luaは「エンジニアがハードウェアと密接に連携しながら高速推論を回したい」ケースに最適

どちらのケースも、学習はPythonが担い、推論だけを現地の言語で実装するという共通アーキテクチャを持っています。
そして、その「現地の言語」がVBAかLuaかは、最終的にソフトウェアが配置される環境と、その環境で利用可能なリソースによって決まるのです。
あなたのプロジェクトがどちらのパターンに近いかを考えれば、自ずと選ぶべき言語は見えてくるでしょう。

VBAとLuaの将来性――Office ScriptsとWebAssemblyの台頭が変える選択肢

Office ScriptsのアイコンとWebAssemblyのロゴが並び、VBA・Luaの将来を示すタイムライン

これまでVBAとLuaの現時点での実力を比較してきましたが、エンジニアとして将来を見据えるならば、これらの言語が今後どのような道を辿るのかにも目を向けるべきでしょう。
テクノロジーの進歩は常に選択肢を広げる一方で、既存のツールを陳腐化させることもあります。
本項では、VBAの次世代候補であるOffice Scriptsと、Luaの代替となり得るWebAssembly（WASM）の動向を踏まえつつ、両言語の将来性を冷静に評価してみます。

Office ScriptsがもたらすVBAの置き換え可能性

Microsoftは、Excelを含むOffice製品の自動化において、VBAの後継としてOffice Scriptsを推進しています。
Office ScriptsはTypeScriptをベースとしており、Excel on the WebやExcel for Windows（バージョン2208以降）で実行可能です。
従来のVBAと異なり、クラウドネイティブな設計がなされており、Power Automateとの連携や、外部APIへのHTTPリクエストが標準でサポートされています。

この点は、AI開発において極めて重要な転換点です。
Office Scriptsでは、fetch関数を使って外部の機械学習API（例えばAzure Cognitive ServicesやOpenAIのエンドポイント）を直接呼び出せるため、VBAのようにCOM経由でPythonを起動するような迂回策が不要になります。
また、TypeScriptの型システムにより、大規模なスクリプトでも保守性が向上し、非同期処理にも標準対応しています。

ただし、現時点でOffice ScriptsがVBAを完全に置き換えるには、以下のハードルが残されています。

  • ローカルファイルへのアクセス制限：Office Scriptsはクラウドストレージ（OneDriveやSharePoint）上のファイルを前提としており、ローカルドライブのファイルを直接操作することはできません
  • アドインモデルの変更：従来のVBAマクロが「ブックに埋め込まれる」のに対し、Office Scriptsは「別途アップロードして管理する」運用が求められます
  • 実行環境の依存性：Excelデスクトップアプリでも実行可能になったとはいえ、機能の全容はWeb版とデスクトップ版で差異が残っています

とはいえ、長期的にはMicrosoftがVBAに新機能を追加することはほぼないと見てよいでしょう。
新規プロジェクトでOfficeオートメーションを検討するなら、VBAではなくOffice Scriptsを第一候補にすべき時代が来ています。
ただし、既存のVBA資産が膨大にある企業では、移行コストが障壁となり、少なくともあと5〜10年はVBAが現役であり続けるとも予想されます。

WebAssemblyがLuaの組み込み領域に与える影響

一方、Luaが得意としてきた「組み込みスクリプティング」の領域にも、新たな競争相手が現れています。
それがWebAssembly（WASM） です。
WASMは、C/C++、Rust、Goなどの言語で書かれたコードを、安全かつ高速に実行するためのバイナリ形式であり、元々はWebブラウザ向けに開発されましたが、現在ではサーバーサイドやエッジデバイスでの利用も急速に拡大しています。

WASMの組み込み分野での優位性は、以下の点に集約されます。

  • 言語非依存：WASMは実行環境であり、特定のスクリプト言語に縛られません。C++やRustで書かれた推論エンジンをWASMバイナリにコンパイルすれば、それをホストアプリケーションから呼び出せます
  • サンドボックスセキュリティ：WASMの実行モデルは明示的に許可されたリソース以外にアクセスできず、組み込みデバイスでの不正動作リスクを低減します
  • サイズと速度の両立：WASMバイナリは比較的小さく、かつネイティブに近い速度で動作します。Luaインタプリタを経由するよりもオーバーヘッドが小さいケースがあります

これらの特性は、Luaがこれまで提供してきた「軽量で埋め込みやすいスクリプト環境」と直接競合します。
特に、TensorFlow LiteやONNX RuntimeがWASM向けにビルドされるようになれば、Luaを介さずに直接推論エンジンを呼び出すことが可能になり、Luaの存在意義は相対的に低下するでしょう。

それでもLuaが生き残るシナリオ

ただし、Luaが完全に駆逐されるとは考えにくい点もいくつかあります。
第一に、WASMのランタイム自体がまだ組み込み環境に広く普及していないという現実です。
WASI（WebAssembly System Interface）は進化していますが、デバイスドライバやGPIO制御といったハードウェア固有の操作は、依然としてCやLuaの方がネイティブに近い形で実装できます。

第二に、Luaのスクリプト記述の容易さは捨てがたい魅力です。
WASMを利用するには、C++やRustでコンパイル済みバイナリを用意し、さらにその呼び出しインターフェースを設計する必要があります。
一方、Luaはテキストスクリプトをその場で書き換えて実行できるため、プロトタイピングや現場でのチューニングにおいて大きなアドバンテージを持ちます。

総合的な将来予測

以上を踏まえ、VBAとLuaの将来性を以下のようにまとめます。

  • VBAは徐々にOffice Scriptsに取って代わられるが、既存システムの保守用途では今後10年程度生き残る。AI分野では、Office ScriptsとクラウドAPIの組み合わせが主流になる
  • LuaはWASMの普及圧力を受けつつも、ハードウェア密着型の現場や、ゲーム開発のような「記述性と即時実行性」が重視される領域では存続する。AI推論のバインド言語としても、Cバインディングの柔軟さゆえに完全には駆逐されない

最終的には、「言語そのもの」ではなく「その言語が接続するエコシステム」 が選択の決め手になるでしょう。
Office ScriptsはMicrosoftのクラウドエコシステム、LuaはC/C++エコシステムとハードウェアベンダの独自拡張、それぞれが異なるネットワーク効果を持っています。
あなたがどのエコシステムに投資するか――それがVBAとLua、そして次世代技術を見極める本当の課題なのです。

結論――プロジェクトのライフサイクルと運用環境で選ぶべき言語の基準

VBAとLuaの選択基準をフローチャート形式でまとめた決定木の図解

ここまでVBAとLuaの特性を、速度、連携、可視化、導入コスト、将来性に至るまで多角的に比較してきました。
最終的に、どちらの言語が「優れている」という単純な答えは存在しません。
なぜなら、両言語がターゲットとする運用環境とユーザー層が根本的に異なるからです。
本項では、プロジェクトのライフサイクルと運用環境という二つの観点から、実際の判断基準を体系化します。

判断基準1：データの流れとユーザーインターフェースを定義する

最初に問うべきは、「推論結果を誰が、どのような形で受け取るのか」という点です。
これは単なる表示形式の問題ではなく、プロジェクトの成功を左右するユーザー体験の中核です。

  • 推論結果をExcelのグラフや条件付き書式で直感的に確認したい業務ユーザーが主な利用者なら、VBAを選ぶべきです。VBAはOfficeオートメーションのネイティブ言語であり、シート上のセルや図形オブジェクトを直接操作できます。この場合、推論速度よりも「見やすさ」と「編集のしやすさ」が優先されます
  • 推論結果をシリアル通信やGPIO、MQTTブローカなど機械的なアクションに変換する必要があるなら、Luaが適しています。LuaはC/C++ホストへの埋め込みを前提としており、ハードウェア抽象化レイヤとの親和性が高いからです

この基準で判断すれば、多くのビジネスシステムではVBAが、産業用IoTやロボティクスではLuaが自然に選ばれるでしょう。

判断基準2：モデルの更新頻度と運用ライフサイクルを評価する

次に考慮すべきは、学習済みモデルをどの程度の頻度で更新するかです。
AIモデルは静的なものではなく、新しいデータが蓄積されるたびに再学習やファインチューニングが必要になるのが一般的です。

  • モデル更新が週次または月次単位で、かつ更新作業をIT部門が担当できるなら、VBAでも運用は可能です。JSONやCSVで係数を差し替えるだけの仕組みを構築すれば、業務部門はExcelの操作だけで最新モデルを利用できます
  • モデル更新が日次またはリアルタイムに近い頻度で発生する場合、LuaとCバインディングの組み合わせが有利です。ONNX Runtimeが読み込むモデルファイルを差し替えるだけの運用は比較的シンプルで、再起動なしで新しい重みを反映することも技術的には可能です

ただし、ここで忘れてはならないのは、両言語とも学習フェーズは外部環境に委ねるという大前提です。
モデル更新の手間は、結局のところPythonやC++による再学習パイプラインの整備度合いに依存するため、VBAとLuaの差はそれほど大きくありません。

判断基準3：既存システムとの依存関係とリソース制約を洗い出す

三番目の基準は、実行環境がすでに決まっているかどうかです。
これが最も現実的な制約条件であることも多いでしょう。

  • 対象環境がWindows + Microsoft Officeで固定されており、外部ソフトウェアのインストールが制限されているなら、VBA以外の選択肢は実質的にありません。導入コストの項目で述べた「ゼロインストール」のアドバンテージは、セキュリティポリシーが厳しい企業では決定的な差になります
  • 対象環境がLinuxベースの組み込みボードやゲームエンジン（UnityやUnreal） であるなら、Luaが標準または容易に導入できます。特に、メモリ制限が厳しい環境では、LuaJITのフットプリントの小ささが大きな安心材料となります

加えて、既存のVBAマクロ資産がすでに大量にある場合は、新たにLuaを導入するよりもVBAを拡張する方が現実的です。
逆に、ハードウェア制御のCコードがすでに存在する場合は、Luaをその上に載せることで高い生産性を得られます。

判断基準4：保守期間とスキルセットを考慮する

最後に、プロジェクトの予想される保守期間と、チームが保有するスキルセットを評価します。

  • VBAは、Excelを日常的に使う業務部門のスタッフでもある程度の読解・修正が可能です。ただし、大規模なVBAコードベースはスパゲッティ化しやすく、設計パターンを徹底しないと保守地獄に陥ります
  • Luaは、ゲーム業界や組み込み業界では知られた言語ですが、一般的な業務システムエンジニアには馴染みが薄いのが現状です。もしチームにLua経験者がいない場合、学習コストと品質担保の難しさを真剣に見積もる必要があります

総合判断フローチャート

以上の四つの基準を統合すると、以下のような判断軸が導かれます。

  • 「Excelが中心」かつ「更新頻度が低く」「Windows制約が強い」 → VBA
  • 「ハードウェア制御が必須」かつ「応答速度が重要」 → Lua
  • 「将来のクラウド連携を見越す」 → Office ScriptsやWASMも含めた再検討を推奨
  • 「学習も含めてすべてPythonで統一したい」 → そもそもVBA/Luaを選ばない

結局のところ、言語選択は技術的な優劣ではなく、運用環境と人的リソースの最適化問題です。
本稿で示した比較表とケーススタディを参考に、あなたのプロジェクトに最もフィットする選択肢を見極めていただければ幸いです。
何かご不明な点や追加の検討要素があれば、ぜひコメントやフィードバックでお聞かせください。

コメント

タイトルとURLをコピーしました