Claude Codeで日本語コメント・日本語変数名を書くときの注意点

Claude Codeは日本語のコメントも日本語の変数名も、書くこと自体は問題なく扱えます。ただし「読める」ことと「意図どおりに運用できる」ことは別です。CLAUDE.mdに日本語で書いた指示は強制力を持たず、統合ターミナルでは条件次第で文字化けが起き、CLAUDE.mdやMEMORY.mdは日本語だと書ける分量が目減りします。

CLAUDE.mdに日本語で指示を書いても機能するか

機能します。CLAUDE.mdはプレーンテキストのMarkdownファイルで、Claude Codeはセッション開始時にその内容をそのまま読み込みます。書く言語に制約はありません。「日本語コメントを使う」「変数名は英語のキャメルケースにする」のような命名規約も、日本語の文章としてそのまま書けます。

理解の精度も実務上は問題になりません。公式の多言語対応ページによると、Sonnet 4.5(拡張思考あり)の日本語タスクは英語基準の96.8%、Haiku 4.5でも93.5%のスコアを保ちます。低リソース言語では英語比80%台まで落ちる言語もある中、日本語はこの表の中でも上位グループです。詳しいスコア表と評価方法はClaudeの多言語性能を言語別データで見るにまとめています。

CLAUDE.mdの指示は「強制」ではなく「文脈」として扱われる

ここが実装前に知っておくべき最重要点です。公式ドキュメントは、CLAUDE.mdとauto memoryの両方を指して次のように明記しています。

Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead.

CLAUDE.mdに「日本語コメントを必ず使う」と書いても、Claudeはそれを文脈として参照するだけで、コードを書くたびに機械的に照合するわけではありません。具体的で簡潔な指示ほど遵守率は上がりますが、100%の保証はありません。

CLAUDE.mdの書き方そのものはClaude CodeのCLAUDE.mdを実用に引き上げる10のパターン、CLAUDE.mdとauto memoryの使い分けはClaude Code memoryの三層構造で扱っています。日本語の運用規約を書く場面でも、この2記事の型がそのまま使えます。

命名規約を具体的に伝えるなら、抽象的な一文よりも実例を添えたほうが遵守率は上がります。

## コーディング規約
- コメントは日本語で書く
- 変数名・関数名は英語のcamelCaseにする(例: userId, fetchOrderList)
- 例外: ドメイン固有の日本語用語(勘定科目名など)は変数名にそのまま使ってよい

日本語の変数名は技術的に書けるか

書けます。Python 3・JavaScript・TypeScript・Java・C#・Kotlin・Swiftはいずれも識別子にUnicode文字を許可しており、合計金額 = 1000のようなコードは構文として通ります。技術的な可否と、チームで採用すべきかは別の話です。

日本語識別子は、英語話者を含む混成チームでのレビューやgrep検索、IME切り替えを挟むタイピングコストの面で摩擦を生みやすく、多くのスタイルガイドが識別子をASCII縛りにしているのはこの摩擦を避けるためです。Claude Codeは自発的に日本語識別子を選ぶわけではなく、CLAUDE.mdに書いた規約や既存コードベースの慣習を文脈として踏まえて命名します。「変数名は英語にする」という指示も、前節のとおりCLAUDE.mdに書けば効きますが、強制ではなく文脈である点は変数名でもコメントでも変わりません。

統合ターミナルで日本語コメントが文字化けする条件

VS Code・Cursor・Devin Desktopの統合ターミナルでClaude Codeを動かしていると、文字が四角や別のグリフで表示されることがあります。原因はターミナルのGPUレンダリングで、日本語のような複雑なグリフを多用する場面ほど症状が出やすくなります。

/terminal-setup

このコマンドを一度実行すると、対象エディタでは terminal.integrated.gpuAcceleration が "off" に設定され、以後の文字化けが止まります。原因と直し方の詳細、Shift+Enterが効かない別症状との関係はterminal-setupコマンドでShift+Enterが効かないときの対処にまとめてあるので、統合ターミナルで作業する人はまず実行しておくのが近道です。

Claude CodeがBashツールで実行するgit commitやgit diff自体は、この文字化けとは別レイヤーです。現在の主要なOS・エディタ・GitHubはUTF-8を既定の文字コードとして扱うため、日本語のコミットメッセージや差分表示が化けるケースは近年ほとんど見かけなくなりました。文字化けが起きるとすれば、統合ターミナルのGPUレンダリングという表示側の問題であって、Gitの側で日本語が特別扱いされているわけではありません。

CLAUDE.mdとMEMORY.mdは日本語だと書ける文字数が減る

見落とされがちなのが、文字コードの仕組みによる実質的な容量の目減りです。UTF-8では英数字1文字が1バイトなのに対し、日本語の文字(ひらがな・カタカナ・漢字)は1文字あたり3バイトを消費します。同じ内容を書いても、日本語はASCIIの約3倍のバイト数を使う計算です。

この差が効いてくるのが、公式ドキュメントが明記する2つの読み込み上限です。

CLAUDE.mdの4MiB上限は日本語で書いても実務上まず届きません。一方でMEMORY.mdの25KB制限は話が違います。auto memoryはセッションをまたいで学習した内容をMEMORY.mdに1行ずつ書き足していく仕組みで、この索引ファイルは毎セッション冒頭で読み込まれます。日本語の説明文が長くなりがちな運用では、英語で運用する場合に比べて記録できる項目数が体感で目減りしやすくなります。

公式ドキュメントも、索引が上限に近づくと「1行1エントリーに保つ」「詳細はトピックファイルへ移す」という圧縮をClaude自身に促す仕組みを持っています。日本語で運用するなら、この圧縮が起きる頻度が英語運用より高くなる点を織り込んでおくと、思わぬタイミングで古いメモリーが読み込み対象から外れる事態を避けやすくなります。

日本語コメントはトークン消費を増やすのか

公式のトークンカウントページは、日本語と英語でトークン消費がどれだけ違うかという言語別の比較値を公開していません。公表されているのは、Claude 4.7以降とMythos Previewが新しいトークナイザーに切り替わり、同じ入力テキストでも旧トークナイザー比で約30%多くのトークンを消費するという点だけで、これは言語を問わない一般的な変化です。

コスト・コンテキスト消費を正確に把握したいなら、憶測に頼らずトークンカウントAPIで実際のコメント文を計測するのが確実です。日本語コメントを大量に含むファイルをClaude Codeで扱う機会が多いチームは、代表的なファイルで一度計測しておくと、コンテキストウィンドウの余裕を見積もる材料になります。

Claude Codeの日本語対応は「表示」より「文脈の踏襲」で設計されている

CLAUDE.mdの指示が文脈止まりであること、統合ターミナルの文字化けが表示層の問題であること、MEMORY.mdの容量が言語によって実質的に変わること――これらはいずれもClaude Code本体が日本語の理解や生成でつまずいているわけではありません。日本語コメント自体の生成品質は英語と大差なく、問題が起きるのは常に「その日本語をどう保存し、どう表示し、どう強制するか」という周辺の仕組みです。

この設計は理にかなっています。CLAUDE.mdやMEMORY.mdは元々、Claudeがコードベースの慣習を推測できない情報を人間が書き足す場所として作られています。日本語で書かれた命名規約も、Claudeにとっては数ある文脈情報の1つに過ぎず、英語の指示より優先度が下がることも上がることもありません。文字化けや容量の目減りは、Claude Codeというプロダクトの言語対応ではなく、ターミナルの描画方式やUTF-8のバイト効率という、もっと下の層で起きている制約です。

まとめ

Claude Codeで日本語コメント・日本語変数名を使うこと自体に技術的な障害はありません。CLAUDE.mdへの日本語指示は文脈として読まれるだけで強制力はなく、確実に守らせたい規約は別途チェックを仕込む必要があります。変数名を英語に統一したいなら、その方針自体もCLAUDE.mdに実例つきで書くのが近道です。VS Code系の統合ターミナルでは文字化けが起きることがあり、/terminal-setupで直せます。MEMORY.mdは日本語だと英語運用より少ない項目数で容量上限に達しやすく、トークン消費も気になるなら公式のトークンカウントAPIで実測するのが確実です。