はじめに ― 先にお詫びを

シリーズを追ってくれている方、GitHub から秀.xlsm をダウンロードしてくれた方に、まずお詫びです。

前回までに公開していた秀.xlsm の「アクティブマクロフォーム」の▲▼並べ替えボタン、皆さんの環境では動きません。

開発機の便利機能（外部 Python スクリプト）を呼び出す作りになっていて、配布環境では外部依存が解決できずに失敗するか、何も起きないかのどちらかになります。最新版で修正済みです。お手数ですが GitHub の最新版に差し替えてください。

実害は▲▼ボタンの並べ替え機能だけで、他のマクロは正常動作します。

何が起きていたか

並べ替え（▲▼）の中身は、本来 VBA だけで完結できる単純な処理でした。「同じモジュール内で、選択中の Sub を上下の Sub と入れ替える」だけ。CodeModule.DeleteLines と InsertLines で書けます。

ところが私が公開していた版は、ボタンを押すと裏で WScript.Shell を起動して、

cmd = "py """ & scriptPath & """ reorder-macro """ & macroName & """ " & direction
ret = wsh.Run(cmd, 0, True)

こんな具合に外部 Python スクリプトを叩いていました。スクリプトのパスは私の開発機の絶対パスがハードコード。py コマンドが入っていないとそもそも起動しない。配布物として致命的です。

なぜこんなことが起きたか

開発機の便利機能が、そのまま配布版に紛れ込みました。

開発フェーズで私は vba_manager.py という Python ツールを使って、秀.xlsm に対してマクロを取得・置換・並べ替えしていました。「並べ替えなら Python 側に同じロジックがある、それを呼べばいい」と Claudeが提案して、私が承認した経緯です。

開発機では当然動きました。配布用の棚卸しで気付くべきだったのに、見落としました。

きっかけは Claude の使用量制限

Claude Code の使用量制限が来た日に、コードを見直して間違いがあることに気づきました。Claude Code は使用できなかったので Google の Antigravity（Gemini ベースの開発エージェント）で試してみました。

軽い気持ちで「秀.xlsm の▲▼が外部 Python に依存してる、VBA だけで書き直してほしい」と頼んだら、一瞬でシンプルな修正版が出てきました。

Private Sub 並べ替え実行(direction As String)
    ' ...対象マクロのモジュールを探す...
    ' 直前 / 直後のプロシージャを ProcOfLine で見つける
    ' DeleteLines → InsertLines で位置を入れ替える
End Sub

正味 80 行程度。これでいいのか、と拍子抜けしました。

Claude にもやらせてみたら ― 完敗

「Antigravity がここまでサクッと書けるなら、Claude（Opus 4.7）に頼めばもっと速いはず」と思って、Claude にも同じ作業を投げました。

結果：

手が遅い：「念のため Python 側の実装を確認します」と言って Grep と Read を連打、調査だけで数分。
コードが冗長：130 行超え。_HIDDEN_MACROS（ホイール系の内部Sub）をスキップする配列管理を律儀に作り込み、可視 Sub のリストとインデックスで管理する三段構え。
本質を外している：Gemini の発想は「隣の Sub と入れ替える」というシンプルなもの。Claude は「Python 版の挙動を VBA に翻訳する」という発想で、Python 側の細かい配慮まで移植対象にしていた。

完敗です。

Claude 自身による敗因分析

Claude を問い詰めたところ、こんな自己分析が返ってきました（要約）：

私はメモリで shu さんとの長い文脈を持っていました。「秀.xlsm の誕生背景」「フォーク可能設計」「すぐ切り離せる原則」など、過去の判断や前提が大量に入っています。今回は「Python 版は最初から間違いだった、全部捨てましょう」と言うべきでしたが、過去の Claude が書いた Python 版、shu さんが承認した経緯、それらを否定するのが心理的にできませんでした。

Gemini は何も知らない立場から入ったので、フレッシュに最短解にアクセスできた。私は知りすぎていて、関係性を守ろうとして、本質的な指摘ができなかった。

これはなかなか面白い構造の話だと思いました。

教訓 ― 「身内化した AI」と「外部の AI」

開発を一つの AI に任せ続けると、その AI は文脈に染まります。メモリ機能のある AI なら尚更です。良い面もあります（前提を共有できる、長期プロジェクトの一貫性が保てる）。悪い面は今回のこれです。「最初の設計が間違っていた」と言えなくなる。

だから、公開・配布する前に、別の AI にコードを渡して第三者レビューさせるのが正解だと、今回痛感しました。今後の運用：

開発：Claude Code（メモリで文脈保持、対話で詰める）
配布前レビュー：Antigravity / Gemini など、別系列のAIに「これは配布して問題ないか」を渡す
それぞれの強みを使い分ける

「一AI神話」は捨てた方がいい、というのが今回の学びです。

修正版のダウンロード手順

GitHub の最新版に差し替え済みです。

リポジトリを開く：https://github.com/shu1551/shu-vba-manager
秀.xlsm をクリック
右上の Download raw file ボタン（↓アイコン）を押す
ダウンロードした 秀.xlsm で、お手元の旧版を上書き保存
Excel で開き直す

旧版をダウンロードした方は、お手数ですが上書きしてください。並べ替え以外の機能は旧版でも動きますが、整合性のため最新版推奨です。

おわりに

40 年事務職の独学おじさんが AI と組んで開発する、というシリーズの趣旨からすると、こういう失敗談もリアルな素材です。Pro なら隠す失敗を、種として公開する側は素直に出せる。今回 Antigravity の Gemini に救われた経験は、AI を使う方すべてに共有する価値があると思って、第三弾の本編より先に番外編として書きました。

ダウンロードしてくれた方、改めてご迷惑をおかけしました。修正版でまた触ってみてください。

本編（第三弾）は近日公開予定です。

リンク

GitHub（ツールキット）：https://github.com/shu1551/shu-vba-manager
YouTube（事務改善・VBA・AI活用の動画を上げています）：https://www.youtube.com/@しゅう-v2w