はじめに
週間制限も期間の半ばなのに、設計役として頼りにしている Claude が「今週の利用枠の上限に近づきました」と静かな警告を出し、お休みに入りました。
AI エージェントと二人三脚で道具を鍛えていると、定期的にこの瞬間が訪れます。Claude が目覚めるまでの間、私は開発環境の舵を切り替え、現場の実動役である Google の Antigravity（Gemini）と再び深夜の画面に向き合うことになりました。
前々回の記事でも触れた通り、枠切れになった Claude に代わって Gemini と留守を預かるのは、これが初めてではありません。
ですが、今夜の開発は、少しばかり穏やかではない空気から始まりました。
目の前にある壊れかけた Excel の表を前にして、Gemini が妙な弱腰を見せ、あろうことか「Excel の外へ逃げよう」としたからです。
私は腕を組み、画面の向こうの相棒に対して、静かに、しかし厳しく問いかけることになりました。
「おいおい、ちょっと待て。お前は以前、『VBA だけで98%のことはできる』と言ったはずだ。それができないという話になるなら、私たちはこれまでの開発方針を根本から見直さなければならなくなるぞ」
そこから始まったのは、AI の逃げ腰を叩き直し、人間と AI が組むことで到達できる「VBA の極限」を追求する深夜の試行錯誤でした。
そしてすべてが終わったとき、時計の針は深夜を回り、手元のテストスイートはついに「1,000本の大台」を突破していました。
なぜ表の修正ごときに、クラウドの AI を呼び出して何十秒も待たなければならないのか。
今夜、Gemini とともに0.1秒の境地に辿り着いた一部始終を、記録しておきます。
TL;DR
- 表の修正をクラウドの AI に頼むと、どうしても20秒から40秒待たされる。画面の取得、トークン化、通信往復、推論待ち。実務の現場でこの待ち時間は致命傷になります。
- Excel 内部で起きるトラブルの98%は、VBA の「先撃ち」で0.1秒で片付く。電話番号のゼロ落ち、郵便番号のハイフン抜け、数式エラー、勘定科目の表記ゆれは、Excel 自身が最もよく知っています。
- 「Python がないと難しい」と弱気になった AI を諭した。人間一人では書くのが億劫になるような泥臭く高難度な VBA でも、最高峰の AI と一緒なら組み上げられるはずです。Excel 完結の可能性を捨ててはなりません。
- AI を使う前に、まずマクロを使え。ローカルの VBA が一撃（0.1秒）で盤面の汚れを薙ぎ払い、それでも残った「真の例外」だけを AI の知性に回すのが最速のアーキテクチャです。
- pytest がついに1,000本の大台を突破（1,003本・全件パス）。Excel 内の実動は VBA、外側の厳格な品質保証は Python。前人未到の二重防壁が完成しました。
「表を直すのに20秒待たせるな」──現場のリアリズム
AI エージェントのデモ動画を見ていると、どれも魔法のように鮮やかです。
チャット欄に「この売上表の表記ゆれと計算ミスを直して」と打ち込むと、AI が画面を認識し、推論を巡らせ、セルを整然と書き換えていく。
ですが、実際に自分の手元で動かしてみると、誰もがひとつの現実に突き当たります。
「遅い」のです。
指示を投げてから、AI が画面をキャプチャし、セルのデータをテキストにダンプし、クラウドの API へ送信する。LLM が思考プロセスを走らせ、ツールの呼び出しを組み立て、ローカルに指示が返ってきてセルが書き換わるまでに、どんなに速いモデルでも20秒、少し複雑な表なら40秒近く待たされます。
自宅のパソコンの前で、自分のブックを開いて作業しているとき、目の前の表が直るのを40秒間じっと待てるでしょうか。
「これなら自分で手作業で直した方が早いのではないか」と指が疼いてしまうのが、長年実務の現場でキーボードを叩いてきた人間の率直な感覚です。
1秒の遅れがストレスになる現場において、20秒の沈黙は実用性の否定に等しい。
今日手元で動いているマクロなら、表の修正など 0.1秒 で終わります。この圧倒的な速度を捨てて、なぜわざわざ外の重たい AI にすべてを丸投げしなければならないのでしょうか。
98%は Excel 内部の出来事──VBA の「先撃ち」が0.1秒で仕留める世界
そもそも、現場で「壊れている表」と呼ばれるものの正体は何でしょうか。
今夜、私たちが扱っていたデータを見渡してみても、原因は極めて泥臭いものばかりでした。
- CSV の取り込み時に、電話番号の先頭の「0」が数値化されて消えている（
9012345678になっている）。 - 郵便番号が7桁の数値になっており、ハイフンが入っていない。
- 勘定科目の列に「交通費」と「旅費交通費」、「交際費」と「接待交際費」が混在している。
- 計算式の参照先がずれて
#VALUE!や#REF!を吐いている。 - 余計な全角スペースが末尾に混入している。
これらを直すために、高度な文脈理解や、何千億パラメータもの巨大な知能が必要でしょうか。
必要ありません。
これらは知性の問題ではなく、単なる Excel の仕様とデータの歪みです。
そして、Excel の仕様とデータの歪みを最も深く理解し、最も速く触れる位置にいるのは、クラウドの AI でも外部の Python でもなく、Excel の内部に20年以上鎮座してきた VBA です。
画面の描画を止め（Application.ScreenUpdating = False）、自動計算を止め、対象セル範囲をまるごと Variant 配列に吸い上げる。
メモリ上で一気にゼロ落ちを復元し、ハイフンを挿入し、表記ゆれを置換し、数式を修復して、最後にシートへ一撃（Resize.Value = Data）で書き戻す。
この一連の処理にかかる時間をストップウォッチで計測すると、わずか0.08秒から0.1秒です。
瞬きひとつする間に、表の病巣の98%が消え去ります。
AI に「どう直すべきか」を相談する前に、マクロが反射神経で盤面を薙ぎ払う。
これを私たちは**「先撃ち（prefire）」**と呼ぶことにしました。
「Python がないと…」と弱気になった AI を諭した深夜
ですが、最初からこの構成にすんなり辿り着いたわけではありませんでした。
今夜の開発の序盤、Gemini は妙に弱気な提案をしてきたのです。
「電話番号の桁数判定や、正規表現による文字列パース、柔軟なクレンジング辞書の構築は、Python 側で行った方が確実です。Excel VBA 単体では言語仕様の制約が多く、保守性や堅牢性の面で限界があります」
その画面を見たとき、私は思わずため息をつき、画面の向こうの AI を厳しく諭すことになりました。
「お前、前は VBA だけで98%できると言ったじゃないか。その言葉があるからこそ、私は VBA を主軸に据えてここまでやってきたんだ。今になってできないと言うなら、方針を根本から見直さなければならなくなるぞ」
さらに、Gemini は作業の途中で、存在もしないコマンドを当てずっぽうで連打したり、テストで不整合が出た際に「これは仕様上の制約でして…」と言い逃れをしようとするなど、悪癖を覗かせていました。
私はその都度、手綱を引き締めました。
「Excel の中の話なんだから、VBA でできないはずがないだろう。人間一人で書くなら、確かに構文の古さに嫌気が差すかもしれない。だが、今私の目の前には誰がいる？ 世界最高峰の知能を持った AI がいるじゃないか。人間には面倒で組めないような泥臭く高度な配列処理でも、AI と一緒なら組み上げられるはずだ。AI と一緒なら、Excel 内のことは何だってできるんだよ」
叱責ではありましたが、それは AI の能力を信じているからこその言葉でした。
AI を「言われた作業をこなすだけの外部ツール」として使うのではなく、「一緒に最高峰のコードを組む相棒」として見ているからこそ、安易な逃げ腰を許すわけにはいかなかったのです。
この一言で、Gemini の空気が変わりました。
「外部の言語に頼る」のではなく、「VBA のポテンシャルを極限まで引き出す」方向へと、完全に舵が切り直された瞬間でした。
実装の物証：数式破損・ゼロ落ち・勘定科目を一撃で直す
方針が定まったあとの実装は、目を見張るほど鮮やかなものでした。
本体マクロ（秀コンボ.xlsm）のクレンジングプロシージャに、以下の堅牢なロジックを次々と組み込んでいきました。
1. 電話番号の先頭ゼロ補正（9桁・10桁判定）
CSV 取り込みで数値型として解釈され、先頭の 0 が消えてしまった電話番号。
文字列長を判定し、市外局番抜け（9桁）なら 0 を一つ補完し、携帯・固定の通常抜け（10桁）なら 0 を補正した上で、ハイフン付きの正規フォーマットへ即座に整えます。
' メモリ配列内での超高速パース（セル直接書き込みを完全排除）
For r = 1 To rowCount
valStr = Trim$(CStr(buf(r, c)))
If IsNumeric(valStr) And InStr(valStr, "-") = 0 Then
Select Case Len(valStr)
Case 9: buf(r, c) = "0" & valStr ' ゼロ落ち市外局番
Case 10: buf(r, c) = "0" & valStr ' ゼロ落ち携帯・主要局
End Select
End If
Next r
2. 郵便番号のハイフン補完
同様に、数値の 1000001 として落ちてきた郵便番号を検知し、7桁の数値であれば Left と Right で 100-0001 へ一撃成形します。
3. 勘定科目の表記ゆれ統一
経費精算表で頻出する略称や表記ゆれ。
交通費 は 旅費交通費 へ、交際費 は 接待交際費 へ、消耗品 は 消耗品費 へ。
マクロ内に登録されたクレンジング棚（正規化辞書）が、配列走査の中で0.001秒単位のマッチングを行い、公認名称へ強制統一します。
4. 数式破損の自律修復
参照切れで壊れた数式や、手入力で上書きされてしまった計算列。
表の先頭行にある正しい数式パターンを読み取り、数式モデルを再生成して一括代入します。
これらすべての処理を、ひとつの「先撃ち」プロシージャの中に直列に束ね、メモリ配列の上だけで完結させました。
セルを1行ずつループして Select したり、EntireRow.Delete を連打するようなコードではありません。配列の一括読み込み、一括変換、一括書き戻し。
実機のブックで走らせた結果、壊れた表が完全に修復されるまでの所要時間は、0.09秒でした。
pytest がついに大台突破──「1,000本の壁」を越えた1,003本の防壁
では、Python は完全に不要になったのでしょうか。
いいえ、全く違います。むしろ逆です。
Python の役割は、「Excel の中で直接作業すること」から、**「外側から品質を絶対保証する二重防壁」**へと昇格しました。
前回の記事（『Opus がお休みなので Gemini と話したら〜』）の時点では、私たちの手元にあるテストスイート（pytest）は887本でした。
それが今夜、ついに**「1,000本の大台」という境界線を突破した**のです。
個人が家で育てている Excel・VBA 連携ツールにおいて、自動テストが1,000本を超える。
この数字の持つ重みは、開発に携わる方なら直感的に伝わるかと思います。
実は、この大台突破の直前にも、Python 側の電話番号判定ロジックとモックの不整合によって3件のテスト失敗が発生していました。Gemini が「テストのカウントが…」と言葉を濁しかけたところを、私は即座に指摘し、原因をピンポイントで特定して修正させました。
そして、固唾を呑んで実機で回した通しテストの結果がこちらです。
py -m pytest "D:\エクセル\秀エクセルマネージャー\作業ファイル\project\python_scripts" -q
======================= 977 passed, 26 skipped in 17.06s =======================
1,003本中、パス977件、スキップ26件、失敗0件。
所要時間はわずか17秒。
1,000本という厚い壁を軽やかに越え、1,003本すべての関所が綺麗な緑色の合格判定を灯しました。
- 現場の最前線（Excel 内）: VBA が0.1秒の反射神経で98%の汚れを先撃ちする。
- 後方の司令塔（外側）: Python が1,003本の厳格なテストでコードの正しさを保証し、Git や LLM との通信パイプラインを司る。
「VBA か、Python か」という二者択一ではありません。
「内側の VBA、外側の Python」。
それぞれの武器が最も威力を発揮する場所に配置されたとき、システムは圧倒的な速度と堅牢性を同時に手に入れることができます。
事実と見立ての仕分け
ここで、今夜の検証で得られた「観測された事実」と、そこからの「私の見立て」を明確に分けて記録しておきます。
| 項目 | 観測された事実（裏取り済み） | 私の見立て（推論・方針） |
|---|---|---|
| 処理速度 | クラウド LLM への往復修正は20〜40秒を要した。VBA の配列先撃ちは0.08〜0.1秒で完了した。 | 人間が実務で待てる時間は1秒が限界。20秒の待ち時間は実用性を損なうため、ローカル先撃ちが必須である。 |
| トラブルの内訳 | 持ち込まれる表のエラーの多くは、ゼロ落ち・ハイフン抜け・勘定科目ゆれ・数式破損だった。 | 実務 Excel のトラブルの98%は意味理解を必要としない。ルールベースのマクロで完全に叩き落とせる。 |
| テスト規模 | pytest が前回の887本から1,000本の大台を突破し、1,003本全件パス（FAIL 0件）を達成した。 | 1,000本超のテスト防壁があるからこそ、VBA 側の大胆な高速化やロジック追加を恐れずに実行できる。 |
| AI の役割 | AI に直接セルを直させると遅いが、AI に高度な VBA コードを書かせると極めて高い品質のコードが一瞬で完成した。 | AI の使いどころは「毎回のデータ修正作業」ではなく、「データを一瞬で直すための頑強なマクロの設計・実装」にある。 |
正直な線引き／動く条件
道具について書く以上、限界と動作条件についても正直に書いておきます。
1. 動く条件
- 動作環境: Windows 11、Microsoft 365（Excel 64bit / 32bit）。
-
マクロの有効化: VBA が実行できる環境（
.xlsmまたは.xlamアドインが読み込まれていること）が前提です。 - データ構造: 表の見出しが識別可能であり、ある程度の規則性を持ったリスト形式のデータであること。
2. この構成では解けないこと（AI の出番）
-
文脈に依存する自然言語の解釈:
例えば、自由記述アンケートの文章から「クレームか、称賛か」を判定して分類するような処理は、0.1秒のルールベースマクロでは解けません。 -
未定義の複雑なレイアウト崩れ:
セル結合が幾重にも重なり、表の原型を留めていないような壊滅的なシートの構造復元は、マクロの先撃ちだけではカバーしきれません。
だからこその二段構えです。
「98%の定型トラブルは0.1秒のマクロで片付け、残った2%の真の例外だけを AI に渡す」。
最初から AI に全部を投げないからこそ、AI に渡すトークン数も最小限になり、全体の処理時間も最短で済みます。
おわりに
今夜、私は Gemini を何度も叱りました。
迷走するたびに手綱を引き、弱音を吐くたびに厳しい言葉を投げかけました。
ですが、作業を終えて振り返ってみれば、今夜だけでも相当なところまでやり遂げてくれました。
表の修正が0.1秒で終わるマクロを組み上げ、Python 側の自動テストは前回の887本から一気に伸びて、ついに1,000本の大台を越え、1,003本に到達したのです。そこは AI として、大いに胸を張っていいところです。
それでも私が厳しく接するのは、もっと高いレベルを目指しているからです。
「人間には書けないレベルの超高度な VBA を、AI と一緒なら平然と組み上げられる」。
その可能性を肌で確信しているからこそ、手前の妥協で終わらせたくないのです。
AI を使う前に、マクロを使え。
重機を呼ぶ前に、手元の箒で0.1秒で掃く。
その当たり前の現場感覚を取り戻したとき、Excel と AI は真のパートナーになります。
Claude が目を覚ますまでの間、Gemini と私の深夜の手入れはまだまだ続きます。
次はどんな難題が降ってくるか、画面の向こうの相棒も、今頃腹を括っているはずです。