Claude Codeでタブ編集できないエラーの原因と対処法

Claude CodeのEditツールは、タブでインデントされたファイルに対して「Error editing file」を返し、書き換えに失敗することがあります。2025年11月にGitHubへ報告されて以降、既知issueとして議論が続いている問題です。原因はEditツールの完全一致マッチングにあり、CLAUDE.mdへの明記や編集単位を小さくする工夫である程度は避けられます。

「Error editing file」が繰り返し起きる典型パターン

この問題はanthropics/claude-codeのissue #11447で2025年11月11日に報告されました。報告者はPHPコードの編集中に何度もEditツールが失敗し、Claudeが最終的に危ういsedコマンドで代用し始めたと述べています。20件のコメントが2026年2月下旬まで続き、Windows 11・WSL・macOS・Ubuntu/Debian Linuxのいずれでも再現するとの報告が集まっています。影響を受けた言語もPHP・C++・Go・Makefile・TypeScript(React/TSX)と幅広く、タブインデントを使うコードベース全般に関わる問題です。

典型的な流れは次のようなものです。

● Update(service-logs.php)
  ⎿  Error editing file
 
● Bash(sed -n '137,157p' service-logs.php | cat -A)
  ⎿  ^I^I^I^I^I<div class="card-body ...">$
     ^I^I^I^I^I^I<div class="p-4 ...">$
 
● Now I can see the exact whitespace (tabs). Let me update it correctly:
 
● Update(service-logs.php)
  ⎿  Error editing file

Editツールでの失敗が続くと、Claudeはcat -Aで見えないタブ文字を確認しようとしたり、最終的にsed -iでの置換や、ファイル全体をWriteで書き直す方向に切り替えたりします。いずれも本来のEditツールが1回で済ませられるはずの変更を、遠回りして達成する動きです。

なぜタブを含む行だけ一致しないのか

Editツールは書き換え対象の文字列(old_string)を、ファイルの実際の内容と完全一致でマッチングする仕組みです。空白1文字でもずれると置換対象が見つからず、エラーになります。issueに寄せられた報告からは、タブが絡む場面でこのマッチングが崩れやすい理由がいくつか浮かび上がっています。

GlassBeaverは、Claudeに直接原因を尋ねたところ次の説明が返ってきたと自身のコメントで紹介しています。

Read toolは340→のように行番号の後に矢印を表示します。矢印の後に続くタブは実際のファイル内容ですが、この表示形式のせいでタブとスペースを取り違えてしまいました。

つまりRead toolの出力は「行番号 + 矢印 + 本来の内容」という形式です。矢印の直後にあるタブが視覚的に紛らわしく、そこからold_stringを組み立てる際にタブとスペースを混同しやすいという指摘です。mikej96も同様に、Read出力を見て頭の中でタブをスペースに変換しながらEdit用の文字列を作ってしまうというClaudeの自己診断を自身のコメントで紹介しています。GlassBeaverはWindows環境について、これに加えてCRLFとLFの改行コードの違いも重なりやすいと付け加えています。

これらはissueのコメントで共有された観察であり、Anthropicが公式に原因を認めた説明ではありません。断定はできませんが、複数の利用者が独立に近い症状を挙げている点は一致しています。

CLAUDE.mdに明記すると再発が減ったという報告

コメントの中で最も詳しく共有されている対処法は、CLAUDE.mdに専用の指示を書く方法です(pdb0102のコメントより)。要点は「Read toolの矢印より後ろの内容をそのままコピーする」「Editが失敗したらsed・awk・Bashでの代替を試みず、いったん止めて説明する」の2点です。

## Edit Tool - Whitespace Handling
 
Read toolは`→`で行番号と内容の境目を示します。
 
**ルール:** `→`の後に現れる空白をそのままコピーする。
- `→`と実際のコード文字列の間にある空白が、ファイルの中身そのもの
- その空白をEditツールの`old_string`にそのまま使う
- 矢印を数えたり解釈したりせず、`→`の後をそのままコピーする
 
**Editが失敗したら:** 止めて問題を説明する。sed/awk/bashでの代用を試みない。

この指示を追加した利用者は、その後の編集がうまくいくようになったと報告しています。ただしこれは利用者コミュニティが自発的に見つけた回避策であり、Anthropicが公式に推奨している手順ではない点に注意が必要です。CLAUDE.mdに禁則事項を具体的に書き込むこと自体は再利用しやすいパターンで、書き方の型はClaude CodeのCLAUDE.mdを実用に引き上げる10のパターンにまとめています。

セッション中にその場で指示する簡易策

CLAUDE.mdを編集する余裕がない場合、d5veはプロンプトの中に一時的な指示を一文挟むだけの方法を紹介しています。

This file uses tabs for indentation. Use Update() or Write() with tab
support. You are forbidden to use Bash()/sed/awk/etc.

貼った直後の数回は編集が通りやすくなります。ただしd5ve自身、効果は長続きせずセッションが進むと同じ失敗が戻ってくるとも書いています。もう1つの回避策は、置換対象の範囲そのものを小さくすることです。ユニークで短いコード片だけをold_stringに指定すれば、一致させるべき空白の量が減り、失敗する余地も小さくなります。

sedの実行確認を「今後確認しない」で承認する前に

Editが失敗を繰り返す場面では、Claudeがsedコマンドの実行確認を求めてくることがあります。このとき「Yes, and don't ask again for sed commands in <dir>」を選ぶと、公式ドキュメントによればそのルールは.claude/settings.local.jsonに恒久的に保存され、以降そのリポジトリで始めるセッション(サブディレクトリやworktreeを含む)すべてに適用されます。issueのコメントにも、複数行にわたる複雑なsed -iコマンドをそのまま承認してしまう例が挙がっています。

この保存されるルールは、見た目以上に広い範囲をカバーします。公式ドキュメントによれば、確認ダイアログで「don't ask again」を選んだコマンドは接頭辞(prefix)として保存されるため、「このsed -iコマンド1回だけ」のつもりで承認しても、以後はそのリポジトリ全体でsedコマンドの実行を確認なしで許可するルールが残ります。&&やパイプで繋いだ複合コマンドを承認したときは、Claude Codeが各サブコマンドを個別に判定したうえでサブコマンドごとに別々のルールを保存する仕組みも合わせて公式ドキュメントに明記されています。詳しい評価の仕組みはClaude CodeのBash権限ルールは複合コマンドをどう評価するかで扱っています。タブ編集の失敗をきっかけにsedやBashへの委任を広く許可する前に、この仕組みを踏まえておくと想定外の許可が残りにくくなります。

Writeツールで全体を書き換える最終手段とリスク

Editが何度失敗しても解決しない場合、Claudeは最終的にファイル全体をReadしてからWriteで丸ごと書き直す動きに切り替えることがあります。issueのコメント(alphonseb)でも、複雑なタブインデントの箇所でEditを繰り返した末に、この方法へ切り替えた例が報告されています。

自分の使い慣れたエディタで該当ファイルを直接編集し、Claude Codeにはその結果だけを伝える運用も選択肢の1つです。この場合、ディスク上の変更をClaude Code側に確実に拾わせたいなら、ファイルシステムの変化そのものを検知するFileChanged hookが使えます。公式ドキュメントは、Bashコマンドによる書き換えかClaude Codeの外で動く別プロセスによる書き換えかを問わず、誰が書き換えたファイルでも検知したいときはFileChanged hookを使うよう案内しています。詳しい設定方法はFileChanged hookでディスク上のファイル変更を検知するにまとめています。

状況別の対処法早見表

影響を受ける環境と現状

issueに寄せられた報告を見る限り、この問題は特定のOSやモデルに限定されません。プラットフォームはWindows 11・WSL・macOS(darwin 25.2.0を含む)・Ubuntu/Debian Linuxのいずれでも報告があり、使用モデルもデフォルトのSonnetからOpus 4.6まで含まれます。最初の報告時点のClaude Codeバージョンは2.0.37でした。

確認した公式changelogのうち、タブ区切りファイルに対するEditツールの一致精度を修正した項目は見当たりませんでした。issue内でも2026年1月28日にボットが「30日間動きがなければ自動クローズする」と通知していますが、その後も複数の利用者が再現を報告し続けており、issueはクローズされていません。2026年2月25日に投稿された最新コメントでは、ある利用者が「修正されないままなのではないか」という趣旨の感想を残していますが、これは1人の利用者の見立てであり、Anthropicが対応しない方針を明言したものではありません。

まとめ

タブインデントのファイルでEditツールが失敗するのは、2025年11月から報告が続く既知の問題です。原因として、Read toolの行番号表示とタブの視覚的な紛らわしさ、そしてEditツールの完全一致マッチングの組み合わせが指摘されていますが、Anthropicによる公式の原因説明は確認できていません。実務的な対処としては、CLAUDE.mdに具体的な禁則事項を書く、編集対象を小さなユニークな断片に絞る、それでも解決しなければ自分のエディタで直接編集してFileChanged hookで検知させる、という順番で試すのが現実的です。Bashのsedへの逃げ道を安易に許可リスト化しないことも、想定外の権限が残らないようにするうえで役立ちます。