Claude Codeの文字化けを直す方法｜Windows・WSL別の設定

Claude Codeで日本語が文字化けするのは、多くの場合ターミナルの文字コードがUTF-8になっていないことが原因です。結論から言えば、Windowsは文字コードをUTF-8へ切り替え、WSLやmacOS・LinuxはLANGをja_JP.UTF-8に設定すれば直ります。ただし文字化けは「入力・出力・ファイル・フォント」のどこで崩れているかで対処が変わり、やみくもに設定を足すとかえって再発しがちです。この記事では、編集部が実機で確認した環境別の直し方を、コマンドと設定値つきで解説します。あわせて、原因の切り分け手順と、サイト制作や自社ツールの定期実行で文字化けを再発させない設定までまとめました。

01Claude Codeの文字化けとは？主な原因は文字コードの不一致

Claude Codeの文字化けとは、応答やログの日本語が「�」や意味の通らない記号、または白い四角（いわゆる豆腐）で表示される状態です。原因の大半は、Claude Codeが前提とするUTF-8と、ターミナル側の文字コードがそろっていないことにあります。とくにWindowsのPowerShellやコマンドプロンプトは、日本語環境では既定がShift_JIS（CP932）になりやすく、UTF-8の出力とぶつかって崩れます。

文字化けの原因を一言でいうと？

一言でいえば、送る側（Claude Code）と受け取る側（ターミナル）で文字の「読み方」が違うことが原因です。UTF-8で書かれた日本語をShift_JISとして読もうとするため、対応表がずれて別の文字に化けます。したがって直し方の軸は「受け取る側をUTF-8にそろえる」ことに集約されます。

豆腐（□）になる場合は原因が違う？

白い四角が並ぶ場合は、文字コードではなくフォントに日本語のグリフが入っていないことが原因です。この場合はターミナルの表示フォントを日本語対応のものに変えると直ります。文字コードのずれ（記号化け）とフォント不足（豆腐）は原因が別なので、まずどちらなのかを見分けることが近道です。

02まず試す：文字化けの原因を切り分ける3つの確認

設定を足す前に、どこで崩れているかを確認します。切り分けを先にやると、環境に合わない設定を重ねて逆に不安定になる事態を避けられます。次の3点を順に見てください。

今の文字コードはどう確認する？

Windowsのコマンドプロンプトやターミナルではchcpと打つと、現在のコードページ番号が返ります。932ならShift_JIS、65001ならUTF-8です。macOSやLinux、WSLではlocaleまたはecho $LANGを実行し、ja_JP.UTF-8やC.UTF-8のようにUTF-8が含まれているかを見ます。ここがUTF-8になっていなければ、次の環境別の手順で切り替えます。

03Windowsの文字化けを直す方法（PowerShell・コマンドプロンプト）

Windowsは文字化けが最も起きやすい環境です。PowerShellとコマンドプロンプトで手順が少し異なります。

PowerShellでの直し方

PowerShellでは、コンソールの出力エンコーディングをUTF-8に変えます。次の1行を実行してから、Claude Codeを起動し直してください。

# 現在のセッションで出力をUTF-8にする
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8

# 毎回自動で適用したい場合はプロファイルに追記
notepad $PROFILE
# ↑に上の1行を書いて保存すると、次回起動から有効になる

Pythonを介したツールで日本語が崩れる場合は、環境変数PYTHONUTF8=1を設定するとPython側の出力もUTF-8に固定できます。パイプでつないだときに崩れるなら$OutputEncodingもUTF-8にそろえると安定します。

コマンドプロンプト（CMD）での直し方

コマンドプロンプトでは、コードページをUTF-8に切り替えるchcp 65001が有効です。chcpは現在のコードページを表示・変更するコマンドで、65001がUTF-8を表します。切り替えは一時的なので、毎回使うならターミナルのプロファイル側でUTF-8を既定にしておくと手間が省けます。

04WSLの文字化けを直す方法

WSL（Windows上のLinux）では、ロケール自体が日本語UTF-8に対応していないと化けます。まず日本語ロケールを生成し、既定に設定します。

# 日本語ロケールを生成する
sudo locale-gen ja_JP.UTF-8

# 既定のLANGをUTF-8にする
sudo update-locale LANG=ja_JP.UTF-8

# 現在のシェルにも反映（~/.bashrc に書いておくと永続化）
export LANG=ja_JP.UTF-8

設定後はWSLを開き直すか、シェルを再読み込みして反映させます。localeでLANG=ja_JP.UTF-8と表示されれば準備完了です。WSL特有のつまずきは、Windows側のターミナルはUTF-8なのにWSL内のロケールが未設定というちぐはぐな状態で、この場合はWSL内のLANGを直すのが正解です。

05macOS・Linuxの文字化けを直す方法

macOSやLinuxのターミナルは既定でUTF-8のことが多いものの、SSH接続先やシェルの設定によってはLANGが未設定で化ける場合があります。対処はシェルの設定ファイルにLANGを書くだけです。

# zsh（macOS標準）なら ~/.zshrc に追記
echo 'export LANG=ja_JP.UTF-8' >> ~/.zshrc
source ~/.zshrc

# bashなら ~/.bashrc に同様に追記
echo 'export LANG=ja_JP.UTF-8' >> ~/.bashrc

それでも記号化けが残るなら、LC_ALL=ja_JP.UTF-8もあわせて設定すると、ロケール関連のすべての項目をUTF-8に上書きできます。反対に四角（豆腐）が出るときは文字コードではなくフォントの問題なので、ターミナルの表示フォントを日本語グリフを含むものに変更してください。

06Dockerコンテナ・VSCodeターミナルの文字化け

開発コンテナやエディタの統合ターミナルでも、同じく文字コードの不一致で化けます。それぞれ設定箇所が違うため、分けて押さえます。

Dockerの開発コンテナでの直し方

コンテナのベースイメージに日本語ロケールが入っていないと、日本語の入出力が崩れます。Dockerfileでロケールを生成し、環境変数を設定します。

RUN apt-get update && apt-get install -y locales
RUN locale-gen ja_JP.UTF-8
ENV LANG=ja_JP.UTF-8
ENV LC_ALL=ja_JP.UTF-8

ビルドし直すと、コンテナ内のClaude Codeやスクリプトの日本語がそろいます。ENVで環境変数を焼き込むため、コンテナを起動するたびに設定し直す必要がありません。

VSCodeの統合ターミナルでの直し方

VSCodeの統合ターミナルで化ける場合は、settings.jsonで"files.encoding": "utf8"を設定し、ターミナルの表示フォントを日本語対応のものにそろえます。統合ターミナルは裏で使っているシェルの設定を引き継ぐため、macOSなら~/.zshrc、WSLなら前述のロケール設定が効いているかもあわせて確認すると確実です。

07設定前と設定後で表示はどう変わる？【環境別・比較表】

環境ごとに「化けている状態」と「設定後の状態」を並べると、どこを直せばよいかが一目で分かります。次の表は、編集部が実機で確認した設定と結果を整理したものです。

この設定によって、アウトプットにも差が出ると想定されます。文字化けが解消すると、Claudeが返すファイルパスやエラーメッセージ、差分のコメントが日本語で正しく読めるようになります。読めない状態では指示のやり取りに手戻りが生じやすいため、UTF-8にそろえるだけで、日本語を含む作業のレビュー効率が上がると考えられます。

08サイト制作・自社ツール開発での文字化け対策【実践】

ここからは編集部の実務での対策です。文字化けは、対話中よりも「自動で回す処理」で表面化しやすいという特徴があります。

サイト制作：HTML・CSVの文字コードをそろえる

LPやサイトの原稿をClaude Codeで生成・編集するときは、保存する文字コードをUTF-8に固定します。既存ファイルがShift_JISのまま混在していると、追記した日本語だけ化けることがあります。取り込むCSVも同様で、Excelから出したShift_JISのCSVはUTF-8へ変換してから渡すと崩れません。編集後は、ブラウザやエディタでUTF-8として開き、見出しや全角記号が崩れていないかを確認する一手を挟むと安全です。

自社ツール開発：定期実行でLANGが空になる問題を防ぐ

効率化のための自動化で最も多いのが、cronやlaunchdなど定期実行の中で日本語が化けるケースです。これらの実行環境は、対話用のシェルと違ってLANGが空のまま起動することがあり、UTF-8前提の処理が崩れます。対策は、実行スクリプトの先頭で環境変数を明示することです。

#!/bin/bash
# 定期実行スクリプトの先頭で文字コードを固定する
export LANG=en_US.UTF-8
export LC_ALL=en_US.UTF-8
export PYTHONUTF8=1

# この下で Claude Code やスクリプトを呼び出す
# 例）記事の本文を生成してファイルに保存する処理など

ポイントは、対話では化けないのに定期実行だけ化ける場合、原因はほぼLANGの未設定だという点です。実行スクリプトに数行足すだけで、日本語のログやファイル出力の崩れを防げます。WordPressへ日本語記事をAPI投稿する処理でも、送信前にファイルをUTF-8で読み込むよう固定しておくと、投稿後の文字化けを避けられます。関連する自動化の考え方はClaude Codeプランモードの使い方や非エンジニアのスラッシュコマンド12選でも触れています。

09再発を防ぐ設定（永続化）

その場しのぎの切り替えだけだと、端末を開き直すたびに化けが戻ります。再発を防ぐには、設定を永続化するのが要点です。Windowsはプロファイル（$PROFILE）へ、macOS・Linux・WSLはシェルの設定ファイル（~/.zshrcや~/.bashrc）へ、それぞれ文字コードの設定を書いておきます。チームで環境をそろえるなら、案件のCLAUDE.mdに「出力はUTF-8を前提にする」旨を明記しておくと、参加者ごとの設定漏れによる化けを減らせます。

10よくある質問

Claude Codeの文字化けはなぜ起きるのですか？

ターミナルの文字コードがUTF-8になっていないことが主な原因です。Claude CodeはUTF-8で日本語を出力するため、受け取るターミナルがShift_JISなどのままだと対応表がずれて化けます。まずはchcpやlocaleで現在の文字コードを確認してください。

Windowsで一番簡単な直し方はどれですか？

コマンドプロンプトならchcp 65001、PowerShellなら[Console]::OutputEncodingをUTF-8にするのが手早い方法です。毎回設定するのが面倒なら、PowerShellのプロファイルに書いて自動化しておくと再発しません。

白い四角（□）が出るのも文字化けですか？

症状は似ていますが原因が異なります。四角はフォントに日本語のグリフが含まれていないときに出るため、文字コードではなく表示フォントを日本語対応のものへ変更すると直ります。記号化け（�）は文字コード、四角はフォント、と覚えると切り分けが速くなります。

設定したのにターミナルを開き直すと戻ってしまいます。

設定がその場限りになっているのが原因です。Windowsは$PROFILE、macOS・Linux・WSLは~/.zshrcや~/.bashrcに設定を書くと、次回以降も自動で適用されます。永続化しておけば都度の設定は不要になります。

対話中は問題ないのに、自動実行だけ文字化けします。

cronやlaunchdなどの定期実行ではLANGが空のまま起動することがあり、これが原因です。実行スクリプトの先頭でexport LANG=ja_JP.UTF-8のように文字コードを明示すると解消します。対話用のシェル設定は自動実行には引き継がれない点に注意してください。

11まとめ：まずUTF-8にそろえる

Claude Codeの文字化けは、原因のほとんどが文字コードの不一致です。直し方の軸は「受け取る側をUTF-8にそろえる」で一貫しており、Windowsはchcp 65001と[Console]::OutputEncoding、WSL・macOS・LinuxはLANG=ja_JP.UTF-8が基本です。□の場合はフォント、と切り分ければ迷いません。まずはchcpやlocaleで現状を確認し、環境に合った設定を1つ入れてから開き直すのが失敗しない進め方です。自動化まで踏み込むなら、定期実行スクリプトにexport LANGを明記して再発を止めておくと安心です。次の一歩として、大きな修正を安全に任せるClaude Codeプランモードの使い方もあわせて確認してみてください。

12出典

• chcp — Microsoft Learn（コードページの表示・変更コマンド。65001がUTF-8）
• about_Character_Encoding — Microsoft Learn（PowerShellの文字エンコーディング）
• Terminal configuration — Claude Code Docs（ターミナル設定）