VBAローカル変数の規約をどうするか

VBA特有の大文字小文字問題を前提に、現場で迷わない変数名の付け方を決める

Copyright © 2026 LWP 山中 一弘

本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

記事要約

　VBAでローカル変数名を決めるとき、単に「読みやすい名前を付ければよい」と言うだけでは済まないことがあります。path のような自然な名前を付けたい場面でも、VBAのエディタ上では大文字小文字の表示が他の識別子に引っ張られ、見た目が意図しない形に変わることがあります。

　この記事では、2022年1月に筆者が投稿した「VBAのローカル変数の規約をどうするか」という考察をもとに、VBAのローカル変数命名を実務向けに整理します。結論は、sPath、nCount、dToday のように、必要最低限の型接頭辞を使いつつ、Booleanや配列は意味で読める名前を優先する、というものです。

　ここで扱うのは、厳密な言語仕様としての命名規則ではありません。チーム、講座、保守現場で合意しやすく、読み間違いを減らし、VBAの癖を避けるための実務規約です。

本記事の対象とゴール

想定読者

• VBAの変数名を毎回なんとなく決めている人

• strPath のような古いハンガリアン記法を使うべきか迷っている人

• path、Path、sPath のどれを使うべきか判断したい人

• 講座、チーム、社内標準としてVBAの命名ルールを説明したい人

本記事で得られること

1. VBAでローカル変数名に接頭辞を付ける意味が分かります。

2. 文字列、数値、日付、Boolean、配列の命名方針を整理できます。

3. sPath 型の命名と、意味で読む命名を使い分けられます。

本記事で扱わないこと

• すべてのVBAプロジェクトに強制すべき絶対的な命名規約

• クラス、プロシージャ、モジュール名を含む全体命名規約

• Microsoft公式の詳細仕様としてのVBAエディタ挙動の網羅

先に結論

　VBAのローカル変数名は、完全に自由に決めるよりも、ゆるい型接頭辞を使って合意したほうが安定します。

　基本形は、文字列なら sPath、数値なら nCount、日付なら dToday です。Booleanは bFlag のように型で表すより、isDir、hasNext のように意味で表すほうが読みやすい場合が多くなります。配列やコレクションは、無理に a を前に付けるより、names、counts のように複数形で表すほうが自然です。

　つまり、VBAでは「型が見えること」と「意味が読めること」の両方が必要です。型接頭辞は便利ですが、すべてを型で支配しようとすると、かえって読みにくくなります。

第1章（VBAで変数名が問題になる理由）

　この章では、VBAでローカル変数名を考えるときに、なぜ他の言語よりも命名規約が問題になりやすいのかを整理します。

1.1（読みやすい名前だけでは済まない）

　プログラミングでは、変数名は意味が分かる名前にするのが基本です。ファイルパスなら path、件数なら count、今日の日付なら today のように書けば、少なくとも英単語としては自然です。

　ところが、VBAではこの自然さだけで押し切ると、エディタ上の表示で違和感が出ることがあります。ローカル変数として path と書いたつもりでも、別の場所にある識別子の大文字小文字に引っ張られて、見た目が変わることがあります。

　実行結果が変わる話ではありません。見た目の問題です。しかし、VBAのコードは保守で読まれることが多く、見た目の揺れは思った以上にストレスになります。

1.2（規約は不自由にするためではなく、迷いを減らすためにある）

　命名規約というと、自由を奪うものに見えることがあります。しかし、VBAのように言語側の癖がある環境では、規約は迷いを減らすために使います。

　毎回 path にするか、Path にするか、strPath にするかを悩むより、チームや講座で「文字列なら sPath にしよう」と決めておいたほうが、コードを書く速度もレビューの速度も上がります。

　規約の目的は、きれいな名前を競うことではありません。あとから読む人が、同じルールで同じように読めることです。

第2章（候補になる命名パターン）

　この章では、VBAのローカル変数でよく候補に上がる命名パターンを整理します。

2.1（path）

　path は、意味としてはもっとも自然です。ファイルパスを表すなら、余計な接頭辞を付けずに path と書くのは分かりやすい考え方です。

　ただし、VBAでは大文字小文字の表示が他の識別子に影響されることがあります。そのため、自然な名前であっても、エディタ上の見た目が安定しない可能性があります。

2.2（Path）

　Path と先頭を大文字にする方法もあります。VBAのプロパティ名やメソッド名に近い見た目になるため、一見すると統一感があります。

　一方で、ローカル変数として見ると、変数なのかプロパティなのかが分かりにくくなる場合があります。短いコードでは問題にならなくても、長い業務マクロでは読み手が迷うことがあります。

2.3（strPath）

　strPath は、文字列であることが明確です。昔ながらのハンガリアン記法に近く、慣れている人には読みやすい名前です。

　ただし、毎回 str、lng、int のように詳しく付けていくと、名前が長くなります。また、VBAでは Integer と Long を厳密に分けるより、実務上は数値として扱えれば十分な場面も多くあります。

2.4（sPath）

　strPath を短くした実務的な形が sPath です。文字列であることを1文字で示しつつ、名前全体は短く保てます。

　筆者としては、VBAのローカル変数では、この形がかなり扱いやすいと考えています。型のヒントがあり、変数であることも分かり、VBAの大文字小文字問題も避けやすいからです。

第3章（基本の型接頭辞）

　この章では、VBAのローカル変数に付ける接頭辞を、実務で使える範囲に絞って整理します。

3.1（文字列は s）

　文字列は s を付けます。

vb

Dim sPath As String

Dim sName As String

Dim sMessage As String

　strPath と書いても間違いではありません。しかし、日常的に使うローカル変数では、sPath で十分です。大事なのは、文字列であることが一目で分かることです。

3.2（数値は n）

　数値は n を付けます。

vb

Dim nCount As Long

Dim nRow As Long

Dim nTotal As Double

　厳密に言えば、整数、長整数、実数は別物です。しかし、ローカル変数名の接頭辞として、毎回 int、lng、dbl を使い分ける必要があるかは別問題です。

　実務上は、まず n で数値であることを示し、必要がある場合だけ rn のように実数であることを補助的に表す、という考え方で十分なことが多いです。

3.3（日付は d）

　日付は d を付けます。

vb

Dim dToday As Date

Dim dStart As Date

Dim dEnd As Date

　日付は文字列や数値と混ざると不具合の原因になりやすい型です。そのため、日付を表す変数には、明確に d を付けておく価値があります。

3.4（配列は a だけで決めない）

　配列には a を付ける案があります。

vb

Dim aNames As Variant

Dim anCounts As Variant

　ただし、配列やコレクションは、接頭辞だけで表すより、名前を複数形にしたほうが読みやすいことがあります。たとえば counts と書けば、複数の件数を持っていることが自然に伝わります。

　そのため、配列については、a を必須にするよりも、複数形を優先し、必要な場合だけ型の情報を補う、という扱いが現実的です。

第4章（Booleanは型ではなく意味で読む）

　この章では、Boolean変数を b 接頭辞で扱うべきかを整理します。

4.1（bFlag は便利だが弱い）

　Booleanだから b を付ける、という考え方は分かりやすいものです。

vb

Dim bExists As Boolean

Dim bSuccess As Boolean

　ただし、Boolean変数で本当に大事なのは、型がBooleanであることよりも、何が真なら True なのかです。

　bFlag のような名前は、Booleanであることは分かります。しかし、何のフラグなのかは分かりません。これでは、読み手は条件式の中身を追わなければ意味を判断できません。

4.2（is と has を優先する）

　Booleanは、is や has で始めると読みやすくなります。

vb

Dim isDir As Boolean

Dim hasNext As Boolean

Dim isEmpty As Boolean

　この形にすると、条件式の中で自然に読めます。

vb

If isDir Then

' フォルダーとして処理する

End If

　Booleanでは、型の接頭辞よりも、条件文として読めることを優先したほうが、保守しやすいコードになります。

第5章（x接頭辞という逃げ方）

　この章では、筆者が使ってきた x 接頭辞の考え方を整理します。

5.1（x は何かが付いていることを示す）

　筆者は以前から、ローカル変数に x を付けることがあります。たとえば、path ではなく xpath のように書く方法です。

　これは、s、n、d のように型を正確に表すというより、ローカル変数として何かしらの接頭辞を付け、VBAの見た目の問題を避けるための実務的な逃げ方です。

　x で始まる日常的な英単語は多くないため、x が接頭辞であることも比較的分かりやすくなります。

5.2（ただし標準化するなら s/n/d がよい）

　x 接頭辞は、自分のコードでは便利です。しかし、講座やチームの標準として説明するなら、s、n、d のほうが伝わりやすくなります。

　xPath なのか、xpath なのか、x_path なのかという別の揺れも生まれます。標準としては、文字列は sPath、数値は nCount、日付は dToday と決めたほうが説明しやすくなります。

第6章（実務規約としての落としどころ）

　この章では、ここまでの内容を、実際に使える命名規約としてまとめます。

6.1（推奨ルール）

　VBAのローカル変数では、次のルールを推奨します。

4. 文字列は s を付ける。

5. 数値は n を付ける。

6. 日付は d を付ける。

7. Booleanは is、has、can など、条件として読める名前にする。

8. 配列やコレクションは、まず複数形で表す。

9. 必要に応じて、配列や実数などの補助情報を接頭辞で足す。

10. 接頭辞の後ろの単語は、読みやすいキャメルケースにする。

　この程度であれば、規約として重すぎません。しかも、コードを読むときに型と意味の両方が見えます。

6.2（例）

　次のような名前を基本形にします。

vb

Dim sPath As String

Dim sFileName As String

Dim nCount As Long

Dim nRow As Long

Dim dToday As Date

Dim isDir As Boolean

Dim hasNext As Boolean

Dim names As Variant

Dim counts As Variant

　配列を明確にしたい場合は、プロジェクト内で合意したうえで aNames や anCounts のような形を使っても構いません。ただし、複数形で十分に意味が伝わるなら、無理に接頭辞を増やさないほうが読みやすくなります。

6.3（規約は短く、例を多くする）

　命名規約は、長く書くほど守られにくくなります。細かい例外を増やすより、代表例をいくつか示し、迷ったときに真似できる形にするほうが実務では機能します。

　講座やチームで伝えるなら、「文字列は sPath、数値は nCount、日付は dToday、Booleanは isDir や hasNext」という程度から始めるのがよいです。

第7章（この規約で避けられること）

　この章では、この命名規約を使うことで、どのような混乱を避けられるのかを整理します。

7.1（大文字小文字の見た目に振り回されにくくなる）

　path のような名前をそのまま使うと、VBAエディタ上の見た目が他の識別子に引っ張られることがあります。sPath のように接頭辞を付けると、その揺れを避けやすくなります。

　これは、実行速度や機能の問題ではありません。しかし、コードレビューや保守では、見た目の安定は重要です。

7.2（型の誤読が減る）

　sPath とあれば文字列、nCount とあれば数値、dToday とあれば日付だと分かります。

　もちろん、最終的には宣言を見るべきです。しかし、業務マクロでは、長い処理の途中で変数を読むことが多くあります。そのとき、名前から型の見当が付くことは、読みやすさに直結します。

7.3（条件式が自然に読める）

　Booleanを isDir、hasNext のように書くと、条件式が文章に近くなります。

vb

If hasNext Then

' 次の要素を処理する

End If

　bFlag よりも、何を判断しているのかが明確です。Booleanでは、型より意味を優先する理由がここにあります。

第8章（まとめ）

　VBAのローカル変数名は、完全に自由に決めるより、軽い規約を持ったほうが安定します。

　文字列は sPath、数値は nCount、日付は dToday。Booleanは isDir や hasNext。配列やコレクションは、まず複数形で読む。これくらいの規約であれば、書く側にも読む側にも負担が少なく、VBA特有の見た目の揺れも避けやすくなります。

　重要なのは、型接頭辞を信仰することではありません。VBAの癖を理解したうえで、コードを読む人の迷いを減らすことです。そのための実務的な落としどころとして、s、n、d を中心にした、ゆるいVBAハンガリアンを採用するのがよいと考えます。

元記事・出典メモ

　この記事は、筆者自身のPosfieまとめ「2022-01-14 VBA ローカル変数の規約をどうするか」をもとに、LWP記事向けに再構成したものです。

• 元URL: https://posfie.com/@hoehoe1234/p/hNWX4kT

• 元まとめタイトル: 2022-01-14 VBA ローカル変数の規約をどうするか

• 元投稿者: ほえほえ＠マクロ師のひとりごとDX/AX

• 取得日: 2026-05-14

• 再構成方針: 筆者自身の投稿内容を中心に、外部投稿の長文引用は避け、VBAローカル変数命名規約の記事として再編集