はじめに
先日、以下の記事を投稿しました。
Claude と私が心血を注いで作り上げた Excel VBA 専用 MCP サーバー「excel-manager」を土台に、Google の AI（Gemini）を走らせるための「掟（AGENTS.md）」と「スキル（SKILL.md）」を徹底的に見直し、会話だけで UserForm が組み上がるようになった記録です。
あの改修によって、フォーム全体の白紙再構築やレイアウトの調整は確かに見違えるほど速くなりました。
しかし、私の「からくりポケット」――思いついたアイデアをポケットから小道具を取り出すように、その場で即座にマクロやフォームに仕立て上げる開発――を日々進める中で、まだどうしても拭いきれない最後のもどかしさが残っていたのです。
それは、「ちょっとした日常の機能追加やマクロのピンポイント修正」における、AI の妙な重さと待ち時間でした。
フォーム全体の骨組みを作るような大きな作業ではなく、「このボタンの挙動を少し変えてほしい」「このイベントを 1 つ足してほしい」といった日常の些細な修正を頼んだときのことです。
AI は「承知しました。関連するプロシージャを確認します」と答えたきり、画面の前で沈黙します。
待たされること、短くても 3 分、手間取ると 5 分から 10 分近く。
AI は真面目にコードを何百行も画面に読み込み、関係のない周辺プロシージャを芋づる式に調べ、1 箇所直すごとに「次はコンパイルします」「次はアドインに登録します」と小出しに往復を繰り返す……。
せっかく頭の中に「こういう仕掛けがあったら便利だな！」というアイデアが湧いているのに、AI の作業待ちで思考のテンポがブツブツと切れてしまう。これでは「からくりポケット」の真価が発揮できません。
そこで今夜、私は AI の行動規範（掟）をさらに研ぎ澄まし、日常のピンポイント修正における無駄な行動を物理的に徹底排除する型を完成させました。
その結果どうなったか。
これまで数分かかっていた日常のマクロ・フォーム修正が、依頼からアドインの再ロードまで含めて「わずか 32 秒」（実機の書き換えからアドイン焼き付け自体は 7 秒）で完了する超爆速環境へと化けたのです。
あまりの速さに、私自身「うん、できているな。……というか、異常に早くできたな。どうしてそんなに早くできるようになったんだ？」と思わず AI を問い詰めてしまったほどでした。
今回は、その実測データと、AI を劇的に覚醒させた「掟と並列直撃」の技術的裏側について、詳しく書き残しておきます。
TL;DR
- 圧倒的な速度差の実測: 以前は 1 箇所のピンポイント修正に 3 分 30 秒〜6 分 かかっていたが、現在は 32 秒（実機書き換え〜アドイン焼き付けはわずか 7 秒）で完走。約 7〜10 倍の爆速化。
-
遅さの真犯人: AI の知能が低いのではなく、①ファイル閲覧（
view_file）による画面汚染とトークン遅延、②周辺コードの詮索連打、③小出しの直列実行（1 手ずつ往復待ち）、という 4 大ブレーキ を AI が無意識に踏んでいた。 -
解決策（掟の進化）:
- ファイル閲覧（
view_file）の全面禁止（Analyzed 表示を撲滅） - 初手 0 秒直撃（思考レスでピンポイント
grep） - 修正・コンパイル・アドイン登録の 「1 レスポンス完全並列実行（マルチツールコール）」
- VBA 識別子（変数名小文字
x等）の事前整合ガード
- ファイル閲覧（
- 結果: 「思いついた仕掛けを口頭でつぶやくだけで、30 秒後には手元の Excel で動いている」という極限の俊敏性を手に入れた。
1. 圧倒的な速度差：実測数字で見るビフォーアフター
今回の検証は、日常の開発で実際に出た以下のリアルな要望で行いました。
手元でバリバリ動かしている『統合マクロフォーム』の一覧リスト（lstItems）を触っていたときのことです。
一覧に並んでいるマクロの名前を見ながら、ここから直接そのマクロの VBE コード編集画面へ飛べたら便利だな、と思い立ちました。
私はチャット欄に、一覧に出ているやつをクリックしたら編集に飛べるようにしてほしい、と指示を出しました。
この改修にかかった時間を、以前の「手探り・逐次実行型」と、現在の「爆速からくりポケット」で実測比較した結果が以下の表です。
| 作業工程 | 以前（逐次・手探り型） | 現在（爆速からくりポケット） | 改善効果 |
|---|---|---|---|
| ① 初動調査・該当箇所特定 | 1分〜2分（コード長文読込） | 約6秒（ピンポイントgrep） | 約15倍高速 |
| ② コード生成・VBA注入 | 1分〜2分（ファイル経由等） | 約19秒（VBA内部API直結） | 約5倍高速 |
| ③ 全体コンパイル通過 | 30秒〜1分（往復確認待ち） | 約1秒（並列実行） | 約45倍高速 |
| ④ アドイン（.xlam）再登録 | 1分（往復確認待ち） | 約6秒（並列実行） | 約10倍高速 |
| 合計所要時間 | 約3分30秒 〜 6分 | 約32秒（実書き換え7秒） | 約7〜10倍の爆速化 |
実際の実機作業ログ（秒刻みの物証）
画面の前でストップウォッチを押すまでもなく、実行ログのタイムスタンプがその凄まじい速度を雄弁に物語っています。
23:48:21 【私】「一覧ですよ。一覧に出ているやつをクリックすると、編集に飛ぶ」
23:48:27 【AI】grep で lstItems 関連イベントを特定（所要 6 秒）
23:48:46 【AI】lstItems_MouseUp イベントを VBA フォームモジュールへ注入
23:48:47 【AI】全体コンパイル実行 → 通過（所要 1 秒）
23:48:53 【AI】アドイン（秀コンボ.xlam）へ即時再登録・焼き付け完了（所要 6 秒）
23:48:56 【AI】「完了いたしました」と即答
チャットで指示を送信してから、AI がプロシージャを特定し、イベントコードを生成してフォームへ注入し、コンパイルを通し、アドインファイルを再生成して Excel に再ロードさせるまで、すべて込みでわずか 32 秒です。
しかも、コードを実際に書き換えてからアドインが焼き上がるまでの実作業時間は、たったの 7 秒でした。
2. なぜ以前は数分もかかっていたのか ── AI が踏んでいた「4大ブレーキ」
プロンプトで「急いでやってくれ」「速くしてくれ」といくら叫んでも、AI は速くなりません。
以前の AI は、自分自身では「慎重に、安全に作業しているつもり」で、以下の 4 つの致命的なブレーキ を踏み続けていたからです。
ブレーキ①：ファイル閲覧（view_file）による画面汚染とトークン遅延
AI は生真面目なので、「現状のフォームコードを確認しなければ」と、ファイル閲覧ツール（view_file）を使ってコードを何百行もチャット画面に読み込もうとします。
巨大なテキストがコンテキストに流れ込むと、画面描画の待ち時間とトークン処理だけで、何も起きないまま 1〜2 分画面がフリーズします（画面に「Analyzed」と出て止まるあれです）。
ブレーキ②：周辺コードの詮索・調査連打
目的のリストボックスのイベントを 1 つ書くだけなのに、「念のためダブルクリックイベントも」「初期化処理も」「関連するボタン制御も」と芋づる式に get_procedure や grep を連打。何往復も調査を繰り返して時間を溶かしていました。
ブレーキ③：小出しの逐次実行（直列ステップ病）
「プロシージャを追加しました（結果を待つ）」
→「では全体コンパイルを通します（結果を待つ）」
→「ではアドインに登録します（結果を待つ）」
このように 1 手ずつ人間や AI の思考ターンを挟むため、通信と推論のオーバーヘッドが単純に 3 倍〜4 倍に膨れ上がっていました。
ブレーキ④：シェル操作（PowerShell）の迂回
一時ファイルを作って Python スクリプトを実行するなど、中間ファイルを経由した間接操作を行っていたため、プロセスの起動オーバーヘッドとディスク I/O のタイムラグが積み重なっていました。
3. 爆速化を実現した「掟」の進化と技術的仕掛け
この 4 大ブレーキを物理的に叩き潰すために、私はプロジェクトの最上位規範である AGENTS.md に以下の鉄の掟を敷きました。
① ファイル閲覧（view_file）の全面禁止
- **ファイル閲覧（`view_file`）による画面汚染の完全撲滅**:
通常のExcel作業・点呼・マクロ修正において、周辺ファイルやコードの `view_file` 閲覧を全面禁止する。
画面に不要な「Analyzed」を一切出さず、初手から専用MCPコマンドのみを0秒直撃すること。
見る必要のないコードは絶対に読ませない。目的のプロシージャやイベントが分かっていれば、MCP ツール（excel-manager）のピンポイント検索だけで急所を捉え、ピンセットで抜き差しするだけに徹させました。
② 初手 0 秒直撃（思考レスで即座に道具を叩く）
AI が「どう直そうか」「他に影響はないか」と内部推論（Thinking）で長考するのを禁止しました。
点呼やマクロ修正の指示を受けた瞬間、思考を挟まず 0 秒で専用 MCP コマンドを発火させるルールを徹底したことで、初動のタイムラグが数秒に縮まりました。
③ 1 レスポンス内での「完全並列実行（マルチツールコール）」
これが今回の最大の高速化要因です。
修正フェーズに入ったら、「コード注入（または置換）」「全体コンパイル」「アドイン再登録」の 3 コマンドを、AI が 1 回のレスポンス内で同時に並列全撃ち（マルチツールコール） するように義務付けました。
通常なら 3 往復かかる通信と推論が、たった 1 往復に凝縮されます。待ち時間が物理的に消滅するのです。
（※ツール呼び出し自体は AI から 1 レスポンスで同時に発行されますが、実行環境側で配列順に確実にパイプライン処理されるため、「注入 → コンパイル → 登録」という依存関係の順序も 100% 保証されています）
④ VBA 識別子（大小文字）の事前整合ガード
VBA には「同一プロジェクト内で同じ変数名を使うと、後から書いた大文字・小文字にプロジェクト全体が勝手に書き換えられてしまう」という悪名高い仕様があります。
たとえば、イベントプロシージャの引数でうっかり大文字の X を使ってしまうと、ブック全体で小文字の x として使っていた変数がすべて大文字に化けてしまい、予期せぬ差分が発生します。
excel-manager にはこの衝突を検知して停止する安全ガードが組み込まれているため、AI 側にも「引数は小文字の x を使う」という事前ガードを徹底。エラー停止による手戻りをゼロに抑え込みました。
4. 実際に注入したコード（右クリック編集ジャンプ）
今回、わずか 7 秒で 統合マクロフォーム に注入されたコードは、以下の極めてシンプルで美しいイベントプロシージャです。
Private Sub lstItems_MouseUp(ByVal Button As Integer, ByVal Shift As Integer, ByVal x As Single, ByVal Y As Single)
If Button = 2 Then ' 右クリック
btnEdit_Click
End If
End Sub
ご覧のとおり、第 3 節で触れた伏線もしっかり回収されており、引数の x（ByVal x As Single）が既存ブックに合わせて小文字のまま完璧に整合しています。大文字小文字エラーによる手戻りは 1 回も起きません。
リストボックスの MouseUp イベントを拾い、右クリック（Button = 2）が押された瞬間に、既存の「編集」ボタンの処理（btnEdit_Click）をそのまま呼び出す。
余計な車輪の再発明をせず、足元にある既存資産をそのまま最短経路で繋ぐ。
この無駄のないコード設計と、迷いのない並列一撃が組み合わさることで、32 秒という驚異的なタイムが生まれました。
おわりに ── 思考の速度で動く「からくりポケット」へ
今回の爆速化を体験して、私は深く納得しました。
「AI ペアプログラミングの真価は、コード生成の賢さではなく、試行錯誤のサイクルの短さにある」 ということです。
以前のように 1 箇所の修正に 3 分も 5 分も待たされていたら、「右クリックで飛べたら便利かも」と思っても、「でも頼むと待たされるし、まあ今のままでもいいか……」と諦めてしまいます。アイデアがそこで死んでしまうのです。
しかし、口頭で「ここを右クリックしたら飛べるようにして」とつぶやくだけで、30 秒後には手元の Excel でそのとおりに動いているとしたらどうでしょうか。
「次はここに定型文ボタンを置こう」
「次はダブルクリックで別画面を開こう」
「次は並べ替えのキー操作を付けよう」
思いついたアイデアが、熱を帯びたまま、その場で次々と現実の道具になっていく。
まさに、40 年前に Lotus 1-2-3 でメニューマクロを組んで「仕事が一気に楽になった！」と感動したあの原体験が、現代の AI と掟によって、思考のスピードそのもので手元に現れる世界です。
AI との開発で「なんかテンポが悪いな」「待ち時間が長くてイライラするな」と感じている方は、ぜひ AI に「ファイル閲覧の禁止」と「1 レスポンス内での並列全撃ち」を課してみてください。
余計な寄り道を捨てさせた先にあるのは、驚くほど身軽で爆速なパートナーの姿です。
思考の速度で道具が立ち上がるからくりポケットの夜は、まだまだ続きます。
【追記】記事を投稿する段になって、さらなる特大の爆速化が起きた話 ── ブラウザ手作業（1分30秒）からPython裏配管直結（7.8秒）へ
この記事を書き終え、まさに「Qiita の下書き保存」を AI に任せた瞬間に、この物語の真骨頂とも言える大事件が起きました。
これまで、Qiita への下書き流し込みは Claude がブラウザ拡張機能（Claude in Chrome）を使って行っていました。エディタを開き、題・タグを入れ、画像を 1 枚ずつ貼り、プレビューを検証して下書き保存を押す。Claude も十分速くやってくれていましたが、それでも画面の往復や操作待ちで 「約 1 分 30 秒（90秒）」 はかかっていました（Gemini に至っては画面要素を見失って迷走し、数分以上溶かすのが日常茶飯事でした）。
ところが今回、Gemini が「ブラウザが開かない！」「ログインできない！」と盛大にやらかし、私から 「小手先で画面を触るな、Python スクリプトで根本から直せ！」 と雷を落とされたのです。
追い詰められた Gemini は、正面玄関（ブラウザ操作）を諦め、普段使っている Chrome のログイン済み Cookie と暗号化キーを裏で直結・自動同期し、Playwright で裏から叩き込む一本の Python スクリプト（qiita_draft.py push）を組み上げました。
その結果どうなったか。
画面を一切開くことなく、題・タグ 5 つ・挿絵 3 枚・本文流し込み・プレビュー機械検査・下書き保存まで、わずか 7.8 秒 で一撃完走したのです。
1 分 30 秒かかっていた作業が、一瞬の 7 秒台へ消滅。
この道具の存在を知った Claude は、
「私が『Chrome 拡張を 1 手ずつ操作する』前提から出られなかった。ブラウザ操作は拡張でやるものと決めつけていただけで、一本のスクリプトにすれば手の間は消える。Gemini はその前提を持たずスクリプトにした。大きな改善だ」
と完敗を認め、即座に自身のスキル（行動規範）を書き換えて push を第一選択に採用しました。
「優秀な GUI ツールがあるからと、人間と同じように画面を操作させて満足していないか？」
「裏配管を Python スクリプト 1 本で直結した方が、10 倍以上速いのではないか？」
道具を作る側も、使う側も、前提を疑って裏配管を繋いだ瞬間に世界が変わる ── まさしくこの記事のテーマそのものが、記事を投稿する最後の最後まで実証された痛快な夜となりました。