まず、自分のケースかどうかを切り分けるなら、実行中にこの文言で止まるかを見ます。
The model's tool call could not be parsed (retry also failed)
今回の症状クラスタで参照できる issue は、どちらも Claude Code 側で tool call の構造が壊れていたケースでした。#62467 では、claude-opus-4-7 と extended thinking の組み合わせで、tool_use ブロックが parse できずに hard-stop していたと報告されています。#74620 では、Opus 4.8 の tool call で、開始タグが court や call、count、caught、co のような近い文字列に崩れ、harness が tool call と認識できなくなっていました。
この2件から言えるのは、少なくとも報告上は「ユーザー入力が長すぎたから失敗した」「特殊文字が入ったから失敗した」とは限らない、ということです。#62467 では、失敗した turn の output tokens は 164〜1093 で、size 起因ではないと書かれていました。また special chars が原因ではないとも報告されています。つまり、見た目に普通のやり取りでも起きています。
手元で確認できた一次情報は環境情報だけです。今回は実際の再現ログや CLI の出力は提示されていないので、ここから先は断定できません。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-01T08:50:54+09:00
現時点で裏が取れている範囲では、対処法が確立したとは言えません。少なくとも、参照できた issue はどちらも close されていますが、コメントは「inactive for too long」「7 days activity なしで locked」という運用上のクローズで、根本解決の手順が示されたわけではありませんでした。
なので、この記事で無理に「これを変えれば直る」とは書きません。確認できる範囲で言うと、もし同じ文言で止まり、かつ assistant turn 側に parse できる tool_use block が見当たらないなら、#62467 に近い挙動の可能性があります。tool call の開始タグそのものが壊れていそうなら、#74620 の報告に寄っています。どちらにせよ、少なくとも issue 上は Claude Code の tool call 出力側の不整合として扱われています。
再発確認を進めるなら、まずは失敗したセッションのログで、assistant turn に stop_reason="tool_use" が付いているか、そして parse できる tool_use ブロックが実際にあるかを見比べるのが近道です。そこが確認できれば、「model が tool call を出したつもりでも、ハーネスが読めない形になっている」かどうかを絞れます。逆に、その手元ログがなければ、今ある情報だけで原因まで言い切るのは無理です。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-01T08:50:54+09:00