PROpus court（court-loop）とは？Claude Codeで止まる原因とStopフック対策
Claude Code の Opus 4.8 court-loop を Stopフックで自動回復する（＋崩れたときだけ予防する二段構え）
基本情報
| 項目 | 内容 |
|---|---|
| 記事種別 | 編集部による実務解説 |
| 分類 | Developer |
| 情報元 | AI News Editorial / Zenn source |
| 公開日 | 2026/07/08 |
| 確認日 | 2026/07/09 |
| 読む目的 | Claude CodeのOpus 4.8で「court」などの文字列と壊れたツール呼び出し用マークアップが表示され、ツールが実行されず止まるcourt-loopについて、現象の見分け方、Stopフックによる一時回復、無限再試行を避ける条件を整理します。 |
先に押さえること
- Opus courtは製品名や設定名ではなく、ツール呼び出しが崩れるcourt-loopを探すときに使われている検索語です。
- Stopフックでできるのは応答終了後の検知と再試行の指示であり、すでに壊れた出力を画面から消すことやモデル側の不具合を直すことではありません。
- 導入するならstop_hook_activeを確認し、再試行回数に上限を設け、機密情報をログへ残さない設計が必要です。
3行要約
- 「Opus court」は正式な機能名ではなく、Claude Codeでツール呼び出しが壊れる現象を指す通称court-loopに関連して検索されている語です。
- 本文にcourt、count、callなどを含む壊れたマークアップが現れ、ツールが実行されない場合は、同系統の不具合を疑えます。
- Stopフックは応答終了後の異常を検知して再試行を促せますが、根本修正ではありません。再試行回数を制限し、失敗時は新しいセッションへ切り替えます。
実務コメント
まず会話ログに壊れたツール呼び出しの痕跡があるかを確認します。頻発する場合だけStopフックを一時的な回復策として導入し、正常な応答まで誤検知しない条件と停止上限を設定してください。
先に結論
Claude Codeでツール呼び出し用の記法が会話へ漏れ、停止と再試行を繰り返す「court-loop」と呼ばれる観測に対しては、モデルを盲目的に再実行し続けるのではなく、Stopフックで異常な出力形状を検出し、回数上限付きで回復させる設計が現実的です。導入前に、通常終了を妨げないこと、誤検知時は安全側へ倒れること、手動復旧経路が残ることを確認してください。
30秒要約
**確認日:** 2026年8月6日
- 「court-loop」は原典記事とIssueで使われる観測上の呼称であり、すべての停止ループを指す公式用語とは限りません。
- 予防は `UserPromptSubmit`、回復は `Stop` と役割を分けると、通常処理への影響を抑えられます。
- 検出条件は漏れたマークアップなど狭い特徴に限定し、再試行回数を必ず制限します。
- 自動回復できない場合は `/rewind`、新規セッション、変更差分の確認へ切り替えます。
何が起きたか
2026年7月に公開された原典記事は、Claude Codeで特定のモデルを利用した際、ツール呼び出しに関係する内部的なマークアップが通常の応答へ漏れ、停止処理と再応答が循環する現象を報告しました。記事は、常時強い制約を加えるのではなく、崩れた出力だけをStopフックで検出して回復メッセージを返す方法と、異常が起きやすい場面だけ予防する二段構えを提案しています。
今回の判断で重要なのは、出来事が報じられた日、対象となった製品・制度・運用、そして2026年8月6日時点の状態を一つの文に混ぜないことです。発表時点で正しかった条件が、現在も同じとは限りません。この記事では原典で示された出来事を起点にしながら、変更されやすい仕様、料金、募集状況、提供範囲は公式ページで再確認する前提にしています。
確定情報と観測を分ける
原典記事の体験談や担当者コメントは、導入判断に役立つ観測です。一方で、すべての環境へ再現する保証、将来の継続提供、独立した性能評価を意味しません。公式文書に書かれた仕様も、対象版や適用条件を外すと誤読につながります。
| 区分 | 確認できたこと | まだ断定しないこと | 次に確認する場所 |
|---|---|---|---|
| 公式仕様 | Claude Codeはライフサイクルの各点でフックを実行できます。 | 原典の検出正規表現が将来版でも有効であること | Claude Code Hooks文書 |
| 観測 | 公開Issueと原典記事に類似の出力崩れ報告があります。 | 全利用者・全モデルで再現すること | Issue本文と更新状況 |
| 現在状態 | フック機構は現行文書で確認できます。 | Opus 4.8固有の不具合が未修正であること | リリースノート、Issueの状態 |
この対象で押さえる3つのポイント
自動回復は「何でも再試行」にしない
Stopフックがすべての停止を異常とみなすと、利用者が意図して止めた処理や正常終了まで再開します。検出対象を、漏れたツール記法や不完全な構造など、観測した異常に限定します。
再試行上限とフェイルオープンを用意する
同じ条件で無限に回復を試す仕組みは、トークン消費と誤操作を増やします。1回または少数回で打ち切り、以後は人間へ状況を返す設計にします。フック自体が失敗した場合も、秘密情報を出力せず通常の停止を優先します。
復旧前に作業ツリーを確認する
ループ中にツールが途中まで実行されている可能性があります。再試行前に `git diff`、未追跡ファイル、実行済みコマンドを確認し、同じ変更を重ねないようにします。
影響と読者の判断
この方法は、Claude Codeを長時間の実装や自動処理に使うチームほど効果があります。ただし、フックはモデルの出力とローカル操作の間に介入するため、誤検知が開発体験や安全性へ直接影響します。導入判断は「症状を実際に観測しているか」「検出条件をテストできるか」「手動停止が残るか」で行います。
AI関連の更新を横断して確認する場合は、[AIニュース話題度レーダー](/ainews/)へ戻ると、単発の出来事を他の製品更新や導入事例と並べて確認できます。個別記事は結論を固定するものではなく、公式情報を再確認するための入口として利用してください。
Claude Codeへ長期的な指示や復旧ルールを置く場所は、[Claude Codeの長期記憶設計](/ainews/article/claude-code-memory-architecture/)で整理しています。フックに長文ルールを詰め込まず、短い検出・回復ロジックと運用文書を分離してください。
| 状況 | 判断 | 理由 | 実施前の確認 |
|---|---|---|---|
| 現象を再現できない | 導入を急がない | 不要なフックは新しい障害要因 | Issue監視とログ保存 |
| 漏れた記法が明確 | 狭い条件のStopフックを試す | 対象を限定しやすい | テストリポジトリ、再試行上限 |
| 通常停止も再開される | 直ちに無効化 | 誤検知で制御を失う | フックログ、終了コード |
| 変更が途中で残る | 自動再試行せず手動確認 | 二重実行の危険 | `git diff`、実行履歴 |
確認手順1: Stopフックを安全に検証する
1. 原典記事と公式Hooks文書を読み、Stopフックへ渡されるデータ形式を確認します。 2. 実害のないテストリポジトリを作り、正常終了、手動停止、異常出力の3ケースを用意します。 3. 異常出力にだけ一致する最小の検出条件を作ります。 4. 回復メッセージには再試行回数を示し、上限を超えたら停止させます。 5. フックの標準出力と標準エラーへ機密情報を出さないことを確認します。 6. 正常ケースを複数回実行し、処理時間と誤検知が増えていないことを確認します。
この確認では、一度に複数の条件を変えないことが重要です。変更前の状態を保存し、1項目だけ変えて同じ入力を再実行します。結果が改善しても、変更した条件との因果関係が確認できない場合は「解決」と断定せず、「再現待ち」として扱います。
確認手順2: ループ発生後に作業を回復する
1. セッションを停止し、画面とログに出た異常な記法を保存します。 2. `git status` と `git diff` で途中変更を確認します。 3. 外部サービスやデータベースへ副作用が発生していないか確認します。 4. フックによる回復を1回だけ試し、同じ出力なら自動処理を打ち切ります。 5. `/rewind` または新規セッションへ切り替え、短い文脈で再開します。 6. Issueへ報告する場合は版、モデル、再現手順を含め、秘密情報を除外します。
本番環境へ反映する前に、テスト用のデータ、リポジトリ、アカウント、テナントで同じ手順を再現してください。外部サービスへ送信される情報、保存されるログ、利用規約、料金発生条件を確認できない場合は、機密性の低い最小データに限定します。
復旧・導入で詰まったときの切り分け
回復フックが原因でClaude Codeが終了できない場合は、フック設定を一時的に退避し、通常起動へ戻します。設定を削除する前にコピーを残し、どの条件が誤検知したかをテスト入力で再現します。モデル側の一時的な出力崩れと、フックスクリプトの構文エラーを混同しないことが重要です。
切り分けの基本は、対象そのものの問題、ローカル環境の問題、アカウント・権限の問題、外部サービス側の一時的な問題を分離することです。公式ステータス、リリースノート、既知の問題を確認した後、最小構成で再現し、最後に既存環境へ戻します。削除や再インストールを最初に行うと証拠と設定を失うため、ログと設定の退避を先に行ってください。
検証結果を残すときの最小記録
再現できない成功例や、条件が分からない失敗例は、後から判断材料になりません。少なくとも次の項目を残してください。
スクリーンショットだけでなく、可能ならテキストのログも保存します。ただしAPIキー、トークン、個人情報、顧客データ、非公開コードは記録へ貼り付けず、伏字または安全な識別子へ置き換えてください。
| 記録項目 | 残す内容 | 目的 |
|---|---|---|
| 確認日時 | タイムゾーンを含む日時 | 障害・仕様変更・期限との照合 |
| 対象 | 製品名、モデル名、版、プラン、OSなど | 別条件の結果を混ぜないため |
| 入力条件 | コマンド、設定、データ範囲、権限 | 再現条件を固定するため |
| 結果 | 成功・失敗、所要時間、usage、ログ | 印象ではなく観測で比べるため |
| 根拠URL | 公式文書、原典、リリースノート | 後日の再確認を可能にするため |
| 次の判断 | 継続、保留、切り戻し、追加検証 | 調査だけで終わらせないため |
更新履歴
- 2026-08-06: 現行公開ページの主題を保持し、原典・公式情報の確認経路、判断表、確認手順、復旧時の注意点を追加しました。
参考リンク
- [原典記事](https://zenn.dev/mitna/articles/claude-code-opus48-court-loop-recovery) — 現象と二段構えの回復策を提示した記事
- [Claude Code Hooks](https://code.claude.com/docs/en/hooks) — フックイベントと設定方法の公式文書
- [Claude Code Issue #69237](https://github.com/anthropics/claude-code/issues/69237) — 関連する公開報告
- [Claude Code Issue #66153](https://github.com/anthropics/claude-code/issues/66153) — 類似症状の公開報告