サポート切れのExcelマクロを、作り直さずに動かし続ける方法

Excel VBA / Office のバージョンアップ対応

「お使いの Office はサポートが終了しました」という通知が届いた。あるいは、社内から「パソコンを入れ替えるので Office も新しくなります」と言われた。そのとき最初に頭をよぎるのは、毎日動いているあのマクロはどうなるのかということだと思います。

結論から書きます。ほとんどの場合、作り直す必要はありません。 修正が必要なのは全体のごく一部で、多くは決まったパターンに収まります。問題は「どこを直せばいいかが分からない」ことであって、「直せない」ことではありません。

まず、2種類の「サポート切れ」を区別する

同じ「サポート切れ」でも、意味がまったく違う2つが混ざって語られています。どちらなのかで、緊急度も対応も変わります。

つまり、更新を実行する前に調べておけば、止まる前に手を打てます。 逆に、何も調べずに全社一斉に Office を入れ替えると、翌朝に業務が止まります。これが最も避けたい事態です。

Office を新しくしたときに、実際に何が起きるか

1. 64bit 版になった瞬間に、まったく起動しなくなる

最近の Office は 64bit 版が既定です。そして古いマクロの多くは、 Windows の機能を直接呼び出す「API 宣言」という記述を含んでいます。

この記述が Declare Function ... で始まっていて、 PtrSafe という語を含んでいない場合、64bit 版 Office ではコンパイルエラーになり、マクロが1行も動きません。一部の機能が使えないのではなく、全体が起動しません。

症状としては「実行時エラー」ではなく、開いた瞬間の「コンパイルエラー」として現れます。これは比較的直しやすい部類で、宣言部分に PtrSafe を追加し、一部の型を調整するだけで済むことが大半です。

2. 削除された命令を使っている

Office のバージョンアップに伴い、いくつかの命令は完全に削除されました。代表的なものが Application.FileSearch で、これは Office 2007 の時点で削除されています。使っていれば必ずエラーになります。

古いマクロがまだ動いているということは、逆に言えば そのパソコンだけ古い Office が残っている可能性があります。その1台が壊れた時点で業務が止まるので、優先度は高いと考えてください。

3. 参照設定が外れる

マクロが外部の部品（カレンダーのコントロール、帳票ツール、データベース接続用の部品など）を使っている場合、新しい環境にその部品が入っていないと「参照不可」の状態になります。

この場合の症状が厄介で、まったく関係のない行でエラーが出ます。 「なぜここでエラーになるのか分からない」という状態は、まずこれを疑います。

4. 保存形式が変わって、マクロが消える

これが最も取り返しのつかない失敗です。マクロを含むファイルを .xlsx 形式で保存すると、マクロは警告一つで消えます。 そして上書き保存してしまえば、元には戻りません。

新しい Office で開いて「はい」を押し続けた結果、マクロが消えたというご相談は実際にあります。後述する保全の手順を、必ず先に済ませてください。

作り直さずに動かし続けるための手順

手順1: 触る前に、現物を保全する

何よりも先にこれをしてください。調査も修正も、その後です。

• 対象のファイルを別の場所にコピーする。上書きではなく、日付を付けた別名で
• コピーを読み取り専用にする（ファイルを右クリック → プロパティ → 読み取り専用）
• そのコピーには絶対に触らない。作業は必ず別のコピーで行う
• ファイルが複数の場所に散らばっている場合、どれが最新かを確認してから保全する

「調べるだけだから」と本番のファイルを開くのは避けてください。 Excel は開いただけでファイルの一部を書き換えることがあります。

手順2: 何が壊れるのかを、更新前に洗い出す

確認したいのは次の点です。ご自身で調べる場合も、この順で見ていくと漏れが減ります。

• Declare で始まる行があり、PtrSafe が付いていないもの
• 共有フォルダやサーバのパスが、コードの中に直接書かれている箇所
• 他のブックやファイルを開いている箇所（そのファイルは今も同じ場所にあるか）
• データベースへの接続文字列（接続先は今も稼働しているか）
• 特定のプリンタを指定している箇所

ここで挙がった箇所の数が、そのまま環境を変えたときの修正箇所の数になります。移行の工数は、ほぼこの数で決まります。

手順3: 修正は最小限にとどめる

ここが最も重要なところです。古いコードを見ると「ついでに整理したい」と思うのが人情ですが、 動いているものに手を入れる範囲は狭ければ狭いほど安全です。

20年動いてきたコードには、誰も覚えていない例外処理が必ず入っています。「この得意先だけ締め日が違う」「この商品だけ税率の扱いが違う」といった条件分岐は、一見すると無駄な処理に見えます。消すと、翌月の締めで発覚します。

今回の目的は「新しい環境で動くようにすること」であって、「コードをきれいにすること」ではありません。この2つを同時にやると、不具合が出たときにどちらが原因か分からなくなります。

手順4: 動作確認の手順を、先に作る

修正してから「たぶん大丈夫でしょう」で本番に戻すのは危険です。修正の前に、「これができれば正常」と言える確認手順を書き出しておいてください。

難しいものである必要はありません。「先月分のデータで実行して、出てくる合計が先月の帳票と一致すること」で十分です。 修正前の状態でも一度実行して、同じ結果になることを確認しておくのがこつです。そうすれば、差が出たときに修正が原因だと切り分けられます。

期限が迫っている場合の優先順位

入れ替えの日程が決まっていて時間がない場合は、次の順で手を付けてください。

1. 保全。これだけは何があっても先に済ませる。5分で終わります
2. 止まったときに業務がどうなるかの確認。手作業で代替できるなら、多少の停止は許容できます
3. 古い環境を1台だけ残せないかの検討。1台残せれば、期限そのものがなくなります
4. コンパイルエラーになる箇所の修正。全体が起動しなくなる原因なので最優先
5. その他の不具合対応

3番目は見落とされがちですが、現実的な選択肢です。「入れ替え対象から1台だけ外し、そのマクロ専用機として残す」という判断は、費用対効果の面でしばしば最も合理的です。恒久策にはなりませんが、落ち着いて対応するための時間を買うことができます。

ご自身で判断が難しい場合

ここまでの内容を、ファイルを見ずに社内で判断するのは簡単ではありません。どこに何が書かれているかが分からないから困っている、というのが実際のところだと思います。