Excelのボタン付きマクロが突然動かない事例を整理する（Windows 11・保存形式差）
業務で使うExcelファイルは、前日まで動いていたマクロが当日に動かなくなることがあります。本記事の対象となる事象は、シート上のボタンをクリックしても処理が起きず、マクロ設定やVBA（Visual Basic for Applications：ビジュアル・ベーシック・フォー・アプリケーション）コード上のエラーも見当たらない状況です。さらに、元データ状態のファイルを「名前を付けて保存」で .xlsm などにしたところ、ボタンが反応しなくなり、マクロ自体が登録されていなかったという条件が付いています。つまり「見た目は同じでも、保存の経路と中身が一致していない」点が中核の論点になります。
事象の概要と、発生→展開の流れで見える共通点
業務開始時に、普段開いているExcelファイルが閉じられていたため、デスクトップから再度開いたところ、シート上のボタンを押しても動作しない、という流れが示されています。マクロが無効になっているわけではなく、VBAコードを見てもエラーは確認できない、という整理です。一方で、当日の朝に実行して印刷した紙が残っており、直前までは動いていた可能性が残ります。
この種の事象は、ファイル自体が「同じ名前・同じ見た目」に見えても、参照している実体が差し替わっている場合に起きやすいです。たとえば、ショートカットの参照先変更、別フォルダの同名ファイル、バックアップからの復元、共有環境での上書き保存などが重なると、ユーザー側の操作感としては「何も変えていない」状態になります。そのため、コードが正常でも「ボタンが呼び出す先」が別物になっている構図が成立します。この問題は「ボタン→割り当て先マクロ→VBAプロジェクト」の連鎖がどこで切れたかを追うのが実務上の確認点となります。
「名前を付けて保存」で .xlsm にしても、マクロが残らないケースの構造
補足として示されている再現条件は重要です。元データ状態のファイルを「名前を付けて保存」して .xlsm などにしたところ、ボタンを押しても動作せず、さらにマクロが登録されていなかった、という結果になっています。ここから、当該ファイルは「元データ側にVBAプロジェクトが存在しない」か、または「保存元がマクロを保持できない経路」だった可能性が上がります。
Excelでは、拡張子が .xlsm（マクロ有効ブック）であっても、保存時点でVBAプロジェクトが入っていなければ、マクロは増えません。言い換えると、拡張子は“入れ物の種類”であり、“中身の有無”を保証しません。また、元データが .xlsx（マクロ非対応ブック）で、別ファイルにあるマクロを前提に運用していた場合、元データだけを .xlsm 化しても、マクロは移りません。さらに、ボタンが「別ブックのマクロ」を割り当てていた運用だと、対象ブックを開き直した瞬間に割り当て先が見つからず、押しても反応しない形になり得ます。この結果からは「拡張子変更」ではなく「VBAプロジェクトと割り当て情報の継承」が論点になります。
ボタンが反応しない原因を、部品別に切り分ける観点
ボタンが反応しない状況は、コード不具合以外にも複数の層で発生します。大きくは①ボタンの種類、②割り当て、③マクロの所在、④実行が止められる設定、の4層です。ボタンは「フォームコントロール」と「ActiveXコントロール」で挙動が異なり、特にActiveXは環境依存要素が増えます。また、ボタンがシート保護・ブック保護の影響を受ける構成もあります。
要点を整理すると、ボタン自体が押せていても「割り当て先が空」「別ブックを参照」「プロジェクトが存在しない」などの理由で無反応になります。さらに、VBA側でブレーク状態（停止状態）になっている、またはイベント停止が有効になっていると、クリックが処理につながらないことがあります。ただし、ここは「エラーが出ない」まま起きるため、現象としては原因が見えにくい部類です。
なお、実務では下表のように層を分けると整理しやすくなります。
| 切り分け層 | 起きる現象 | 代表的な確認点 | 影響範囲 |
|---|---|---|---|
| ボタン種類 | 押しても反応しない | フォーム/ActiveXの別 | 端末差が出る |
| 割り当て | クリックで何も起きない | 割り当てマクロ名の有無 | ファイル単位 |
| マクロ所在 | マクロ一覧に出ない | VBAプロジェクトの有無 | ブック単位 |
| 実行制御 | 動作が止まる | 保護/停止状態/設定 | セッション単位 |
以上を踏まえると、ボタンの「見た目」ではなく、割り当てとマクロ所在を同時に確認することが判断材料として重要です。
Windows 11アップデート後も動いていたのに、当日だけ崩れた可能性
本記事が示す状況では「昨年のWindows 11アップデート後から、このファイルは .xlsm で動作していた」という経緯が述べられています。一方で、当日に閉じられていたファイルを開き直したところ動かないため、「アップデート＝直因」とは限りません。この点から、アップデートは“条件を変えた背景”として残しつつ、当日の変化点を探すのが整理の筋になります。
アップデートやセキュリティ更新は、マクロの実行条件に影響することがあります。たとえば、保護ビュー（Protected View：保護された表示）や、インターネット由来ファイルのブロック（Mark of the Web：ダウンロード由来印）などが絡むと、同じファイルでも保存場所や取得経路で挙動が変わります。また、社内共有からコピーされたファイル、メール添付から復元されたファイルなどは、同名でも属性が異なる場合があります。したがって「昨日まで動いた」という事実があっても、当日に開いた個体が別であれば説明がつきます。
他方で、ActiveXコントロールは更新やOfficeの状態差で動作が変わる余地があるため、ボタン種別がActiveXの場合は環境要因を広めに見ます。ここは断定しにくい領域ですが、条件差が生じる可能性がある、という位置づけになります。この論点では「当日開いたファイルの出所・属性・保存場所」が、直接原因の特定に近い情報になります。
実務での確認順序と、再発を防ぐための運用整理
最終的に原因が「元データを .xlsm 化したが、マクロが登録されていなかった」という整理に落ちた場合、実務上は“正しいマクロ入りの原本”が別に存在する前提が強まります。つまり、運用としては「元データ」と「マクロ実装ブック」が分離していた、または途中で統合が崩れた可能性を扱うことになります。そうすることによって、ボタンが呼ぶ処理が存在しない状態が説明できます。
切り分けの順序としては、まず「マクロ一覧に対象が出るか（所在）」、次に「ボタンに割り当てがあるか（紐付け）」、その次に「ボタン種類と保護・設定（実行制御）」を当てます。さらに、ファイルが複数ある場合は「ファイル名ではなくフルパスと更新日時」で同一性を確認します。ここを飛ばすと、同名別物を追ってしまい、調査が長期化します。なお、確認手順を文書化して共有すると、夜間作業や引き継ぎが挟まっても、判断の基準が揃います。
再発防止の観点では、原本の保存場所を固定し、配布する場合は「コピー運用」と「編集権限」を分ける設計が残ります。また、マクロを含むブックはテンプレート（.xltm：マクロ有効テンプレート）として管理し、元データを読み込むだけに寄せる構成もあります。どの方式でも、運用上の確認点となるのは「どのファイルがマクロの正本か」を明示することです。最後に、文章内の表記としては「保存がほぞん経路で変わる」点があるため、保存操作のルールを固定しておくと差分が減ります。言い換えると、技術設定よりも「正本管理」と「ファイル個体の同一性確認」が、最も効果の出やすい整理になります。
