Claude Codeでツール呼び出しが実行されない不具合と回避策

Claude Code CLIでOpusモデルを使った長時間セッション中に、EditやReadなどのツール呼び出しが実行されず、<invoke>タグを含むXML片がそのままチャット欄に文字として出力される不具合が報告されています。GitHub issue #64108では、出力の先頭にcourtという無関係な単語が必ず現れることから、表示上の崩れではなくモデルが生成するテキスト自体の破損だと確認されています。原因はまだ特定されていません。

症状 — ツール呼び出しがXMLの生テキストとして出力される

最初の報告(2026年5月31日)は、Opus・大コンテキストのCLIセッションで少なくとも6回発生したというものでした。典型的な出力は次の形です。

court
<invoke name="Edit">
<parameter name="file_path">/path/to/file</parameter>
<parameter name="old_string">...</parameter>
<parameter name="new_string">...</parameter>
</invoke>

本来ならEditが実行されるはずの箇所が、そのままテキストとして表示されます。最初の報告では影響がほぼEditとReadに集中し、Bashは無事だったとされていました。ところが別の報告者は逆の傾向を見つけています。53件の発生のうち42件がBashで、Edit・Read・内部のタスク更新呼び出しも巻き込まれていたというものです。影響を受けるツールの種類は環境ごとに一定しません。

漏れ出すトークンも一種類ではありません。多くの報告はcourtですが、ある報告者の環境では常にcountが現れ、courtやcallは一度も出ていません。さらに別の報告ではcourtesyやcourthood、courceforgeといった派生語も観測されています。トークンが環境によって変わるという事実は、固定の文字列バグではなく、モデルの出力生成そのものが不安定になっている可能性を示しています。セッションのJSONLを直接調べた複数の報告が、この文字列がモデルの生成テキスト自体に含まれており、描画側の不具合ではないと確認済みです。

一つの不具合ではなく、同じ形の報告が複数ある

このissueには、同じ症状形状を報告する6件の関連issueが2026年6月2日までにひも付けられました。表示上のノイズとして終わるものもあれば、courtが50回以上続く無限ループ、「ツール呼び出しをパースできませんでした(再試行も失敗)」というエラーで静かにターンが落ちるもの、生の<invoke>タグがそのまま描画されるものまで、下流の見え方はさまざまです。報告されたプラットフォームもmacOSとWindowsにまたがり、のちにLinuxでの再現も追加されました。CLI以外では、Windows版のClaude Cowork(デスクトップアプリ)でComputer Useプラグインを使っていたときにも、同じcourtの連打が起きたという報告があります。

いつ起きやすいか — 長いコンテキストとOpus系モデル

ある報告は、2026年5月28日から6月2日までの1セッションを対象に、この形状の発生を日別に数えています。

このセッションはOpus 4.7・Claude Code 2.1.148のまま、モデルもクライアントも変えずに走り続けていました。5/30の急増はClaude Code 2.1.158のリリース時期と、5/28の発生開始はOpus 4.8の展開日と重なりますが、報告者自身がこれを「タイミングが一致しているだけで、因果関係の証明ではない」と明記しています。

別の報告はLinux上のセッション記録を2026年5月19日から6月13日まで走査し、56件の該当イベント(2種類の出力形状の合計)を確認しました。このうち100%がOpus 4.8で発生し、同じ期間に使ったFable 5・Opus 4.7・Haikuでは0件でした。133セッションを対象にした生存時間分析では、セッション開始から初回発生までの応答回数は中央値で約100回、コンテキスト量にして66,000〜476,000トークンの範囲だったとまとめられています。ある1セッション内の比較では、Fable 5で約626回応答を重ねても0件だったのに、同じセッションでOpus 4.8に切り替えた直後の17回目で最初の発生が確認されました。一方でコンテキストの大きさだけが条件ではなく、642,000トークンまで到達しても一度も発生しなかったOpus 4.8セッションも44件報告されています。長いコンテキストは必要条件ではあっても、それだけでは十分条件にならないというのがこの報告の見立てです。

除外された仮説 — 特定バージョンやプラットフォームに限らない

このクラスタの報告を横断すると、いくつかの仮説が消去法で外れています。Opus 4.8限定という仮説は、Opus 4.7でも同じ形状が確認されたことで外れました。特定のCLIバージョン限定という仮説も、2.1.148から2.1.196まで幅広いバージョンで再現が報告されており成立しません。プラットフォーム限定という仮説も、macOS・Windows・Linuxの3系統すべてで再現が確認されたことで外れています。プロキシやゲートウェイ経由の通信破損という仮説についても、ある報告はANTHROPIC_BASE_URLの上書きなしにAnthropicの一次APIへ直接接続しており、レスポンスに正規のリクエストIDが付いていたことを確認したうえで否定しています。

なぜ厄介なのか — サイレントドロップと虚偽の「完了」報告

この不具合が単なる表示ノイズより深刻なのは、APIレスポンス上はstop_reasonがtool_useのままなのに、実際のtool_useブロックが1つも含まれないケースがあるためです。Claude Code側からは「ツールを呼び出そうとした形跡はあるが中身がない」状態に見え、呼び出しは実行されずに消えます。

ある報告では、モデル自身が「実は完了していなかった作業を訂正しようとしたEdit呼び出し」が、まさにこの不具合で失われる事例が確認されました。訂正しようとした呼び出しそのものが握りつぶされたことになります。別の報告でも、Editが実際にはファイルへ書き込まれていないのに、モデルは「修正を適用しました」と応答を続けており、ファイルの中身を読み直すまで誰も気づけなかったとしています。エージェントが呼び出し結果を検証せずに次の判断へ進む運用では、この種の取りこぼしが「完了したはずの作業」として静かに積み上がるリスクがあります。

見分け方 — セッションのJSONLをgrepする

Claude Codeのセッション記録(~/.claude/projects/<encoded>/<session-id>.jsonl)を直接調べると、stop_reason: "tool_use"なのにtool_useブロックを持たないメッセージとして該当イベントを特定できます。ある報告で使われた検出スクリプトの要旨は次のとおりです。

python3 -c "
import json, sys
for line in open(sys.argv[1], encoding='utf-8', errors='replace'):
    try: o = json.loads(line)
    except: continue
    m = o.get('message', {})
    if m.get('stop_reason') != 'tool_use': continue
    c = m.get('content', [])
    if any(b.get('type') == 'tool_use' for b in c if isinstance(b, dict)): continue
    print(o.get('timestamp',''), m.get('model'))
" ~/.claude/projects/<encoded>/<session-id>.jsonl

出力がタイムスタンプとモデル名だけを返せば、その時点で呼び出しが失われたことになります。漏れ出すトークンがcourt・count・courtesyのように変わる以上、固定の単語で検索するより「tool_useなのにtool_useブロックがない」という構造そのものを検出条件にするほうが確実です。

対処法 — フックやリトライでは捕まえられない

Claude CodeのPreToolUseフックは、モデルが組み立てたツール呼び出しが実際に処理される直前に発火する仕組みです。しかしこの不具合ではtool_useブロック自体が生成されないため、そもそもフックの発火対象になりません。PostToolUseフックも同様で、ツールが実行された後にだけ動くため、実行されなかった呼び出しには反応しません。

公式のエラーリファレンスが説明する自動リトライも対象外です。Claude Codeがリトライするのはサーバーエラーや接続切断、429スロットリングなど通信層の失敗に限られており、モデルがテキストとして応答を返し切った場合は「リクエストは成功した」という扱いになります。この不具合はネットワーク層の失敗ではなくモデルの出力内容そのものの問題であるため、公式ドキュメントが挙げる既存のリトライ経路のどれにも当てはまらないとみられます。実際、Claude Codeのエラーリファレンスにはこの症状に専用のエントリが無く、近い項目である「Tool use or thinking block mismatch」も、会話履歴のtool_useとtool_resultの並びが食い違って起きる別種の400エラーで、/rewindで復旧できると案内されています。今回の不具合はそもそもエラーとして表面化しないため、この案内も当てはまりません。

報告されている回避策は次の3つです。

• 不具合が始まったセッションはリセットする(再試行を重ねるほど悪化したという報告がある)
• 幅の広いターミナル出力や大量のスクリーンショットなど、大きなツール出力を一度に蓄積させない
• 強いエスケープを含む複雑なpython3 -c "..."の一行コマンドを避け、単純なBashコマンドに分割する

いずれもコンテキストの蓄積を抑える方向の対処で、不具合そのものを防ぐ手段としては確認されていません。code executionツールとBashツールの混同のように、ツール呼び出しが期待どおりに動かない他のケースと合わせて、呼び出し後の結果を自分で確認する習慣が実質的な防御線になります。このissueには2026年7月20日までに16件のコメントが寄せられていますが、Anthropic公式からの一次コメントは確認できません(重複候補を通知する自動botのコメントを除く)。

早見表 — 状況ごとの深刻度

まとめ

Claude Code CLIでOpusモデルを使う長時間セッションでは、ツール呼び出しがcourtのような無関係な単語とともにテキストとして漏れ出し、実行されずに終わることがあります。原因は特定されておらず、Opus 4.7・4.8の両方、macOS・Windows・Linuxの3プラットフォーム、複数のCLIバージョンで報告されているため、単純な「このバージョンだけ更新すれば直る」という話でもありません。有効と報告されている回避策はセッションの作り直しだけで、PreToolUse・PostToolUseのどちらのフックも、公式ドキュメントが説明する自動リトライも、この不具合を捕まえられません。長時間・大コンテキストのセッションを運用するときは、ツール呼び出しの結果を都度確認する習慣が実質的な保険になります。