Claude Code で作業をしていると、Bash や Edit、MCP ツールの呼び出し直後に「The model's tool call could not be parsed (retry also failed).」というエラーが出て、進行中の処理が丸ごと破棄されます。しかも一度出始めると、リトライしても直らず、数ターンおきに何度も再発します。大きめのリファクタや長時間のセッションでこれが連発すると、作業はまったく前に進みません。
このとき多くの方が最初に疑うのは「自分が何か設定を壊したのではないか」という点です。直前まで普通に動いていただけに、settings.json を見直したり、MCP サーバーを片っ端から外したり、/clear を連打したりと、原因探しに時間を溶かしてしまいがちです。
結論から言うと、このエラーの多くは利用者側の設定ミスではなく、モデル応答側のバグです。Claude Code が悪いというより、モデルが返してくるレスポンス（ツール呼び出しの部分）が壊れていて、それを Claude Code が解釈できずにターンを破棄している、という構図になっています。これは GitHub の公式リポジトリに複数の Issue として報告されており、特定のモデル・特定の条件で再現することが確認されています。
本記事では、まずこのエラーが「あなたのせいではない」と確信できるよう、技術的な発生メカニズムを整理します。そのうえで、自分のケースが既知のバグと同一かを自力で判定する切り分け手順、今すぐ作業を再開するために効果がある対処法、逆に試しても遠回りになりやすい対策、そして恒久対応までを順に解説します。
「tool call could not be parsed」エラーとは何か
エラーの全文と表示される瞬間
このエラーは、Claude Code のターミナル上に次のメッセージとして表示されます。
The model's tool call could not be parsed (retry also failed).
表示されるのは、Claude が Bash・Edit・Read・MCP などの「ツール」を呼び出そうとした直後です。Claude Code は内部で 1 回リトライを試みますが、そのリトライも失敗すると上記のメッセージを出し、進行中だったアクション（ファイル編集やコマンド実行）はそのまま破棄されてターンが終了します。
厄介なのは、コンテキストにまだ余裕があっても、ネットワークが正常でも発生する点です。レート制限（429）や接続エラーのように「待てば直る」性質のものではなく、同じ操作を繰り返しても同じ場所で止まることが少なくありません。
結論先出し：多くはモデル応答側のバグであり設定ミスではない
先に結論を述べておきます。このエラーの大半は、あなたの環境設定・コンテキストの使いすぎ・MCP の構成ミスが原因ではありません。モデルが返すレスポンス（ツール呼び出し部分）が壊れて出力される、応答ストリーミング側のバグです。
このことは Anthropic 公式の GitHub リポジトリで複数の Issue として報告されています。たとえば 2026 年 5 月 20 日以降に Opus 4.7 で急増した事例（Issue #61133）では、特定のモデルバックエンドへのルーティング変更が引き金になったことが、レスポンスの解析データとともに示されています。つまり、利用者が何もしていなくても、ある日を境に発生し始める種類の問題です。
「自分の設定をいくら見直しても直らない」と感じているなら、それは正しい直感です。原因を自分の中に探し続けるのをいったん止め、次章以降で「本当にこれが既知バグなのか」を確認し、効果のある回避策に進みましょう。
エラーが起きる仕組み（技術的な原因）
なぜ「自分のミスではない」と言えるのか、その技術的な根拠を整理します。
Claude Code がツールを実行するとき、モデルは応答の終了理由を表す stop_reason と、実際に実行する処理を表す tool_use ブロックをセットで返します。Claude Code は stop_reason が tool_use であれば「次はツールを実行するんだな」と判断し、付随する tool_use ブロックの中身（コマンドや引数）を読み取って実行します。
このエラーは、この「stop_reason と tool_use ブロックの整合性」が崩れたときに発生します。そして、同じエラーメッセージでも内部要因は大きく 2 系統に分かれます。
系統A：tool_use ブロックが欠落する（Opus 4.7 系）
1 つ目は、stop_reason は tool_use なのに、肝心の tool_use ブロックが応答に含まれていないパターンです。応答の中身は thinking（思考）ブロックと text（テキスト）ブロックだけで、実行すべきツール呼び出しが存在しません。
Issue #61133 の解析によれば、これは Opus 4.7 で 2026 年 5 月 20 日に行われたモデルルーティングの変更がきっかけでした。報告者がレスポンスを解析したところ、5 月 19 日までは正常なモデルシグネチャを返していたものが、5 月 20 日以降に別のバックエンドへ振り分けられるようになり、そのバックエンドが「ツール呼び出しを欠いた応答」を返すようになっていたことが時系列データとともに示されています。5 月 21 日には、retry でも失敗するケースが 29 件記録されています。
Claude Code 側の挙動は次のようになります。
- モデルが
stop_reason: tool_useを返すがtool_useブロックがない - Claude Code が「ツール呼び出しが壊れている、リトライして」と内部で再要求する
- リトライ応答にも
tool_useブロックがない - 最終的に「The model's tool call could not be parsed (retry also failed).」を表示してターン破棄
この系統は Issue #61133 上では既に Closed（解決扱い）になっています。
系統B：tool_use の JSON が壊れて出力される（Opus 4.8 系）
2 つ目は、tool_use ブロック自体は存在するものの、その中の JSON が壊れているパターンです。文字列が途中で閉じられていない（unterminated string）、波括弧が足りない、引数が途中で切れている（truncated arguments）といった、構文として不正な JSON が出力されます。
Issue #63604 では、Opus 4.8 で MCP ツールを呼び出す際にこの壊れた JSON が繰り返し出力されると報告されています。興味深いのは、同じシステムプロンプト・同じ MCP 構成・同じ会話履歴のまま Opus 4.7 に切り替えると即座に解消した、という観測です。これは構成ミスではなくモデル世代に依存した問題であることを裏づけています。
また、テキストブロックとツール呼び出しブロックが 1 つの応答にまとめて出力される都合上、ツール呼び出しが壊れているとテキストブロックごと破棄されてしまいます。そのため、ユーザーから見るとモデルが急に「黙ってしまった」ように見えることもあります。Issue #63875 でも Opus 4.8（1M コンテキスト）・Windows 環境での再発が報告されており、執筆時点で Open（未解決）のまま継続しています。
発生しやすい条件
報告された事例を整理すると、次のような条件で起きやすい傾向があります。
- 長いターン：複数ステップにわたる複雑な操作の途中
- 1M コンテキスト：Opus 4.7 / 4.8 の 1M コンテキスト構成
- 高い effort（extended thinking）：思考量が大きい設定での連続ツール呼び出し
- 大きな引数・特殊文字を含むツール呼び出し：非 ASCII 文字、引用符、複雑なコードスニペットを含む引数
いずれも「コンテキストを使い切ったから」ではない点に注意してください。使用率が低くても発生します。
自分のケースが既知バグかを切り分ける手順
ここまでで「モデル側のバグである可能性が高い」と分かりましたが、念のため自分のケースが既知のバグと同一かを確認しておくと、無駄な設定見直しを完全に切り捨てられます。以下の手順で機械的にチェックしましょう。
まず確認するバージョン・モデル
最初に、使っている Claude Code のバージョンとモデルを確認します。
claude --version
加えて、/doctor を実行すると環境診断ができます。報告が集中しているのは Opus 4.7 系および Opus 4.8 系です。逆に、当該期間に Sonnet 系では当エラーが観測されなかったという報告もあります。自分が Opus 4.7 / 4.8 を使っているなら、既知バグに該当する可能性が高いと判断できます。
セッションログ（jsonl）で見るべき3つの異常
より確実に判定したい場合は、セッションのログファイルを確認します。Claude Code はセッションの記録を ~/.claude/projects/ 配下に .jsonl 形式で保存しています。該当セッションのログを開き、エラーが出た前後の assistant 応答を確認してください。次の 3 点のいずれかが見つかれば、系統A（tool_use 欠落型）の既知バグに合致します（qualiteg ブログの分析手順を参照）。
- content が
thinkingブロックだけで終わっている：本来はtextやtool_useが続くべきところが、思考ブロックのみで終わっている thinkingが空文字になっている："thinking": ""のように中身が空stop_reasonとの矛盾："stop_reason": "tool_use"と書かれているのに、応答内にtool_useブロックが存在しない
系統B（壊れた JSON 型）の場合は、tool_use ブロックの中の引数 JSON が途中で切れていたり、引用符が閉じられていなかったりします。
別エラーと混同しないための見分け
このエラーは、見た目が似ている別のエラーと混同しやすいので注意してください。
rate_limit/ 429：レート制限。一定時間待てば解消するため、ツール呼び出しの構文とは無関係です- Connection error：ネットワーク・SSE の切断。トークンが流れてこない状態であり、本エラー（トークンは流れてくるが解析に失敗する）とは異なります
- 401 / 認証エラー：APIキーや認証の問題
これらは「待つ」「再接続する」「認証し直す」で対応すべきもので、本記事の回避策とは別物です。逆に言えば、待っても再接続しても同じ場所で止まり、jsonl に上記の異常が見つかるなら、それはモデル応答側のバグです。
効果がある対処法
切り分けが済んだら、今すぐ作業を再開するための回避策に移ります。即効性の高い順に並べ、それぞれ「なぜ効くか」（どの発生条件を外すか）を添えます。コマンド・環境変数は公式ドキュメントおよび各 Issue・qualiteg ブログで確認したものに限定しています。
/effort を下げて thinking 依存度を減らす
extended thinking の量が多いほど発生しやすい傾向があるため、/effort を下げると改善することがあります。Claude Code のチャット内で次のように実行します。
/effort medium
/effort の取りうる値は low / medium / high / xhigh / max の 5 段階です（Claude Code Model configuration ドキュメント）。なお xhigh は Opus 4.7 以降で利用できる値で、Opus 4.7 では xhigh、Opus 4.8 では high がそれぞれデフォルトになっています。デフォルトが高めに設定されているモデルでは、medium や low に下げることで thinking ブロックの肥大化を抑え、発生条件の 1 つを外せます。
1M コンテキストを無効化する
Opus 4.7 / 4.8 の 1M コンテキストで発生しやすいため、これを無効化して標準の 200k に戻すと改善するケースがあります。環境変数 CLAUDE_CODE_DISABLE_1M_CONTEXT を設定します（Claude Code Model configuration ドキュメント）。
export CLAUDE_CODE_DISABLE_1M_CONTEXT=1
恒久的に無効化したい場合は、~/.claude/settings.json に次のように記述する方法もあります。
{
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}
}
この変数は Claude Code v2.1.50 以降で利用できます。なお、無効化すると当然 1M の長大コンテキストは使えなくなり 200k に戻る点には注意してください。Max / Team / Enterprise プランでは Opus が自動的に 1M コンテキストに引き上げられる仕様のため、知らないうちに 1M を使っていることがあります。
壊れたセッションは再開せず新規セッションで始める
一度このエラーが記録されたセッションは、壊れた assistant 応答が履歴に残ったまま再開されるため、--resume や --continue で続けると同じ場所で再発しやすくなります。深追いせず、新しいセッションを開始して作業を仕切り直すのが確実です。
最新版へアップデートする
ストリーミング周辺の不具合は CLI やモデルの更新で改善することがあります。次のコマンドで最新版に更新してください。
claude update
系統A（Opus 4.7 系）の Issue #61133 が Closed になっているように、特定の発生パターンは更新によって解消されています。まず最新版になっているかを確認しましょう。
タスクを小さく分割する・大きな引数を避ける
系統B（壊れた JSON 型）は、大きな引数や特殊文字を含むツール呼び出しで起きやすい傾向があります。一度に大量のファイルを編集させる、巨大なコードブロックを引数に渡す、といった操作を避け、タスクを小さく分割すると発生確率を下げられます。
効果が薄い・遠回りになる対策
一方で、検索者が真っ先に試しがちなのに根本解にならない対策もあります。先回りで止めておきます。
/clearを打つ：一時的に直ったように見えても、根本原因（モデルの応答ストリーミング）が残っているため、数ターン後に再発します。連打しても解決には近づきません- MCP サーバーを片っ端から外す：MCP のトークン寄与は本件の主原因ではないことが多く、外しても改善しないケースが大半です（系統Bで MCP ツール呼び出しが絡む場合を除く）
/compactを実行する：コンテキストの圧縮はコンテキスト使用率が高い局面でこそ意味を持ちます。本エラーは使用率が低くても発生するため、使用率に余裕がある状態で/compactを打っても効果は期待できません
これらに時間をかける前に、前章の「効果がある対処法」を試すのが近道です。
恒久対応とAnthropicへの報告
このエラーがモデル／CLI 側のバグである以上、根本的な恒久解は基本的に提供側の修正待ちになります。利用者側でできるのは、発生条件を外す回避策（前述）と、改善を後押しするための報告です。
報告には Claude Code の /bug コマンドが使えます。報告時には、再現に役立つ情報（セッション ID、claude --version の出力、可能であれば該当する request_id、jsonl 上で観測した異常）を添えると、原因特定に寄与します。
関連 Issue の状況は執筆時点で次のとおりです。
- 系統A（Opus 4.7 系・tool_use 欠落型）の Issue #61133 は Closed
- 系統B（Opus 4.8 系・壊れた JSON 型）の Issue #63604 は Open
- 同じく Opus 4.8（1M コンテキスト）での再発を報告する Issue #63875 も Open
Issue の状況は時間とともに変わります。同じエラーに遭遇したら、まず最新版へアップデートし、それでも直らなければ関連 Issue の最新コメントを確認しつつ、自分のケースを /bug で報告するのが建設的なアクションです。
よくある質問（FAQ）
このエラーは自分の設定ミスが原因ですか？
多くの場合、設定ミスではありません。モデルが返す応答（ツール呼び出し部分）が壊れて出力される、応答ストリーミング側のバグである可能性が高いです。確信を持ちたい場合は、本記事の「自分のケースが既知バグかを切り分ける手順」に沿って、バージョン・モデルの確認と jsonl ログの確認を行ってください。
/clear で一時的に直るのに再発するのはなぜですか？
/clear で会話履歴をリセットすると一時的に改善したように見えますが、根本原因であるモデルの応答ストリーミングの問題は残っているためです。同じモデル・同じ条件で使い続ける限り、数ターン後に再発します。
特定のモデルでだけ起きますか？
報告は Opus 4.7 系および Opus 4.8 系に集中しています。逆に、当該期間に Sonnet 系では当エラーが観測されなかったという報告もあります。Opus を使っていて頻発する場合は、既知バグに該当する可能性が高いと考えてよいでしょう。
1M コンテキストを切ると何が変わりますか？
CLAUDE_CODE_DISABLE_1M_CONTEXT=1 を設定すると標準の 200k コンテキストに戻り、発生条件の 1 つ（1M コンテキスト構成）が外れます。その代わり、1M の長大コンテキストは使えなくなります。長い文脈を保持したい作業では不便になる点を理解した上で切り替えてください。
コンテキストがまだ余っていても起きるのはなぜですか？
コンテキストの枯渇は本エラーの直接原因ではないためです。使用率が低い状態でも、モデルが壊れた応答（tool_use ブロックの欠落、または壊れた JSON）を返せば発生します。だからこそ /compact でコンテキストを圧縮しても解決しないのです。
