ターミナルの文字化けは、原因が2つしかありません。日本語が「�」や見慣れない漢字の羅列になるなら文字コードのずれ、「□」が並ぶならフォントに日本語が入っていないかのどちらかです。この記事では症状から原因を突き止める診断表を先に置き、Windows・VSCode・macOS・WSL・Claude Codeの環境別の直し方を、コマンドと設定値つきで解説します。

01ターミナルの文字化けはなぜ起きる？原因は文字コードとフォントの2つ

ターミナルの文字化けは、文字コードのずれか、フォントの日本語不足のどちらかで起きます。この2つは症状の見た目がはっきり違うため、画面を1秒見れば切り分けられます。設定を足す前に、いま出ているのがどちらなのかを先に決めてください。

「�」や見慣れない漢字が並ぶのは文字コードのずれ

日本語が「譁�蟄怜喧縺」のような漢字の羅列になるのは、文字を書き出した側と読み取った側で対応表が食い違っているからです。多くのCLIツールやプログラムはUTF-8で日本語を出しますが、Windowsの日本語環境ではターミナル側の既定がShift_JIS（CP932）です。UTF-8の並びをShift_JISの対応表で読むため、まったく別の文字に化けます。この形なら直すのは読み取る側で、ターミナルのコードページやロケールをUTF-8にそろえれば、同じ出力がそのまま日本語として読めます。

同じ文字コードのずれでも、「�」と「?」は逆を向いています。「�」は置換文字（U+FFFD）といい、読み取る側がUTF-8として解釈しているのに、届いたバイト列がUTF-8ではないときに出ます。つまり崩れているのは書き出す側で、読み取る側のコードページを触っても消えません。

いっぽう「?」は、書き出す側がCP932などのUTF-8以外で出力していて、その文字を表現できずに代用した跡です。変換先で表現できない文字を疑問符で代用する動きは、Microsoftの.NETドキュメントにも既定の挙動として書かれています。どちらの記号が出ているかで直す場所が入れ替わるので、まず記号を見分けてください。

FIG.1　同じデータでも「読み方」が違うと化ける
出力する側
UTF-8で「文字化け」
受け取る側
Shift_JISとして解釈
譁�蟄怜喧縺�
＝文字コードのずれ
直すのは受け取る側。ターミナルをUTF-8にそろえると解消する

「□」（豆腐）が並ぶのはフォントに日本語が入っていない

白い四角や下駄記号だけが等間隔で並ぶ状態は、文字コードのずれではありません。文字自体は正しく届いているのに、表示に使っているフォントがその文字の形（グリフ）を持っていないため、代替の四角で描かれています。俗に豆腐と呼ばれる症状です。

ここでコードページを切り替えても何も変わりません。直し方はフォントの変更です。ターミナルやエディタの表示フォントを、日本語グリフを含む等幅フォントに差し替えてください。

文字は読めるのに枠線だけずれるのはなぜ？

罫線や進捗バーの位置だけがずれる場合は、文字幅の解釈が食い違っています。全角と半角のどちらとも取れる「あいまい幅（East Asian Ambiguous）」の文字を、ツール側は2桁分、ターミナル側は1桁分として数えているため、描画位置が1文字ずつずれていきます。

Claude CodeのようにTUI（文字で枠を描く画面）を使うツールで目立ちます。iTerm2には「Treat ambiguous-width characters as double width」という項目があり、ここを合わせると枠がそろいます。文字化けとは別系統の症状なので、コードページを触っても解決しません。

02症状から原因を突き止める｜ターミナル文字化けの診断表

編集部が公式ドキュメントで確認した内容と、実際に扱った範囲を整理しました。画面に出ている見た目を左端の列から探し、右へ読み進めてください。原因が決まってから設定を触ると、環境に合わない設定を重ねて不安定になる事態を避けられます。

いま画面に出ている症状 起きていること 直し方 確認・設定する場所
日本語が「譁�蟄怜喧」のような漢字の羅列になる UTF-8の出力をShift_JIS（CP932）として読んでいる 読み取る側のコードページをUTF-8にする chcp 65001／[Console]::OutputEncoding
日本語が「�」（置換文字）に置き換わる 読み取る側はUTF-8として解釈しているが、届いたバイト列がUTF-8ではない 書き出す側の出力をUTF-8に固定する PYTHONUTF8=1／LANG
日本語が「?」に置き換わる 書き出す側がCP932などで、その文字を表現できずに代用している 書き出す側のエンコードをUTF-8に変える [Console]::OutputEncoding／Out-File -Encoding utf8
日本語が全部「□」になる フォントに日本語のグリフが無い 日本語等幅フォントを入れて指定する terminal.integrated.fontFamily
記号やアイコンだけ「□」になる フォントにその記号のグリフが無い 記号を含むフォントに変更する ターミナルのフォント設定
文字は読めるが枠線・カーソル位置がずれる あいまい幅の文字を1桁と2桁で数え違えている ターミナル側の文字幅設定を合わせる iTerm2のambiguous-width設定
画面は正常だがファイルに書き出すと化ける 書き出し時のエンコードが既定のまま違っている 出力エンコードを明示する Out-File -Encoding utf8
特定のファイルを開いた時だけ本文が化ける ファイル自体がShift_JISやEUC-JPで保存されている エンコードを指定して開き直す VSCodeのステータスバー右下
対話中は正常なのに自動実行だけ化ける cronやタスクスケジューラにLANGが渡っていない スクリプト先頭で環境変数を明示する export LANG=ja_JP.UTF-8
Windows Updateのあとから急に化け出した 既定のターミナルアプリやシステムロケールが変わった 既定のターミナルとコードページを見直す 設定＞システム＞開発者向け

03いまの文字コードはどうやって確認する？

Windowsはchcp、macOS・Linux・WSLはlocaleで一発で分かります。表示された値がUTF-8を指していなければ、それが化けている原因です。

Windowsはchcpで確認する

コマンドプロンプトかPowerShellでchcpと打つと、現在のコードページ番号が返ります。932ならShift_JIS、65001ならUTF-8です。932のまま日本語が化けているなら、原因はほぼ確定します。

chcp
# 「現在のコード ページ: 932」→ Shift_JIS。これが化けの原因
# 「現在のコード ページ: 65001」→ UTF-8。ここが正常ならフォント側を疑う

macOS・Linux・WSLはlocaleで確認する

ターミナルでlocaleまたはecho $LANGを実行し、ja_JP.UTF-8やC.UTF-8のようにUTF-8が含まれているかを見ます。LANG=のあとが空だったり、POSIXやCだけだったりする場合は未設定です。SSH接続先や開発コンテナの中では、この状態が起こりがちです。

locale
# LANG=ja_JP.UTF-8 なら正常
# LANG= や LANG=C なら未設定。ここを直す

echo $LANG
FIG.2　見た目で原因が3つに分かれる
A

「譁�蟄怜喧」「�」
＝文字コードのずれ
→ コードページ・LANG

B

「□□□□」
＝フォントに日本語が無い
→ 表示フォントの変更

C

枠線・位置だけずれる
＝文字幅の解釈違い
→ あいまい幅の設定

A・B・Cで直し方が違う。まずどれかを決めてから設定を触る

04Windowsのターミナル文字化けを直す（PowerShell・コマンドプロンプト）

Windowsは文字化けが最も起きやすい環境です。既定のコードページが932である以上、UTF-8を出すツールとは必ずぶつかります。PowerShellとコマンドプロンプトで打つものが違うため、分けて押さえます。

PowerShellの文字化けを直す

PowerShellでは、コンソールの出力エンコーディングをUTF-8に切り替えます。1行実行してからツールを起動し直すと、その場で読めるようになります。

# 外部コマンドの出力をUTF-8として読む（BOMなしを明示）
[Console]::OutputEncoding = [Text.UTF8Encoding]::new($false)

# 外部コマンドへ渡す側もそろえる（こちらもBOMなし）
$OutputEncoding = [Text.UTF8Encoding]::new($false)

ここで[System.Text.Encoding]のUTF8プロパティをそのまま代入している解説をよく見かけますが、これは避けてください。Microsoftの.NETドキュメントは、このプロパティが「Unicodeのバイトオーダーマーク（BOM）を付けるUTF8Encodingオブジェクトを返す」と明記しています。BOMなしにするにはUTF8Encodingのコンストラクタを呼ぶ、とも書かれています。上のコードが[Text.UTF8Encoding]::new($false)になっているのはこのためです。

BOMが付くと何が困るのかは、$OutputEncodingの役割から分かります。PowerShellの公式ドキュメント（about_Character_Encoding）によれば、この変数は「PowerShellが外部プログラムと通信するときのエンコーディングに影響する」ものです。BOM付きにすると、外部コマンドへ渡すデータの先頭に毎回が紛れ込み、受け取った側が引数やJSONを読み違えます。文字化けを直したつもりが、別の壊れ方を仕込む結果になるわけです。

役割の違いも押さえておくと迷いません。[Console]::OutputEncodingは外部コマンドから受け取った文字をどう解釈するか、$OutputEncodingは外部プログラムへ渡すデータをどう書き出すかを決めます。片方だけ設定して直らない場合は、両方そろえてください。Pythonを経由するツールで崩れるなら、環境変数PYTHONUTF8=1を足すとPython側の入出力もUTF-8に固定できます。

コマンドプロンプトの文字化けを直す

コマンドプロンプトはchcp 65001でコードページをUTF-8へ切り替えます。chcpはコードページを表示・変更するコマンドで、65001がUTF-8を指します。ただし切り替えはそのウィンドウ限りです。

chcp 65001

開き直すと戻ってしまうのはなぜ？

コードページの切り替えがセッション限りの設定だからです。ウィンドウを閉じると既定の932に戻るため、永続化の書き場所を決める必要があります。PowerShellは$PROFILE、コマンドプロンプトはレジストリのAutorunに登録するのが定番です。

# PowerShell: プロファイルを開いて上の2行（BOMなし指定）を書き足す
notepad $PROFILE

# コマンドプロンプト: 起動のたびにchcpを走らせる
reg add "HKCU\Software\Microsoft\Command Processor" /v Autorun /t REG_SZ /d "chcp 65001>nul"

Windows Terminalを使っているなら、プロファイルのcommandlineにcmd.exe /k chcp 65001のように書いておく手もあります。どの層に書いたかを忘れると原因調査が長引くので、書き場所は1箇所に決めておくと迷いません。

システム全体をUTF-8にする（システムロケールの変更）

タスクバーの検索からintl.cplを実行すると「地域」の設定が開きます。「管理」タブの「システム ロケールの変更」を押し、「ベータ: ワールドワイド言語サポートで Unicode UTF-8 を使用します」にチェックを入れて再起動すると、コードページの既定が65001になります。個別のターミナルを1つずつ触らずに済むのが利点で、化けが複数のアプリで同時に起きているなら候補です。

システムロケールを変える前に確認すること

この項目にはMicrosoft自身が「ベータ」と明記しています。Shift_JIS前提で作られた古い業務アプリが逆に化ける可能性があるため、業務端末で入れるなら戻し方（同じ画面でチェックを外して再起動）を先に確認しておくのが安全です。まず1台で試し、業務アプリを一通り開いて表示が崩れないかを見てから広げてください。

Windows Updateのあとから化け始めた場合はどこを見る？

更新そのものが文字を壊すわけではなく、更新をきっかけに設定の既定値が入れ替わったと考えると当たりが早くなります。見る場所は次の3つです。

① 既定のターミナルアプリが切り替わっていないか

「設定＞システム＞開発者向け＞ターミナル」で、既定のターミナルアプリを確認します。コマンドプロンプトからWindows Terminalへ切り替わっていると、化けていなかった画面が別プロファイルで開くため、同じ操作なのに突然崩れて見えます。

② chcpの値が戻っていないか

chcpを実行して932に戻っていないかを見ます。システムロケールのUTF-8設定や、レジストリのAutorunに書いたchcp 65001が外れていると、この値が既定へ巻き戻ります。

③ フォント指定が反映されているか

□が並んでいるなら、プロファイルのフォント指定が反映されていない状態です。Windows Terminalのsettings.jsonでfont.faceに指定したフォントが、更新後の環境に存在しているかを確かめてください。

05VSCodeの文字化けを直す（ターミナル・エディタ・フォント）

VSCodeの文字化けは、ターミナル・ファイル・実行結果のどこで起きているかで設定箇所が変わります。統合ターミナルは裏で動いているシェルの設定を引き継ぐため、シェル側とVSCode側の両方を見るのが近道です。

統合ターミナルをUTF-8で開く（settings.jsonの書き方）

Windowsで統合ターミナルだけ化ける場合は、プロファイル定義にchcpを仕込んでおくと、開くたびにUTF-8で始まります。Ctrl+Shift+Pから「基本設定: ユーザー設定を開く (JSON)」を選ぶと、すでに{と}で囲まれた設定が開きます。次のキーは、その中身の末尾にカンマ区切りで足してください。いちばん外側の{と}を二重に貼るとJSONとして壊れます。

"terminal.integrated.profiles.windows": {
  "コマンド プロンプト (UTF-8)": {
    "path": "C:\\Windows\\System32\\cmd.exe",
    "args": ["/K", "chcp", "65001"]
  },
  "PowerShell": {
    "source": "PowerShell",
    "args": ["-NoExit", "-Command", "[Console]::OutputEncoding=[Text.UTF8Encoding]::new($false)"]
  }
},
"terminal.integrated.defaultProfile.windows": "コマンド プロンプト (UTF-8)"

末尾のキーが設定全体の最後になるなら、そのうしろにカンマは付けません。保存したらターミナルを一度閉じて開き直します。既存のターミナルには反映されないので、直っていないと判断する前に開き直してください。

ファイルを開いた時点で本文が化けている場合

エディタ側に表示された日本語が化けているなら、ファイルがShift_JISやEUC-JPで保存されています。ウィンドウ右下のステータスバーに現在のエンコード（UTF-8など）が出ているので、そこをクリックして「エンコード付きで再度開く」を選び、Japanese (Shift JIS)を指定すると正しく読めます。

既存ファイルの文字コードが混在している案件では、"files.autoGuessEncoding": trueを入れておくと、開いた時点でVSCodeが推定してくれます。推定なので万能ではありませんが、毎回手で指定する手間はかなり減ります。

保存する文字コードを変える

新規ファイルの既定はfiles.encodingで決まります。ワークスペース単位でも指定できるため、案件ごとに文字コードが違うなら.vscode/settings.jsonに書くのが確実です。既存ファイルをUTF-8へ移すときは、ステータスバーから「エンコード付きで保存」を選びます。次の2つのキーも、既存の設定の末尾にカンマ区切りで足す形になります。

"files.encoding": "utf8",
"files.autoGuessEncoding": true

デバッグコンソールや実行結果だけ化ける場合

ターミナルは正常なのに実行結果だけ崩れるなら、化けているのは言語処理系の側です。VSCodeの設定ではなく、コンパイラや実行環境に文字コードを渡して直します。使っている言語ごとに指定する場所が違うため、該当するものを見てください。

Java

コンパイルと実行の両方で指定が必要です。コンパイル時はjavac -encoding UTF-8でソースの文字コードを渡し、実行時はjava -Dfile.encoding=UTF-8を付けます。片方だけだと、コンパイルは通るのに出力だけ崩れる状態になります。

C言語

gccでビルドするなら-fexec-charset=UTF-8を付けます。これは実行ファイルの中に埋め込まれる文字列の文字コードを指定するオプションで、ソースの文字コードを指定する-finput-charsetとは別物です。

Python

環境変数にPYTHONUTF8=1を置くのがいちばん手早い方法です。標準入出力だけを狙って変えたいならPYTHONIOENCODING=utf-8を使います。どちらもVSCodeのlaunch.jsonのenvに書いておくと、デバッグ実行のたびに反映されます。

launch.jsonの設定

言語側を触らずに逃がす手もあります。launch.jsonで"console": "integratedTerminal"にすると、出力先がデバッグコンソールからUTF-8化済みの統合ターミナルへ移り、そちらの設定に乗ります。言語ごとの指定を入れるまでの、つなぎの手段です。

VSCodeのフォントはどこで変える？エディタとターミナルで別々です

エディタ本文はeditor.fontFamily、統合ターミナルはterminal.integrated.fontFamilyで変えます。この2つは独立した設定項目で、片方だけ変えて「変わらない」と感じるケースの多くは、変えた場所が違うだけです。

"editor.fontFamily": "'HackGen Console NF', 'BIZ UDGothic', Consolas, monospace",
"editor.fontSize": 14,
"terminal.integrated.fontFamily": "'HackGen Console NF', 'BIZ UDGothic', Consolas, monospace",
"terminal.integrated.fontSize": 13

この4つのキーも、既存の設定の末尾にカンマ区切りで足します。VSCodeの公式ドキュメントは、この値をCSSのfont-familyと同じ書式の文字列として扱うと説明し、例として"'Fira Code', monospace"を挙げています。空白を含むフォント名はシングルクォートで囲ってください。囲まずに書くと、名前の途中で区切られて別のフォントとして探されます。

フォント名はカンマ区切りで複数書け、左から順に使えるものが選ばれる仕組みです。先頭に日本語グリフを含むフォントを置き、末尾にmonospaceを残しておくと、環境が変わっても最低限は表示されます。GUIから変えたい場合は、設定画面の検索窓にfont familyと入力すると両方の項目が並びます。

日本語等幅フォントを入れる

ここで注意したいのは、名前を書けばそのフォントが使われるわけではない点です。指定したフォントが端末に入っていなければ、VSCodeは黙って次の候補へ進みます。□が並んだままなら、まずフォント自体を入れてください。

上の例に出てくるHackGen Console NFは、GitHubで配布されている日本語プログラミングフォント「白源（HackGen）」です。標準では入っていないので、配布元のリリースページからダウンロードします。BIZ UDGothicはWindowsに標準搭載されているUDフォントで、macOSやLinuxには入っていません。これらの環境ではGoogle Fontsから入手できます。

環境別に選ぶなら、次のあたりが無難です。WindowsはBIZ UDGothicかMS Gothicが最初から使えます。macOSはヒラギノが標準で入っているため□になること自体が少なく、等幅で日本語もそろえたいときに白源や「Cica」を追加します。Linuxやコンテナでは、日本語フォント自体が入っていない場合が多いので、fonts-noto-cjkのようなパッケージを先に入れてください。

インストール手順は、ダウンロードした.ttfや.otfを、Windowsなら右クリックから「インストール」、macOSならFont Bookで追加するだけです。ただし入れた直後は設定画面の候補にも出てきません。VSCodeとターミナルアプリを再起動してから、あらためて設定を開いてください。

06macOS・Linux・WSLの文字化けを直す

Unix系はロケール（LANG）が主役です。既定でUTF-8になっている環境が多い一方、SSH接続先やコンテナの中では未設定のまま化けます。

macOSのターミナルはテキストエンコーディングを確認する

標準のターミナル.appは、設定＞プロファイル＞詳細にある「テキストエンコーディング」でUnicode（UTF-8）が選ばれているかを見ます。iTerm2はプロファイルの設定にCharacter Encodingの項目があり、ここもUTF-8にそろえます。ここが合っていて□が並ぶなら、原因はフォント側です。

LANGとLC_ALLを設定する

ロケールが空なら、シェルの設定ファイルに1行足すだけで解決します。zshが標準のmacOSは~/.zshrc、bashの環境は~/.bashrcが書き場所です。

echo 'export LANG=ja_JP.UTF-8' >> ~/.zshrc
source ~/.zshrc

# それでも残る場合は LC_ALL でまとめて上書きする
echo 'export LC_ALL=ja_JP.UTF-8' >> ~/.zshrc

LC_ALLはロケール関連の項目をすべて上書きする強い設定です。常用すると個別の設定が上書きされるため、まずLANGだけで試し、直らないときの追加策として使うと副作用を抑えられます。

WSLは日本語ロケールの生成から始める

WSLは、そもそも日本語ロケールが生成されていないとLANGを書いても反映されません。生成、既定値の設定、現在のシェルへの反映の順に進めます。

sudo apt-get update && sudo apt-get install -y locales
sudo locale-gen ja_JP.UTF-8
sudo update-locale LANG=ja_JP.UTF-8
export LANG=ja_JP.UTF-8

WSL特有のつまずきは、Windows側のターミナルはUTF-8なのにWSL内が未設定という食い違いです。localeでja_JP.UTF-8が返るまでWSL側を直します。WSLそのものが不安定でツールが入らない段階なら、Claude CodeがWSLで入らない原因と対処を先に確認してください。

07Claude CodeなどCLIツールで文字化けする時の追加設定

対話型のCLIツールは、画面全体を文字で描き直す作りになっているため、文字コードだけでなく文字幅やフォントの影響を受けます。ここまでの設定で直らない場合の追加分を挙げます。

Claude Codeの日本語が化ける時に最初にやること

Claude CodeはUTF-8で日本語を出力します。したがって直し方は前章までと同じで、WindowsならコードページとPowerShellのエンコーディング、macOS・Linux・WSLならLANGをそろえるだけです。設定後はターミナルを開き直してから起動してください。なお、文字化けと「英語で返ってくる」問題は別物です。応答の言語を固定したい場合はClaude Codeを日本語で使う設定にまとめています。

コピペした日本語だけ化けるのはなぜ？

貼り付け経路のどこかでUTF-8以外に変換されているためです。リモート接続を挟んでいる場合は接続先のロケール、Windows Terminalなら貼り付け元のアプリの文字コードが疑わしい箇所になります。切り分けとして、いったんテキストエディタへ貼ってUTF-8で保存し、そのファイルをツールに読ませると、崩れているのが貼り付け経路なのか表示側なのかがはっきりします。

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

08設定したのに直らない時に見る4箇所

UTF-8にそろえたはずなのに化けが残るなら、画面の手前ではなく、その先で崩れている可能性があります。データが通る順に4箇所を見ていくと、原因がどこにあるかを絞り込めます。

FIG.3　直らない時は「通り道」を順にたどる
01

画面の表示
コードページ・LANG

02

ファイルへの出力
BOM・UTF-16

03

受け渡すデータ
CSV・git・ファイル名

04

自動実行
cron・タスクスケジューラ

対話中は正常で自動実行だけ化けるなら、原因はほぼ04にある

ファイルに書き出すと化ける（PowerShellのBOMとUTF-16）

Windows PowerShell 5.1は、>やOut-Fileで書き出すときの既定がUTF-16です。画面では読めていたのに、保存したログを開くと崩れるのはこれが理由です。PowerShell 7ではBOM無しのUTF-8が既定になったため、まずバージョンを確認してください。5.1のまま使うなら、エンコードを明示するのが確実です。

$PSVersionTable.PSVersion

# 5.1でファイル出力の既定をUTF-8にそろえる
$PSDefaultParameterValues['*:Encoding'] = 'utf8'

# 個別に指定する場合
"日本語のログ" | Out-File -Encoding utf8 log.txt

5.1のutf8はBOM付きで書き出されます。BOMを嫌うツールへ渡すなら、PowerShell 7のutf8NoBOMを使うか、変換を1手挟んでください。

gitのログでファイル名が数字の羅列になる

日本語のファイル名が"\346\227\245..."のように表示されるのは、gitが非ASCII文字をエスケープして出しているためです。設定を1つ変えるとそのまま日本語で表示されます。

git config --global core.quotepath false

ExcelのCSVを読ませると化ける

Excelから通常の「CSV（コンマ区切り）」で保存したファイルはShift_JIS（CP932）です。UTF-8前提のスクリプトに渡すと、日本語の列だけが崩れます。Excelの保存形式で「CSV UTF-8（コンマ区切り）」を選べば、最初からUTF-8です。既存ファイルはコマンドで変換するほうが速い場面もあります。

iconv -f CP932 -t UTF-8 input.csv > output.csv

cronや定期実行の時だけ化ける

対話用のシェルと違い、cronやlaunchd、タスクスケジューラはLANGが空のまま起動します。~/.zshrcに書いた設定は読み込まれないため、実行スクリプトの先頭で環境変数を明示するのが対処です。自動化を組んでいる案件では、ここが最後まで残る化けの原因になりがちです。

#!/bin/bash
export LANG=ja_JP.UTF-8
export LC_ALL=ja_JP.UTF-8
export PYTHONUTF8=1

# この下で実行したい処理を呼び出す

定期実行そのものの組み方はClaude Codeの定期実行をcronで自動化する手順で解説しています。

09再発を防ぐ｜設定の書き場所一覧

その場で打ったコマンドはウィンドウを閉じると消えます。再発を止めるには、環境ごとに決まった場所へ書いておくことが必要です。環境別の書き場所を一覧にしました。

環境 書き場所 書く内容
PowerShell 5.1／7 $PROFILE [Console]::OutputEncoding = [Text.UTF8Encoding]::new($false)
コマンドプロンプト レジストリのAutorun chcp 65001>nul
Windows Terminal settings.jsonのプロファイル commandlineとfont.face
VSCode統合ターミナル ユーザー設定のsettings.json terminal.integrated.profiles.windows
macOS（zsh） ~/.zshrc export LANG=ja_JP.UTF-8
Linux・WSL（bash） ~/.bashrc＋update-locale export LANG=ja_JP.UTF-8
Docker Dockerfile ENV LANG=ja_JP.UTF-8
cron・launchd 実行スクリプトの先頭 export LANG／export PYTHONUTF8=1

チームで環境をそろえるなら、書き場所と設定値をリポジトリのセットアップ手順に載せておくと、参加者ごとの設定漏れによる化けが減ります。日常のコマンドを共通化しておく考え方は非エンジニアが使うClaude Codeスラッシュコマンド12選でも触れています。

10ターミナルの文字化けに関するよくある質問

ターミナルの文字化けを一番早く直す方法はどれですか？

Windowsならchcp 65001、macOS・Linux・WSLならexport LANG=ja_JP.UTF-8です。どちらもその場で反映されるため、まず実行して直るかどうかを見てください。直ったなら原因は文字コードで確定なので、あとは永続化するだけです。

chcp 65001を実行しても直らないのはなぜですか？

症状が文字コードのずれではない可能性があります。□が並んでいるならフォント、枠線だけずれているなら文字幅の問題で、どちらもコードページとは無関係です。PowerShellの場合は[Console]::OutputEncodingも併せて設定すると解決することがあります。

VSCodeのターミナルだけ文字化けするのはなぜですか？

統合ターミナルが独自のプロファイルでシェルを起動しているためです。OS側のターミナルをUTF-8にしても、VSCodeのプロファイル定義には反映されません。terminal.integrated.profiles.windowsにchcpを仕込み、ターミナルを開き直してください。

「□」が並ぶのも文字化けですか？

見た目は文字化けですが、原因は別です。□はフォントに日本語のグリフが無いときに出る代替表示で、文字データ自体は壊れていません。表示フォントを日本語対応のものに変えると直ります。

Windowsのシステムロケールを「Unicode UTF-8を使用」にしても大丈夫ですか？

アプリによっては逆に化けます。Microsoftがこの項目に「ベータ」と表示している通り、Shift_JIS前提の古いアプリで表示が崩れる場合があります。業務端末では、戻し方を確認したうえで試すのが安全です。

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

cronやタスクスケジューラではLANGが空のまま起動するのが原因です。~/.zshrcや~/.bashrcの設定は自動実行には引き継がれません。実行スクリプトの先頭にexport LANG=ja_JP.UTF-8を書いて解決します。

11まとめ｜ターミナルの文字化けは症状の見分けで9割決まる

ターミナルの文字化けを直す手順は、症状を見分けてから設定を触る、この順番に尽きます。「�」や漢字の羅列なら文字コード、「□」ならフォント、枠線のずれなら文字幅で、打ち手はそれぞれ別です。Windowsはchcp 65001と[Console]::OutputEncoding、macOS・Linux・WSLはLANG=ja_JP.UTF-8を起点にすれば迷いません。

次の一歩として、いま出ている症状を診断表に当てはめ、該当する設定を1つだけ入れてターミナルを開き直してください。1つずつ入れて確かめると、どの設定で直ったかが分かり、次に同じ症状が出たときの復旧が速くなります。自動実行まで組んでいる場合は、スクリプト先頭のexport LANGを先に入れておくと安心です。作業の進め方そのものを安全にしたい場合は、Claude CodeのPlan Modeの使い方も参考になります。

12出典