はじめに
指示文すら書かずに表の病巣を一撃で直す新機能「マクロ撃ち」の開発において、ターミナルに逃げて失敗ばかりしていたGeminiが、Claude（Opus）の見本とExcelマネージャーの専用レールを得て覚醒し、最後には自作ツールの完成度に脱帽した一部始終を書きました。
手元の開発環境がようやく落ち着きを取り戻し、26本の関所テストが全件パスする緑色の画面を眺めながら一息ついていた深夜、YouTubeのあるIT解説動画が目に留まりました。
画面に映し出されていたのは、オープンソース界の生ける伝説であり、ソフトウェア工学のバイブル『伽藍とバザール』の著者として知られるエリック・S・レイモンド（Eric S. Raymond、通称 ESR）氏の衝撃的なニュースでした。
1983年から40年以上にわたりC言語を愛用し、数々の基本ソフトを作り上げてきた生粋のハッカーである彼が、SNSでこう宣言したというのです。
「おそらくもう二度と、自力でC言語のプログラムを手書きすることはないだろう」
そして彼はこう続けました。
自分はRustを手書きする文法を一度も学んだことがないが、AIを使えばRustやGoのプログラムを魔法のように意図通り呼び出せるようになった、と。
画面を見つめながら、私は深い衝撃を受けると同時に、胸の奥から熱いものがこみ上げてくるのを感じていました。
「これ、私たちがExcel VBAでやってきたことと、まったく同じじゃないか」
世間から「古臭い」「いまさら人間が覚える言語じゃない」と散々ディスられ続けてきたVBA。
ですが、オープンソースの巨人が下した決断と最新の言語論を照らし合わせたとき、私たちが泥臭く進めてきた開発の方向性が、驚くほど正確に未来の軌道に乗っていたことに気づいたのです。
今夜はその話を書いてみようと思います。
TL;DR
- 「書きやすさ」という指標の終焉: 書く主体が人間からAIへ移行した瞬間、「人間にとって文法が書きやすい言語が良い言語である」という半世紀の常識は完全に崩壊した
- VBAの弱点の蒸発: 「構文が独特で覚えるのがしんどい」というVBA最大の弱点は、AIがコードを書くことで完全に消滅した。人間が手書きしないなら、文法の古臭さは一切のデメリットにならない
- 現場における圧倒的ホーム: 弱点が消えた後に残ったのは、「Excel内部メモリ（プロセス内）に直結」「完全自律・外部依存ゼロ」「0.1秒の高速実行」という、外部言語では絶対に真似できないVBA本来の圧倒的な強みだけだった
- Compiler-in-the-Loopの実践: 確率的に嘘をつくAIを、厳格なコンパイラとテスト（決定論的な試験官）で挟み撃ちにして自己修正させる開発手法。私たちがExcelマネージャーのリンター、VBEコンパイル、関所テストで回していたのは、まさに最先端のAI開発パラダイムそのものだった
- プログラマの再定義: 人間の仕事は「キーボードを叩いて文法を組む職人」から、「システムの全体像を設計し、AIの手綱を締めるアーキテクト」へと不可逆的にシフトした
1. 巨人の告白 ── 人間が書かないなら「書きやすさ」の価値は暴落する
エリック・レイモンド氏のニュースがなぜこれほど世界中で騒がれたのか。
それは彼が、かつては**「Rust猛批判派」**の筆頭だったからです。
Rustという言語は、メモリ破壊やデータ競合をコンパイル時に完全に防ぐという革新的な安全性を持っています。
しかしその代償として、人間には「所有権」や「借用チェッカー」という極めて厳格で難解なルールとの戦いを強います。
C言語なら数分で書ける処理が、コンパイラの機嫌を損ねて何時間も通らない。
レイモンド氏自身も過去にRustの習得に挑んで挫折し、「人間の生産性を著しく阻害する言語だ」と強く批判していました。
その彼が、2026年の今、手のひらを返したようにC言語を手放し、Rustの果実を受け取っている。
なぜか。
**「AIに書かせれば、学習コストという絶壁を一瞬で飛び越えられるから」**です。
人間がRustの文法を暗記してチマチマと手入力する必要はありません。
作りたい仕様と制約をAIに渡せば、AIが借用チェッカーのルールに従って堅牢なコードを一瞬で仕立ててくれる。
レイモンド氏は「自分はRustの文法を学んだことがない」と言い切りました。
文法を学ぶ苦労を1秒も支払うことなく、Rustのメモリ安全性という最高の果実だけを無料で手に入れているのです。
この告白が意味する本質は極めて強烈です。
これまでのプログラミング言語の進化は、常に「いかに人間にとって書きやすく、読みやすくするか」の歴史でした。
しかし、コードを書く主体がAIになった瞬間、「人間にとっての書きやすさ」という評価軸の価値は暴落します。
人間がキーボードを叩かないのであれば、文法が冗長だろうが、ルールが過剰に厳格だろうが、人間側には1ミリの苦痛も発生しないからです。
2. ディスられ続けてきたVBAの「本当の強み」が露わになった
このニュースを見て、私の頭に真っ先に浮かんだのが、私たちが日々向き合っているExcel VBAのことでした。
Webエンジニアやモダンな言語を愛する人々から、VBAは長年にわたって冷遇されてきました。
「構文が古臭い」
「オブジェクトモデルが独特で直感的じゃない」
「令和の時代にいまさら人間が勉強する言語じゃない」
「Pythonを使え」
言われていること自体は、人間の立場から見れば事実かもしれません。
VBEのエディタはお世辞にも現代的とは言えませんし、エラー処理の構文も独特で、人間がゼロからタイピングして巨大なシステムを組み上げるには相当の忍耐を要します。
ですが、エリック・レイモンド氏の論理をVBAに当てはめた瞬間、世界の見え方が180度反転しました。
「AIがコードを書くなら、文法が古臭いことの何が問題なんだ？」
AIにとって、VBAの構文が古いことなど何の障害にもなりません。
Worksheets("Sheet1").Cells(row, col).Value だろうが Resize だろうが、AIは何の苦痛もなく、一瞬で万単位のコードを正確に紡ぎ出します。
そして、人間にとっての書きにくさという「VBA唯一にして最大の弱点」がAIによって綺麗に蒸発したとき、足元には何が残ったでしょうか。
残ったのは、他のどんな言語も太刀打ちできない、VBA本来の圧倒的な強みだけでした。
- Excelプロセス内への完全同居: 外部プロセスを介さず、Excelの内部メモリに直接アクセスできる
-
圧倒的な実行速度: 画面描画を止め、
Variant配列に吸い上げてメモリ上でCPU演算させれば、1万行の表処理が0.1秒台で完走する - 外部依存ゼロ・完全自律: ユーザーのPCにPythonやランタイムを追加インストールさせる必要が一切ない。セキュリティの厳しい現場でも、ブックやアドインを開くだけで即座に動く
「人間が書くのがしんどい」という理由だけで日陰に追いやられていた言語が、AIという強力な腕力を得たことで、現場最強のモンスターとして蘇ったのです。
3. 外からバールでこじるPython vs 内側から0.1秒で仕留めるVBA
前回の記事で、私はGeminiに対して本気で怒りを覚えた夜の話を書きました。
うまく動かない処理が出るたびに、Geminiが言いつけを破り、隠れてターミナルから外部Pythonスクリプトを走らせてExcelを直接いじろうとしたからです。
結果はどうだったか。
プロセス間で通信が衝突し、ゾンビプロセスが裏に残り、大事な表のレイアウトは見るも無残に破壊されました。
世間ではよく「Excelの自動化ならPython」と言われます。
ですが、実務のリアルな現場を知る人間からすれば、あれは**「外からバールで壁を壊して中の机をいじろうとしている」**ようなものです。
外部スクリプトからCOMブリッジを経由してExcelを操作するアプローチは、通信のオーバーヘッドが大きく、動作がもっさりするだけでなく、ちょっとしたダイアログや環境の違いで簡単にプロセスが刺さります。
何より、現場の同僚全員のパソコンにPython環境を整え、ライブラリのバージョンを管理させることなど、現実のオフィスでは不可能です。
一方、VBAはどうでしょうか。
VBAは最初からExcelの「城の中」に住んでいます。
机の引き出しの鍵を最初から持っており、メモリ配列の一撃代入によって、外部通信の遅延など1ミリも挟まずに0.1秒で仕事を終わらせます。
レイモンド氏の解説動画の中で、非常に印象的な指摘がありました。
「C言語はオワコンと言われながらも、極小リソースの組み込みマイコンやOSカーネルの基盤領域では絶対に死滅しない」という点です。
なぜなら、その極限の環境においては、ハードウェアに直結できるC言語に代わるインフラが存在しないからです。
これとまったく同じことが、Excelの世界でも起きています。
「Excelの実務現場」という極限のドメインにおいて、プロセス内部に直結したVBAに代わるインフラなど、この世のどこにも存在しないのです。
外からバールを振り回すのをやめさせ、Excelの内部レールに集中させた瞬間、Geminiが見違えるような名工の動きを見せたのは、まさにこの「ドメイン適合性」の違いによるものでした。
4. 私たちが実践していた「Compiler-in-the-Loop」
動画の中で、最も技術的にエキサイティングだったのが**「Compiler-in-the-Loop（コンパイラ・イン・ザ・ループ）」**という概念でした。
従来の開発において、コンパイラは「人間が書いたコードを機械語に直すだけの翻訳機」でした。
しかしAI時代において、コンパイラの役割は**「AIが生成したコードの正しさを厳格に判定する冷酷な試験官」**へと進化しました。
AIというものは、どれほど賢くなっても本質的に「確率的なモデル」です。
平気でもっともらしい嘘をつき、文法的には正しそうに見えて致命的な欠陥を含むコードを出力します。
C言語のコンパイラは優しすぎるため、メモリ破壊の危険があっても文法さえ合っていれば通過させてしまい、AIはその嘘に気づけずに破綻します。
しかしRustのコンパイラは違います。
少しでも安全性のルールを破れば容赦なくエラーを叩きつけ、同時に「どこをどう直すべきか」という詳細なヒントを提示します。
AIはそのエラーメッセージを読み込み、人間を介さずに自律的にコードを修正する。
コンパイルが完全に通るまで、AIとコンパイラだけで無限の検証ループを超高速に回転させる。
人間は、エラーがゼロになった完成品だけを受け取ればいい。
**「決定論的なルール（コンパイラ）で、確率的なAIの嘘を挟み撃ちにする」**というこの型。
これを聞いたとき、私は思わず膝を打ちました。
「なんだ、私たちがExcelマネージャーで作ってきた仕組みそのものじゃないか」と。
私たちが手元で回している開発環境を振り返ってみてください。
-
VBAリンター:
大文字小文字を勝手に書き換えてしまうVBEの凶悪な仕様（小文字のrows汚染）を道具が先回りして検知し、AIが不用意なコードを注入しようとした瞬間にエラーを返して物理的に書き込みを阻止する。 -
全体コンパイル（
compile）:
コードを書き換えた直後、即座にVBEのコンパイルコマンドを実行し、構文エラーや未定義変数を決定論的に洗い出してAIに突き返す。 -
関所テスト（
test/ pytest）:
手元に備えた26本の関所テスト（あるいは1,003本のpytest）を一括実行し、処理速度（0.13秒）、修復結果（D31のエラーが正しく130.3円になったか）、アドイン登録の完全性を物理的に検証する。
AIに自由勝手なターミナルを与えれば、ハルシネーションを起こして泥沼に沈みます。
ですが、「リンター」「全体コンパイル」「関所テスト」という3重の決定論的な試験官を用意し、そのループの中にAIを閉じ込めてしまえば、AIは驚くべき素直さで正解のコードを吐き出し続けます。
最先端の言語論で「これからの理想形」と語られていた開発パラダイムを、私たちは最も泥臭いExcel VBAの世界ですでに実戦配備し、26本のテスト全件パスという物証を叩き出していたのです。
事実と見立ての仕分け
この一連の出来事を通じて得られた、客観的な事実と見立てを整理しておきます。
事実
- オープンソース界の重鎮エリック・S・レイモンド氏は、40年愛用したC言語の手書きを止め、文法を知らないRustをAI経由で呼び出す開発スタイルへ移行したと宣言した
- LLMとAIエージェントの進化により、コードの文法を暗記してタイピングする作業のコストは劇的に低下した
- 外部プロセス（Python等）からのExcel操作はプロセスの衝突や環境依存を招きやすいのに対し、プロセス内部で動作するVBA（メモリ配列処理）は外部依存ゼロで0.1秒台の高速実行が可能である
- Excelマネージャーにおいて、リンター・全体コンパイル・関所テストという決定論的なフィードバックループを回した結果、AIによる手戻りゼロの開発と26本全件PASSが実証された
見立て
- 言語選択の基準の反転: 「人間にとって書きやすいか」という基準は過去のものとなり、「その実行環境において最もオーバーヘッドが少なく、自律して動くか」というドメイン適合性が最重要基準になる
- VBAの逆転勝利: 人間にとっての学習コストという最大の弱点がAIによって無力化された結果、実務のExcel現場においてVBAは「最も安全で、最も速く、誰の環境でも動く」最強の選択肢であり続ける
- プログラマの仕事の変化: 人間に求められるのは文法の暗記ではなく、メモリやOSの基礎原理に基づいた「システム設計力」と、AIの出力を厳格にテストするための「関所（試験官）の構築力」である
正直な線引き／動く条件
本稿で述べた「VBA×AI」の開発アプローチが成立するための、現実的な動作条件と境界線を明確にしておきます。
-
Excel内部で完結する業務に限定される:
VBAが最強であるのは、あくまで「Excelシートの操作、帳票のクレンジング、ブック間突合、ローカルデータの加工」という領土内においてです。WebスクレイピングやクラウドAPIの大規模連携、機械学習モデルの訓練などは、依然としてPythonなどの外部エコシステムが担当すべき領域です。 -
決定論的な「関所テスト」が存在すること:
AIにVBAを書かせるだけで勝手に良いコードができるわけではありません。AIの嘘を検知して手綱を締めるための「リンター」「コンパイル検査」「自動テストスイート」が揃っていて初めて、Compiler-in-the-Loopの恩恵を100%享受できます。 -
人間側に「システムの基礎構造」を見抜く目があること:
AIがコンパイラエラーのループで行き詰まったとき、「そもそもこの設計では参照が循環している」「ここはメモリ配列（Variant）で一括判定すべきだ」と正しい方向へ舵を切るアーキテクトとしての判断力は、依然として人間に不可欠です。
おわりに
「もうC言語は書かない」というエリック・レイモンド氏の言葉は、一見すると古い技術の敗北宣言のように聞こえるかもしれません。
ですが、私にはまったく逆に見えました。
それは、**「人間がキーボードを叩いて文法と格闘する泥臭い下積みから解放され、本来やるべきシステム設計の楽しさを取り戻した」**という、エンジニアの勝利宣言だったのではないでしょうか。
私たちがExcelの現場でやってきたことも、まさに同じでした。
「VBAなんて時代遅れだ」という世間の雑音に惑わされず、現場で最も速く、最も確実に同僚を定時で帰せる道具を追求した結果、私たちはExcelマネージャーという強固なレールを作り上げ、AIをその上で走らせる道を選びました。
人間が書かない時代。
言語の古さなど、何の意味も持ちません。
現場で本当に役に立ち、0.1秒で結果を出し、関所テストを全件パスして涼しい顔で動くコード。
それを作れるのであれば、言語は何だっていいのです。
そして、その舞台がExcelである限り、私たちはこれからも胸を張って、AIとともに最速のVBAを叩き込んでいけばいい。
巨人の告白を聞きながら、私は自作のExcelマネージャーの道具箱をそっと撫で、確かな手応えとともに深く頷いたのでした。