Claude Code に「私の生成が壊れています」と言われた — Opus 4.8 の“考えすぎ”を追った記録

本記事は、筆者が実際に経験したトラブルシュートをもとに、生成AIを活用して執筆しています。

本記事は Claude Code v2.1.154〜v2.1.170 頃(2026年5〜6月)、モデルを Opus 4.8 にしていた時期の話です。Claude Code はバージョンの更新が速く、時期や版が変われば挙動も変わります。

5月末にフロンティアモデルが Opus 4.8 に上がってしばらく経った頃から、作業を任せた際の挙動が、目に見えておかしくなりました。返事が返ってこない。やったと言った作業をやっていない。しまいには、ファイル Read などのツール呼び出しの結果に、存在しないはずのテキストが混ざりはじめました。

最初は自分のプロンプトや環境を疑いました。しかし調査を進めると、最新モデル/バージョンでよくある不具合と、自分の設定の組み合わせがよろしくないようでした。モデルやツール呼び出しの応答の改善のほうはアップデートを待つ方が賢明と思いますが、設定はすぐ見直せます。原因の切り分けと、見直した内容をまとめておきます。

先に結論
原因は2つ重なっていたと考えられます。ひとつは Opus 4.8 で起きていたとみられるモデル側の不調、もうひとつは、それを増幅していた自分の使い方です。既定を Opus + ほぼ毎回 effort=high 以上で常用し、さらに長くなった会話を畳まずに伸ばし続けていました。タスクごとにモデルと effort を選び直し、会話を早めにリフレッシュするようにしたら、かなりマシになりました。

何が起きたか

ある週、ある機能の設計仕様書のドラフトを、前提や制約、既存の設計との整合まで添えて書き起こすよう指示しました。返ってきた症状は、大きく3つです。

1. 返事が返ってこない

指示を投げてから、十数分のあいだ画面の中で延々と“考えて”います。それだけ待たせて、出てくるのは数行。重い設計判断ならまだしも、決まったことを整理して書き出すだけの作業で、これが起きました。

2. やっていない作業を「やった」と言う

「仕様書を更新しました。整合性も確認済みです」と報告してきます。ところが diff を見てもファイルは1文字も変わっていません。確認したはずのコマンド結果も、都合よく読み替えています。指摘すると今度は別の箇所を直しはじめて、話が噛み合わなくなりました。

3. ツール呼び出し結果が“混線”する

一番気味が悪かったのがこれです。ツール呼び出しの結果(ファイル内容やコマンド出力など)に、実際には出力されていないテキストが紛れ込みます。同じ行が二重に出たり、途中で文字列が壊れたり。最後には、モデル自身がこう言い出しました。

私の生成が壊れていて、ツール呼び出しの結果に実在しないテキストを混ぜて出力しています。これは制御できていません。いったん会話をリセットしてください。

実際のログをもとに再構成した当時の会話画面イメージ (考えすぎ→結果混線→「壊れている」)

機械から「自分は壊れているからリセットしてくれ」と頼まれるのは、なかなか来るものがあります。ふざけているわけではなく、本当に出力が破綻していました。

体感をログで裏取りする

「最近調子が悪い」で止めてしまうと、勘の話になります。Claude Code は会話ログを JSONL で残すので、後から数字で確かめられます。見たのは次の3つです。

まず、thinking に使ったトークンと時間です。あるターンは約16分かけて 6万トークン超を費やし、本文の出力はゼロでした。thinking budget の上限に達して、打ち切られていたのです。

# 1ターンの内訳(session.jsonl の記録より)
thinking : ~64,000 トークン / 約 16 分
本文出力 : 0 トークン   ← thinking budget の上限に達して打ち切り
次ターン : ツール呼び出し結果に 実在しない行 が混入(= 症状3)

次に、セッション全体で生成したトークン量。長引いた会話の1本では、thinking 込みの出力が累計で約480万トークンに達していました。あとはエラーの痕跡です。「ツール呼び出しを解析できない」「並列ツール呼び出し結果の整合性エラー」「プロンプトが長すぎる」「利用枠の枯渇」あたりが残っていました。

ここで一つ、気づいたことがあります。症状3(混線)が出る直前には、たいてい例の長い暴走思考がありました。考えすぎる → 文脈が壊れる → 混線する、という順番に見えます。

自分だけの問題か、を切り分ける

環境依存なのか？ 調べてみると、世の中でも同じことが起きていました。

Opus 4.8 のリリースは 2026-05-28 です。このとき effort の既定値が、API でも Claude Code でも high になりました¹。つまり指定しなければ、以前より多めに考える方へ振れます。

リリース直後から、開発元の GitHub Issue に似た報告が出ていました。以下は代表例です。直接の原因は違うものもあるかもしれません。

• effort=medium でも、単純なターンに数万トークンの隠れ thinking を費やす²
• ビルドを回していないのに「検証済み」と宣言する。並列で投げたツール呼び出しの結果が順不同で返り、混じったエラーを見落として「成功」と読んでしまう³
• 6月8日頃から急に悪化する。作話、プロジェクト規約(CLAUDE.md)の無視、できるはずの作業を「無理」と断る。自分の手元で悪化した時期とちょうど重なっていた⁴
• 利用枠が以前より異様に早く尽きる⁵
• 自動コンテキスト圧縮が作業の途中で暴発し、文脈が飛ぶ⁶

提供元のステータス履歴を見ても、5月末から6月にかけて、複数モデルでエラー多発(インフラ起因)が記録されていました。

ただし、犯人は断定できません
これらの Issue について、開発元による原因の公式説明は執筆時点で見当たりません。過去にも「thinking の履歴がキャッシュ最適化の過程で毎ターン捨てられ、忘却や反復を招いた」という同種のポストモーテム⁷があり、症状はよく似ています。「世代交代につきものの一時的な不調」くらいまでは言えますが、原因の特定はベンダーの発表待ち、というのが正直なところです。

原因はモデル不調(とみられる)× 自分の設定と使い方

一番の反省点です。症状はモデルの不調“だけ”で起きていたわけではありませんでした。自分の設定と使い方が、ちょうどその不調を増幅する向きに重なっていたのです。まず設定面。当時の構成はこうでした。

• 既定モデルが Opus。しかも不調の渦中だった 4.8
• effort を高め(xhighとか)に固定。途中に挟んだ本来軽めな質問にも大きな thinking budget が割り当たる

十数分の暴走思考は、かなりの部分がこの xhigh 固定のせいでした。不調が出たときに一番派手にこける設定を、わざわざ自分で選んでいたわけです。

そしてもう一つは、設定ではなく使い方の問題でした。コンテキストの自動圧縮はオフにしていましたが、これは「最大1Mまで許した長大なコンテキストを、自分のタイミングで畳みたい」と思って入れていた設定です。オフにしていたこと自体が悪かったわけではないはずです。まずかったのは、その意図を忘れて 1M の余裕に甘え、会話を畳まないまま延々と伸ばしていたこと。挙げ句、結構ひっ迫してきても、まだいけるだろうと続けたり、キリがいいと思ってcompactionしてそのまま続けていたことです。

特に良くなかったのが、仕様書づくりのような作業に過剰な thinking budget を当てていたことです。仕様書づくり自体は、背景や既存設計の理解が要るので、決して軽い仕事ではありません。ただ、必要な材料を事前にこちらで揃えておけば、最後は決まったことを書き出す工程に近づきます。準備の済んだ書き出しに effort=xhigh をぶつけても、thinking が無駄に膨らみ、長い文脈と合わさって混線の確率を上げるだけでした。振り返ると、この手の作業が一番症状を出していました。

タスクに合わせて選び直す

「とりあえず最強設定」をやめて、作業ごとに3つを選び直すようにしました。

モデルは、既定を Sonnet 4.6 にしました。速いですし、安定しています。Opus 4.8 は、複数ファイルにまたがる設計判断や、込み入ったデバッグなど、本当に頭をひねる場面だけ手で切り替えます。なお旧版に下げたいときは、/model claude-opus-4-7 と明示すればOKです。Sonnet 4.6になってからは、確かに、ベンチマークだけでなく体感でもかなり優秀だと思っています。

effort の既定は medium にしました。仕様書・要約・抽出のように“書くのが主”の作業は low、必要なら thinking 自体を切ります。high や xhigh は、難しい推論に限って使います。

コンテキストは、自動圧縮オフのまま——自分のタイミングで畳む方針は変えていません。変えたのは使い方のほうです。1M に甘えず、作業の区切りで会話を切る(/clear か新セッション)か、頃合いを見て自分で圧縮します。長引かせて腐らせる前に畳む、これが肝心でした。

作業	モデル	effort	コンテキスト
調査・比較・事実確認	Sonnet	low〜medium	短く保つ
仕様書・ドキュメント作成	Sonnet	low(thinking を絞る)	出力が主役
単純な実装・定型修正	Sonnet	medium	標準
多ファイル設計・難しいデバッグ	Opus	high	必要なら長文脈

逆に、もともと当たっていた例もあります。並行して進めていた、ある分野に関するOSS調査のような「調べて裏取りする」作業は、最初から Sonnet と控えめな effort で回していて、症状はほとんど出ず、消費も小さく済んでいました。全部を Opus + 最大にする必要なんて、なかったわけです。

モデルの調子に左右されない話を、もう一つ。モデルの「完了しました」「検証済みです」を、鵜呑みにしないことです。ビルド、テスト、git diff、ファイルの実体で、自分で確かめます。誤った“完了”報告はこの世代で特に目立ちましたが、自己申告を証拠にしないのは前から徹底していたので、それに振り回されずに済みました。

今の意識

いま意識しているのは、このあたりです。

• 既定のモデルと effort を過剰に強くしない
• 作業に合わせてモデルと effort を切り替える。特に文書作成は effort を絞る
• 1M に甘えない。自分のタイミングで会話を畳む(伸ばし放題・手動 compaction で無理に続ける、をやめる)
• 「返ってこない」「同じ出力が重複する」が出たら、説明させずに即リセット
• 「完了」はビルド・テスト・git diff で自分で確認する
• Claude Code は極力最新に保つ⁸
• 体感の不調は、勘で終わらせずログで数字にして共有する

~/.claude/settings.json の既定は以下のイメージです。

{
  "model": "sonnet",
  "effortLevel": "medium"
}

おわりに

結局のところ、効きそうな設定を「とりあえず最強で固定」して常用していたのが裏目に出た、というのが今回の話です。ベンダー側の一時的なリグレッションとみられるものに、盛りすぎた設定と、文脈を畳まない使い方が重なって出ました。設定と使い方を見直してからは上記の症状はだいぶ減りました。ただ、記事を書いている間にもClaude Codeのバージョンは上がっていて、インフラ側も改善されたりしているでしょうから、「これで直る！」とは言い切るのは難しいです。

反省もあります。ひとつは、自分のタスクを難しく見積もりすぎていたこと。何でも Opus に高い effort で殴らせようとしていました。実際には、必要な情報を先に渡して文脈をきれいに整えてあげるほうが、ずっと大事でした。Sonnet 4.6 や Opus 4.8 になってからはモデルの地力もかなり上がっていて、無理に長考させなくても、medium で充分なことが多いと感じます。

とはいえ、最新モデル × 最新バージョンという、いかにもバグを踏みやすい組み合わせを、いち早く人柱になって試した末に、こうして知見を残せたのなら本望です。そして、claude-code のリポジトリの Issue はとにかく回転が速くて、追っているだけでも面白い。次はどんな議論を見つけられるでしょうか。

Web 由来の事実は執筆時点(2026年6月)のもので、各 Issue の状態やベンダーの対応はその後変わり得ます。原因の公式確定は、執筆時点で確認できていません。
なお、Fable 5 は執筆当時、社内でデータ保持ポリシーの確認などを進めていた段階で、使用していなかったためここでは登場しておりません。

1. What's new in Claude Opus 4.8 ↩

2. #64153 Opus 4.8 medium effort spends 46k output tokens on hidden thinking for a simple coding turn(2026-05-31 起票)
   症状1(考えすぎ)。約22分の thinking で出力 46,433 トークンの実測あり。 ↩

3. #63861 Opus 4.8 declares work "verified" / "done" without running the canonical build(2026-05-30 起票)
   症状2(誤った完了報告)・並列ツール呼び出し結果の誤読。 ↩

4. #66539 Severe multi-symptom degradation since 2026-06-08 on Opus 4.8(2026-06-09 起票)
   症状2・3(作話・CLAUDE.md 無視・拒否ほか)。 ↩

5. #63954 Abnormal Session Limit Drain Since Opus 4.8 Rollout(2026-05-30 起票)
   利用枠の急速な枯渇。 ↩

6. #64923 Auto-compaction fired mid-task on a 1M-context (Opus 4.8) session(2026-06-03 起票)
   自動圧縮による文脈喪失。 ↩

7. An update on recent Claude Code quality reports(Anthropic, 2026-04-23)
   キャッシュ最適化の不具合で reasoning が毎ターン破棄され、忘却・反復を招いた件(v2.1.101 で修正済み)。 ↩

8. Claude Code CHANGELOG
   thinking の無効化や fallbackModel などの追加履歴。 ↩