Claude Code の応答を日本語にする — 毎回頼まなくていい設定

英語で流れてくる処理内容を読むのに時間がかかる

Claude Code を使い始めると、まずここでつまずきます。AI が何をしようとしているかの説明が英語で流れていくので、読み解くのに時間がかかります。

そのうち、内容を追うのをやめて結果だけ見るようになります。これは避けたい状態です。途中の説明を読まなくなると、意図と違う方向に進んでいることに気づくのが遅れます。

対処としてプロンプトに「日本語で答えて」と書いている方も多いと思います。動きはしますが、設定で解決できます。

/config から言語を指定する

ターミナルで次のコマンドを打つと設定画面が開きます。

/config

表示される項目のなかから language を探し、日本語を指定します。項目が多いときは、画面に出るフィルターに language と入力すると絞り込めます。

これだけです。以降は AI 側の説明が日本語で出るようになります。

プロンプトで指示するのと何が違うか

結果として日本語になる点は同じですが、性質が違います。

プロンプトでの指示は、会話が長くなるにつれて最初の指示が薄れ、英語に戻ることがあります。長時間の作業ほど設定にしておく利点が出ます。

もう 1 つ、プロンプトで毎回指示する方式には見えにくい損があります。指示に使った分だけ、本来の依頼に割ける余地が減ります。 1 回あたりは小さくても、毎回書いていれば積み上がります。設定に移せば、そのぶんがまるごと空きます。

精度が落ちるのではないかという心配

「日本語で答えさせると質が落ちるのでは」と聞かれることがあります。言語の指定は出力の言語を決めるもので、考える深さや正確さを変えるものではありません。

実際に効いてくるのは逆の側です。読めない状態で使い続けるほうが、結果として品質を落とします。 理由は後述します。

気になる場合は、しばらく使って手戻りの量が変わるかを見てください。設定はいつでも戻せるので、試してから判断すれば十分です。

用語まで訳させない

1 つだけ気をつける点があります。設定を入れると、技術用語まで無理に日本語へ置き換えられることがあります。読みにくくなるだけでなく、検索しても情報が出てこなくなります。

気になるときは、依頼の中で一言添えておくと安定します。

説明は日本語で。技術用語・コマンド名・ファイル名はそのまま英語で書いてください。

固有名詞やコマンドは、原語のほうが調べやすく、他の資料とも突き合わせやすくなります。訳すのは説明で、名前は訳さない と考えておくとちょうどよいはずです。

設定が効かないときに見る順番

設定したはずなのに英語のまま、という場合があります。原因はいくつかありますが、確認する順番を決めておくと早く切り分けられます。

1. 設定が保存されているか。もう一度 /config を開いて、指定した内容が残っているかを見ます
2. 起動し直したか。設定を変えた直後のセッションでは反映されないことがあります
3. プロジェクト側の指示と競合していないか。リポジトリに置いた指示書が英語で書かれていると、そちらに引っ張られることがあります
4. 依頼そのものが英語か。英語で聞けば英語で返ってきます

実際に多いのは 3 つ目です。設定は全体に効きますが、その場の指示のほうが強く効きます。 プロジェクトの指示書を英語で書いているなら、そこに「応答は日本語で」と一行足しておくと安定します。

4 つ目も見落とされがちです。英語の資料をそのまま貼って質問すると、文脈に引きずられて英語で返ることがあります。この場合は、質問文だけでも日本語で書けば戻ります。

英語のままにしておくほうがよい場面

例外もあります。次のような場合は、無理に日本語へ寄せないほうが運用しやすくなります。

判断の軸は、その出力を誰が読むかです。 自分と社内のメンバーだけが読むなら日本語のほうが速く、社外や海外のメンバーが関わるなら英語のほうが手戻りが少なくなります。

それでも英語が混ざるとき

設定したのに英語が残る場合、その部分が何なのかを見てください。混ざるのは主に次の 2 つです。

1 つ目は、実行したコマンドの出力です。テストの結果やビルドのログは、そのツールが出した文字列をそのまま表示しているだけなので、言語設定では変わりません。

2 つ目は、ライブラリやフレームワークが出すエラーメッセージです。これも同じ理由で、AI が書いた文章ではありません。

つまり、地の文 (AI 自身の説明) が日本語になっていれば設定は効いています。 ツールの出力まで日本語にしたい場合は、そのツール側の設定を見ることになります。

FIXIT

毎回「日本語で」って打ってたんだけど、意味なかったの？

Hinata

その気持ち、わかります。動くので気づきにくいんですよ。

FIXIT

じゃあ設定にしたほうがいいってこと？

Hinata

はい。一度入れておけば次から要らないので、試してみてください。

読める状態にすると、確認の回数が変わる

小さい設定ですが、効き方は見た目より大きいところがあります。

説明が読める状態になると、AI が何をしようとしているかを途中で確認するようになります。確認の回数が増えると、意図と違う変更に早く気づけます。手戻りが減るのは、精度が上がったからではなく、見るようになったからです。

逆に、読みにくいまま使っていると結果だけを見る運用になり、おかしな変更が混ざったまま先に進んでしまいます。導入したばかりのチームで手戻りが多いときは、この入口を疑ってみてください。

日本語で依頼するときに気をつけること

出力が日本語になると、依頼のほうも日本語で書くようになります。ここで質が変わるのが、曖昧さの残りやすさ です。

日本語は主語を省いても文が成立します。「直しておいて」「いい感じにして」で通じてしまうぶん、指示としては曖昧なまま渡ることになります。英語で書いていたときは、文を組み立てる過程で主語や目的語を埋めていたので、結果的に具体化されていました。

日本語で書くときは、次の 3 つが入っているかを確認してください。

• 何を 変えるのか。ファイルや箇所を特定する
• どうなったら 完了なのか。終わりの状態を書く
• どこは 触らないのか。範囲を切る

とくに 2 つ目が抜けやすい部分です。「使いやすくして」は、完了の判断ができません。「入力が空のときにエラー文言を出す」まで書けば、できたかどうかがその場で分かります。

導入直後のチームでよくある詰まり方

日本語設定は小さな話ですが、導入したてのチームでは、ここが原因で使われなくなることがあります。よく見る形が 3 つあります。

1 つ目は、英語だから読まないまま結果だけ受け取る ようになるケースです。何をしたのか把握しないまま変更が積み上がり、あとでまとめて確認することになります。手戻りが大きくなるのはこの形です。

2 つ目は、毎回「日本語で」と打つのが面倒で使わなくなる ケースです。設定の存在を知らないと、この手間が使うたびに発生します。

3 つ目は、一部の人だけが設定を知っている ケースです。慣れた人は快適に使い、知らない人は英語のまま格闘します。同じツールを配ったのに、体験の差が開きます。

いずれも、導入手順に一行あれば起きません。技術の問題ではなく、共有の問題です。

どこまで読むかの目安

日本語になったあとで、次に出てくるのが「全部読むべきか」という疑問です。全部読んでいると、結局スピードが出ません。

読む価値が高いのは、次の 2 箇所です。

• これから何をするか を書いている部分。着手前に方向が分かる
• 前提を置いた 部分。「〜という想定で進めます」と書かれている箇所

逆に、実行したコマンドの結果や、変更後の細かな説明は流し読みで構いません。差分そのものを見たほうが速いためです。

止めるべきかどうかは、着手前の説明でほぼ判断できます。 終わってから読むと、直す作業が発生します。読む場所を絞ると、日本語にした効果がそのまま速さに変わります。

読む場所を絞ると、確認が習慣になる

日本語で読めるようになっても、全部を追いかけていると疲れます。続けるには、見る場所を決めてしまうのが早いです。

実務で回している人の見方は、だいたい次のようになっています。

確認の価値が最も高いのは、着手前です。 そこで方向が違えば、作業そのものが不要になります。終わってから読むと、直す作業が追加で発生します。

この見方に慣れると、読む量は減るのに気づく回数は増えます。日本語にする目的は全部読むことではなく、要るところだけを速く読めるようにすること だと考えてください。

よくある誤解を 3 つ

この設定について、聞かれることの多い誤解をまとめておきます。

「日本語にすると遅くなる」。 言語の指定は出力の言語を決めるだけで、処理の速さを変える設定ではありません。体感で遅く感じる場合は、別の要因を疑ってください。

「一度設定すると英語に戻せない」。 いつでも戻せます。/config から指定を変えるだけです。試して合わなければ戻せばよい、という前提で入れて構いません。

「英語で使ったほうが本来の性能が出る」。 出力の言語と、内部で考える深さは別のものです。むしろ、読めないまま使い続けて確認が減るほうが、実務上の損は大きくなります。

いずれも「よく分からないから触らない」ことから生まれています。設定 1 つで戻せる範囲なので、迷うより試したほうが早いです。

他のツールでも考え方は同じ

Claude Code に限らず、対話しながら作業を進める種類のツールには、たいてい似た設定があります。名前は違っても、出力の言語をあらかじめ決めておける という点は共通しています。

複数のツールを使い分けている場合は、導入時にまとめて確認しておくとよいです。片方だけ日本語で、もう片方が英語のままだと、切り替えるたびに読む速度が落ちます。

確認の順番としては、次のようになります。

1. 設定画面に言語の項目があるか探す
2. 無ければ、プロジェクト側の指示書に一行足す
3. それも難しければ、依頼の冒頭で指定する

上ほど手間が少なく、下ほど毎回の作業が増えます。同じ結果を得るなら、上から順に試すのが得です。

入れた直後の 3 日で見るもの

設定を変えたあと、効いているかどうかは短期間で分かります。見るのは次の 2 点です。

1 つは、説明を読む回数が増えたか。以前は流していた部分に目が行くようになっていれば、狙いどおりです。

もう 1 つは、途中で止める回数が増えたか。読める状態になると、進む前に「それは違う」と言えるようになります。止める回数が増えるのは悪い兆候ではなく、手戻りを前倒しできている状態です。

逆に、設定しても何も変わらない場合は、そもそも説明を読む習慣が無い可能性があります。その場合は設定より先に、着手前の説明だけは読む、という運用を決めるほうが効きます。

チームに配るときは手順書に 1 行

設定は各自の環境に保存されるので、自動では共有されません。導入手順に「/config から language を指定する」の 1 行を入れておくと、新しく参加した人がつまずかずに済みます。

英語のまま使い続けている人は、設定の存在を知らないだけということがほとんどです。チーム内で一度共有するだけで解決します。

初日に済ませておくと後が楽になる項目を挙げておきます。どれも数分で終わります。

• 応答の言語を指定する
• 技術用語は英語のままにする旨を、プロジェクトの指示書に書いておく
• 着手前の説明は読む、という運用をチームで合意しておく

3 つ目は設定ではありませんが、いちばん効きます。読める状態を作っても、読む習慣が無ければ何も変わりません。 順番としては、設定を入れてから運用を決めるのではなく、同時に決めてしまうほうが定着します。

新しく入った人には、この 3 つを最初の日に渡してください。あとから直すより、最初から入っているほうが摩擦がありません。

まとめ

• 応答が英語なのは設定の問題で、プロンプトで毎回指示する必要はない
• /config で言語を指定すれば、起動のたびに効き、プロジェクトを移っても引き継がれる
• 効かないときは、保存・再起動・プロジェクト側の指示・依頼文の順に見る
• 技術用語まで訳させない。訳すのは説明で、名前は訳さない
• 読める状態にすると確認の回数が増え、手戻りが前倒しになる
• 導入手順に一行入れるだけで、チーム内の体験差がなくなる

Claude Code の導入そのものを体系立てて進めたい場合は Claude Code を実務に導入する完全ガイド が出発点になります。設定まわりの全体像は Claude Code の初期設定ガイド にまとめています。