tool call could not be parsedエラー — Claude Codeの原因と対処法

このTipsでできること

Claude Codeで作業中に「The model's tool call could not be parsed (retry also failed).」というメッセージが出て、実行中のタスクが急に止まることがあります。この記事では、エラーが出る仕組み、GitHub Issueに集まった発生条件と復旧の報告、v2.1.251とv2.1.281で入った修正、そして今すぐ試せる対処法を扱います。

「tool call could not be parsed」とは何を意味するエラーか

Claude Codeは、モデルの応答からEditやBashなどのツール呼び出しを読み取り、実際にコマンドを実行します。この読み取り(パース)に失敗すると、次のメッセージが表示されます。

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

Issue #63875の報告によれば、モデルがツール呼び出しを試みてもコマンドは実行されず、このメッセージが出て実行中の行動が中断されます。内部で自動的に再試行されますが、その再試行も失敗するため、そのターンは失われます。ユーザーは同じ依頼を送り直すことになります。

報告者の環境はClaude Code v2.1.158、モデルはOpus 4.8(1Mコンテキスト)、OSはWindows 11でした。決まった再現手順はなく、間欠的に多くのセッションで起きると書かれています。公式のエラーガイドには、このメッセージを扱う項目はありません。

内部で何が壊れているのか

Issueには、より踏み込んだ観察を書いたコメントが付いています。あるコメントによれば、壊れたツール呼び出しには共通の形があります。正しい開始タグの代わりに、無関係な短いトークン(多くはcountという語)が単独の行として現れ、続く<invoke name="...">から名前空間の接頭辞(antml:)が欠けているというものです。

ハーネス側のパーサーは決まった開始シーケンスを探すため、これを見つけられません。そのブロックはツール呼び出しではなく、ただのテキストとして扱われます。これは一利用者の観察で、Anthropicの公式な原因説明ではありません。

同じコメントは、失敗したブロックが会話履歴に保存されない点にも触れています。--debugやトランスクリプトを見ても、壊れた生のペイロードは残らないという指摘です。デバッグログを探しても手がかりが出てこないのはこのためだとされています。

Issueのコメントから見える発生条件

Issueは2026年5月30日に立ち、8月19日に重複(duplicate)としてcloseされました。その間に付いたコメントには、環境も言語も異なる報告が混在しています。どれも一利用者の観察で、確定した原因ではありません。

Issueが立った直後には、重複候補として別の3件(#62123、#62467、#63719)が自動コメントで挙げられました。8月19日のclose先は#62123で、そちらをフォローするよう案内されています。症状の報告が複数のIssueに分かれているので、最新の議論は#62123でも追えます。

• 長いターンの後半: 失敗が集中するという報告があります。一方で、2〜3回目のツール呼び出しで失敗した短いセッションの報告もあり、長さだけでは説明できません
• 特殊文字の多い文脈: 非ASCII文字、入れ子の引用符、シェルのエスケープ、base64のブロックの直後に起きたという報告があります
• 日本語・中国語の作業: 中国語で繰り返し失敗したセッションを、フランス語の新しいセッションに切り替えたところ約3時間再発しなかったという報告があります。一方でスウェーデン語(å/ä/ö)を毎日使う利用者は、2週間で2回ほどしか遭遇しなかったと書いています
• thinkingの後のtool_use: 長い思考やテキストの出力の後に同じターンでtool_useが続くと落ちやすく、ツール呼び出しを先に出す順序にすると頻度が下がったという報告があります
• effort設定: maxの利用者が、highやmediumに下げると頻度が減ったと書いています。完全な解決策ではないという但し書き付きです
• モデル: 「Sonnetでは問題ない」という報告と、Opus 4.7に戻したら起きなくなったという報告があります。一方で、Opus 4.7でも4.8でも起き、4.7に戻しても直らなかったという報告があります。Opus 5でも出たという報告もあり、モデルだけでは切り分けられません。Issueのラベルにはarea:modelとplatform:windowsが付いていますが、コメントにはmacOSやWSL2の環境もあります

一度起きると続くケースと、復旧に効いたという報告

コメントの中に、特に厄介な型の報告があります。一度失敗が始まると以降のツール呼び出しがすべて壊れ、モデルは失敗に気づかず成功したかのように振る舞うというものです。モデルが履歴の中の壊れた出力を引き継いで、同じ形を繰り返しているように見えるという観察でした。

この報告者が試した復旧手段の結果は、次のとおりです。

/compactは公式のコマンド一覧で「会話を要約してコンテキストを空ける」コマンド、/rewindは「会話やコードを以前の時点に戻す」コマンドとして載っています。どちらもこのエラーのための機能ではありません。この報告は一利用者の経験にとどまります。

修正の経過

changelogで、このエラーに関わる修正は2件あります。

v2.1.251のchangelogの文言は次のとおりです。

Improved retry when the model's tool call is malformed: the broken output is now dropped from the retry context, including on Bedrock, Vertex, and Foundry.

Bedrock・Vertex・Foundryでも適用されるとchangelogに明記されています。以前は壊れた出力がリトライの文脈に残っていたため、モデルが同じ壊れ方を繰り返しやすかったと読めます。この改善はClaude Code v2.1.251に含まれています。

v2.1.281の修正は、「解釈できないツール呼び出し」が--max-turnsの上限を超えて続く事態を止めるものです。--max-turnsを付けて実行している場合に関わります。修正の後の9月13日にも、Opus 5で同じエラーに遭遇したというコメントが付いています。再試行で軽減できたそうです。

なお、このリトライはCLAUDE_CODE_MAX_RETRIESが制御するものとは別です。公式のエラーガイドでは、この環境変数はサーバーエラーや通信断などAPI呼び出し自体が失敗したときの再試行回数(既定10)を調整するものとされています。パース失敗の再試行がこの値に従うとは書かれていません。

今すぐ確認したい対処法

claude --version
claude update

claude --versionは2.1.289 (Claude Code)の形式で表示されます。デバッグログを残したいときは--debug-file <path>でファイルに書き出せますが、前述のとおり壊れたペイロードそのものはログに残らないという報告があります。

似た名前のエラーと混同しない

「tool」の語を含む別系統のエラーが2つあります。

両者は英語表現が似ているため、エラーメッセージの全文を見てから対処法を選んでください。MCPのツールが見つからないという別のエラーもあります。「MCP tool not found」は--permission-prompt-toolの設定が原因で、メッセージの文言が違います。

長時間実行されるMCPツール呼び出しが自動でバックグラウンド化される仕組みの変更も別の話です。詳しくはMCPの長時間ツール呼び出しが自動でバックグラウンド化する仕組みを参照してください。認証周りにも紛らわしい文言があります。「Could not resolve auth method」や「Could not load credentials」は、今回のパース失敗とは無関係です。

まとめ

Issueの報告を並べると、このエラーはモデルの出力の形が崩れる現象で、設定の見直しでは直らないようです。v2.1.281以降に更新したうえで、失敗が続くセッションは送り直しを重ねず/compactか/rewindで履歴を作り替える、というのが報告の多い復旧手順です。