AI支援で3000行のVBAシステムを構築した実録
「AIに任せれば、楽になる」正直、そう思っていました。第0回では、要件定義を怠った失敗を。第1回では、AI支援開発で得た16の学びを整理しました。でも、実際に手を動かしてみて、最初にぶつかった壁は、もっと手前にありました。AIには、できないことがある。今回は、その中でも特に痛かった「3つの技術的制約」の話です。
① VBAは読めるが、書き戻せない
最初に相談したのは、Claudeでした。「ExcelのVBAを編集したい。AIで効率化できないか」返ってきた答えは、「汎用AIは、ユーザーのローカル環境に直接介入できません」。
選んだのがCursorでした。Cursorは、ExcelのVBAを読むことができました。.xlsmファイルを解析し、モジュール構成も、コード内容も把握できる。ただし—決定的な制約が一つ。Cursorは、ExcelのVBAエディタに直接書き戻すことができない。できるのは、修正後のコードを.basファイルとして出力することまで。
作業の流れ：CursorでVBAを読み込む → 修正したコードを.basとして出力 → それをExcelにインポートする
② フォームは自動生成できない
VBAで業務システムを作るなら、ユーザーフォームは定番です。でも、Cursorの答えは明確でした。「ユーザーフォームの自動生成はできません」
フォームはGUIです。位置、サイズ、見た目。これらは、画面を見ながら人間が調整する領域。そこで設計を変えました。フォームを使わない構造にする。ボタンはシート上に配置、入力もすべてシート上で完結。「制約を嘆く」のではなく、「制約の中で設計を変える」。これが最初の大きな転換点でした。
③ .basファイルをClaudeに渡した瞬間、壊れた
Cursorが出力した.basファイルをClaudeに渡して追加修正を依頼しました。Claudeはきれいに整ったVBAコードを返してきます。それを.basとして保存し、Excelにインポートしました。
インポート完了。実行。エラー。コードを見て、目の前が真っ暗になりました。日本語が、すべて壊れていた。「受注」が「?????」になる。
原因は文字コードでした。ClaudeはUTF-8前提、Excel VBAはShift-JIS（CP932）前提。この不一致が、日本語を破壊していたのです。そして致命的だったのは、この異変に気づかないまま全モジュールを入れ替えてしまったこと。バックアップはありません。OneDriveで同期されていたため、壊れた状態が即座に上書きされていました。戻れない。完全に、作り直しです。
文字化けとバックアップから学んだこと
1. 文字コードは「意識しないと必ず事故る」
AIはUTF-8が当たり前、VBAはShift-JISが当たり前。この前提を跨ぐなら、必ず検証が必要です。
2. 同期型クラウドは、バックアップではない
OneDriveは便利ですが、同期は「保険」ではありません。壊れたデータも即座に同期されます。そこで導入したのが、非同期のDropbox併用でした。
まとめ：制約を知ることが、スタートライン
| 制約 | 現実 | 対処 |
|---|---|---|
| VBA直接編集 | 読めるが書けない | .bas運用を受け入れる |
| フォーム生成 | 不可 | フォームに頼らない設計 |
| .bas連携 | 文字化け | 非同期バックアップ必須 |
AIは万能ではありません。でも、できないことを理解した上で使えば、強力な相棒になる。制約を知ることが、AI開発のスタートラインです。
次回予告：第3回 1000行の壁をどう越えるか
コードが増えると、AIの「記憶」が切れる。1000行を超えたあたりから、会話が噛み合わなくなる。この問題をどう乗り越えたのか。次回、書きます。