会話するだけで怪物マクロが作れる、VBAマネージャーを更新した話

はじめに

五月に「会話するだけでマクロが直る」という記事を書きました。

七月に、それを自分で書き直しました。「直る」ではなく「会話するだけですごいマクロが作れる」だった、と。

八月に、もう一段上がりました。怪物みたいなものができました。

Excelコンボといいます。Excel のフォームの中に AI が住んでいて、開いているブックを見ながら会話する窓です。コードは 3,784 行、その中にプロシージャが 83 本。ユーザーフォーム一枚の話です。手で書いていたら、私は途中で諦めていました。

この記事は、その怪物を建てるのに使った道具──公開している自作ツール shu-vba-manager の更新告知です。前回の更新告知は七月十三日でした。

あれから一か月と少し、公開のほうは止めたまま、手元だけが進んでいました。 怪物を建てるほうに時間を使っていたからです。そして建て終えて振り返ると、建てているあいだに踏んだ詰まりが、そのまま道具の直しどころの一覧になっていました。 今回足したものは、ほとんど全部そこから出ています。

大きいのは次の二つです。

• gate（関所） ── 「直した。で、通ったのか？」に機械が一言で答えるコマンド。本体のコピーの中で構文検査とテストを走らせ、通過か不通過かを終了コード 0 / 1 で返します
• AI が自分で詰まりを解けるようにした四点 ── フォームを閉じる、中断モードを外す、入力を求めるダイアログに答える、実行時エラーを文字で持ち帰る。どれも、これまで私に頼んでいた作業です

ほかに、フォームをテキストで持ち出せるようにしたのと、公開前の検査を厚くしたのが入っています。一式はここにあります。

なぜ今書くか

正直に書くと、一か月以上、公開物を置き去りにしていました。 手元の道具は毎日直しているのに、GitHub のほうは七月十七日のまま止まっている。使ってくださっている方には、その間の改良が一つも届いていませんでした。

止まっていた理由は、道具を使う側が忙しかったからです。八月はずっと Excelコンボを作っていました。そちらの話は連載に書いてきました。書いていないのは、そのあいだに道具の側で起きていたことです。

TL;DR

• 会話だけで、ユーザーフォーム一枚に 3,784 行・プロシージャ 83 本の怪物が建ちました。二番目に大きいフォームの 2.5 倍です。建てられた理由は腕ではなく、作るのが安くなったからです
• 量だけではありません。Windows の API を八本直に呼び、パイプで AI を子プロセスとして常駐させ、VBA が VBA 自身を書き換えています。私はその宣言を一行も書いていません。注文の言葉と、出てくるものの高度さが釣り合っていません
• 先に環境を作った人が、その環境でしか届かない場所に行きます。 同じことを、ハルミさんも書いていました。私にとっての環境が VBAマネージャーで、これが無かったら怪物には届いていません
• コマンドが 76 → 80 になりました（日本語の別名を数えると 87）。新しいのは gate / close-form / vbe-reset / form-to-vba の四本です
• gate（関所） ── 本体のコピーで構文検査とテストを走らせ、PASS / FAIL を終了コード 0 / 1 で返します。テストが 0 本のブックは合格になりません（合否を言えないので）
• AI が人に頼まなくなりました。 表示中のフォームを閉じる、VBE の中断モードを外す、InputBox に答えて先へ進める、実行時エラーをダイアログにせず文字で受け取る──全部、私が手で片づけていたものです
• form-to-vba でフォームを作成マクロに変換できます（.frx を持ち歩かずテキストだけで運べます）。公開前チェックには「秘密の文字列」の検査が入りました。「画面の値を消した」は、消えた証拠になりません
• 使い方は変わりません。既存のコマンドの打ち方は一つも変えていません（run-macro だけ既定の内部動作が変わったので、戻す --raw を用意しました）
• 現在 80 コマンド／一式 20,006 行／pytest 126 件＋実機 E2E 17 件（2026-08-26 実測）

前回までのあらすじ

この連載では、Excel VBA を Claude Code と会話しながら直す話を書いています。その会話の下で動いているのが shu-vba-manager で、いまは MCP サーバーとして常駐し、開いたままのブックに相乗りして働きます。前回の更新告知は「遅くなった犯人を挙げた」話でした。今回は、その道具で建てたもののほうが先に大きくなった、という回です。

本題1: 怪物のほうが先に大きくなった

まず、直しどころの一覧を出した側の話をします。

Excelコンボは、Excel のフォームの中に AI が住んでいて、開いているブックを見ながら会話する窓です（フォームの名前は「AI作業窓」といいます）。八月のあいだに、よく使う指示を選ぶタブが付き、材料を先回りして渡すようになり、AI が書いた結果を見て自分で直す輪が回るようになりました。その経過は先週の記事に書きました。

書いていなかったのは、中身の大きさです。数えてもらいました。

数えたもの（コードの行数・デザイナ部を除く）	実測
Excelコンボのコード	3,784 行（空行とコメントを除くと 3,234 行）
その中のプロシージャ	83 本（最長は［元に戻す］の 272 行）
家で2番目に大きいフォーム	1,487 行
小さいほうのフォーム（名前を1つ聞くだけ）	45 行

二番目に大きいものの 2.5 倍。名前を一つ聞くだけのフォームと比べたら、八十倍以上です。

中身も、ボタン一つの裏でこれだけ動いています。外の AI と話す通信。ブックから材料を集めて先に渡す部品。戻せない操作を人に聞く承認の窓。退避と［元に戻す］。往復を数える輪。止まり方の判定。エンジンごとの切り替え。定型の読み書き。書式・置換・条件付き書式のそれぞれの実行部。これはフォームではなく、一本のソフトです。

そして正直なところ、この量は、手で書いていたら届きません。 腕の話をしているのではありません。量の話です。3,784 行を打ち込んで、83 本のプロシージャを頭の中で並べ直して、途中で仕様が変わるたびに手で追いかける。私はどこかで力尽きます。というより、力尽きるのが分かっているので、最初から作りません。

量だけではなく、中身も

もう一つ、量とは別に書いておきたいことがあります。中で使っている手が、事務のマクロの範囲を出ています。 これも数えてもらいました。

• Windows の API を八本、直に宣言して呼んでいます。 CreatePipe / CreateProcessW / WriteFile / CloseHandle / GetExitCodeProcess ほか。AI の本体をブックの子プロセスとして立ち上げ、その標準入力のパイプを VBA が握ったまま離さず、指示を一行ずつ流し込むためのものです
• 六十四ビットの Excel で落ちないように書いてあります。 ポインタを受ける型（LongPtr）が三十一か所。ここを一つ間違えると、動かないのではなく Excel ごと落ちます
• 通信は MSXML2.ServerXMLHTTP.6.0 を同期で投げ、返ってきた UTF-8 を ADODB.Stream で剥がしています
• そして、VBA プロジェクト自身に手が届いています（VBComponents が三十五か所）。VBA が VBA を読み、書き換え、実行する部分です

セルに色を塗る、行を消す、一覧を作る──私がこれまで書いてきたマクロは、その辺りにいました。上の四つは、その隣の部屋の話です。

そして、私はこの八本の宣言を一行も書いていません。 私がしたのは、「同じ質問なのに時間が変わらないのはなぜか」と聞いて、返ってきた案のうち「AI を会話のあいだ立ち上げたままにする」を選んだことだけです。注文の言葉と、出てくるものの高度さが、まるで釣り合っていません。 そこが今回いちばん面白かったところです。

同じことを、先に言っている人がいました

これは私だけの気づきではありませんでした。八月二十三日に、ハルミさんという方のことを書きました。

VBA のための本格的な HTTP クライアントを公開された方です。その記事で、ご本人は今回やっていたことをこう言い表しています。

AIがVBAでソフトウェア開発をできる環境を作る

「AI に VBA を書かせる」ことではなく、そちらに近かった、と。そしてハルミさんも、実装のコードを一行も直接書いていないと明記しています。用意したのは、AI が自分の間違いに気づいて直せるようにする足場のほうでした。ご本人が重く見たのも、AI が一発で正しく書けることより「間違えたとき、自分で間違いを検出して修正できること」だ、と書かれています。

向きは私とは違います。ハルミさんはテストと静的解析で無人で回る輪を作り、私は承認と退避と会話で横に張り付いて口を出す輪を作りました。どちらが上でもありません。それでも、行き着いた形は同じでした。先に環境を作った人が、その環境でしか届かない場所に行っている。

私にとっての環境が、VBAマネージャーでした。この道具が無かったら、Excelコンボには絶対に届いていません。 一年かけて道具のほうを育てていたから、八月に怪物が建った。順番はそれだけです。

この道具があると、マクロもフォームも、会話で作れます。 取ってきて、直して、戻す。一行だけの差し替えもできる。フォームはデザイナを開かずに置ける。作るのが高いものは、作る前に諦めます。 安くなった瞬間に、諦めていたものが作れるようになる。増えたのは私の腕ではなく、諦めなくてよくなった範囲のほうです。

そして安さには代償があります。速く建てられるようになると、速く転ぶようになります。 一日に何十回もマクロを差し替えれば、差し替えにまつわる詰まりを一日に何十回も踏む。以下はその記録です。

本題2: gate（関所） ── 宿題の一番目を、道具の側に書いた

八月十三日に、ループエンジニアリングという言葉を調べた記事を書きました。

あのとき原典で読んだ定義を私の言葉に直すと、「停止条件が満たされるまで作業のサイクルを繰り返すエージェント」でした。終わりが決まっていないものは、そもそもループと呼ばない。 記事の締めに次の宿題を四つ書いて、その一番目が「停止条件を先に書く」でした。

八月二十三日の夜、その宿題に手を付けました。「停止条件を作ってくれ」と頼んで、AI が作ったのが gate です。日本語の別名は「関所」です。

撃つと、いま開いているブックを未保存の変更まで含めてコピーし、別の Excel を起こしてそのコピーだけを開き、中で構文検査とテスト Sub の一括実行をして、畳んで消します。あなたが開いている Excel には触れません。

最後に出るのは一行です。判定: 通過（PASS） か、判定: 不通過（FAIL） に理由が付いたもの。そして終了コードが 0 か 1 で返るので、シェルからも上位のスクリプトからも、そのまま停止条件として使えます。

一つだけ厳しくしました。テストが 0 本のブックは、PASS になりません。 実際に、テストを一本も書いていないブックへ撃つとこうなります。

関所: 秀.xlsm のコピーで検分します（本体は無傷）
  構文: OK（エラー 0・警告 656）
テストが見つかりません（標準モジュール 9 本 を走査）。
判定: 不通過（FAIL）  理由: テストが 0 本＝合否を言えない  （5.9秒）

構文は通っているのに、不通過です。 何も確かめていないのに通過と言うのが、停止条件としては一番たちが悪いからです。

作った日のうちに一周まわしてもらいました。テスト Sub を三本書いて撃ち、通過を確認する。次に捨てコピーのほうで、テストが見ている本体マクロの判定行をわざと潰して撃ち、不通過になることを確認する。さらに足し算を引き算にしたバグ入りのマクロを入れて 不通過「C1 期待=5 実際=-1」 → 一行直して 通過。理由を読んで直して通過まで行くところを、実機で一周しました。

通るのを見るだけでは、関所として働いている証明になりません。関所は、通せることではなく、止められることで関所です。

本題3: AI が、人に頼むのをやめた

ここからが、Excelコンボを建てているあいだに一番よく踏んだ詰まりです。共通点があります。どれも「私に頼めば解決すること」でした。

フォームを、自分で閉じる（close-form）

八月二十三日、作業の途中で AI に言いました。「フォームが開いていると、閉じてくださいと言ってくるじゃないか。自分で閉じられないのか」と。

調べてもらうと、そのとおりでした。フォームが表示されているとデザイナが取れないので、AI は「閉じてください」と私に頼み、私が閉じ、作業が再開する。毎回です。道具にコマンドが無かったから人に頼んでいただけで、できない理由は一つもありませんでした。

そこで close-form ができました。×ボタンを押したときとまったく同じ合図を窓に送ります。COM を使わないので、モーダルで他の操作を全部はねつけている状態でも効きます。

ここは正直に書きます。AI が書いた初版で、私の Excel が二回落ちました。 初版は別の合図を投げていて、窓は消えるのに VBA 側の後始末を通らない。フォームの実体が「切断された」状態で残り、次に開こうとした瞬間に Excel ごと落ちます。落ちるところを二回見たのは私です。別の Excel で切り分けてもらい、壊れた合図で閉じたときだけ落ちると再現できました。いまのコードには「この合図は二度と使わない」と理由つきで書いてあります。

中断モードを外し、入力にも答える（vbe-reset と --input-text）

残りの二つも同じ形です。マクロが実行時エラーで止まると VBE は「中断モード」で固まり、デザイナが取れず他のマクロも動かなくなります。解除には VBE を開いて「実行 > リセット」を押す──これも私の仕事でした。vbe-reset はそのボタンを外から押し、押したあとに読み直して解けていなければ「解けませんでした」と正直に返します。ただし自動では絶対に撃ちません。 走っている VBA を全部止めるので、人が「戻せ」と言ったときだけ、と方針をコードに書き込んであります。

InputBox で止まるマクロには --input-text を付けます。閉じるのではなく、値を入れて確定する。 そして入れた値は必ず報告に出します。黙って入力して先へ進む道具は怖いので。

こちらには出どころがあります。ハルミさんの xlflow には、ダイアログに自動で答えて進める仕組みが前からありました。以前それを見た AI が「秀の流儀とは違う」と言って見送っていたのです。私がそれを持ち出して並べ直してもらうと、見送ったつもりの三つのうち二つは既にうちにも入っていて、残っていた差はこの一点だけでした。様式の話にして止めたのが誤りだったので、その日のうちに潰しました。先に穴を塞いだ人がいるなら、塞ぎ方は借りるべきです。

実行時エラーを、ダイアログにせず文字で持ち帰る（run-macro の既定変更）

マクロを外から実行して、その先で実行時エラーが起きると、Excel に赤いダイアログが出て止まります。呼び出した側からは何も見えません。ただ黙って戻ってこない。

そこで既定を変えました。マクロを直に呼ぶのをやめて、受け皿を一枚かませます。 持ち主のブックに一時的な小さいモジュールを入れ、その中で対象を呼び、失敗なら番号と説明を文字列にして持ち帰る。

エラー: マクロが実行時エラーで止まりました: 実行時エラー 9: インデックスが有効範囲にありません。
（ハーネスで受けたのでダイアログは出ていません。マクロは落ちた行で終わっています）

受け皿は終わったら必ず片づけます。既定を変えたので --raw という逃げ道も付けました。予行演習（rehearse）も同じ受け皿を通ります。

これを作ろうと言ったのは私です。「エラーが出たら、まず脱出させて、それから解決する仕組みがあればいいのではないか」と聞いたら、半分もう作ってある、という返事でした。

本題4: フォームを、テキストだけで持ち歩けるようにした（form-to-vba）

八月十九日に、ユーザーフォームの設計図の話を書きました。

あの記事で使った書き出し機能が、今回から一式に入ります。form-to-vba は、フォームを「VBA だけで組み立て直す作成マクロ」に変換します。効き目が出るのは持ち出すときです。フォームの見た目は .frx というバイナリに入っていて、中身が読めず差分も取れません。作成マクロはただのテキストなので、記事に貼れる、差分が読める、別のブックに押し込むだけで移る。

--all で全部を一気に、--verify で捨てブックに実際に組み立てて元と照合します（元のブックには一行も書きません）。私の手元では、フォーム二十二本が組み上がるまで 3.4 秒でした。詳しい話は上の記事に譲ります。

本題5: 関所を、あと二つ

gate のほかに、関所が二つ増えています。どちらも AI に任せる範囲が広がったことへの備えです。

二つめ ── 戻せない操作だけ、人に聞く

Excelコンボから AI を走らせているとき、戻せない操作だけが確認ダイアログを出して止まるようにしました。セルの上書き・範囲のクリア・モジュールの削除・別名保存・ブックを閉じる、の五つです。

線引きは「読み書き」ではなく、**「戻せるか、戻せないか」**にしました。マクロの置換は退避してあるので戻せる。だから止めません。シートやブックへの操作には戻す先がない。だから止めます。却下すると AI 側に伝わるので、別の手を提案してきます。返事が三分無ければ実行せずに終わります。

その置換のほうには、同じ関所の中にもう一枚、当てる前に差分を出して確認をとる仕掛けを足しました。「戻せること」と「間違ったものを当てる前に気づけること」は別だからです。当ててから戻すより、当たる前に止まるほうが安い。

その関所を、壊してみた

この関所には困ったところがあります。普通に使っているぶんには、壊れても気づけないのです。Excelコンボから走らせたときだけ働くので、手でコマンドを打っている限り、黙って素通しするようになっていても画面は同じです。

そこで自動テストを 21 本足してもらいました。確かめているのは、通ることではなく止まり方の向きです。返事が無いときは実行しない側に倒れているか。窓に聞けない異常のときは素通しする側に倒れているか。前回の答えの残骸を拾っていないか。止める対象がちょうど「戻せない五つ」のままか。

そのテストが本当に効くのかも確かめてもらいました。関所を五通りに壊して、そのつど全部を走らせる。五通りとも、テストが落ちました。 壊したファイルは同じであることを確認して元に戻してあります。gate と同じことを、関所と、それを見張るテストの二段でやった形です。

三つめ ── 公開する前に、秘密が残っていないか調べる

出口にも関所を足しました。publish_check に「秘密の文字列」の検査です。

きっかけは、フォームの .frx を設定値の置き場として使い始めたことでした。シートから値を消しても、フォームの中には残っている。 さらに調べたら、値を消して保存し直したあとでも、ブックのバイト列の中に前の中身の断片が残っていました。

そこで、ブックの中身を丸ごとバイト列で、三通りの文字コードで走査する検査を入れました。自分で指定した文字列と、形で確実に判別できる六種類（各社の API キー、トークン、中継用の URL）を探し、当たれば公開を止めます。誤検知でいちいち止まる作りにはしていません。鳴りっぱなしの警報は、無視する癖を育てるからです。

「画面の値を消した」は、消えた証拠になりません。現物のバイト列で見る。 今回いちばん、身にしみた一行です。

本題6: 空振りを、道具の側で吸収した

毎日効いている修正が一つ。細かいものは CHANGELOG に譲ります。

code-replace が空振りしなくなりました。 VBA は保存のときに、識別子の大文字小文字をプロジェクト内の最初の書き方へ揃えます。だから .Value と書いたコードが .value で保存されていることがある。置換は文字どおり探すので「一致なし」になり、AI が三周むだ撃ちしました。私が「何度も同じ空振りを繰り返している、なんとかならないか」と言って、道具の側で吸収しました。完全一致が 0 行だったときだけ、大文字小文字 → 空白の順に緩めて探し直し、緩めて当てたときは必ず断ってから差分を出します。

同じ型の直しをもう一つ。マクロを入れ直すとアドインのショートカットキーが死ぬ症状も、持ち主はアドインに残すという決めごとで塞ぎました。どちらも、繰り返し踏んでいた穴を面でふさいだものです。

数字（2026-08-26 実測）

項目	前回公開 2026-07-17	今回 2026-08-26
コマンド数	76	80（日本語別名を含めると 87）
本体（薄い入口＋パート）	12,375 行（5パート）	13,990 行（6パート）
MCP サーバー	354 行	496 行
フォーム系4ツール	2,908 行	2,908 行（今回は手を入れていません）
テスト（純ロジック）	92 件	126 件
テスト（実機 E2E）	10 件	17 件
一式合計	17,739 行	20,006 行

行数はいずれも空行を除いた数で、対象は GitHub に置いている Python 17 本です。公開された差分は 15 ファイル・2,922 行の追加と 112 行の削除（Python だけなら 10 ファイル・2,654 行の追加と 102 行の削除）でした。

事実と見立ての仕分け

例によって仕分けます。

事実。 上の数字は 2026年8月26日に私の一台（Windows 11・64bit Excel）で数えたものです。最後に公開した状態は 2026年7月17日のコミットで、それ以降の変更は全部手元にありました。実装で手を動かしたのは AI（Claude）で、私は指示と判断と実機での確認をしています。 Excelコンボの 3,784 行・83 本は、書き出したフォームの現物を数えた実測。AI が書いた close-form の初版で私の Excel が二回落ちたことも、別の Excel で再現を取って切り分けたことも、その日の記録どおりです。フォーム二十二本が 3.4 秒で組み上がったのは 8月17日に私が実機で測りました。関所を五通りに壊して五通りともテストが落ちたのも、その場で撃った結果です。ハルミさんの記事は 8月17日の公開で、引いた三か所はいずれもご本人の記述です。

見立て。 「怪物が道具を鍛え直した」は私の言い方です。「先に環境を作った人が、その環境でしか届かない場所に行く」も、二人を並べて私が引いた線で、ハルミさんがそう言ったわけではありません。「この量は手で書いていたら届かない」も私の見立てで、手で打った時間を測ったわけではなく、私が同じものを手で書き始めたら途中でやめる、という自分についての判断です。「作るのが高いものは作る前に諦める」も実感で、数字はありません。

正直な線引き

• gate が見るのは、構文とテストだけです。 テストが触っていない部分は守れません。実際、存在しないマクロを呼ぶ Sub を足しても通ります（VBA は呼ばれるまでその行をコンパイルしないためです）。**「gate が通った＝安全」ではなく、「テストが見ている範囲では壊れていない」**です。演習用の Excel は素の環境なので、アドインの関数を呼ぶテストは --addins が要ります
• --timeout で本当に打ち切れるのは、道具が起こした演習用の Excel だけです。あなたが開いている Excel に対しては「待つのをやめて報告する」ところまでで、マクロ自体は止まりません
• close-form にキャプションを渡したとき、完全に一致するものが無ければ部分一致に落ちます。似た名前のフォームが並んでいると二枚とも閉じることがあります
• MCP サーバーは常駐しているので、今回の新コマンドは再起動するまで見えません。 承認の関所と差分の確認が働くのも、Excelコンボから走らせているときだけです
• 私の環境は Windows 11 と 64bit Excel、道具を作る相棒は Claude Code です。この一か月はクロード・フェーブルと、ところどころオーパスと話しています

おわりに

八月十二日に、この道具のことを書きました。

「自分で作った道具のことを、作った本人が正しく見積もれていない」という書き出しでしたが、あのとき見積もれていなかったのは私ではなく、その道具を毎日使っている AI のほうでした。二週間たって、今度は私の番です。私は、この道具が何を建てられるかを見積もれていませんでした。

Excelコンボがフォームの枠を越えて一本のソフトになったのは、私が急に上達したからではありません。マクロもフォームも会話で作れる場所に立っていたからです。建てるのが安い場所では、人は建てすぎます。建てすぎた結果、道具の弱いところが全部見えて、直しどころの一覧になって返ってきました。

五月に「会話するだけでマクロが直る」と書き、七月に「すごいマクロが作れる」だったと書き直し、八月は手では量が届かないものが建ちました。三段目です。上がったのは私の腕ではなく、毎回、諦めなくてよくなった範囲のほうです。

道具が怪物を建て、怪物が道具を鍛え直しました。

一式は GitHub に置いてあります。導入は ZIP ボタンからで、環境の確認は setup-check の一コマンドです。

関所は、これで三つになりました。