キャメル / スネーク / ケバブ / パスカル - 命名規則の使い分け完全ガイド

導入：命名規則の不統一がチーム生産性を落とす理由

userId と user_id は意味こそ同じですが、同じコードベースに混在すると実害があります。 たとえば API レスポンスのキーが user_id なのに、フロントエンドで JSON.parse(text).userId と書いてしまうと、 エラーにはならず undefined が返るだけなので、原因の特定に時間がかかります。 コードレビューで「命名を統一してほしい」という指摘が繰り返されるのも、この種の不具合を未然に防ぐためです。

厄介なのは、言語やコンテキストごとに「正解」が異なる点です。Python は snake_case、JavaScript は camelCase、 URL は kebab-case、環境変数は UPPER_SNAKE_CASE というように、それぞれの文化圏で慣習が確立しています。 本記事では主要な命名規則の由来と、レイヤごとの使い分けを整理します。

1. 主要な命名規則と語源

名称の由来はいずれも見た目の形状です。camelCase は単語の先頭だけ大文字にした凸凹がラクダのこぶに見えることから、 snake_case は下線でつないだ形が地面を這う蛇に、kebab-case はハイフンでつないだ形が串に刺した具材に見えることから名付けられています。 PascalCase は Pascal 言語の慣習に由来し、先頭も大文字にする点で camelCase と区別されます（upper camel case とも呼ばれます）。

同じ名前を各規則で書き分けると次のようになります。

2. 「どこで何を使うか」の実務早見表

3. API の JSON キーは camelCase か snake_case か

API レスポンスの JSON キーをどちらにするかは、明確な業界標準がなく、チームの文化と利用言語によって決まるのが実情です。 JSON:API 仕様もメンバー名に camelCase を推奨しつつ、snake_case や kebab-case を禁止してはいません。

Twitter（X）API や GitHub API の旧版は snake_case、Stripe や AWS の新世代 API は camelCase が多い傾向にあります。 日本国内では、Rails 由来のサービスが snake_case を使い続けている例も多く見られます。

選定の指針：

• クライアントが JS/TS のみ → camelCase（フロントエンドで変換不要）
• クライアントが Python・Ruby も含む → snake_case（多数派の言語慣習に合わせる）
• どちらでも構わないなら、チーム内で1つに統一することが最優先

両方を共存させたい場合、サーバー側で snake_case ↔ camelCase の自動変換ミドルウェアを使う方法もあります。 ただし「URL のクエリパラメータが snake_case で、レスポンスは camelCase」のような不揃いは避けるべきです。

4. 国際化・記号の扱い

日本語をそのまま使うべきか

URL スラッグは ASCII の kebab-case が無難です。/about-us のように。 Unicode URL（/会社情報）は技術的には可能ですが、SNS 共有時にパーセントエンコードされて見づらくなります。

略語の大文字化

parseHTML か parseHtml か、判断が分かれやすい箇所です。Google JavaScript Style Guide は「略語も通常の単語として扱い、先頭以外は小文字にする」方針を採用しています。XmlHttpRequest ではなく xmlHttpRequest、parseHTML ではなく parseHtml という形です。 Microsoft の .NET 命名ガイドラインも、3 文字以上の略語は同様に扱う（HtmlTag、XmlDocument）と定めており、 複数の主要スタイルガイドが同じ結論に至っています。

この方針の根拠は単語境界の明確さです。parseHTMLString のように略語を全て大文字で書くと、HTML と String の境界が大文字の連続に埋もれ、 機械的に単語へ分割する際に parse / HTMLString なのか parse / HTML / String なのかが一意に決まりません。 snake_case へ変換するツールが parse_h_t_m_l_string のような結果を返すのも、この曖昧さが原因です。userId、apiUrl、htmlContent、parseHtmlString のように略語を小文字化しておけば、 大文字が常に単語の先頭を示すため、人間にも変換ツールにも境界が正確に伝わります。

5. 一括変換ツールで一気に揃える

既存コードや CSV のヘッダーを一括変換したい場合は、大文字・小文字変換ツールが利用できます。 文章を入力してクリック1つで camelCase / snake_case / kebab-case / PascalCase / SCREAMING_SNAKE_CASE に変換できます。

関連: スラッグ生成（日本語タイトルから URL 用 slug を作成）、Diff ツール（命名統一前後の差分確認）。

Lint で命名規則を機械的に強制する

レビューで指摘し続けるより、Lint に検出させる方が確実です。 TypeScript プロジェクトでは @typescript-eslint/naming-convention ルールで、 識別子の種類ごとに許可する形式を指定できます。

// .eslintrc.js（抜粋）
rules: {
  '@typescript-eslint/naming-convention': [
    'error',
    { selector: 'variableLike', format: ['camelCase'] },
    { selector: 'variable', modifiers: ['const'], format: ['camelCase', 'UPPER_CASE'] },
    { selector: 'typeLike', format: ['PascalCase'] },
  ],
},

この設定では、変数・関数・引数は camelCase、const 宣言は camelCase または UPPER_CASE（定数用）、 クラス・インターフェース・型エイリアス・enum は PascalCase 以外を書いた時点でエラーになります。 命名規則はチームで決めるだけでなく、ツールで強制して初めて定着します。