Antigravity 内蔵ターミナルで日本語が文字化けするときの原因と対処

Antigravity の内蔵ターミナルで git log --oneline を叩いたら、コミットメッセージが「譁?ュ怜喧縺代＠縺ｾ縺励◆」のような呪文に化けていた。npm run start のエラーメッセージが読めない。アプリのリソースフォルダにある「アイコン.png」を ls したら全部「?」になっている。私自身、Windows と macOS を行き来しながら個人開発をしていて、新しい Mac に Antigravity を入れ替えたタイミングや、Git Bash を使い始めた直後にこの症状で半日溶かしたことが何度かあります。

ターミナルの文字化けは「現象は派手だけれど原因は地味」というタイプの問題です。多くの場合、シェル本体の出力エンコーディングと、ターミナル側が読み取るエンコーディングが一致していないだけで、設定を 1〜2 行直せば一瞬で復旧します。ここでは Windows・macOS・WSL の典型パターンを順に、私が実際に踏んできた地雷も含めて整理していきます。Dolice Labs では Antigravity Lab・Claude Lab を含む 4 サイトを並行運用していて、日本語の記事ファイル名やコミットメッセージが日常的に飛び交うため、最初にここを潰しておくと後の作業がぐっと軽くなります。

まずは「どこで化けているか」を切り分ける

文字化けが起きたとき、最初にやるべきは「Antigravity が悪いのか、シェルが悪いのか、コマンドの出力自体が悪いのか」を切り分けることです。順番に確認してください。

最初のチェックは、Antigravity を経由しない素のターミナルで同じコマンドを叩いてみることです。macOS なら Terminal.app、Windows なら Windows Terminal や cmd.exe を直接起動して、同じ git log を実行します。ここで化けないなら Antigravity 側の設定、ここでも化けるならシェルまたは出力元の問題です。

次に echo "テスト" のように、シェル自体が日本語を扱えるかを確認します。echo で化ける場合はターミナルのフォントまたはエンコーディング設定の問題が濃厚で、echo は通るのに git log で化けるなら、コミットメッセージ側のエンコーディング設定（あるいは Git の core.quotePath）が原因です。

最後に、ターミナルに表示中のテキストを | od -c や Format-Hex に流して、生バイト列を覗いてみます。E3 81 82 のような 3 バイト連続なら UTF-8 で出力されており、ターミナル側の解釈設定が間違っているだけなので復旧は容易です。

Windows での文字化け：99% は CP932 と UTF-8 のすれ違い

Windows で発生する文字化けのほぼ全ては、コマンドプロンプトが既定で CP932（Shift_JIS の Microsoft 拡張）を使っているのに、Node.js や Python、Git for Windows が UTF-8 で出力している、というすれ違いから来ています。

Antigravity の内蔵ターミナルが PowerShell を呼んでいる場合、まず chcp を実行してコードページを確認します。932 と返ってきたら CP932 モードです。一時的に UTF-8 へ切り替えるなら chcp 65001 を叩けば即座に効きますが、新しいターミナルを開くと元に戻ってしまうので、恒久対応は PowerShell プロファイルに次の 1 行を入れます。

# $PROFILE が存在しなければ `New-Item -Path $PROFILE -ItemType File -Force`
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8
chcp 65001 | Out-Null

Antigravity の Settings → Terminal → Integrated: Default Profile を PowerShell に固定し、terminal.integrated.profiles.windows の args に -NoLogo を入れておくと毎回プロファイルが読み込まれます。

Git Bash を使っているなら ~/.bashrc または ~/.bash_profile に次を追記します。LANG と LC_ALL の両方を指定するのが鉄則で、片方だけだと man や less だけ化ける、というよく分からない症状が残ります。

export LANG=ja_JP.UTF-8
export LC_ALL=ja_JP.UTF-8
export LESSCHARSET=utf-8

Git 自体にも別の罠があります。git status で日本語ファイル名が "\343\201\202..." のような 8 進エスケープで表示される場合、これは文字化けではなく Git の出力モードです。git config --global core.quotePath false を一度だけ実行してください。これだけで「素材/アイコン.png」がそのまま表示されるようになります。

macOS での文字化け：意外と多い「ロケール未設定」と SSH 越しの落とし穴

macOS は UTF-8 が標準なので「Mac で文字化けすることはない」と思われがちですが、私自身、新しい M3 MacBook Pro をクリーンインストールした直後に SSH で社内サーバーに入ったら、リモート側で LANG: not set が出て日本語が全部 ? になった経験があります。

ローカルで locale を実行して LANG=ja_JP.UTF-8 か LANG=en_US.UTF-8 になっていれば問題なし。LANG= のように空になっているなら ~/.zshrc に次の 1 行を追記します。

export LANG=ja_JP.UTF-8

SSH 越しに化ける場合は、ローカルの zsh が LC_* をリモートに送りつけているのに、リモート側にそのロケールが入っていない、というのが定番です。/etc/ssh/ssh_config の SendEnv LANG LC_* 行をコメントアウトするか、リモート側で sudo locale-gen ja_JP.UTF-8 するかのどちらかで解決します。私はリモートが Ubuntu サーバーなら後者、社内の混在環境では前者を選んでいます。

Antigravity 側の設定では、Settings → Terminal → Integrated: Inherit Env を true のままにしておきます。これを false にすると .zshrc の export 内容が反映されず、別ターミナルでは化けないのに Antigravity 内だけで化ける、という追跡しづらい症状になります。

WSL2 環境での落とし穴：Windows と Linux のロケールが二重に絡む

WSL2 を使っているケースでは、Windows 側のターミナル設定と Linux 側のロケール設定が二重に絡むため、片方だけ直しても直りません。私は Rork Lab の記事を書く際に WSL2 上で npm を動かすことが多いので、ここで何度かハマっています。

まず WSL 側で locale -a | grep ja を実行し、ja_JP.utf8 が表示されるか確認します。表示されなければ次を実行します。

sudo locale-gen ja_JP.UTF-8
sudo update-locale LANG=ja_JP.UTF-8

その上で ~/.bashrc または ~/.zshrc に export LANG=ja_JP.UTF-8 を追記。シェルを開き直してから echo $LANG で反映を確認します。

Windows 側で Antigravity の Integrated Terminal が wsl.exe を呼ぶ場合、Windows 側のコードページが 932 のままだと、Linux 側が UTF-8 で出した文字列を Windows 側が誤解釈してしまいます。対処は前述の chcp 65001 を PowerShell プロファイルに入れる方法と同じです。

それでも直らないときの最終チェック

ここまでやって直らない場合、私が必ず確認している 3 つの最終チェックポイントを共有します。

第一に、ターミナルのフォント設定です。Antigravity の Settings → Terminal → Integrated: Font Family に CJK グリフを含まないフォント（例: Cascadia Code を CJK 補完なしで指定）を使っていると、エンコーディングは正しいのにグリフだけ豆腐になります。HackGen Console NF や Cica、MesloLGS NF の日本語対応版に変えれば直ります。

第二に、ファイル自体のエンコーディングです。file -i logs/error.log で charset=shift_jis と出るなら、cat ではどう転んでも化けます。iconv -f shift_jis -t utf-8 logs/error.log | less で一時的に読むか、nkf --overwrite -w logs/error.log で UTF-8 に変換してしまうのが手っ取り早いです。私は Android アプリ事業を 2014 年から続けていますが、古い Eclipse 時代のログファイルが Shift_JIS で混じっていたりして、たまにこの罠を踏みます。

第三に、Antigravity 自体の再起動と拡張機能の無効化です。Settings Sync で他マシンから入った Terminal 拡張が LANG を上書きしているケースがあり、Help → Toggle Developer Tools の Console で process.env.LANG を確認してみると犯人が見つかることがあります。

化けないターミナル環境を作っておくチェックリスト

最後に、新しいマシンに Antigravity を入れたときに私が必ずやっている初期設定を一覧にしておきます。これを最初にやっておくと、日本語のコミットメッセージや日本語ファイル名が混じったプロジェクトでも、後から「あれ、化けてる」と慌てずに済みます。

シェルプロファイル（.zshrc / .bashrc / $PROFILE）に LANG=ja_JP.UTF-8 と UTF-8 関連の export を集約する
Windows なら PowerShell プロファイルに chcp 65001 と OutputEncoding = UTF8 を入れる
git config --global core.quotePath false を実行する
Antigravity の Font Family を CJK 対応フォントに固定する
Settings Sync を使っているなら、Terminal 設定が他マシンの設定で上書きされていないか確認する

開発が止まる時間が一番もったいないので、新マシンを開封したらこの 5 つだけは先に済ませてしまうのがおすすめです。実装の参考になれば幸いです。