キャメルケース・スネークケース・ケバブケースの違い｜命名規則の一覧と変換ツール

ツールの使い方：入力欄に名前を入れると、入力するたびに camelCase・PascalCase・snake_case・SCREAMING_SNAKE_CASE・kebab-case・Train-Case・dot.case・flatcase の8つに一度に変換し、それぞれに主な使い道を添えて表示します。結果ごとの「コピー」で、その形だけをコピーできます。

• 入れ方：どの形で入れても変換できます。大文字の始まり・_・-・.・空白で単語に分けてから組み立て直します。
• まとめて変換：1行に1つずつ、200行まで入れられます。DB の列名の一覧を貼って、JSON のキー（camelCase）の一覧を作るときに便利です。
• 略語：XMLHttpRequest のように大文字が続く略語は、最後の大文字から次の単語とみなします（xml・http・request）。
• 数字：「数字の前後でも区切る」にチェックを入れると、version2 を version_2 のように数字の前後でも分けます。既定では分けません。
• 英数字以外と送信：日本語や記号は区切りとして取り除きます。入れた名前はこの端末の中だけで変換し、どこにも送信しません。

この記事で実際に動かしたもの：上のツールを Chromium で開いて15種類の名前を入れた結果、lodash と change-case の変換結果の比較、Jackson と Pydantic の自動変換、ESLint・Ruff・Pylint・rustc の命名規則の警告、PostgreSQL で camelCase の列名を作ったときのエラー、ブラウザの dataset と HTTP ヘッダーの大文字小文字の扱いを記録しました。

flowchart TD
    A[入力 getUserName] --> B[単語に分ける<br>大文字・_・-・.・空白]
    B --> C[get / user / name]
    C --> D[つなぎ方を選ぶ]
    D --> E[camel<br>getUserName]
    D --> F[snake<br>get_user_name]

どの書き方も「単語に分ける」「つなぎ方を決める」の2段でできています。よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、記事内ツール（テーマの code.js）を Chromium 153.0.8010.12（Playwright 1.63.0）で開き、名前を入れた結果を読み取りました。変換ライブラリは Node.js 22.23.4 の lodash 4.18.1・change-case 5.4.4、Python 3.13.18 の Pydantic 2.14.3、Java は OpenJDK 21.0.12 と Jackson 2.14（Ubuntu の apt の .deb を作業フォルダーに展開。Maven Central には接続できなかったため、最新版の挙動は公式の変更一覧で確かめました）で実行しています。命名規則の警告は ESLint 10.14.0・Ruff 0.17.4・Pylint 4.1.3・rustc 1.97.0、言語の挙動は Go 1.24.7・Ruby 3.3.6・PHP 8.3.6、DB は PostgreSQL 16.15（作業フォルダーにソケットだけで起動）と SQLite 3.53.1 で確かめました。ブラウザの dataset と HTTP ヘッダーは Chromium と 127.0.0.1 の Node.js のサーバーで確かめています。言語別の規則は PEP 8・Google Java Style Guide・Google JavaScript Style Guide・Effective Go・Go Code Review Comments・Microsoft Learn（C#）・PSR-1・Ruby Style Guide、DB は PostgreSQL の公式ドキュメント、dataset は MDN、環境変数は POSIX で確かめました。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年11月9日）。

キャメルケース・スネークケース・ケバブケースとは（8つの書き方の一覧）

この節では、キャメルケース・スネークケース・ケバブケースを含む8つの書き方の形と別名、主な使い道が一覧で分かります。

プログラムの名前（変数名・関数名・クラス名）には、多くの言語で空白を入れられません。「user login count」の3語を1つの名前にするには、空白の代わりに「大文字で区切る」「記号でつなぐ」のどちらかが要ります。この区切り方の種類が、キャメルケース・スネークケース・ケバブケースです。下の表は、同じ3語を8つの形で書いた結果です（上のツールの出力と同じです）。

「キャメルケース」とだけ言うときは、先頭が小文字の形（ローワーキャメル）を指すことが多く、先頭も大文字の形はパスカルケースと呼び分けます。PEP 8（Python）は先頭も大文字の形を「CapWords」、先頭が小文字の形を「mixedCase」、Go は両方をまとめて「MixedCaps」と呼んでいます。呼び名が違うだけで、形は同じです。

名前の由来と「ケース」の意味

この節では、キャメル・スネーク・ケバブという呼び名の由来と、「ケース」が何を指すのかが分かります。

「ケース」はふだんの日本語では「場合」や「入れ物」の意味ですが、ここでは英語の letter case（文字の大文字・小文字の別）を指します。活版印刷で大文字の活字を上の箱（upper case）、小文字を下の箱（lower case）に入れていたことから、大文字を uppercase、小文字を lowercase と呼びます。「ケースを区別する（case-sensitive）」は「大文字と小文字を区別する」という意味です。

キャメルケースは、userLoginCount の途中の大文字がラクダのこぶのように見えることからの呼び名です。英語版 Wikipedia によると、似た書き方は以前から InterCaps などと呼ばれており、「Camel Case」という呼び名は1995年の投稿が最初の例とされています。パスカルケースはプログラミング言語 Pascal にちなむ名前です。スネークケースは _ で低くつながる形をヘビに、ケバブケースは - でつながる形を串焼きに見立てた呼び名として広く使われています。

変換ツールの単語の分け方（略語・数字・日本語）

この節では、記事内ツールが名前をどう単語に分けるかを、実際に入れた結果で確かめられます。

変換で迷うのは「どこで単語を切るか」です。上のツールを Chromium で開き、迷いやすい名前を入れた結果が次の表です（camelCase と snake_case の列だけを抜き出しました）。

XMLHttpRequest は「大文字が続いたら、最後の大文字から次の単語」という決まりで xml・http・request に分かれます。この決まりは多くのライブラリと同じです。一方、iOS や IPv6 のように小文字が混ざった略語は、機械には分け方が分かりません。iOSVersion は i・os・version、IPv6Address は i・pv6・address になるので、こうした名前は変換後に手で直します（ios_version、ipv6_address）。先頭と末尾の _ も区切りとして消えるので、Python の __init__ のような特別な名前は変換の対象にしません。

「数字の前後でも区切る」にチェックを入れると、結果は次のように変わりました。どちらが正しいということはなく、チームの決まりに合わせて選びます。

base64・h264・utf8 のように数字までで1語のものは、既定のまま（区切らない）のほうが自然です。address_line_2 のように「2行目」という別の語として数字を書く場合は、チェックを入れると元の形に戻せます。250行を貼ったときは「200 個の名前をまとめて変換しました。」と表示され、201行目以降は変換されませんでした。

言語別の命名規則の一覧（Java・JavaScript・Python・Go・C#・Ruby・PHP・Rust）

この節では、主な言語でクラス・関数・変数・定数をどの書き方にするかが、公式のスタイルガイドに沿って一覧で分かります。

命名規則は文法ではなく「その言語の利用者が守っている約束」です。守らなくても多くは動きますが、型・変数・定数を名前で見分けられなくなります。各言語のスタイルガイドで確かめた結果です。

Go だけは命名が文法に関わります。Effective Go は「名前がパッケージの外から見えるかどうかは、最初の文字が大文字かどうかで決まる」と書いており、UserName は公開、userName は非公開になります。Go では _ でつなぐ名前は使わず、MixedCaps か mixedCaps で書くのが慣習です。C# は Java と似ていますが、メソッドと定数も PascalCase にする点が違います（MaxRetryCount）。

Ruby も、クラス名を小文字で始めると文法の誤りになります。Ruby 3.3.6 で class user_account と書いたときの原文です。

$ ruby a.rb
a.rb: --> a.rb
expected a constant name after `class`
> 1  class user_account
> 2  end
a.rb:1: class/module name must be CONSTANT (SyntaxError)
class user_account
      ^~~~~~~~~~~~

Ruby では大文字で始まる名前が定数として扱われ、クラス名もその1つです。定数に2回代入すると、止まらずに警告が出ます（warning: already initialized constant MaxRetry）。PHP 8.3.6 では、関数名は大文字小文字を区別せず GETUSERNAME() でも getUserName() が呼ばれ、変数名は区別するので $userName と $username は別の変数でした。

名前の付け方そのもの（何を表す単語を選ぶか、動詞で始めるか）は、関連記事「変数名・関数名の付け方｜命名規則と言語別のルール」で扱っています。この記事は形と変換を中心にしています。

場所別の慣習（DB の列名・URL・CSS・環境変数・HTTP ヘッダー・JSON）

この節では、言語の外（DB・URL・CSS・環境変数・HTTP ヘッダー・JSON の API）でどの書き方が使われるかと、その理由が分かります。

環境変数は、POSIX が「OS の道具が使う名前は大文字・数字・_ だけ」「小文字を含む名前はアプリケーション用に空けてある」と定めています。慣習として自分のアプリの変数も大文字の snake_case で書くことが多いです。

JSON の API のキーは、言語ではなく API ごとに1つに決めます。DB は snake_case、API は camelCase と決め、その間をライブラリで変換する組み合わせがよく使われます。DB の名前の付け方の全体は関連記事「DB命名規則一覧｜テーブル名・カラム名・インデックス名・制約名」で扱っています。

略語（ID・URL・HTTP）の書き方は言語で違う

この節では、userId と userID、XmlHttpRequest と XMLHttpRequest のどちらで書くかが、言語のガイドごとに分かります。

略語の扱いは、言語のガイドどうしで答えが割れている数少ない点です。それぞれのガイドに載っている例をそのまま並べます。

Java と JavaScript の標準ライブラリには XMLHttpRequest と getElementById のように両方の形が混ざっていますが、新しいコードはプロジェクトのガイドに合わせて1つにそろえます。迷ったら頭だけ大文字の形にしておくと、HTTPURLConnection のように略語が続いて機械で分けられない名前を避けられます。

プログラムで変換する（Python・JavaScript・PHP・Ruby）

この節では、キャメルケース・スネークケース・ケバブケースを相互に変換するコードと、ライブラリごとに結果が違う点が分かります。

記事内ツールと同じ決まり（大文字の始まり・記号・空白で分け、大文字の連続は最後の1字から）を Python で書くと次のようになります。正規表現2つで単語に分け、つなぎ方だけを変えます。

import re

def words(name: str) -> list[str]:
    s = re.sub(r"([a-z0-9])([A-Z])", r"\1 \2", name)    # userName → user Name
    s = re.sub(r"([A-Z]+)([A-Z][a-z])", r"\1 \2", s)    # XMLHttp → XML Http
    return [w.lower() for w in re.split(r"[^A-Za-z0-9]+", s) if w]

def to_snake(name): return "_".join(words(name))
def to_kebab(name): return "-".join(words(name))
def to_camel(name):
    w = words(name)
    return w[0] + "".join(x.capitalize() for x in w[1:]) if w else ""

for n in ["getUserName", "XMLHttpRequest", "user_login_count", "Content-Type", "userID"]:
    print(f"{n:18} snake={to_snake(n):20} camel={to_camel(n):18} kebab={to_kebab(n)}")

getUserName        snake=get_user_name        camel=getUserName        kebab=get-user-name
XMLHttpRequest     snake=xml_http_request     camel=xmlHttpRequest     kebab=xml-http-request
user_login_count   snake=user_login_count     camel=userLoginCount     kebab=user-login-count
Content-Type       snake=content_type         camel=contentType        kebab=content-type
userID             snake=user_id              camel=userId             kebab=user-id

JavaScript では lodash の _.camelCase・_.snakeCase・_.kebabCase と、change-case パッケージの camelCase・snakeCase などがよく使われます。同じ名前を両方に通すと、数字の扱いで結果が分かれました。

lodash 4.18.1 は数字の前後で区切り、change-case 5.4.4 は区切りませんでした。記事内ツールでいうと、lodash は「数字の前後でも区切る」にチェックを入れた状態、change-case は既定の状態と同じ結果です。どちらのライブラリも日本語はそのまま残しました（記事内ツールは取り除きます）。プロジェクトの中で変換の道具を2つ混ぜると、同じ列名から違うキーができるので、1つに決めておきます。

PHP と Ruby は標準の関数だけで書けます。PHP 8.3.6 と Ruby 3.3.6 で実行した結果です。

<?php
echo lcfirst(str_replace('_', '', ucwords('user_login_count', '_'))), "\n";   // userLoginCount
echo strtolower(preg_replace('/(?<!^)[A-Z]/', '_$0', 'getUserName')), "\n";  // get_user_name

puts "user_login_count".split("_").map.with_index { |w, i| i.zero? ? w : w.capitalize }.join
# => userLoginCount

この PHP の2行目は「大文字の前に _ を入れる」だけなので、XMLHttpRequest は x_m_l_http_request になります。略語を含む名前は、上の Python と同じ2段の正規表現にします。

snake_case と camelCase を自動で変える（Jackson・Pydantic・Go の JSON タグ）

この節では、DB や API の snake_case と、プログラムの camelCase の間を、ライブラリに自動で変換させる方法と実行結果が分かります。

Java：Jackson の PropertyNamingStrategies

Java のクラスは camelCase、API の JSON は snake_case、というときは Jackson の命名戦略を1行設定します。

ObjectMapper m = new ObjectMapper()
        .setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);
// record User(int userId, String firstName, boolean isActive, String xmlHttpURL)
System.out.println(m.writeValueAsString(new User(1, "Taro", true, "x")));

戦略を変えて同じ record を書き出した結果です（OpenJDK 21.0.12・Jackson 2.14）。

(既定)           -> {"userId":1,"firstName":"Taro","isActive":true,"xmlHttpURL":"x"}
SNAKE_CASE       -> {"user_id":1,"first_name":"Taro","is_active":true,"xml_http_url":"x"}
KEBAB_CASE       -> {"user-id":1,"first-name":"Taro","is-active":true,"xml-http-url":"x"}
UPPER_CAMEL_CASE -> {"UserId":1,"FirstName":"Taro","IsActive":true,"XmlHttpURL":"x"}
LOWER_DOT_CASE   -> {"user.id":1,"first.name":"Taro","is.active":true,"xml.http.url":"x"}
LOWER_CASE       -> {"userid":1,"firstname":"Taro","isactive":true,"xmlhttpurl":"x"}

UPPER_CAMEL_CASE は先頭を大文字にするだけなので、xmlHttpURL は XmlHttpURL のままでした。読み込みでは、戦略を設定しない ObjectMapper に snake_case の JSON を渡すと、次のエラーになりました。

UnrecognizedPropertyException: Unrecognized field "user_id" (class Main$Member), not marked as ignorable (2 known properties: "firstName", "userId"])

このエラーは「JSON のキーとフィールド名の書き方が合っていない」ときの代表です。戦略を SNAKE_CASE にすると、普通のクラス（Member）には正しく読み込めました。一方、Ubuntu 24.04 の apt で入る Jackson 2.14 では、record に snake_case の JSON を読み込むと JsonMappingException: Can not set final java.lang.String field Main$User.xmlHttpURL to java.lang.String で失敗しました。Jackson 2.15 の変更一覧には「#2992 Properties naming strategy do not work with Record」の修正が載っているので、record と命名戦略を組み合わせるなら、最新の 2.x 系を使います。Spring Boot なら spring.jackson.property-naming-strategy=SNAKE_CASE でも同じ設定になります。ObjectMapper の使い方全体は関連記事「Jackson ObjectMapperの使い方｜JSON変換・日付・record」で扱っています。

Python：Pydantic の alias_generator

Python のフィールドは snake_case、API の JSON は camelCase、というときは Pydantic の alias_generator=to_camel を使います。

from pydantic import BaseModel, ConfigDict
from pydantic.alias_generators import to_camel

class User(BaseModel):
    model_config = ConfigDict(alias_generator=to_camel, validate_by_name=True)
    user_id: int
    first_name: str
    is_active: bool = True

u = User.model_validate({"userId": 1, "firstName": "Taro"})
print(u)
print(u.model_dump())
print(u.model_dump_json(by_alias=True))

user_id=1 first_name='Taro' is_active=True
{'user_id': 1, 'first_name': 'Taro', 'is_active': True}
{"userId":1,"firstName":"Taro","isActive":true}

書き出しで camelCase にするには by_alias=True が要ります。付けないと snake_case のまま出ます。validate_by_name=True を付けないモデルに snake_case のキーを渡すと、次のエラーになりました。

1 validation error for Strict
userId
  Field required [type=missing, input_value={'user_id': 1}, input_type=dict]

Pydantic 自体の使い方は関連記事「Pydanticとは｜何に使う・dataclassとの違いと使い方を実測で解説」で扱っています。

行って戻すと元に戻らない名前がある

snake_case → camelCase → snake_case と往復させたとき、元に戻るとは限りません。DB の列名を想定した名前で、自作の関数（記事内ツールの既定と同じ決まり）と Pydantic の to_camel・to_snake を往復させた結果です。

数字を含む名前は、どちらの決まりでも崩れるものがあります。往復させる設計にせず、「DB → API は自動変換、合わない列だけ別名（Jackson の @JsonProperty、Pydantic の Field(alias=...)）を付ける」とすると安全です。

Go：構造体タグで1つずつ決める

Go の encoding/json には自動の命名戦略がなく、フィールドごとにタグで JSON のキーを書きます。Go 1.24.7 で実行した結果です。

type User struct {
	UserID    int    `json:"user_id"`
	FirstName string `json:"firstName"`
	LastName  string
	password  string
}
// json.Marshal(User{1, "Taro", "Yamada", "x"})
// json.Unmarshal(`{"USER_ID":2,"firstname":"Hanako","lastName":"Sato"}`, &v)

{"user_id":1,"firstName":"Taro","LastName":"Yamada"}
{UserID:2 FirstName:Hanako LastName:Sato password:}

小文字で始まる password は非公開なので JSON に出ません。タグの無い LastName はフィールド名のまま出ます。読み込みは大文字小文字を区別せずに照らし合わせるため、USER_ID や firstname でも入りました。タグの書き方の一覧は関連記事「Go JSON｜構造体タグ一覧とencoding/json v2の変更点」で扱っています。

ブラウザと HTTP の自動変換（dataset・style・ヘッダー）

この節では、ブラウザが kebab-case と camelCase を自動で変換する場所と、HTTP ヘッダーの大文字小文字の扱いが分かります。

HTML の data-user-id 属性は、JavaScript では dataset.userId で読みます。CSS の background-color は style.backgroundColor です。ブラウザが kebab-case と camelCase の間を自動で変換しているためです。Chromium 153 で確かめた結果です。

dataset                     : {"userId":"42","isActive":"true"}
dataset.createdAt = '2026-11-10' のあと:
  <p id="a" data-user-id="42" data-is-active="true" class="userName" data-created-at="2026-11-10">
style.backgroundColor='yellow' のあとの style 属性: background-color: yellow;
dataset['user-name'] = 'x'  : SyntaxError: Failed to set a named property 'user-name' on 'DOMStringMap': 'user-name' is not a valid property name.

MDN の説明どおり、属性名からは「- の後ろの小文字を大文字にして - を消す」、プロパティ名からは「大文字の前に - を入れて小文字にする」という変換でした。dataset に kebab-case のまま書くと SyntaxError になります。CSS のクラス名は大文字小文字を区別し、.userName に付けた色は class="username" の要素には付きませんでした。

HTTP ヘッダー名は、RFC 9110 で大文字小文字を区別しないと決まっています。127.0.0.1 の Node.js のサーバーに Content-Type・X-API-KEY・x-trace-id を送ると、req.headers のキーはすべて小文字（content-type,x-api-key,x-trace-id）になり、送ったときの形は req.rawHeaders にだけ残りました。fetch の res.headers.get("X-REQUEST-ID") も、小文字で返したヘッダーを読めました。ヘッダー名は Train-Case で書くのが慣習ですが、読む側は大文字小文字に頼らない書き方にします（HTTP/2 ではヘッダー名を小文字で送る決まりです）。

DB の列名で camelCase を使うと起きること（PostgreSQL・SQLite）

この節では、DB の列名を camelCase にしたときに PostgreSQL で何が起きるかと、DB の列名が snake_case になる理由が分かります。

PostgreSQL は、引用符で囲まない名前をすべて小文字にします。userId で作った列は userid になり、"createdAt" と引用符で囲んで作った列だけが大文字を残します。PostgreSQL 16.15 で実行した結果です。

CREATE TABLE users (userId int, "createdAt" date, user_name text);
INSERT INTO users VALUES (1, '2026-11-10', 'taro');
SELECT createdAt FROM users;

                 Table "public.users"
  Column   |  Type   | Collation | Nullable | Default
-----------+---------+-----------+----------+---------
 userid    | integer |           |          |
 createdAt | date    |           |          |
 user_name | text    |           |          |

psql:a.sql:7: ERROR:  column "createdat" does not exist
LINE 1: SELECT createdAt FROM users;
               ^
HINT:  Perhaps you meant to reference the column "users.createdAt".

引用符で作った列は、以後ずっと "createdAt" と引用符つきで書かないと読めません。SELECT userId や SELECT USER_NAME は小文字にそろえられて読めました。公式ドキュメントも「移植性を考えるなら、ある名前を常に引用符で囲むか、決して囲まないかのどちらかにする」と勧めています。SQL 標準は引用符なしの名前を大文字にそろえる決まりで、PostgreSQL はこの点が標準と違います。

SQLite 3.53.1 では、列名は大文字小文字を区別せずに照らし合わせられ、select userid, CREATEDAT でも読めました。ただし結果の列名は作ったときの形（userId・createdAt）で返ります。DB ごとに挙動が違うので、列名は小文字の snake_case にしておくのがいちばん崩れません。

1. 1列名は小文字の snake_case で作るcreated_at・user_id。引用符を使わない
2. 2ORM で camelCase のフィールドに対応させるJPA・MyBatis・Prisma などの対応づけの設定を使う
3. 3API の JSON で camelCase にするJackson の命名戦略・Pydantic の alias_generator

リンターで命名規則をそろえる（ESLint・Ruff・Pylint・rustc）

この節では、命名規則の違反をリンターやコンパイラに見つけさせる設定と、出てくるメッセージの原文が分かります。

JavaScript：ESLint の camelcase

ESLint 10.14.0 で、camelcase と new-cap を有効にした flat config で検査した結果です。

// eslint.config.mjs
export default [{ files: ["**/*.js"], rules: { camelcase: "error", "new-cap": "error" } }];

/dev/shm/t318/js/bad.js
  1:7   error  Identifier 'user_name' is not in camel case                  camelcase
  3:10  error  Identifier 'get_user' is not in camel case                   camelcase
  3:30  error  Identifier 'user_name' is not in camel case                  camelcase
  4:15  error  Identifier 'first_name' is not in camel case                 camelcase
  5:9   error  Identifier 'first_name' is not in camel case                 camelcase
  6:15  error  A constructor name should not start with a lowercase letter  new-cap

✖ 6 problems (6 errors, 0 warnings)

const MAX_RETRY = 3 は全部大文字なので定数とみなされ、警告は出ませんでした。API から受け取る first_name のように自分で決められないキーは、{ properties: "never", ignoreDestructuring: true } を付けると対象から外れ、6件が4件に減りました。公式ドキュメントでは、このルールは「凍結（frozen）」とされ、機能の追加は受け付けていません。型やクラスごとに細かく決めたいときは、TypeScript 用の @typescript-eslint/naming-convention を使います。設定全体は関連記事「ESLint flat config設定｜v10対応の完成形コピペ集」で扱っています。

Python：Ruff の N ルールと Pylint の invalid-name

maxRetry = 3

class user_account:
    def getName(self):
        userName = "taro"
        return userName

def LoadConfig(filePath):
    return filePath

このファイルを Ruff 0.17.4（ruff check --select N）と Pylint 4.1.3（--enable=invalid-name）で検査した結果です（Ruff の出力は位置の図を省きました）。

N816 Variable `maxRetry` in global scope should not be mixedCase
N801 Class name `user_account` should use CapWords convention
N802 Function name `getName` should be lowercase
N806 Variable `userName` in function should be lowercase
N802 Function name `LoadConfig` should be lowercase
N803 Argument name `filePath` should be lowercase
Found 6 errors.

bad.py:1:0: C0103: Constant name "maxRetry" doesn't conform to UPPER_CASE naming style (invalid-name)
bad.py:4:0: C0103: Class name "user_account" doesn't conform to PascalCase naming style (invalid-name)
bad.py:5:4: C0103: Method name "getName" doesn't conform to snake_case naming style (invalid-name)
bad.py:6:8: C0103: Variable name "userName" doesn't conform to snake_case naming style (invalid-name)
bad.py:10:0: C0103: Function name "LoadConfig" doesn't conform to snake_case naming style (invalid-name)
bad.py:10:15: C0103: Argument name "filePath" doesn't conform to snake_case naming style (invalid-name)

同じ6か所を両方が見つけました。Ruff は maxRetry を「グローバルの mixedCase」、Pylint は「定数なのに UPPER_CASE でない」と、見方が少し違います。Ruff の N ルールは pep8-naming を移したもので、既定では有効になっていないため select に "N" を加えます。

Rust：コンパイラが既定で警告する

Rust は、リンターを入れなくてもコンパイラ（rustc 1.97.0）が命名規則を検査し、直した名前まで示します。

warning: type `user_account` should have an upper camel case name
 --> main.rs:2:8
  |
2 | struct user_account { userName: String }
  |        ^^^^^^^^^^^^ help: convert the identifier to upper camel case: `UserAccount`
  |
  = note: `#[warn(non_camel_case_types)]` (part of `#[warn(nonstandard_style)]`) on by default

warning: constant `maxRetry` should have an upper case name
warning: structure field `userName` should have a snake case name
 --> main.rs:2:23
  |
2 | struct user_account { userName: String }
  |                       ^^^^^^^^ help: convert the identifier to snake case: `user_name`

warning: function `getName` should have a snake case name
warning: 4 warnings emitted

Java には命名規則を検査する仕組みが言語に無いので、Checkstyle などの道具を使います。C# は .editorconfig の命名規則（IDE1006）で検査できると Microsoft Learn に書かれています。

• 1言語の標準のガイドに合わせた規則をリンターで有効にした
• 2外部の API のキーなど、自分で決められない名前を対象から外した
• 3略語の書き方（userId か userID か）をチームで1つに決めた
• 4CI でもリンターを動かし、違反が入らないようにした

よくあるエラー・つまずき（原文つき）

この節では、書き方の違いが原因で起きるエラーの原文と、直し方が一覧で分かります。

どれを使うか判断表（キャメル・スネーク・ケバブ）

この節では、名前を書く場所ごとに、どの書き方を選べばよいかが判断表で分かります。

決め方の順番は「言語や仕組みが決めているか」→「その言語の公式のガイド」→「プロジェクトの既存のコード」です。既存のコードが別の書き方でそろっているなら、新しいコードもそれに合わせます（PEP 8 も「既存のスタイルとの一貫性を優先する」と書いています）。

キャメルケース・スネークケースのよくある質問

この節では、キャメルケース・スネークケース・ケバブケースについてよく聞かれる疑問の答えが分かります。

Q. キャメルケースとパスカルケースの違いは何ですか？ A. 先頭の文字だけが違います。先頭が小文字の userName がキャメルケース（ローワーキャメルケース）、先頭も大文字の UserName がパスカルケース（アッパーキャメルケース）です。多くの言語で、変数と関数はキャメルケース、クラスと型はパスカルケースにします。

Q. スネークケースとケバブケースはどう使い分けますか？ A. プログラムの名前には、- を使えない言語が多いのでスネークケースを使います。URL・CSS のクラス名・HTML の属性・ファイル名のように、- が引き算と読まれない場所ではケバブケースを使います。

Q. 変数名に日本語を使ってもよいですか？ A. Python・Java・JavaScript などは Unicode の文字を名前に使えるので動きます。入力のしにくさがあるため、チームで決めたうえで使います。記事内ツールは日本語を取り除くので、日本語の名前の変換には使えません。

Q. enum の値はどの書き方にしますか？ A. Java は定数と同じ SCREAMING_SNAKE_CASE（Color.DARK_RED）、C# と TypeScript は PascalCase（Color.DarkRed）が多く使われます。Python の Enum は定数として大文字の snake_case で書く例が公式ドキュメントに多く載っています。

Q. 1つのプロジェクトに camelCase と snake_case が混ざってもよいですか？ A. 場所ごとに分かれているなら問題ありません。Python のコードは snake_case、API の JSON は camelCase、のように境目で変換します。同じ場所（1つのクラスの中など）で混ざるのは避けます。

Q. 既存のコードが規則と違う書き方でそろっているときは？ A. 既存のコードに合わせます。規則に寄せたいときは、一度にまとめて名前を変える作業として別に行います。

Q. ID は userId と userID のどちらで書きますか？ A. Java（Google のガイド）は userId、Go は userID です。言語のガイドに合わせます。JavaScript で迷う場合は、標準 API の getElementById に合わせて userId にするのが一般的です。

Q. Excel や VS Code でキャメルケースに変換できますか？ A. Excel には専用の関数が無いので、このページのツールで変換した結果を貼るのが手早い方法です。VS Code には選んだ文字を変換する「Transform to Uppercase」「Transform to Lowercase」などのコマンドがあり、コマンドパレットで Transform と入れると、その版で使える変換の種類が一覧で出ます。

Q. 変換ツールに入れた名前はどこかに送られますか？ A. 送られません。このページのツールは、入れた名前をブラウザの中だけで変換します。

まとめ

• キャメルケースは userName、パスカルケースは UserName、スネークケースは user_name、ケバブケースは user-name。違いは「単語のつなぎ方」と「先頭が大文字か」だけ。
• Java・JavaScript の変数は camelCase、Python・Ruby・Rust は snake_case、クラスはほぼ PascalCase、定数と環境変数は大文字の snake_case、URL と CSS は kebab-case。Go は大文字始まりで公開になる。
• 略語の書き方は言語で違う（Java は userId・XmlHttpRequest、Go は userID・ServeHTTP、Python のクラスは HTTPServerError）。iOS・IPv6 のような名前は機械で正しく分けられないので、変換後に見直す。
• DB は snake_case、API は camelCase と決め、Jackson の命名戦略・Pydantic の alias_generator で境目を変換する。PostgreSQL で camelCase の列を引用符つきで作ると、以後ずっと引用符が要る。
• 命名規則は ESLint の camelcase、Ruff の N ルール、Pylint の invalid-name、rustc の警告で検査できる。変換は記事内ツールで8つの形を一度に確かめられる。

次に読むとよい記事です。名前に使う単語の選び方は関連記事「変数名・関数名の付け方｜命名規則と言語別のルール」で、テーブル名と列名の決め方は関連記事「DB命名規則一覧｜テーブル名・カラム名・インデックス名・制約名」で扱っています。

参考・出典

確認日はいずれも 2026年11月9日です。

• Python「PEP 8 – Style Guide for Python Code」Naming Conventions：https://peps.python.org/pep-0008/#naming-conventions
• Google「Google Java Style Guide」5 Naming：https://google.github.io/styleguide/javaguide.html#s5-naming
• Google「Google JavaScript Style Guide」6 Naming：https://google.github.io/styleguide/jsguide.html#naming
• The Go Authors「Effective Go」Names：https://go.dev/doc/effective_go#names
• The Go Authors「Go Code Review Comments」Initialisms：https://go.dev/wiki/CodeReviewComments#initialisms
• Microsoft Learn「C# identifier naming rules and conventions」：https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names
• PHP-FIG「PSR-1: Basic Coding Standard」：https://www.php-fig.org/psr/psr-1/
• 「The Ruby Style Guide」Naming Conventions：https://rubystyle.guide/#naming-conventions
• PostgreSQL「4.1.1. Identifiers and Key Words」（PostgreSQL 16）：https://www.postgresql.org/docs/16/sql-syntax-lexical.html
• MDN「HTMLElement: dataset property」：https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset
• The Open Group「POSIX Base Definitions 8. Environment Variables」：https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html
• IETF「RFC 9110 HTTP Semantics」5.1 Field Names：https://www.rfc-editor.org/rfc/rfc9110#section-5.1
• IETF「RFC 9113 HTTP/2」8.2.2：https://www.rfc-editor.org/rfc/rfc9113#section-8.2.2
• Google 検索セントラル「Google の URL 構造に関するベスト プラクティス」：https://developers.google.com/search/docs/crawling-indexing/url-structure
• ESLint「camelcase」：https://eslint.org/docs/latest/rules/camelcase
• Pydantic「Alias」：https://pydantic.dev/docs/validation/latest/concepts/alias/
• FasterXML「Jackson Release 2.15」：https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15
• Wikipedia（英語版）「Camel case」：https://en.wikipedia.org/wiki/Camel_case

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。