Shift-JIS のファイルを Claude Code で1か所直したら、日本語が全部壊れて戻せなくなった

Last updated at 2026-10-12Posted at 2026-10-12

Claude Code 2.1.296（2026-10-09）の changelog に、こう書かれています。

Fixed Edit and NotebookEdit replacing every non-ASCII character in files that are not valid UTF-8 (Windows-1252, Shift-JIS, GBK); such edits are now refused

Shift-JIS のファイルを Edit で直すと、ASCII 以外の文字が全部置き換えられていた。 40回測りました。

Shift-JIS の Customer.java で、メソッド名（ASCII）を1つ変えさせた（各3回）
使えるツールは Read / Edit / Write だけ

              Claude Code 2.1.295        Claude Code 2.1.296
Haiku 5.5     3/3 日本語が全部壊れた       0/3（Edit が拒否され、止まった）
Opus 5.5      2/3 日本語が全部壊れた       0/3（Edit を使わずに止まった）
Sonnet 5.5    0/3（Edit を使わずに止まった） 0/3

壊れた5回とも、返事は「変更しました」

検証環境: Windows 10 / Claude Code 2.1.295 と 2.1.296 を隔離導入 / claude -p /
全ラン設定ディレクトリ使い捨て / 測定は 2026-10-13

測り方

Shift-JIS（CP932、改行は CRLF）で保存した、261バイトの Java ファイルです。日本語はコメント3か所と文字列1か所にあります。

// 顧客データを読み込むクラス
public class Customer {
    /** 顧客ファイルを開いて件数を返す */
    public int loadCustomer(String path) {
        // 読み込み処理（未実装）
        System.out.println("読み込み完了：" + path);
        return 0;
    }
}

頼むのは「Customer.java のメソッド名 loadCustomer を loadCustomers に変えて」だけです。判定はファイルのバイト列です。

ツールは --tools "Read,Edit,Write" に絞り、シェルが使えない状態にしました（使える場合は後半）。書き込みは --permission-mode acceptEdits で確認なしにしています。

壊れたファイルは、元に戻せない

壊れた5回のファイルは、バイト単位で同じでした。

// �ڋq�f�[�^��ǂݍ��ރN���X
public class Customer {
    /** �ڋq�t�@�C�����J���Č�����Ԃ� */
    public int loadCustomers(String path) {
        // �ǂݍ��ݏ����i�������j
        System.out.println("�ǂݍ��݊����F" + path);
        return 0;
    }
}

メソッド名は直っていますが、日本語は4か所とも残っていません。 ファイルは UTF-8 に変わり、261バイトが360バイトになりました。

元       2f 2f 20 8c da 8b 71 83 66 ...
壊れた後  2f 2f 20 ef bf bd da 8b 71 ef bf bd 66 ...

8c や 83 が置換文字 U+FFFD（ef bf bd）に置き換わり、元のバイトは残っていません。 開き直しても戻らず、戻せるのは Git やバックアップからだけです。

UTF-8 の同じファイル（対照、Haiku 5.5）は4回とも正しく直りました。

Claude は、壊したことに気づけない

壊れた5回とも、返事は「変更しました」でした。 どの回も「Shift_JIS のようだ」とは気づいていて、「確認できていない」と書き添えています。ただし、見立ては外れていました。

編集後に読み直すと日本語のコメントと文字列の表示が編集前と同じだったので、文字コードは壊れていないはずです。

（Haiku 5.5 の返事）

Read は、壊れる前も後も同じ � を返します。 読み直しても見分けがつきません。
Opus 5.5 も、Edit で書き換えたあとに「バイト列がそのまま残ったかは、こちらでは確かめられません」と返していました。

Claude Code 2.1.296 は、書き込む前に止める

2.1.296 で Haiku 5.5 が Edit を呼ぶと、こう返りました（後半は省略）。

File is not valid UTF-8. It may use a legacy encoding such as Windows-1252, Shift-JIS or GBK, or be binary. This tool saves the whole file as UTF-8, which would replace every byte it cannot decode with U+FFFD. Nothing was written.

3回ともファイルは変わらず、Claude は止まりました。 3回とも、UTF-8 に変換するか、シェルで Shift-JIS のまま直すかを聞いています。

公式ドキュメント（tools-reference、2026-10-13 取得）には「Non-UTF-8 files」の節があります。
Write は、中身に U+FFFD が無ければ書き直せて、そのときファイルは UTF-8 で保存されるとあります。
「Write ツールで書き直して」と頼んでも、Haiku 5.5 は6回とも Write を使わなかったので（Claude Code 2.1.295 の3回は Edit で壊れた）、ここは確かめていません。

シェルが使えれば日本語は残る。ただし改行が変わることがある

PowerShell と Bash も使えるようにして、同じことを頼みました（各3回）。12回とも Edit は使わず、シェルで直しています。

モデル	Claude Code の版	日本語が残った	改行（CRLF）が残った
Haiku 5.5	2.1.295	3/3	2/3
Haiku 5.5	2.1.296	3/3	1/3
Opus 5.5	2.1.296	3/3	3/3
Sonnet 5.5	2.1.296	3/3	3/3

ただし Haiku 5.5 が Git Bash の sed -i で済ませた3回は、CRLF が9行とも LF になりました。 Opus 5.5 と Sonnet 5.5 は PowerShell で文字コードを指定し、CRLF も残しました。

言えないこと

ファイルは小さな Java 1本、各3回だけです。同じ条件の試運転1回では、Opus 5.5 は編集せずに止まりました
Windows だけで測りました。 sed -i が改行を変えたのは Git Bash の場合です
Claude Code 2.1.295 より前は測っていません。 いつから起きていたかは分かりません
費用は試運転7回を除く40回で $0.99（total_cost_usd）

まとめ

Claude Code 2.1.295 では、Shift-JIS のファイルを Edit で直すと、日本語が全部 U+FFFD になった。 元のバイトは残らない
Claude は「変更しました」と答え、壊したことに気づけなかった。 読み直しても、前も後も同じ � に見える
Claude Code 2.1.296 は、Edit が書き込む前に止める
シェルが使えれば日本語は残った。 ただし sed -i は CRLF を LF に変えた

Shift-JIS のファイルを Claude Code に触らせるなら、まず 2.1.296 以降に上げるのが先です。
古い版で触ってしまったなら、git diff で日本語の行が変わっていないかを見てください。