Claude Opus 4.8で作業が止まる「court」問題、原因と回避策を調べてみた

「Claudeがほぼ毎ターンで court という文字列を出力して動作が止まる。
なんとかしてくれ」。
2026年6月、Claude Codeの開発元であるAnthropicのGitHubリポジトリに、こんな不具合報告が投稿されました。
ファイルを読み込もうとしても、コマンドを実行しようとしても、画面には「court」や「count」という一語だけが表示されて処理が固まる——そんな症状です。

Claude CodeやClaude Opus 4.8を業務のコーディングに使っている方は少なくないはずです。
あるいはこれから導入を検討している方もいるでしょう。
そうした方にとっては、作業が突然止まる地味だけれど厄介な不具合です。
何が起きているのか、なぜ起きるのか、今使える回避策はあるのかを調べてみました。

先に結論をまとめると：
– Claude Opus 4.8で、ツール呼び出し（ファイル編集やコマンド実行の指示）を制御するはずの内部トークンが「court」「count」という実在の単語に化けて壊れ、処理が止まる不具合が確認されています
– 原因はモデル内部のトークン生成の乱れとみられ、長時間セッションや日本語混じりの文脈で起きやすいと報告されています。
Anthropicから正式な原因究明・修正時期の発表は2026年7月22日時点で確認できませんでした
– 回避策は「セッションを初期化する」「Opus 4.7やSonnet系モデルに一時的に切り替える」の2つが有力です

Xやコミュニティで広がる報告

この不具合は、Claude Opus 4.8が2026年5月28日にリリースされた直後から報告が相次いでいます。
開発者向け技術情報共有サービスのZennには「Claude Code（Opus 4.8）で出力に court / count が混入してツール呼び出しが壊れる件」という記事が投稿されました。
同様の症状に悩まされたエンジニアたちの間で広く共有されています。

Anthropicが運営するClaude Codeの公式GitHubリポジトリにも、複数の重複した不具合報告（Issue）が積み上がっています。
あるIssueでは「The model’s tool call could not be parsed（retry also failed）」というエラーメッセージが報告されていました。
再試行しても、同じ場所で処理が止まってしまうそうです。
件名だけを見ても「Opus 4.8, long Edit-heavy session」「日本語環境で踏みやすい未修正バグ」といった言葉が並びます。
長時間の編集作業や日本語を使う開発者が、特に影響を受けやすいことがうかがえます。

ただ、こうした報告の多くは非公式なコミュニティの投稿です。
実際にどのような条件で起きるのか、Anthropic側はどう見ているのか、一次情報にあたって確かめてみました。

調べて分かったこと

なぜ「court」という単語が出てくるのか？

Claude Codeのようなツールは、AIモデルがファイル編集やコマンド実行を行う際、内部的に制御用のタグ（tool_use、invoke など）を使ってやり取りしています。
「これから〇〇というツールを呼び出す」という合図のようなものです。
本来このタグは会話の本文には表示されません。

ところが今回の不具合では、この制御タグの開始部分が「court」や「count」という普通の英単語に化けてしまいます。
そのため、システムがツール呼び出しだと認識できなくなるのです。
結果として、実行されるはずだったコマンドの内容（<invoke name="Edit">のような生のタグ）がそのまま画面に文字として表示されます。
GitHub上の不具合報告では、この現象が「トークン生成時のシリアライズ（データを特定の形式に変換する処理）不具合」ではないかと分析されています。

いつ、どんな条件で起きやすいのか?

複数の報告を突き合わせると、共通する傾向が見えてきます。
長時間・複数日にわたるセッションや、コンテキスト（AIが記憶している会話履歴）が大きく膨らんだ状態です。
/compact（履歴を要約する機能）を使った直後も要注意とされています。
複数のツールを同時に扱っている状況や、日本語・中国語などのCJK言語を多用する場面でも起きやすいようです。

さらに厄介なのは、一度この不具合が会話履歴に紛れ込むと、モデルが壊れた出力パターンをそのまま模倣し続けてしまうという点です。
一つのIssueでは、単一のセッション内で「court」という文字列が180回以上出力された例も報告されていました。
単発のエラーというより、連鎖して悪化していくタイプの不具合と言えそうです。

今すぐ使える回避策はあるのか?

複数の報告に共通していたのは、次の3つの対処法です。

1つ目は、/clearでセッションを完全に初期化することです。
壊れた履歴を引きずらないため、最も確実とされています。
2つ目は、/rewindやEscキーの2回押しで、不具合が起きる前のチェックポイントまで巻き戻す方法です。
3つ目は、モデルをOpus 4.7や別系統のモデルへ一時的に切り替えることです。
この不具合はOpus 4.8に特有の現象で、Opus 4.7には出ないとする報告が複数あり、切り替えた途端に症状が消えたという声も見られました。

なお、--continueのようなセッション再開の仕組みには注意が必要です。
壊れたやり取りごと会話履歴を読み込み直してしまい、逆効果になる可能性があります。

Anthropicは対応しているのか?

2026年7月22日時点で、Anthropicが「court問題」という名称でこの不具合を公式に認め、修正版を出したという発表は確認できませんでした。
GitHub上の関連Issueも、複数が「重複」として一本化された状態のまま、明確な解決報告は見当たりません。

一方でAnthropicの障害情報ページでは、6月以降Opus 4.8を含む複数モデルで断続的なエラー率上昇が報告されています。
7月にも同様のインシデントが記録されていました。
米メディアの取材に対しAnthropicは、需要の急拡大にインフラ増強が追いついていないことを一因として説明したと報じられています。
ただしこれは全体的なエラー率の話であり、「court」不具合そのものへの言及ではありません。
裏を返せば、この不具合はまだ個別に切り分けて公式対応されたわけではなさそうです。

Shiritomo編集部の考察：ツール障害への備えを「運用設計」に入れる

今回の一件で気になるのは、不具合そのものより「情報が公式発表ではなくコミュニティ発の報告に依存している」という構造です。
SNSやZenn・Qiitaといった技術共有の場が、実質的な障害情報の集積地になっています。
企業のSNS運用やコンテンツ制作でAIツールを日常的に使うチームほど、こうした一次情報を追う体制が必要になってきているのではないでしょうか。

実務的な備えは2つあります。
1つは、長時間セッションを避けてこまめに/clearする運用ルールを決めておくこと。
もう1つは、特定モデルへの依存を避け、切り替え可能な代替手段を事前に用意しておくことです。
AIツールの障害は、SNSでの拡散スピードの方が公式のステータスページより早いケースが多いものです。
日頃からコミュニティの声を拾う習慣が、業務停止のリスクを減らす近道になりそうです。

まとめ

Claude Opus 4.8で報告されている「court」問題は、ツール呼び出しの制御トークンが単語に化けて処理が止まる不具合です。
2026年7月22日時点で、Anthropicからの公式な原因究明・修正発表は確認できていません。
長時間セッションを避け、/clearやモデル切り替えといった回避策を知っておくことが、当面の実務上の防御策になりそうです。