APIのJSONが user_name でフロントはuserName — 毎回手で書き換えてませんか？ 命名規則（naming convention）はプログラミング言語・フレームワーク・用途ごとに慣習が異なり、どれを選ぶかを迷う場面は思いのほか多いです。 この記事では、実務でよく使う5種類の記法の違いと、JavaScript・Python・CSS・DB・URLなど場面別の使い分け、 そして変換ツールの裏で動いているロジックの難しさまでを整理します。
主要な5つの命名規則
プログラミング・Web開発で日常的に使われる命名規則は、主に次の5種類です。 いずれも「複数単語をどうつなぐか」という問題への異なる答えと考えると整理しやすくなります。
| 記法 | 例 | 主な用途 |
|---|---|---|
| camelCase（キャメルケース） | userName / getUserProfile | JavaScript・Java・Swiftの変数・関数名 |
| PascalCase（パスカルケース） | UserName / UserProfile | クラス名・型名・Reactコンポーネント |
| snake_case（スネークケース） | user_name / get_user_profile | Python・Ruby・DB列名・Rails系JSON |
| kebab-case（ケバブケース） | user-name / user-profile | URL・CSSクラス名・HTML属性・ファイル名 |
| SCREAMING_SNAKE_CASE | MAX_RETRY / API_BASE_URL | 定数・環境変数・マクロ |
このほか「Train-Case」（User-Name・HTTPヘッダーで使用）や、 単語をそのまま繋げる「flatcase」（username）もありますが、 上記5種類を押さえておけば実務の9割はカバーできます。
camelCase と PascalCase の違い
この2つはよく混同されます。違いは先頭が小文字か大文字かの1点だけです。
- camelCase: 先頭小文字 —
getUserProfile - PascalCase: 先頭大文字 —
GetUserProfile
PascalCaseは「UpperCamelCase」とも呼ばれます。 JavaScriptでは関数・変数はcamelCase、クラス・Reactコンポーネント・型（TypeScript）はPascalCaseという住み分けが定着しており、 Reactで <userCard /> と書くと「HTMLの小文字要素」と誤認されてしまうのも、 この慣習に基づいた仕様です（Reactコンポーネントは必ず大文字始まり）。
言語・場面別にどれを使うか
「どの記法を選ぶか」はほぼ言語と場面で決まります。迷ったら以下のマトリクスを参照してください。
| 場面 | 推奨記法 | 例 |
|---|---|---|
| JavaScript / TypeScript 変数・関数 | camelCase | getUserName() |
| JavaScript クラス・TypeScript 型 | PascalCase | class UserProfile {} |
| Python / Ruby 変数・関数 | snake_case | get_user_name() |
| Python / Ruby クラス | PascalCase | class UserProfile: |
| CSSクラス・HTML属性 | kebab-case | .user-card / data-user-id |
| URL パス | kebab-case | /user-profile/edit |
| DB列名（SQL） | snake_case | user_name / created_at |
| 定数・環境変数 | SCREAMING_SNAKE_CASE | API_BASE_URL |
| ファイル名（Web） | kebab-case | user-profile.tsx |
| React コンポーネントファイル | PascalCase | UserProfile.tsx |
特にURLをkebab-caseにするのはSEO上も重要です。Googleはハイフン（-）を単語の区切りとして認識しますが、 アンダースコア（_）は1語として扱うことがあります。/user_profile より /user-profile のほうが検索エンジンに優しい、というのはこのためです。
変換ロジックは意外に難しい — 頭字語問題
「camelCaseをsnake_caseに変換する」と言うと単純に聞こえますが、実装してみると落とし穴にぶつかります。代表が頭字語（acronym）の扱いです。
// 同じ「XMLHttpRequest」をsnake_caseへ変換するとき
XMLHttpRequest → ???
// 候補A: 大文字の連続を1語とみなす
→ xml_http_request
// 候補B: 大文字ごとに区切る
→ x_m_l_http_request（← 壊れている）
候補Aが直感的ですが、実は逆変換（snake_case → PascalCase）で情報が失われます。xml_http_request を素直にPascalCaseに戻すとXmlHttpRequest になり、元の「XML」の大文字情報が消えてしまうのです。
Google JavaScript Style Guideはこの問題への答えとして「頭字語も普通の単語として扱う」方針を採り、XmlHttpRequest・getUserIdを正として統一しています。一方、JavaのAPIは伝統的に XMLHttpRequest・getUserIDのように頭字語を大文字維持します。どちらが「正解」ということはなく、チーム内で統一されていれば良いという性質のものです。
ライブラリでの変換
自前でロジックを書くより、実績のあるライブラリを使うほうが安全です。JavaScriptでよく使われる選択肢を挙げます。
| ライブラリ | 特徴 |
|---|---|
| lodash.camelCase / snakeCase / kebabCase | 定番。頭字語は普通の単語として扱う（XMLHttpRequest → xmlHttpRequest） |
| change-case | モダン。5種類以上の記法に対応し、関数単位でツリーシェイクが効く |
| camelcase-keys / snakecase-keys | オブジェクトのキーを再帰的に変換。API境界での変換に便利 |
| humps | 古参。camelize / decamelize が簡潔で、軽量 |
単発の変換をサッと確認したいときは、ぱんだツールズのケース変換ツールにテキストを貼り付けると、camelCase・PascalCase・snake_case・kebab-case・SCREAMING_SNAKE_CASEに一括変換できます。 処理はブラウザ内で完結するため、社外秘のコード片や識別子候補でも安心して試せます。 変換後の文字列の長さを確認したいときは文字数カウンターと組み合わせると、API仕様書のフィールド長制限などのチェックにも使えます。
まとめ
- 実務で使う命名規則は主に5種類（camelCase / PascalCase / snake_case / kebab-case / SCREAMING_SNAKE_CASE）
- camelCaseとPascalCaseの違いは先頭が小文字か大文字かの1点だけ
- 言語・場面ごとに慣習が固まっている — JS/TS変数はcamelCase、クラス・型はPascalCase、Python/RubyとDB列はsnake_case、URL/CSSはkebab-case、定数・環境変数はSCREAMING_SNAKE_CASE
- URLをkebab-caseにするのはSEO観点でも有利（ハイフンは単語区切りと認識される）
- 頭字語の扱い（XMLHttpRequest vs XmlHttpRequest）は流派が分かれる。チーム内で統一するのが現実解
- 自前実装は頭字語の罠にはまりやすいので、lodash・change-caseなどのライブラリを使うのが安全
- 単発の変換はケース変換ツールでワンクリック。ブラウザ内処理で安心