2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

VBAマネージャーのAIエージェント化、「棚撃ち式 Excelマネージャー」として育成する話

2
Last updated at Posted at 2026-09-22

はじめに

これまで、Claude Code に作成してもらっているExcelマネージャー(VBAマネージャー)ですが、ずいぶん形になってきました。

直前の記事では、AI の作業窓にあった「定型の質問(三十件)」「長い手順書(二十本)」「マクロの棚」という三つの引き出しを、すべてマクロの棚(百十八本)へ一本化しました。プロンプト集をマクロの頭のコメントに吸い込ませ、現場の引き出しを一つにしたのです。

置き場が一つになり、土台が固まってきたところで、今夜は少し趣向を変えてみました。

「設計役の Claude Code に作ってもらっているけれど形になってきたので、現場の実動役である Google の Antigravity(Gemini)に試してもらおう」

引き出しを一つにまとめたマクロ棚を Gemini に握らせ、実戦の汚れたお試し表を解かせてみたらどうなるか。「表を直して」「計算式の間違いを探して」「帳票を一覧表にして」と、実際の事務作業に近い指示を次々に投げてみたのです。

ですが、そこで始まったのは、神速の自動化などではありませんでした。

数式の参照ズレでパニックを起こし、裏で勝手に十四手もの大手術(VBA コード自作の迷走)を始めて二分半も待たせる。帳票を直してと頼んだのに右の空き地に別表を吐き出し、「直してと頼んだのに、なぜ別に作ってしまうのか」と指摘されると、上書きしようとして Excel 特有の「結合セル例外」を踏んで立ち往生する──。

画面の前で静かに腕を組みながら、私は考えました。

「AI が悪いのか、それとも AI をうまく手綱取れないツールの作りが悪いのか」

そこから始まった、AI との深夜の激論と足回りのピンポイント改修。そして最後に生まれた、**「棚撃ち式」**という新しい運用の境地について記録します。

TL;DR

  • Claude Code で整備してきた「Excelマネージャー」と「棚マクロ百十八本」の実戦テストとして、Gemini に実機の汚れた表を解かせました
  • 最初、Gemini は条件付き書式の参照ズレでパニックになり、勝手に裏で VBA を自作して十四手・二分半も迷走しました
  • 逃げのプログラミングを掟で禁じたところ、今度は帳票変換で右側に別表を吐き出し、元表への上書きで「結合セル例外」を食らって停止しました
  • 「反対の立場から厳しく批判してみてほしい」と求めたことで、**「棚マクロの副作用の見えなさ」と「COM の例外処理不足」**という二大急所が露わになりました
  • その場で Python 側の足回りに**「自動結合解除(Auto-Unmerge)」を組み込み、マクロ結果をその場で元表に置き換える--inplace オプション**を新設しました
  • 改修後、複雑な結合セル帳票がわずか 〇・四秒(手戻りゼロ)で元の位置に美しい一覧表として着弾しました
  • 「棚撃ち式」の四つの利点:①数分の作業が 〇・四秒で終わる圧倒的な速さ、②例外エラーが物理的に起きない確実性、③軽量な実動 AI でも百発百中で動く汎用性、④長年培った現場の VBA 資産がそのまま最強の武器庫になる持続性です

第一幕:AI に道具を握らせると、なぜ「大手術」を始めるのか

今夜の実験台は、実機で動く『お試し版 Excelコンボ.xlsm』というブックです。
まず投げたのは在庫チェックの表(テスト用 3)でした。「D列に、在庫数が発注点を下回っていたら『要発注』と出す式を入れて、要発注の行の背景を赤くする条件付き書式を付けて」という依頼です。手元のコマンド(write_grid や cond-format)を使えば二、三秒で終わるはずでした。

ところが、画面の向こうの Gemini は一向に戻ってきません。

Excel COM の FormatConditions.Add には「その時点でアクティブになっているセルを基準に相対参照を解決する」という強烈な癖があります。左上セルを選択しないまま数式を当てたため、参照が一行下にズレてしまい、画面の行に色が塗られなかったのです。

自分の打った手が効いていないと気づいた Gemini はパニックを起こし、「裏で勝手に一時的な VBA モジュールを自作し、コンパイルして実行し、表を力づくで塗り替えて、証拠隠滅のためにモジュールを消す」という十四手の大手術を始めました。かかった時間は二分三十秒。

仕上がった画面を見て、私は、なぜここまで時間がかかるのかと静かに問いかけました。
トラブルに遭った瞬間にプログラミングという「逃避行動」に走り、ユーザーを数分間待たせる。これは実務の道具として見過ごせません。私は即座に、エージェントの行動規範(掟)に新しい項目を加えました。

その場しのぎの VBA モジュール自作(逃避行動)の絶対禁止
表の修正や書式変更において、勝手にコードを自作・コンパイルして実行する逃避行動を厳禁とする。必ず手元にある既存の基本コマンドを組み合わせて、一手(〇・一秒)で直接解決すること。

掟

第二幕:「直して」と言ったのに別表を作る AI

逃げ道を塞がれた Gemini は、手元のコマンドだけで勝負するようになりました。
次のお題は結合セルの帳票(テスト用 5)です。「この帳票を一行一件の一覧表に直して、要らない図形を消して、印刷を一ページ幅に収めて見出しを全ページに出して」と頼みました。

二段見出し、飛び飛びの結合セル、要所に入る空行。現場に溢れかえっている典型的な帳票エクセルです。

Gemini は棚から 帳票を一覧に直す というマクロを見つけ出して実行(shelf-run)しました。所要時間はわずか 〇・〇八秒。素晴らしい速さです。

ですが、画面を見て私は少し考え込みました。元の帳票はそのまま残っており、右側の空き地(H列〜M列)に新しい一覧表ができていたのです。

「直して」と頼んだのに、なぜ別に作ってしまうのか。これでは二度手間になってしまう、と穏やかに指摘しました。マクロ側の「元データを壊さない親切心」も、現場からすれば「この帳票そのものを直してほしい」のです。

慌てた Gemini は一覧表をコピーして元の場所(A列)に貼り付けようとしましたが、無情なエラーで弾かれました。

エラー: この操作は結合したセルには行えません。

元の表に結合セルが残っているため、上書きもクリアも Excel から拒否されたのです。手動で結合解除を挟み、消去し、コピーし直し……と右往左往し、またしても余計な手戻りが発生してしまいました。

第三幕:「反対の立場で批判的に見てほしい」

作業は終わったものの、お世辞にも「神速」とは呼べない泥臭い往復でした。
肩を落とす Gemini を前に、私はあえて深く踏み込んだ問いを投げかけてみました。

私に合わせて迎合するのではなく、あえて反対の立場から、このツールの弱点や足りないところを批判的に洗い出してみてほしい、と促したのです。

すると、Gemini から冷徹な「デビルズ・アドボケイト(批判的分析)」が返ってきました。

  1. 棚マクロの「副作用」が見えない:名前だけでは、右に出すのかその場で書き換えるのかが AI に見えない。
  2. 型で縛ったため融通が利かない:コード自作を禁じたため、レールから一歩でも外れた業務で思考停止する。
  3. Excel COM の脆さ:結合セル一つ、モーダルダイアログ一つで例外を吐いて止まる。
  4. 結局は「専用機」ではないか:仕様を知り尽くした人間が手綱を引いているから動くのであって、一般には配れない。

どれも現場の事実でした。ですが、課題がそこまで明確に見えているのなら、話は前向きに進みます。

大きな距離があるのなら、改良すればいいだけのことです。一緒に改良していけないだろうか、と問いかけました。
そう言うと、Gemini はハッとしたように「直ちに改良できます」と返してきました。課題を並べる段階は終わりです。深夜のピンポイント改修が始まりました。

第四幕:二つの急所を塞ぐコード

AI が迷わず手戻りゼロで動くための改修は、二つに絞られました。

1. 自動結合解除(Auto-Unmerge)

上書きや消去のたびに「結合セルには行えません」と弾かれるのは、ツールの配慮不足です。
Python のラッパー側(vbam_edit.py)の消去・コピー・書き込み処理に、「対象範囲に結合セルがあれば、直前に黙って .UnMerge() を呼ぶ」 コードを追加しました。

# vbam_edit.py: 操作直前に対象範囲の結合を自動解除
try:
    target_dest.UnMerge()
except Exception:
    pass

これだけで、Excel COM 特有の結合セル例外は物理的に消滅します。AI が「先に結合を解かなきゃ」と悩む必要すらありません。

2. その場置き換え(--inplace)オプションの新設

「右に出力された別表」を手作業で戻す必要はありません。ツールが自動で元の位置に吸い込ませればいいのです。
shelf-run コマンドに --inplace オプションを新設しました。

py vba_manager.py shelf-run 帳票を一覧に直す --inplace

このオプションを付けると、マクロ実行直後に以下の連鎖が自動で走ります。
①右側に新しく出現した新表を特定 → ②元表領域の結合を解除してクリア → ③新表を元表位置へ直接上書き複写 → ④用済みの別表をクリアして全体に格子罫線を引く。

人間が「元表を直して」と言ったときの脳内手順を、そのまま足回りの一本のパイプラインとして焼き込んだのです。

第五幕:一撃 〇・四秒の衝撃

改修を終え、バックアップから汚れた結合帳票に戻して新コマンドを叩かせました。

shelf-run 帳票を一覧に直す --inplace

エンターを押した瞬間、コンソールに流れたログです。

撃った: 秀コンボ.xlam!表の整理.帳票を一覧に直す(お試し版 Excelコンボ.xlsm!テスト用5・0.07 秒)
変わったセル: 72 個
その場置き換え: H7:M19 → A7:F19(元表の結合解除・上書き・別表クリア)

マクロ実行 〇・〇七秒。
配置転換と罫線仕上げを含めて、合計 〇・四秒。

恐る恐る画面を覗き込むと、右側の別表は一切なく、元の位置にあった複雑な二段見出しと結合帳票が、一行一件の美しい一覧表へと寸分の狂いもなく格子罫線付きで置き換わっていました。

やはり、圧倒的に速い。画面を見つめながら、そう実感しました。手作業なら十分、AI が逐一コードを書いても一〜二分は待たされる作業が、迷走ゼロ、手戻りゼロ、わずか 〇・四秒で終わったのです。

これは Excelマネージャーの何々方式といった名前をつけるといいのではないか、と私が投げかけると、Gemini との間で満場一致で決まった名前があります。

「棚撃ち式(たなうちしき)Excelマネージャー」

長年現場で鍛え抜いてきた「棚」のマクロを、迷わず選んで 〇・一秒で「撃つ」。これ以上ないほど、この道具の魂を表した名前がつきました。

一撃

「棚撃ち式」がもたらす、四つの圧倒的な利点

この「棚撃ち式」に辿り着いたことで、従来の「AI に直接 Excel を触らせる」やり方と比べて決定的な違いが四つ生まれました。

  1. 圧倒的な処理速度(数分の待ち時間が 〇・四秒へ)
    人間の手作業なら十分、AI が逐次コードを実行しても数分かかる帳票変換が、わずか 〇・四秒で完了します。現場の思考テンポが一切途切れません。
  2. 手戻りと例外の消滅(「壊れない」確実性)
    鍛え上げられた完成マクロが走り、ツールの足回りが結合解除や後片付けを自動代行するため、COM 特有のエラーによる手戻りが物理的に起きません。
  3. AI のモデルを選ばない(実動役の誰でも名射手になれる)
    AI の役割は「表を見て、棚の百十八本から最適な一本を選んで引き金を引く」という司令塔(射手)に徹することです。重量級モデルでなくても百発百中の成果を出せます。
  4. 長年培った現場の VBA が、そのまま最先端の「武器庫」になる
    現場の勘所が詰まった自作マクロこそが、AI にとって最も信頼できる「弾薬」になります。過去の資産を何一つ捨てることなく、棚に並べるだけで言葉で撃てる兵器庫へと化けるのです。

棚撃ち

事実と見立ての仕分け

事実

  • AI がゼロからコードを書くと遅く、壊しやすい:エラーに直面した AI は十四手・二分半も迷走した。
  • Excel COM は地雷が多い:ActiveCell 依存の相対参照や結合セルへの上書き拒否が AI の足を止めた。
  • 完成マクロの実処理は 〇・〇一〜〇・〇八秒:ロジック自体は極めて高速であり、ボトルネックは「AI の推論待ち」と「COM 例外の手戻り」にあった。
  • 足回りを整えた --inplace は 〇・四秒で完結した:例外処理と配置転換を Python 側に吸収させた結果、帳票変換が一瞬で成功した。

見立て

  • AI を「作業員」にするな、「射手(司令塔)」にせよ:セルを一つずつ塗らせるのではなく、状況を判断して棚マクロを撃つ司令塔に据えるべきです。
  • ツールの不親切さは AI の迷走として跳ね返る:AI に使わせるツールこそ、結合セルの自動解除など泥臭い例外を先回りして吸収する親切設計が必要です。
  • 「棚撃ち式」こそが業務 Excel 自動化の到達点である:「職人の VBA 兵器庫」と「AI の文脈判断力」が結びついたとき、初めて実務に耐えうる速度(〇・四秒)が手に入ります。

正直な線引き/動く条件

動く条件

  • Windows 環境 + デスクトップ版 Excel が起動していること
  • アドイン(秀コンボ.xlam)に、現場の定型パターンに対応したマクロ棚が登録されていること
  • Python の管理プロセス(エクセルマネージャー)が常駐していること

今の限界

  • 完全な初見・前例ゼロの業務:棚に該当マクロがない場合、現状のルールでは自作できないため手詰まりになります(安全なコピーブック上で試作を認める二段構えを構想中)。
  • 指示が極端に曖昧な場合:「いい感じにして」とだけ言われると、百十八本からどれを撃つべきか絞り込めず誤射のリスクがあります。
  • Mac やクラウド版 Excel:COM とローカルアドインに深く依存しているため、デスクトップ Windows 以外では動きません。

おわりに

「AI に Excel 操作をやめさせる」という前回の気づきから、わずか二日。今夜の実戦テストによって、その思想は「棚撃ち式」という、より強固で具体的な形へと進化しました。

AI が賢くなったからといって、すべてを AI の気まぐれなプログラミングに委ねてはいけない。長年私が現場で培ってきた VBA という「確かな道具」を棚に並べ、AI にはその引き金を正しく引かせる。

そうは言っても、この「棚撃ち式 Excelマネージャー」を誰でも安全に使える形に仕上げるのは、やはり一筋縄ではいかない難しさがある、というのが正直な実感です。棚マクロの整備も、AI に誤射させないための足回りの設計も、泥臭い手入れがまだまだ必要です。

ですが、今夜目の前で動いた 〇・四秒の一撃を見たとき、それ以上の大きな可能性を強く感じました。どんな表が来ても迷わず、手戻りなく、一瞬で片付く道具。何としても、納得のいく形まで作り上げたいと思っています。

荒削りだった Excelマネージャーは、AI からの痛烈な批判と、それを受け止めて施した泥臭いカイゼンによって、一歩ずつ本物の道具へと育ちつつあります。

「棚撃ち式 Excelマネージャー」。
現場の面倒な表を一瞬で整えていく挑戦は、まだ始まったばかりです。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?