VBAを組み込んだExcelファイルをメール添付で別のPCへ移したところ、セルに #NAME? が表示されることがあります。この場合、単純にExcelファイルが壊れたとは限りません。マクロが無効になっている、VBAで作ったユーザー定義関数が利用できない、参照設定が不足している、アドインや定義名が別PCに存在しないなど、複数の原因が考えられます。
特にメールやインターネット経由で取得したOfficeファイルは、セキュリティ上の理由からマクロが制限されることがあります。そのため、元のPCでは正常だったExcelが別PCでは動かないという現象は珍しくありません。
この記事では、VBA入りExcelを別PCへ移したときに #NAME? が出る原因を切り分け、なるべく安全に解消する手順を順番に解説します。
- #NAME?エラーは「Excelが名前を認識できない」ときに出る
- 最初にファイル形式を確認する
- メールからダウンロードしたファイルはマクロがブロックされることがある
- Windowsならファイルの「ブロック解除」を確認する
- 「コンテンツの有効化」が表示されているか確認する
- 信頼できるファイルなら「信頼できる場所」を使う方法もある
- 数式がVBAのユーザー定義関数を使っていないか確認する
- VBAコードが実際に残っているか確認する
- 「参照設定が見つかりません」になっていないか確認する
- 参照設定が不足していたらどうする？
- 32bit版と64bit版Excelの違いも確認する
- 別PCに必要なアドインが入っていない場合もある
- 名前の定義が失われていないか確認する
- メール添付によってセルの数式が変わるのが一般的なわけではない
- Excelのバージョン差で新しい関数が使えないケースもある
- まず1つのエラーセルの数式を確認するのが近道
- おすすめの確認順序
- マクロのセキュリティ設定を全部無効にするのは避ける
- 会社PCなら管理者設定が原因の場合もある
- 別PCでも動くVBAブックにするための対策
- まとめ｜メール添付後の#NAME?はVBAの実行環境から確認する
#NAME?エラーは「Excelが名前を認識できない」ときに出る
#NAME? は、Excelが数式の中にある関数名や定義名などを認識できないときに表示されるエラーです。Microsoftも、関数名の入力ミス、未定義の名前、必要なアドインが無効になっている場合などを主な原因として案内しています。Microsoft公式情報[参照]
例えばセルに =MyFunction(A1) と書かれており、MyFunction がVBAで作った独自関数だった場合、そのVBAが実行できない状態になるとExcelが MyFunction を認識できず、#NAME? になることがあります。
VBA入りファイルを別PCへ移した直後に#NAME?が出た場合は、まず「マクロやユーザー定義関数が有効に動いているか」を確認するのが重要です。
最初にファイル形式を確認する
VBAを保存できるExcelファイルは、通常 .xlsm や .xlsb、旧形式の .xls などです。一方、一般的な .xlsx 形式にはVBAマクロを保存できません。
元のファイルが .xlsm だったのに、メール添付や保存の途中で .xlsx として保存し直してしまった場合、VBAコードが失われている可能性があります。
エクスプローラーやExcelの「名前を付けて保存」で拡張子を確認し、マクロを含むブックであれば .xlsm などのマクロ対応形式になっているか確認してください。
メールからダウンロードしたファイルはマクロがブロックされることがある
別PCでだけ問題が起きる場合に特に確認したいのが、ファイルのセキュリティ状態です。メール添付やインターネット経由で取得したOfficeファイルは、WindowsやOfficeによって信頼されていないファイルとして扱われることがあります。
その状態でVBAが実行できなければ、VBAで定義された関数をセルから呼び出しているブックでは #NAME? が発生する可能性があります。
ただし、マクロを無条件に有効化するのは危険です。送信元とファイルの内容が確実に信頼できる場合だけ、後述する方法でブロック状態を確認してください。
Windowsならファイルの「ブロック解除」を確認する
信頼できる自作ファイルを自分宛てに送信した場合など、ファイルの出所が確実な場合は、Windows側でブロックされていないか確認できます。
- Excelをいったん閉じる
- ダウンロードしたExcelファイルを右クリックする
- 「プロパティ」を開く
- 「全般」タブの下部を確認する
- 「ブロックの解除」または同様の項目があればチェックする
- 「適用」「OK」を押す
- Excelファイルを開き直す
この項目は、すべての環境・ファイルで表示されるわけではありません。また会社PCでは管理者がマクロポリシーを設定しており、利用者側で変更できないこともあります。
不明な送信者から届いたファイルや、内容を確認できないファイルではブロックを解除せず、管理者や送信者へ確認してください。
「コンテンツの有効化」が表示されているか確認する
Excelを開いたとき、画面上部にセキュリティ警告が表示されることがあります。信頼できるファイルであり、マクロを動かす必要がある場合は、その警告内容を確認します。
ただし最近のOfficeでは、ファイルの入手経路や組織のセキュリティ設定によって、従来の「コンテンツの有効化」だけでは実行できない場合もあります。
そのため、単に「マクロをオンにすればよい」と考えるのではなく、ファイルが信頼できることを確認したうえで、ブロック解除、信頼済みの場所、組織のポリシーなどを確認する必要があります。
信頼できるファイルなら「信頼できる場所」を使う方法もある
Microsoft Officeには「信頼できる場所」という仕組みがあります。これは、指定したフォルダー内のファイルを信頼済みとして扱う機能です。Microsoftは、マクロやデータ接続などのアクティブコンテンツを含む信頼できるファイルを保存する用途として案内しています。Microsoft公式情報[参照]
ただし、信頼できる場所に置いたファイルは一部のセキュリティチェックを回避するため、ダウンロードフォルダー全体などを安易に信頼済みにするべきではありません。
利用する場合は、自分で管理している専用フォルダーだけを指定し、信頼できるExcelファイルだけを保存する運用が安全です。
数式がVBAのユーザー定義関数を使っていないか確認する
VBAでは、通常のマクロだけでなくExcelの数式から利用できる独自関数を作成できます。これをユーザー定義関数、UDFと呼ぶことがあります。
例えばVBA側に次の関数があるとします。
Function AddTax(price As Double) As Double
AddTax = price * 1.1
End FunctionExcelのセルでは次のように利用できます。
=AddTax(A1)元PCでは正常でも、別PCでVBAが無効になっていたりコード自体がなくなったりすると、Excelが AddTax という関数を認識できず #NAME? になる可能性があります。
VBAコードが実際に残っているか確認する
ファイル形式が正しくても、何らかの理由でVBAコードが含まれていない可能性があります。信頼できる自作ファイルであれば、VBAエディターを開いてコードが存在するか確認します。
Windows版Excelでは通常、Alt + F11 でVisual Basic Editorを開けます。左側のプロジェクトエクスプローラーに対象ブックが表示され、標準モジュールなどにコードが残っているか確認します。
ユーザー定義関数が標準モジュールにあるはずなのにモジュール自体が存在しない場合は、メール転送より前の段階でマクロなし形式へ保存してしまった可能性なども考えられます。
「参照設定が見つかりません」になっていないか確認する
VBAが別PCで動かない原因として非常に重要なのが「参照設定」です。元PCには入っていたライブラリやアプリケーションが別PCにない場合、VBAプロジェクトの参照設定が壊れることがあります。
VBAエディターで「ツール」→「参照設定」を開き、一覧に 参照不可 や MISSING: に相当する表示がないか確認します。
例えば元PCにだけ特定のActiveXライブラリ、Access関連ライブラリ、サードパーティー製ソフトなどがインストールされている場合、別PCでは同じ参照先を利用できないことがあります。
参照設定が不足していたらどうする？
不要な参照設定なら、コードへの影響を確認したうえでチェックを外せる場合があります。必要なライブラリであれば、同じソフトや適切なコンポーネントを新しいPCへ正規の方法でインストールする必要があります。
ただし、何のライブラリか分からない状態で参照設定をむやみに変更すると、別の機能が動かなくなる可能性があります。まず元PCの参照設定と比較すると原因を特定しやすくなります。
特に業務用Excelの場合は、作成者または社内システム管理者へ確認してから変更するのが安全です。
32bit版と64bit版Excelの違いも確認する
元PCと別PCでOfficeの32bit版・64bit版が異なる場合、VBAコードによっては正常に動作しないことがあります。特にWindows APIを直接呼び出している古いVBAでは影響を受けることがあります。
例えば古いAPI宣言を64bit版Officeで使う場合、コード側で PtrSafe などへの対応が必要になるケースがあります。
ただし、単純なユーザー定義関数で #NAME? が出ているだけなら、最初から32bit・64bit問題と決めつける必要はありません。まずマクロ有効化、VBAコードの存在、参照設定の順で確認するほうが効率的です。
別PCに必要なアドインが入っていない場合もある
数式がExcel標準関数ではなくアドイン由来の関数を使っている場合、別PCにそのアドインがないことで #NAME? になることがあります。Microsoftも、必要なアドインが有効になっていない場合に #NAME? が発生することがあると案内しています。Microsoft公式情報[参照]
例えば元PCに独自の .xlam アドインを入れており、そのアドイン内の関数をExcelシートから呼び出している場合、新しいPCにも同じアドインを導入しないと動作しません。
数式バーを確認し、自作関数らしい名前が含まれている場合は、その関数が現在開いているブック内のVBAなのか、外部アドインなのかを確認します。
名前の定義が失われていないか確認する
#NAME? はVBAだけでなく、Excelの「定義された名前」が見つからない場合にも発生します。
例えばセルに次のような式が入っているとします。
=売上合計*1.1この 売上合計 が名前マネージャーで定義されていなければ、Excelは何を指しているのか理解できません。「数式」→「名前の管理」などから、必要な定義名が存在するか確認します。
別ファイルを参照している名前や、外部リンクを含む定義名では、ファイル移動によって参照先が変わっている可能性もあります。
メール添付によってセルの数式が変わるのが一般的なわけではない
通常、Excelファイルを単純にメールへ添付して別PCへ保存しただけで、セルの数式やVBAコードが勝手に別の内容へ書き換えられるわけではありません。
そのため、元PCでは正常、新PCでは #NAME? という場合、メールそのものより「別PC側のOffice環境・セキュリティ設定・アドイン・参照ライブラリ・Excelバージョン」などの差を疑うほうが有効です。
ただし、途中でクラウドサービスやメールソフトから別形式として保存した場合はファイル形式を確認してください。
Excelのバージョン差で新しい関数が使えないケースもある
元PCのExcelと別PCのExcelのバージョンが違う場合、片方でしか利用できないワークシート関数が含まれている可能性もあります。
例えば新しいExcelで利用可能になった関数を、対応していない古いExcelで開くと、期待通り処理できない場合があります。この場合はVBAが原因ではありません。
数式バーを確認して、#NAME? が出ているセルが自作VBA関数を呼んでいるのか、Excel標準関数を利用しているのかをまず確認すると、原因を絞り込めます。
まず1つのエラーセルの数式を確認するのが近道
シート全体に #NAME? が大量に表示されている場合でも、最初からすべてを修正する必要はありません。まずエラーが出ているセルを1つ選択して、数式バーを確認します。
例えば次のようになっていれば、原因を分類できます。
| 数式の例 | 疑うポイント |
|---|---|
=MyFunc(A1) |
VBAのユーザー定義関数 |
=CustomTool(A1) |
アドインや外部関数 |
=売上合計*1.1 |
定義名 |
=新しい関数(...) |
Excelバージョン差 |
| 明らかなスペルミス | 数式そのものの誤り |
Microsoftも、#NAME? はExcelが数式内のテキストを認識できない場合に表示されるエラーとして説明しています。数式エラーの確認方法[参照]
おすすめの確認順序
原因を効率よく探すなら、次の順番で確認すると分かりやすくなります。
- ファイルの拡張子が
.xlsmなどマクロ対応形式か確認する #NAME?のセルを選び、数式バーを見る- 自作のVBA関数名が使われているか確認する
- VBAコードがブック内に残っているか確認する
- メール由来のファイルがブロックされていないか確認する
- 信頼できるファイルの場合のみマクロ実行環境を確認する
- VBAの「参照設定」に不足がないか確認する
- 必要なアドインが別PCにもあるか確認する
- 元PCと新PCのExcelバージョン・32bit/64bitを比較する
- 定義名や外部参照も確認する
この順番で確認すれば、「VBA自体が動いていないのか」「VBAは動くが特定ライブラリがないのか」「そもそもVBAとは無関係な数式エラーなのか」を切り分けやすくなります。
マクロのセキュリティ設定を全部無効にするのは避ける
問題を解消するために、インターネット上で「Excelのマクロセキュリティを最低にすればよい」といった方法を見つけることがあります。しかし、すべてのマクロを無条件で実行できるようにする設定は推奨できません。
VBAマクロにはファイル操作や外部プログラムの実行など強い機能があります。悪意のあるExcelファイルを開いた場合、セキュリティ上の被害につながる可能性があります。
信頼できる自作ファイルだけを使うなら、その特定ファイルのブロック状態や専用の信頼済みフォルダーを確認するなど、対象を限定した方法を選ぶほうが安全です。
会社PCなら管理者設定が原因の場合もある
会社支給PCでは、利用者自身がマクロ設定を変更できないことがあります。組織がグループポリシーなどでVBAの実行を制御しているためです。
元PCが個人PC、新PCが会社PCという組み合わせなら、同じExcelを開いても動作が変わる可能性があります。
この場合はセキュリティ設定を無理に回避せず、社内のIT管理者へ「業務で使用する署名済み・自社作成のVBAブックを動かす必要がある」など、用途を説明して対応を確認してください。
別PCでも動くVBAブックにするための対策
今後も複数PCで同じVBAブックを利用するなら、作成段階から環境依存を減らしておくとトラブルを防ぎやすくなります。
- 必要なアドインや外部ソフトを文書化する
- 参照設定を必要最小限にする
- Officeの32bit・64bit差を考慮する
- 外部ファイルの絶対パスを安易に固定しない
- Excelの対応バージョンを明確にする
- マクロ対応形式で保存する
- 配布方法と信頼設定をあらかじめ決める
例えばコード内に C:\Users\Tanaka\Desktop\data.csv のような固定パスを書いていると、ユーザー名やフォルダー構成が違うPCでは動作しません。これは #NAME? の直接原因とは限りませんが、別PCへ移行した際に起きやすい代表的な環境依存問題です。
まとめ｜メール添付後の#NAME?はVBAの実行環境から確認する
VBA入りExcelをメール添付で別PCへ移した後に #NAME? が表示された場合、特に自作のユーザー定義関数をセルで利用しているなら、VBAが正常に利用できていない可能性があります。
まずマクロ対応形式で保存されているかを確認し、エラーセルの数式を見て自作関数名が含まれているか調べます。その後、VBAコードの存在、メール由来ファイルのブロック、参照設定、アドイン、Officeのバージョンや32bit・64bit差を順番に確認すると原因を特定しやすくなります。
最も重要なのは、#NAME?という表示だけを見てマクロ設定を全面的に変更せず、まずエラーセルの数式が「何という名前を認識できていないのか」を確認することです。自作VBA関数ならマクロ・コード・参照設定を、通常のExcel関数ならバージョンやスペルを、定義名なら名前マネージャーを確認することで切り分けられます。
また、マクロを有効にするのはファイルの送信元と内容を信頼できる場合だけにしてください。会社管理PCなどで実行が制限されている場合は、セキュリティ設定を回避せず管理者へ相談するのが安全です。
コメント