Claude Codeのツール呼び出しが失敗する原因と4つの対策｜2026年6月時点のリグレッション全貌

Claude Codeで「The model's tool call could not be parsed (retry also failed)」というエラーが2026年5月末以降、急増しています。
これはユーザー側の設定ミスではなく、複数の公開GitHub IssueでClaude Code本体と特定のClaudeモデル側で並行発生しているリグレッション（機能後退）が原因として示唆されています。

本記事では、いま起きている不具合の全貌、4つの発生パターン、安定バージョンへのダウングレード／自動更新の停止／モデルとセッション運用の調整／Stopフック検出という4つの対策、公式修正の追跡先までを、2026年6月時点の最新情報で整理します。

Claude Codeで多発しているツール呼び出し不具合

Claude Codeで急増している「The model's tool call could not be parsed (retry also failed)」エラーは、Claude Codeがツール呼び出しを正しく組み立てられず、解析に失敗していることを示すメッセージです。複数の公開Issueでは、ユーザー側のプロンプトや設定の問題ではなく、Claude Code本体（CLI）とClaudeモデル側で並行発生しているリグレッションが原因として示唆されています。

このセクションでは、まず画面に出てくる「2種類の見え方」を整理したうえで、いつから・どの規模で発生しているのかを公開データから押さえます。

エラーの2つの表面症状

このエラーには大きく分けて2種類の見え方があります。

ひとつは、Claude Codeがツールを呼び出そうとしたタイミングで長く「思考」したあと、結果が返らずに次のメッセージとして「Your tool call was malformed and could not be parsed. Please retry.」が突然挿入されるパターンです。Claude Codeは自動で1回リトライしますが、そのリトライも失敗すると最終的に「The model's tool call could not be parsed (retry also failed).」というメッセージで停止し、そのターンの作業はそこで途切れます。

もうひとつのパターンは、ツール自体は正しく実行されているのに、その直後に同じ失敗メッセージが付加されるケースです。git commit や gh コマンドが正常に走って結果も返っているのに、画面には失敗を示すメッセージが表示されるため、ユーザーは成功なのか失敗なのか判断できない状態に陥ります。

この2分類はあくまで「ユーザーに見える挙動」の整理であり、その奥にある原因の内部メカニズムは次のセクション「並行発生している4つの不具合パターン」で別途A〜Dに分解します。

発生規模と公式対応の現状

このエラーの始点は明確で、GitHub Issue #64235 では2026年4月23日〜5月28日の期間に記録された約32,000件のツール呼び出しターンで該当エラーが0件だった一方、2026年5月29日に突如57件が発生したと報告されています。

複数の独立した実測でも同時期に同様の傾向が観測されており、Claude Code 2.1.37〜2.1.148まで数百セッションで0件だったエラーが、2.1.150で初発、**2.1.158では12セッション中7セッションで合計68件発生（1セッションあたり平均9連発）**したことが報告されています。

ユーザー側で何かを変えたわけではなく、Claude Code側で2026年5月下旬以降に変わった結果として一斉に発生し始めた事象だと押さえておく必要があります。

2026年6月17日時点で、Anthropic公式リポジトリには関連Issueが15本以上 OPEN のまま残っています。最新のIssue #68833 は6月16日に新規に開かれており、本文によると 2.1.178 で症状が再現しています。公式のClaude Code Changelog を見ても、最新版である2.1.179のリリースノートに本件の明示的な修正は確認できません。「最新版にすれば直る」という前提は、2026年6月17日時点では確証がない状態です。

並行発生している4つの不具合パターン

このエラーが厄介なのは、「単一の原因ではなく、Claude Codeの内部で独立した症状が同時期に並行発生している」点です。原因が複数ある以上、対処も症状ごとに分ける必要があります。

ユーザー側で「同じエラーメッセージが出る」と認識される事象も、内部的には少なくとも4種類の異なるメカニズムが識別されています。

以下の表で、4つのパターンを整理しました。

この4分類は対処判断に直結します。たとえばパターンBは「ツール自体は通っている」ため、データ損失や副作用は起きていない一方で、見た目だけが壊れています。これに対しパターンAやCは「ツール呼び出し自体が成立しなかった」ため、必要だった処理が抜け落ちる実害が出ます。

A: ツール呼び出しブロックが欠落する

最も典型的な症状がこのパターンAです。Claude のターンが「ツールを呼ぶ」という終了理由で終わっているにもかかわらず、応答メッセージの中身を覗くと「思考（thinking）」のブロックしか入っておらず、肝心のツール呼び出しブロックが存在しません。

#64235のフォレンジック で実際のJSONLログ抜粋が公開されていますが、turn N-2で正常に Bash 呼び出しが成立し、turn N-1でツール結果が返り、その次のturn Nで「ツールを呼ぶ」終了理由ながら中身が思考ブロックのみ、というシーケンスが確認できます。

Claude Code側のパーサは「『ツールを呼ぶ』と宣言されているなら呼び出しブロックがあるはず」という前提で動くため、この欠落を検知した瞬間に「malformed」と判断してリトライを投げます。リトライも同じ症状で返ってくると、ターンが破棄される流れです。

このパターンは Opus 4.7 と Opus 4.8 の双方で確認されており、長い思考を伴うターン（高effort設定や1Mコンテキストモードで顕著）に発生しやすい傾向があります。

B: 実行成功なのに失敗メッセージが後付けされる

Issue #62700 と#65787 が報告しているのが、この「見た目だけ壊れている」パターンです。git commit/push も gh クエリも Write/Edit も実際には正常に走って結果を返しているのに、その直後に「Your tool call was malformed and could not be parsed. Please retry.」が割り込んで挿入されます。

報告者の環境では「Request interrupted by user」という擬似的な割り込みメッセージを伴うこともあり、ユーザーは「continue」と入力し直して進める必要があります。

このパターンは作業データには影響しませんが、画面の挙動が壊れているため「成功しているのか失敗しているのか分からない」という認知負荷を発生させます。長時間の自動エージェント実行で多発すると、後からどのステップを本当に通したのかを追跡するのに余分なコストがかかります。

パターンBに遭遇した場合、即座に同じコマンドを再実行する前に、ツールが本当に成功していたかを確認する手順が重要です。git commit や git push のように副作用のあるコマンドだと、画面の「malformed」を見て条件反射でリトライすると、コミットや push が二重に実行される事故になります。確認の手順は次の3点です。

• git 系コマンドの場合：git log -1 や git status で直前のコミット/プッシュ状態を確認してから次の操作に進む
• ファイル系（Write/Edit）の場合：対象ファイルを ls -la または cat で開いて、想定どおりの変更が反映されているか確認する
• gh / API系の場合：gh pr view / gh issue view などで結果側を直接見て、操作が反映されたかを確認する

これらは数秒で済む確認なので、「malformed」を見たら反射的にリトライせず、必ず結果側を一度見るルールにしておくと事故が防げます。

C: Opus 4.8で余計な文字が混入する

これは Opus 4.8 固有の症状で、Issue #67307 で詳しく報告されています。アシスタントの通常の文章が終わったあと、独立した行に「count」または「call」という単語だけがぽつんと残り、続いて出力されるはずのツール呼び出しブロックが、Claude Codeが「実行可能なツール呼び出し」と認識するための識別子を失った状態で出力されます。

結果としてXML的なマークアップ部分が「実行されるべきツール呼び出し」としてではなく、素のテキストとして画面に流れます。Claude Codeのharness側はこれを実行不能と判定し、失敗メッセージを差し込みます。

報告者の集計では2026年5月13日〜6月11日の期間で、生のマークアップがアシスタントの文章ブロックに残った事例が55件、harnessによるmalformed注入が14件、いずれもOpus 4.8でのみ発生し、Opus 4.7・Sonnet 4.6・Haiku 4.5では同期間ゼロです。Claude Code 2.1.159〜2.1.172 にまたがって発生しており、特定バージョンではなくモデル側に原因がある可能性が高い症状です。

なお、Claude Fable 5 は 2026年6月9日にリリースされたものの、2026年6月12日にAnthropicがFable 5／Mythos 5のアクセス停止を告知しており、2026年6月17日時点では新規アクセスができない状態です。Fable 5 はサイバーセーフティ判定でセッション中に Opus 4.8 へ自動フォールバックする経路が報告されているため、再開後に Fable 5 を使う場合は、選んだつもりでも実体は Opus 4.8 でパターンC を踏みうる「自動フォールバック経路」に注意してください。

D: Claude Code本体のバージョン依存退行

これがClaude Code本体側の退行です。失敗率はバージョン別に定量化されており、Issue #66247 で公開されている計測値と、別ソースの独立した実測データの両方が同方向を示しています。

以下の表で、Claude Codeのバージョン別の失敗率を比較しました。

2.1.156〜162のベースライン（1〜3‰）に対して、2.1.165で約8倍に跳ね上がっていることがわかります。#64176・#66247いずれも主にOpus 4.7/4.8環境で計測された値ですが、Read、Edit、Bash、Write、TaskCreate、WebSearch、MCPツールなどツールの種類を問わず観測されており、CLI側のバージョン依存性が強く示唆されます。

独立した実測でも2.1.150〜158の別山が同様に記録されており、2.1.158ピーク時の失敗率は #66247 計測のレベルをさらに上回っていました。2026年5月22日（2.1.149）以前は完全にクリーンだったClaude Codeが、2.1.150以降は2つの別系統のリグレッション山を抱えているというのが現状です。

ツール呼び出し失敗の4つの対策

ここまでで原因の全体像を整理しました。実務的には、修正がリリースされるまで以下の4つの対策を組み合わせて被害を最小化します。

• 対策1: 安定バージョンへのダウングレード——リグレッションが導入される前のバージョンに戻す
• 対策2: 自動更新を止めてバージョンを維持する——せっかく戻したバージョンが勝手に上がらないようにする
• 対策3: モデルとセッションの運用調整——Opus 4.8固有の症状を回避し、長セッションでの破綻を避ける
• 対策4: Stopフックで失敗を自動検出する——失敗してもエージェント実行を継続できるようにする

対策1と2はセットで実施するのが基本です。対策3・4は症状の出方とユースケースに応じて選択します。それぞれの実装手順を以降のセクションで詳述します。

安定バージョンへのダウングレード

最も確実な一次対処はClaude Code本体のダウングレードです。「最新が常に良い」「古いほど安定」のどちらも単純には当てはまらないため、ユースケース別に推奨バージョンを選び分ける必要があります。

バージョン確認とログ集計

最初にやるのは、自分の環境が現在どのリグレッションゾーンに置かれているかを客観的に確認することです。

ターミナルで次のコマンドを実行してClaude Code本体のバージョンを確認します。

claude --version

出力されたバージョンが2.1.150〜2.1.158または2.1.165〜2.1.168に該当する場合は危険ゾーンで、即座にダウングレードが必要です。2.1.159〜2.1.172も#67307 によるとOpus 4.8固有のパターンCが観測されており、最新の2.1.179まで明示的な修正リリースは確認できていません。

「最近この症状が出始めた気がする」という感覚は、ローカルのセッションログから定量的に裏付けられます。Claude Codeのセッションログは ~/.claude/projects/ 以下にJSONL形式で保存されており、次のワンライナーで該当エラーの発生数を集計できます。バージョン別の失敗率を比較するときに同じ集計コマンドが使えます。

grep -rc "malformed and could not be parsed" ~/.claude/projects/ | \
  grep -v ":0$" | sort -t: -k2 -n -r | head -20

このコマンドは、該当エラーが含まれるセッションファイルを発生件数の多い順に並べます。直近1〜2週間のファイル名（タイムスタンプ）と件数を見れば、どの日からどの程度発生しているかが一目でわかります。

より厳密にバージョン別の失敗率を出したい場合は、Pythonでversionフィールドごとに集計すると、自分の環境で2.1.149〜と2.1.158以降を比較した実数値を作れます。

失敗率（per-mille）が3‰を超えていればリグレッションゾーン、8‰を超えていれば重度の退行と判定して構いません。

推奨バージョンマップと戻し方

集計結果と利用機能の組み合わせで、推奨バージョンを整理しました。

2.1.149は最も安定していますが、その後追加されたClaude Code Agent Teams のexperimental有効化や ultracode などの新機能は使えません。一方で2.1.162は、並列ツール呼び出しの改善や、claude mcp list のパースエラー警告機能などが入った状態で、退行も軽微なため多くのユーザーにとって最もバランスの良い選択になります。

特定のバージョンに固定するコマンドは次のとおりです。

claude install 2.1.162

ネイティブインストール版（macOS/Linuxの ~/.local/share/claude/versions/ 配下にバージョン別ディレクトリを持つ形式）では、このコマンドは指定バージョンを取得して ~/.local/bin/claude のシンボリックリンクを張り替える動作になります。起動中のセッションには影響しません。シンボリックリンクの張り替えだけなので、すでに動いているプロセスは元のバージョンのまま走り続け、新しく claude を起動した時点から新バージョンに切り替わります。

npm経由で入れている場合は次のコマンドで指定バージョンに戻せます。

npm install -g @anthropic-ai/claude-code@2.1.162

Homebrew経由の場合は、Anthropic公式のtapが該当バージョンのformulaを保持していれば指定可能ですが、tap側の事情によりpinできないことがあります。その場合はnpm経由かネイティブインストールに切り替えるのが確実です。

自動更新を止めてバージョンを維持する

ダウングレードしただけでは安心できません。Claude Codeのネイティブインストール版にはユーザーに通知せず自動的にstableへ更新する仕組みがあり、PCを再起動した時点で勝手にバージョンが上がってしまうケースがあります。

自動更新が止まらない理由

設定ファイルでの自動更新無効化は、一見すると ~/.claude.json の autoUpdates を false に設定すれば済みそうに見えます。しかしAnthropic公式ドキュメント では、ネイティブインストールはバックグラウンドで自動更新される旨が明示されており、停止手段としては settings.json の env で DISABLE_AUTOUPDATER=1 を設定する方法が案内されています。autoUpdates: false の指定で停止できると読める箇所は公式Docsには見当たりません。

実際の環境で claude install 2.1.149 で安定版にピン留めしたつもりが、数日後に確認すると versions/ 内に2.1.149が存在しなくなり、2.1.153→168→179のように勝手にドリフトしていく現象が報告されています（#24396 でも類似の挙動が議論されています）。これは「自分が指定していないバージョンで動いている」という追跡困難な状態を生むため、次に紹介する環境変数で確実に止める必要があります。

環境変数による無効化

バックグラウンド自動更新を確実に止めるには、環境変数 DISABLE_AUTOUPDATER=1 をシェル起動時にエクスポートします。

zshユーザー（macOS標準）の場合、~/.zshrc の末尾に次の行を追加します。

export DISABLE_AUTOUPDATER=1

bashユーザーの場合は ~/.bash_profile または ~/.bashrc に同じ行を追加します。fishやPOSIX系シェルでも、それぞれの起動ファイルで環境変数を立てる構文に直して同じ意味を実現できます。

設定後は新しいシェルを起動し、次のコマンドで反映を確認します。

echo $DISABLE_AUTOUPDATER

「1」が表示されれば反映完了です。この状態でClaude Codeを起動すると、バックグラウンドの更新チェックが止まり、PC再起動時や常駐中に勝手にバージョンが上がる挙動を防げます。.claude.jsonのautoUpdates:false設定とは独立に効くため、ネイティブインストール版でもバージョンドリフトを止められます。

公式ドキュメントが明示しているとおり、DISABLE_AUTOUPDATER=1 は バックグラウンド更新チェックのみを止める変数で、claude update や claude install のような明示的な更新コマンドは引き続き動作します。社内配布やCI環境などで手動更新も含めてすべての更新パスをブロックしたい場合は、DISABLE_UPDATES=1 を併用します。個人開発で「勝手なバージョンドリフトだけを止めたい」用途なら DISABLE_AUTOUPDATER=1 で十分です。

更新したいときだけ環境変数を一時的に外して claude install latest を実行する方法もあります。次の1行で済みます。

DISABLE_AUTOUPDATER=0 claude install latest

このコマンドが終われば変数指定はそのターン限定なので、次にClaude Codeを起動するときは再びバックグラウンド更新が止まった状態に戻ります。週1回程度、公式のChangelogを確認し、解消版が出たタイミングでだけ手動更新する運用が安定します。

モデルとセッションの運用調整

バージョンピン留めと自動更新停止だけでは取りこぼされる症状もあります。特にパターンA（ツール呼び出しブロック欠落）とパターンC（Opus 4.8固有）はClaude Code本体のバージョン問題ではなくモデル側の挙動なので、モデル選択と運用パターンの変更で対処する必要があります。

Sonnet 4.6への退避

最もシンプルで効果的なのは、Opus 4.7/4.8からSonnet 4.6に切り替えることです。

パターンA・Cはいずれも Opus 系（特に4.7と4.8）で発生しており、Sonnet 4.6・Haiku 4.5では発生報告が極めて少ない状況です。コーディング業務であっても、シンプルなリファクタリングや既存コードの修正であればSonnet 4.6で十分こなせます。

切り替えは /model コマンドで行います。

/model claude-sonnet-4-6

セッション中での切り替えがimmediately反映されるため、エージェント実行を進めながら必要に応じてモデルを使い分けるのが現実的です。ただしSonnet 4.6は推論能力（特に複雑な計画立案やコードベース全体のリファクタリング設計）でOpus 4.8と差があるのも事実なので、Opusが必要な作業のときだけ短時間Opusに切り替え、それ以外はSonnet 4.6に戻す運用が無難です。

effort・1M contextの調整

1M contextモード と effortLevel xhigh（/effort max）の組み合わせは、ツール呼び出し失敗の発生確率を上げることが観測されています。

Qiita TomohiroSakai氏の整理 では、/effort medium への明示的な切り替えと、CLAUDE_CODE_DISABLE_1M_CONTEXT=1 環境変数による1M context無効化が、症状軽減策として有効と紹介されています。

note KOMOREBi氏の記事 では、CLAUDE_CODE_AUTO_COMPACT_WINDOW を512Kで運用することで、1Mのメリットを残しつつ実質的な負荷を下げる方法も提案されています。

これらは応急処置ではあるものの、根本対応がリリースされるまでの間、long-runningなエージェント実行を継続する必要があるチームには有効な工夫です。

コンテキスト圧縮前のセッション切り替え

#67307 は自動コンテキスト圧縮（auto-compaction）の直後にツール呼び出しが破綻しやすい傾向を明示しており、Opus 4.8で長文ブロック直後の初回ツール呼び出しが集中的に壊れていると報告しています。#64235 は「contributing factors」として effortLevel xhigh による長い thinking ブロック、1M contextモード、大きなツール面を挙げており、こちらは auto-compaction を直接の引き金とは断定していません。

いずれにせよ、長時間のセッションを「コンテキストが膨らんでも頑張って続ける」よりも、作業の自然な区切りで /clear または新規セッション起動でリセットしたほうが malformed リスクを下げられます。

実務的な目安として次のルールが有効です。

• 1セッションあたりコンテキスト使用量が80%を超えた時点で、次のタスクは新規セッションに移す
• 大きなコンテキスト圧縮が走った直後は、重要なツール呼び出し前に一度新規セッションへ切り替える
• 一度 malformed が複数回連続したセッションは、そのまま再開せず新規セッションでやり直す

Stopフックで失敗を自動検出する

ここまでの対策は「人間が気をつけて運用する」前提でした。長時間の自動エージェント実行や本番運用では、人が常に画面を見ているわけではないため、Claude CodeのHooks機能を使って失敗を自動検出する仕組みを組み込めます。

検出スクリプトの仕組み

zenn ultimatile氏の記事 で紹介されている方式は、StopイベントでアシスタントメッセージをスキャンしてXML的なツール呼び出しマークアップが平文として残っていないかをチェックする、というアプローチです。

スクリプトの動作は次の通りです。

• Stopイベントでアシスタントの最終メッセージを受け取る
• メッセージ本文中に invoke / parameter のような実行されていないツール呼び出しマークアップが含まれていないかを正規表現で検出
• 検出された場合、ターン終了をブロックして「あなたの最後のメッセージは生のツール呼び出しマークアップが平文として吐かれていました（実行されていません）」というメッセージをモデルに渡す
• モデルはこのフィードバックを受けて、同じツール呼び出しを正しい形式で再試行する

この設計のポイントは、サイレントに失敗するのではなく、会話履歴に「ラベル付きの失敗例」として残す点です。モデルは以降のターンで同じ失敗を回避しやすくなる、という副次効果も期待できます。

Hooksでの組み込み

Claude Codeの settings.json にHooksセクションを追加して、Stopイベントで上記スクリプトを呼び出すように設定します。

検出スクリプトは ~/.claude/hooks/detect-leaked-toolcall.py のようなパスに配置し、Stopイベントに対してPathPatternとコマンドを登録します。具体的な設定方法はClaude Code Hooksの解説記事 に詳細があるため、そちらも参照してください。

この方式の弱点は、検出スクリプトが完全ではないため誤検出・見逃しがゼロにはならない点です。ただしサイレントに失敗するよりは、検出された時点でログに残し再試行を促すほうが運用上の実害が小さいという判断で、長時間自動エージェント実行を行うチームでは導入する価値があります。

公式修正の追跡先

最後に、Anthropic公式の修正をどう追いかけるか、判断材料をどこから取るかを整理します。このリグレッションは複数の独立した症状を抱えているため、「全部直った」と判断するためのチェック項目も複数になります。1本のリリースで全パターンが解消されない可能性が高い前提で、各パターンを個別に追跡することをおすすめします。

以下の表が現時点で主要な追跡対象です。

これらは2026年6月17日時点ですべてOPENであり、Anthropic側からの解消アナウンスは出ていません。Issueは個別にウォッチ登録しておくと、解消時のクローズ通知が届きます。

公式のClaude Code Changelog でリリースノートを追う際は、「tool」「parse」「regression」「stream」「malformed」などのキーワードでgrepするとリグレッション関連の修正を見逃しません。特に「mid-stream connection」「streaming tool execution」「tool_use deserialization」のような表現が出てきたら、リグレッション解消候補として注意深く読み込む価値があります。

「いつ自動更新を再開してよいか」の判断基準は次の3条件すべてが揃った時点です。

• 上記Issueの3本以上がCLOSEまたはfix shippedとして更新される
• 解消版でローカル再現テストを行い、自分の環境でmalformed発生数が1‰未満に戻る
• 解消版リリース後最低1週間は他のユーザーから新規退行報告が出ていない

この条件が揃ったら、DISABLE_AUTOUPDATER を外して通常の自動更新運用に戻して問題ありません。最新動向はClaude Codeの2026年アップデートまとめ でも継続的に追跡しています。

【関連記事】
Claude Codeとは？できることや料金、使い方を徹底解説！

Claude Codeをチームで安定運用するには

Claude Codeのようなコーディングエージェントは、こうした一時的なリグレッションを差し引いてもなお、開発業務の生産性を大きく変えるツールです。重要なのは、「最新版なら大丈夫」という前提を置かず、Claude Code本体とモデル両方の挙動を観察しつつ運用ルールを更新し続ける体制を持つことです。

AI総研では、Claude Codeを含むコーディングエージェントの導入支援・運用設計を行ってきた経験から、次のような実装パターンが安定運用に効くことを確認しています。

• バージョンピン留めと環境変数によるバックグラウンド更新停止で「勝手に変わらない」状態を維持
• セッションログ集計のルーチン化による退行の早期検知
• モデル選択（Opus／Sonnet／Haiku）のユースケース別ルール化
• コンテキスト圧縮前のセッション切り替えを含む、自動エージェント運用パターンの設計

これらは個別のチームのワークフローに合わせて作り込む必要があり、特に統制・セキュリティの観点では業務影響の事前評価が欠かせません。Claude Codeの法人導入を検討する段階では、PoCから全社展開までの設計を体系的にまとめた資料が判断材料になります。

Claude Code活用を業務にどう定着させるか

PoCから全社展開までの設計を1冊で

Claude Codeのようなコーディングエージェントを業務に組み込むには、PoC設計・モデル選定・運用ルール・統制まで一気通貫の整理が欠かせません。AI業務自動化ガイド（220ページ）では、PoC段階から全社展開までの進め方、部門別ユースケース、AI運用における統制・セキュリティのチェックポイントをまとめています。

▶ 無料でダウンロード

まとめ

本記事では、Claude Codeで「The model's tool call could not be parsed」エラーが2026年6月時点で多発している現状を、原因と対策の両面で整理しました。

エラーは複数の公開Issueの観察によれば、2026年5月29日以降に始まったClaude Code本体とモデル両側のリグレッションが原因として示唆されており、ユーザー側の設定問題ではないとみられます。並行発生しているのはパターンA（ツール呼び出しブロック欠落）、パターンB（実行成功後の失敗メッセージ後付け）、パターンC（Opus 4.8固有の余計な文字混入）、パターンD（Claude Code本体のバージョン依存退行）の4種で、対処は症状ごとに分ける必要があります。

対策は4つあります。第一がバージョンのダウングレード（安定最優先なら2.1.149または2.1.156、2.1.165以降からの退避なら2.1.162が選択肢）。第二が DISABLE_AUTOUPDATER=1 によるバックグラウンド更新停止。第三がSonnet 4.6への退避とeffort／1M context／コンテキスト圧縮の調整。第四がStopフックを使った失敗の自動検出です。これら4つを組み合わせて被害を最小化します。

公式修正は2026年6月17日時点で複数Issueが未解決のまま進行中のため、解消アナウンスを追跡しながらバージョンのピン留めを維持する運用が現実的です。