「昨日まで動いていたマクロが、今日になったらエラーで止まった…」そんな経験はありませんか？
特に、SeleniumやChromeDriverを使ってVBAでChromeを自動操作している方は要注意です。
原因はコードではなく、Chromeのバージョン更新やセキュリティ仕様の変更。
つまり「外部要因による突然の停止」が起きやすい仕組みなんです。
今回は、Chrome操作VBAが抱える代表的なリスクとその対処法を、EXCEL女子がわかりやすく解説します。
VBAでChromeを操作するときに多いトラブルは、実はどの現場でも似ています。
「昨日まで動いていたのに突然止まった」── その背景には、環境依存による典型的な落とし穴があるのです。
ここでは、多くのユーザーが直面する『よくある3つのリスク』をまとめてご紹介します。
業務でよくあるのが、「昨日まで普通に動いていたマクロが、今日いきなりエラーになった」というケース。原因を探ってみると、実は Chromeが自動更新されて新しいバージョンになっていた ということが非常に多いです。
しかもやっかいなのは、ユーザー側で「更新しない」と設定できない点。
業務開始の朝に突然マクロが止まり、慌てて原因を探すことになりがちです。
大切なレポート提出前や請求業務など、業務のボトルネックになるリスクが潜んでいます。
ChromeDriverを定期的に更新する（バージョン管理をルーティン化する）
自動更新を見越して、ドライバを自動ダウンロードするスクリプトを組み込む
更新の影響をいきなり本番で受けないように、検証用PCや仮想環境で事前テストを行う
VBAでChromeを操作する場合、多くの方が SeleniumBasic + ChromeDriver の組み合わせを使っています。
便利で強力な方法ですが、実はここに大きな落とし穴があります。
なぜなら、複数の部品に依存しているからです。
Seleniumのバージョン
ChromeDriverのバージョン
Chrome本体のバージョン
さらにWindowsの更新状況や64bit/32bit環境の違い
これらがすべて“うまく噛み合って”はじめて、VBAマクロが正常に動作します。
そのため、どれかひとつでもズレると、突然マクロが動かなくなるのです。
問題は、止まったときに 「原因がどこにあるのか特定しづらい」 こと。
調査に時間がかかり、復旧までに丸一日かかってしまった…という声も少なくありません。
つまり、ライブラリ依存型のVBAは壊れやすく、直すのも大変なのです。
依存している ライブラリやバージョンの一覧を管理しておく
「動作していた環境」をそのまま保存するために、仮想マシンやバックアップ環境を用意する
本番マクロとは別に「検証用マクロ」を作り、更新の影響を切り分ける
将来的には、RPAツールやPower Automate Desktopなど、保守性の高い仕組みへの移行を検討する
さらに、多いのがログイン処理が急に動かなくなるケースです。
「昨日までは自動でログインできていたのに、今日からはIDとパスワード入力の画面で止まってしまう…」という声は、現場でも本当によく聞かれます。
その背景にあるのは、ブラウザ側のセキュリティ強化です。
こうした仕様変更はユーザーを守るための重要なアップデートですが、VBAによる自動操作にとっては“障害”になってしまいます。特に金融機関や大手ポータルサイトのようにセキュリティレベルが高いサービスでは、自動入力が完全にブロックされることも珍しくありません。
その結果、マクロはログイン画面で停止し、先に進めなくなるのです。
業務で毎日使っていた「データ取得マクロ」や「帳票ダウンロードマクロ」が動かないと、手作業に戻らざるを得ず、業務効率が大きく下がってしまいます。
ログイン処理は手動で行い、その先を自動化する形に割り切る
可能なら、公式APIを利用してログインレスでデータ取得できるようにする
どうしてもVBAでログインする必要がある場合は、仕様変更があっても修正しやすいコードにしておく
中長期的には、Power Automate DesktopやRPAツールに切り替え、サポートが続く仕組みを選ぶ
VBAでChromeを操作する仕組みは、とても便利で業務効率を高めてくれる一方で、『外部環境に強く依存する』という特性を持っています。
こうした対策をしておけば、「突然止まる」という不安を最小限に抑えることができます。
大切なのは、『完成したら終わり』ではなく『運用しながら育てていく』という発想でマクロを扱うことです。