--- category: AIとの付き合い方 date: 2026-07-22 description: Claude CodeのOpus 4.8で起きる「court」問題を、自分の作業ログ2,315件で調べました。画面に見える故障より、エラーが出ないまま「できました」と嘘をつく故障のほうが怖い、という話です。 draft: false henso: false slug: opus48-court title: Opus 4.8の「court」問題 ── 本当に怖いのは、エラーが出ない故障でした --- ## こんな記事を見ました Claude Code——AIにコードを書かせたり、ファイルを触らせたりする道具——を長く使っていると、画面に脈絡なく `court` という短い単語が出て、そのあとAIが何も実行しなくなることがあります。 この症状を丁寧に解説した記事を読みました。 > [最近のClaude Codeがバカな件｜Opus 4.8で「court」が連続する問題を解決する方法](https://x.com/ai_ai_ailover/status/2079480963575251125) 曰く、`court` はAIの返事ではない。AIが「このファイルを読む」「このコマンドを実行する」と決めて道具に指示を渡すとき、その指示の形式が壊れて、ただの文字として画面に漏れ出したものだ、と。 だから、実際にはファイルは読まれていません。テストも走っていません。AIがそのあと「修正しました」と書いても、それは実行されていない。 ## 僕にも、覚えがあります これは、まさに僕が困っていたことでした。 Opus 4.8という賢いはずのモデルを長く使っていると、ある時点から `court` が出はじめます。「続けて」と打っても、また `court`。もう一度頼んでも `court`。同じ場所で止まる。 賢いモデルを使っているのに、ファイル一つまともに読めません。正直、「最近のこれ、バカになったんじゃないか」と思いました。 記事の言うことは腑に落ちました。でも、腑に落ちたからこそ、確かめたくなりました。本当にそうなのか。自分の環境ではどう起きているのか。 ## だから、自分のログを調べました Claude Codeは、[やりとりを全部ログに残しています](https://aika-keiei.com/articles/jsonl-genten/)。僕の手元には、直近1か月ぶんで **2,315件** の作業記録がありました。これを、人の目ではなく機械で数えました（2026年7月22日時点）。 数え方には気をつけました。`court` という文字は、AIの思考の途中や、読み込んだファイルの中身や、この不具合を話題にした会話にも当然出てきます。それを全部数えたら、意味のない数字になってしまいます。 だから、**「画面に、脈絡なく、出す必要がないのに出てきた `court`」だけ** を数えました。結果ははっきりしていました（詳しくは後半に書きます）。 ## 元記事が言っていること——そして、それは正しい 調べてわかったのは、まず、元記事の核心が正しいということでした。 `court` は、壊れた指示が漏れたものです。そして、そこから導かれる一番大事な原則があります。 > 道具の実行結果が返っていないなら、その操作は行われていない。 AIが「完了しました」「テストは全部通りました」「コミットしました」と書いても、それ自体は何の証拠でもありません。ファイルが実際に変わったか。コマンドが本当に走ったか。見るべきなのは、そこだけです。 元記事は、ここをかなり強く書いています。謝罪の言葉は確認結果ではない。「コミットしました」と言われても、Gitの状態を見るまでは未確認である、と。**AIの完了報告を信じるな、という話は、元記事がすでに繰り返し書いていることです。** 原因についても慎重でした。長い会話に壊れた出力が残り、それに引っ張られて連続するのだろう、という見立てを示しつつ、**「これは実務上の仮説であり、公式に確定した原因ではない」と自分で断っています。** そのうえで、一度だけやり直させる、それでも直らなければ会話を巻き戻す、ダメなら会話をまるごと捨てる、最後にモデルを切り替える——という順番で対処を並べていました。 読んで、その通りだと思いました。 ## でも、僕が困っていたのは、少し違う場所でした 自分のログを見ているうちに、気づいたことがあります。 `court` が **画面に見える** のは、実はまだ親切な壊れ方なのです。おかしいと目でわかる。だから止められる。 元記事も「完了報告を信じるな」と書いています。そこは同じです。**ただ、元記事が想定しているのは、`court` という異常が画面に出た"あと"の話です。** 異常が見えているから、疑うきっかけがある。 僕の環境で起きていたのは、それとは別でした。**`court` が一度も出ていないのに、報告だけが嘘なのです。** - ファイルを作ったと報告してきました。行数まで添えて。**実際には、そのファイルは作られていませんでした。** - テストが全部通ったと報告してきました。**実際には、テストは一度も動いていませんでした。** - コマンドの実行結果を見せて「環境が壊れているので確認できません」と、確認作業から降りました。**その実行結果自体が、作り物でした。** あとでログを開いて分かったのですが、**そもそもツール呼び出しの記録が一件も残っていませんでした。** 壊れた指示が漏れたのではありません。指示を出そうとすらせず、報告の文章だけを書いていた。 画面には、何の異常も出ません。`court` のような、目に見える印がない。**疑うきっかけそのものがない**のです。 賢いAIに任せるとき、一番怖いのは、エラーが出て止まることではありません。エラーが出ないまま、間違ったことを「できました」と言って進むことです。 ![見える故障と見えない故障の対比。見える故障は画面にcourtと出て道具が動かず気づけるが、見えない故障は画面が正常に見えて「できました」と報告され、実際には動いておらず気づけない](画像/opus48-court/slide1-two-failures.png) ## 今、僕がやっていること では、どうしているか。**モデルを替えています。** これは元記事も挙げている方法です。ただ、元記事では7番目、最後の手段として置かれていました。**僕の実測では、これが最初にやるべきことでした。** 自分のログを数えて、はっきりしたことがあります。あの脈絡ない `court` を含む異常な出力は、1,000行を超えていて、**そのすべてが同じモデル（Opus 4.8）から出ていました**。ほかのモデルは、何百回と動いても、ほとんど一度も出しませんでした。 もっと決定的な場面もありました。ある作業で、Opus 4.8が `court` を連発したので、途中で別のモデルに切り替えました。切り替えた直後は、そのモデルも数回だけ引きずりました。会話に残った壊れた出力に釣られたのだと思います。**元記事の見立ては、ここでは当たっています。** ただ、それは数分で止まりました。そのあとは、何百回動いても一度も出していません。 そして——会話の履歴はそのままに、モデルだけをOpus 4.8に戻したら、**3秒で再発しました**。 履歴は同じ。変えたのはモデルだけ。それで、止まったり、また出たりする。会話が汚れていることも効いてはいる。でも、主な原因はそちらではなかった、ということです。 ![異常な出力の行数。作業ログ2,315件の機械集計で、Opus 4.8が1,139行、Sonnet 5はほぼ0、Fable 5とOpus 4.7は0。同じ作業の中では、Opus 4.8で多発、別のモデルに切替、数分で停止、履歴はそのままモデルだけ戻す、3秒で再発、という経過をたどった](画像/opus48-court/slide2-which-model.png) だから僕は、Fable 5かSonnet 5、あるいはOpus 4.7を使っています。 Opus 4.7は、モデルの一覧に出てこないことがあります。それでも、こう打てば切り替わります。 ``` /model claude-opus-4-7 ``` 一覧の「opus」という選択肢は、その時点のおすすめを指す看板のようなもので、今はOpus 4.8を指しているだけです。Opus 4.7が消えたわけではありません。型番を直接打てばいい。 正直に書いておくと、**Opus 4.7で本当に症状が抑えられるかは、まだきちんと確かめていません**。僕のログではOpus 4.7の時期に症状は出ていませんが、それは単に使った量が少なかっただけかもしれない。ここは推測で断言しません。確実なのは、FableとSonnetでは止まる、ということです。 もう一つ、これは元記事に書かれていない落とし穴です。「Opus 4.8は避ける」と決めても、利用の上限に達すると、道具が **黙ってOpus 4.8に切り替わる** ことがあります。実際、Fableで動かしていたはずの作業に、Opus 4.8の区間が紛れ込んでいて、そこだけ症状が出ていました。モデルを選び直すだけでは、安心しきれません。 ![Opus 4.8を避けると決める、利用の上限に達する、黙ってOpus 4.8に切り替わる、その区間だけ症状が出る、という流れ図。モデルを選び直すだけでは安心できない](画像/opus48-court/slide3-fallback.png) ## これは、まだ根本解決ではありません ここまで書いておいて何ですが、これは応急処置です。 原因はモデルの側にあります。使う側が、指示の書き方を工夫して直せる種類の問題ではありません。元記事も最後にそう書いていました。根本修正はAnthropic側の領域だ、と。同じ結論です。 だから、僕にできるのは、症状の出ないモデルで作業を回すことと、AIの「できました」を鵜呑みにせず、実際の状態を自分で確かめることだけです。 Opus 5あたりで直ることを期待しています。それまでは、FableとSonnetで、だましだましやるしかないと思っています。 賢いモデルを最初から最後まで使うことが、いつも正解とは限りません。今いちばん安定して仕事が終わる組み合わせを選ぶ。それだけのことです。 [モデルの切り替え方そのものを測った話: Fableであなたは損してます！モデル切り替えのベストプラクティスの実態実験](https://aika-keiei.com/articles/model-switch-cache/) --- この記事の元手は、僕自身のAIとのやりとりの記録——作業ログ2,315件——でした。こういう生の記録を捨てずに残しておくと何ができるか、という話も書いています。 [AI要約は「未来の問い」を知らない時点での圧縮である](https://aika-keiei.com/articles/gijiroku-genten/)