【VBA】他のマクロを呼び出す方法｜Application.Runの基本から実務で壊れない設計

Excel VBAで処理が増えてくると、「このマクロの一部を別のマクロから使い回したい」「処理を分割して管理したい」と感じる場面が必ず出てきます。
そのときに登場するのが、他のマクロを呼び出す処理です。

VBAでは、単純に Call や Sub名 で呼び出す方法もありますが、
実務では Application.Run メソッドを使うべき場面 が確実に存在します。

この記事では、

• Application.Runとは何か
• なぜ実務で使われるのか
• どんな設計で使うと壊れにくいのか

を、実務目線で体系的に整理します。

✅ VBAで「他のマクロを呼び出す」必要が出てくる理由

VBAを書き始めたばかりの頃は、1つのSubにすべての処理を書いてしまいがちです。
しかし処理が増えるにつれ、次のような問題が出てきます。

• 処理が長くなり、全体像が把握できない
• 一部だけ修正したいのに、影響範囲が分からない
• 同じ処理を別マクロでも使いたくなる

この状態を放置すると、修正できないマクロに育ってしまいます。
そこで必要になるのが、処理の分割と呼び出しです。

✅ Application.Runとは何か【基本の考え方】

Application.Run は、
「文字列として指定したマクロ名を実行する」 メソッドです。

最大の特徴は、

• 同一ブックだけでなく
• 別ブックのマクロも実行できる

という点にあります。

この性質があるため、
Application.Run は 単なるSub呼び出し以上の役割 を持ちます。

✅ なぜApplication.Runを使うのか（Callとの違い）

ここで一度、よくある疑問を整理します。

「Sub名で呼べるなら、Application.Runはいらないのでは？」

結論

使い分けが必要です。

Application.Run は
「どのマクロを実行するかを、実行時に決めたい」
という設計と相性が非常に良いのです。

✅ Application.Runの基本構文

Application.Run "マクロ名"

または、別ブックの場合：

Application.Run "'BookName.xlsm'!マクロ名"

ただし、この書き方をそのまま多用するのは危険です。
次章で、実務向けの設計に落とし込みます。

✅ 実務で壊れにくいApplication.Runの基本設計

なぜこの設計にするのか

Application.Run は便利な反面、

• マクロ名の変更に弱い
• 実行対象が分かりにくい
• エラー時の原因特定が難しい

という弱点があります。

そのため、直接ベタ書きしない設計が重要です。

実務向けサンプルコード（基本形）

Public Sub ExecuteTargetMacro()
    Dim targetMacroName As String
    
    ' 実行するマクロ名を明示的に管理
    targetMacroName = "MainProcess"
    
    ' マクロ実行
    Application.Run targetMacroName
End Sub

この書き方を採用する理由

• マクロ名を変数として管理できる
• 実行対象がコード上で明確
• 後から条件分岐・差し替えが容易

「今は1つしか呼ばない」場合でも、
将来の変更を前提にした設計にしておくことで、
修正コストを大きく下げられます。

✅ 条件によって呼び出すマクロを切り替える設計

Application.Run が真価を発揮するのは、
実行マクロを動的に切り替える場面です。

実務サンプル：処理モード別に実行マクロを変更

Public Sub ExecuteByMode(processMode As String)
    Dim macroName As String
    
    Select Case processMode
        Case "Import"
            macroName = "ImportDataProcess"
        Case "Export"
            macroName = "ExportDataProcess"
        Case Else
            MsgBox "不正な処理モードです。", vbExclamation
            Exit Sub
    End Select
    
    Application.Run macroName
End Sub

なぜSelect Caseを使うのか

• 条件分岐が増えても可読性が落ちにくい
• 実行可能なマクロを制限できる
• 誤ったマクロ実行を防げる

If文で文字列を直接渡すより、
安全性と保守性が高い設計になります。

👉 今回のように、
処理内容に応じて実行マクロを切り替える場合は、
If文ではなく Select Case を使う理由を理解しておくことが重要です。
条件分岐を整理し、後から壊れにくいコードを書くための考え方は、
「【VBA】Select Case文の使用例と適用パターン｜条件分岐を効率化する方法」で詳しく解説しています。

✅ 別ブックのマクロを呼び出すときの考え方

別ブックのマクロを実行できるのは、
Application.Run の大きなメリットです。

Application.Run "'Utility.xlsm'!CommonProcess"

実務で気をつけるポイント

• ブック名は完全一致が必要
• ブックが開いていないと実行できない
• ファイル名変更の影響を受けやすい

実務対策

• 共通処理用ブックは名称を固定
• 起動時にブック存在チェックを行う
• 依存関係をドキュメント化しておく

✅ Application.Runを使うときの実務上の注意点

① エラー処理を必ず入れる

On Error GoTo ErrorHandler

Application.Run macroName
Exit Sub

ErrorHandler:
MsgBox "マクロ実行中にエラーが発生しました。", vbCritical

→ 失敗しても原因が分かる設計が必須です。

② マクロ名の「文字列直書き」を最小限にする

• 定数
• Enum
• 管理用モジュール

などで一元管理すると、
名前変更に強い構成になります。

③ Application.Runは「万能」ではない

• 単純な処理分割
• 同一モジュール内呼び出し

これらは 通常のSub呼び出しで十分です。
Application.Run は 必要な場面だけに限定しましょう。

✅ まとめ：Application.Runは「拡張性のための選択肢」

• Application.Runは柔軟だが、乱用すると読みにくくなる
• 実務では「動的にマクロを切り替える」場面で使う
• マクロ名管理・エラー処理が設計の要
• CallやSub呼び出しと使い分けることが重要

Application.Run は、
「今を楽にするため」ではなく
「将来の変更に耐えるため」 の手段です。

処理が増えてきたタイミングで、
ぜひ設計として取り入れてみてください。

🔁 次に読むと理解が深まる関連記事

👉 VBAで処理を分割・管理していくうえで、
マクロ設計全体の考え方を整理したい方は、
「Excel業務改善はどう判断すべきか？ツール・自動化に迷う前の設計思考」
もあわせて確認すると、判断に迷わなくなります。