やっぱり、Claude Code で ExcelVBA のコーディングをしてもらっても、品質があまりよくない。

しかしそれでも、いろいろと工夫した結果、次のような方法に落ち着いた。
まず、

「マクロファイルを直接のぞかせるのではなく、モジュールをすべてエクスポートしておく」

マクロファイルを直接のぞかせて、直接編集させると、ボロボロになる。
最悪、マクロファイルが壊れる。

「モジュールをエクスポートしたあと、文字コードを UTF-8 に変更する」

エクスポートした直後の文字コードは、Shift-JIS。
これをそのまま修正させると、文字化けが発生するケースが多々ある。
そのため、エクスポートしたモジュールは、必ず UTF-8 に変換することをお勧めする。
その際、モジュールの先頭にある「Attribute ...」の部分は削除しておく。
（最終的に、このモジュールファイルを VSCode などのエディタで開き、コピペでマクロファイルに反映するため）

「VSCode に修正させたファイルは、エクスポートしたファイルにそのまま上書きしない」

Claude Code が修正に失敗し、取り返しがつかないくらいボロボロになった場合を想定し、エクスポートしたファイルにそのまま修正させない。
Claude Code に修正させたファイルは、別フォルダに出力させる。
しかもこの方が、どのモジュールを修正したかが判別でき、どのモジュールを ExcelVBA にコピペするのかわかりやすい。

「Claude Code の修正を信用しない」

これは特に ExcelVBA に限ったことではないが、AI が作ったものをそのまま信用しない。
ひととおり、ざっと目を通すことをお勧めする。
よくあるのが、ExcelVBA の予約語を変数名にして、コンパイルができないケース。
empty() という配列を作りたがるが、empty は予約語のため、これをそのまま変数名にしていまったらコンパイルができないのは当然だ。

とはいえ、ここまでしても、やはりプログラムは自分で組むより、Clade Code に依頼した方がはるかに楽だ。
当初、「ExcelVBA だけはまだまだ人の手でやった方が安心」と思っていたが、AI がコーディングしやすいようにいろいろと模索してでも、コーディングは AI にしてもらうべきだ。