はじめに
九月十九日の未明に、「秀エクセルマネージャー」を開発中のまま公開した、という記事を書きました。
外から Python で Excel を掴み、Claude Code や Gemini に道具を握らせて、表の仕事を片付けさせる。
その仕組みを追いかけて、お題を作り、夜通しテストを回してきました。画面を見ていると、AI が自分で考えてセルを埋め、表を整えていく。確かに技術としては面白く、少し未来のような光景でした。
ですが、今朝、ふだん使っている自分のアドイン（秀コンボ）を開き直して、AI作業窓の通信の仕組みを眺めながら、私はこう思いました。
「ふだんの仕事で、毎回 AI を呼ぶ必要はあるのだろうか」
世間では「プロンプトで Excel 業務を自動化する」「AI エージェントに Excel を直接操作させる」という話が毎日のように流れてきます。私たち自身、その最前線を試してきました。だからこそ、ずっと足元に引っかかっていた違和感がありました。
遅い。通信の負荷が大きい。そして何より、他人のパソコンに配れない。
その違和感を抱えたまま、今朝、手元のアドインにほんの三十六行の関数を差し込みました。そして、AI に読ませるために書き溜めていた二十本の手順書を机の上に並べてみたとき、答えがはっきりと見えました。
AI に Excel を直接触らせるのをやめる。AI にはマクロを作らせて、現場は言葉でマクロを先撃ちする。
その方が圧倒的に速く、無駄がなく、そして誰にでも配れる形になりました。今日起きたことを、そのまま記録します。
TL;DR
- 毎回 AI に Excel を直接操作させる方式は、遅く（数十秒待ち）、通信への依存が重く、職場に配れない（環境構築の壁） という三つの壁に突き当たります
- 鍛え上げた六十七本のマクロ棚に、依頼文からキーワードを拾うわずか三十六行の関数を挟んだところ、言葉で頼んで AI 通信 〇 回・約一秒 で処理が終わるようになりました
- AI に作業させるために書いていた二十本の手順書を棚卸ししたところ、「手順書が書けている仕事は、そのままマクロに焼ける」 ことが分かりました
- 二十本のうち、すでに棚にあるものが七本、既存マクロを並べるだけが七本、新規は六本。残り十三本を鍛えれば、手順書はすべて消えます
- AI を使うのは作るときの一回だけ。現場は完成したマクロを叩く。 AI を毎日の作業員にするのではなく、裏方の鍛冶場に閉じ込めてマクロを打たせる体制が、結局いちばんの正解でした
毎回 AI を呼ぶやり方の、三つの限界
ここ数か月、私たちは Python から Excel を操縦するエージェント環境を突き詰めてきました。Claude Code に指示を出し、Gemini に道具を握らせて動かす。
動く範囲は広がりましたし、エージェントの動きを見るのは楽しいものです。ですが、実務の道具として見たとき、どうしても超えられない壁が三つありました。
1. 速さの壁
九月十一日の実測で、手作りのマクロなら 〇・三秒 で終わる処理が、Python と AI を通すと 二十二秒 かかりました。
また、Gemini がダッシュボードを一手ずつ推論しながら作ったときは、五十二回のやり取りで 二百九十八秒（約五分） かかっています。
画面の向こうで AI が考えているのを待つ時間は、開発の実験なら面白がれますが、日常の業務ではテンポが完全に崩れます。
2. 依存と無駄の壁
AI に直接操作させるということは、表を触るたびに外部の推論エンジンと往復するということです。
ネットワーク環境に左右され、モデルの応答を毎回待つ構造は、決まり切った定型処理をこなす道具としては無駄が多すぎます。
3. 配れない壁
これが最も大きいです。
Python の環境、API の設定、ターミナルの操作、CLI へのログイン。どれだけ自分のパソコンで高度な AI 環境を作っても、職場の同僚のパソコンにそのまま持っていくことはできません。
配れない道具は、実務の道具にはならない。
私たちが直面したのは、この当たり前の現実でした。
わずか三十六行の「先撃ち」
そこで今朝、ふだん使っている自分のアドイン（秀コンボ）を開き直しました。
この中には、どんな表が来ても壊れないようにテストを重ねて鍛えてきた、六十七本の完成マクロ（「表の整理」モジュール） が入っています。
それぞれのマクロの頭には、以前、何気なくこんなコメントを残していました。
' 依頼の語: 二重計上|二重払い|同日同額|同じ日付|同じ金額|重複
Sub 同日同額の二重計上を一覧にする()
' ...
End Sub
照合に要る材料は、最初から全部 VBA の中にありました。
「フォームに入力された言葉から、この語を探して、当たったらマクロを直接叩けばいいのではないか」
そう思い立って、Claude Code に頼んで三十六行の関数を一本書いてもらいました。
-
コンボ道具.先撃ち候補（新規・三十六行）:
マクロの頭にある' 依頼の語:を読み、依頼文に含まれる単語の長さの合計が最大になるマクロ名を返す。長い語ほど点数が高くなるので、「二重計上」が「合計」のような短い語に負けません。 -
実行ボタンの頭に十数行を差し込み:
候補が見つかったら『「◯◯」で実行します』と一度だけ確認し、はいならApplication.Runでマクロを撃って終了する。外れたり、いいえを押したときだけ、今までどおり後ろの AI へ流す。
できた仕組みに、いくつか言葉を投げてみました。
○ 二重計上を一覧にして → 同日同額の二重計上を一覧にする
○ スパークラインを足して → スパークライン折れ線を足す
○ ウォーターフォールにして → ウォーターフォールグラフを作る
○ 度数分布表を右に作って → 度数分布表を右に作る
○ 年齢と勤続年数を足して → 年齢と勤続年数を足す
○ こんにちは → (AIへ)
全部合いました。
入力欄に「二重計上を一覧にして」と書いて実行を押すと、確認の画面が一つ出て、はいを押すと約一秒で表が仕上がります。AI は一回も呼んでいません。
言葉で頼める入口はそのままに、裏で AI の通信が消えました。
手順書を眺めていて気づいたこと
先撃ちが動いたあと、もう一つ気になっていたことがありました。
AI に複雑な作業をさせるために、少しずつ書き溜めてきた「手順書」のことです。手元に二十本ありました。
「この手順書、もう要らなくなるんじゃないか」
中を開いてみると、手順書はこういう形をしていました。
【手順書：◯◯】
ゴールに着くまで手順どおりに進め、各手順の完了条件を満たしたか確かめること:
（開始条件・手順・完了条件）
これは AI に手順を教えるための指示書です。
ですが、手順と完了条件がここまで明確に書けているということは、人が途中で判断する余地がもう無いということです。それなら、最初から VBA に焼いてしまえばいい。
手順書は「消える」のではなく、「マクロを鍛えるための種」 だったのです。
手元の二十本を、いま棚にある六十七本と突き合わせてみました。
| 区分 | 本数 | 内容 |
|---|---|---|
| すでに棚にある | 七本 | 月次の集計表、重複チェック、グラフ付き報告、印刷の仕上げ、空白処理など |
| 既存マクロを順に呼ぶだけ | 七本 | データの掃除、表の点検、数式の監査、CSV取り込み後の整形など |
| 本当に新規 | 六本 | 引き継ぎ準備、図形と画像の整理、名前付き範囲の整理など |
新規の六本のうち、三本は別のモジュールに似た処理があるので、呼ぶだけで済む可能性が高いです。
つまり、新しく鍛える必要があるのは実質十三本だけでした。
この十三本をマクロにして棚に入れ、頭に ' 依頼の語: を添えれば、二十本の手順書はすべて空になります。
手順書が空になるということは、日々の仕事から AI が完全に退場する、ということです。
毎日の作業員と、鍛冶場の職人
世間がやっている「プロンプトで Excel を直接動かす」やり方は、いわば 「毎日アルバイトの作業員を雇って、パソコンの隣に座らせている」 ような状態です。
- 毎回指示を出して、作業が終わるのを数十秒待つ
- 毎回外部と通信し、モデルの挙動に気を配る
- 体調や機嫌によって、たまに指示を取り違える
- その作業員を、他人のパソコンに連れていくことはできない
一方、私たちが今日たどり着いたのは、「AI は裏方の鍛冶場に閉じ込めて、現場には完成した道具だけを配る」 という形です。
-
AI を使うのは「型を作るとき」の一回だけ:
新しい表の型に出会ったときだけ、鍛冶場で AI にマクロを打たせる。テスト表を何十枚もぶつけて、穴を塞ぎ切る。 -
現場はマクロを撃つだけ:
一度棚に入れば、日常の業務では言葉で呼んで 〇・三秒で終わる。通信もログインも要りません。 -
アドイン（.xlam）一本で配れる:
同僚のパソコンに必要なのは、アドインファイルが一つだけ。Python も設定も要りません。
【これまでのやり方】
[人] ──(指示文)──> [AI] ──(20秒待ち・毎回通信)──> [Excelを直接操作]
【今日からのやり方】
[鍛冶場（作るとき）]
[AI] ──(1回だけ)──> [過酷なテストを通過したマクロを棚に入れる]
[現場（ふだんの仕事）]
[人] ──(指示文)──> [先撃ち照合] ──(約1秒・通信なし)──> [マクロ実行]
│ (外れたときだけ)
└───> [AIへ]
AI を使うのは作るときの一回だけ。現場は完成したマクロを一瞬で動かす。
この違いは、日々の実務を繰り返すほど圧倒的な差になります。
そして何より、片方は職場に届き、もう片方は届きません。
事実と見立ての仕分け
ここで、実際に確かめた事実と、私の見立てを分けておきます。
確かめた事実
- 先撃ちの動作: 三十六行の照合関数により、六十七本のマクロ棚に対応する言葉は、AI 通信 〇 回・約一秒で直接実行された。
- 手順書の内訳: 二十本のうち、七本はすでに棚にあり、七本は既存マクロの直列呼び出しで済み、新規は六本だった。
- 配布の実態: アドイン（.xlam）として保存したマクロ群は、外部環境（Python、API キー）を一切持たない素の Excel でそのまま動作する。
私の見立て
- AI 呼び出しの激減: 定型の繰り返し作業に限れば、棚を整備することで、日々の業務における AI の出番は九割以上減らせる。
- 手順書の役目: 手順書が書ける仕事は、AI に読ませるよりマクロに焼いた方が、中長期的な運用の安定性は圧倒的に高くなる。
- AI の最終的な居場所: マクロが数百本に増えたときは「どれを撃つか」の選定だけに軽量な AI を使う可能性があるが、表を触る実動そのものはマクロが担うべきである。
正直な線引き
この仕組みの限界と、現在の線引きも正直に書いておきます。
-
語の照合の限界:
先撃ちはキーワードの照合です。棚にある語からあまりに離れた言い回しをされると外れます。ただし、外れたときは後ろの AI に落ちるだけなので、実害は「一秒で終わるはずが数十秒かかる」だけです。 -
人の判断が要る仕事:
「この数字はどちらの科目に振り分けるべきか」といった文脈の判断は、マクロにはできません。ただ、それは AI に丸投げすべきでもなく、人間が決めるべき領分です。 -
全く新しい型:
一度も見たことがない構造の表に出会ったときは、マクロでは太刀打ちできません。そのときだけ、鍛冶場にいる AI を呼び出して、新しいマクロを一本打たせる必要があります。
おわりに
「これからは AI の時代だから、VBA なんて勉強しても意味がない」と言われることがあります。
ですが、AI エージェントを突き詰めてみて分かったのは、むしろ逆でした。
AI がいてくれるからこそ、人間には作れなかったほど堅牢なマクロの棚を、手元に揃えられるようになったのです。
どんな表でも壊れないマクロを、人間が一人で何十本も書くのは無理があります。
ですが、テストを何十枚も作って厳しく審査する鍛冶場があれば、AI は数分で頑丈なマクロを打ち上げてくれます。そして出来上がったマクロは、通信もログインも要らずに、誰のパソコンでも一瞬で動きます。
AI は、毎日の作業員として雇うのではありませんでした。
裏方の鍛冶場で道具を打たせるために使うのが、一番無駄がなく、一番遠くまで届く配置でした。
手元に残った手順書は、あと十三本です。
この十三本を種にして、マクロを鍛えるところから始めます。