この記事で分かること
- 一部のPCでのみExcelマクロが動かなくなる4つの主要原因
- 32bit版と64bit版のOfficeが混在する環境でのVBA記述の修正方法
- 参照設定の「参照不可（MISSING）」を解決・予防するためのコード書き換え手順
- セキュリティブロックや警告を解除し、安全に実行させるための具体的設定
特定のPCだけでExcelマクロが動かない4大原因
これまで問題なく動作していたExcelマクロが、特定のPCに移動した途端に動かなくなる場合、マクロのプログラム（コード）自体に欠陥があるわけではありません。多くの場合、実行するPCごとの「Excelを取り巻く環境の差異」がエラーを引き起こしています。主な原因は、大きく以下の4つに分類されます。
| 主な原因 | 発生する現象・症状 | 主な対策 |
|---|---|---|
| Officeのビット数差異 | 「コンパイルエラー：このシステムのコードは、64ビットシステムで使用するために更新する必要があります」と表示される。 | Declare文にPtrSafe属性を追加し、データ型を適切に変更する。 |
| 参照設定の不整合 | 「コンパイルエラー：プロジェクトまたはライブラリが見つかりません」となり、標準関数（LeftやMidなど）すら動かなくなる。 | VBEの参照設定で「MISSING（参照不可）」を解除するか、プログラムをレイトバインディング化する。 |
| セキュリティ制限 | マクロが警告なしに無効化される、または「セキュリティリスク：このファイルのソースが信頼できないため、Microsoftによりマクロの実行がブロックされました」と赤色バーが表示される。 | ファイルのプロパティから「ブロックの解除」を行うか、保存先を「信頼できる場所」として登録する。 |
| OSやOfficeのバージョン差 | 新しいバージョンのExcelで追加された関数やプロパティが、古いバージョンのExcelで実行した際にエラーになる。 | 古いバージョンでもサポートされている標準的なコードに書き直す。 |
これらの原因は、PCのキッティング状況や、Officeがプリインストール版かMicrosoft 365版かといったライセンス形態の違いによっても容易に発生します。原因を正確に見極め、適切な処置を施すことで、どの端末でも安定して動くマクロを構築できます。
Officeバージョンとビット数（32bit/64bit）の差異による影響と解決策
近年、Excelマクロが急に動かなくなる原因として特に増えているのが、Office（Excel）のビット数（32bit版と64bit版）の違いです。かつては32bit版のOfficeが推奨されていましたが、現在の新しいPCではデフォルトで64bit版のOfficeがインストールされることが一般的になりました。これにより、過去に32bit環境で作成されたマクロが64bit環境で動作を停止する問題が多発しています。
Win32 APIを呼び出す「Declare文」の不整合
マクロ内でWindowsのシステム機能（API）を直接呼び出す記述（Declare文）がある場合、64bit環境のExcelで実行すると「コンパイルエラー」となります。64bit版のVBA（VBA7）では、API呼び出しの安全性を確保するために「PtrSafe」キーワードの指定が必須となっており、さらにメモリポインタやハンドルを表すデータ型を「Long」から「LongPtr」に変更しなければなりません。
32bit環境と64bit環境の双方が混在するオフィスでマクロを共有する場合、どちらの環境でもエラーを発生させずに動作させるために、条件付きコンパイル（#If…Then）を用いてコードを書き分ける必要があります。以下に具体的な修正コード例を示します。
#If VBA7 Then
' 64bit（Office 2010以降のVBA7対応環境）向け宣言
Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As LongPtr)
#Else
' 32bit（古いOffice環境）向け宣言
Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#If Endこの記述をモジュールの先頭に組み込むことで、Excelの内部が自動的に環境を判定し、適切な宣言を読み込んで実行します。古いマクロを移行する際は、まずコード内に「Declare」というキーワードが使われていないか、検索機能を用いて確認することをお勧めします。
参照設定の「参照不可（MISSING）」を解消する手順
あるPCでは軽快に動くマクロが、別のPCに持っていくと「プロジェクトまたはライブラリが見つかりません」という謎のエラーを出して強制終了することがあります。これは、VBAが他のアプリケーション（OutlookやAccess、Wordなど）や、外部ライブラリ（FileSystemObject、RegExpなど）を制御する際に利用する「参照設定」のバージョン情報が、PC間で不一致を起こしていることが原因です。
原因：開発時と実行時のライブラリバージョンのギャップ
マクロの開発者がOffice 2019を使って作成し、そこで「Microsoft Outlook 16.0 Object Library」にチェックを入れたとします。このマクロファイルを、Office 2013（バージョン15.0）がインストールされている別のPCで開くと、Excelは指定された「16.0」のライブラリを見つけられず、参照設定の画面で「参照不可：MISSING」というマークを付与します。この「参照不可」が1つでも存在すると、マクロ全体がコンパイルエラーになり、一見全く関係のない標準の文字列操作関数（LeftやMid、Formatなど）までもが「定義されていない」としてエラーになります。
解決手順：参照不可の解除とレイトバインディング化
このトラブルを根本から排除するための手法として、実務では「レイトバインディング（事後バインディング）」へのコード修正が非常に有効です。
参照設定を事前に済ませておく方法（アーリーバインディング）は、コーディング中に自動メンバー表示（インテリセンス）が効いて開発しやすいというメリットがある反面、環境差に極めて弱いというデメリットがあります。一方、プログラム実行時にライブラリを動的に生成するレイトバインディングを用いれば、参照設定画面のチェックが不要になり、環境依存エラーを完璧に予防できます。
| バインディング手法 | メリット | デメリット / コード例 |
|---|---|---|
| 事前バインディング (Early Binding) |
・コーディング時に補完が効く ・処理速度がわずかに速い |
・Officeのバージョン差でエラーが発生しやすいDim objOutlook As Outlook.Application |
| 事後バインディング (Late Binding) |
・参照設定が不要 ・実行環境のバージョンに左右されない |
・自動メンバー表示が機能しないDim objOutlook As Object |
社内で多人数に配布するマクロについては、開発段階では「事前バインディング」で効率よく作成し、テスト完了後に「事後バインディング（Object型とCreateObject関数を使用する形式）」へ書き換えて配布するという運用ルールを徹底することで、無駄なエラー対応の手間を劇的に削減できます。
セキュリティ警告やブロックへの対策と設定方法
特定のPCだけでマクロが動かない原因の中には、プログラム側の不備ではなく、WindowsやExcel自体の「セキュリティ制御」によるものも多く存在します。特に、インターネットや社内ネットワーク経由で共有されたExcelファイルに対するMicrosoftのセキュリティパッチ適用により、マクロの動作基準は年々厳格化しています。
「Mark of the Web (MotW)」による動作ブロックの解除
メールに添付されたマクロファイルをダウンロードしたり、ファイルサーバーからローカルにコピーしたりした際、画面上部に赤い警告バーが表示されてマクロが強制的に無効化される現象があります。これは、Windowsがそのファイルに「インターネットから入手した」という識別情報（ZoneID、通称Mark of the Web）を付与するためです。これを解除するには、以下の手順を実施します。
- 対象のExcelファイルを完全に閉じます。
- エクスプローラー上で対象ファイルを右クリックし、「プロパティ」を開きます。
- 「全般」タブの最下部にあるセキュリティ項目で、「許可する」（または「ブロックの解除」）にチェックを入れます。
- 「適用」をクリックしてプロパティ画面を閉じます。
「信頼できる場所」へのフォルダ登録
社内の特定のネットワークフォルダー（ファイルサーバーや共有フォルダ）にマクロファイルを配置し、複数のメンバーで共有して作業する場合は、毎回ブロック解除の作業を行うのは現実的ではありません。その場合は、マクロが保存されているフォルダ自体を「安全な場所」としてExcelに登録することが推奨されます。
- Excelを開き、「ファイル」＞「オプション」を選択します。
- 左側メニューの「トラスト センター」（または「セキュリティ センター」）を選び、「トラスト センターの設定」ボタンを押します。
- 「信頼できる場所」メニューを選択し、「新しい場所の追加」をクリックします。
- マクロが保存されているフォルダパスを入力（または「参照」から選択）し、「この場所のサブフォルダーも信頼する」にチェックを入れ、「OK」を押して保存します。
この設定を行うことで、そのフォルダ内に置かれたすべてのマクロファイルについて、ブロックや警告が表示されることなく安全かつスムーズにプログラムを実行できるようになります。
社内解決が困難なマクロトラブルを専門家に相談するメリット
ここまで紹介した「ビット数」「参照設定」「セキュリティ」に関する原因究正と対処法を実践すれば、多くの環境エラーは解決できます。しかしながら、以下のような複雑な状況においては、社内担当者のリソースだけで対処を試みることが、かえって業務効率の著しい低下や、プログラムの二次破損を招くリスクがあります。
- マクロの開発者が既に退職しており、ソースコードの全体像や修正箇所が誰も分からない（ブラックボックス化）。
- 修正を繰り返した結果、コード内に条件付きコンパイルや重複処理が散乱し、メンテナンスが不可能な状態（スパゲッティコード）になっている。
- 数千行に及ぶ長大なマクロであり、どの部分が「参照設定」や「32bit API」に依存しているかを漏れなく洗い出す時間がない。
このようなケースでは、Excel・VBA開発や修復の専門チームへ外注することを推奨します。専門のエンジニアであれば、単に「エラーを動くようにする」だけにとどまらず、古いAPI呼び出しを一括で最新のものへと更新し、将来的なOfficeアップデートにも耐えられる「レイトバインディング設計」へとプログラムをリファクタリング（最適化）することが可能です。業務のダウンタイムを最小限に抑え、本業に集中できる環境を維持するためにも、社外の技術サポートを効果的に活用しましょう。
よくある質問（FAQ）
マクロのエラー時に「コンパイルエラー」と出ますが、通常の「実行時エラー」と何が違いますか？
「コンパイルエラー」は、プログラムを実行する前の段階（Excelがマクロの文章を解析した時点）で、構文の不整合やライブラリの欠損を検知して停止するエラーです。32bit/64bitの宣言不整合や参照不可（MISSING）はコンパイルエラーに分類され、コード全体の動作がその場で一切できなくなります。一方、「実行時エラー」は、実行中に不都合なデータ（不正な値や、存在しないファイルを開こうとした場合など）に遭遇して発生するエラーです。
社内のPCすべてのOfficeを同じバージョン・ビット数に統一すれば、トラブルは起きませんか？
環境を完全に統一できれば、環境差異によるエラーの発生確率を大幅に低減できます。しかし、PCの新規導入や一部の部署での新ソフト利用、Officeのサイレント自動アップデートなどにより、長期的には必ずどこかでバージョンの差分が生じます。そのため、環境を強引に固定化するよりも、どのビット数やバージョンでも動作する「ロバスト（堅牢）なコード設計」にプログラム側をあらかじめ修正しておくことが、最も確実で恒久的な対策となります。
ファイルサーバー上の共有Excelマクロを開くとセキュリティ警告が出ますが、ネットワーク内のパスも「信頼できる場所」に追加できますか？
はい、追加可能です。ただし、デフォルトの状態では、Excelの「信頼できる場所」へのネットワークパス（IPアドレスや「\\server\…」などの共有名）の登録はセキュリティ上制限されています。トラストセンター設定画面の「信頼できる場所」一覧の下部にある「自分のネットワーク上にある信頼できる場所を許可する（推奨しません）」にチェックを入れることで、ネットワーク上の共有フォルダパスを指定・登録できるようになります。
