直らないバグ"に向き合った話 ― VBAのマウスフック再入問題

前回、専任のIT担当がいない環境で、3人で使う在庫管理システムをExcel VBAで内製した経緯を書きました。
今回はその中で一番手こずった、原因不明のクラッシュについて詳しく書きます。

VBAでシステムを作ったことがある方なら、一度は経験があるかもしれません。
「特定の操作をしたときだけ、何の前触れもなくExcelが落ちる」という現象です。
今回向き合ったのは、まさにこのタイプの不具合でした。結論から言うと、原因は自分自身が仕込んでいた、ある便利機能の中に隠れていました。

前回書いた通り、このシステムはまだ導入されたばかりで、同僚2人にとっては「使い慣れていない新しいツール」でした。
そこで頻繁にクラッシュが起きると、「やっぱり前のExcelファイルのままの方が安心だったのでは」という空気が生まれかねません。
原因を突き止めて直すことは、機能の問題であると同時に、システムへの信頼を保てるかどうかの問題でもありました。

何が起きていたか

大量のデータを一括で処理する機能を使っているときに限って、Excelが突然「Microsoft Excel は動作を停止しました」という画面とともに落ちる、という不具合が起きていました。

厄介だったのは、毎回同じ操作で必ず再現するわけではなかったことです。
ある日は問題なく処理が終わるのに、別の日は同じボタンを押しただけで落ちる。
データ量が多いときに起きやすい、という傾向はうっすら感じていましたが、それだけでは説明がつかない場面も多く、原因の見当がまったくつきませんでした。

3人が使っている端末のスペックがバラバラだという話は前回書きましたが、今回のクラッシュもその影響ではないかと最初は疑いました。

特に古い端末で発生頻度が高いように見える瞬間もあったからです。
ですが、結論から言うと、これは大きな勘違いでした。

原因究明の過程

最初に疑ったのは、単純にデータ量が多すぎて処理が重くなり、メモリ不足で落ちているのではないか、ということでした。
処理を分割してみたり、変数の型を見直してみたりしましたが、症状は変わりません。

次に疑ったのは、Excelファイル自体の破損でした。
ファイルを作り直してみたり、不要な書式設定を消してみたりもしましたが、これも効果はありませんでした。

その次に疑ったのは、各PCに入っているウイルス対策ソフトとの相性でした。
バックグラウンドで動いている常駐ソフトが、VBAの処理に何か干渉しているのではないかと考え、一時的に監視を止めて試したこともあります。
ですが、これも症状の改善にはつながりませんでした。
振り返ると、原因とは無関係なところをずいぶん遠回りしていたことになります。

Windowsのイベントビューアーでエラーログを確認したこともありました。
クラッシュのタイミングと一致するエラーは記録されていたものの、
そこに書かれていたのはExcel本体が異常終了した、という結果だけで、
なぜ異常終了したのかという原因までは読み取れませんでした。

原因を絞り込むために、処理の主要なステップごとにログを書き出すようにもしました。
「どこまで実行されて、どこで止まったか」を記録に残せば、
次にクラッシュしたときに手がかりが得られると考えたからです。
ですが、ログを見返しても、クラッシュする直前の処理内容はいつもバラバラで、共通点が見つかりませんでした。

正直、この時点で「Excelがおかしいだけで、直しようがないのでは」と半分あきらめかけていました。
ただ、クラッシュするタイミングをよく観察していると、あるパターンに気づきました。
処理中にマウスを動かしたり、ホイールを回したりしたときに、クラッシュする確率が上がっているように見えたのです。
処理内容ではなく、操作のタイミングに目を向けたのは、このときが初めてでした。

原因:マウスフックの再入問題

この気づきをきっかけに調べていくと、システムの中に仕込んでいた「マウスフック」の仕組みが原因だとわかりました。

もともとこのシステムでは、標準のリストボックスがマウスホイールでのスクロールに対応していないという問題がありました。
これを解決するために、WindowsのAPIを使ってマウスの動きを監視する「WH_MOUSE_LL」というフックを仕込んでいたのです。
マウスホイールが回されたことを検知して、リストボックスの表示をスクロールさせる、という仕組みです。
現場からの「マウスホイールでスクロールしたい」という小さな要望に応えるために入れた機能でした。

問題は、このフックが「いつでも割り込んでくる」仕組みだったことです。
VBAは基本的にシングルスレッドで動いていて、1つの処理が終わるまで次の処理は待たされるのが前提になっています。
ところが、大量データを処理している最中にマウスが動かされると、このフックが処理の途中に割り込んできてしまいます。
まだ終わっていないはずのVBAの実行環境の中に、もう一つの処理が入り込んでしまう。
いわゆる「再入（リエントランシー）」と呼ばれる状態です。

VBAの実行環境は、こうした再入を想定して作られていません。
結果として内部の状態が矛盾を起こし、Excelごと強制終了してしまっていた、というのが実際に起きていたことでした。
データ量が多いときほど処理時間が長くなり、その間にマウスが動く確率も上がるため、「データ量が多いときに起きやすい」ように見えていたのも、これで説明がつきました。

たとえるなら、
1人の作業者が伝票を1枚ずつ処理している途中に、
別の人が「ちょっとこれも今すぐお願い」と横から割り込んできて、
同じ机の上で作業がぐちゃぐちゃになってしまうようなイメージです。

VBAは「1人の作業者が、1つの作業を最後まで終わらせる」ことを前提に動いているので、途中で割り込まれることをまったく想定していませんでした。

解決方法

原因がわかれば、対処自体はシンプルでした。
重い処理に入る直前でマウスフックを一時的に解除し（UnhookWindowsHookEx）、
処理が終わったタイミングで再度フックをかけ直す（SetWindowsHookEx）、
という形にしました。処理中はマウスホイールでのスクロールが一時的に効かなくなりますが、クラッシュするよりはるかにましです。

この修正を入れてから、同じ症状のクラッシュは一度も起きていません。
修正後は、わざと処理中にマウスを激しく動かしたり、ホイールを回し続けたりしながら何度も動作確認を行いました。
何週間も原因がわからなかった不具合が、直してみると数行のコード追加で収まった、という拍子抜けするような結末でした。

この経験から学んだこと

一番の学びは、「再現しない不具合ほど、操作のタイミングを疑う」ということです。
データ量やコードの中身ばかりを疑っていた間は、まったく原因にたどり着けませんでした。
「何をしていたときに起きたか」という、操作側の情報に目を向けてから、一気に糸口が見えてきました。

もう一つは、便利にするための工夫が、思わぬ形で足を引っ張ることがある、という点です。
マウスホイールでのスクロールという、現場の小さな要望に応えるために入れた仕組みが、まさかシステム全体を不安定にする原因になるとは思っていませんでした。
機能を足すときは、それが他のどの処理と同時に動く可能性があるか、少し立ち止まって考える必要があるのだと感じています。

これ以降は、重い処理を書くたびに「この処理中にユーザーが何か操作したらどうなるか」を意識して確認するようにしています。
実際に処理中にマウスを動かしたりキーボードを触ったりしながらテストする、という手順も、この一件から加わった習慣です。

専任のIT担当がいない環境では、こうした地道な確認作業を自分自身で積み重ねていくしかないのだと、改めて感じさせられた出来事でした。

原因がわかった後、同僚2人にも「なぜ落ちていたのか」「もう起きないのか」を、専門用語をできるだけ使わずに説明しました。
原因を隠さずに共有したことで、逆に「ちゃんと直してくれる人がいる」という安心感につながったように思います。
不具合そのものより、不具合にどう向き合っているかの方が、使う人にとっては大事なのかもしれません。

こんな方に読んでいただけたら

• VBAで「再現しない不具合」に頭を悩ませている方

• Windows APIを使ったマウス・キーボードフックをVBAやExcelに組み込んでいる方

• 「原因不明のクラッシュ」の切り分け方を知りたい方

さいごに

次回は、GitHub Pagesへの反映が遅く、作業が止まってしまっていた問題を、非同期処理で解決した話を書く予定です。

同じように、原因不明の不具合に頭を悩ませている方の参考に少しでもなれば嬉しいです。