命名規則を英語で書く方法｜ケース・品詞・対義語と公式ガイドの規定

命名規則は英語で naming convention といいます。変数名や関数名を英語で付けるときに迷うのは、どのケース（camelCase など）で書くか、どの品詞を使うか、同じ意味の動詞のどれを選ぶか、の3点です。この記事では各言語の公式スタイルガイドの規定を引きながら、そのまま使える命名の型と英単語の一覧をまとめます。言語ごとの細かな規約はプログラミングの命名規則まとめ｜キャメルケース・スネークケースの違いとPythonのファイル名など6言語の書き方で扱っているので、ここでは英語の単語選びと文法の側に絞ります。

まとめ：英語で名前を付けるときの要点

• ケースは言語のガイドに合わせます。Python は関数・変数が snake_case、Java は lowerCamelCase、C# の公開メンバーは PascalCase、定数は Python・Java・Rust が UPPER_SNAKE_CASE で C# は PascalCase です。
• 品詞で役割を示します。クラスと変数は名詞、処理を行う関数は動詞で始めます。真偽値は isEmpty・hasPermission・canEdit のように、条件文に入れて英文として読める形にします。
• getを付けない言語があります。Go と Rust の公式ガイドでは、getter に通常 get を付けず、Owner()・first() のようにフィールド名を基本に書きます。
• 反対の操作は対義語ペアでそろえます。open/close、add/remove、min/max のように片方から他方を推測できる組を使います。
• 単語の確かめ方を持っておきます。命名辞書の codic.jp は2026年10月25日時点で接続できない状態です。辞書で品詞と可算・不可算を確かめ、GitHub のコード検索で実際の使用例を見る方法に切り替えます。

識別子を英語でそろえる根拠

Python の公式スタイルガイド PEP 8 は、標準ライブラリの識別子について「ASCII だけで書かなければならず（MUST）、できる限り英単語を使うべき（SHOULD）」と定め、世界中の利用者がいるオープンソースにも同じ方針を勧めています。言語の文法上は日本語の変数名も書けますが、標準ライブラリや主要なフレームワークの名前が英語で書かれている以上、自分のコードだけローマ字や日本語にすると、user.get_kingaku() のように一文の中で言語が切り替わります。

社外に出る可能性が少しでもあるコードは識別子を英語にそろえ、日本語は補足のコメントに残します。英訳が定まらない業務用語（例：稟議）は、チームの用語集で英訳を1つ決めて全員がその語を使います。

ケース（記法）の選び方と公式ガイドの規定

複数の単語をつなぐ書き方をケースと呼びます。ケースは採用するスタイルガイドに合わせます。既存コードに別の規約がある場合は、プロジェクト内の一貫性を優先します。

主要7言語の変数・関数・クラス・定数のケース

Java の大文字の規定は Google Java Style Guide の5.2 にあり、定数を UPPER_SNAKE_CASE と呼んでいます。C# は Microsoft の C# 識別子の命名規則が、定数をフィールドもローカルも PascalCase で書き、private の非定数インスタンスフィールドは _camelCase、static フィールドは s_camelCase、スレッド静的フィールドは t_camelCase とする慣習を紹介しています。他の言語の感覚で C# の定数を MAX_COUNT と書くと、このガイドから外れます。Go はアンダースコアを使わず、先頭が大文字かどうかでパッケージ外への公開・非公開が決まります。

HTMLの標準属性名は仕様で決まり、tabindexのようにハイフンを含まないものもあります。URL のパスや CSS のクラス名では、user-profile のような kebab-case が一般的です。

略語（HTTP・ID・XML）の大文字の扱い

略語を含む名前について、4つのガイドの規定を比較します。ここは英語力ではなく、どのガイドに従うかで答えが決まる部分です。

PEP 8 は Descriptive: Naming Styles の節で「HttpServerError より HTTPServerError がよい」と書き、Google Java Style Guide は 5.3 Camel case: defined で XMLHTTPRequest を誤りの例に挙げています。正反対なので、複数言語を扱うチームでは「その言語のガイドに従う」とだけ決めておくのが安全です。

品詞の使い分けと語順

英語の名前は、品詞で「値なのか処理なのか」を伝えます。Google Java Style Guide は、クラス名を名詞または名詞句、メソッド名を動詞または動詞句（sendMessage・stop）と定めています。

名詞・動詞・形容詞の役割

• 変数・プロパティ・クラスは名詞です。total・errorMessage・OrderRepository のように、何を持っているかを表します。
• 処理をする関数は動詞から始めます。calculateTotal・sendEmail のように、何をするかを表します。
• 能力を表す型は形容詞にします。Swift API Design Guidelines は、能力を表すプロトコルに able・ible・ing を付けると定め、Equatable・ProgressReporting を例に挙げています。Java の Readable も同じ形です。

英語の命名における修飾語の位置と語順

英語では修飾語を前に置きます。「商品の状態」は conditionOfItem ではなく itemCondition、「最大件数」は countMax より maxCount が自然です。of を使うと名前が長くなり、並べたときに先頭の語がそろいません。

一方、条件を後ろに付けたいときは前置詞が役に立ちます。usersWithoutPermission（権限の無いユーザー）や itemsBeforeShipping（発送前の商品）は、形容詞1語では言えない条件を短く表せます。

単数・複数と、sを付けない不可算名詞

1件は単数（user）、配列やリストは複数（users）にすると、for user in users がそのまま読めます。

注意が要るのは不可算名詞です。Cambridge Dictionary は information を不可算名詞（[U]）としているので、informations とは書きません。software・equipment・feedback も不可算名詞です。data は不可算名詞として使われるほか、datum の複数形としても使われます。これらに s を付けた datas などは英語として不自然なので、複数件を表したいときは dataItems・feedbackList のように数えられる語を足します。

真偽値（boolean）の命名パターン

真偽値は、条件文に入れたときに英語の文として読めるかどうかで良し悪しが決まります。Swift API Design Guidelines は「状態を変えない Bool のメソッドとプロパティは、対象についての断定として読めるように」と定め、x.isEmpty を例にしています。

避けたいのは否定形の名前です。isNotEmpty や disableCache を条件に入れると、if (!isNotEmpty) のような二重否定が生まれます。肯定形の isEmpty・cacheEnabled にして、否定は呼び出し側の ! に任せます。Microsoft の 型メンバーの名前のガイドも、Boolean プロパティには CanSeek のような肯定形の句を使うよう求め、Is・Can・Has は意味を足すときだけ付けてよいとしています。

言語の文法で真偽値を表す場合もあります。Ruby は empty? のようにメソッド名の末尾に ? を付ける慣習があり、この場合は is を付けません。

日時・件数・IDを表す接尾辞

名前の末尾は、値の種類を伝える場所として使えます。

• 日時は動詞の過去分詞＋at：Rails は Active Record の規約で、作成時に created_at、作成・更新時に updated_at を自動で入れます。日付だけなら published_on のように on を使い分ける流儀もあります。
• 件数は Count：users と書くと配列と区別できないので、userCount とします。
• 識別子は Id：orderId とし、大文字の扱いは上の略語の表に従います。
• 単位を付ける：timeout だけでは秒かミリ秒かわからないので、timeoutMs・fileSizeBytes のように単位まで名前に入れます。

関数名の動詞：目的別一覧と紛らわしい語の使い分け

関数名に使う目的別の動詞一覧

Google Java Style Guideは、メソッド名に動詞または動詞句を使うとし、sendMessageやstopを例に挙げています。次の一覧は、処理内容に合う動詞を選ぶための候補です。

get・fetch・find、check・validate・verify、delete・remove の違い

以下は、チームで採用する使い分けの一案です。既存APIでは異なる意味でも使われるため、処理の重さや戻り値は仕様で確認します。たとえばPythonのRequestsでは、getもHTTP通信を行います。

• getは手元にある値をすぐ返すとき、fetchはAPIやDBなど外へ取りに行くとき、findは条件で探して見つからない可能性があるときに使います。getUser がネットワーク通信をしていると、呼び出し側は待ち時間を想定できません。
• checkは真偽を返すだけ、validateは入力が規則に合うかを調べて違反を報告するとき、verifyは署名やトークンなど正しさを照合するときに使います。
• removeは集まりから取り除く（要素自体は残りうる）とき、deleteは保存先から消すときに使います。removeItem はカートから外す、deleteItem は商品データを消す、と読めます。

getを付けない言語：GoとRust

「値の取得は get」は Java の流儀で、全言語の決まりではありません。Effective Go は、owner フィールドの getter を GetOwner ではなく Owner と書き、setter は SetOwner とする例を示しています。Rust API Guidelines の C-GETTER も、少数の例外を除いて get_ を付けず first()・first_mut() と書くと定めています。

Rust には変換の重さを接頭辞で示す規定（C-CONV）もあります。

Go の1メソッドのインターフェースは、メソッド名に -er を付けて Reader・Writer のように動作する主体の名詞にする慣習があります。Go や Rust で Java と同じ感覚の getName を書くと、ガイドに沿っていないコードとして読まれます。

元の値を変える処理と変えない処理の語形

Swift API Design Guidelines は、副作用のあるメソッドを命令形の動詞（x.sort()）、副作用のないメソッドを名詞句か過去分詞・現在分詞（x.sorted()・x.appending(y)）で書くと定めています。動詞の形だけで、元の配列が書き換わるかどうかがわかる仕組みです。Python と JavaScript の標準APIも同じ形をとっています。

# Python 3.14.6
a = [3, 1, 2]
b = sorted(a)     # 新しいリストを返す。a は [3, 1, 2] のまま
a.sort()          # a 自体を並べ替え、戻り値は None
# JavaScript（Node v26.5.0）では a.toSorted() が新しい配列を返し、a.sort() は元を書き換える

自作の関数でも、元を書き換えるなら normalize()、新しい値を返すなら normalized() と分けると、呼び出し側で戻り値を捨てる誤りが減ります。

対義語ペアの一覧（動詞・名詞）

反対の操作は対になる単語でそろえると、open があれば close もあると読み手が推測できます。

避けたいのは、ペアの片方だけを別の系統にすることです。start と end、begin と stop のように混ぜると、対の相手を毎回探すことになります。error の反対側は文脈で変わり、Rust の Result 型は成功を Ok、失敗を Err という2つのバリアントで表します。アプリケーションでジョブの結果を表すなら success / failure の組が使えます（HTTP のステータスはRFC 9110で5分類に分かれるので、二択の名前は当てはまりません）。

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

通じる略語と避けたい略語

略語は、誰が見ても元の語に戻せるものに限ります。usr・btn2・prcs は、文脈によって意味が曖昧になります。Swift API Design Guidelinesも非標準の略語を避けるよう勧めているため、共有された慣習がなければ元の語で書きます。res は result とも response とも読めるので、両方が出てくる関数では片方を略さずに書きます。

場面別の基本語彙

status と state はどちらも「状態」ですが、status は処理の結果や段階（orderStatus：受付・発送済み）、state は画面やオブジェクトが今持っている値の集まり（React の state）に使うのが一般的です。

英単語に迷ったときの調べ方：codicの現状と代わりの手段

日本語を入れると英語の名前の候補を返す「codic（プログラマーのためのネーミング辞書）」は、2026年10月25日時点で codic.jp・api.codic.jp とも接続を受け付けていません。Internet Archive に HTTP 200 で保存された最新の記録は2026年7月16日ですが、保存日時だけでは停止の時期はわからず、運営側の終了告知も見つかっていません。一時的な停止か終了かは判断できないため、codic だけに頼らない調べ方を持っておきます。

代わりに、次の2段階で単語を確かめます。

1. 辞書で品詞と可算・不可算を確かめます。英英辞典の Cambridge Dictionary は名詞に [C]（可算）・[U]（不可算）の記号を付けているので、s を付けてよいかがその場でわかります。和英辞典で候補を出したら、英英辞典で意味の範囲を確かめると和製英語を避けられます。
2. GitHub のコード検索で実際の使われ方を見ます。GitHub Docs のコード検索構文にある language: の絞り込みを使い、たとえば "isDeleted" language:java と "isRemoved" language:java を比べると、それぞれがどのような状態や処理を表しているかを実際のコードで確かめられます。

生成AIの候補も使えますが、そのまま採ると同じプロジェクトに fetchUser・getUserInfo・loadUserData が混在しがちです。品詞・語順・対義語のルールに合うかは自分で確かめます。

英語の命名で避けるミス

• ローマ字と英語の混在：getKingaku は英語話者にも日本語話者にも読みにくくなります。業務用語は用語集で英訳を決めます。
• 和製英語：「マンション」を mansion（英語では大邸宅）、「クレーム」を claim（英語では請求・主張）とすると意味がずれます。apartment・complaint を使います。
• 中身の無い名前：data2・tmpList・flag は何が入っているかを伝えません。retryCount・pendingOrders のように中身を書きます。
• 型名を名前に入れる：strName・userArray は、型を変えたときに名前と中身がずれます。複数形の users で足ります。
• スペルミス：recieve（正しくは receive）・lenght（正しくは length）は検索で見つからなくなります。エディタのスペルチェッカーを有効にします。

命名規約を決めても、守られなければ効果はありません。Python なら Ruff の N 系ルールで検出でき、Ruff 0.17.2 では class my_class: が「N801 Class name my_class should use CapWords convention」として報告されます。C# なら .editorconfig の命名ルールで違反を警告にできます。PEP 8 全体の扱いはPEP8とは？Pythonコーディング規約の基本ルールとチェックツール（Ruff対応）にまとめています。名前を一括で付け直すときの進め方はリファクタリングとは？24の観点とタイミング・進め方が参考になります。既存システムの命名がばらばらで手が付けられない場合は、保守運用・内製化支援の中で規約づくりと既存コードの整理から相談いただけます。

よくある質問

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

naming convention（ネーミングコンベンション）といいます。変数・関数・クラス・ファイルなどの名前をどのケースで書き、どの品詞や接頭辞を使うかを決めた取り決めのことです。naming rule と書く例もありますが、PEP 8 や Effective Go などの公式文書では naming conventions が使われています。

コーディング規約は英語で何といいますか？

coding conventions、coding standards、style guide のいずれかで呼ばれます。Python の PEP 8 は Style Guide for Python Code、Google は Google Java Style Guide という名前です。命名規則（naming conventions）はコーディング規約の一部です。

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

動作はしますが、おすすめしません。英訳が定まらない業務用語だけは、チームの用語集に英訳を1つ決めて使います。

createの対義語はdeleteとdestroyのどちらですか？

どちらも使われます。データを消す一般的な処理なら create / delete の組が多く、Rails では destroy がコールバックを実行して消し、delete はコールバックを飛ばして消すという違いがあります（Rails ガイドの Skipping Callbacks）。使っているフレームワークの語に合わせます。

日本語の変数名は使えますか？

Python 3 と JavaScript では書けて、そのまま動きます。ただし入力の手間や海外のメンバーが読めないことを考えると、業務のコードでは英語にそろえるほうが扱いやすくなります。言語別の書き方の違いはプログラミングの命名規則まとめの各言語の章を参照してください。

関連記事

• プログラミングの命名規則まとめ｜キャメルケース・スネークケースの違いとPythonのファイル名など6言語の書き方
• PEP8とは？Pythonコーディング規約の基本ルールとチェックツール（Ruff対応）
• Laravelの命名規則一覧｜テーブル・モデル・コントローラーとコーディング規約【Laravel 13対応】
• リーダブルコードとは？読みやすいコードの4原則と書籍のエッセンス
• リファクタリングとは？24の観点とタイミング・進め方