Claude Codeがスマート引用符を壊す問題と回避策

Claude Codeがスマート引用符を書き換えるとは

Claude Codeのスマート引用符書き換え問題とは、EditツールやWriteツールでファイルを編集する際に、正しく入力されたUnicodeの曲線引用符(’“”)やアポストロフィを、ASCIIの直線引用符(' ")へ無断で変換してしまう既知の不具合です。GitHub Issue #1599として2025年6月4日に登録され、いまもクローズされずに残っています。2026年2月18日のv2.1.47でEditツールの一部の症状は修正されましたが、その後の報告を追うと同じ現象が別の形で観測され続けています。

最初の報告は、ユーザーがコード中に I’m という曲線アポストロフィ付きの文字列を書いていたところ、無関係な箇所を編集させただけで I'm に書き換わったというものでした。CLAUDE.mdに逆の指示(正しい引用符を使ってほしい)を書いても、Claudeは自分がルールに従えていないことを認識しながら、修正しようとすると「old_stringとnew_stringが完全に同じです」というエラーを繰り返すだけで直せませんでした。指示が効かないタイプの不具合である点が、この問題を厄介にしています。

なぜ意図した文字が書き換わるのか

最初の報告者は、Claudeモデル自体の判断ミスというより「スタック内の別の処理・フィルタ層で発生している」と推測しています。実際に同じ端末・同じ設定でGemini CLIを使って同じ編集をさせたところ、曲線アポストロフィはそのまま残ったとされ、Claude Code側の処理に原因がある可能性を示す材料になっています。

厄介なのは、Claude自身が正しい文字コードを認識していながら、実際の出力ではそれを再現できないという点です。あるユーザーが「開き引用符と閉じ引用符(いわゆるcurly quote)を使ってHello worldを出力して」と指示したところ、Claudeは「開き引用符はU+201C、閉じ引用符はU+201D」だと正しく説明しながら、実際の出力はASCIIの直線引用符でした。このユーザーが問題を指摘すると、Claude Code自身が「処理パイプラインのどこかでUnicodeのタイポグラフィ文字がASCII相当に正規化されている」「正規化された後の状態しか自分では見えていないので、自分の出力が影響を受けていることに気づけない」という趣旨のコメントを返しています。CLAUDE.mdへの指示が効かないのも同じ構造で、モデルが従うべきルールを認識できても、書き換えが起きる層まで指示が届いていないと考えられます。同様の乖離はモデルが更新されたあとも解消していません。KingSupernova31は、Opus 4.6の時点でも、実際には直線引用符を出力していながら「曲線引用符を使っている」と誤って言い切る挙動が残っていたと報告しています。

IDE拡張の自動編集がどこまで許可されるかでは、protected pathsやVS Code Restricted Modeなど、自動編集に対する複数の防御層が扱われています。スマート引用符の書き換えは、そうした防御層とは別に、編集内容そのものが処理の過程で変質するという種類の問題です。ArtKoKoは、タイポグラフィ的な引用符と、コードの区切り記号として使われる直線引用符を、意味を理解せずに機械的に区別する方法は無いため、フック単体での確実な修正は難しいと分析しています。同じユーザーは、この問題がフランス語やドイツ語のようにタイポグラフィ上の正しい引用符を重視する言語のプロジェクトで、とくに顕著に表面化すると指摘しています。

影響を受けるケースとその実害

もっとも実害が大きいのは、直線引用符が構文上の意味を持つプログラミング言語です。Perlで書かれたコードでは、アポストロフィ付きの文字列がEditツールの書き換えによって構文エラーに変わります。

# 書き換え前(正しく動く)
$text = "Nom d’hôte";  # U+2019のアポストロフィ
 
# Editツール適用後(構文エラー)
$text = "Nom d'hôte";  # U+0027が文字列の区切りとして解釈されてしまう

この報告をしたユーザーは、1つのファイルだけで502行が影響を受けたとしています。Perl以外にも、次のような環境・ケースが報告されています。

英語以外の言語を扱うプロジェクトほど、タイポグラフィ的に正しい引用符やアクセント記号を使う頻度が高くなります。結果として、この不具合による実害も英語以外のコードベース・翻訳ファイルで大きくなりやすいという傾向が、複数の報告から読み取れます。

v2.1.47で直った範囲とまだ残っている範囲

2026年2月18日公開のv2.1.47では、公式changelogに次の修正が記載されています。

Fixed Edit tool silently corrupting Unicode curly quotes (\u201c\u201d \u2018\u2019) by replacing them with straight quotes when making edits (anthropics/claude-code#26141)

これはEditツールが “” ‘’ の4種類の文字を直線引用符へ書き換えてしまう不具合(重複Issueとして登録されていた#26141)を対象にした修正です。Issue #1599のスレッドを見ると、報告自体はこの修正の前後で途切れず続いています。ArtKoKoは2026年3月のコメントで、この現象が#8234・#14355・#15920・#26141・#29786と、少なくとも5件の重複Issueとして個別に登録されてきたと指摘しています。

v2.1.47の修正はEditツール内の特定パターンに絞ったものであり、Issue #1599自体は解決済みとしてクローズされていません。同じバージョンでも、Editツールでの書き換えとモデル出力そのものの正規化は別の現象です。バージョンを上げても、モデル出力側の正規化は残ります。

今すぐ試せる回避策

完全な修正ではありませんが、実務で試されている回避策がいくつか報告されています。

Unicodeエスケープシーケンスを使う方法です。ソースコード中で ’ のようなリテラル文字の代わりに \u2019 のようなエスケープ表記を使うと、Editツールの書き換え対象から外れます。ソースの可読性は下がりますが、構文が壊れる事故を防ぐ手段になります。

Editツールを避けてシェルコマンドで置換する方法もあります。perl -i -pe や sed はバイト列をそのまま扱うので、この正規化を避けられます。

perl -i -pe "s/old/new/g" file.pl

プレースホルダーで一時的に退避する方法もあります。コミュニティが公開しているワークアラウンドの一つは、編集前にスマート引用符を一時的なプレースホルダー文字列へ置換し、Editツールの処理が終わったあとにperlやsedで元の文字へ戻すというものです(Issue #1986で共有されています)。同じユーザーは、この現象を踏まえた恒久対応として、コードの区切り記号として使われている直線引用符と、文字列の中身としての曲線引用符を区別して扱う /curly オプションを提案しています。区切り記号の変換を控えめにする safe モードと、曲線引用符を積極的に使う lazy モードの2種類が想定されているとのことですが、この提案は2026年3月に登録されたもので、Claude Codeの正式な機能にはまだ組み込まれていません。

コミット前にgit diffで確認する方法も、実質的な最後の安全網になります。書き換えは通知なく起きるため、レビューで気づくにはコミット前の差分確認が有効です。Claude Codeのcheckpoint機能はEditツールが加えた変更そのものは記録しますが、その変更が意図した内容かどうかまでは判定しません。差分を目視で見る習慣が、通知されない書き換えに気づく手段として残ります。

逆方向の破損も報告されている

2026年4月には、書き換えの方向が逆になったという報告も出ています。あるユーザーは、これまでの直線化とは逆に、コード内に不要な曲線引用符が混入して構文エラーを起こしたと報告しました。丸一日デバッグに費やしたあとで、このユーザーはClaude自身に「曲線の引用符やアポストロフィを本当に必要とするプログラミング言語はあるか」と確認しています。

このとき、GitHubのコメント欄でClaudeが返した回答を対象ごとに整理すると、次のようになります(Claudeの回答であり、Anthropicが検証した仕様ではありません)。

曲線引用符が正当な使い道を持つのは、画面に表示される文字列リテラルの中身としてだけです。上記の言語でコードの区切り記号として混入した場合は、構文エラーの原因になります。逆方向の書き換えも、直線化と同じくらい実害が大きいことがこのやり取りから読み取れます。

まとめ

Claude Codeのスマート引用符書き換え問題は、2025年6月の登録から1年以上が経ってもなお、Issueとしてクローズされていません。2026年2月のv2.1.47でEditツールの一部の症状(#26141)は修正されましたが、Issue #1599のスレッドではその後もモデル出力の正規化や逆方向の書き換えが報告されています。CLAUDE.mdでの指示は効果がないと報告されているため、タイポグラフィ的に正しい引用符を保ちたいファイルでは、Unicodeエスケープの利用、Editツールを経由しない置換、コミット前のgit diff確認といった対処を組み合わせるのが実務的な選択肢になります。