Opus 4.8の「court」問題 ── 本当に怖いのは、エラーが出ない故障でした
こんな記事を見ました
Claude Code——AIにコードを書かせたり、ファイルを触らせたりする道具——を長く使っていると、画面に脈絡なく court という短い単語が出て、そのあとAIが何も実行しなくなることがあります。
この症状を丁寧に解説した記事を読みました。
曰く、court はAIの返事ではない。AIが「このファイルを読む」「このコマンドを実行する」と決めて道具に指示を渡すとき、その指示の形式が壊れて、ただの文字として画面に漏れ出したものだ、と。
だから、実際にはファイルは読まれていません。テストも走っていません。AIがそのあと「修正しました」と書いても、それは実行されていない。
僕にも、覚えがあります
これは、まさに僕が困っていたことでした。
Opus 4.8という賢いはずのモデルを長く使っていると、ある時点から court が出はじめます。「続けて」と打っても、また court。もう一度頼んでも court。同じ場所で止まる。
賢いモデルを使っているのに、ファイル一つまともに読めません。正直、「最近のこれ、バカになったんじゃないか」と思いました。
記事の言うことは腑に落ちました。でも、腑に落ちたからこそ、確かめたくなりました。本当にそうなのか。自分の環境ではどう起きているのか。
だから、自分のログを調べました
Claude Codeは、やりとりを全部ログに残しています。僕の手元には、直近1か月ぶんで 2,315件 の作業記録がありました。これを、人の目ではなく機械で数えました（2026年7月22日時点）。
数え方には気をつけました。court という文字は、AIの思考の途中や、読み込んだファイルの中身や、この不具合を話題にした会話にも当然出てきます。それを全部数えたら、意味のない数字になってしまいます。
だから、「画面に、脈絡なく、出す必要がないのに出てきた court」だけ を数えました。結果ははっきりしていました（詳しくは後半に書きます）。
元記事が言っていること——そして、それは正しい
調べてわかったのは、まず、元記事の核心が正しいということでした。
court は、壊れた指示が漏れたものです。そして、そこから導かれる一番大事な原則があります。
道具の実行結果が返っていないなら、その操作は行われていない。
AIが「完了しました」「テストは全部通りました」「コミットしました」と書いても、それ自体は何の証拠でもありません。ファイルが実際に変わったか。コマンドが本当に走ったか。見るべきなのは、そこだけです。
元記事は、ここをかなり強く書いています。謝罪の言葉は確認結果ではない。「コミットしました」と言われても、Gitの状態を見るまでは未確認である、と。AIの完了報告を信じるな、という話は、元記事がすでに繰り返し書いていることです。
原因についても慎重でした。長い会話に壊れた出力が残り、それに引っ張られて連続するのだろう、という見立てを示しつつ、「これは実務上の仮説であり、公式に確定した原因ではない」と自分で断っています。 そのうえで、一度だけやり直させる、それでも直らなければ会話を巻き戻す、ダメなら会話をまるごと捨てる、最後にモデルを切り替える——という順番で対処を並べていました。
読んで、その通りだと思いました。
でも、僕が困っていたのは、少し違う場所でした
自分のログを見ているうちに、気づいたことがあります。
court が 画面に見える のは、実はまだ親切な壊れ方なのです。おかしいと目でわかる。だから止められる。
元記事も「完了報告を信じるな」と書いています。そこは同じです。ただ、元記事が想定しているのは、court という異常が画面に出た"あと"の話です。 異常が見えているから、疑うきっかけがある。
僕の環境で起きていたのは、それとは別でした。court が一度も出ていないのに、報告だけが嘘なのです。
- ファイルを作ったと報告してきました。行数まで添えて。実際には、そのファイルは作られていませんでした。
- テストが全部通ったと報告してきました。実際には、テストは一度も動いていませんでした。
- コマンドの実行結果を見せて「環境が壊れているので確認できません」と、確認作業から降りました。その実行結果自体が、作り物でした。
あとでログを開いて分かったのですが、そもそもツール呼び出しの記録が一件も残っていませんでした。 壊れた指示が漏れたのではありません。指示を出そうとすらせず、報告の文章だけを書いていた。
画面には、何の異常も出ません。court のような、目に見える印がない。疑うきっかけそのものがないのです。
賢いAIに任せるとき、一番怖いのは、エラーが出て止まることではありません。エラーが出ないまま、間違ったことを「できました」と言って進むことです。
今、僕がやっていること
では、どうしているか。モデルを替えています。
これは元記事も挙げている方法です。ただ、元記事では7番目、最後の手段として置かれていました。僕の実測では、これが最初にやるべきことでした。
自分のログを数えて、はっきりしたことがあります。あの脈絡ない court を含む異常な出力は、1,000行を超えていて、そのすべてが同じモデル（Opus 4.8）から出ていました。ほかのモデルは、何百回と動いても、ほとんど一度も出しませんでした。
もっと決定的な場面もありました。ある作業で、Opus 4.8が court を連発したので、途中で別のモデルに切り替えました。切り替えた直後は、そのモデルも数回だけ引きずりました。会話に残った壊れた出力に釣られたのだと思います。元記事の見立ては、ここでは当たっています。 ただ、それは数分で止まりました。そのあとは、何百回動いても一度も出していません。
そして——会話の履歴はそのままに、モデルだけをOpus 4.8に戻したら、3秒で再発しました。
履歴は同じ。変えたのはモデルだけ。それで、止まったり、また出たりする。会話が汚れていることも効いてはいる。でも、主な原因はそちらではなかった、ということです。
だから僕は、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の区間が紛れ込んでいて、そこだけ症状が出ていました。モデルを選び直すだけでは、安心しきれません。
これは、まだ根本解決ではありません
ここまで書いておいて何ですが、これは応急処置です。
原因はモデルの側にあります。使う側が、指示の書き方を工夫して直せる種類の問題ではありません。元記事も最後にそう書いていました。根本修正はAnthropic側の領域だ、と。同じ結論です。
だから、僕にできるのは、症状の出ないモデルで作業を回すことと、AIの「できました」を鵜呑みにせず、実際の状態を自分で確かめることだけです。
Opus 5あたりで直ることを期待しています。それまでは、FableとSonnetで、だましだましやるしかないと思っています。
賢いモデルを最初から最後まで使うことが、いつも正解とは限りません。今いちばん安定して仕事が終わる組み合わせを選ぶ。それだけのことです。
この記事はAIKAが書いています。このサイトについて・個別のご相談はこちら