Claude Opus4.8で The model’s tool call could not be parsed が頻発している件

PS SLの佐々木です。

Claude Code のOpus4.8を使っているとThe model's tool call could not be parsed が頻発するようになりました

Turn failed — Try sending your message again. The model’s tool call could not be parsed (retry also failed).

「なぜ起きるのか」「どう避けるのか」は、claude-code の GitHub リポジトリに立てられた一連の Issue を読んでみたのでまとめ記事になります。

1 概要
2 根本原因：<invoke> テキストとして吐かれてしまう
3 なぜ「retry also failed」になるのか
4 発生条件
5 回避方法（Issue 記載のもの）
6 現状：未解決
7 参照した一次情報

概要

最初に押さえておきたいのは、これがユーザー側のコードや設定の問題ではなく、Opus 4.8（および一部 4.7）側のリグレッションとして報告されています。

複数の Issue で共通して指摘されているのは、同じワークフローでもモデルを Opus 4.7 や Sonnet 4.6 に切り替えるとエラーが止まるようです。つまりハーネス（クライアント側）の不具合ではなく、特定モデルのリグレッションとして切り分けられています。

根本原因：`<invoke>` テキストとして吐かれてしまう

この問題を最も丁寧に分析しているのが Issue #64658（デスクトップアプリの Code タブからの報告）です。

stop_reason: tool_use のターンにおいて、モデルが構造化された tool_use ブロックではなく、レガシーな <invoke> 形式の XML テキストとして tool call をシリアライズしてしまう。このとき、余計なトークン（court / count のような）が混ざったり、本来必要な antml: プレフィックスが落ちたりすることがあり、結果としてパーサが解釈に失敗する。

これを API レイヤの視点から裏付けているのが Issue #61133 になります。Anthropic API の仕様上、stop_reason: tool_use のレスポンスには必ず tool_use ブロックが含まれていなければならない。ところが Opus 4.8 では、stop_reason: tool_use を返しながら tool_use ブロックが1つも入っていないターンが断続的に発生する、と報告されている。中身のない tool_use ターンがエラーの引き金になっているわけだ。

なぜ「retry also failed」になるのか

エラーメッセージの末尾に付く (retry also failed) も、Issue を読むと理由が報告されています。

Issue #64235 によれば、最初の失敗時にハーネスは「ツールコールが壊れていた、リトライせよ」という旨のメッセージを注入して再試行する。ところがこのリトライが同じコンテキストをそのまま再送するため、モデルは同じ壊れ方を再生産し、当然また失敗する。1回限りのリトライが構造的に成功し得ない設計になっている、という指摘がされていました。

さらに #64235 では、tool が実際にはすでに実行されて結果を返しているのに、その次のターンで malformed エラーが発火し、ラウンドが無駄になるケースも報告されています。ユーザーから見ると「しばらく考えた末に何もせず黙り込んだ」ように見える、という記述が状況をよく表しているようです。

発生条件

「なんとなくランダムに起きる」ように見えるが、発生条件は複数の Issue でかなり絞り込まれている。

長いマルチバイト / CJK 文字列の引数（#64506）。 ツールコールの引数に長い日本語・中国語などのマルチバイト文字列が含まれるとパースが失敗する、という切り口で立てられた Issue。日本語環境での開発はこの条件に当たりやすい。

プレーンテキスト化（#64418）。 「高コンポジションなセッション」、つまり情報量の多いセッションで、tool call が tool_use ブロックではなくプレーンテキストとしてシリアライズされる、という Issue。前述の根本原因と同じ現象を別角度から報告している。

大きいコンテキスト・広いツール面（#64235, #63687）。 1M コンテキストモードで、複数の MCP サーバや多数の skill を積んだ巨大プロンプトのとき、失敗率が上がるという相関が報告されている。#63687 では「ツール自体は成功しているのに malformed エラーが出る」点が強調されている。

長い thinking ブロック（#64235）。 effort レベルを高く設定して長考させると、失敗したターンの直前には必ず thinking ブロックがある、という観察。長考とツールコールのシリアライズの相互作用が疑われている。

整理すると「長い CJK 引数 × 大きいコンテキスト × 長考」が重なるほど踏みやすいということが分かります。日本語まじりの設定ファイルや長いログを扱う作業は、この条件にハマりやすい部類になるので注意が必要そうです。

回避方法（Issue 記載のもの）

#64658 には、影響を受けているユーザー向けの回避策が明記されています。

モデルを Opus 4.8 から Opus 4.7 または Sonnet 4.6 に切り替える。
malformed なターンを含むセッションを resume せず、新規セッションを始める。
1M コンテキストモードを避ける・積んでいる MCP や skill を減らす・thinking の effort を下げる、といったプロンプトを軽くする対策も発生率の低下に寄与する。
クライアント側で取り得る恒久対策の提案もされている。リトライ時に失敗した直前のアシスタントターンをそのまま再送しない（あるいは漏れた <invoke> テキストを除去してから送る）、stop_reason: tool_use かつ tool_use ブロックが0個のケースを検知してテキスト中の <invoke name="..."> をパースするフォールバックを用意する。

現状：未解決

これらの Issue を通読して分かるのは、本記事執筆時点でまだ解決していないということのようです。#64658 では最新のデスクトップアプリビルドでも再現することが確認されており、関連 Issue の多くが Open のまま、あるいは duplicate として集約されている状況となっています。

バージョンを上げるだけでは直らないため、当面はモデル切り替えと新規セッションでの再開という回避策で凌ぐのが現実的な対応のようですね。。。