ホーム/ なぜ全社が日本人だとしても、コードで日本語の命名を使ってはいけないのでしょうか？

なぜ全社が日本人だとしても、コードで日本語の命名を使ってはいけないのでしょうか？

API の命名規則は、世界的な協力とシステムの安定性にとって不可欠です。パラメータ名に母国語を使用すると、各种の問題が発生する可能性があります。英語ベースの命名が API にとってなぜ重要なのか、そして EchoAPI がどのようにして支援できるかについて探ってみましょう。

川原建

2025年4月29日 • 4 min read

あなたは「変数名なんて一時的な適当な決定だ」と思っていませんか？もしかしたら「変数は肺炎決」だなんて思っているかもしれません。でも実際には：

プロジェクトのナビゲーションシステム
チームコミュニケーションの言語プロトコル
ソフトウェアアーキテクチャの骨組み

こんなこと、思ったことはありませんか？

「うちのチームはみんな日本人なんだから、userNameなんて書かなくても、ユーザー名って書けば、ユーザーねーむの方が直感的じゃない？」

合理的に聞こえますよね？

でも現実は、「ユーザー名」って書いた途端、IDEがフリーズ、CIがエラー、Swaggerが死に、Redisのパフォーマンスが急降下、Google翻訳も逃げ出す。

だから今日は、コードの変数名を英語にする理由についてお話しします！

1️⃣ 技術的な理由：システムは「カタカナ」を理解しない

システムが日本語を理解していると思うかもしれませんが、実際には五十音すら覚えていません。

エンコードの体積比較：日本語変数は超重い

// 日本語命名
{
  "ユーザー名": "たなか",
  "年齢": 28
}

// 英語命名
{
  "userName": "tanaka",
  "age": 28
}

UTF-8エンコーディングでは：

"ユーザー名" = 5つの日本語文字 × 3バイト = 15バイト
"userName" = 8つの英文字 × 1バイト = 8バイト

「たなか」って名前は、実は「恐竜」と同じくらい重たいんです。

IDE & ツールチェーン：日本語サポート = ギリギリ

// 英語命名体験
user.na // IDEが自動補完：name

// 日本語命名体験
ユー. // IDE：意味不明

Swagger、Postman、ログツール、CI/CD、コード補完――これらのツール、実は「ユーザー」や「パスワード」みたいな可愛い日本語単語を全く認識しません。

2️⃣ コラボレーションの観点：コードはチームの協奏曲、あなたの個人的な俳句じゃない

他の人があなたの変数を理解できなければ、いくら美しく書いても意味がない。

命名が統一されていない、全ては推測に頼る：

// Aが書いた
const userName = 'tanaka'

// Bが書いた
const nameOfUser = 'tanaka'

// Cが書いた
const ユーザー名 = 'たなか'

これはまるで、3人が「味噌ラーメン」のメニューを作っているようなものです。
一人は「味噌ラーメン」、一人は「ミソラーメン」、一人は「Miso Ramen」って書いてる――
あなたはどれを選びますか？

🔁 命名がバラバラ、インターフェースが「再利用不可」

こんな登録インターフェースがあったとします：

{
  "shozoku": "営業部",
  "sei": "田中",
  "mei": "太郎"
}

他の人がそのインターフェースを再利用しようとすると、顔が？？？に。

「shozokuは部署？seiはfirstName？meiは何？」

インターフェースのドキュメントは謎解きになり、コンポーネントは再利用できず、ただ書き直しが必要になります。

3️⃣ パフォーマンスの観点：変数が「太った」分、システムは「息切れ」

システムは音節ではなく、バイト単位で文字を処理します。

Redisキャッシュのキーが重すぎる

// 日本語命名
redis.set("ログイン時間:たなか", "2024-04-25")

// 英語命名
redis.set("login_time:tanaka", "2024-04-25")

一見、差がないように見えますが、実は日本語キーは英語より少なくとも1.5倍重いんです。
さらに、システム内部でエンコード・デコードが必要になり、パフォーマンスが東京のラッシュアワーのように詰まってしまうことも。

コンパイラやインタープリタも日本語変数名には弱い

const 名前 = 'たなか'
const 年齢 = 28
console.log(`こんにちは、${名前}さん！`) // 🌸 エラーなし

// ある日、ログシステムがこの文字を認識できず、ログが❌になる

書いている時は問題ないけど、実行したりデプロイしたりすると、突然問題が発生します。

4️⃣ 業界の規範：間違っているのはあなたではなく、世界基準で物事を考えていないこと

業界の慣習は、無数の失敗から得た経験の賜物です。

📘 Swagger/OpenAPIは日本語のフィールド名をサポートしていない

parameters:
  - name: ユーザー名  # ❌ Swaggerが文字化けする
  - name: userName   # ✅ 完璧に解析、ドキュメント生成

国際的な会議のサイトに登録する時に、「田中太郎」って名前を入力したら、システムは「tanaka taro」しか認識しないことが多いです。

これは差別ではなく、システムがUTF-8 + ASCIIを最適化しているからです。

CI/CDツールやLintツールは日本語変数を理解しない

rules:
  variable-naming:
    format: camelCase

camelCase？snake_case？PascalCase？これらはすべて英語用に設計されたルールです。
「名前」とか入れたら、ツールは**「何それ？」**って顔になります。

5️⃣ 命名の表現力：英語の変数名 = レゴブロック

良い命名はコミュニケーションを半分に、悪い命名はプロジェクトを崩壊させる。

英語の組み合わせ = 強い表現力 + 軽量

userName
isActive
orderStatus
emailVerifiedAt

これらの変数は短くて、メニューのように分かりやすい：
主語 + 動作 + 状態、一目で意味が分かります。

日本語変数 = 冗長 + 組み合わせにくい

ユーザー名の確認日時
アクティブ状態判定フラグ
電子メール確認済みフラグ

意味は分かりますが、IDEは追いつけない、覚えにくい、タイピングが面倒、協力するときには血を流すことに。

変数名って本当に難しい！

英語以外の母国語を持つ人にとって、標準化されたパラメータ名をつけるのは本当に悩ましい。特に、インターフェースドキュメントを書くときに、こんなことを考えていることがよくあります：

「これ、ユーザーの学歴情報だけど... 英語でどう表現すればいい？」
「このフィールドはユーザーの最後の訪問チャネルを表しているけど、標準的な表現は何？」
「registration_channelって書くの、ちょっと変じゃない？」

そんなとき、あなたはこうしているかも：

Google 翻訳で名前を調べる
Notionに命名メモを作成
設計システムで命名規則を確認
VSCodeで命名ルールのマニュアルとにらめっこ