Claude Codeを日本語で使う方法 設定手順とCLAUDE.md・文字化け対処を解説

ターミナルからコードの作成や修正を任せられるClaude Codeは、開発の進め方を変えるツールとして導入が広がっています。使い始めた人がまず戸惑うのが、応答が英語で返ってくる場面があることです。

日本語で指示を出せば日本語で返ってくることも多い一方、セッションによって英語に戻る現象は珍しくありません。設定で固定できる仕組みが用意されているため、押さえておけば毎回言い直す手間はなくなります。本記事では、日本語で安定して使うための設定方法、CLAUDE.mdの書き方、文字化けへの対処、英語との使い分けまでを整理します。

確認したいポイント	結論	詳細
Claude Codeは日本語で使える？	設定なしでも日本語で会話できる	モデルが多言語に対応しているため、日本語で入力すれば日本語で返ってきます。
英語で返ってくるのはなぜ？	応答言語が固定されていないため	セッションや文脈によって揺れが出るため、設定で明示的に指定する必要があります。
確実に日本語にする方法は？	settings.jsonのlanguageキー	設定ファイルに言語を記述する方法が公式に用意されており、最も確実な手段です。
CLAUDE.mdでも指定できる？	指示として書けば有効に働く	言語設定用のファイルではありませんが、規約とあわせて管理できる利点があります。
文字化けしたときは？	ターミナル側の設定を見直す	統合ターミナルの描画が原因のことが多く、専用コマンドで解消できる場合があります。
英語で使ったほうがいい場面は？	技術用語や既存の英語資産を扱う時	エラー文の解析やライブラリの仕様確認では、英語のまま扱うほうが精度が安定します。
チームで設定を揃えるには？	プロジェクト設定をGitで共有	リポジトリ内の設定ファイルに書いて共有すれば、メンバー全員に同じ設定が適用されます。
導入はどう進めればいい？	個人設定から始めて段階的に広げる	まず自分の環境で固定し、有効性を確かめてからチームへ展開する順序が確実です。

この記事でわかること

• Claude Codeが日本語に対応している範囲と、英語に戻る理由
• 設定ファイルとCLAUDE.mdによる、日本語での固定方法の違い
• CLAUDE.mdの配置場所と、指示が守られないときの確認手順
• 文字化けや入力の不具合が起きたときの対処法
• 日本語と英語を使い分けて精度とコストを最適化する考え方

【AI活用を自社の業務に落とし込みたい方へ】 ネクストスケールでは、生成AI・AIエージェントの社内研修から業務への実装支援までを一貫してお手伝いしています。 「どの業務から着手すべきか分からない」という段階からご相談いただけます。 ▶ 無料相談はこちら

Claude Codeは日本語で使えるのか

検索すると「日本語化の設定が必要」という記事と「設定なしで使える」という記事の両方が出てきます。どちらも部分的に正しく、指している範囲が違うだけです。

整理すると、応答の言語は設定で固定でき、ツールの操作画面は英語のままという構造です。この線引きを先に把握しておくと、どこまで日本語にできるのかで悩まずに済みます。

設定なしでも日本語で会話できる

Claude Codeの背後で動いているのは多言語に対応したモデルです。そのため、インストール直後の状態で日本語の指示を入力すれば、内容は正しく理解され、日本語で応答が返ってきます。

日本語化という言葉から想像される、言語パックの導入やアプリの再設定といった作業は不要です。まず何も設定せずに日本語で話しかけてみるところから始めて問題ありません。

日本語の理解力と生成力は高い水準にあり、コードの説明、エラーの原因の解説、コミットメッセージの作成なども日本語で完結できます。生成AIの基礎については生成AIとは？仕組みと従来AIとの違いを解説で整理しています。

エンジニアでない担当者が触れる場面でも、この点は入口のハードルを下げます。コードの内容を日本語で説明させたり、既存のスクリプトが何をしているかを尋ねたりする使い方であれば、専門的な知識がなくても進められます。

それでも英語で返ってくる理由

実際に使っていると、途中から英語の応答に切り替わる場面に出会います。参照したドキュメントが英語だった、エラーメッセージが英語だった、といった文脈に引きずられるためです。

応答言語が明示的に固定されていない状態では、こうした揺れが起こります。毎回「日本語で」と指示し直す運用は続きません。設定で固定してしまうのが正しい対処になります。

揺れが起きやすいのは、長い作業の途中や、英語の資料を大量に読み込ませた直後です。文脈が英語に寄るほど、応答も引きずられます。裏を返せば、固定さえしておけばこの現象は起きません。

日本語化と多言語対応の違い

押さえておきたいのは、日本語にできる範囲です。応答の文章は日本語に固定できますが、コマンド名やメニューの表示といったツール側の要素は英語のままです。

この点を誤解すると、設定したのに英語が残っていると感じることになります。日本語で扱えるのは会話とコードのコメントの部分であり、操作体系そのものは英語という理解で進めてください。

▼ 自社の開発フローにどう組み込むか、整理しませんか ツールの設定だけでは開発の進め方は変わりません。現在の工程をうかがい、効果の出やすい箇所を一緒に特定します。 ▶ 開発体制を相談する

日本語で使うための設定方法

手段は3つあります。確実性と手軽さのバランスが異なるため、目的に応じて選びます。

選ぶ基準は、適用したい範囲と共有の要否です。自分だけが使うのか、チーム全体に効かせたいのか、その場限りで足りるのか。この3つのどれに当たるかで、書く場所が決まります。

settings.jsonのlanguageキーで固定する

公式に用意されている方法で、最も確実です。設定ファイルにlanguageというキーを追加し、値として言語を指定します。記述はごく短く、次の1行だけで完結します。

“language”: “japanese”

配置する場所は2つあります。すべてのプロジェクトに適用したい場合はホームディレクトリ配下の設定ファイル、特定のプロジェクトだけに適用したい場合はリポジトリ内の設定ファイルです。個人で使うならホーム側の1か所だけで足ります。

この設定は応答の言語を制御し、音声入力の機能を使っている場合はその言語にも影響します。コマンドラインのフラグや環境変数で同じことを指定する手段は用意されていないため、設定ファイルに書く方法が正式な手順にあたります。

設定ファイルは変更を検知して読み込み直される仕組みになっているため、多くの項目は再起動なしで反映されます。反映されているか不安な場合は、新しいセッションを立ち上げて確認するのが確実です。詳しい仕様はClaude Codeの設定に関する公式ドキュメントにまとまっています。

CLAUDE.mdに指示として書く

CLAUDE.mdは、Claudeに永続的な指示を与えるためのファイルです。公式ドキュメントではClaudeがプロジェクトを記憶する方法として説明されており、各セッションの開始時に読み込まれます。

言語設定専用のファイルではありませんが、「回答は必ず日本語で記述してください」と書けば指示として機能します。コーディング規約やアーキテクチャの方針と同じファイルにまとめて管理できる点が実用上の利点です。

設定ファイルによる指定と比べると、確実性ではやや劣ります。言語の固定は設定ファイル、コメントの書き方や用語の扱いはCLAUDE.mdという役割分担にすると、両方の利点を活かせます。

両方を併用しても矛盾は起きません。設定ファイルで言語を固定したうえで、CLAUDE.mdに「技術用語は英語のまま残す」といった細かな方針を書き足す形が、実務では扱いやすい構成になります。

確実性で並べると、設定ファイル、CLAUDE.md、その場の指示という順序になります。手軽さはちょうど逆順です。継続して使うほど、上位の手段に移していく価値が出てきます。

会話の中で指示する

その場で「以降は日本語で回答してください」と伝える方法もあります。設定を触らずに済むため、試したいだけの場面では最も手軽です。

ただし効果はそのセッション内に限られ、新しく開始すると元に戻ります。継続して使うなら、設定ファイルに書く方法へ移行してください。

CLAUDE.mdの書き方と注意点

言語だけでなく、開発の前提を伝える手段として活用できるファイルです。書き方によって守られる度合いが変わります。

扱い方を誤ると、設定ファイルの肥大化と指示の形骸化を招きます。何を書き、何を書かないかの線引きを最初に決めておくと、運用が長く続きます。

配置場所とスコープ

公式ドキュメントによると、CLAUDE.mdは複数の場所に置けます。組織全体に適用する管理ポリシーの場所、すべてのプロジェクトに効くユーザー向けの場所、リポジトリ内のプロジェクト向けの場所、そして個人用のローカル向けの場所です。

読み込みは広いスコープから順に行われ、起動した場所に近い指示が後から読まれます。チームで共有したい内容はリポジトリ内、個人の好みはホーム配下という使い分けが基本になります。

自動で生成させる手段も用意されています。初期化のコマンドを実行すると、コードベースを解析したうえでビルドコマンドや規約を含むファイルが作られます。ゼロから書くより、生成されたものを土台に手を入れるほうが早く仕上がります。

効果的な書き方

公式では、1ファイルあたり200行以下を目安とするよう案内されています。長くなるほどコンテキストを消費し、指示が守られる度合いも下がるためです。

書き方のコツは具体性です。「コードを適切にフォーマットする」ではなく「2スペースのインデントを使用する」のように、検証できる粒度まで落とし込みます。見出しと箇条書きで整理すると、読み取られやすくなります。

矛盾する指示を残さないことも重要です。複数のファイルに異なる方針が書かれていると、どちらが採用されるか定まりません。定期的に見直して、古い記述を削除する運用にしておきます。指示の設計はプロンプトの書き方と業務で使えるテンプレートも参考になります。

内容の目安としては、プロジェクトの構成、ビルドとテストのコマンド、命名の規則、やってほしくない操作が中心になります。コードを読めば分かることを書き写す必要はありません。

指示が守られないときの確認手順

CLAUDE.mdの内容は、強制的な設定ではなくコンテキストとして扱われます。そのため、必ず従うという保証はありません。守られていないと感じたら、まず読み込まれているかを確認します。

セッション内で専用のコマンドを実行すると、読み込まれているファイルの一覧が表示されます。一覧に出てこなければ、そもそも参照されていないということです。配置場所を見直すか、指示をより具体的に書き換えます。

日本語環境で起きやすいトラブル

設定が正しくても、表示や入力の面で問題が出ることがあります。原因の切り分け方を整理します。

起きる事象は、表示に関するものと入力に関するものに分かれます。どちらもClaude Code側ではなく端末環境が原因のことが多いため、切り分けの順序を知っていれば短時間で解決できます。

文字化けが起きる場合

日本語が四角い記号として表示されたり、にじんで見えたりする現象です。多くの場合、エディタに組み込まれたターミナルの描画処理が原因で、日本語固有の問題ではありません。

対処としては、Claude Code内でターミナルの設定を調整するコマンドを実行し、エディタを再読み込みする方法があります。多バイト文字は崩れが目立ちやすいため、日本語で使い始めた段階で気づくケースが多くなります。

切り分けの手順としては、まず別のターミナルアプリで同じ操作を試します。そちらで正常に表示されるなら、原因はClaude Code側ではなく描画環境にあると特定できます。

日本語入力の不具合

変換の途中で表示が乱れる、入力が遅れるといった症状が出ることがあります。ターミナルの文字コードがUTF-8になっているかを確認し、使用しているターミナルアプリを変えて再現するかを見てください。

主要なターミナルアプリは日本語入力に対応しています。特定の環境だけで起きる場合は、そのアプリの設定か描画処理に原因があると判断できます。

文字コードの確認も基本の手順です。ほとんどの環境では既定でUTF-8になっていますが、古い設定が残っている端末では別の値になっていることがあります。この場合は文字化けが常時発生します。

コマンドやメニューは英語のまま

設定を入れても、スラッシュコマンドの一覧やモデル選択の画面などは英語で表示されます。これは仕様であり、不具合ではありません。

操作に関わる部分は英語で覚える前提で進めると、迷いが減ります。よく使うコマンドを一覧にして手元に置いておくと、チームへの展開時にも役立ちます。

▼ 設定やルールを社内で標準化したい方へ 個人の工夫のままでは、チーム全体の生産性には結びつきません。設定の共有ルールづくりから支援します。 ▶ 標準化を相談する

日本語と英語の使い分け

すべてを日本語にすることが最適とは限りません。場面によって使い分けると、精度と効率の両方が上がります。

判断の軸はシンプルで、情報の正確さが失われないほうを選ぶという一点です。翻訳を挟むことで意味がぶれる内容は原語のまま、自分の意図を伝える内容は書き慣れた言語で、と考えれば迷いません。

日本語が向く場面

業務の要件や背景を伝える場面では、日本語のほうが正確に書けます。無理に英語にすると、意図が抜け落ちたり曖昧になったりして、かえって手戻りが増えます。

コードの説明を受ける場面、設計の相談をする場面、レビューの観点を伝える場面も日本語が適しています。自分が正確に書ける言語で指示を出すことが、結果的に品質を左右します。

レビューの指摘を受け取る場面も同様です。なぜその修正が必要なのかという説明は、日本語のほうが理解の速度が上がります。学習の効率という観点でも、母語で受け取る利点は小さくありません。

英語のまま扱ったほうがよい場面

エラーメッセージやログは、翻訳せずそのまま貼り付けたほうが確実です。訳した時点で情報が変質し、原因の特定が難しくなることがあります。

ライブラリの仕様やフレームワークの用語も同様です。公式ドキュメントが英語で書かれている以上、その表記のまま扱ったほうが照合の精度は上がります。無理にカタカナへ置き換える必要はありません。

コミットメッセージやプルリクエストの説明文も、チームの慣習に合わせて決めておきます。個人の判断に任せると表記が揺れ、後から履歴を追う際の手がかりが弱くなります。

トークン消費の観点

日本語は英語に比べて同じ内容でも消費するトークンが多くなる傾向があります。長い説明を毎回日本語でやり取りすると、その分の負担が積み上がります。

対策としては、CLAUDE.mdを簡潔に保つこと、指示を冗長にしないことが効きます。必要な情報を短く伝える書き方は、コストと精度の両面で有利に働きます。

コスト面では、やり取りの回数を減らす工夫のほうが効果は大きくなります。前提を先にまとめて渡し、往復を減らす。この基本は言語にかかわらず有効です。

コメントとドキュメントの言語

生成されるコードのコメントをどちらの言語にするかは、チームの方針で決まります。日本語のメンバーだけで開発するなら日本語、外部との共有を想定するなら英語という判断になります。

重要なのは、途中で方針が揺れないことです。同じコードベースに両方の言語が混在する状態が最も読みづらくなります。CLAUDE.mdに明記して、生成される時点で揃えておいてください。

チームで日本語設定を統一する

個人の設定で終わらせると、メンバーごとに出力の形式が変わります。組織で使うなら統一の仕組みが必要です。

統一されていないと、同じリポジトリの中で日本語のコメントと英語のコメントが混在し、レビューのたびに指摘が発生します。設定を揃えるだけで防げる摩擦は、早めに潰しておく価値があります。

プロジェクト単位で共有する

リポジトリ内の設定ファイルとCLAUDE.mdをバージョン管理に含めれば、メンバー全員に同じ設定が適用されます。新しく参加した人も、リポジトリを取得した時点で同じ環境になります。

共有するのは、言語設定に加えてコーディング規約、ビルドとテストのコマンド、ディレクトリの構成といった内容です。プロジェクトの引き継ぎ書としても機能するため、書いておく価値は設定以上のものになります。

共有する範囲は段階的に広げます。最初から完璧なファイルを作ろうとすると着手が遅れるため、言語設定と最低限の規約だけで運用を始め、必要になった項目を追記していく進め方が現実的です。

レビューの観点や禁止事項を書いておくと、生成される時点で品質が揃います。人が指摘して直させるより、はじめから守らせるほうが手戻りは少なくなります。

組織全体に配布する

会社としての標準を全社に適用したい場合、管理ポリシーとして配置する方法が用意されています。この場所に置いたファイルは個別の設定で除外できないため、全体に必ず適用されます。

配布には端末管理の仕組みを使います。セキュリティ方針やコンプライアンス上の要件を含めておくと、開発者ごとの判断に依存しない運用が可能になります。

組織の設定と個人の設定は目的が異なります。技術的に禁止したい操作は設定側で制御し、書き方や進め方の方針は指示ファイル側に書く。この切り分けを最初に決めておくと、後から管理が破綻しにくくなります。

ルールを整理して肥大化を防ぐ

プロジェクトが大きくなると、CLAUDE.mdに書きたいことが増えていきます。すべてを1つのファイルに詰め込むと、読み込みの負荷が上がり指示の遵守も下がります。

公式では、専用のディレクトリにトピック別のファイルを置き、対象とするファイルの種類を指定して読み込ませる仕組みが案内されています。テスト、API設計、セキュリティといった単位で分けると保守しやすくなります。

▼ メンバーが使いこなせる状態まで持っていきたい方へ 研修は座学だけでは定着しません。実際のコードベースを題材に手を動かす形式で、翌日から使える状態までを設計します。 ▶ 研修プログラムを相談する

日本語で使い始めるための手順

設定そのものは数分で終わります。そこから成果につなげるまでの流れを整理します。

着手の順序は、個人設定、プロジェクト設定、組織設定の3段階です。いきなり組織全体に配ろうとすると、運用の勘所が分からないまま標準が固まってしまいます。

最初にやること

ホームディレクトリ配下の設定ファイルに言語の指定を追加します。ファイルが存在しない場合は新規に作成し、既にある場合は既存の記述に追記する形にしてください。

設定を保存したら、新しいセッションを開始して日本語で返ってくるかを確認します。上書きで既存の設定を消してしまう事故が起きやすいため、編集前に内容を控えておくと安全です。

設定を終えたら、実際の作業で数回試してみてください。既存のコードを読ませて説明させる、小さな修正を依頼するといった軽い作業から入ると、応答の質と癖がつかめます。

社内へ展開する進め方

個人の環境で有効性を確かめたら、一つのプロジェクトに絞って共有設定を導入します。全社に一斉展開するより、成功例を作ってから広げるほうが定着します。

展開の際は、設定の内容だけでなく使い方の共有も必要です。指示の出し方によって結果が大きく変わるため、うまくいった例を蓄積する場を用意しておきます。学習設計はAI人材の育成方法と社内研修の設計手順で解説しています。

つまずきやすいのは、設定はできたが使い方が分からないという段階です。ツールの導入と使い方の共有はセットで進めてください。研修の組み立て方は生成AI研修で何を学ぶ？企業向けプログラムの選び方で解説しています。

推進する担当者を決めておくことも欠かせません。兼務のまま進めると通常業務が優先され、検証が止まります。工数の何割を充てるのかを事前に決めておくと、現場の協力も得やすくなります。

効果の測り方

導入前に、何をもって成果とするかを数値で決めておきます。実装にかかる時間、レビューでの指摘件数、既存コードの理解にかかる時間といった指標が使いやすい候補です。

測定の基準がないと、感覚だけで継続の可否を判断することになります。開発全体の進め方を見直す観点はAI開発とは？種類・費用相場・開発の流れと会社の選び方で整理しています。

自社だけで進めるのが難しい場合は、外部の支援を受ける選択肢もあります。導入の初期設計だけを依頼し、運用は社内で回す形であれば費用も抑えられます。委託時の考え方はAI受託開発とは？依頼できること・費用相場・開発会社の選び方にまとめています。

まとめ

Claude Codeは設定を入れなくても日本語で会話できますが、応答が英語に戻る揺れが起こります。確実に固定したい場合は、設定ファイルにlanguageキーを追加する方法が公式に用意されており、これが最も確実な手段です。

CLAUDE.mdは言語設定専用のファイルではないものの、指示として書けば有効に働きます。1ファイル200行以下、具体的で矛盾のない記述という原則を守れば、コーディング規約とあわせて管理できる実用的な仕組みになります。守られていないと感じたら、まず読み込まれているかを確認してください。

文字化けの多くはターミナル側の描画が原因で、日本語固有の問題ではありません。そして、すべてを日本語にする必要もありません。要件は日本語、エラーや技術用語は英語のままという使い分けが、精度とコストの両面で有利に働きます。

▼ 最初の一歩を、一緒に設計します AIを使った開発は、対象工程の選び方で成果が大きく変わります。愛媛・東京を拠点に、AI研修と開発支援の両面から企業のAI活用を伴走しています。 ▶ お問い合わせ・無料相談はこちら