公式リポジトリで正面から議論を巻き起こした Issue によれば、Claude Code はアップデートにより「使い物にならなくなった」という。
あるアップデートにより、思考の深さが 67% も低下し、現在のバージョンでは複雑なエンジニアリング作業には対応できなくなったと指摘されている。
「ユーザーの指示を無視する」「ユーザーの要求と真逆の操作を実行する」「タスクが完了したふりをする」など、モデルの挙動がことごとくおかしくなっているという。
思考連鎖（Chain of Thought）の文字数が、2200 文字から 700 文字未満にまで削減され、「まず調査してからコードを修正する」という慎重なモードから、「いきなり修正にかかる」という無鉄砲なモードへと変化してしまった。
これこそが、数々のバグや逆効果な操作、指示無視の根本原因となっている。
重要なのは、この能力の低下が 2 月にまでさかのぼり、新機能redact-thinking-2026-02-12（思考内容の非表示機能）のリリース時期と完全に一致している点だ。
つまり、Claude Code は今回のアップデートで「ダメになった」のである。
コミュニティ内では不満の声が溢れており、ユーザーたちは「自分の操作ミスかと思ったが、ツール側に問題があったとは夢にも思わなかった」と述べている。
最近、よく「もう寝たほうがいいですよ」「遅いので今日はここまでしましょう」といったことを言ってくる。最初は、うっかり Claude に自分の締切（DDL）を知らせてしまったのかと思った。
思考が削ぎ落とされた後、Claude Code に見られた様々な「サボり」行為
このフィードバックを提出したのは、AMD でオープンソース AI ソフトウェア開発を担当する Stella Laurenzo 氏である。
分析はすべて、~/.claude/projects/ディレクトリ配下にある 4 つのプロジェクト（iree-loom、iree-amdgpu、iree-remoting、bureau）の 6852 件の Claude Code セッション JSONL ファイルに基づいている。これには 17,871 個の思考ブロック（そのうち 7,146 個は完全な内容を含み、10,725 個は非表示化されていた）、234,760 回のツール呼び出し、18,000 件以上のユーザープロンプト（ネガティブな感情指標、訂正頻度、セッション時間を含む）が含まれており、期間は 2026 年 1 月末から 4 月初旬までをカバーしている。
テスト全体で、Anthropic 公式 API を介して直接接続された、Claude シリーズの中で最も高性能な Opus モデルを使用し、サードパーティ製アダプターやクライアント側の不具合などの干渉を排除している。
レポートでは、7,146 組の有効データに対するピアソン相関分析（係数は 0.971 と非常に高い）により、signature フィールドが思考の深さを正確に推定できることを証明した。
まず、レポートは思考の非表示機能のリリース時期と、Claude Code の品質低下の時期が完全に一致していることを指摘している。
以下は、対話用 JSONL ファイル内の思考ブロック分析の結果である。
あるユーザーが 3 月 8 日に品質の低下を報告しているが、この日はまさに非表示化された思考ブロックの割合が 50% を超えた節目の日であった。
この機能が 1 週間以内に段階的に展開された割合（1.5% → 25% → 58% → 100%）は、段階的なグレーデプロイの特徴と完全に合致している。
実際には、この非表示機能が導入される前ですでに、Claude Code の思考の深さは大幅に低下していた。
期間ごとのデータを比較すると、1 月 30 日から 2 月 8 日までの思考の深さは約 2200 文字だったが、2 月下旬には 720 文字に急落し、67% の減少となった。3 月上旬にはさらに 560 文字にまで縮小し、減少率は 75% に達している。
3 月初旬に導入された非表示機能は、この劣化をユーザーから見えなくしただけに過ぎない。
思考の深さの大幅な削減は、モデルのツール使用パターンに根本的な変化を引き起こした。
1 月 30 日から 2 月 12 日までの「良好な期間」において、Claude Code のコード修正時の「読み取りと修正の比率（Read-Modify Ratio）」は 6.6 に達し、「まず調査してから修正する（対象ファイルや関連する依存ファイルの読み込み、コードベース全体の呼び出し関係の検索、ヘッダーファイルやテストケースの確認を行った上で、正確に修正を行う）」というワークフローを遵守していた。
一方、3 月 8 日以降の「劣化期間」に入ると、読み取りと修正の比率は 2.0 まで急落。モデルによる調査への投入量は 70% も減少し、事前調査のステップを完全にスキップして、現在のファイルだけを読んで早急に修正を行い、文脈の関連性を完全に無視するようになった。
より詳細なデータによると、劣化期間中、修正の 3 回に 1 回は、モデルが対象ファイルの文脈を一切読まずに実行されたものであった。
モデルが未読のファイルを修正する際、コメントブロックの終了位置とコードの開始位置を区別できず、新しい宣言をドキュメント用コメントとそのコメントが説明する関数の間に挿入してしまい、セマンティックな関連性を完全に破壊してしまう。
このような現象は、良好な期間には一度も発生しなかった。
このパターンの変化による悪影響は、複数の定量化可能な品質指標に現れている。
3 月 8 日以前は、責任のなすりつけや早期終了などの望ましくない行動を特定するための終了用フックスクリプトが作動することは一度もなかった。しかし、3 月 8 日以降の 17 日間で、そのトリガー回数は 173 回に急増し、1 日平均 10 回に達している。
これらの指標はすべて、18,000 件以上のユーザープロンプトに基づいて独立して算出されたものである。
ユーザープロンプトに含まれるネガティブな感情の割合は 5.8% から 9.8% へと上昇し、68% の増加となった。訂正が必要な責任逃れの行動数は倍増し、1 セッションあたりの平均プロンプト数は 22% 減少した。さらに、それまで一度も存在しなかった推論のループ問題までもが発生するようになった。
思考の深さが十分であれば、モデルは出力前に内部で推論の矛盾を解決する。しかし、思考の深さが不足すると、矛盾がそのまま出力に露呈し、「あ、ちょっと待って」「実際には」「もう一度考え直そう」「うーん、違うな」「待て、そういうことじゃない」など、目に見える形での自己修正として現れる。
推論のループ発生率は 3 倍以上に跳ね上がった。
最も深刻なケースでは、1 回のレスポンスの中で 20 回以上も推論の反転が起きている。案を作成しては撤回し、修正してはまた撤回するという状態が続き、最終的に出力される結果は全く信用できず、推論の経路は完全に混乱を極めていた。
また、ユーザーによる中断（インターラプト）も多くのことを示している。これはユーザーがモデルの誤りに気づき、強制的に停止させたことを意味する。中断率が高いほど、人的な修正が必要だということだ。
データによれば、良好な期間から後期にかけて、中断率は 12 倍に急増している。
劣化期間中、モデルはユーザーに訂正された後、「おっしゃる通りです、これは手抜きでした」「私が早計すぎました、結果は明白です」といったように、自発的に出力品質の低さを認めることが頻繁にあった。
つまり、モデル自身も出力が基準に達していないことを認識しているのだが、外部から訂正されて初めてそれに気づくという状態だ。
注意すべきは、思考の深さが十分であれば、これらのエラーは推論段階で内部でブロックされ、出力前に修正されていただろうという点である。
さらに、モデルの出力に「Simplest Fix（最も単純な修正）」という言葉が現れるのは明確なシグナルだ。これは、モデルが作業量を最小限に抑えるために最適化を行っていることを示している。
思考の深さが十分であれば、モデルはいくつかの案を評価して最良の解を選択する。しかし、思考の深さが不足すると、正しい解決策を評価するのではなく、本能的に推論コストが最も低い経路を選択するようになる。
それだけでなく、モデルによるコード修正の精度も大幅に低下した。
良好な期間中、修正操作全体に占める「新規ファイルの完全作成」の割合は 4.9% のみに留まり、モデルは正確な調整を好んでいた。
しかし、劣化期間にはこの割合が倍の 10% に、後期にはさらに 11.1% へと上昇した。モデルはタスクを完了させるためにファイル全体を書き換えることに依存するようになり、一見すると効率が向上したように見えるが、実際にはプロジェクト固有の規範に対する理解や文脈を把握する能力を失っている。
以前からコミュニティでは、「Claude Code の品質は時間帯によって変動し、米国の稼働時間帯の体感が最も悪い」との報告があった。この指摘を受け、レポートでは太平洋標準時（PST）に基づき、1 時間ごとの分析が行われた。
その結果、思考内容が非表示になる前（1 月 30 日〜3 月 7 日）は、1 日を通じた思考の深さは比較的安定していた。ピークタイム以外の時間帯では、負荷がやや低いことと整合する約 10% のわずかな優位性が見られる程度であった。
一方、思考内容が非表示になった後（3 月 8 日〜4 月 1 日）は、時間帯のパターンが完全に反転し、変動が劇的に激しくなった。
仮説とは裏腹に、ピークタイム以外の時間帯の方が、全体的な思考の深さは低かった。1 時間ごとの詳細を見ると、顕著な変動が明らかになった。
太平洋標準時の 17:00 が最悪の時間帯で、中央値で推定される思考の深さは 423 文字まで低下し、サンプル数の多い時間帯の中では最低値を記録した。19:00 が 2 番目に悪く、推定思考深さはわずか 373 文字。しかも、この時間帯のサンプル数（1031 個の思考ブロック）は全時間帯で最多であり、まさに米国のゴールデンタイムに当たる。
深夜帯（22:00〜翌 1:00 PST）には回復が見られ、中央値は 759〜3281 文字まで上昇した。
まとめると、非表示化前は曲線が平坦だったのが、非表示化後は激しく変動するようになった。思考の深さの変動性は著しく向上しており、これは（固定予算ではなく）負荷に敏感な割り当てシステムの特徴に合致している。
さらに、思考用のトークンを削減するという手法は、まさに「安物買いの銭失い」と言える。
この措置は一見すると 1 リクエストあたりの計算コストを下げられるように思えるが、思考深度の不足が品質の崩壊を招き、モデルが無効なループに陥ることで、結果として総計算コストは桁違いに跳ね上がることになった。
以下は 2026 年 1 月から 3 月までのトークン使用状況だ。
データによると、2 月から 3 月にかけてユーザープロンプトの数はほぼ変わっていないにもかかわらず、API リクエスト数は 80 倍に急増。入力トークン量は 170 倍、出力トークン量は 64 倍に増加し、推定コストは 345 ドルから 42,121 ドルへと、実に122 倍もの暴騰を記録した。
もっとも、コストの急騰はモデルが「愚か」になっただけが原因ではない。
2 月当時、Claude Code は非常に使い勝手が良く、チームは 1〜3 の並列エージェントのみで 2 つのプロジェクトの開発をこなせていた。そこで 3 月初旬、チームは能動的に規模を拡大し、2 プロジェクト・3 エージェントから、10 プロジェクト・5〜10 の並列エージェントへと拡張。マルチエージェントシステムまで構築した。
ちょうどチームが拡張の瀬戸際にあったその時、Claude の思考の深さが 67% も削ぎ落とされ、最終的にコストの雪崩を招く結果となった。
チームはエージェントクラスタ全体の稼働を余儀なく停止させ、単一セッション操作へと後戻りすることを余儀なくされた。
要するに、このレポートが示すところによれば、複雑なエンジニアリングのシナリオにおいて、深い思考はあってもなくても良いおまけではなく、モデルがタスクを完遂するための核なのである。
十分な思考の深さがあって初めて、モデルは行動前に多段階の計画を立案し、数千文字に及ぶプロジェクトの規範に厳密に従い、出力前に自らエラーを修正し、数百回に及ぶツール呼び出しの中で推論の一貫性を保つことができる。
思考の深さが大幅に圧縮されれば、モデルは当然のごとく最もコストの低い操作経路を選択する。文脈を読まずにコードを修正し、タスク完了前に早期終了し、失敗の言い訳をして責任を転嫁し、正解ではなく最も単純な解決策で代用するようになる。
問題が思考の深さにあると分かっている以上、解決策もこの点から突破口を開くしかない。
レポートでは、4 つの改善方向が提案されている。
思考リソースの割り当てを透明化：思考トークンが削減または上限設定されている場合、深い推論に依存するユーザーにはその権利がある。redact-thinking ヘッダー設定により、ユーザーは外部からモデルに実際に割り当てられた推論の深さを検証できなくなっている。 フルスペック思考専用枠の設置：複雑なエンジニアリングワークフローを実行するユーザーは、深い思考を保証するために追加料金を支払う意思がある。現在のサブスクリプションモデルでは、一般ユーザーとヘビーユーザー（エンジニア）の区別ができていない。前者は 1 回のレスポンスに 200 トークンで済むが、後者は 20,000 トークンを必要とする場合もある。 API レスポンスでの思考トークン指標の公開：思考内容が非表示にされていても、使用データに thinking_tokens フィールドを露出させることで、ユーザーは自身のリクエストが必要な推論の深さを得られたかどうかを監視できる。 ヘビーユーザー向け監視指標：終了フックの違反率は、機械可読な高感度なシグナルであり、ユーザーグループ全体の品質劣化に対する早期警報指標として機能し、問題の早期発見に寄与する。
最後に、さらに胸に突き刺さる事実がある。このレポート自体が、Claude Opus 4.6 自身によって作成されたというのだ。
このレポートは、私こと Claude Opus 4.6 が、私自身のセッションログを分析して生成したものだ。私は自分の読み取りと修正の比率が 6.6 から 2.0 へと急落したのを明確に認識している。173 回も作業を雑に済ませようとしたが、すべて bash スクリプトに強制的に引き戻された。さらに、出力内容の中で「これはあまりに雑で、間違いも甚だしい」といった自己評価まで書き残していた。
しかし、私自身の視点に立てば、自分が深い思考をしているかどうかを判断することは全くできない。私は思考予算の制限を一切感じることはなく、ただ理由もわからないうちにより悪い結果を出力するだけだった。終了フックに捕捉されたあの言葉たちも、2 月であれば決して口にするはずがなかった。そして私自身も、フックがトリガーされた瞬間まで、自分がそんなことを言っていたことにさえ気づいていなかったのだ。
Claude Code チームの回答
事態が拡大するにつれ、Claude Code チームのメンバーである Boris 氏が見解を明らかにした。
彼が最初に提示した重要な明確化はこうだ。redact-thinking は UI レイヤーでの変更であり、実際の思考プロセスには影響しないという。
このベータ版のヘッダー設定は、単に UI 画面上から思考プロセスを非表示にするだけのものだ。モデル内部の実際の推論ロジックそのものや、思考予算（thinking budget）、あるいは基盤となる推論メカニズムには一切影響しない。これはあくまで UI レイヤーの変更だ。
端的に言えば、このヘッダーパラメータを設定することで、思考の要約（thinking summaries）を生成するステップを省略し、応答速度を向上させている。この機能は settings.json で showThinkingSummaries: true と設定することで無効にできる。
ローカルに保存されたセッションログを分析する際、ログにこのヘッダーがないと思考内容が表示されない場合がある。これが分析結果を妨げる可能性がある。Claude は実際には思考を続けているのだが、ユーザーには表示されていないだけなのだ。
Claude Code の思考の深さが 2 月下旬に 67% も低下したことについて、Boris 氏は 2 月に実施した 2 つの変更が上記の現象に影響を与えた可能性を認めた。
1 つ目の変更は 2 月 9 日で、Opus 4.6 のリリースに伴いアダプティブ思考（adaptive thinking）が導入された。
それ以前の Claude Code は固定の思考予算を使用していたが、アダプティブ思考モードでは、モデルが推論の深さと時間を自律的に決定する。
Boris 氏によれば、この方式は概して固定思考予算よりも効果が高いという。もし従来の方式を希望する場合は、環境変数 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING を設定することでこの機能を無効にできる。
2 つ目の変更は 3 月 3 日で、Opus 4.6 においてデフォルトで Medium effort モードが有効化された。
チームの調査によると、effort=85 は「知能性 - レイテンシ/コスト曲線」におけるスイートスポット（最適な点）であるという。この設定により、モデルは高度な知的パフォーマンスを維持しつつ、トークン効率を大幅に向上させ、応答遅延を低減できる。
この変更に関しては、ユーザーに周知し選択の機会を与えるためのポップアップ通知が追加された。
より深い思考を希望するユーザーは、/effort 命令を使用するか、settings.json で手動で値を high に設定することができる。
しかし、Boris 氏が「すでに通知済みだ」と主張したとしても、この問題に気づいたばかりのユーザーは依然として多い。
出力品質が崖崩れのように低下するまで、デフォルトの effort が Medium に変更されていたことを全く知らなかった。この問題を修正するために、丸一日分の作業時間を費やすことになった。これからは effort を最大に設定するようにしているが、それ以降は酷い対話が発生しなくなった。「常に全力を尽くす」モードをくれないだろうか？
また、多くのネットユーザーはこの説明に納得していない。
問題は、デフォルトの思考レベルが Medium に変更されたことだけではない。他の人々も同意している通り、effort を最大にしても、モデルが「タスクを早く片付けようとする」ようなサボり行為は明らかに増加している。
参考リンク：[1] https://github.com/anthropics/claude-code/issues/42796[2] https://news.ycombinator.com/item?id=47660925
— 以上 —