プログラミングの命名規則を英語で書く方法｜ケース・動詞・対義語ペアと変数名の実例

変数や関数を英語でどう名付けるかは、コードを書くたびに立ち止まりがちな作業だ。日本人エンジニアが迷うのは「命名が大事な理由」ではなく、どの単語を、どの形式（ケース）で、どういう規則で並べるかという具体である。この記事は、命名規則を英語で書くための実務ルールを、ケースの使い分け・関数に使う動詞と対義語ペア・変数名でよく使う英単語一覧・命名支援ツール・避けるべきミスまで、そのまま真似できる形でまとめる。ローマ字や和製英語から抜け出し、チームで読めるコードにするための土台として使ってほしい。

まとめ：英語での命名で押さえる5点

• ケースは言語の慣習に従う。変数・関数は camelCase か snake_case、クラスは PascalCase、定数は SCREAMING_SNAKE_CASE、URLやCSSは kebab-case が基本。
• 品詞で役割を示す。変数は名詞（userName）、関数は動詞＋名詞（getUser）、真偽値は is／has／can で始める。
• 動詞は対で覚える。get／set、add／remove、open／close のように対義語ペアで揃えると、コード全体の一貫性が上がる。
• 英単語に迷ったら、日本語を入力して命名候補を返す codic のようなネーミング辞書を使い、最終判断は自分で下す。
• ローマ字（namae）・和製英語・意味のない省略（data2）・否定形の真偽値は避ける。

以下で、ケース・品詞・単語選び・ツール・ミスの順に具体を見ていく。

英語で命名する理由と、ローマ字を使わない判断

プログラミング言語のキーワードや標準ライブラリはすべて英語で書かれている。そこにローマ字（kingaku）や日本語を混ぜると、英語の予約語・メソッド名との間で語感が途切れ、読み手は毎回「これは何語か」を意識させられる。英語で統一された名前は、コードそのものが短い説明文として機能するため、可読性・保守性・レビュー効率のすべてに効く。

実務上の判断はシンプルだ。識別子は英語で統一し、ローマ字は使わない。GitHubなどで公開・共同開発する可能性がある限り、英語以外の選択肢は将来の負債になる。日本語コメントは補足として残してよいが、変数名・関数名・クラス名の本体は英語にする。以降のルールは、この前提のうえで「どう英語にするか」を詰めるものだ。

英語命名の3つの土台：ケース・品詞・単数複数

英語での命名は、見た目の形式（ケース）・単語の品詞・数の3点を押さえれば大半が整う。それぞれ独立した判断なので順に確認する。

ケース（記法）の種類と使い分け

複数の単語をつなぐ書き方を「ケース」と呼ぶ。どのケースを使うかは言語の慣習で決まっており、好みで選ぶものではない。代表的な5種類を用途とともに示す。

迷ったら「その言語の公式スタイルガイドが定めるケースに合わせる」でよい。定数だけはほとんどの言語で SCREAMING_SNAKE_CASE、URLとCSSは kebab-case が共通なので、ここは言語をまたいで覚えておくと使い回せる。

品詞のルール：変数は名詞、関数は動詞＋名詞

名前の品詞は、その識別子が「値」か「動作」かを示す。読み手はこの品詞で役割を推測するため、崩すと誤読を招く。

• 変数・プロパティ＝名詞。total、userList、errorMessage のように「何を保持しているか」を表す。
• 関数・メソッド＝動詞＋名詞。getUser、calculateTotal、sendEmail のように「何をするか」を表す。
• 真偽値（boolean）＝ is／has／can などで始め、条件文で自然に読める形にする。isEmpty、hasPermission、canEdit なら if (isEmpty) がそのまま英文として通る。

この3分類を守るだけで、名前を見た瞬間に「値か・処理か・条件か」が判別でき、コードを追う速度が変わる。

単数形と複数形でコレクションを示す

英語の名前は単数・複数で「1件か・複数件か」を表現できる。1件の値は単数（user）、配列やリストは複数（users）にすると、ループの意図が名前だけで伝わる。

数えにくい概念は明示語を添える。件数は userCount、リスト構造を強調するなら userList、連番のインデックスは index や i を使う。users と userList を同じコード内で混在させないなど、チーム内で一方に統一することが一貫性のカギになる。

関数名でよく使う英語動詞と対義語ペア

関数名の質は、先頭の動詞をどれだけ的確に選べるかで決まる。ここが英語命名で最もつまずきやすい部分なので、目的別の動詞と、対で覚える対義語ペアを一覧化する。

目的別・関数の動詞一覧

同じ「取得」でも、単純参照は get、外部からの読み込みは fetch や load、検索は find や search と、動作の性質で使い分ける。目的別に整理する。

「登録」を add と register のどちらにするかのような揺れは、プロジェクト内で1語に決めておくと迷いが消える。

対で揃える対義語ペア

「開く」があるなら「閉じる」もある。反対の動作は対義語ペアで統一すると、片方の名前からもう片方が推測でき、コード全体の予測可能性が上がる。よく使うペアを挙げる。

混ぜてはいけないのは、同じ意味に delete と remove の両方を場当たりで使うこと。ペアは覚えつつ、プロジェクト内では「配列からの除去は remove、DBからの消去は delete」のように役割を決めて固定する。

変数名でよく使う英単語と略語一覧

変数名は動詞ではなく名詞が中心になる。頻出する単語と、許容される略語を一覧にしておくと、命名の初速が上がる。

略語は広く知られた慣用に限るのが原則だ。idx や tmp のように誰でも復元できる略語は問題ないが、独自に縮めた usr や btn2 は読み手を止める。request と response をどちらも res と略すと衝突するため、片方は略さないといった配慮も要る。時刻は createdAt／updatedAt のように動詞の過去分詞＋At でそろえると、DB列名との対応も取りやすい。

場面別・命名でよく使う英単語集

命名で迷う多くは、扱う対象を表す名詞が出てこない場面だ。開発で頻出する語を場面別にまとめておくと、辞書を引く回数が減る。以下は変数名・プロパティ名の素材として使いやすい基本語彙である。

これらは組み合わせて具体化する。ユーザーの一覧なら userList、選択中のアイテムなら selectedItem、最大件数なら maxCount のように、場面語＋前掲の品詞ルールで大半の名前が組み立てられる。語の意味がぶれやすい data や value は単体では避け、userData／inputValue のように何のデータ・値かを添えると読みやすい。

日本語から英語名を導くツール「codic」の使い方と限界

適切な英単語が思いつかないときに役立つのが、プログラマー向けのネーミング辞書 codic（codic.jp）だ。日本語の語句を入力すると、プログラミングで使いやすい英語表記を返してくれる。

• 無料・登録不要でブラウザからそのまま使える。
• 出力形式を camelCase / snake_case / PascalCase / SCREAMING_SNAKE_CASE から選択できるため、言語の慣習に合わせてそのまま貼り付けられる。
• VS Code拡張もあり、エディタ内で命名候補を得られる。

ただしツールの出力を無検証で採用してはいけない。codicは機械的な変換のため、文脈によっては不自然な語や過度に長い名前を返すことがある。候補は当たりを付ける道具と位置づけ、対義語ペアやケースの整合、既存コードとの一貫性は自分で最終確認する。特にチームで既に定めた用語（例：「顧客」を customer と決めているのに client が返る）とのズレは、ツールでは吸収できない。

英語命名で避けるべきミス

良い名前のルールと同じくらい、避けるべきパターンを知っておくと事故が減る。頻出する失敗を挙げる。

• ローマ字表記：kingaku／namae は英語ではない。amount／name にする。
• 和製英語・意味のずれた語：日本語のカタカナ語をそのまま英語だと思い込むと通じない。マンションは mansion（大邸宅）ではなく apartment、ノートPCは note ではなく laptop。辞書で語義を確認する。
• 意味のない省略・連番：a／b／tmp1／data2 は後から読めない。役割を表す語を入れる。
• 否定形の真偽値：isNotValid は二重否定（if (!isNotValid)）で混乱する。isValid にして呼び出し側で否定する。
• 予約語との衝突：class／type／list など言語の予約語・組み込み名は避け、className／itemType のように具体化する。

逆に、過度な省略やチーム未合意の独自略語は「短くて速い」ように見えて、レビューと引き継ぎのたびにコストを生む。タイプ数を削るより、読んで意味が通ることを優先するのが、保守を続けるコードでは正解になる。

言語ごとの命名規則の違い（早見）

ケースの慣習は言語ごとに異なる。同じ「ユーザー名の変数」でも、Pythonなら user_name、JavaScriptなら userName が標準だ。主要言語の基本を一覧にする。

なお定数はSCREAMING_SNAKE_CASE、URL・CSSはkebab-caseが言語をまたいで共通だが、C#とGoは変数・定数ともに独自のケースを使うため例外として扱う。言語別の詳細な規則は個別に確認したい。プログラミング言語ごとの命名規則はPython・Java・JavaScript・C++の命名規則をまとめた記事、フレームワーク単位ではLaravel（PHP）の命名規則一覧、Pythonの公式スタイルはコーディング規約PEP8の解説で扱っている。英語での単語選びを本記事で固め、ケースの詳細は各言語の記事で補完すると迷いが減る。

よくある質問

命名規則は英語で何といいますか

「naming convention（ネーミング・コンベンション）」または「naming rule」と表現する。プログラミング文脈では naming convention が最も一般的で、Wikipediaの項目名や各言語の公式ドキュメントもこの語を使う。

Naming Conventionは具体的に何を決めるものですか

命名規則が定めるのは主に3点だ。単語のつなぎ方を決めるケース（camelCase／snake_caseなど）、識別子の役割を示す品詞（変数は名詞、関数は動詞、真偽値はis/has/can）、そして意味を表す英単語の選び方である。この3点をチームで揃えることで、誰が読んでも意図が伝わるコードになる。

変数名はローマ字でもよいですか

避けるべきだ。ローマ字は英語話者に伝わらず、標準ライブラリの英語名とも語感が合わない。公開・共同開発の可能性がある限り、識別子は英語で統一する。日本語は名前ではなくコメントに残す。

英単語が思いつかないときはどうすればよいですか

ネーミング辞書のcodicに日本語を入力して候補を得るか、英和・和英辞書で語義を確認する。ツールの出力はそのまま使わず、対義語ペアや既存コードとの一貫性を自分で確かめてから採用する。

camelCaseとsnake_caseはどちらを使うべきですか

個人の好みではなく、使う言語の慣習に従う。Python・Rubyは snake_case、JavaScript・Javaは camelCase が標準だ。1つのプロジェクト内で混在させないことが最も重要で、既存コードのスタイルに合わせるのが原則になる。

関連記事

• プログラミング言語別（Python・Java・JavaScript・C++）の命名規則
• Laravel（PHP）の命名規則一覧
• PythonのコーディングルールPEP8の解説