--- title: "プログラミングの命名規則を英語で書く方法｜ケース・動詞・対義語ペアと変数名の実例" url: "https://www.issoh.co.jp/column/details/2328/" published: 2024-05-30 updated: 2026-07-18 categories: ["Webシステム"] publisher: "株式会社一創" --- # プログラミングの命名規則を英語で書く方法｜ケース・動詞・対義語ペアと変数名の実例 変数や関数を英語でどう名付けるかは、コードを書くたびに立ち止まりがちな作業だ。日本人エンジニアが迷うのは「命名が大事な理由」ではなく、**どの単語を、どの形式（ケース）で、どういう規則で並べるか**という具体である。この記事は、命名規則を英語で書くための実務ルールを、ケースの使い分け・関数に使う動詞と対義語ペア・変数名でよく使う英単語一覧・命名支援ツール・避けるべきミスまで、そのまま真似できる形でまとめる。ローマ字や和製英語から抜け出し、チームで読めるコードにするための土台として使ってほしい。 ## まとめ：英語での命名で押さえる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種類を用途とともに示す。 | ケース | 例 | 主な用途 | | -------------------------- | ------------ | --------------------------- | | camelCase | userName | 変数・関数（JavaScript / Java） | | snake\_case | user\_name | 変数・関数（Python / Ruby / DB列名） | | PascalCase（UpperCamelCase） | UserProfile | クラス・型・コンポーネント | | SCREAMING\_SNAKE\_CASE | MAX\_COUNT | 定数 | | kebab-case | user-profile | URL・CSSクラス・HTML属性 | 迷ったら「その言語の公式スタイルガイドが定めるケースに合わせる」でよい。定数だけはほとんどの言語で 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` と、動作の性質で使い分ける。目的別に整理する。 | 目的 | よく使う動詞 | | ----- | -------------------------------------------------- | | 取得・参照 | get / fetch / load / read / find / search / select | | 生成・作成 | create / generate / build / make | | 追加・挿入 | add / insert / append / push / register | | 更新・変更 | update / set / change / modify / edit | | 削除・破棄 | delete / remove / clear / destroy | | 判定・検証 | validate / check / verify | | 変換・整形 | convert / parse / format / to○○（toString） | 「登録」を `add` と `register` のどちらにするかのような揺れは、プロジェクト内で1語に決めておくと迷いが消える。 ### 対で揃える対義語ペア 「開く」があるなら「閉じる」もある。**反対の動作は対義語ペアで統一する**と、片方の名前からもう片方が推測でき、コード全体の予測可能性が上がる。よく使うペアを挙げる。 | 動作 | 対義語ペア | | ------- | ---------------------------- | | 取得／設定 | get / set | | 追加／削除 | add / remove | | 作成／削除 | create / delete | | 開く／閉じる | open / close | | 開始／停止 | start / stop | | 有効化／無効化 | enable / disable | | 表示／非表示 | show / hide | | 最小／最大 | min / max | | 最初／最後 | first / last | | 前／次 | previous / next | | 送信元／送信先 | source / target（destination） | 混ぜてはいけないのは、同じ意味に `delete` と `remove` の両方を場当たりで使うこと。ペアは覚えつつ、プロジェクト内では「配列からの除去は `remove`、DBからの消去は `delete`」のように役割を決めて固定する。 ## 変数名でよく使う英単語と略語一覧 変数名は動詞ではなく名詞が中心になる。頻出する単語と、許容される略語を一覧にしておくと、命名の初速が上がる。 | 意味 | 推奨語 | 一般的な略語 | | ------- | ------------------ | ------------ | | 件数・カウント | count / number | cnt / num | | 連番・添字 | index | idx / i, j | | 一時変数 | temporary | temp / tmp | | 配列・一覧 | list / array | arr | | 設定 | configuration | config / cfg | | 結果 | result | res | | 要求／応答 | request / response | req / res | | エラー | error | err | | メッセージ | message | msg | | 識別子 | identifier | id | | フラグ・状態 | flag / status | — | 略語は**広く知られた慣用に限る**のが原則だ。`idx` や `tmp` のように誰でも復元できる略語は問題ないが、独自に縮めた `usr` や `btn2` は読み手を止める。`request` と `response` をどちらも `res` と略すと衝突するため、片方は略さないといった配慮も要る。時刻は `createdAt`／`updatedAt` のように動詞の過去分詞＋`At` でそろえると、DB列名との対応も取りやすい。 ## 場面別・命名でよく使う英単語集 命名で迷う多くは、扱う対象を表す名詞が出てこない場面だ。開発で頻出する語を場面別にまとめておくと、辞書を引く回数が減る。以下は変数名・プロパティ名の素材として使いやすい基本語彙である。 | 場面 | よく使う英単語 | | ------- | ------------------------------------------------------------------------------------- | | ユーザー・認証 | user / account / login / logout / password / permission / role / session / token | | データ操作 | data / record / item / entry / value / field / column / row / key | | 状態・フラグ | status / state / active / enabled / valid / visible / selected / current / default | | 日時 | date / time / timestamp / duration / period / start / end / expired | | 画面・UI | page / view / button / label / title / message / modal / dialog / menu / form / input | | 数量・範囲 | count / total / sum / amount / size / length / min / max / limit / offset | これらは組み合わせて具体化する。ユーザーの一覧なら `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` が標準だ。主要言語の基本を一覧にする。 | 言語・領域 | 変数・関数 | クラス・型 | 定数 | | ---------- | --------------------------- | ---------- | ---------------------- | | Python | snake\_case | PascalCase | SCREAMING\_SNAKE\_CASE | | Java | camelCase | PascalCase | SCREAMING\_SNAKE\_CASE | | JavaScript | camelCase | PascalCase | SCREAMING\_SNAKE\_CASE | | C# | 変数camelCase／メソッドPascalCase | PascalCase | PascalCase | | Go | MixedCaps（公開=先頭大文字／非公開=小文字） | MixedCaps | MixedCaps | | HTML / CSS | kebab-case | — | — | なお定数はSCREAMING\_SNAKE\_CASE、URL・CSSはkebab-caseが言語をまたいで共通だが、C#とGoは変数・定数ともに独自のケースを使うため例外として扱う。言語別の詳細な規則は個別に確認したい。プログラミング言語ごとの命名規則は[Python・Java・JavaScript・C++の命名規則をまとめた記事](/tech/details/2339/)、フレームワーク単位では[Laravel（PHP）の命名規則一覧](/tech/details/5468/)、Pythonの公式スタイルは[コーディング規約PEP8の解説](/tech/details/3032/)で扱っている。英語での単語選びを本記事で固め、ケースの詳細は各言語の記事で補完すると迷いが減る。 ## よくある質問 ### 命名規則は英語で何といいますか 「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++）の命名規則](/tech/details/2339/) - [Laravel（PHP）の命名規則一覧](/tech/details/5468/) - [PythonのコーディングルールPEP8の解説](/tech/details/3032/) --- 出典: [プログラミングの命名規則を英語で書く方法｜ケース・動詞・対義語ペアと変数名の実例]()（株式会社一創）