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

導入：「命名規則がバラバラ」がチーム生産性を落とす

男の子

「博士、コードレビューで『命名統一しろ』ってまた指摘されたんだぜ。userId と user_id って一緒の意味じゃんかよ！」

博士

「意味は同じでも、混在するとバグの温床になるのじゃ。JSON.parse(text).user_id と書くつもりが userId と書いてしまい、データが取れない。デバッグに 30 分溶けるパターンじゃよ。」

女の子

「言語やコンテキストごとに『正解』が違うのが厄介なのよね。Python は snake_case、JavaScript は camelCase、URL は kebab-case、環境変数は UPPER_SNAKE_CASE、と。」

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

博士

「キャメルは『ラクダのこぶ』のように凸が並ぶ形、スネークは『下線でつなぐ蛇のような形』が由来じゃ。ケバブは串に刺さった具材、というわけじゃな。」

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

3. 「API の JSON 命名」問題

男の子

「API の JSON のキーって camelCase？ snake_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 です。

女の子

「私のチームでは userId、apiUrl、htmlContent と完全に小文字統一する派よ。parseHTMLString って書くと、parseHTMLstring なのか parse HTML string なのか境界が不明瞭になっちゃうから。」

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

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

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