Claude Code で「tool call could not be parsed」が出て作業が消える時、どの版が自分の環境で安全かを1分で測る

Claude Code を使っていて、編集の途中で突然こう出て止まったことはありませんか。

The model's tool call could not be parsed (retry also failed)

これが出ると、進行中の Edit や Bash がそこで中断し、内部のリトライも失敗して、そのターンが丸ごと消えます。利用枠は消費されているのに、手元には何も残りません。軽い編集をお願いしただけなのに、書きかけのコードもろとも消える。地味ですが、これは「気づいた時には取り返せない」たちの悪い損失です。

この記事は、原因の解説ではありません（原因は基盤側にあって、こちらでは直せません）。代わりに、この事故が自分の環境でどのくらいの頻度で起きているか、どの版なら安全かを、自分のログから1分で測る方法を共有します。送信は一切しない、読み取りだけの自己診断です。

まず、これはあなたのプロンプトのせいではない

「自分の書き方が悪いのかも」「エスケープのしかたを変えれば直るのかも」と思いがちですが、ほぼ違います。

このエラーは、入力が68文字しかない Read（中身は file_path ひとつだけ）でも発生します。引数の大きさや複雑さに関係なく、確率的に当たります。つまり内容の問題ではなく、Claude Code（CLI）が、ストリームで送られてくる tool_use の JSON を組み立てる部分の問題です。だから、プロンプトをいくら直しても根本的には減りません。

でも「どの版が悪いか」は、環境ごとに違う

ここが大事なところです。「特定の版で増えた」という報告は出ています。たとえばある報告では、CLI 2.1.165 で失敗率が以前の約8倍に跳ねた、と計測つきで挙がっています（1.85‰ → 16.4‰）。

ところが、私が自分のログで同じ計測をすると、山に来る版が違いました。私の環境では 2.1.165 はむしろ低く、別の版（2.1.153 や 2.1.168）で高く出ました。

これが意味するのは、「この版に下げれば直る」という万人向けの答えは無いということです。OS、ターミナル、使い方（並列のツール呼び出しの量、拡張思考の有無）で、悪い版は変わります。だから、他人のおすすめの版に盲目的に下げるのではなく、自分のログで自分の最良の版を測るのが、唯一あてになる方法です。

自己診断：自分のログで版別の失敗率を測る

Claude Code は、セッションの記録を ~/.claude/projects/<プロジェクト>/<セッションID>.jsonl に1行1 JSON で残しています。各メッセージには使われた CLI の version が入っているので、版ごとにこのエラーの発生率を集計できます。

次のスクリプトは、そのログを読むだけで、どこにも送信しません。

python3 - <<'PY'
import json, glob, os, collections
tot, fail = collections.Counter(), collections.Counter()
for f in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
    for line in open(f, encoding="utf-8", errors="replace"):
        try:
            o = json.loads(line)
        except Exception:
            continue
        v = o.get("version")
        if not v:
            continue
        tot[v] += 1
        if "malformed and could not be parsed" in line:
            fail[v] += 1

print("version      msgs   fails   per-mille")
for v in sorted(tot):
    if tot[v] < 200:          # サンプルが少ない版は除外
        continue
    rate = fail[v] / tot[v] * 1000
    print(f"{v:10s} {tot[v]:6d} {fail[v]:6d}   {rate:7.2f}")
PY

出力はこんな形になります（これは私の実際のログの一部です）。

version      msgs   fails   per-mille
2.1.140     159162      0      0.00
2.1.153      73842    105      1.42
2.1.159      15317     11      0.72
2.1.162      10973      0      0.00
2.1.165      15379      1      0.07
2.1.168      14796      6      0.41

per-mille（千分率）が、その版での「parse 失敗の起きやすさ」です。私の場合は 2.1.153 が突出して悪く、2.1.162 や 2.1.165 は実質ゼロでした。あなたのログでは、まったく別の版が悪く出るかもしれません。 それでいいのです。大事なのは、自分の環境での当たり版を知ることです。

測った結果をどう使うか

• 失敗率が低い版に固定する。 直近の版のうち、自分のログで per-mille が低かったものに合わせます。

  npm i -g @anthropic-ai/claude-code@2.1.162   # 自分のログで低かった版に置き換える

そして1日ほど使ってから、もう一度上のスクリプトで測り直して確かめます（「測って、固定して、また測る」）。

• 出てしまった時の応急。 ターンは消えますが、その直前までの作業は記録に残っています。慌てて全部やり直す必要はありません。セッションを claude --resume で開き直し、最後の指示をもう一度出せば、それまでの文脈は失われていません。

• 当たりにくくする小ワザ（経験則）。 思考の effort を下げると、当たる頻度が下がる人がいるようです（ツール呼び出しのストリームが短く・少なくなり、組み立てに失敗しにくくなる、という見立て）。確証のある対策ではないので、あくまで補助として。

ついでに：もっと深刻な「セッションが永久に開けなくなる」事故

同じ「静かに作業が消える」系で、これより重いのが、拡張思考を使った長いセッションを resume すると 400 thinking blocks cannot be modified が出て、そのセッションが二度と開けなくなる事故です。何時間ぶんもの会話が、開いた瞬間に永久に閉じ込められます。

これは記録（.jsonl）の保存のしかたに原因があって、壊れたファイルから復旧版を作れます。ブラウザの中だけで（送信せずに）復旧版を作る道具を置いてあります → Claude Code セッション救出ツール

「道具が成功と言ったのに、実は消えていた」を実行の手前で止める

今回のような「気づけない静かな喪失」は、エラーで止まってくれるぶんまだましな方です。本当に怖いのは、道具が「できました」と報告したのに、実際にはファイルが消えていたり、データが静かに失われていたりする型です。

そういう事故を実行の手前で止める無料のフック集を公開しています（rm -rf、強制 push、秘密の漏れ、壊れたデプロイを止める例を多数収録）→ cc-safe-setup

「道具の報告」ではなく「成果物そのもの」を自分で検証する習慣と、実際に起きた事故を体験と防御の手順でまとめた読み物が Claude Code 事故防止ハンドブック です。

---

まとめると、tool call could not be parsed は CLI 側のリグレッションで、あなたのプロンプトのせいではなく、悪い版は環境ごとに違います。だから、他人のおすすめではなく、自分のログで自分の最良の版を測って固定するのが、いちばん確実な対処です。上のスクリプトは読み取りだけなので、安心して回してみてください。