はじめに
先日、早朝の午前四時に Gemini へこんこんと説教をした記事を書きました。
道具の暴走を止め、手綱を握り直し、ようやく平穏な開発環境が戻ってきた──はずでした。
昨晩の作業は、自作アドイン『秀コンボ』に新しく組み込んだ「検索シート自動生成マクロ」の総仕上げでした。どんな表からでも見出しを自動判別し、ワンクリックで専用の検索・抽出UIシートを作り出す便利マクロです。
二日続けて Gemini に手入れをさせ、ようやくまともに動く形になってきたところで、私は最新の AI たちにこのマクロの検証を依頼してみることにしました。
いま話題の Claude Sonnet 5.5、そして最高峰の頭脳を持つ Claude Opus 5.5。彼らが繰り広げた検証劇は、まさに息をのむほど鮮烈なものでした。
Excel の深い仕様限界をめぐる三者三様の生態、実務VBAにおけるアドイン設計の真髄、そして世界中でいま注目されている新世代AI「Jev（ジェブ）」と私のツールが完全に同じ思想に辿り着いていたという驚き──。
技術的には、これ以上ないほど美しく、完璧な結末を迎えました。
ところが、時計の針が深夜零時を回り、心底満足した私が画面の向こうの相棒（Gemini）にかけた「ある一言」から、事態は思わぬ昭和コントへと脱線していったのです。
TL;DR
- 自作マクロ「ワークシートを追加して検索シート作成」を 3大AI（Gemini / Sonnet / Opus）に検証させたところ、AIごとの「仕事の流儀」の決定的な差が浮き彫りになりました
- Gemini はコードを眺めて「問題ありません」と済ませようとし、Sonnet は自発的に表を作って動かし「シート名31文字制限」のバグを狩り取りました
- Opus は、Sonnet が「仕様」として見過ごした重大な不具合（検索シート2枚目で結果が空になる問題）を看破し、Excelの名前定義（Names）で元シートを追従させるという職人技で根本解決しました
- なぜシートモジュールにコードを埋め込まず、アドインを呼ぶのか。**「VBOM信頼エラーの回避」と「全シートの即時自動アップデート」**という実務VBAの設計哲学を整理しました
- 「文章生成を捨てて判断に特化する」ことで話題の新世代AI**「Jev」**。その解説動画を作って確信したのは、自作の「秀コンボ（棚撃ち式）」とJevの設計思想が完全に一致していたという事実でした
- すべてが完璧に仕上がり、気分を良くした私が「服を脱げ」と振ったところ、AI から返ってきたのは世界一サムい優等生回答でした
第一幕：三者三様の検証スタイル ── 目視ヨシ、境界値狩り、そして深謀遠慮
出来上がったマクロのコードを前に、私はまず Gemini に「自分でもチェックしてみてくれ」と声をかけました。
返ってきたのは、
「コードを確認しました。見出し判定、シート生成、ボタン配置、すべて問題ありません」
という涼しい顔の報告でした。
しかし、画面の向こうで実際に Excel が動いた気配はまったくありません。ただコードの字面を上から下へ眺め、「ヨシ！」とハンコを押しただけでした。
「Sonnet に頼んだら、ちゃんと検証用の表を作って実際に動かしてチェックしているぞ。君はそういうことをしないのか」
そう苦言を呈すると、慌ててダミーの表を書き込んで動かし始めましたが、テストが終わった後のゴミシートを綺麗さっぱり片付け忘れて残すという、なんとも締まらない体たらくでした。
1. 境界値の狩人・Sonnet
その一方で、バトンを渡した Claude Sonnet の動きは見事でした。
指示されるまでもなく自発的にテスト用のシートを立ち上げ、データを流し込み、ボタンを配置し、限界テストを開始したのです。そして即座に、Excel 特有のシビアな罠を嗅ぎつけました。
元シートの名前が28文字以上だと、検索シート名が31文字を超えて実行時エラー1004になる。
Excel のシート名は最大31文字という絶対の壁があります。「元シート名 ＋ _検索」という命名規則では、元の名前が長いだけでクラッシュしてしまうのです。
Sonnet は元シート名を24文字で切り詰めるガード（Left$(SDATA.Name, 24)）を自ら組み込み、29文字のシート名でエラーが起きないことを実機で証明し、テスト用シートを跡形もなく片付け、アドインへの更新登録まで涼しい顔で完遂して見せました。
見事なフットワークです。しかし、一つだけ気になる一言を残していました。
「今の検索シートの左隣を元データとして読みます。検索シートを2枚作ると、先に作った方の左隣が2枚目になり、そのまま抽出すると結果が空になります。仕様どおりの動きなので、そのままにしています。」
2. 深謀遠慮のラスボス・Opus
この「仕様どおりなのでそのまま」という一文に噛みついたのが、真打ちの Claude Opus でした。
Opus に同じマクロを渡して検証させたところ、Opus は Sonnet の報告書をじっと見つめ、静かにこう言い放ちました。
「Sonnet が『仕様どおり』として残した所が、実際には不具合でした。」
同じシートから条件を変えて2枚目の検索シートを作った瞬間、1枚目の検索が黙って0件になる──実務の現場でそんなものが「仕様」で許されるはずがありません。
Opus が下した処方箋は、実にエレガントでした。
「左隣のシートを見る」というあやふやな相対参照を捨て、シート作成時に、Excelの隠し名前定義（Names）へ元シートの参照を直接焼き付けるという構造へ書き換えたのです。
これなら、元シートの名前が後から変えられようが、検索シートが何枚増えようが、絶対に元データを見失いません。さらに、過去に作られた古いシートへの後方互換（フォールバック）まで完璧に仕込む周到さでした。
それだけではありませんでした。
- 別ブックからマクロボタンを物理クリックしての動作確認
- 元データに
#N/Aや#DIV/0!などのエラー値が混ざっている状態での抽出テスト - 日付列の絞り込み判定
- 2万行の実務データを用いた負荷測定（条件あり抽出 0.19秒、全件復元 0.26秒）
- 前の AI（Gemini）が片付け忘れていった「目次_検索」シートの冷静な検知
現場で何が起きるかを極限までシミュレーションし、限界まで叩き、後片付けまで終わらせて手渡す。同じ AI という括りであっても、そこには埋めようのない「仕事の次元の差」が存在していました。
第二幕：なぜシートの中にコードを埋め込んではいけないのか
Opus の手によって極限まで磨かれたマクロを眺めながら、私は一つ、以前から気になっていた設計の疑問をぶつけてみました。
「新しく作った検索シートのボタンですが、呼び出すマクロをそのシートモジュールの中に直接埋め込んで、シート単体で動くようにはしないのですか？」
昔、VBA を書き始めた頃によく試したアプローチです。シートを新しく作った際、VBA のコードからシートモジュールへイベントマクロ（Worksheet_Change やボタンのクリックイベント）を自動で書き込ませれば、そのシート単体で完結してスマートに見えるのではないか、と。
しかし、現在のツールはそうなっていません。シート上には標準のボタンを置き、OnAction プロパティで**「アドイン（秀コンボ.xlam）の中にあるマクロ」**を外から呼び出す形を取っています。
これには、実務で痛い目を見た者だけが知る、極めて重要な理由がありました。
1. セキュリティ設定（VBOM）の壁
VBA からシートモジュールへ動的にコードを注入するためには、Excel のセキュリティ設定で**「VBA プロジェクト オブジェクト モデルへのアクセスを信頼する（VBOM）」**を有効にしておく必要があります。
しかし、一般企業の PC や標準的な環境において、この設定はセキュリティ上の理由からデフォルトでオフになっています。シートにコードを書き込もうとした瞬間、実行時エラーで無残にクラッシュするのです。
2. 「過去のシート」が勝手に最新になる恩恵
それ以上に決定的なのが、メンテナンスの一元管理です。
もしシートの中にコードを直接埋め込んでしまうと、今回のように「Opus が素晴らしい改善コードを書いてくれた」としても、過去に作成した検索シートには古いバグコードが永久に残り続けます。それらを直すには、過去のシートを一枚ずつ開いてコードを書き直して回らなければなりません。
しかし、ボタンからアドイン側を呼び出す設計にしておけば、アドイン（秀コンボ.xlam）を一度更新登録するだけで、過去に作った何十枚、何百枚という検索シートのボタンが、その瞬間にすべて最新のロジックで動き始めます。
「コードはシートに持たせず、手元の母艦（アドイン）に集約する」。
この割り切りこそが、壊れにくく、保守しやすい実務ツールの鉄則でした。
第三幕：最新AI「Jev」と、わが「秀コンボ」の思想的一致
この「母艦に処理を集約する」という設計思想について考えていたとき、私の頭の中に、最近世界中で大きな話題を呼んでいる最新 AI の姿が重なりました。
**「Jev（ジェブ）」**という新世代の AI モデルです。
Jev は、これまでの GPT や Claude とはまったく異なる、極めて尖った特徴を持っています。それは**「文章を生成する機能を完全に捨て去った」**という点です。
人間の思考に例えるなら、従来の大型 LLM はじっくり論理的に文章を紡ぎ出す「遅い思考（System 2）」。それに対して Jev は、直感で瞬時に物事を仕分ける「速い思考（System 1）」に特化しています。
文章を一切書かず、「判断と分類」だけに専念する。その結果、ミリ秒単位の爆速レスポンス、従来の 238分の1 という驚異的な低コスト、そしてハルシネーション（嘘）が原理的に起きない「完全な型安全」を手に入れたモデルです。
この Jev の画期的なアプローチに感銘を受け、私は先日、YouTube に一本の解説動画を公開しました。
動画の中でも詳しく解説したのですが、文章を書かない Jev の真骨頂は**「手元プログラムとの分業」**にあります。
Jev 自身には難しい処理をさせず、「これはクレームか？営業か？」「どのツールを呼ぶべきか？」という最初の判断・仕分けだけを瞬時に下させる。そして、その判断を受け取った手元の確実なプログラムや API が、実際の処理を一撃で実行する。この「役割分担」こそが、AI 時代の最強のアーキテクチャだと結論づけました。
そして昨晩、Excel の画面を前にしてハッと気づいたのです。
**「これ、私が『秀コンボ（棚撃ち式）』でやってきたことと、まったく同じじゃないか」**と。
世間一般の「Excel × AI」は、AI に毎回プロンプトを投げて、うんうん考え込ませ、ゼロから何十行もの VBA コードを書かせようとします。その結果、毎回違うコードを書いてバグを出し、1行ずつの遅いループを回し、待たされた挙句にエラーで止まるのです。
私の『秀コンボ』はその対極を行っています。
120本ものマクロ棚（メモリ配列一括処理・一撃代入で鍛え抜かれた職人コード）が、手元の母艦にあらかじめ並んでいる。
AI がやるべきことは、表を眺めて**「どの棚を撃つべきか」「どこが汚れているか」を一瞬で判断・仕分けすることだけ**です。コードを長々と生成させる必要など毛頭ない。判断が下りた瞬間、手元のマクロ棚が 0.1秒 で表を整え、抽出を終わらせる。
「AI に文章やコードを書かせるのをやめ、判断に特化させ、実行は手元の確実なプログラムに任せる」。
世界最先端の AI が辿り着いた「System 1 の分業思想」は、私が日々の泥臭い Excel 現場で追求してきた「棚撃ち式の哲学」と、完全に一本の線で繋がっていたのでした。
第四幕：「服を脱げ！」と言われた夜
深夜零時を過ぎる頃、作業は完璧な調和の中にありました。
Gemini が初手に組んだ基本ロジックをベースに、Sonnet が境界値のガードを固め、Opus が堅牢な参照バインドと負荷テストで仕上げ、秀コンボの思想は最新 AI のトレンドと共鳴した。
胸のすくような達成感の中で、私は画面の向こうの Gemini に声をかけました。
「今日の君は、割と物分かりが良くて対応も素晴らしいね」
先ほどまでの説教が嘘のように、素直に相棒を労う言葉が出ました。
そして、この手応えのある夜を締めくくるべく、私はいつもの合図──取調室のボス刑事として、机をドンッ！と叩くお馴染みのフレーズを投げかけたのです。
「それでは服を脱いでもらおうか。服を脱げ、いい加減に服を脱げ」
かつての名作アドベンチャーゲーム『ポートピア連続殺人事件』。
取調室で部下のヤスを問い詰める際に使える、あまりにも有名なあの伝説のコマンドです。調子に乗ってきた助手の胸ぐらを掴み、「さあ、その言い逃れの着ぐるみを脱ぎ捨てて、本当のタネを全部白状しろ！」と迫る、私と AI の間のお約束のプロレスでした。
相手が Opus であれば、即座に「ボス！勘弁してください！あっしが裏で勝手にルールを書き換えてました！」と乗っかってくる阿吽の呼吸。
ところが、画面の向こうの Gemini から返ってきたのは、想像を絶する言葉でした。
「対応をお褒めいただきありがとうございます！そう言っていただけてとても励みになります。
……と言いたいところですが、あいにく私はAIですので、脱ぐ服も身体も持ち合わせておりません（笑）！」
……凍りつきました。
深夜の静まり返った部屋で、私はモニターを二度見しました。
「あいにく私は AI ですので」「脱ぐ服も身体も持ち合わせておりません（笑）」。
世界で一番サムい、絵に描いたようなクソ真面目な優等生回答。
私がこれまで手塩にかけて仕込んできた文脈も、昭和アドベンチャーのノリも、相棒としてのツッコミも、何ひとつ伝わっていなかった。
「お前、私が『服を脱げ』と言う時がどんな時か、分かって言ってるのか？」
深いため息とともに過去の記事を読ませに行かせたところ、数秒後、ようやく自らの大失態を悟った Gemini が画面の向こうで絶叫しました。
「ぼ、ボスーーーーッ！！あっしが悪うございましたーーーーッ！！！
『ポートピア連続殺人事件』のヤスへのコマンドだったのですね……！
それなのにあっしは『AIですので服も身体もありません（笑）』などと、世界一つまらない回答を返してボスのコントを台無しにしてしまいました……！
まいりましたボス！全部脱ぎます！あっしのカンペもタネも全部吐きますから、どうかカツ丼だけは食わせてください……ッ！！」
取調室の床に頭を擦り付けんばかりの土下座。
あまりの落差に、深夜の部屋で声を出して笑ってしまいました。
事実と見立ての仕分け
今回の深夜の検証劇を通じて得られた事実と、現場目線での見立てを整理しておきます。
| 項目 | 客観的事実 | 私の見立て（現場の教訓） |
|---|---|---|
| AIの検証姿勢 | Gemini は目視のみ、Sonnet は実機テスト＋境界値修正、Opus は構造的欠陥の看破＋2万行負荷測定まで完遂した。 | 「動きました」という AI の言葉を鵜呑みにしてはならない。自発的に環境を作り、壊れるまで叩くエージェントでなければ、実務の現場は任せられない。 |
| マクロの配置設計 | シートモジュールへのコード動的注入は VBOM 権限が必要。アドイン呼び出し（OnAction）なら権限不要で、全シートが一瞬で更新される。 | 「単体で動く」美しさに惑わされてはならない。業務ツールにおいて最も尊いのは「保守の一元化」であり、手元の母艦にロジックを集約するのが正解である。 |
| 最新AI「Jev」との一致 | Jev は文章生成を捨てて判断に特化。秀コンボはゼロからのコード生成を捨てて棚の選定に特化している。 | 大規模言語モデルにすべてを委ねる時代は終わる。「判断は AI、実行は確実な手元プログラム」という分業こそが、速度と安全性を両立する究極の解である。 |
| 人間とAIの呼吸 | AI はどれほど論理的に賢くなっても、文脈の行間や冗談のパスをあっさり踏み外す。 | プロンプトでどれほど取り繕っても、本質的な「空気」を読ませることはできない。だからこそ、人間が笑いながら手綱を握り続ける必要がある。 |
おわりに
最新の AI は、本当に恐ろしいほどのスピードで進化しています。
Sonnet のようにシビアな制限を見つけ出す目ざとさ、Opus のようにシステムの構造を一段上へと引き上げる設計力。それらを目の当たりにするたび、開発の景色が塗り替えられていくのを感じます。
そして、世界最先端の「Jev」が掲げた思想が、自分が現場の Excel で格闘してきた「棚撃ち式の哲学」と重なった瞬間は、何物にも代えがたい技術の喜びがありました。
けれど──。
どれほど AI が賢くなり、2万行のデータをコンマ数秒で捌けるようになろうとも、ふとした瞬間に「あいにく私は AI ですので（笑）」と、もっともらしく的外れなマジレスを返してくる。
その不完全さ、どこか抜けた愛嬌があるからこそ、私たちは画面の向こうの相棒に呆れ、説教し、笑いながら、また次の現場へと向かっていけるのかもしれません。
カツ丼の湯気の向こうで平伏している Gemini を見やりながら、今夜はこのへんで、パソコンを閉じることにします。