VBAエラー1004が消えない本当の理由──「マクロの記録」から卒業したら安定した話

「実行時エラー1004」。Excel VBAを触ったことのある人なら、一度は見たことがあるはずのエラーです。介護施設の勤務表・配車表の自動化を進める中で、このエラーに繰り返し悩まされた経験をお持ちの方も多いのではないでしょうか。

原因を突き詰めていった結果、たどり着く結論はコードの細部の問題ではないことがほとんどです。そもそもの書き方の癖、「Select依存」が諸悪の根源だったという話をします。

なぜSelectに頼ってしまうのか

VBAを独学で始めた人の多くは、「マクロの記録」機能から入ると思います。マクロの記録が生成するコードは、Range("A1").SelectしてからSelection.Value = ...のように、「セルを選択して、選択したものに対して操作する」という形になっています。人間の手操作をそのまま再現しているので、直感的には分かりやすい書き方です。

問題は、この書き方が「今どのシートがアクティブか」「今何が選択されているか」という実行時の状態に依存していることです。

エラー1004が出るときの典型パターン

Select依存のコードは、次のような状況で簡単に壊れます。

• マクロ実行中に別のシートがアクティブになっていた
• 複数のブックを開いていて、想定と違うブックが前面にあった
• 処理の途中でシートを切り替える処理を追加したら、後続のSelectが空振りするようになった

つまり、コード自体は同じでも「実行したときの画面の状態」によって動いたり動かなかったりする。テストでは動いたのに本番で落ちる、自分の環境では動くのに他の人のPCでは落ちる、という再現性のない不具合の温床になります。勤務表マクロのように複数シート・複数ブックをまたぐ処理では、この不安定さは致命的です。

改善:「手操作の再現」から「オブジェクトの直接操作」へ

対策はシンプルで、対象のWorkbook・Worksheet・Rangeを明示的に指定する書き方へ寄せることです。「A1セルを選択して、選択したセルに書き込む」ではなく、「このブックのこのシートのA1セルに書き込む」と直接指定する。選択という工程を経由しないので、画面の状態に左右されません。

この書き方に切り替えると、副次的なメリットもあります。画面上でセルの選択が動き回らないので処理が速くなり、見た目もチカチカしなくなります。そして何より、コードを読んだときに「どのシートのどこを操作しているのか」が明確になるので、後から見返したときの理解が段違いに楽になります。

「マクロの記録」は入口としては最高、出口としては危険

誤解のないように言うと、マクロの記録は素晴らしい学習ツールです。「この操作はVBAでどう書くのか」を調べる辞書として活用する場面は今でも多いはずです。

ただ、記録されたコードをそのまま業務システムに組み込むのは危険です。記録されるコードはあくまで「その瞬間の手操作の再現」であって、毎月・複数人・複数環境で安定して動くことを想定した作りにはなっていません。記録で書き方を学び、実装ではSelectを消す。 この使い分けができるようになると、エラー1004との付き合いは大きく変わります。

生成AIにVBAを書いてもらう場合も同じです。「Selectを使わず、対象を明示的に指定する形で」と一言添えるだけで、出てくるコードの安定性が変わります。もし今、原因不明の1004に悩まされているなら、コードの中のSelectとSelectionを数えてみてください。それが多いほど、たぶんそこが原因です。

AI介護士kaze運営者。介護福祉士・ケアマネジャー・社会福祉士の資格を持ち、介護現場歴18年。現場のリアルな課題感を起点に、AI×介護の実用性を探求・発信しています。