VBA実行時エラー5「プロシージャの呼び出し、または引数が不正です」が出た時に確認した場所

VBA 実行時エラー5が出たとき、最初は何を直せばよいのか分かりませんでした。画面には「プロシージャの呼び出し、または引数が不正です」と出ます。言葉だけ見ると、とても難しく感じます。自分の場合も、そこで手が止まりました。たとえば、そのとき作っていたのは、Excelの一覧からPDFを作る小さなマクロでした。シート名を見て、保存名を作ります。必要な文字だけを切り出します。最後にPDFとして保存する流れでした。どれも単純な処理のつもりでした。ところが、ある行で突然止まりました。ただ、型が違うわけではありません。ファイルが見つからないわけでもありません。式の書き方も、ぱっと見では間違っていませんでした。それでも処理は止まります。

あとから見ると、原因は「渡している値」でした。たとえば、開始位置が0になっていました。文字数もマイナスの状態でした。保存名に使えない記号も混ざっていました。この記事では、そのときに自分が確認した順番を共有します。

ファイル名エラーの正体と対処

まず、最初に止まったのは、ファイル名を作る処理でした。Excelのセルから日付と部署名を読みます。それをつなげて、PDFの保存名にしていました。毎月の作業を少し楽にしたかっただけです。

エラーが出た行を見ても、すぐには分かりませんでした。しかも、関数の名前は知っているものです。変数名も自分で付けたものです。それでも、なぜ止まるのか見えませんでした。ここで焦って、コード全体を直そうとしました。でも、それは遠回りでした。実行時エラー5は、処理全体が壊れた合図とは限りません。渡した値が、その処理に合っていないだけのことがあります。自分の場合は、切り出す文字数が想定と違っていました。また、空欄のセルも混ざっていました。保存名には、使えない記号も入っていた状態です。まずは、止まった一行だけを見る方が早かったです。

VBAエラー：括弧の中の引数確認

VBAでエラーが出ると、黄色く止まる行があります。まず見た方がよかったのは、その行でした。特に、関数名の後ろにある括弧の中です。そこに渡している値を見ます。

ここで、プロシージャは処理のまとまりのようなものだと考えました。引数は、その処理へ渡す材料です。料理でいえば、手順と材料に近いと感じました。材料の数や中身が違うと、手順が進みません。つまり、実行時エラー5では、この材料側が合っていないことがあります。文字を切る関数なら、開始位置や文字数です。日付を動かす関数なら、日付や増減の値です。保存処理では、保存先やファイル名を見ました。自分は最初、関数名ばかり見ていました。でも、見るべき場所は括弧の中でした。そこに入っている変数が、どんな値になっているかを確認します。

Debug.Print 変数の実態

次に使ったのが、Debug.Printでした。これは、変数の中身を画面に出すための確認メモです。VBAのイミディエイトウィンドウに値を表示できます。難しい道具というより、途中経過を見るための窓でした。

たとえば、開始位置を入れた変数があります。また、文字数を入れた変数もあります。保存名を入れた変数も対象にしました。それぞれを、止まる直前で表示します。すると、思い込みが外れました。開始位置は1以上のつもりでした。でも、実際の値は0です。文字数は正の数のつもりでした。ところが、マイナスになっていました。画面に出してみると、原因が急に具体的になります。ただ、コードを眺めるだけでは分かりません。変数名から想像しても外れます。実際の値を見る方が確実でした。

文字列関数エラーは引数が原因

文字列を切り出す処理でも、実行時エラー5が出ました。そのとき自分が使っていたのは、MidやLeftです。Midは、文字列の途中から必要な分を取り出します。Leftは、左側から指定した分を取り出します。

ここで大事だったのは、開始位置と文字数でした。たとえば、開始位置が0になると困ります。文字数がマイナスになっても困りました。元の文字列が空欄でも、想定が崩れます。自分の場合は、区切り文字の位置を探していました。その位置を使って、必要な文字数を計算します。ところが、区切り文字が見つからない行がありました。その結果、計算した文字数が変な値になりました。関数の書き方だけを見ると、間違いは見えませんでした。でも、渡している数字を見ると原因が分かりました。文字列関数で止まったら、まず数字を見ます。開始位置、文字数、元の文字列の3つです。

保存名のエラー原因と対処

PDF保存でも、同じエラーに出会いました。Excelのシート名を、そのまま保存名に使っていました。見た目には普通の名前です。でも、ファイル名に使えない記号が混ざっていました。

たとえば、保存名には使えない文字があります。スラッシュやコロンなどです。末尾の空白も邪魔になることがあります。セルが空欄のまま、名前を作っていることもあります。この場合も、コード全体は悪くありませんでした。保存処理そのものも間違っていません。つまり、問題は保存処理へ渡した名前でした。中身を見るまで気づけませんでした。自分は、保存名を一度変数に入れました。その変数を画面に出します。余計な記号や空白を見つけました。その後で、使えない文字を置き換えました。

見落としがちなエラー原因

文字や保存名を見ても直らない場合があります。その場合は、日付や番号も疑いました。たとえば、DateAddを使う処理です。DateAddは、日付に日数や月数を足す関数です。

ここでも、渡す値が大事でした。たとえば、日付の形が崩れていることがあります。増やす数が想定外のこともありました。基準日が空欄の場合もあります。そのまま渡すと、エラーになることがありました。また、配列番号でも似たことが起きます。配列は、複数の値を入れておく箱のようなものです。存在しない番号を見に行くと、処理が止まります。エラー番号は違う場合もあります。でも、値の範囲を見る考え方は同じでした。環境差も少しだけ気にしました。Windowsでは動いても、別のPCで止まることがあります。パスの書き方や保存先が違うためです。直前の計算結果を変数に分けると、確認しやすくなりました。

空欄セル：VBA処理の盲点と対策

自分が見落としやすかったのは、空欄セルでした。一見すると、ただの未入力に見えます。でも、VBAの処理ではそのまま値として渡されます。その値を使って文字を切ると、計算が崩れました。

たとえば、部署名が空欄の行があります。そして、その部署名を使って保存名を作っていました。空欄のままつなげると、思った名前になりません。さらに、区切り文字の位置もずれました。このときも、エラー文だけでは分かりませんでした。セルを見ればすぐ分かる話です。しかし、コードだけ見ていると気づきにくいです。だから、元のセルの値も一度見るようにしました。空欄があり得る列は、先に確認します。空欄なら処理を飛ばす方法もありました。仮の名前を入れる方法もあります。どちらにしても、空欄を想定しておくと安心でした。

実行時エラー対策：段階的確認と処理分割

実行時エラー5が出たあと、何度も本番処理を動かしました。これはよくありませんでした。保存先に途中のファイルが残ります。どこまで進んだかも分かりにくくなりました。

今は、まず小さい範囲で試します。そこで、対象行を1行だけにしました。保存処理の前で止めます。変数だけ画面に出しました。それから本番の処理へ戻します。この順番にすると、確認が軽くなりました。そのため、エラーが出ても影響する範囲が小さいです。ファイルを何度も消す必要も減りました。自分のように不安な人には、この方が向いていました。コードを一気に直すより、状態を分けて見る方が楽です。値を作る処理と、保存する処理を分けます。日付を計算する処理も分けます。一つずつ動かすと、原因の場所が狭くなりました。

直った気分で終わらない確認

原因らしい場所を直したあとも、すぐ安心しませんでした。まず、同じ行でもう一度動かします。同じファイル名でもう一度試しました。同じ日付でもう一度確認します。ここを飛ばすと、直った気分だけで終わります。

自分の場合、記号を置き換えたあとに別の問題が出ました。ファイル名は作れるようになりました。でも、保存先フォルダが存在しませんでした。一つ直すと、次の問題が見えることがあります。そのため、直した値をもう一度表示しました。また、保存名も表示します。保存先も表示しました。日付の計算結果も表示します。画面に出すだけで、確認漏れが減りました。ここまでやってから本番処理を流しました。もちろん、時間は少しかかります。でも、同じエラーで何度も止まるよりは楽でした。急いでいるときほど、再確認が効きました。

小さなメモでエラー解決

直したあとに、短いメモも残すようにしました。まず、どの行で止まったのかを書きます。どの変数が変な値だったのかも書きました。どう直したのかも一緒に残します。

最初は面倒だと思っていました。ただ、同じエラーは忘れたころに出ます。そのとき、前の自分のメモが役に立ちました。エラー文を見て慌てる時間が減りました。メモは立派な資料でなくて大丈夫でした。たとえば、行番号、変数名、実際の値だけでも十分です。具体的には、開始位置が0でした。保存名にコロンが入っていました。このくらいで、次の確認が早くなります。VBAに詳しい人なら、すぐ分かるのかもしれません。でも、自分は毎回そこまで早くありません。だから、エラーのたびに小さく記録します。それが、自分にとって一番現実的な対策でした。

あとで見返すと、同じ失敗の形も見えてきました。自分の場合は、空欄と記号が多かったです。文字数の計算ミスも何度かありました。この傾向が分かるだけでも、次の確認が楽でした。

最初の一歩を早めるメモ

メモを残す目的は、立派にまとめることではありません。次に止まったとき、最初の一歩を早くするためです。「前もここを見た」と思えるだけで、少し落ち着けました。焦って全部を直そうとしなくなったのも助かりました。

今でも完璧には直せません。それでも、見る順番があるだけで前より落ち着けます。同じエラーで止まっても、まず値を見るところから始められるようになりました。

エラー解決の確認手順

何度か同じエラーに当たって、見る順番を決めました。まず、黄色く止まった行を見ます。次に、括弧の中の引数を見ました。その後で、変数の中身を画面に出します。

文字列関数なら、開始位置を見ます。文字数も見ました。元の文字列が空欄ではないかも見ます。保存処理では、ファイル名を見ました。使えない記号や空白を探します。日付なら、日付として読める値か見ます。配列なら、番号が範囲内か見ました。別のPCで動かすなら、保存先も見ます。この順番にしただけで、迷う時間が減りました。エラー文だけを見ると、今でも難しく感じます。でも、確認する場所を小さく分けると楽になります。全部を一度に直そうとしない方がよかったです。一つずつ値を見るのが、自分には一番合っていました。

VBAエラーの原因特定と解決策

次に同じエラーを見たら、まず止まった行を見ます。それから、括弧の中を見ました。変数があれば、Debug.Printで出します。ここまでで、かなり見通しがよくなりました。

文字を切る処理なら、0やマイナスを疑います。保存する処理なら、名前の中身を疑いました。日付や番号を使う処理なら、範囲を疑います。どれも、難しい理屈から入らなくて大丈夫でした。自分は、VBAに詳しい人間ではありません。そのため、エラー文だけで原因を当てるのは無理でした。でも、値を見える形にすることはできます。それだけでも、かなり前に進みます。実行時エラー5は、言葉だけ見ると怖いです。ただ、毎回すべてを疑う必要はありません。止まった行と渡した値を見るだけでも十分です。もし同じところで困っている人がいたら、まずこの順番で見てみてください。

関連リンクとチェックリスト

学習サービスとアンケート