目次
Claude Codeで長時間作業していると、突然応答が 「court court court court…」と同じ単語を何十〜数百回も繰り返し、最後に 「API Error: Response stalled mid-stream. The response above may be incomplete.」 と出て止まる——そんな現象に遭遇したことはないだろうか。
これはあなたのプロンプトや環境のミスではなく、2つの別々の不具合が連鎖して起きていることが多い。①モデルが同じトークンを吐き続ける反復ループ（デジェネレーション）と、②その大量出力や接続の問題でストリームが止まる「Response stalled mid-stream」だ。どちらもAnthropic公式リポジトリに複数のIssueが立つ既知の不具合である。本記事では、この2層の正体・誘発条件・今すぐの止め方・開発者向けの防ぎ方・似たエラーとの見分け方を、公式ドキュメントと実Issueに基づいて整理する。
同じトークンを延々と繰り返す反復（デジェネレーション）。出力トークンを食い潰す。
応答ストリームがデータを送らなくなり停止。「途中で途切れた」状態。
※ 片方だけ起きることもある。court暴走が大量出力を生み、ストリーム停止を誘発するケースが典型。
1. 何が起きているのか——2つの別現象が連鎖する
まず切り分けが重要だ。画面で見えるのは「courtの繰り返し」と「Response stalled mid-stream」だが、これは層が違う2つの問題だ。
- ① 「court」無限ループ：Claude（モデル本体）が、意図した応答やツール呼び出しの代わりに同じトークンを繰り返し生成し続ける反復現象。GitHub Issue #68740（Output enters an infinite loop repeating the token "court"）や #65823（固定文字列を数千回繰り返し出力トークンを使い切る）などが該当。
- ② 「Response stalled mid-stream」：応答のストリーム（逐次送信）が途中で止まる転送側のエラー。Claude Code公式のエラーリファレンスにも記載があり、Issue #70840 でも報告されている。
①が暴走すると大量の出力が生まれ、それが②のストリーム停止を誘発する——という連鎖がユーザーの画面では1つの現象に見える。だが原因も対処も別なので、分けて理解するのが早道だ。
2. 「court」無限ループの正体——反復（デジェネレーション）
「court」に意味はない。これは言語モデルが同じ出力に固着してしまう「反復（repetition／degeneration）」という古くから知られる失敗モードの一種で、たまたまその固着先が「court」というトークンになっているだけだ。別の語や記号列になることもある。
報告された特徴（#68740ほか）:
- モデルは claude-opus-4-8 など、Claude Code の VS Code拡張／CLIで発生。
- セッション途中から始まり、同一セッション内で 何度も再発する（状態依存）。
- ツール呼び出し（Editなど）の直前に日本語などの文章を生成する場面で誘発されやすい、との報告。
- 暴走すると出力トークンを大量消費し（#65823）、セッションがロックする事例も（#66950）。
ラベルは area:model（モデル挙動）が付いており、ハーネス（Claude Code）ではなくモデル側の生成の問題と位置づけられている。つまりコマンドや設定を直しても根絶はできず、「起きたら止めて逃げる」対処が基本になる。
3. 「Response stalled mid-stream」の正体——ストリーム停止
もう一方の 「API Error: Response stalled mid-stream. The response above may be incomplete.」 は、応答ストリームが途中でデータを送らなくなったときに出る転送側のエラーだ。「上の応答は不完全かもしれない」という警告どおり、そこまでにストリームされた分は失われていない——最後の数文やツール呼び出しが欠けているだけだ。
主な要因として報告・解説されているもの:
- 長い応答：複数の大きなファイルを読んで構造化レポートを生成するなど、生成が長引くと発生しやすい。court暴走による大量出力もこれに該当。
- ネットワーク/接続の不安定さ：越境接続、家庭用回線、tmuxセッション越しなどで確率が上がる。
- 読み取りタイムアウトの欠如：上流APIがパケット送信を止めたまま、クライアントが待ち続ける状態に陥るとの指摘（Issue #70840）。
なお、よく似た 「Connection closed mid-response（応答の途中で接続が閉じられた）」（#69415）は、ストリームが「止まる」のではなく「切断される」別エラーだ。症状は近いが、こちらはより接続断に寄っている。
4. 「court/invokeタグ漏れ」とは別物——見分け方
混同されやすいが、「courtが無限ループする」本記事の現象と、「courtがinvokeタグと一緒に画面に漏れる」現象は別物だ。後者は当サイトの別記事で詳説している。
| 観点 | 本記事：court無限ループ → stall | 別記事：court/invokeタグ漏れ |
|---|---|---|
| 見える症状 | 「court」を何十〜数百回繰り返す／最後にstalled | 「court」や生の<invoke>タグが数個漏れる |
| 正体 | 反復（デジェネレーション）＋ストリーム停止 | ツール呼び出しの制御タグ生成の破損 |
| ツール呼び出し | そもそも生成に固着して進まない | タグが壊れて不発になる |
| 終端 | Response stalled mid-stream／ハング | タグがテキスト表示されて停止 |
「court」がタグと一緒に漏れてツール呼び出しが不発になるタイプは、Claude Codeで「court」やinvokeタグが出力されるエラーの原因と対処を参照。原因も対処も一部異なる。
5. 誘発条件
両現象とも「必ず起きる」再現条件は特定されていないが、報告から共通して確率を上げる要因が見えている。
数時間〜複数日の連続セッション、数十万〜約100万トークンの重い文脈。状態が溜まるほど起きやすい。
Editなどの直前に日本語などの前置き文を書く場面でループに入りやすい、との報告。
越境接続・家庭用回線・tmux越しなどはストリーム停止の確率を上げる。
大きなファイルを複数読んで長文レポートを出すなど、生成が長引くタスク。
6. 今すぐ直す（ユーザー向け）
モデル側の反復は設定で根絶できないため、「素早く止めて、状態をリセットする」のが最も確実だ。優先順位は次のとおり。
- すぐ止める（Esc）：ループやハングに気づいたら Esc で生成を中断する。出力トークンの浪費を止められる。
- 新しいセッションに逃げる：状態依存の不具合なので、新規セッションを開始すると解消することが多い。同一セッションでの再試行は再発しやすい。
/clearで文脈をリセット：セッションを続けたい場合は文脈をクリアして状態を軽くする（/compactは状態を引き継ぐため解消は不確実）。- ツール呼び出しは前置きなしで：Editなどの直前に長い文章を書かせず、前置きゼロでツールを呼ぶ指示にするとループを避けやすい、との報告がある。
- タスクを短いセッションに分割：1タスク＝1セッションにして生成時間と文脈を短く保つと、反復もストリーム停止も起きにくい。
- 接続を安定させる：stalledが頻発するなら、回線やプロキシ経路の安定性を見直す。ストリーム済みの内容は残っているので、続きから指示し直せばよい。
✅ ポイント：「2回外したら粘らず新セッションへ」。同じ壊れた状態のまま再試行すると、モデルが直前の反復を真似て再発しやすい。
7. 開発者向け——API/SDKで防ぐ
Messages APIやSDKで自前実装している場合、次の対策で被害を抑えられる。
- ストリーミングに読み取りタイムアウトを設定：一定時間パケットが来なければ打ち切って再試行する。無限待ちを避ける（stalledの根因対策）。
- 反復検出のガード：直近の出力で同一トークン／短い文字列が異常回数繰り返されたら生成を打ち切る。出力トークンの暴走消費を防ぐ。
- 不完全応答のリトライ：
stop_reasonを確認し、途中終了なら壊れた出力を履歴に残さずやり直す（壊れた履歴は次ターンの反復を誘発する）。 - max_tokensの上限設定：万一暴走しても課金と時間の上限を切れるようにしておく。
- ツール引数・前置きを短く：長い引数や長文の前置きは誘発条件になりうる。
8. 似たエラーとの見分け方
| 症状/メッセージ | 正体 | 主な対処 |
|---|---|---|
| court を何十回も繰り返す → stalled | 反復ループ＋ストリーム停止（本記事） | Escで停止→新セッション/clear |
| court や生の invoke タグが数個漏れる | ツール呼び出しタグの生成破損（別記事） | 2回外したら新セッション |
| Connection closed mid-response | ストリームが「切断」される（#69415） | 接続見直し・リトライ |
| Prompt is too long | 入力がコンテキスト上限超過 | 文脈削減・/clear |
| usage limit / 429 | 使用量・レート上限 | 時間を空ける・プラン確認 |
| Output blocked by content filtering policy | 出力側の安全フィルタ（別記事） | 逐語コピーを避ける言い換え |
9. 公式の対応状況
2026年7月時点の状況を、確度を明示して整理する。
- ✅ 既知の不具合として認識：court反復・stalled ともにAnthropic公式リポジトリに複数のIssueが立ち、court反復には
area:model・bugラベルが付いている。 - 🟡 恒久修正は未確認：本稿執筆時点で「これで直った」と断定できる公式修正は確認できていない。バージョン更新で改善する可能性はあるため、Claude Codeは最新版に保つとよい。
- 🟡 原因は状態・環境依存：長時間・大コンテキスト・接続品質など複数要因が絡み、単一の再現手順は特定されていない。
※ 状況は変わりうる。最新は Claude Code の Issue 一覧 と 公式エラーリファレンス を確認してほしい。
FAQ
Q1. 「court」って何か意味がありますか？
ありません。言語モデルが同じ出力に固着する「反復（デジェネレーション）」で、たまたま固着先が「court」というトークンになっているだけです。別の語や記号列になることもあります。あなたのプロンプトやデータの問題ではありません。
Q2. 「Response stalled mid-stream」が出たら、途中までの出力は消えますか？
消えません。メッセージどおり「上の応答は不完全かもしれない」だけで、そこまでにストリームされた内容は残っています。最後の数文やツール呼び出しが欠けている可能性があるので、続きから指示し直せばOKです。
Q3. 再試行すればすぐ直りますか？
軽症なら直ることもありますが、同じセッションでの再試行は再発しやすいです。モデルが直前の壊れた出力（反復）を真似てしまうためです。2回外したら粘らず新しいセッションに切り替えるのが確実です。
Q4. /compact すれば直りますか？
不確実です。/compact は文脈を要約して状態を引き継ぐため、反復の原因が残ることがあります。状態をリセットしたいなら /clear か新セッションのほうが確実です。
Q5. これは記事にある「court/invokeタグ漏れ」と同じ不具合ですか？
関連はしますが別物です。本記事は「courtが無限ループして最後にstalledで止まる」反復＋ストリーム停止型。タグ漏れ型は「courtや生のinvokeタグが数個漏れてツール呼び出しが不発になる」もので、詳しくは別記事を参照してください。
Q6. 開発者として根本的に防ぐには？
ストリーミングに読み取りタイムアウトを設定し、反復検出で異常な繰り返しを打ち切り、途中終了時は壊れた出力を履歴に残さずリトライする——の3点が効果的です。max_tokensの上限も課金と時間の暴走を防ぎます。
Q7. どんな時に起きやすい？
長時間・複数日の連続セッション、数十万〜約100万トークンの重い文脈、ツール呼び出し直前の長い文章生成、越境・家庭用回線・tmux越しの不安定な接続、長文出力タスク——などで確率が上がります。1タスク＝1セッションで短く保つのが予防になります。
関連記事
- Claude Codeで「court」やinvokeタグが出力されるエラー — タグ漏れ型（本記事と別物）
- Output blocked by content filtering policy の原因と対処 — 出力側フィルタのエラー
- Claude Codeの /loop コマンドとは — 反復実行の正しい使い方
