Claude Codeのcourt連続問題を安全に復旧する手順

「原因は分かりました。修正します」そう言った次の瞬間、Claude Codeの画面に表示されたのはコード差分でもテスト結果でもなかった。 court <invoke name="Read"> <parameter name="file_path">...</parameter> </invoke> そして、何も実行されない。最近のClaude Code、とりわけOpus 4.8を長時間使っていると、こうした謎の文字列に遭遇することがある。環境によって表示される単語は court、count、call など微妙に異なる。検索時に「courseが連続する問題」と表現されることもあるが、この記事ではまとめて「court問題」と呼ぶことにする。 Anthropicは2026年5月28日にOpus 4.8を公開し、複雑なコーディングやエージェントタスクに強いモデルとして紹介した。ところが、その直後からClaude CodeのGitHubには、Opus 4.8がツール呼び出しを壊れたテキストとして出力する報告が複数投稿されている。高性能モデルを使っているはずなのに、ファイルすらまともに読めない。しかも一度発生すると、こちらが「続けて」「再開して」と入力しても、また court。もう一度頼んでも court。何度やっても同じところで止まる。利用者からすれば、感想は一つしかない。最近のClaude Code、バカになってないか。ただし、この症状を正しく直すには、「Claudeの推論力が落ちた」と考えるだけでは不十分だ。ここで壊れているのは、コードを考える能力そのものではない。考えた操作をClaude Codeへ渡すための、ツール呼び出しの形式が壊れている。この違いを理解すると、効かない対処と、効きやすい対処が見えてくる。なお、セットアップやガチの活用術はPDFにまとめてます。欲しい人は、この👇から受け取れるようにしてます！ https://docs.google.com/document/d/1LRXiSARp2K9ffNoUlXIRSaKLyl3-GXB1muzz2G8-5e8/edit?tab=t.0 「court」はClaudeの返事ではなく、壊れたツール呼び出しである Claude Codeは、普通のチャットAIとは少し違う。 Claudeが文章でコードを提案するだけでなく、ファイルを読み、文字列を検索し、コードを編集し、シェルコマンドを実行する。内部では、おおまかに次の流れが動いている。 Claudeが「このファイルを読む必要がある」と判断する Readツールを構造化された形式で呼び出す Claude Code側がファイルを読む読み取った内容をツール結果としてClaudeへ返す Claudeが結果を見て、次の操作を考える正常な場合、利用者が内部形式を意識する必要はない。画面上には「Read」「Edit」「Bash」などのツール実行として表示され、実際にファイルが読み込まれたり、コマンドが走ったりする。ところがcourt問題が発生すると、内部で使われるはずのツール呼び出しが、通常の文章として漏れ出してくる。 court <invoke name="Bash"> <parameter name="command">npm test</parameter> </invoke> 見た目だけなら、Claudeが npm test を実行しようとしているように見える。しかし、これは正規のツール呼び出しとして認識されていない。ただのテキストだ。そのため、実際にはテストが走っていない。ファイルの読み取りも行われていない。EditやWriteなら、コードも変更されていない。公開Issueでも、余計な court や count がツール呼び出しの直前に混ざり、本来の名前空間が欠落した <invoke> がプレーンテキストとして表示され、操作が実行されない症状が報告されている。ここで、絶対に覚えておかなければならない原則がある。ツール結果が返っていないなら、その操作は実行されていない。 Claudeがその後に「修正が完了しました」と書いても関係ない。「テストはすべて通りました」と言っていても、Bashの実行結果が表示されていなければ信用してはいけない。「コミットしました」と言っていても、Gitの状態を確認するまでは未確認である。 AIコーディングでは、Claudeの文章ではなく、観測できる状態を正とする。 git status --short git diff --stat git diff git log -1 --oneline テストについても同じだ。 npm test pytest cargo test Claudeが「やった」と言ったかどうかではない。ファイルが変わっているか。コマンドが実行されたか。テスト結果が存在するか。見るべきなのは、そこだけである。本当に厄介なのは、一度ではなく連続すること単発でツール呼び出しに失敗するだけなら、まだ大きな問題ではない。同じ操作をもう一度頼めば済む。 court問題の厄介なところは、一度発生したあとに連続しやすいことだ。実際、公開されている報告の中には、最初の失敗をきっかけに、その後のツール呼び出しも連続して壊れるという記述がある。長時間継続したセッション、大きなコンテキスト、何度も再開された会話、MCPを含む多数のツール呼び出しなどが発生時の環境として挙げられている。なぜ連続するのか。 Anthropicから、この症状に関する完全な原因説明が出ているわけではないため、内部原因を断定することはできない。ただ、運用上は次のように考えると分かりやすい。最初のツール呼び出しが壊れる。すると、その壊れた <invoke> の文字列が会話履歴へ残る。次の応答を生成するとき、Claudeはその履歴も読んでいる。直前の失敗した形式に引っ張られ、次のツール呼び出しも似た形で出力する。さらに会話が長くなり、古い調査結果、テストログ、スクリーンショット、MCPの出力、訂正のやり取りなどが積み重なっていると、正常なツール呼び出しを生成するための文脈が相対的に弱くなる。これは公開報告とLLMの文脈依存性から立てられる実務上の仮説であり、公式に確定した原因ではない。しかし、復旧方法を考えるうえでは十分に役立つ。つまり、一度壊れたセッションで延々と再試行するよりも、失敗した履歴を切る。正常だった地点まで戻る。新しい会話へ必要な情報だけ移す。この三つが重要になる。最初にやるべきことは、Claudeを叱ることではない court問題が起きると、つい長いメッセージを送りたくなる。また止まっています。なぜ同じ失敗を繰り返しているのですか。原因を分析し、今度こそ確実に実行してください。実行前に何をするか説明し、終わったら詳細に報告してください。気持ちは分かる。だが、この指示はcourt問題に対しては逆効果になりやすい。長い原因説明、謝罪、作業計画を書かせたあと、再びツール呼び出しへ移行させるからだ。そもそも壊れているのは「何をすべきか分からない」部分ではない。 ClaudeはReadを使うべきことも、Bashを使うべきことも分かっている。壊れているのは、それをClaude Codeへ渡す形式だ。必要なのは説教でも反省文でもない。出力の形を単純にすることである。最初の一回は、次の一文だけを送る。説明・謝罪・要約は不要。直前に失敗したツール呼び出しだけを、本文なしで一度だけ再実行してください。さらに短くしてもよい。本文なし。直前のツールだけ再実行。ここでは、新しい要件を追加しない。「ついでに別のファイルも調べて」は書かない。「原因も報告して」は書かない。「全体を見直して」は書かない。目的はClaudeへ深く考えさせることではなく、次の出力を可能な限り単純なツール呼び出しから始めさせることだ。ただし、再試行は一回だけにする。一回目で正常に実行されたら、すぐにGitやテストで状態を確認する。二回目も court になったら、そこで止める。三回、四回、五回と「続けて」を送るほど、壊れた履歴と未確認の完了報告が増えていく。まずClaude Code自体を更新しておく復旧作業へ入る前に、Claude Codeが古いままになっていないかも確認したい。 claude update その後、Claude Code内で診断を実行する。 /doctor 公式のエラーリファレンスでは、Opus 4.7またはOpus 4.8を使っている場合、古いClaude Codeでツール利用履歴の不整合が発生することがあり、少なくともv2.1.156より前のバージョンでは正常なツール利用中にも問題が起き得るため、最初に更新するよう案内されている。これはcourt問題と完全に同一のエラーとは限らないが、古いCLIを使い続ける理由はない。 /doctor はインストール状態、設定ファイル、使われていないMCPやスキル、重いhooks、新しいバージョンの有無などを診断する。ただし、更新すれば壊れた会話履歴まで自動的に直るわけではない。すでにcourt問題が連続しているなら、次の /rewind が本命になる。二回目も失敗したら、/rewind で壊れたターンを切る Claude Codeにはチェックポイント機能がある。入力欄が空の状態でEscを二回押すか、次のコマンドを実行する。 /rewind すると、それまでに送ったプロンプトが一覧表示され、以前の地点へ戻せる。現在のClaude Codeでは、次のような操作を選べる。コードと会話の両方を戻す会話だけを戻し、現在のコードは残すコードだけを戻し、会話は残す選択地点より後ろだけを要約する選択地点より前だけを要約するこれらは公式のチェックポイント機能として提供されている。 court問題で基本的に選ぶのは、最初に壊れたターンの直前である。正常な編集がすでに行われているなら、「会話だけを復元」を選ぶ。これなら、それまでのコード変更を残したまま、壊れた <invoke> を会話履歴から除去できる。一方、Claudeが誤ったコード変更も行っている場合は、「コードと会話の両方を復元する」を選ぶ。重要なのは、何となく最初まで戻ることではない。正常な最後の地点まで戻ることだ。なお、Claude CodeのチェックポイントはGitとは別物であり、すべての副作用を戻せるわけではない。特にBashツール経由の変更、データベース操作、外部API、デプロイなどは、ファイル編集用のチェックポイントだけでは復元できない場合がある。公式ドキュメントでも、チェックポイントはBashツールによる変更や外部システムへの作用を追跡しないと説明されている。だからこそ、Gitとテストが必要になる。チェックポイントを過信せず、外部状態は必ず個別に確認する。戻ったあとは、作業を極端に小さくする /rewind で正常地点へ戻ったあと、元と同じ巨大な依頼をそのまま送り直してはいけない。例えば、元の依頼がこれだったとする。認証機能全体を調査して原因を特定し、関連ファイルを修正し、テストを追加し、既存テストもすべて実行して、ドキュメントを更新してコミットしてください。これでは、調査、読み取り、編集、テスト、ドキュメント、Git操作が一つの長いエージェントループに詰め込まれている。途中でツール呼び出しが壊れたとき、どこまで完了したのか分からなくなる。戻ったあとは、次のように分割する。 src/auth/session.ts だけ読んで。正常に読めたら、次へ進む。今回のエラーにつながる条件を一つだけ特定して。原因が確認できたら、編集する。その条件だけを直す最小修正を入れて。編集後、対象テストだけを実行する。今回の変更に直接関係するテストだけ実行して。最後にdiffを見る。変更差分を確認し、意図しない変更がないかだけレビューして。タスクを小さくするのは、Claudeの能力を下げるためではない。一回のツール呼び出しに含まれる構造を単純にし、失敗した場所を特定しやすくするためだ。一つ読む。一つ直す。一つテストする。この粒度なら、どこかで再発しても被害範囲が小さい。 /compact を連打する前に、/context all を見る会話が長くなっているなら、まず何がコンテキストを占有しているか確認する。 /context all /context は現在のコンテキスト使用量を表示し、ツール、メモリ、指示ファイルなど、何が容量を使っているかを可視化する。 all を付けると、より詳しい内訳が表示される。そこで巨大なログ、長大なCLAUDE.md、大量のMCPツール、過去の探索、不要なスクリーンショットなどが見つかったら、次に圧縮を検討する。 /compact ただし、何も指定せず圧縮するより、残す情報を明示したほうがよい。 /compact 最終目的、確定済みの仕様、変更済みファイル、実行済みテストと結果、未完了作業、次の最小作業だけを残す。失敗した生の<invoke>出力は要約へ再掲しない。 /compact は会話全体を要約してコンテキストを空けるコマンドで、任意の焦点指示を追加できる。さらに、court問題では全体圧縮よりも、/rewind メニューから行える部分要約のほうが使いやすいことがある。例えば、古い調査だけを要約し、直近の実装内容はそのまま残す。あるいは、court問題が始まった地点から後ろだけを要約し、壊れた生テキストを圧縮する。会話全体を一気に混ぜるのではなく、不要な区間だけ切るという発想だ。二回以上訂正しているなら、会話を捨てたほうが早い「あと少しで終わるから、このセッションを何とか救いたい」そう考えて、同じ会話を使い続けてしまうことがある。しかし、訂正、謝罪、再試行、追加説明、失敗したツール呼び出しが積み重なったセッションは、それ自体がノイズになっている。 AnthropicのClaude Codeベストプラクティスでも、同じ問題について二回以上Claudeを訂正している場合、失敗した試行でコンテキストが散らかっているため、/clear で新しく始めることが推奨されている。新しい会話を始めるには、次を使う。 /clear court-recovery /clear は空のコンテキストで新しい会話を開始する。引数に名前を付けると、以前の会話がその名前で保存され、後から /resume で確認できる。ただし、ここで注意したい。壊れた会話をそのまま /resume して作業を続けたら、当然ながら壊れた履歴も戻ってくる。以前の会話は証跡として残す。新しい会話には、正常だと確認できた情報だけを持ち込む。会話全体を救出するのではなく、事実だけを救出する。新しいセッションへ渡す「引き継ぎ文」の作り方新しいセッションへ移る前に、現在の状況を引き継ぎ文へまとめる。このとき、Claudeへファイル保存を頼むと、Writeツールでcourt問題が再発する可能性がある。まずはツールを禁止し、通常のMarkdownとして表示させる。そのまま使えるプロンプトがこちらだ。ここから先はツールを一切使わないでください。新しいClaude Codeセッションへ貼るための引き継ぎ文を、通常のMarkdown本文だけで作成してください。必ず含めるもの: - 最終目的 - 確定済みの仕様 - 実際に変更済みと確認できたファイル - 実行済みと確認できたコマンド - 確認済みのテスト結果 - 未完了の作業 - 次に行う最小の一手 - 触ってはいけない範囲 - 未解決の疑問 - court/count/call発生後で、未実行の可能性がある操作確認済みの事実と推測を明確に分けてください。生の<invoke>タグは再掲しないでください。出てきた引き継ぎ文を、そのまま信用してはいけない。「変更済み」と書かれたファイルを git diff で確認する。「テスト成功」と書かれているなら、実際のテスト出力が存在するか確認する。「コミット済み」と書かれているなら、git log を見る。怪しいものはすべて「未確認」に変更する。そのうえで /clear し、新しいセッションへ貼り付ける。新セッションで最初に頼むのは、実装の続きではなく現状確認だ。この引き継ぎを前提に、まずgit statusと差分を確認してください。まだ編集はしないでください。これで、壊れた会話の癖を持ち込まず、リポジトリの実体から再開できる。 Opus 4.8に固執せず、モデルを切り替える court問題が特定のモデルで繰り返すなら、一時的に別モデルへ切り替えるのも手だ。 Claude Codeでは次のコマンドでモデルを変更できる。 /model またはモデル名を指定する。 /model sonnet /model は現在のセッションで使用するモデルを切り替える公式コマンドである。ただし、モデルを切り替えれば必ず直るわけではない。これは恒久的な修正ではなく、回避策だ。実務では、役割を分けると使いやすい。 Opusには、要件整理、設計、難しいバグの仮説、diffレビューなど、推論の比重が大きい作業を担当させる。別モデルには、対象ファイルの読み取り、限定的な編集、テスト実行など、ツール利用の比重が大きい作業を担当させる。大切なのは、「一番賢いモデルを最初から最後まで使う」ことではない。現在の作業を、最も安定して完了できる構成にすることだ。また、壊れた長いセッションの途中でモデルだけ切り替えるより、新しいセッションでモデルを変え、検証済みの引き継ぎ文から始めたほうが安全である。 CLAUDE.mdへ短い実行契約を書く同じ問題を繰り返すなら、プロジェクトの CLAUDE.md に運用ルールを書いておくとよい。ただし、数百行の巨大なルール集にしてはいけない。常に読み込ませる指示が大きすぎれば、それ自体がコンテキストを圧迫する。必要なのは、短く検証可能なルールだけだ。 ## Tool execution contract - ツールを使う場合、最初のツール直前に長い説明を書かない。 - tool resultを受け取るまで、編集・実行・テスト成功を断言しない。 - malformed tool callは、説明なしで一度だけ再試行する。 - 二度失敗したら追加ツールを止め、Markdownの引き継ぎを出す。 - 完了報告では、変更ファイル、実行コマンド、確認結果を分ける。 ## Compact instructions 圧縮時に保持する: 目的、確定仕様、変更済みファイル、テスト結果、未解決事項、次の最小作業、禁止事項。失敗した生の<invoke>出力は再掲しない。このルールでcourt問題そのものを修正できるわけではない。しかし、発生したあとにClaudeが未実行の操作を「完了済み」と扱ったり、説明と再試行を延々と繰り返したりするリスクは下げられる。上級者向け：Stop hookで一度だけ自動再試行する毎回 court を目視して再試行するのが面倒なら、Claude Codeのhooksを使って検知を補助できる。 Claude CodeのStop hookには、最後の応答本文である last_assistant_message と、すでにStop hookによって継続中かを示す stop_hook_active が渡される。また、additionalContext を返すと、Claudeへ追加指示を与え、会話を続行できる。例えば、プロジェクト内に次のファイルを作る。 .claude/hooks/court_guard.py #!/usr/bin/env python3 import json import re import sys BAD_TOOL_CALL = re.compile( r"(?is)(?:^|\n)\s*(?:court|count|call)\s*" r"\n\s*<invoke\b.*?<parameter\b" ) def main() -> None: try: data = json.load(sys.stdin) except Exception: # hook自身の失敗で通常のClaude Codeを止めない return if data.get("hook_event_name") != "Stop": return # 自動再試行による二周目なら、さらに継続させない if data.get("stop_hook_active", False): return message = str(data.get("last_assistant_message") or "") if not BAD_TOOL_CALL.search(message): return output = { "hookSpecificOutput": { "hookEventName": "Stop", "additionalContext": ( "壊れたツール呼び出しを検出しました。" "説明・謝罪・要約を書かず、直前に意図していた" "構造化ツール呼び出しだけを一度再実行してください。" "再構成に確信がない場合は、ツールを使わず停止してください。" ), } } print(json.dumps(output, ensure_ascii=False)) if __name__ == "__main__": main() 次に、プロジェクトの .claude/settings.json へStop hookを追加する。既存の設定がある場合は、内容を消さずにマージする。 { "hooks": { "Stop": [ { "hooks": [ { "type": "command", "command": "python3", "args": [ "${CLAUDE_PROJECT_DIR}/.claude/hooks/court_guard.py" ] } ] } ] } } このhookは、最後の応答に court、count、call のいずれかと、生の <invoke>／<parameter> が同時に現れた場合だけ、再実行を促す。 stop_hook_active が真の場合は何もしないので、自動再試行は一回で終わる。 Claude Codeの公式仕様でも、Stop hookによる継続時には stop_hook_active を確認し、終わらないループを避けるよう案内されている。ただし、これはあくまで補助策だ。エラーの発生経路によってはStop hookまで到達せず、検知できない可能性もある。また、説明文やログの中にたまたま同じ文字列が含まれていると誤検知することもある。自分の環境に合わせて正規表現を調整し、最初は小さなテスト用プロジェクトで確認したほうがよい。なお、command hookはユーザー権限でシェルコマンドを実行する。公式ドキュメントも、入力の検証、絶対パスの使用、機密ファイルの回避などを求めている。内容を理解していないhookをそのまま導入してはいけない。設定が読み込まれているかは、次で確認できる。 /hooks 問題がある場合は、次を使う。 /doctor /debug court guard 再発を減らすには、セッションの使い方を変える court問題の根本修正はAnthropic側の領域だ。しかし、発生したときの被害は、こちらの運用でかなり変えられる。最も効果が大きいのは、Claude Codeを「永遠に続く一つの会話」として使わないことだ。一つのセッションで、要件整理、調査、設計、実装、テスト、デバッグ、レビュー、コミット、PR作成まで全部やらせると、履歴は急速に膨らむ。途中で一度失敗すると、その失敗を説明する会話まで追加される。さらに訂正する。また失敗する。気づけば、現在のコードよりも、失敗の歴史のほうが長くなっている。作業を次のように区切る。調査セッションコードを読み、原因候補を整理する。この段階では編集しない。計画セッション変更対象、受け入れ条件、テスト方法、触らない範囲を決める。結果はIssue、設計文書、Markdownなどへ固定する。実装セッション一つの受け入れ条件ごとに、小さく編集する。変更直後に対象テストを実行する。レビューセッション新しいコンテキスト、または別モデルでGit diffを確認する。実装時の思い込みを引き継がない状態でレビューする。各段階の境界では、Gitを確認する。 git status --short git diff --stat まとまった地点ではコミットする。 git add -A git commit -m "Fix session validation condition" Claudeの会話は壊れる。圧縮で細部が消える。誤った要約が混ざる。しかし、Gitのコミットとテスト結果は残る。本当のチェックポイントは会話ではなく、リポジトリの状態である。 court問題が起きたときに、やってはいけないことまず、同じセッションで「続けて」を何度も送らない。一回だけ再試行し、二回目も失敗したら履歴を切る。次に、Claudeの謝罪を確認結果として扱わない。申し訳ありません。今度は正しく実行しました。この文章には何の証拠もない。ツール結果、Git、ファイル、テストを見る。また、生の <invoke> の中に表示されたコマンドを、内容を理解しないまま自分のターミナルへ貼り付けてはいけない。 Claude Codeの権限確認やサンドボックスを飛び越え、削除、デプロイ、データ変更などを直接実行してしまう危険がある。壊れた会話を再開し、「新しいセッションにした」と考えるのも避ける。以前の会話をresumeすれば、その履歴も戻る。証跡として読むのはよいが、復旧先としては空のコンテキストを使う。そして、court問題を防ぐために巨大なCLAUDE.mdや複雑すぎるhookを追加しない。予防策そのものがコンテキストや実行経路を重くしたら、本末転倒である。迷ったら、この順番で復旧すればいい最後に、court問題が発生したときの流れをまとめる。 1．一回目の発生次だけ送る。本文なし。直前のツールだけ再実行。 2．正常に動いた場合 Gitとテストで実行状態を確認する。 git status --short git diff --stat 3．二回目も失敗した場合再試行を止める。 /rewind 最初の失敗直前へ戻る。正常なコード変更を残したい場合は、会話だけを復元する。 4．コンテキストが重い場合 /context all 不要な履歴を部分要約する。必要なら焦点付きで圧縮する。 /compact 目的、変更済みファイル、確認済みテスト、未完了作業、次の一手だけを残す。 5．再発した場合ツール禁止で引き継ぎ文を作る。人間がGitとテストで内容を確認する。 6．新しい会話へ移る /clear court-recovery 検証済みの引き継ぎ文だけを貼る。 7．それでも再発する場合 /model 別モデルへ切り替える。必要ならStop hookを導入する。 8．最後に不具合報告を送る Claude Codeには、セッション情報を添えて不具合を報告するコマンドがある。 /bug Opus 4.8でcourtと生のinvokeタグが連続し、ツールが実行されないまたは、 /feedback /bug では共有する履歴の範囲を選び、送信前に確認できる。報告には、次の情報を入れるとよい。使用モデル Claude Codeのバージョン OS 発生直前に頼んだ作業使用していたツール MCPの有無セッションの長さ /compact やresumeの有無表示された court／count／call 生の <invoke> の内容一回で終わったか、連続したかモデル側の問題は、利用者がプロンプトだけで完全に修理することはできない。だからこそ、再現情報を残す意味がある。おわりに――救うべきなのは会話ではなく、開発状態である Opus 4.8でcourt問題が起きたとき、「自分の指示が悪かったのか」と考えすぎる必要はない。公開Issueを見る限り、同種の壊れたツール呼び出しは複数の利用者から報告されている。 Claudeが急にコードを理解できなくなったというより、理解した操作を実行基盤へ渡すところで形式が壊れている。だから、丁寧な説明を追加すれば直るとは限らない。むしろ、長い謝罪や原因分析を挟まず、ツールだけを一度再試行する。二回失敗したら /rewind する。壊れた履歴を切る。必要なら /clear し、検証済みの引き継ぎだけを新しいセッションへ移す。そして、Claudeが何を言ったかではなく、Gitとテストを見る。 Claude Codeが壊れたとき、会話を救おうとして会話だけを見続けると抜けられない。救うべきものは会話ではない。現在の開発状態だ。仕様は文書へ残す。変更はGitへ残す。正しさはテストへ残す。未完了作業は引き継ぎへ残す。会話は、それらを操作するための一時的な作業面にすぎない。そう考えれば、Opus 4.8がまた突然 court と言い始めても、こちらの開発まで法廷送りにされずに済む。

Claude Codeのcourt連続問題を安全に復旧する手順

AIFCC — AI Fluent CxO Club