VBAの「スコープ」を完全理解：Public, Private, Staticの使い分けで大規模開発を制御する
プロシージャを並べ、なんとなく `Dim` で変数を宣言し、シートの操作をすべて1つの標準モジュールに詰め込んでいく――。
そんな「動くには動くが、改修のたびに壊れるスパゲッティコード」から脱却する時が来た。
Excel VBAでの開発規模が大きくなるにつれ、開発者を最も悩ませるのが「意図しない変数の書き換え」と「名前の衝突（グローバル汚染）」だ。どこからでもアクセスできる変数を作ってしまうことは、高速道路の逆走車を野放しにするようなもの。いつどこでクラッシュしてもおかしくない。
今回は、VBAにおけるスコープ（可視範囲）とライフサイクル（生存期間）を完全に掌握し、大規模開発にも耐えうる堅牢なアーキテクチャを構築するための極限の知見を授けよう。
—
1. スコープの本質：なぜ「見えてはいけないもの」を隠すのか
VBAにおけるスコープ設計の基本思想は極めてシンプルだ。
> 「変数は、必要最小限の場所からしか見えないようにし、必要最小限の期間だけ生存させよ（カプセル化の原則）」
これを怠ると、以下のような悪夢のようなバグに直面する。
- 別モジュールの処理が勝手にグローバル変数を書き換え、原因不明の計算ズレが発生する。
- 変数名が重複し、コンパイルエラーかと思いきや予期せぬ挙動を引き起こす。
- ブックを閉じ忘れたかのようにメモリが圧迫され、Excel全体がフリーズする。
VBAが用意している `Public`, `Private`, そして `Static`。この3つのキーワードを適材適所で使い分けることこそが、プロのVBAエンジニアと素人コーダーを分かつ境界線だ。
—
2. キーワード別：完全使い分けマトリクス
まずは、それぞれのキーワードが「どこから見えるのか（可視性）」と「いつ消えるのか（生存期間）」を正確に把握しよう。
| キーワード | 宣言場所 | 可視範囲（スコープ） | ライフサイクル（生存期間） | 推奨用途 |
| :— | :— | :— | :— | :— |
| Dim (プロシージャ内) | プロシージャ内 | そのプロシージャ内のみ | プロシージャ実行中のみ | 一時的な作業用変数（カウンタ、フラグ等） |
| Private | モジュール先頭 | そのモジュール内のみ | ブックが開いている間 | モジュール内で共有する定数や状態保持 |
| Public | モジュール先頭 | アプリケーション全体（全モジュール） | ブックが開いている間 | 設定値、アプリケーション共通の定数（※極力使用を控える） |
| Static | プロシージャ内 | そのプロシージャ内のみ | ブックが開いている間 | 呼び出し後も値を保持したいカウンタ等 |
—
3. 実践！プロダクションコードに学ぶ堅牢なスコープ設計
百聞は一見にしかず。実務でよくある「マスターデータを取り込み、DB（または別ファイル）へ連携し、ログを残す」という一連の処理を想定した、保守性の高いコード構造を見てほしい。
ここでは、「グローバル汚染を避けつつ、モジュール間で安全にデータを授受する設計」を実装している。
標準モジュール①：`m_Config` （定数と環境設定をカプセル化）
アプリケーション全体で共有すべき設定値やパスは、`Public Const` または `Public` プロパティとして一元管理する。マジックナンバーをコード内に直書きしてはならない。
Option Explicit
‘ 【Publicの適正利用】アプリケーション全体で参照する不変の定数
Public Const APP_TITLE As String = “基幹データ自動連携システム”
‘ 【データ構造体（User-Defined Type）の定義】
‘ 関連する設定をひとまとめにし、モジュール間の引数の数を減らす
Type SystemConfig
TargetFolder As String
TimeoutSec As Long
IsDebugMode As Boolean
End Type
‘ 実行時設定を保持するモジュールレベル変数（Privateで隠蔽する）
Private g_Config As SystemConfig
‘ 設定を初期化するプロシージャ（エントリポイントから最初に呼ぶ）
Public Sub InitializeConfig()
‘ ※本来は外部INIファイルやシートから読み込む
g_Config.TargetFolder = ThisWorkbook.Path & “\data\”
g_Config.TimeoutSec = 30
g_Config.IsDebugMode = True
‘ デバッグ出力
If g_Config.IsDebugMode Then
Debug.Print “[” & APP_TITLE & “] 設定の初期化が完了しました。”
End If
End Sub
‘ 読み取り専用のプロパティとして設定値を提供（カプセル化の徹底）
Public Function GetConfig() As SystemConfig
GetConfig = g_Config
End Function
標準モジュール②：`m_Main` （処理のオーケストレーション）
ユーザーが実行するエントリポイント（マクロ一覧に表示されるプロシージャ）は、このモジュールに集約する。
Option Explicit
‘ ユーザーが実行するメインプロシージャ
Public Sub RunDataImportPipeline()
‘ 1. エラーハンドリングの要塞化
On Error GoTo ErrorHandler
‘ 2. アプリケーション環境の最適化（高速化）
Call OptimizeEnvironment(True)
‘ 3. 設定の初期化
Call m_Config.InitializeConfig
‘ 4. データ処理の実行（他のモジュールを安全に呼び出す）
Dim importedCount As Long
importedCount = ProcessDataImport()
MsgBox “処理が正常に終了しました。” & vbCrLf & _
“処理件数: ” & importedCount & “件”, vbInformation, m_Config.APP_TITLE
CleanUp:
‘ 5. 環境の復元
Call OptimizeEnvironment(False)
Exit Sub
ErrorHandler:
MsgBox “予期せぬエラーが発生しました。” & vbCrLf & _
“Error: ” & Err.Description, vbCritical, m_Config.APP_TITLE
Resume CleanUp
End Sub
‘ 内部処理用プロシージャ（Privateで外部から隠蔽）
Private Function ProcessDataImport() As Long
Dim cfg As SystemConfig
cfg = m_Config.GetConfig() ‘ カプセル化された設定を取得
‘ 処理ロジックのシミュレーション
Debug.Print “対象フォルダ: ” & cfg.TargetFolder
‘ Static変数の実用デモ（このプロシージャが何回呼ばれたかを永続的にカウント）
Dim executionId As Long
executionId = GetExecutionCounter()
Debug.Print “今回の実行ID (Static): ” & executionId
‘ ダミーの処理件数を返す
ProcessDataImport = 1250
End Function
‘ 【Staticの極意】プロシージャが終了しても値が消えないカウンター
Private Function GetExecutionCounter() As Long
Static counter As Long
counter = counter + 1
GetExecutionCounter = counter
End Function
‘ 画面描画の停止による高速化処理
Private Sub OptimizeEnvironment(ByVal isEnable As Boolean)
With Application
.ScreenUpdating = Not isEnable
.Calculation = IIf(isEnable, xlCalculationManual, xlCalculationAutomatic)
.EnableEvents = Not isEnable
End With
End Sub
—
4. なぜこの設計がプロダクションレベルなのか？
上記のコードには、現場で生き残るためのアーキテクチャ上の工夫が随所に散りばめられている。
1. グローバル変数の乱用を根絶
多くの初心者は `Public g_Path As String` のように標準モジュールの先頭に何でもかんでも変数を置きたがる。しかし、これではどのタイミングでその値が書き換わったのか追跡不能になる。上記コードでは `Private g_Config` とし、外部からは `GetConfig()` というGetter関数を経由することで読み取り専用の安全なアクセスを実現している。
2. `Static` 変数によるスマートな状態保持
「クラスモジュールを作るほどではないが、プロシージャの呼び出しを超えて値を保持したい」というケース（例えば、エラーリトライ回数や、今回のセッションでの実行回数など）において、`Static` キーワードは非常に強力だ。不要にモジュールレベルの変数枠を消費せずに済む。
3. エントリポイントの明確化
マクロから直接実行してよいプロシージャ（`Public Sub`）と、内部でのみ呼び出すプロシージャ（`Private Sub`）を厳密に分離している。これにより、ユーザーが意図しない内部処理をマクロダイアログから誤実行してしまう事故を防げる。
—
5. チーフアーキテクトからの最終提言
VBAのスコープ設計は、単なる「エラーを防ぐお作法」ではない。それはコードの可読性を極限まで高め、未来の自分やチームメンバーへの最大のギフトとなる設計思想だ。
- 変数を宣言するときは、まず `Dim`（プロシージャ内） で閉じられないか考える。
- モジュール間で共有が必要な定数や設定は、`Private` + Getter関数でカプセル化する。
- `Public` は、アプリケーション全体の定数や、ごく限られたエントリポイント以外では原則禁止とする。
この規律をチームに導入した瞬間から、あなたの作るExcelツールは「動くだけの壊れやすいおもちゃ」から「堅牢な業務システム」へと生まれ変わるはずだ。手元のコードの `Public` を今すぐ見直してみてほしい。
