はじめに
一昨日の夜に公開した前作の記事が、ありがたいことに大きな反響をいただいています。
自作の環境「秀コンボ」で起きた通信沈黙事件と、Claude自身が埋め込んだ脆弱な決め打ちをGeminiが暴いて修正した顛末をまとめた記事です。
管理画面を開いてみると、閲覧数は 3,752 views。これで3記事連続で2,000回を超えたことになります。
「結構読まれているな」と驚き、手元のExcelをいじりながら感謝していました。
そんな中、昨日、YouTubeである解説動画が上がっているのを見かけました。
タイトルは『VBAだけしかできないエンジニアは存在するのか』という趣旨のものです。
まだ公開されて1日も経っていない動画でした。ですが、再生数もさることながら、何よりコメント欄の熱気に目を奪われました。現場のエンジニアや事務職の方々から、切実で生々しい声がずらりと書き込まれていたのです。
「勝手にプログラミング環境を構築する許可も得られないので、結局VBAしかない」
「海の向こう（最新技術）に憧れる人のように、今日もVBAを書きながら外の世界に思いを馳せている」
「VBA専業の需要はあるはず。負の遺産のスパゲッティコードが心臓部にあって、誰も仕様書を作れないのだから」
画面をスクロールしながら、私は「世間では時代遅れと言われがちだけれど、現場の最前線でVBAと真剣に向き合っている人たちが、今もこんなにたくさんいるんだな」と驚き、どこか心強いような気持ちになりました。
私自身の環境が、職場で使えるツールがExcelしかないというものなので、Excelなんて古いと批判されようとそれしかないわけなのです。
動画の解説やコメント欄の中で、繰り返し語られている「諦め」の言葉も目に留まりました。
「VBAには構造的な檻がある。Officeファイルの内側でしか動かないから、外の世界には出られない」
「AIとVBAは相性が悪い。実行環境がオフィスのアプリだから、AI自身がセルフでデバッグできないのがキツい」
「業務とコードが密結合しているから、AIにリファクタリングさせると新しいカオスが生まれる」
そうした言葉を眺めながら、私は自宅のパソコンで動いている自分の開発環境を振り返りました。
そして、ふと思ったのです。
「あれ……？ これ、ひょっとして私の手元では、すでに出来ているんじゃないだろうか？」
世間が「できない」「無理だ」と諦めている壁を、私は自宅のパソコンで、泥臭い工夫を重ねる中でとっくに通り過ぎていたのではないか。
今夜は、動画とコメント欄の熱い議論に背中を押されながら、手元の実機で動いている「もう一つの現実」について書いてみようと思います。
TL;DR
- 昨日のYouTube動画に寄せられた熱気: 『VBAしかできないエンジニアはいるか』という動画のコメント欄に、環境構築を許されない現場の切実な声が溢れており、今もVBAが現場の心臓部を支えている現実を再確認しました。
- 動画の「外に出られない」という誤解: VBAは檻に閉じ込められてなどいません。GAS（Google Apps Script）の中継器を挟めばGoogle Workspaceと繋がり、自作のExcelコンボではローカルの最新AI（Claude / Gemini）と直接パイプを繋いで会話しています。
- コメント欄の「AIはセルフデバッグできない」という諦め: AIがExcelの実行環境を直接触れないのは、道具を用意していないからです。PythonのMCPサーバー（Excelマネージャー）で直接COM（Component Object Model）を握らせることで、AI自身が全体コンパイルを通し、テストを回して自己修復するループはすでに手元で毎日動いています。
-
「リファクタリングでカオスになる」を防ぐ二重防壁: コード全体をAIに丸投げせず、指示された行だけを0.09秒で置換する「ピンポイント修正（
patch-procedure）」と、全体コンパイル＋テスト全問合格を義務づけた「関所テスト」で安全性を完全に担保しています。 -
仕様書がない問題は自動化できる:
docs（取説生成）、flow（Mermaid流れ図）、checkup（健康診断）、そしてマクロの頭の数行から手順書を自動組み立てる仕組みにより、ブラックボックスは構造的に消滅させられます。 - なぜCopilotはVBAを直接編集しないのか: VBAは外に出られないどころか、Win32 APIやファイルシステムを叩ける「強大すぎるローカル権限」を持っているため、クラウドのCopilotでは安全管理が難しくて触れないのだ、というのが現場からの見立てです。
- そして今、私が当たっている「本当の壁」: 世間が「できない」と言っているものは手元で越えられたかもしれない。だからこそ、私は今「数学の難問すら解くAIの知能を、どうやって自律した『棚ビルダー』へ昇華させるか」という、その先にある本当の壁と格闘しています。
動画とコメント欄で見かけた「3つの諦め」
昨日公開された動画は、1993年にExcel 5.0にVBAが搭載されて以来の歴史を振り返り、「VBAは最初からエンジニアではない人（経理や営業）のために作られた」「マクロの記録と環境構築不要という、世界で一番低い入り口だった」という本質を突いた、大変見応えのある内容でした。
ただ、その動画の展開やコメント欄の議論を読んでいると、いくつかの「決定的な諦め」が共通の前提として語られていました。主に次の3点です。
-
「VBAは構造的な檻があり、外の世界へ出られない」
Officeファイルの内側でしか動かず、単体アプリもWebサービスも作れない。だから基幹システムやWebと繋ぐためには、SQLやPowerShellなど外の技術へ押し出されるしかない、という見立てです。 -
「AIはExcelの実行環境を直接触れないから、セルフデバッグができず相性が悪い」
コメント欄で強く共感を集めていた意見です。AIにコードを書かせることはできても、実行環境がオフィスのデスクトップアプリであるため、書いた後のデバッグをAI自身が自律的に行えない。人間がコピペしてエラーを伝えないといけないから、実用には耐えないという諦めです。 -
「業務とコードが密結合しているから、AIにリファクタリングさせると新しいカオスが生まれる」
現場のマクロは継ぎ接ぎだらけのスパゲッティコードであり、仕様書もない。そこにAIの手を突っ込ませると、余計なところまで書き換えてしまい、業務がクラッシュするという恐怖です。
どれも、現場で何年もVBAと格闘してきた人間なら、「その通りだな」と深く頷いてしまうリアルな悩みばかりでした。
長年オフィスの片隅で孤独にマクロを書いてきた私自身、まったく同じ壁にぶつかってきたからです。
ですが、画面を眺めながら、私はふと我に返りました。
「ちょっと待てよ。この3つ、私の手元のパソコンでは、いつの間にか全部動いているんじゃないか？」
1. 「外の世界に出られない」── GAS中継器とExcelコンボ
動画では「VBAの世界はExcelやAccessのファイルの内側で完結している。檻の中では最強だが、檻の外には出られない」と語られていました。
ですが、現場で泥臭く手を動かしてきた実感から申し上げますと、VBAは決して檻の中に閉じ込められてなどいません。
例えば、私の手元では**「GAS（Google Apps Script）の中継器」**が日常的に稼働しています。
VBAの標準機能であるHTTP通信（MSXML2.ServerXMLHTTP）を使って、Googleドライブ上に置いたシンプルなGASのWeb APIへJSONを投げます。たったこれだけの土管を通すだけで、ExcelのシートとGoogle Workspace（スプレッドシート、Gmail、ドライブのファイル群）は、何の問題もなくリアルタイムで双方向に繋がります。
さらに、自作の開発環境である「秀コンボ」では、ExcelのUserFormからローカルのコマンドラインを叩き、最新のAI（Claude CLIやGemini）と直接パイプを繋いでいます。
画面のボタンを押せば、裏で動くAIにシートの構造が渡り、わずか数秒で結果が返ってくる。
基幹システムのデータを引っ張るのも、クラウドのサービスと会話するのも、AIの巨大な知能を呼び出すのも、VBAの手元から外へ向けて「土管」を一本伸ばしてやるだけで事足ります。
外へ出られないのではなく、外へ繋ぐための小さな中継器をどう組むかという工夫の問題だったのです。
2. 「AIはセルフデバッグできない」── 直接COMを握る道具の存在
コメント欄で最も深く頷かされていたのが、「AIとVBAは相性が悪い。実行環境がオフィスのアプリだから、書いた後のデバッグをAIがセルフでできないのがキツい」という指摘でした。
この意見は、現在の一般的なAIの使い方──つまりブラウザのチャット欄に「VBAを書いて」と頼み、出力されたコードを人間がAlt+F11でVBEを開いて貼り付ける──という運用をしている限り、100%正しい指摘です。
人間がAIとExcelの間を往復する「コピペの土管」になっている状態では、AIは自分の書いたコードが動いたのか、文法エラーで止まったのかを知る術がありません。
ですが、それは「AIとVBAの相性が悪い」からではありません。
AI自身に、Excelの実行環境を直接触らせる道具（インターフェース）を渡していないからです。
私の手元では、Pythonで自作したMCPサーバー**「Excelマネージャー（vba_manager.py）」**がその役割を担っています。
この道具の正体は、Windowsの COM（Component Object Model） を通じて、AIが外部からExcelのプロセスそのものを直接握り込む仕組みです。
AIがCOMを直接操作できるため、私の環境では以下のことが「人間の手を一切介さずに」自動で回ります。
-
コードの取得と注入:
getでプロシージャを読み出し、patch-procedureで修正行だけを直接書き戻す。 - 全体コンパイルの自律実行: VBEの「デバッグ > VBAProjectのコンパイル」（CommandBars Id 578）をAI自身が外から押し、構文エラーや未定義の変数を検知する。
-
テストの一括実行: テスト用のSubプロシージャ（
test_*）を自動実行し、戻り値やエラーコードをAIが直接受け取る。 - エラー行の名指しと修正: コンパイルやテストが落ちた場合、エラーメッセージと該当行番号をAIが自分で読み取り、「ここが間違っていた」と自律的に直してもう一度テストを回す。
前作の記事で書いた事件が、まさにその生きた証拠でした。
Claudeが埋め込んだ脆弱な決め打ちコードによって通信が止まったとき、ログを調べ、VBEのコードを読み、InStr関数に書き直し、関所テスト67本を全問合格させ、GitHubのpytest 760本まで通して完了させたのは、相棒であるGeminiでした。私自身はコードを1行も修正していません。
「AIはExcelをセルフデバッグできない」のではありません。
直接COMを叩ける道具を用意してやりさえすれば、AIはコンパイルからテスト、エラー修復までを完璧にセルフで完走できるのです。
3. 「リファクタリングでカオスになる」を防ぐ二重防壁
「業務とコードが密結合しているから、AIにリファクタリングさせると新しいカオス（バグ）が生まれる」という指摘も、現場の切実な実感です。
AIに「このマクロを綺麗にして」と丸投げすると、AIは良かれと思って変数名を勝手に変えたり、動いていた既存のロジックをごっそり削ったりして、かえって動かなくしてしまうことがよくあります。
このカオスを防ぐために、私の手元では**「二重の防壁」**を敷いています。
防壁1：ピンポイント修正（patch-procedure）
プロシージャ全体をごっそり書き直させることを原則として禁じています。
AIには「直すべき行の置換前」と「置換後」だけを指定させ、わずか 0.09秒 でピンポイントに対象行だけを差し替える専用コマンド（patch-procedure）を使わせています。周辺の無関係なコードや、過去の職人が残した絶妙なロジックをAIが勝手に触る余地を物理的に奪うためです。
防壁2：関所テスト（全体コンパイル ＋ テストSub全件合格）
コードを修正したあと、本体のブックには直接触れず、メモリ上でコピーを開いて「全体コンパイル」と「テストSub」を一括で回す**「関所（gate）」**という仕組みを通しています。
テストが1本でも落ちたり、コンパイルが通らなければ、修正は即座に破棄されます。合格のハンコ（PASS）が出たものだけが、初めて本体に反映されます。
さらに、マクロを触る直前には必ず自動バックアップが取られ、ボタン一つで元の状態へ戻せる導線（restore）も用意しています。
「AIがコードを壊す」というのは、AIの能力の問題というよりも、AIにコードを触らせる際の安全管理（ハーネスとゲート）の設計問題だったのです。
4. 仕様書がない問題は、AI自身に作らせればいい
コメント欄には「現場のマクロは仕様書もない継ぎ接ぎだらけ。仕様書作成やVBAのままリファクタリングする需要はあるはずなのに」という声もありました。
この問題に対しても、手元の道具には最初から解答が組み込まれています。
-
docs（取説の自動生成）
ブック全体の構成、シートの役割、含まれるマクロ一覧と概要を、コマンド一発でMarkdownの仕様書（_last_docs.md）として書き出します。 -
flow（マクロの流れ図 / Mermaid）
解読不能なスパゲッティコードを解析し、条件分岐やループの構造をMermaidチャートの流れ図として自動生成します。コードを読まなくても、処理の流れが一目で図解されます。 -
checkup（健康診断 / カルテ）
壊れた参照設定（MISSING）や、存在しないマクロを呼んでいる未解決呼び出し、長すぎるプロシージャを自動検知し、修理の履歴をカルテとして蓄積します。 -
棚の手順書を組み立てる仕組み
マクロの頭に数行のコメント（依頼の語・扱う対象・ゴール）を書いておくだけで、画面を開くたびに日本語の手順書（いつ使うか・ゴール・手順）をVBA自身が自動で組み立てます。
誰かが書いたマクロがブラックボックス化するのは、「仕様書を別の場所に手で書くから」です。
マクロ自身の中に仕様を持たせ、AIがいつでもそれを読み解いて解説してくれる環境を作れば、「属人化」という問題そのものが構造的に成り立たなくなります。
なぜCopilotはVBAを直接編集しないのか ── 現場からの見立て
ここで、動画が語っていた「VBAは構造的な檻があり、外の世界へ出られない」という命題に戻ります。
私は、この見立ては実は完全に真逆ではないかと考えています。
「VBAは、檻の外に出られすぎてしまうからこそ、MicrosoftはCopilotにVBAの直接編集をつけられないのではないか」
世間一般では、「MicrosoftはVBAを捨てようとしているから」「古い技術だから」と解釈されがちです。
しかし、アーキテクチャの視点から見れば理由はもっと明白です。
VBAは、Officeの中に閉じ込められているどころか、
- Win32 APIを直接叩くことができる
-
WScript.Shellや FileSystemObject でローカルOSのファイルを自在に読み書き・削除できる - 外部のプロセスをバックグラウンドで起動できる
つまり、手元のWindowsマシンに対して、極めて強大なローカル権限を持っています。
もしクラウド上で動くMicrosoft Copilotが、ユーザーのローカル環境にあるVBAを直接生成し、直接コンパイルして実行できる権限を持ったらどうなるでしょうか。
AIのわずかな誤認やプロンプトインジェクションによって、ローカルPCのファイルが書き換わったり、外部の危険なスクリプトが叩かれたりするリスクを、クラウドサービスとして保証することは極めて困難です。
だからこそMicrosoftは、手元のマシンに一切の副作用を及ぼさない、「クラウド上の安全な鳥籠」として Python in Excel を用意せざるを得なかったのではないか。
VBAは外に出られない弱い言語なのではありません。
ローカルの全権を握って外に出られすぎる強大な刃だからこそ、本家のクラウドAIですら手綱を握るのを躊躇しているのです。
そして、ローカル環境で自作の安全網（MCPサーバーと関所テスト）を構築した個人の開発者だからこそ、その強大な刃をAIに直接握らせることができている──というのが、私の手元から見えるリアルな景色です。
そして今、私が直面している「本当の壁」
外の世界とも繋がり、AIに直接COMを触らせてセルフデバッグを回し、仕様書まで自動で組み立てられるようになった。
世間の解説動画やコメント欄で「できない」「無理だ」と議論されている壁は、毎晩自宅のパソコンで泥臭く工夫を重ねてきた結果、いつの間にか手元で動くようになっていました。
では、これで私の道具は完成したのでしょうか？
正直に書くと、いま私は立ち止まっています。
「まあまあ出来ている」という手応えはあるのに、長年VBAを書いてきた私の皮膚感覚が、心のどこかで**「まだ何かが足りない」**と囁きかけてくるのです。
昨今のAIの進化を見ていると、国際数学オリンピック級の難問を解いたという驚くべきニュースが飛び込んできます。世界の最先端で、AIの知能はかつてない高みへと駆け上がっています。
その凄まじい知能を見つめていると、痛切に思うのです。
「数学の難問すら解く知能があるのなら、Excelマクロの世界だって、もっと異次元に質の高い、想像もつかないようなことができるはずではないか」
いま手元で動いている「指示された数式を入れる」「表をエグゼクティブデザインに整える」「ピボットを作る」といった作業は、AIが持つ途方もないポテンシャルから見れば、まだほんの数パーセントの入り口に過ぎないのではないか。
AIの能力が足りないのではありません。
その巨大な知能を、現場の実務という場に100%解放するための「枠組み（システム）」が、まだ私の手元で追いついていないのです。
先日、Geminiと深夜に対話する中で、一つの終着点が見えてきました。
整理された棚パーツを選んで並べるだけで業務レシピが組み上がり、足りないパーツはAIが裏で自動テストを回して棚に追加してくれる**「棚ビルダー（Tana Builder）」**という完成形の構想です。
しかし、私はそこで足を止めました。
表面のUI（ビルダー）を作る前に、解かなければならない「裏側のシステム設計の宿題」が、まだ手前に山積みになっているからです。
どんな表が来ても壊れない棚マクロのインターフェース、複数の棚を安全にバトンタッチさせる連鎖の仕組み、失敗したときに一瞬で巻き戻せるセーフティネット。
世間が議論している「できない」という壁を越えたその先で、私は今、この「次の壁」の前に立って腕を組んでいます。
事実と見立ての仕分け
本稿における「客観的な事実」と、私自身の「見立て（主観）」を整理しておきます。
事実
- YouTube動画とコメントの反響: 昨日公開された動画『VBAだけしかできないエンジニアは存在するのか』において、現場の技術者や事務職から多数の切実なコメントが寄せられている。
- 手元の実装とテスト実績: 自作のExcelマネージャー（MCPサーバー）により、AIがCOMを直接操作して全体コンパイル（Id 578）およびテストSubを実行するセルフデバッグ環境が実在し、関所テスト67本、pytest 760本をパスしている。
-
外部連携と可視化の実装: GAS中継器によるGoogle Workspace連携、
patch-procedure（ピンポイント行置換）、docs（取説生成）、flow（Mermaid流れ図）が手元の環境で稼働している。
見立て
- VBAの自由度に関する解釈: VBAは「檻の外に出られない」のではなく、Win32 APIやファイル操作など「外に出られすぎる強大な権限」を持っているため、クラウドのCopilotが直接編集を避けざるを得ないのではないかという考察。
- 「まだ足りない」という違和感: 現在のマクロ撃ちや棚撃ちは実用域にあるが、フロンティアAIの知能から見れば、まだその潜在能力のごく一部しか引き出せていないという直感。
正直な線引き／動く条件
本稿で触れたツール群の動作条件と現在の限界についても、正直に明記しておきます。
- 動作環境: Windows上のデスクトップ版Excel（Microsoft 365推奨）と、Python（pywin32）環境が必要です。
- 設定要件: 外部からVBEを操作するため、Excelの「VBAプロジェクト オブジェクト モデルへのアクセスを信頼する（VBOM）」の有効化が必須となります。
-
公開状況: コアとなるMCPサーバー
vba_manager.pyはGitHub（shu-excel-manager）にて公開していますが、UIを含むアドイン（秀コンボ）やAI連携機構は、現在も自宅環境での個人検証と改修を続けている段階です。 - 安全性の限界: 非破壊ハーネスやバックアップ機構を備えていますが、外部ファイルへの直接書き込みや通信など、ブックの外側に対する副作用を持つマクロの自動実行は完全には遮断できません。
おわりに
昨日の動画のコメント欄に書き込まれていた、ある方の言葉が、今も深く胸に残っています。
「海の向こうに憧れる人のように、今日もVBAを書きながら『外の世界は今そんなことになっているのか』と思いを馳せています」
勝手な環境構築も許されず、新しいツールの導入も許されないオフィスの片隅で、それでも日々の業務を少しでも前に進めるために、孤独にVBAのキーボードを叩き続けている人たちがいます。
世間は「VBAなんて時代遅れだ」「属人化の極みだ」「エンジニアとは呼ばない」と簡単に切り捨てます。
けれど、その制限だらけの環境の中で、現場の人間が泥臭く工夫を重ねてきたからこそ、日本の業務の心臓部は今日も止まらずに動いているのです。
そして、最新のAIという知能と、COMを直接握る道具を手に入れたとき、その「見捨てられたはずの言語」は、世間のエンジニアが想像もしていないような力強い手足へと生まれ変わりました。
私はまだ、この先に見える「棚ビルダー」の完成を諦めるつもりはありません。
全国のオフィスの片隅で、今日も静かにVBAと向き合っている仲間たちの声に背中を押されながら、私は今夜も自宅のパソコンで、この次の壁の向こう側を目指して設計図を引き直しています。