目次

Claude Code で長時間作業していると、突然こんな“見たことのない文字列”が画面に流れてきた経験はないだろうか：

court
<invoke name="Bash">
<parameter name="command">ssh host 'cp file file.bak ; sed -i ...'</parameter>
<parameter name="description">…コマンドの説明…</parameter>
</invoke>

Your tool call was malformed and could not be parsed. Please retry.

本来は 裏側で実行されるはずのツール呼び出し（コマンド）が、生のテキストとして画面にダダ漏れし、しかも実行されない。先頭には court（または call）という意味不明な単語がくっついている。「自分のPCが壊れた？」「設定をミスった？」と不安になるが、結論から言うと、これはあなたの環境やコマンドのミスではない。

正体は Claude（特に Opus 4.8／4.7 系）がツール呼び出しの“制御タグ”を生成する瞬間に、まれにそのタグが壊れて出力されるモデル側の不具合だ。Anthropic 公式リポジトリにも 多数のIssue（#64108, #64150, #64690, #65705, #66153, #67295, #68354 など）が立っている既知の現象である。本記事では 仕組み・原因・よくある誤解・ユーザー/開発者それぞれの対処・似たエラーとの違い・公式の対応状況までを、公式ドキュメントと実Issueに基づいて整理する。最重要の対処を先に言うと「court が出たら、そのセッションで粘らず、早めに新セッション（/clear）へ逃げる」——理由は本文で説明する。

CLAUDE CODE · TOOL CALL LEAK

「court」＋invokeタグ漏れの正体

— 制御タグが壊れて生成され、実行されずに画面へ流れ出る

claude-code — opus-4.8 (1M)
本物を作ります。これは直すべきです。バックアップを取得します…
court ← ① 壊れた制御トークン
<invoke name="Bash">
<parameter name="command">cp file file.bak</parameter>
</invoke> ← ② 実行されるはずのXMLが素通し
Your tool call was malformed and could not be parsed.
↑ ③ fail-closed で弾かれる → コマンドは実行されない

壊れた呼び出しは 解釈できない＝実行されない（fail-closed）ので、誤コマンドが走る危険はない。
問題は 「1ターンの空振り」と、放置すると“連鎖”して詰まることだ。

1. 何が起きているのか——「court」とinvokeタグの正体

画面に出た <invoke name="Bash"> や <parameter name="command"> は、本来あなたの目に触れないはずの「ツール呼び出し用マークアップ」だ。Claude はコマンド実行やファイル編集をするとき、この XML風の構造化タグをトークンとして“生成”し、Claude Code（ハーネス）側がそれを解釈して実際にコマンドを動かしている。正常時は、このタグはハーネスに吸収されて画面には出ず、実行結果だけが表示される。

ところが今回は、ツール呼び出しの「開始を示す制御トークン」が壊れて生成され、先頭に court や call という無関係な単語が紛れ込んだ。ハーネスは厳密な構文にしか反応しないため、「これはツール呼び出しではない、ただのテキストだ」と判断して画面にそのまま流す。結果、コマンドは実行されず、「Your tool call was malformed and could not be parsed（ツール呼び出しが不正で解釈できなかった）」というメッセージが返る。なお、エラーメッセージすら出ず 無言で止まるパターンもある（Issue #65705 では応答が stop_reason=end_turn になり、実行すべきものが無いまま会話がストールした）。

court という単語自体に意味はない。ただし 「たまたま出た完全ランダムな1回限りの語」でもない——複数の独立した報告で 判で押したように court / call が出る。Issue #64690 はこれを 「語彙の中で“隣接した”トークンが正しいタグの代わりに誤って選ばれている」と分析している。つまり court は このバグを見分ける“目印（シグネチャ）”として役立つ、と捉えるのが正しい。

2. 背景：エージェントはツール呼び出しも「生成」している

なぜ“制御タグ”が壊れることがあるのか。鍵は 「AIエージェントにとって、ツール呼び出しも結局はテキスト生成だ」という点にある。

Claude API でツールを使うとき、開発者から見える形式は JSON（tool_use ブロック）だ。しかしモデルの内部では、Anthropic が自動で差し込む隠しシステムプロンプトの指示に従い、<function_calls> <invoke> <parameter> という囲みタグをトークン列として生成している。API層がこれを受け取って パースし、整った JSON の tool_use ブロックに変換している（公式ドキュメントの tool use 仕様）。MCP や AIエージェント の「ツールを呼ぶ」動作は、すべてこの仕組みの上に乗っている。

ここで重要なのが ハーネス側のパーサが「fail-closed（安全側に倒れる）」設計だということ。タグが 1トークンでも所定の形と違えば、ハーネスは 推測で実行したりせず、即「不正」として弾く。これは ハーネス設計として正しい——曖昧なコマンドを“良かれと思って直して実行”する方が、はるかに危険だからだ。だから今回の現象は 「壊れた → 弾かれた → 実行されなかった」という、安全に転んだ事例だと理解してほしい。

ひとことで言うと

ツール呼び出し＝モデルが生成する「特殊タグ付きテキスト」。そのタグの開始トークンが生成エラーで壊れると、ハーネスが認識できず地の文に漏れ、実行されない。弾く動作自体は正しい安全機構であり、バグはあくまでモデル側の生成エラーにある。

3. なぜ起きるのか——2つの主因と誘発条件

実Issueを統合すると、原因は 「①生成時の破損」と、それが厄介化する 「②自己汚染による連鎖」の2層に整理できる。

2 ROOT CAUSES

破損が起き、そして“連鎖”するまで

主因① 制御トークンの生成破損
ツール呼び出しの開始タグが、トークン生成のゆらぎで 隣接した別トークン（court / call）に化ける。名前空間接頭辞も欠落し、ハーネスが認識不能に。環境非依存（Win/mac/Linuxで再現・#68354）。
主因② 自己汚染による連鎖
壊れたブロックが会話履歴に残ると、モデルがそれを「正しいお手本」と誤認してコピー。だから再試行が逆効果になり、決定的に再発する（#64150・#62344）。
確率を上げる「誘発条件」（報告ベース・因果は未証明）
・非常に長い／複数日にまたがる resume セッション、1M級の重いコンテキスト（#65705：1,739行・3日）
・1メッセージに複数のツール呼び出し／文章の直後にツール呼び出しを置く（#66153）
・/compact 実行後の状態（#67295：compact直後の初回呼び出しで再発）
・バックグラウンドBash（run_in_background）や 3個以上のMCPサーバ接続（#64690）
・段落のように長いツール引数（#49747：JSONにXMLが混入する別変種）

要点：壊れること自体はまれな生成ゆらぎ。本当に厄介なのは②の連鎖——
だから「同じセッションで粘って再試行」は最悪手になりうる。

4. よくある3つの誤解を正す

この現象は情報が錯綜しやすい。正確に対処するために、ありがちな誤解を3つ正しておく。

よくある誤解実際は
「ツールが暴走／誤作動した」逆。壊れた呼び出しは実行されずに弾かれた（fail-closed）。誤ったコマンドが走るリスクはなく、起きたのは「空振り＋画面露出」だけ。安全側に倒れた事例。
「再試行すれば直る、放っておけば自己修復する」半分しか正しくない。軽症なら1回の再試行で戻るが、壊れたブロックが履歴に残るとモデルがそれを真似て連鎖する。#65705 は5時間超で14連続失敗、#66153 は1セッションで30回超。同セッションでの粘りは逆効果になりうる。
「court に何か特別な意味・コマンド性がある」意味はない。制御トークンが化けた“残骸”にすぎない。ただし court/call は繰り返し現れる目印なので、診断のサインとして使える。

とくに2つ目が重要だ。事象レポートでよく「再試行で正常復帰したので問題なし」と書かれるが、それは 連鎖が始まる前の“軽症”ケースに限った話。一度連鎖モードに入ると、そのセッション内では何度やり直しても直らないのがこのバグの本質である。

5. 今すぐ直す（Claude Codeユーザー向け）

対処は 「軽症のうちか、連鎖し始めたか」で分かれる。優先順に並べる。

USER FIXES

対処の優先順位

FIX 1 · 新セッションへ逃げる（最優先）
court が出たら早めに /clear または新規セッション。汚染された履歴を断ち切るのが最も確実。移る前に git commit や引継ぎメモで状態を退避。
FIX 2 · 1回だけ再試行（軽症時）
初回・単発なら 「続けて」と促すと正しく出し直すことが多い（#66153 では「再開」入力で復帰）。ただし2回続けて失敗したら粘らず FIX 1 へ。
FIX 3 · 負荷を下げる運用
長時間・複数日のセッションを避ける。1メッセージに詰め込みすぎない。/compact は直後に再発する報告があり、確実な解決ではない点に注意。

鉄則：「2回外したら、そのセッションは諦めて新セッション」。
連鎖に入った履歴で粘るほど傷が深くなる。CLIは最新版に保つ（ただし修正版は未提供＝更新は“おまじない”ではなく衛生管理）。

補足：作業状態を git や .md の引継ぎメモに小まめに退避しておけば、いつ新セッションへ移っても痛くない。長時間の自律作業を回す人ほど、この習慣が効く（コンテキストウィンドウの管理とも直結する）。

6. 開発者向け：API/SDKで防ぐ

Claude API / SDK で 自分でエージェントを組んでいる場合、ハーネス側で次の防御を入れられる。Issue #65705 が提案した検出ロジックが実用的だ。

// 受信した assistant ターンを実行前に検査する
const text = assistantText(resp);
const looksLeaked =
  /<invoke\s+name=/.test(text) ||
  /function_calls/.test(text) ||
  /\bcourt\s*<invoke/.test(text);

// 1) 構造化された tool_use ブロックが無いのに上記が混入 → 壊れた呼び出し
if (looksLeaked && !hasToolUseBlock(resp)) {
  // 2) 画面には出さずログへ。履歴に壊れたブロックを残さない（自己汚染防止）
  // 3) 「テキストではなく構造化 tool_use で出して」と促して自動リトライ
  return retryWithNudge(messages);
}

// 切断による不完全な tool_use も弾く
if (resp.stop_reason === 'max_tokens' && lastBlock(resp)?.type === 'tool_use') {
  return retryWith({ max_tokens: higher }); // 実行しない
}

原則は4つ。① stop_reason を必ず確認する（end_turn なのにツールが走っていない＝無言ストールを検知）。② 実行前に「textに <invoke name= や function_calls が混入していないか」を検証し、混入していたら実行せずリトライ。③ 壊れたブロックを会話履歴に残さない（残すと次の生成が真似て自己汚染する／#62344）。④ ツール引数は短く、長い出力は分割（#49747 の長ペイロード変種を避ける）。Claude Agent SDK など公式ハーネスを使う場合も、長時間ループの挙動は把握しておきたい。

7. 似たエラーとの見分け方

「ツールが動かない」系のエラーは複数あり、対処が異なる。混同しないよう4つを切り分ける。

症状正体主な対処
court / call + 生invokeタグが表示、実行されない本記事の主題。制御トークンの生成破損＋自己汚染で連鎖新セッション（/clear）優先・2回外したら粘らない
400「thinking blocks cannot be modified」でセッションが詰む拡張思考の署名不一致（別バグ）。API hard error専用記事参照（Esc×2/rewind）
応答が途中で切れる（XMLの化けは無い）max_tokens 到達による正常な切断。エラーではないmax_tokens を上げて再実行
BedrockやLangChain等でXMLが構造化されない第三者クライアント側がAnthropic形式を解釈できていない（langchain-aws #521）。公式API/Claude Codeでは再現しない連携ライブラリ／ホスティング側を見直す

見分けの軸はシンプルだ。「court / call という化けトークン＋生XML」が見えたら本記事のバグ。400の署名エラーなら thinkingブロックエラー。きれいに途切れているだけなら単なる出力上限。BedrockやLangChain経由でだけ起きるなら連携層の問題——という具合に切り分ける。その他のClaude Code頻出エラーは エラー集にまとめてある。

8. 公式の対応状況

2026年6月時点で、この現象を直したと明記する公式の修正（チェンジログ項目）は確認できない。Claude Code の最新版（2.1.183系）までリリースノートを追っても、ツール呼び出しのシリアライズ破損に対応したという記載はなく、関連Issueの多くは open のまま、または「duplicate／stale」として整理されている。したがって本記事の対処は すべて“公式修正待ち”の回避策（ワークアラウンド）であり、「最新版に更新すれば直る」とは断言できない点に注意してほしい（更新は推奨だが“直る保証”ではない）。

一方で、「壊れた呼び出しを推測実行せず弾く」ハーネスの fail-closed 設計そのものは正しい。直すべきはモデル側の生成安定性であって、パーサを甘くして“それっぽく直して実行”する方向は、誤コマンド実行という重大リスクを招く。私たちユーザーにできる最善は、連鎖を避ける運用と、再現したら公式Issueに環境・ログを添えて報告することだ（報告が増えるほど優先度と修正が早まる）。

9. 再発防止チェックリスト

Claude Code ユーザー：① court/call が出たら2回まで再試行、ダメなら即 /clear・新セッション。② 超長時間・複数日のセッションを避け、区切りで作業を git/メモに退避。③ 1メッセージに複数ツール呼び出しを詰め込みすぎない。④ /compact は万能ではない（直後再発あり）と心得る。⑤ CLIは最新版に保ちつつ、再現したら公式Issueへ報告。

API/SDK 開発者：① stop_reason を常時確認。② 実行前に <invoke name=／function_calls の混入を検出してリトライ。③ 壊れた呼び出しを履歴に残さない（自己汚染防止）。④ ツール引数を短く・長出力は分割。⑤ max_tokens 到達時の不完全な tool_use は実行せず再試行。

まとめ

Claude Code で 「court／call ＋ 生の <invoke> タグが表示され、ツールが実行されない」現象は、Claude（Opus 4.8／4.7系）がツール呼び出しの制御トークンを壊れた形で生成してしまうモデル側の不具合だ。ハーネスはそれを fail-closed で弾いているので、誤コマンドが走る危険はない（安全側に転んだ事例）。本当に厄介なのは、壊れたブロックが履歴に残るとモデルが真似て“連鎖”すること。だから 「再試行で直る」は軽症時だけで、2回外したら新セッションへ逃げるのが鉄則になる。

原因は ①制御トークンの生成破損 ＋ ②自己汚染による連鎖の2層。誘発条件は 長時間・複数日セッション、重いコンテキスト、/compact後、複数ツール同時、3+MCP、長いツール引数など。公式修正は2026年6月時点で未提供のため、対処はすべて回避策だ。ユーザーは 「新セッション優先＋小まめな状態退避」、開発者は 「stop_reason確認・混入検出リトライ・壊れた履歴を残さない・引数短縮」で守る。thinkingブロック400エラーや Claude Codeエラー集、MCP も併読すると、ツール呼び出し周りのトラブルに強くなれる。

FAQ

Q. 画面に出た「court」や invoke タグは、私のコマンドや設定のミスですか？
A. いいえ、ほぼ確実に違います。これは Claude 側がツール呼び出しタグを壊れた形で生成してしまうモデル側の既知の不具合で、Anthropic 公式リポジトリにも複数Issue（#64108, #65705, #66153 など）が立っています。あなたの環境・コマンド・設定のミスではありません。court/call はバグの“目印”だと捉えてください。

Q. このとき、間違ったコマンドが実行されてサーバーやファイルが壊れたりしませんか？
A. しません。壊れたツール呼び出しは「不正」と判定されて実行されずに弾かれます（fail-closed 設計）。起きるのは「そのターンが空振りして、制御テキストが画面に見える」ことだけで、データやサーバー状態への影響はありません。安全側に倒れる設計です。

Q. 「再試行すれば直る」と聞きました。本当ですか？
A. 軽症のときだけ正しいです。初回・単発なら「続けて」と促すと正しく出し直すことが多いですが、壊れたブロックが会話履歴に残ると、モデルがそれを手本にして同じ壊れ方を繰り返す（自己汚染）状態に入ります。こうなると同セッションでの再試行は逆効果。2回続けて失敗したら、粘らず新セッション（/clear）へ移ってください。

Q. /compact すれば直りますか？
A. 確実ではありません。コンテキストを圧縮すれば改善することもありますが、Issue #67295 では /compact の直後の最初のツール呼び出しで再発しています。最も確実なのは /compact ではなく 新セッション（/clear）で履歴を完全にリセットすることです。移る前に作業状態を git やメモに退避しておきましょう。

Q. Claude Code を最新版にすれば直りますか？
A. 「直る」とは断言できません。2026年6月時点で、この現象を修正したと明記する公式チェンジログ項目は確認できず、関連Issueの多くは open または duplicate のままです。更新は衛生管理として推奨しますが、“おまじない”ではありません。現状の最善は連鎖を避ける運用（2回外したら新セッション）と、再現時の公式Issueへの報告です。